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

Tisztázzuk az alapokat: big data, nosql, ES, APM

Mielőtt nagyon belemélyednél a konkrét témákra (lásd címben), talán érdemes tisztázni, hogy mit is jelentenek ezek a fogalmak, mi közük van egymáshoz és konkrétan én mit értek ezeken. Ebben a postban véletlenül sem szeretném tudományos alapokig részletezni és szakmailag sem mennék bele, célom csak egy általános kép kifejtése azoknak akik csak most ismerkednek ezekkel a fogalmakkal.
Big data: Kezdeném is mindjárt a legnagyobb lufival. Kezdetben vala a strukturált adattárolás, amikor (az ősidőkben) még luxus volt az adattár, jól végig gondoltuk, hogy mit is akarunk tárolni és törekedtünk arra, hogy ezt a leginkább optimális módon tegyük. Ezzel együtt eljött az internet, eljöttek a felhők (nem… nem a skynet) és eljött mindaz ami ma jellemzi az adattárolást. Az olcsó adattárolás, a mesterséges(-nek tűnő) intelligencia (gépi tanulás) és strukturálhatatlan adatkörök miatt jöt letre az a valami amit big datanak nevezünk. Mi jellemzi ezt: gyakorlatilag mindent tárolunk amilyen adatot csak elő tudunk állítani annak minősége, jellege és értelme nélkül, mindezt tesszük azzal a szándékkal, hogy később feltételezhetően fel fogunk fedezni olyan összefüggéseket, amik értelmet adnak a strukturálatlan adatnak. A régi mondás, mely szerint “a kevesebb több”, mára átalakult a “több az több lehet” mondássá.
Continue reading

ELK: Több Elasticsearch [ES] node futtatása egy hoston

Aki ismeri az Elasticsearch [ES] filozófiáját, az pontosan tudja, hogy alap esetben semmi érteme nincs annak, hogy egy hoston több nodeot futtassunk, hiszen mi is az ES esszenciája: Végy egy halom középkategóriás, olcsón fenntartható gépet, majd minden különösebb technológiai tudás nélkül rakd fel rájuk az ES-t, kapcsold öket egy clusterbe és jöhet a fun. Ha pedig mégsem jön, mert ez így nem elég hatékony, akkor optimalizáld a shardok eloszlását, rakj hozzá a clusterhez még néhány gépet és ezen egyszerű eszközökkel lényegében bármikor tudod skálázni a clustert.

Azonban nagyvállalati környezetben előfordul, hogy középkategóriás olcsó gépek helyett komolyabb vasak kerülnek a kijelölésre. Ilyenkor meg kell tudni találni az ésszerű középutat. Egy önálló ES node kapcsán van néhány olyan technikai függőség, ami meghatározza, hogy maximum mennyi erőforrást tud optimálisan használni. Ezen függőségek közül a leginkább fontos talán a heap size:

  • Az elasticsearch technológiailag java virtuális gépben fut, aminek a heap kezelése erősen kihathat az ES működésére. Technológiai adottság, hogy 32Gb heap size alatt a JVM compressed object pointer (compressed oops) technológiát használ a heap kezelésére, ez felett már nem lehet használni ezt az opciót, ami jelentősen rontja a JVM hatékonyságát.

Continue reading

Szakdolgozathoz segítség…

Sziasztok. Készülő szakdolgozatomhoz kérném segítségeteket. A szakdolgozat témája mi más is lehetne mint: “Befektetési alapok elemzése, vizualizálása egyszerűsített döntéselőkészítés céljából”
Ha van 5-10 perced és segítenél a kérdőív kitöltésével, akkor ezt itt teheted meg:
https://goo.gl/forms/zZvNUvQrBu6UvGMi1

Támogató kérdőív a “Befektetési alapok elemzése, vizualizálása egyszerűsített döntéselőkészítés céljából” szakdolgozathoz. A kérdőív kitöltésével abban tud segíteni, hogy a szakdolgozat minél pontosabb képet mutasson a lehetséges eszközökről és azok használhatóságáról. A Kérdőív teljesen anoním, annak kitöltése semmilyen módon nem kapcsolható a kitöltő személyéhez! A kérdőivnek nem célja, hogy “túrkáljon” a kitöltő zsebében, egyetlen kérdés sem tartalmaz konkrét pénzösszegekkel, fizetéssel, vagyonnal kapcsolatos kérdéseket. A kérdőív kitöltése nagyjából 5-10 percet vesz igénybe.

