Čo je to MongoDB Sharding a osvedčené postupy?

Ako škálovať MongoDB? Aké sú najlepšie postupy v oblasti ochrany?


Aj keď flexibilná schéma je spôsob, akým sa väčšina ľudí oboznámi s MongoDB, je to tiež jedna z najlepších databáz (možno dokonca najlepšia, pokiaľ ide o každodenné aplikácie) na spracovanie veľmi, veľmi veľkých súborov údajov. Aj keď odôvodnenie tohto argumentu si vyžaduje celý článok ako taký (dúfam, že jedného dňa dokážem nájsť čas!), Všeobecnou myšlienkou je, že riešenia založené na SQL nepodporujú sharding a tvrdo ho stavajú na vašich saniach..

To najlepšie, v čo môžete dúfať, je vytvoriť klaster (ktorý nemá vôbec nič spoločné s ostreľovaním) alebo ísť na spravované riešenie, ako je Amazon RDS alebo Google Cloud SQL, ktoré sa s rastúcimi údajmi stanú neúmerne drahými..

V tomto článku sa pozrieme na jednu zo základných techník horizontálne škálovanie databázy: orezávanie, pre MongoDB a odporučiť pre ne niekoľko osvedčených postupov. Domnievam sa však, že je lepšie začať so základmi orezávania, pretože mnohí ľudia, ktorí sa snažia škálovať MongoDB, s tým nemusia byť oboznámení..

Ak však viete o ostreľovaní, môžete prejsť nasledujúcou časťou.

Základy ostreľovania

Možno ste si všimli použitie slova „horizontálne“ v poslednom odseku z predchádzajúcej časti. Bez toho, aby som sa pustil do ďalšej rozsiahlej obchádzky, chcem tento bod uviesť rýchlo. Zmena mierky sa považuje za dva typy: buď získate výkonnejší stroj s väčšou úložnou kapacitou (vertikálne) alebo prepojíte niekoľko menších počítačov a vytvoríte zbierku (horizontálne).

Vzhľadom na to, že ani tie najlepšie servery v súčasnosti nemajú viac ako 256 GB RAM alebo 16 TB pevného disku, narazíte čo najskôr na tehlovú stenu, keď sa snažíte zvislo zväčšiť (alebo „zväčšiť“, ako terminológia pokračuje)). Môžete však spojiť toľko samostatných strojov spolu (aspoň teoreticky) a toto obmedzenie ľahko obísť.

Úlohou samozrejme je teraz koordinovať všetky tieto stroje.

Sharding databázy

Pojem „šrafovanie“ sa všeobecne vzťahuje na databázy, pričom sa vychádza z myšlienky, že jeden stroj nikdy nemôže stačiť na uloženie všetkých údajov. Pri strieľaní je databáza „rozdelená“ na samostatné kúsky, ktoré sa nachádzajú na rôznych strojoch. Jednoduchým príkladom môže byť: predpokladajme, že firma má stroje, ktoré môžu uložiť až 2 milióny údajov o zákazníkoch. Teraz spoločnosť dosahuje tento bod zlomu a pravdepodobne čoskoro prekročí 2,5 milióna používateľov. Preto sa rozhodnú rozdeliť svoju databázu na dve časti:

A magicky je kapacita systému teraz zdvojnásobená!

Keby bol život taký jednoduchý! ��

Výzvy v databáze

Hneď, ako si trochu rozmýšľal o ostreľovaní, ich škaredá hlava stihla nejaký nebezpečný problém.

Žiadne primárne kľúče

Len čo vystúpite z jednej databázy, primárne kľúče stratia svoj význam. Napríklad, ak sú vaše primárne kľúče nastavené na automatické zvyšovanie a polovicu údajov presuniete do inej databázy, pre každý primárny kľúč budete mať teraz dve rôzne dátové položky..

Žiadne cudzie kľúče

Pretože v databázach neexistuje podpora, ktorá by ukazovala na subjekty mimo aktuálnej databázy (dobre, dokonca ani iná databáza na tom istom počítači nie je podporovaná, takže zabudnite na databázu na inom počítači), koncept cudzích kľúčov platí pre prehadzovanie, pretože dobre. Zrazu sa databáza stane „nemou“ a integrita údajov je váš problém.

Podivné dátové chyby

Ak jeden stroj zhasne, koncovému užívateľovi sa môže zobraziť „Oops, niečo sa pokazilo!“ stránku, ktorá bude bezpochyby obťažovať, ale život bude po určitej dobe na ceste.

