Mi a MongoDB Sharding és a bevált gyakorlatok?

Hogyan méretezhető a MongoDB? Melyek a legjobb sharding gyakorlatok??


Noha a rugalmas séma az, ahogyan a legtöbb ember megismeri a MongoDB-t, ez az egyik legjobb adatbázis (a mindennapi alkalmazásoknál talán még a legjobb is) a nagyon, nagyon nagy adatkészletek kezelésére. Noha ennek az érvnek az indokolása önmagában egy teljes cikk kidolgozását igényli (remélem, hogy valamikor időt is találok ehhez!), Az általános gondolat az, hogy az SQL-alapú megoldások nem támogatják a szilánkok kialakítását, és éppen az ön nehézségeire épít.

A legjobb, amire számíthat, ha létrehoz egy fürtöt (aminek egyébként semmi köze nincs a shardinghoz), vagy menedzselt megoldást keres, például az Amazon RDS vagy a Google Cloud SQL, amely megfizethetetlenül drágává válik az adatok növekedésével.

Ebben a cikkben megvizsgáljuk az egyik alapvető technikát vízszintes adatbázis méretezés: árnyékolás, és javasoljon néhány bevált gyakorlatot ehhez. Úgy érzem azonban, hogy jobb a sharding alapjaival kezdeni, mert sok ember, aki a MongoDB méretarányát keresi, lehet, hogy nem ismeri nagyon jól.

Ha azonban tisztában van a szilánkok kialakításával, nyugodtan lépjen át a következő szakaszban.

A Sharding alapjai

Lehet, hogy észrevette a „vízszintes” szó használatát az előző szakasz utolsó bekezdésében. Anélkül, hogy újabb hatalmas kitérőre indulnék, gyorsan szeretném felhozni ezt a pontot. A méretezés kétfélenek tekinthető: vagy kapsz egy nagyobb teljesítményű gépet nagyobb tárolókapacitással (függőleges), vagy több kisebb számítógépet csatlakoztat, és gyűjteményt alkot (vízszintes).

Most, mivel még a legjobb kiszolgálóknak sem több, mint 256 GB RAM-ja vagy 16 TB merevlemezük van, hamarosan egy téglafalra kerül, amikor megpróbál függőlegesen méretezni (vagy “méretarányosan növeli”, ahogy a terminológia megy). Ugyanakkor annyi önálló gépet csatlakoztathat (legalábbis elméletileg), és ezt a korlátozást könnyen megkerülheti.

Természetesen a kihívás most az, hogy összehangoljuk ezeket a gépeket.

Database Sharding

A „sharding” kifejezés általában az adatbázisokra vonatkozik, azzal az elképzeléssel, hogy egyetlen gép soha nem lehet elegendő az összes adat tárolására. Szilánkoláskor az adatbázist „feldarabolják” különálló darabból, amelyek különböző gépeken találhatók. Egy egyszerű példa lehet: Tegyük fel, hogy egy vállalkozásnak vannak gépei, amelyek akár 2 millió ügyféladat-elemet is tárolhatnak. Most az üzlet eléri ezt a pontot, és valószínűleg hamarosan meghaladja a 2,5 millió felhasználót. Tehát úgy döntenek, hogy felosztják adatbázisát két részre:

És varázslatosan a rendszer kapacitása megduplázódott!

Nos, ha csak az élet lenne ilyen egyszerű! ��

Az adatbázis-sharding kihívásai

Amint egy kicsit mélyen elgondolkodott a szilánkok kialakításán, néhány borzasztó kihívás hátrahagyta csúnya fejüket.

Nincs elsődleges kulcs

Amint kilép az egyetlen adatbázisból, az elsődleges kulcsok elveszítik a jelentését. Például, ha az elsődleges kulcsokat automatikusan növeli, és az adatok felét áthelyezi egy másik adatbázisba, akkor minden egyes elsődleges kulcshoz két különböző elem tartozik..

Nincs idegen kulcs

Mivel az adatbázisok nem támogatják az aktuális adatbázison kívüli entitásokra mutató mutatókat (nos, még ugyanazon a gépen egy másik adatbázist nem támogatunk, ezért felejtsük el egy másik gépen található adatbázist), az idegen kulcsok fogalma az jól. Hirtelen az adatbázis „hülyé” válik, és az adatok integritása a te problémád.

Furcsa adathibák

Ha egyetlen gép kialszik, a végfelhasználónak megjelenik egy “Hoppá, valami tört!” oldal, amely minden bizonnyal bosszant, de egy idő múlva az élet a pályán lesz.