A segítséget előre is köszönöm,

Ébredező funkcionalitás

Jelezném, hogy A K&H alapkezelő folyamatos adatfrissítése mellett néhány egyéb fukciót is működésre bírtam. Ennek fő oka, hogy beindult a szakdolgozat készítésem aminek témája: “BEFEKTETÉSI ALAPOK ELEMZÉSE, VIZUALIZÁLÁSA EGYSZERŰSÍTETT DÖNTÉSELŐKÉSZÍTÉS CÉLJÁBÓL”. Ennek apropóján újra működnek a következő alapkezelők folyamatos frissítése és bepótlásra került az eddigi adatfrissítés is: OTP, ERSTE, CONCORDE. Terveim szerint megpróbálom feléleszteni még a METLIFE és az UNIQUA alapokat frissítő modulokat is, de ezek lényegesen másabb alapokon nyugszanak. Ezzel párhuzamosan egyéb munkálatok is folyamatban vannak. Remélhetőleg hamarosan újra közel teljes funkcionalitással fog működni az összes korábbi modul.

Nagy rápihenés, karbantartás és új alapkezelő

Rég volt már, hogy életjelet adtam. Volt némi kis kanyar az életemben, ami miatt nem tudtam idekoncentrálni. Ez utóbbi nyilván fenn áll még, úgyhogy a helyzet ezen a téren nem sokat fog változni egyhamar. A BTC bizniszben vegetatív módon még mindig benne vagyok, bár a folyamatosan zuhanó árfolyamok miatt nem őszinte az öröm az arcomon. Előző hét péntekkel sikerült átmigrálni a teljes szervert (amin az oldal is fut) egy lényegesen költséghatékonyabb környezetbe, ennek kapcsán némi fennakadások történtek, de ezeket már orvosoltam. Elvileg semmilyen adat nem veszett el, ha mégis akkor majd pótlom. Ha már hozzányúltam akkor viszont beraktam egy új alapkezelőt is a QUANTIS személyében. Nyilván azért, mert tervezek vele a jövőben alaposabban foglalkozni. A háttere, multja, stb. nem érdekel, csak az eredményei (még mielőtt valaki elkezdené boncolgatni azt.)

10+% profit 5 óra alatt… ilyen ez a Bitcoin

Már egy jó hete benne volt a levegőben egy komolyabb korrekció Bitcoin kapcsán. Az összes relevánsabb szaksajtó egy hete csámszog a kínai jegybank vélt (vagy valós) fenyegetésére mely szerint a nagyobb kínai bitcoin kereskedők számla befagyasztásra számíthatnak ha nem függesztik fel a tevékenységüket. Némi korrekció után jó egy hétig oldalazgatott a Bitcoin árfolyama a 400-460-as sávban, majd tegnap este erősen elkezdett esni annak hírére, hogy már több kereskedő is óvatosságból felfüggesztette a kereskedést. Hajnali három körül érte el az árfolyam a mélypontot, ahol is felülkerekedett a vételi oldal és elkezdték feltornászni az árfolyamot. Nekem 349$-os árfolyamon sikerül beújítanom 25 BTC-t. A BTC jellegéből fakadóan különösebb kockázatot nem láttam a tranzakcióban, hiszen ha a zuhanás tovább folytatódott volna, akkor max veszek a BTC-ből mining hardvert (igen… tudom, hogy ezzel a cikkel még lógok..) és azzal termelem ki a veszteséget 1-2 hét alatt. (ez akár 200 USD/BTC árfolyamig simán működő lett volna).

Continue reading

A motorház alatt…

Szolgálati közlemény: Egy typo hiba miatt számos automatikusan frissülő adat nem frissült Április eleje óta. A hiba javításra került és elvileg minden hiányzó adat pótlásra is került vagy legkésőbb holnap reggelig frissülni fog. Ha mégis bármi hiányozna akkor kérem azt jelezzétek.

