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.