Most fontolja meg, mi történik egy élesített adatbázisban. Tegyük fel, hogy korábbi példánkban az élesített adatbázis egy banki adatbázis, és az egyik ügyfél pénzt küld a másiknak. Tegyük fel azt is, hogy az első ügyféladatok az első szilánkban élnek, míg a második ügyfél adatai a második szilánkban élnek (látod, hová megyek ezzel?!). Ha a második szilánkot tartalmazó gép meghibásodik, el tudja képzelni, milyen állapotban lesz a rendszer? Hová kerül a tranzakciós pénz? Mit fog látni az első felhasználó? Mit fog látni a második felhasználó? Mit fognak látni mindkettő, amikor a szilánkok visszatérnek online?

Tranzakciókezelés

Vegyük figyelembe a tranzakciókezelés egyre kritikusabb esetét is. Most tegyük fel, hogy a rendszer 100% -ban jól működik. Két ember (A és B) fizet egy harmadiknak (C). Nagyon valószínű, hogy mindkét tranzakció egyidejűleg elolvassa a C számlájának egyenlegét, ami ezt a zavart okozza:

  • C számla egyenlege = 100 USD.
  • Az A tranzakciója kimutatja C egyenlegét: 100 USD.
  • A B tranzakciója kimutatja C egyenlegét: 100 USD.
  • Egy tranzakció 50 USD-t ad, és frissíti az egyenleget: 100 USD + 50 = 150 USD.
  • A B tranzakciója 50 USD-t ad, és frissíti az egyenleget: 100 USD + 50 = 150 USD.

Átkozott! 50 dollár csak eltűnt a vékony levegőben!

A hagyományos SQL rendszerek megmentik Önt ettől azáltal, hogy beépített tranzakciókezelést biztosítanak, de amint kilép az egyetlen gépről, pirítós.

Emlékeztetni kell arra, hogy az ilyen rendszerekkel könnyű adatkezelési problémákkal találkozni, amelyeket lehetetlen helyreállítani. A hajhúzás sem segít! ��

MongoDB Sharding

A szoftver-építészek számára a MongoDB iránti izgalom nem annyira a rugalmas sémában volt, mint a beépített sharding-támogatásban. Néhány egyszerű szabály és a csatlakoztatott gépek segítségével készen állt arra, hogy egy éles MongoDB-fürtöt gyorsan futtasson.

Az alábbi kép azt mutatja, hogy ez hogyan néz ki egy tipikus webalkalmazás-telepítésnél.

Kép jóváírása: mongodb.com

A legjobban a MongoDB szilánkosítása az, hogy még a szilánkok kiegyenlítése is automatikus. Vagyis ha öt szilánkja van, és közülük kettő majdnem üres, akkor mondhatja meg a MongoDB-nek, hogy állítsa egyensúlyba a dolgokat oly módon, hogy minden szilánk egyformán tele legyen.

Fejlesztőként vagy adminisztrátorként nem kell különösebben aggódnia, mivel a MongoDB a színfalak mögött a nehéz emelést végzi. Ugyanez vonatkozik a csomópontok részleges meghibásodására; ha a replikák helyesen vannak konfigurálva és futnak a fürtön, akkor a részleges leállások nem befolyásolják a rendszer üzemidejét.

A teljes magyarázat meglehetősen rövid lenne, ezért bezárom ezt a részt, mondván, hogy a MongoDB számos beépített eszközzel rendelkezik a shardinghoz, a replikációhoz és a helyreállításhoz, így a fejlesztőknek nagyon könnyű nagy méretű alkalmazásokat létrehozniuk. Ha átfogóbb útmutatást szeretne kapni a MongoDB szilánkoló képességeiről, akkor a hivatalos dokumentumok azok a helyek, ahol lenniük kell.

Ön is érdekli ezt teljes fejlesztői útmutató.

A MongoDB Sharding bevált gyakorlata

Míg a MongoDB „csak úgy működik” a dobozból, hogy szilánkot készítsen, ez nem azt jelenti, hogy pihenhetnénk a babérjainkon. A sharding örökre megrongálhatja vagy megszakíthatja a projektet, attól függően, hogy milyen jól vagy rosszul végezték el.

Sőt, sok apró részlettel kell számolni, amelyek hiányában nem ritka, ha a projekteket összeomlik. A szándék nem az, hogy megijesztessen, hanem hogy rámutasson a tervezés szükségességére és rendkívül óvatos legyen még apró döntésekkel is.

A Sharding Key elkerülhetetlenül irányítja a shardingot a MongoDB-ben, ezért ideális, ha ezzel felméréssel kezdjük meg a felmérést..

Magas kardinalitás

A kardinalitás a variáció mértékét jelenti. Például egy egymillió emberből álló kedvenc ország gyűjteményének alacsony a variációja (a világon csak oly sok ország van!), Míg e-mail címeik gyűjteménye (tökéletesen) nagyon bíboros. Miért számít? Tegyük fel, hogy olyan naiv sémát választott, amely az felhasználó keresztnév alapján eloszlatja az adatokat.