Teraz zvážte, čo sa deje v databáze s chránenými údajmi. Predpokladajme, že v našej predchádzajúcej ukážke je zastrešená databáza bankovou databázou a jeden zákazník posiela peniaze inému. Predpokladajme tiež, že prvé údaje o zákazníkoch žijú v prvom zlomku, zatiaľ čo údaje o druhých zákazníkoch žijú v druhom zlomku (uvidíte, kam s tým idem ?!). Ak dôjde k zlyhaniu zariadenia obsahujúceho druhú črepinu, viete si predstaviť, v akom stave bude systém? Kam pôjdu peniaze na transakciu? Čo uvidí prvý užívateľ? Čo uvidí druhý používateľ? Čo uvidia, keď budú črepy späť online?

Riadenie transakcií

Zoberme si tiež niekedy kritický prípad správy transakcií. Tentoraz predpokladajme, že systém pracuje na 100% v poriadku. Teraz dvaja ľudia (A a B) uskutočnia platbu tretí (C). Je veľmi pravdepodobné, že obe transakcie odčítajú zostatok účtu C súčasne a spôsobia tento zmätok:

  • Zostatok na účte C = 100 USD.
  • Transakcia A číta zostatok C: 100 USD.
  • Transakcia B číta zostatok C: 100 USD.
  • Transakcia spoločnosti A pridáva 50 dolárov a aktualizuje zostatok: 100 EUR + 50 = 150 USD.
  • Transakcia spoločnosti B pridáva 50 dolárov a aktualizuje zostatok: 100 EUR + 50 = 150 USD.

Sakra! 50 dolárov práve zmizlo do vzduchu!

Tradičné systémy SQL vás z toho ušetria tým, že poskytujú vstavanú správu transakcií, ale akonáhle vystúpite z jedného počítača, opekáte sa.

S takýmito systémami je ľahké sa stretnúť s problémami s poškodením údajov, z ktorých nie je možné obnoviť sa. Vyťahovanie vlasov vám tiež nepomôže! ��

MongoDB Sharding

Pokiaľ ide o softvérových architektov, vzrušenie z MongoDB nebolo ani tak v jeho flexibilnej schéme, ako v vstavanej podpore šnorchlovania. Po pripojení iba niekoľkých jednoduchých pravidiel a strojov ste boli pripravení spustiť strážený klaster MongoDB v žiadnom momente.

Obrázok nižšie ukazuje, ako to vyzerá v typickom nasadení webovej aplikácie.

Obrazový kredit: mongodb.com

Najlepšie na opláštení MongoDB je to, že rovnomerné vyváženie črepov je automatické. To znamená, že ak máte päť úlomkov a dva z nich sú takmer prázdne, môžete MongoDB povedať, aby veci vyvážili tak, aby všetky úlomky boli rovnako plné..

Ako vývojár alebo správca sa nemusíte veľa obávať, pretože MongoDB v zákulisí väčšiny ťažkých zdvíhaní. To isté platí pre čiastočné zlyhanie uzlov; Ak máte sady replík správne nakonfigurované a spustené vo vašom klastri, čiastočné výpadky neovplyvnia dostupnosť systému.

Celé vysvetlenie by bolo dosť stručné, takže túto časť uzavriem tvrdením, že MongoDB má niekoľko vstavaných nástrojov na ochranu, replikáciu a obnovu, čo vývojárom veľmi uľahčuje vytváranie rozsiahlych aplikácií. Ak chcete komplexnejšiu príručku o možnostiach ochrany v MongoDB, oficiálne dokumenty sú miestom, kde sa majú nachádzať.

Môže vás to tiež zaujímať kompletná príručka pre vývojárov.

Najlepšie postupy MongolDB Sharding

Zatiaľ čo MongoDB „jednoducho funguje“ mimo poľa na orezávanie, neznamená to, že by sme mohli odpočívať na vavrínoch. Sharding môže váš projekt donekonečna zlomiť alebo zlomiť, v závislosti od toho, ako dobre alebo zle sa to stalo.

Okrem toho existuje veľa malých detailov, ktoré by sa dali zohľadniť, v opačnom prípade nie je nezvyčajné vidieť kolaps projektov. Zámerom nie je vystrašiť vás, ale zdôrazniť potrebu plánovania a byť mimoriadne opatrní aj pri malých rozhodnutiach.

Kľúč Sharding nevyhnutne riadi ostreľovanie v MongoDB, takže je ideálne, aby sme začali s týmto prieskumom..

Vysoká mohutnosť

Kardinalita znamená množstvo variácií. Napríklad zbierka obľúbenej krajiny s 1 miliónom ľudí bude mať nízke variácie (na svete je toľko krajín!), Zatiaľ čo zbierka ich e-mailových adries bude mať (dokonale) vysokú kardinálnosť. Prečo na tom záleží? Predpokladajme, že vyberiete naivnú schému, ktorá zhromažďuje údaje na základe krstného mena používateľa.

