MongoDB Megosztás: lépésről lépésre bemutató bemutató példával

Mi az a Sharding in MongoDB?

A megosztás egy fogalom MongoDB, amely a nagy adatkészleteket több kis adatkészletre osztja fel MongoDB példányok.

Néha a benne lévő adatok MongoDB olyan hatalmas lesz, hogy az ilyen nagy adathalmazokra irányuló lekérdezések jelentős CPU-használatot okozhatnak a szerveren. A helyzet megoldása érdekében, MongoDB A Sharding koncepciója alapvetően az adatkészletek több részre való felosztása MongoDB példányok.

A gyűjtemény, amely mérete nagy is lehet, valójában több gyűjteményre, vagy ahogy nevezik, Shardokra oszlik. Logikusan az összes Shard egyetlen gyűjteményként működik.

A sharding előnyei MongoDB

Mielőtt egy szegmentált klasztert implementálnánk, érdemes megérteni, hogy a csapatok miért alkalmazzák a szegmentálást. A főbb előnyök a következők:

• Vízszintes skálázhatóság: Az adatokat számos árukiszolgáló között osztják el, ahelyett, hogy egyetlen gépet kényszerítenének egyre nagyobb növekedésre.
• Nagyobb áteresztőképesség: Az olvasási és írási műveletek párhuzamosan futnak a szegmensek között, így a klaszter másodpercenként több kérést kezel.
• Nagyobb tárolókapacitás: Az összes szegmens együttes lemeze sokkal nagyobb adathalmazokat képes tárolni, mint amennyit egyetlen szerver képes tárolni.
• Magas rendelkezésre állás: Amikor minden egyes szegmenst replikakészletként telepítenek, egyetlen csomópont meghibásodása nem állítja le a fürtöt.
• Kiegyensúlyozott terhelés: Az MongoDB A balancer automatikusan újraosztja az adattömböket, hogy megakadályozza, hogy bármelyik szegmens hotspottá váljon.

Ezek az előnyök együttesen teszik a shardingot a skálázás standard megközelítésévé. MongoDB egyetlen szerver korlátain túl.

A megosztás megvalósítása

A szilánkokat klaszterek segítségével valósítják meg, amelyek nem mások, mint egy csoportja a MongoDB példányok.

A Shard összetevői a következők:

1. Egy szilánk – Ez az alap, és ez nem más, mint a MongoDB példány, amely az adatok részhalmazát tartalmazza. Éles környezetben az összes szilánknak replikakészletekbe kell tartoznia.
2. Konfigurációs szerver - Ez egy MongoDB példány, amely metaadatokat tárol a klaszterről, alapvetően információkat a különböző MongoDB példányok, amelyek a szegmensadatokat fogják tárolni.
3. Egy router - Ez egy MongoDB példány, amely alapvetően felelős a kliens által küldött parancsok átirányításáért a megfelelő szerverekre.

Lépésről lépésre megosztás Cluster Példa

Step 1) Hozzon létre egy külön adatbázist a konfigurációs kiszolgáló számára.

mkdir /data/configdb

Step 2) Indítsa el a MongoDB példány konfigurációs módban. Tegyük fel, hogy van egy D szerver nevű szerverünk, amely a konfigurációs szerverünk lenne. A szerver konfigurációs szerverként való konfigurálásához az alábbi parancsot kell futtatnunk.

mongod --configdb ServerD:27019

Step 3) Indítsa el a mongos példányt a konfigurációs kiszolgáló megadásával.

mongos --configdb ServerD:27019

Step 4) A mongo shellből kapcsolódj a mongos példányhoz.

mongo --host ServerD --port 27017

Step 5) Ha az A és a B szervert hozzá kell adni a fürthöz, akkor adja ki az alábbi parancsokat.

sh.addShard("ServerA:27017")
sh.addShard("ServerB:27017")

Step 6) Engedélyezze az adatbázis shardingját. Tehát, ha shardingolni kell az Employeedb adatbázist, adja ki az alábbi parancsot.

sh.enableSharding("Employeedb")

Step 7) Engedélyezd a gyűjtemény szegmentálását. Tehát, ha szegmentálni kell az Employee gyűjteményt, add ki az alábbi parancsot.

sh.shardCollection("Employeedb.Employee", { "Employeeid": 1, "EmployeeName": 1 })

Hogyan válasszunk Sharp Key-t? MongoDB

A szegmenskulcs az indexelt mező vagy mezők halmaza, amely MongoDB használ annak eldöntésére, hogy melyik szegmens tárolja az egyes dokumentumokat. Mivel a kulcs határozza meg az adatelosztást, a megfelelő kulcsválasztás a legfontosabb döntés egy szegmenses telepítésben. Egy rossz kulcs egyetlen szegmensre koncentrálja az adatokat és a forgalmat, ami semmissé teszi a szegmensesítés előnyeit.

Egy erős shard kulcs általában a következő jellemzőkkel rendelkezik:

• Magas kardinalitás: A mezőnek sok lehetséges értékkel kell rendelkeznie, hogy az adatokat sok apróra bontható részre lehessen osztani.
• Alacsony frekvencia: Egyetlen érték sem dominálhat, különben az adott értéket megosztó dokumentumok egyetlen szegmensre halmozódnak.
• Nem monoton változás: Az olyan kulcsok, amelyek mindig növekednek, mint például az időbélyegek, minden új írást ugyanarra a szegmensre küldenek, így egy hotspotot hoznak létre.

MongoDB két, a kulcson alapuló sharding stratégiát támogat. A rangozott sharding az adatokat összefüggő tartományokra osztja, és tartományalapú lekérdezésekhez illik, míg a hashelt sharding hash függvényt alkalmaz az írási műveletek egyenletes elosztására a szegmensek között. A csapatok gyakran hashelt shardinggal kezdenek, amikor az írási műveletek nagy mennyiségűek, és átváltanak a rangozott shardingra, amikor a tartományalapú olvasások dominálnak. Bármelyik stratégiát is választja, tesztelje a kulcsot realisztikus lekérdezési mintákkal a véglegesítés előtt, mert a szegmenskulcs az adatok betöltése után nem módosítható könnyen.

Sharding vs. Replikáció MongoDB

A sharding és a replikáció egymást kiegészítő, de különálló funkciók. Az alábbi táblázat kiemeli a különbségeket, így helyesen alkalmazhatja őket, és a gyakorlatban az éles klaszterek együtt használják mindkettőt.

Röviden, a horizontális skálázás a méretezhetőség, míg a replikáció a rendelkezésre állás iránti igényt elégíti ki, és egy robusztus telepítés mindkettőt ötvözi.

GYIK