Itt van egy meglehetősen egyszerű elrendezés; a bejövő dokumentumot felhasználónévvel vizsgálják meg, és attól függően, hogy hol helyezkedik el az első betű az angol ábécében, a három szilánk egyikébe kerül. Hasonlóképpen, a dokumentum keresése is egyszerű: például a „Péter” részletei biztosan a második szilánkban vannak.

Minden jól hangzik, de lényeg az, hogy nem ellenőrizzük a bejövő dokumentum felhasználók nevét. Mi lenne, ha csak a B – F tartományba kerülne nevek? Ha igen, akkor lesz az úgynevezett „jumbo” darab a shard1-ben: a rendszer adatainak többsége ott zsúfolódik, és a telepítést hatékonyan egyetlen adatbázis-rendszerré alakítjuk..

A kúra?

Válasszon egy nagyszerűségű kulcsot – például a felhasználók e-mail címét, vagy akár egy összetett shard-kulcsot is megkereshet, amely több mező kombinációja..

Monotonikusan változó

A MongoDB sharding általános hibája az, hogy monoton módon növekvő (vagy automatikusan növekvő) gombokat használnak shard kulcsként.

Általában a dokumentum elsődleges kulcsát használjuk. Az ötlet itt jó szándékú, nevezetesen, mivel az új dokumentumok folyamatosan készülnek, egyenletesen esnek a rendelkezésre álló rétegek egyikébe. Sajnos egy ilyen konfiguráció klasszikus hiba. Ennek oka az, hogy ha a shard-kulcs folyamatosan növekszik, egy pont után az adatok felhalmozódnak a szilánkok nagy értékű oldalán, ami egyensúlyhiányt okoz a rendszerben.

Kép jóváírása: mongodb.com

Mint a képen látható, miután a 20-as tartományt túlléptük, az összes dokumentum gyűjteni kezd a Chunk C-ben, és ott monolitot eredményez. A megoldás a hashed sharding key séma használata, amely létrehozza a sharding key-et a megadott mezők egyikének kivágásával és ezzel a darab meghatározásához..

Kép jóváírása: Mongodb.com

A kivágott szilánkkulcs így néz ki:

{
"_id értékű" :"6b85117af532da651cc912cd"
}

. . . és létrehozható a Mongo klienshéjban a következők használatával:

db.collection.createIndex ({_id: hashedValue})

Szilánk korán

Az egyik leghasznosabb tanács a közvetlenül az árokból a korai szilánk, még akkor is, ha kicsi, két darabból álló csoportba kerül. Miután az adatok meghaladták az 500 GB-ot vagy valamit, a sharding rendetlen folyamat lesz a MongoDB-ben, és készen kell állnia a csúnya meglepetésre. Ezenkívül az egyensúlyba állítási folyamat nagyon nagy mennyiségű hálózati sávszélességet fogyaszt, ami elfojthatja a rendszert, ha nem vagy óvatos.

De nem mindenki támogatja a szilánkot. Érdekes példaként (a tanulás valójában a megjegyzésekben található) olvassa el ezt a szép Perconát blog.

A kiegyensúlyozó működtetése

Egy másik jó ötlet az, hogy figyelemmel kíséri a forgalmi mintákat, és csak a kis forgalmú időben használja az shard kiegyensúlyozó rendszert. Mint már említettem, az újbóli kiegyenlítés jelentős sávszélességet igényel, ami az egész rendszert gyors feltérképezéshez vezetheti. Ne felejtse el, hogy az kiegyensúlyozatlan szilánkok nem okozzák az azonnali pánikot. Csak hagyja, hogy a normál használat fennmaradjon, várjon alacsony forgalmi lehetőségeket, és hagyja, hogy a kiegyenlítő végezze el a többit!

Az alábbiak szerint végezheti el ezt (feltételezve, hogy 3: 00-tól 5-ig alacsony a forgalom):

használja a config
db.settings.update (
{_id: "egyensúlyozó" },
{$ set: {activeWindow: {start: "03:00", állj meg : "05:00" }}},
{upsert: true}
)

Következtetés

Bármely adatbázis szétosztása és méretezése bonyolult vállalkozás, de szerencsére a MongoDB könnyebben kezelhetővé teszi, mint a többi népszerű adatbázis..

Valóban volt egy idő, amikor a MongoDB nem volt a megfelelő választás egyetlen projekthez sem (több kritikus kérdésének és alapértelmezett viselkedésének köszönhetően), ám ezek már régóta elmúltak. Az árnyékolás, az újbóli kiegyenlítés, az automatikus tömörítés, az aggregált szintű elosztott zár és a sok ilyen szolgáltatás mellett a MongoDB mérfölddel feljebb jött, ma a szoftver-építész első választása.

Remélem, hogy ez a cikk rávilágíthatott arra, hogy mi az árnyékolás a MongoDB-ben, és mit kell a fejlesztőnek vigyáznia, ha méretarányos. Ha többet szeretne tudni, megszerezheti ezt online tanfolyam a MongoDB elsajátításához.

CÍMKÉK:

  • adatbázis

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map