Tu máme pomerne jednoduché usporiadanie; v prichádzajúcom dokumente sa naskenuje užívateľské meno a podľa toho, kde prvé písmeno leží v anglickej abecede, pristane do jedného z troch úlomkov. Podobne je vyhľadávanie dokumentu jednoduché: podrobnosti napríklad o „Peterovi“ budú určite v druhom črepe.

Všetko znie dobre, ale ide o to, že nekontrolujeme mená používateľov prichádzajúcich dokumentov. Čo ak dostaneme mená v rozmedzí B až F väčšinou? Ak je to tak, budeme mať v shardi tzv. „Jumbo“ chunk1: väčšina systémových údajov sa tam preplní, čím sa nastavenie zmení na jediný databázový systém..

Liek?

Vyberte si kľúč s vysokou kardinálnosťou – napríklad e-mailovú adresu používateľov, alebo si môžete dokonca zvoliť zložený kľúč zo střepov, ktorý je kombináciou viacerých polí..

Monotónne sa mení

Bežnou chybou pri orezávaní MongoDB je použitie klávesov orezávania monotónne zväčšujúcich (alebo automaticky zvyšujúcich, ak chcete) klávesov..

Všeobecne sa používa primárny kľúč dokumentu. Myšlienka je tu zmysluplná, konkrétne, keď sa nové dokumenty vytvárajú, spadajú rovnomerne do jedného z dostupných úlomkov. Bohužiaľ, takáto konfigurácia je klasická chyba. Je to tak preto, že ak sa črepový kľúč neustále zvyšuje, po dátovom bode sa začnú hromadiť údaje na vysokej hodnote črepov, čo spôsobuje nerovnováhu v systéme..

Obrazový kredit: mongodb.com

Ako vidíte na obrázku, akonáhle sa dostaneme okolo 20 rozsahov, všetky dokumenty sa začnú zhromažďovať v časti C a spôsobujú tam monolit. Riešením je ísť po schéme hashed sharding key, ktorá vytvára sharding key hashovaním jedného z poskytnutých polí a jeho pomocou na určenie kusa..

Obrázkový kredit: Mongodb.com

Kľúč hashed Shard vyzerá takto:

{
"_id" :"6b85117af532da651cc912cd"
}

. . . a môžete ho vytvoriť v klientskom prostredí Mongo pomocou:

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

Shard Early

Jednou z najužitočnejších rád priamo zo zákopov je ostrihať sa skoro, aj keď skončíte s malým dvojdielnym zhlukom. Akonáhle údaje prekročia 500 GB alebo niečo podobné, stane sa z opláštenia v MongoDB chaotický proces a vy by ste mali byť pripravení na nepríjemné prekvapenia. Proces vyvažovania okrem toho spotrebuje veľmi veľké množstvo šírky pásma siete, ktoré môžu systém tlmiť, ak si nebudete dávať pozor..

Nie všetci sa však chránia. Ako zaujímavý príklad (učenie je naozaj v komentároch), pozri tento pekný Percona blog.

Spustenie balanceru

Ďalším dobrým nápadom je monitorovať vaše dopravné vzorce a spúšťať vyvažovaciu frézu iba v časoch s nízkou prevádzkou. Ako som už spomenul, samotné vyvažovanie vyžaduje značnú šírku pásma, čo by mohlo rýchlo priniesť celý systém k prehľadávaniu. Pamätajte, že nevyvážené črepy nie sú príčinou okamžitej paniky. Nechajte bežné použitie pretrvávať, počkajte na príležitosti s nízkou návštevnosťou a nechajte balancer urobiť zvyšok!

Postupujte takto (za predpokladu nízkej premávky od 3:00 do 5:00):

použitie konfigurácie
db.settings.update (
{_id: "vyvažovacie" },
{$ set: {activeWindow: {start: "03:00", zastávka: "05:00" }}},
{upsert: true}
)

záver

Sharding a škálovanie akejkoľvek databázy je zložitý podnik, ale našťastie MongoDB ho spravuje lepšie ako iné populárne databázy..

V skutočnosti bol čas, keď MongoDB nebol správnou voľbou pre žiadny projekt (vďaka niekoľkým kritickým problémom a predvolenému správaniu), ale tie sú už dávno preč. Spolu s ostreľovaním, opätovným vyvážením, automatickou kompresiou, distribuovaným zámkom na úrovni agregátov a mnohými takýmito funkciami, MongoDB je na míle náskoku, dnes je prvou voľbou softvérového architekta.

Dúfam, že tento článok dokázal vrhnúť nejaké svetlo na to, čo je to opláštenie v MongoDB a na čo sa musí vývojár starať, keď ide o mierku. Ak sa chcete dozvedieť viac, môžete to získať online kurz na zvládnutie MongoDB.

Tagy:

  • databázy

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