Blockchain elemzés Pythonnal

Most, hogy a kripto piacok erősen az egyet előre, egyet hátra elv szerint működnek (mindezt napi akár 10-15%-os elmozdulásokkal, amiket azért lehet rendesen nyerészkedni) és lényegében már mindenki enerváltan várakozik a augusztusi drámatagozatos óvodások előadására, ahol bal oldalon az UASF család mérhetetlen haragot táplál a jobb oldalon elhelyezkedő BitcoinABC család iránt, mely haragnak az eredeti okára már senki sem emlékszik, de a két család egy-egy sarja… oké, elkalandoztam.

Szóval a nagy rápihenésben végre van időm elővenni a kis házi barkács projektemet. Aki olvasta a self-info postomat, annak ismerős lehet az alábbi rész: “Amivel leginkább szeretnék foglalkozni, az ezen kettő témának (márhogy az Machine-Learning és a Cryptocurrency) összehozatala egy nagy projektté. Persze még messze a cél, de sikerül komolyabb eredményeket felmutatni egy olyan automatizált platform elkészítése kapcsán, ami segíthet hasznos predikciókat készíteni.

Ahol tartok:  az a blockchainek értelmezése és abból hasznos adatok kinyerése. Mivel mapság mindenki blockchain kóder akar lenni (már persze leszámítva azokat akik nem…), ezért gondoltam megosztok néhány nagyon egyszerű példát ami hasznos lehet azoknak akik tényleg csak most ismerkednek a témával. A továbbiakban két minta projektet mutatok be, az első egy egyszerű block explorer és statisztikáció, ami a legyűjti az utolsó 5 block (elmúlt egy óra) teljes tranzakció listáját és abból leválogatja azon bitcoin addresseket, amik az elmúlt egy órában a legtöbb bitcoint szerezték és azokat akik a legtöbbet vesztették el. A második projekt egy egyszerű address explorer, amivel le lehet kérdezni egy konkrét address teljes tranzakció történetét aggregálva blockonként.

Ezek a példák persze önmagukban kb semmit sem érnek, azonban beleillesztve ezeket egy keretbe nagyon is hasznosak lehetnek. Nézzük egy egyszerű példát:

  • Ismeretesek a nagyobb tőzsdék (kraken, bitfinex, pol, stb.) wallet addressei. Ha az elmúlt időszakban ezen addressek irányába nagy mennyiségű bitcoin áramlik olyan privát addressekről amik jelentősebb tranzakciós múlttal rendelkeznek, akkor jogosan lehet feltételezni, hogy ezeket azért rakják oda be, mert el akarják adni vagy fiatra/más kriptora váltani. Ez ugye azt jelentheti, hogy csökkenni fog az adott crypto pénz piaci kapitalizációja. Nyilván ez vice-versa is igaz.

Ennél több részletet egyelőre nem osztanék meg a projektről, de megígérem, hogy folyamatosan közölni fogom a részleteket itt a blogon, ahogy haladok előre. Előbb utóbb tisztulni fog a kép 🙂

Continue reading

Hogyan joinoljunk Elasticsearchben?

Oké, ennyire hülye címet is már régen adtam bármilyen postnak. De lássuk csak, hogy miről is akar ez szólni. Ugye a JOIN egy közkedvelt eszköze a relációs (RDBMS) adatbáziskezelőknek, ami pont az a tulajdonságot használja ki, hogy az adatbázis relációs és annak tartalma normalizált ÉS feltételezhetően vannak benne relációk. Ezen relációk adják az RDBMS rendszerek valódi lépéselőnyét a saját pályájukon. A JOIN lényege az, hogy egy vagy több tábla között létrehozunk logikai kapcsolatot és ezen kapcsolatokon keresztül bonyolult lekéréseket tudunk létrehozni. (vagy éppen ki tudjuk nyírni az egész RDBMS-t egy gyönyörű kaszkád szorzással…)
Namost az Elasticsearch az sem nem RDBMS, sem nincsennek benne reálciók (óóó, dehogy nincs… lásd a cikk végén a parent/child relációt…) és úgy egyébként a JOIN-nak sincs semmi értelme benne. Miért is nincs értelme a JOIN-nak? Az Elasticsearch (és igaz ez a legtöbb key=value alapú NoSQL motorra) pont arra az elvre épül fel, hogy minden egyes dokumentum önálló elem melyek önmagukban értemezhetők és esetleg valamilyen statisztikai elemzést vagy aggregációt akarhatunk rajta végrehajta. Mivel erre van optimalizálva az egész motor, ezért semmi értelme az olyan relációs adatmodellnek, ahol egy indexben tárolunk mondjuk dokumentumokat és felhasználói ID-kat, egy másik indexben pedig tárolunk a felhasználói ID-khoz tartozó neveket és egyéb adatokat. Sokkal egyszerűbb minden releváns adatot minden dokumentum esetén tárolni, hiszen a háttérben a NoSQL motor gondoskodik arról, hogy ezek az adatok ne redundánsan tárolódjanak. Ráadásul az ilyen erőltetett kereszthivatkozások csak lassítják is a keresési performanciát.
Continue reading