A legfontosabb MongoDB konfigurációs beállítások a teljesítmény érdekében

A MongoDB rugalmassága és skálázhatósága miatt az egyik legnépszerűbb NoSQL adatbázis napjainkban. Azonban, mint minden összetett rendszer esetében, a nyers teljesítményének kiaknázásához elengedhetetlen a megfelelő konfiguráció. Egy rosszul beállított MongoDB szerver jelentősen lassabb lehet, mint egy optimalizált, még azonos hardver mellett is. Ebben a cikkben végigvesszük a legfontosabb konfigurációs beállításokat, amelyek segítségével maximalizálhatja MongoDB rendszere teljesítményét.

Miért olyan fontos a konfiguráció?

Képzeljük el, hogy van egy sportautónk. Hiába erős a motor, ha a gumik rosszul vannak felfújva, a futómű nincs beállítva, és a vezető nem tudja, hogyan használja ki a jármű képességeit. Hasonlóan, a MongoDB esetében sem elegendő a nagy RAM és a gyors SSD. Az alapértelmezett beállítások sokszor általános felhasználásra vannak optimalizálva, de egy specifikus terheléshez (pl. írás- vagy olvasás-intenzív alkalmazások, nagy adatmennyiség) finomhangolásra van szükség. A cél, hogy az adatbázis ne legyen szűk keresztmetszet az alkalmazásunk számára.

1. Tároló motor (Storage Engine): A WiredTiger ereje

A MongoDB 3.2-es verziója óta a WiredTiger a default tároló motor, és nem véletlenül. Jelentősen felülmúlja elődjét, az MMAPv1-et, többek között a dokumentum szintű zárolás (document-level locking), a beépített adattömörítés és a hatékonyabb memóriakezelés révén. Ha még régebbi MMAPv1 motorral futtatja rendszerét, sürgősen tervezze meg a migrálást WiredTigerre!

storage.engine: wiredTiger: Győződjön meg róla, hogy ez van beállítva.
storage.wiredTiger.engineConfig.cacheSizeGB: Ez az egyik legkritikusabb beállítás! A WiredTiger saját belső cache-t használ, amely alapértelmezetten a fizikai RAM 50%-át foglalja el mínusz 1GB, vagy 256MB-ot, amelyik nagyobb. Sok esetben ez az alapérték ideális, de írás-intenzív terheléseknél vagy akkor, ha a rendszer más szolgáltatásokat is futtat, szükség lehet a finomhangolásra. A cél az, hogy a „hot data” (gyakran hozzáférő adatok) beférjenek ebbe a cache-be. Fontos megjegyezni, hogy az operációs rendszer (OS) fájlrendszer cache-ével együtt kell kezelni, erről később.
storage.wiredTiger.collectionConfig.blockCompressor és storage.wiredTiger.indexConfig.prefixCompression: A WiredTiger támogatja az adattömörítést, ami helyet takarít meg és növeli az I/O teljesítményt, mivel kevesebb adatot kell diszkről beolvasni. Az alapértelmezett tömörítő a snappy, ami jó egyensúlyt kínál a tömörítési arány és a CPU kihasználtság között. Választhatja a zlib-et (nagyobb tömörítés, több CPU) vagy a zstd-t (legújabb, általában legjobb kompromisszum) is, ha a CPU kapacitás engedi. Az indexek esetében a prefixCompression bekapcsolása szintén hatékony.

2. Memóriakezelés és Caching

A memória a MongoDB teljesítményének alfája és omegája. Két szinten is működik a caching:

WiredTiger Internal Cache: Ezt az előző pontban tárgyaltuk (cacheSizeGB).
Operációs Rendszer Fájlrendszer Cache (OS File System Cache): Az OS automatikusan cache-eli a gyakran hozzáférő adatokat a szabad RAM-ban. A MongoDB ezen felül épül fel. Ezért kritikus, hogy elegendő RAM álljon rendelkezésre a rendszer számára. Ha a WiredTiger cache-t túl nagyra állítjuk, az az OS cache elől veszi el a memóriát, ami általában nem optimális. A „hüvelykujj szabály” szerint a RAM 50%-a a WiredTiger cache-nek, a maradék az OS-nek ideális kiindulópont.

