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.
