Az Elasticsearch alapértelmezetten nem spórol az indexekben tárolt dokumentumok kapcsán az erőforrásokkal. Ha az adott index nem rendelkezik egy jól felépített és átgondolt mappinggel, akkor az ES gyakorlatilag “szabadfolyást” tart, minden szöveges típust analizál, minden olyan adatot ami rendezhető vagy aggregálható azt inmemory bufferbe lapoz, ráadásul menedzsel egy csomó olyan virtuális fieldet is mint pl az: _all.
Ezzel az ES egy végtelen rugalmasságot és könnyed felhasználást teszt lehetővé, ami a legtöbb projekt esetén egyébként nagyon pozitívan értékelhető hozzáadott érték. Azonban ennek megvan az ára, ez pedig a performancia. Egy tetszőleges ES installment esetén elmondható, hogy néhány millió dokumentumig nem nagyon kell foglalkozni a mappingekkel, hiszen itt még bőven érvényesül az a fajta distributed processing hozzáállás, hogy ha kezd lassulni az indexelés vagy a keresés, akkor bővíteni kell a clustert egy-két extra node-dal (már persze ha az index shard beállításainál ügyeltünk arra, hogy ennek legyen értelme…) és máris normalizálódik a performancia.
Ez a két technológia lényegében uralja a piacot. Előbbi ugye egy robosztus rendszer, ami modulok és célalkalmazások százait vonultatja fel, az utóbbi pedig leginkább keresésre való, de arra viszont nagyon. A megközelítéssel ugye az a baj, hogy a Big Data mint kifejezés pont annyira egzakt mint mondjuk a “cloud”. Tehát önmagában semmit sem jelent és lényegében bármire lehet használni. A megvalószítás technológiai eszközének kiválasztásához nem árt végig gondolni, hogy mit is akarunk tárolni a big data-ban és mit is akarunk azzal csinálni.
A Zcash témával foglalkozó cikksorozat első részében a bitcoin mellett létező alternatív coinok térhódításáról írtam. Ha érdekel, hogy mik ezek az alternatív coinok és mi milyen módon védettek az ASIC mining ellen, akkor olvasd el ezt a cikket: 
A tavalyi évben született majd 200 postba 178828 szó került (javarésze természetesen elgépelve…), az idén eddig született 52 postba pedig eddig 45752 szó. (Számomra) érdekes módon a tavalyi és az idei words/post arány is szinte pontosan megegyezik: 880.9 és 879.8
Szóval ezen fellelkesülve futnék még egy kört: Jelenleg bejáratott frontend programozó csapattagunk üveghangon dolgozik most kb 3-4 projekten, viszont az élet nem áll meg, ezért szeretnénk bővíteni a csapatot. Jelenleg ebben a témában biztosan nem tudunk/akarunk fulltime foglalkoztatni valakit, ezért mindenképp freelancer vagy parttime munkaerőt keresnénk.