A swap memória használatát minden áron kerüljük! A swap a diszkre lapozza a memóriatartalmat, ami drámai teljesítménycsökkenést okoz. Győződjön meg róla, hogy a rendszerén a swappiness értéke alacsony (pl. vm.swappiness=1 vagy 0 Linuxon), és hogy elegendő RAM van a terheléshez.

3. Journaling (Naplózás)

A journaling biztosítja az adatbázis konzisztenciáját és helyreállíthatóságát áramszünet vagy váratlan leállás esetén. A változásokat először a journal fájlba írja az adatbázis, mielőtt az adatfájlokba kerülnének. Ez alapértelmezetten be van kapcsolva WiredTiger esetén és nagyon ajánlott bekapcsolva hagyni éles környezetben. Egy kikapcsolt journal adatvesztést eredményezhet!

storage.journal.enabled: true: Győződjön meg róla, hogy ez igaz.
storage.journal.commitIntervalMs: Ez a beállítás szabályozza, hogy milyen gyakran írja ki a MongoDB a journal bejegyzéseket a diszkre milliszekundumban. Alapértelmezett értéke 50-100ms. Egy alacsonyabb érték (pl. 10ms) nagyobb adatbiztonságot jelent, de növeli az I/O terhelést és kissé csökkentheti az írási teljesítményt. Magasabb érték javíthatja az írási sebességet, de nagyobb a potenciális adatvesztés kockázata egy meghibásodás esetén. Az esetek többségében az alapértelmezett érték megfelelő, de nagy írási terhelésnél érdemes kísérletezni vele, ha a maximális írási sebesség a legfontosabb (felvállalva a minimális adatvesztés kockázatát).

4. Hálózati Beállítások

A hálózati kommunikáció szintén befolyásolja a teljesítményt, különösen elosztott rendszerekben.

net.port és net.bindIp: Győződjön meg róla, hogy a megfelelő porton hallgat az adatbázis, és csak azokról az IP címekről fogadjon kapcsolatot, ahonnan szükséges. A bindIp beállítása biztonsági okokból is kulcsfontosságú.
net.maxIncomingConnections: Ez a beállítás korlátozza az egyidejű bejövő kapcsolatok számát. Az alapértelmezett érték (20000) általában elegendő, de DDoS támadás vagy rosszul megírt alkalmazás esetén megvédheti az adatbázist a túlzott kapcsolatszám okozta leterheltségtől.
SSL/TLS titkosítás: Éles környezetben mindig használjon SSL/TLS titkosítást a hálózati kommunikáció védelmére (net.ssl.mode). Bár ez minimálisan befolyásolhatja a teljesítményt, a biztonság elsődleges.

5. Replikációs halmaz (Replica Set) beállításai

A replikációs halmazok biztosítják a magas rendelkezésre állást és az adatredundanciát. A teljesítmény szempontjából itt is vannak fontos beállítások:

replication.oplogSizeMB: Az oplog (operation log) egy speciális capped collection, amely az összes írási műveletet rögzíti a primár tag-en. Ez alapján replikálják a szekunder tag-ek az adatokat. Túl kicsi oplog méret esetén a szekunder tag-ek „lemaradhatnak” és reszinkronizálásra lehet szükségük, ami terheli a hálózatot és az erőforrásokat. Egy túl nagy oplog feleslegesen foglal helyet. Az ideális méret függ az írási terheléstől és attól, hogy mennyi ideig képes egy szekunder tag offline maradni anélkül, hogy reszinkronizációra lenne szüksége. Általában 24-72 órányi műveletet képes tárolni az oplog, de ezt érdemes monitorozni és finomhangolni.
Read Preference: Bár ez nem konfigurációs fájlbeállítás, hanem alkalmazásoldali, kulcsfontosságú a replikációs halmazok teljesítményéhez. Ha az olvasási terhelés magas, a secondaryPreferred vagy secondary olvasási preferencia használata elosztja a terhelést a szekunder tag-ek között, tehermentesítve a primárit.

6. Sharding beállítások