Apropó: Mostanában azért ritkultak meg a postok (finoman szólva), mert a jelenlegi témák mellett elkezdtem komolyabban foglalkozni bitcoin bányászattal. Hamarosan érik ebben a témában is egy nagyobb lélegzetvételű bejegyzés. Szintén jelezném az olvasóknak, hogy elvileg van fény az alagút végén nyugdíjbiztosítás terén is. Legalábbis végre megtaláltak egy olyan konstrukcióval amiben eddig nem találtam fogást. A témában szintén készülődik egy post.

Meddig tart még a fejlődő piaci fluktuáció?

Megközelítőleg 2009 óta az erős gazdasággal rendelkező fejlett országok olyan gazdaságpolitikát játszottak, amivel előre kőbe vésték a tavaly nyár óta zajló fejlődő piaci gyengélkedést. Az USA és az Euro kört használó országok a folyamatos monetáris lazításoknak köszönhetően a saját pénzüket gyengítve tették lehetővé, hogy stabilizálják gazdasági helyzetüket. Új világpiaci helyzet keletkezett azáltal, hogy Európa már egyértelműsítette stabilizációját és ezzel befejezettnek tekinti a kiigazításokat, mindezzel párhuzamosan már az USA is erős léptekkel halad a QE#3 likvidálása felé.

Az elmúlt években az európai és az USA gazdasági politika miatt lényegében kéretlen figyelmet kaptak a fejlődő piacok és szabadon ömlött be a spekulatív tőke, ezzel folyamatosan nyújtva el az elmúlt évszázad egyik leghosszabb és egyben talán leglassabb bull piacát. Ez a legtöbb országban azt eredményezve, hogy vagy egyáltalán, vagy csak kis mértékben  kellett a jegybanknak lényegi intézkedéseket foganatosítania a válság hatására. Az állampapírokon keresztül bőségesen likvidek maradtak az országok, miközben egyre nagyobb mértékben nőtt az adott ország kitettsége a külföldi tőke irányába. A 2008-2009-es válság krízishelyzete után mondhatni túlságosan is gyorsan álltak talpra a fejlődő országok.

Ennek hatására sok országot váratlanul ért az elmúlt kb egy év, mely során folyamatosan vonják kifelé a pénzt a fejlődő piacokról. Ezen tevékenységet kiváltó okok között természetesen az USA gazdasági megerősödése áll az első helyen. A jegybank szerepét betöltő FED egyértelműsítette már tavaly nyáron, hogy meglátása szerint a gazdaság megerősödött annyira, hogy önállóan is a saját talpán álljon.

Continue reading

Akik nincsenek a listán…

Biztos sokan olvastátok a portfolio.hu-n megjelent hírt, mely szerint számos hazai bank és takarékszövetkezet kapott összértékében 1,2 milliárdos büntetést, amihez várhatóan további közel 10 milliárdos egyéb kiadás is fog társulni.

Aki esetleg értetlenül állna a hír előtt (mert nem olvasta az eredeti cikket), annak röviden némi magyarázat: A büntetés alapját a 2012-ben megjelent tranzakciós illeték intézmény adja, aminek hatására a pénzintézetek elkezdték ezt a költséget beleépíteni bizonyos számlacsomagokba, amivel – az MNB meglátása szerint – megkárosították az ügyfeleiket. A pontos jogi értelmezés még várat magára, de azt már most lehet tudni a friss információkból, hogy az érintett bankok egy része szeretne bíróságra vonulni.

Elnézve az érintett pénzintézetek listáját mindjárt egy érdekes kérdés merült fel benne: Vajon van-e olyan nagyobb pénzintézet, aki kimaradt a büntetésből? Hosszas bogarászás után is csak három olyan bankot találtam, amire illik a nehezen értelmezhető ‘nagyobb pénzintézet’ kategória, ezek pedig: Kereskedelmi és Hitelbank, UniCredit Bank és a Sberbank (ex Volksbank). Előre is elnézést, ha bárkit is kihagytam volna a felsorolásból. Nyilván előfordulhat, hogy már a megítélésünk a fent jelzett kategória kapcsán.

Tehát az MNB meglátása szerint mindösszesen ezen három bank járt el tisztességesen az ügyfeleivel a tranzakciós illeték kapcsán. Jó tudni… Ahogy azt is jó tudni, hogy a jelek szerint továbbra is komoly szándék van arra, hogy külföldi nagybank hazai leányát államosítsa kormányzat és ehhez egyre újabb és kreatívabb eszközöket talál.