Nagy adathalmazok és magas terhelés esetén a sharding (horizontális skálázás) a megoldás. A sharding beállítások komplexek, de néhány alapvető szempont:

Shard kulcs (Shard Key) kiválasztása: Ez a legfontosabb döntés a sharding tervezésénél, és szintén nem egy mongod.conf beállítás. Egy jól megválasztott shard kulcs egyenletesen osztja el az adatokat a shard-ok között, minimalizálja az elosztott lekérdezéseket (scatter-gather), és elkerüli a „hot spotokat”. Egy rosszul megválasztott shard kulcs viszont az ellenkezőjét okozhatja, lerontva a sharding előnyeit.
Config Serverek: A config serverek tárolják a klaszter metaadatait. Mindig legalább három config szervert használjon replikációs halmazként a magas rendelkezésre állás érdekében.
mongos instanciák: A mongos routerek irányítják a lekérdezéseket a megfelelő shard-okra. Skálázhatja őket a terhelés elosztásával.

7. Rendszerszintű és OS Beállítások

A MongoDB teljesítménye nagymértékben függ az alapul szolgáló operációs rendszer és hardver megfelelő beállításától.

SSD-k használata: A diszk I/O a MongoDB egyik legnagyobb szűk keresztmetszete lehet. Mindig használjon SSD-ket éles környezetben, mivel sokkal nagyobb IOPS (Input/Output Operations Per Second) teljesítményt nyújtanak, mint a hagyományos HDD-k.
I/O ütemező (I/O Scheduler): Linuxon állítsa be az I/O ütemezőt noop-ra vagy deadline-ra SSD-k esetén. Ezek az ütemezők minimalizálják a késleltetést.
ulimit beállítások: A MongoDB számos fájlleírót és folyamatot használ. Győződjön meg róla, hogy az OS korlátok (nofile a nyitott fájlokra és nproc a folyamatokra) elegendően magasak (pl. 64000 vagy magasabb) a mongod felhasználó számára.
NTP (Network Time Protocol) szinkronizáció: Különösen replikációs halmazok és sharding esetén kritikus, hogy minden szerver órája pontosan szinkronizálva legyen. Az időeltérés súlyos problémákat okozhat a replikációban és a klaszter konzisztenciájában.
Transparent Huge Pages (THP) kikapcsolása: Linuxon a THP funkció (Transparent Huge Pages) teljesítménybeli problémákat okozhat a MongoDB-vel, ezért ajánlott kikapcsolni.

8. Monitoring és Iteratív Optimalizálás

A konfigurációs beállítások finomhangolása nem egy egyszeri feladat, hanem egy folyamatos folyamat. Mindig monitoroznia kell rendszere teljesítményét, hogy lássa, milyen hatással vannak a változtatások.

MongoDB Cloud Manager / Ops Manager: A MongoDB saját monitoring eszközei átfogó betekintést nyújtanak a rendszer működésébe.
Prometheus és Grafana: Népszerű nyílt forráskódú megoldások a metrikák gyűjtésére és vizualizálására.
mongostat és mongotop: Egyszerű parancssori eszközök a gyors áttekintéshez.

Keresse a szűk keresztmetszeteket (pl. magas I/O wait, alacsony cache hit rate, lassú lekérdezések) és célozza meg azokat a beállításokat, amelyek megoldhatják a problémát. Végezzen stresszteszteket és terheléses teszteket a változtatások bevezetése előtt egy tesztkörnyezetben!

Összefoglalás

A MongoDB teljesítményének optimalizálása egy komplex, de elengedhetetlen feladat. A megfelelő WiredTiger cache beállítás, a journaling kezelése, a replikáció finomhangolása, a rendszerszintű paraméterek és az OS beállítások mind-mind hozzájárulnak egy gyors és stabil adatbázishoz. Ne feledje, nincs egy „mindenre jó” konfiguráció. A saját alkalmazása terhelési mintázata és adathalmazának jellege határozza meg, hogy mely beállításokra kell a legnagyobb figyelmet fordítania. Folyamatos monitoringgal és iteratív finomhangolással képes lesz kihozni a maximumot MongoDB rendszeréből.