Ce este Sharing MongoDB și cele mai bune practici?

Cum puteți scala MongoDB? Care sunt cele mai bune practici de ascuțire?


Deși schema flexibilă este modul în care majoritatea oamenilor se familiarizează cu MongoDB, este, de asemenea, una dintre cele mai bune baze de date (poate chiar cele mai bune atunci când vine vorba de aplicații de zi cu zi) pentru gestionarea seturilor de date foarte mari. În timp ce justificarea acestui argument necesită un articol întreg în sine (sper că pot găsi timp pentru el într-o zi!), Ideea generală este că soluțiile bazate pe SQL nu acceptă ascuțirea și construirea lui pe sucul tău..

Cel mai bun lucru pe care îl poți spera este să creezi un cluster (care nu are nicio legătură cu ascuțirea în mod fundamental, apropo) sau să te duci pentru o soluție gestionată precum RDS-ul Amazon sau Google SQL Cloud, care devin costisitoare prohibitiv pe măsură ce datele tale cresc.

În acest articol, vom analiza una dintre tehnicile esențiale pentru scalare orizontală a bazelor de date: ascuțire, pentru MongoDB și recomandăm unele bune practici pentru aceleași. Cu toate acestea, consider că este mai bine să începeți cu elementele de bază ale ascuțirii, deoarece multe persoane care încearcă să facă o scară MongoDB pot să nu fie foarte familiari.

Dacă sunteți conștienți de ascuțire, totuși, nu ezitați să treceți peste secțiunea următoare.

Bazele de partajare

Este posibil să fi observat utilizarea cuvântului „orizontal” în ultimul paragraf din secțiunea anterioară. Fără să mă lansez într-un alt ocol masiv, vreau să aduc repede acest punct. Scalarea consideră că este de două tipuri: fie primiți o mașină mai puternică cu o capacitate de stocare mai mare (vertical) sau conectați mai multe computere mai mici și formați o colecție (orizontală).

Acum, având în vedere faptul că chiar și cele mai bune servere în prezent nu au mai mult de 256 GB RAM sau 16 TB de hard disk, ați lovit curând un zid de cărămidă când încercați să faceți o scară verticală (sau „scalați”, așa cum merge terminologia). Cu toate acestea, puteți conecta la fel de multe mașini unice (cel puțin teoretic) și puteți evita această limitare cu ușurință.

Desigur, provocarea este acum să coordonăm între toate aceste mașini.

Partajarea bazelor de date

Termenul „ascuțire” se aplică, în general, bazelor de date, ideea fiind că o singură mașină nu poate fi niciodată suficientă pentru a deține toate datele. Când se face ascuțirea, baza de date este „împărțită” în bucăți separate care se află pe diferite mașini. Un exemplu simplu ar putea fi: să presupunem că o afacere are mașini care pot stoca până la 2 milioane de articole de date despre clienți. Acum, afacerea atinge acel punct de pauză și va depăși probabil 2,5 milioane de utilizatori în curând. Deci, ei decid să-și împartă baza de date în două:

Și magic, capacitatea sistemului este acum dublată!

Ei bine, dacă numai viața a fost atât de simplă! ��

Provocări în accentuarea bazelor de date

De îndată ce te-ai gândit un pic profund la ascuțire, unele provocări nefaste au pus capul urât.

Fără chei primare

De îndată ce ieșiți dintr-o singură bază de date, tastele primare își pierd sensul. De exemplu, dacă cheile dvs. principale sunt setate pe auto-creștere și mutați jumătate din date într-o altă bază de date, veți avea acum două elemente diferite pentru fiecare cheie primară.

Fără chei străine

Deoarece nu există suport în bazele de date care să indice entitățile din afara bazei de date actuale (bine, chiar și o bază de date diferită pe aceeași mașină nu este acceptată, deci uitați de o bază de date de pe o mașină diferită), conceptul de chei străine este recomandat ca bine. Dintr-o dată, baza de date devine „mută”, iar integritatea datelor este problema ta.

Erori de date ciudate

Dacă iese o singură mașină, utilizatorului final i se poate afișa „Oops, ceva s-a rupt!” pagină, care, fără îndoială, se va enerva, dar viața va fi pe parcurs după ceva timp.

Acum luați în considerare ce se întâmplă într-o bază de date fragmentată. Să presupunem că baza de date fragmentată din exemplul nostru anterior este o bază de date bancară și un client trimite bani către altul. Să presupunem, de asemenea, că primele date ale clienților trăiesc în primul fragment, în timp ce datele celui de-al doilea client trăiesc în al doilea fragment (vedeți unde merg cu asta ?!). Dacă mașina care conține al doilea fragment eșuează, vă puteți imagina în ce stare se va afla sistemul? Unde vor merge banii tranzacției? Ce va vedea primul utilizator? Ce va vedea al doilea utilizator? Ce vor vedea amândoi când fragmentele vor fi din nou online?

Managementul tranzacțiilor

Să luăm în considerare și cazul mereu critic al gestionării tranzacțiilor. De data aceasta, să presupunem că sistemul funcționează 100%. Acum, două persoane (A și B) efectuează o plată către o a treia (C). Este foarte probabil ca ambele tranzacții să citească soldul contului C simultan, provocând această confuzie:

  • Soldul contului C = 100 USD.
  • Tranzacția unei tranzacții indică soldul lui C: 100 USD.
  • Tranzacția lui B arată valoarea soldului lui C: 100 USD.
  • Tranzacția unei adaugă 50 $ și soldul actualizărilor: 100 $ + 50 = 150 $.
  • Tranzacția lui B adaugă 50 USD și soldul actualizărilor: 100 $ + 50 = 150 $.

La naiba! 50 de dolari tocmai au dispărut în aer subțire!

Sistemele tradiționale SQL vă scutesc de acest lucru prin furnizarea de gestiune integrată a tranzacțiilor, dar imediat ce ieșiți dintr-o singură mașină, vă veți prinde.

Este evident că, cu astfel de sisteme, este ușor să vă confruntați cu probleme de corupție a datelor din care este imposibil de recuperat. Tragerea părului nu vă va fi de folos nici! ��

MongoDB Sharding

Pentru arhitecții software, entuziasmul pentru MongoDB nu a fost atât în ​​schema sa flexibilă, cât și în suportul de ascuțire integrat. Cu doar câteva reguli și mașini simple conectate, erai gata să rulezi un cluster MongoDB fragmentat în cel mai scurt timp.

Imaginea de mai jos arată cum arată acest aspect într-o implementare tipică a aplicației web.

Credit imagine: mongodb.com

Partea cea mai bună despre ascuțirea MongoDB este că chiar echilibrarea cioburilor este automată. Asta dacă aveți cinci cioburi și două dintre ele sunt aproape goale, puteți spune MongoDB să reechilibreze lucrurile într-un mod în care toate fragmentele să fie la fel de pline.

În calitate de dezvoltator sau administrator, nu trebuie să vă faceți griji, întrucât MongoDB din culise face cea mai mare parte din ridicarea grea. Același lucru este valabil și pentru eșecul parțial al nodurilor; dacă aveți seturi de replici configurate și funcționate corect pe cluster, întreruperile parțiale nu vor afecta timpul de funcționare al sistemului.

Întreaga explicație ar fi destul de sumară, așa că voi închide această secțiune spunând că MongoDB are mai multe instrumente încorporate pentru ascuțire, replicare și recuperare, ceea ce face foarte ușor pentru dezvoltatori să construiască aplicații la scară largă. Dacă doriți un ghid mai cuprinzător cu privire la capacitățile de ascuțire ale MongoDB, documente oficiale sunt locul de a fi.

Ați putea fi, de asemenea, interesat de acest lucru Ghidul complet al dezvoltatorului.

Cele mai bune practici de partajare MongoDB

În timp ce MongoDB „funcționează” din cutie pentru ascuțire, nu înseamnă că ne putem baza pe lauri. Împărțirea poate face sau rupe proiectul dvs. pentru totdeauna, în funcție de cât de bine sau de slab a fost realizat.

Mai mult decât atât, există multe mici detalii de care trebuie să dați cont, în caz contrar, nu este neobișnuit să vedem că proiectele se prăbușesc. Intenția nu este să te sperii, ci să evidențiezi nevoia de planificare și să fii extrem de atent chiar și cu mici decizii.

Cheia de partajare controlează inevitabil ascuțirea în MongoDB, așa că este ideal să începem sondajul cu asta.

Cardinalitate ridicată

Cardinalitate înseamnă cantitatea de variație. De exemplu, o colecție dintr-o țară preferată de 1 milion de oameni va avea variații scăzute (există doar atât de multe țări în lume!), În timp ce o colecție a adreselor lor de e-mail va avea (perfect) o mare cardinalitate. De ce conteaza? Să presupunem că alegeți o schemă naivă care cotește datele pe baza prenumelui utilizatorului.

Aici avem un aranjament destul de simplu; documentul de intrare este scanat pentru numele de utilizator și, în funcție de locul în care se află prima literă din alfabetul englez, acesta aterizează într-unul dintre cele trei fragmente. În mod similar, căutarea unui document este ușoară: detaliile pentru „Peter”, de exemplu, vor fi în al doilea fragment sigur..

Totul sună bine, dar ideea este că nu controlăm numele utilizatorilor de documente primite. Ce se întâmplă dacă primim doar nume în intervalul B – F de cele mai multe ori? Dacă da, vom avea ceea ce se numește un „jumbo” în shard1: majoritatea datelor din sistem vor fi aglomerate acolo, transformând efectiv configurarea într-un singur sistem de baze de date.

Leacul?

Alegeți o cheie cu cardinalitate ridicată – de exemplu, adresa de e-mail a utilizatorilor sau puteți chiar să căutați o cheie de fragment compus, care este o combinație de mai multe câmpuri.

Schimbarea monotonică

O greșeală obișnuită în ascuțirea MongoDB este de a utiliza tastele care crește monoton (sau de auto-creștere, dacă veți dori) ca cheie shard.

În general, se folosește cheia principală a documentului. Ideea de aici are o bună semnificație, și anume, pe măsură ce noile documente continuă să fie create, acestea vor intra în mod uniform într-unul din fragmentele disponibile. Din păcate, o astfel de configurație este o greșeală clasică. Acest lucru se întâmplă pentru că, dacă cheia fragmentului este mereu în creștere, după o dată datele vor începe să se acumuleze în partea de mare valoare a fragmentelor, provocând un dezechilibru în sistem.

Credit imagine: mongodb.com

După cum puteți vedea în imagine, după ce am trecut de intervalul de 20, toate documentele încep să se colecteze în Chunk C, provocând un monolit acolo. Soluția este să mergi la schema de chei de ascuțire a hașei, care creează o cheie de ascuțire prin hashing unul dintre câmpurile furnizate și folosind asta pentru a determina bucata.

Credit imagine: Mongodb.com

O cheie de șaibă arată așa:

{
"_id" :"6b85117af532da651cc912cd"
}

. . . și poate fi creat în shell-ul clientului Mongo folosind:

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

Shard Early

Unul dintre cele mai utile sfaturi directe din tranșee este să zdrobiți mai devreme, chiar dacă terminați cu un cluster mic, cu două bucăți. Odată ce datele au trecut de 500 GB sau ceva similar, ascuțirea devine un proces dezordonat în MongoDB și ar trebui să fii pregătit pentru surprize urâte. În plus, procesul de reechilibrare consumă cantități foarte mari de lățime de bandă a rețelei, ceea ce poate sufoca sistemul dacă nu sunteți atent.

Cu toate acestea, nu toată lumea este pro-ascuțit. Ca un exemplu interesant (învățarea este într-adevăr în comentarii), vedeți acest frumos Percona blogul.

Rularea balansierului

O altă idee bună este să vă monitorizați modelele de trafic și să rulați echilibratorul doar la orele de trafic redus. După cum am menționat deja, reechilibrarea necesită o lățime de bandă considerabilă, ceea ce ar putea aduce rapid întregul sistem la o rampă. Amintiți-vă, cioburile dezechilibrate nu sunt un motiv de panică imediată. Lăsați doar utilizarea normală, așteptați oportunități de trafic redus și lăsați echilibratorul să facă restul!

Iată cum puteți realiza acest lucru (presupunând că aveți un trafic redus între orele 3 și 5)

utilizați config
db.settings.update (
{_id: "echilibrist" },
{$ set: {activeWindow: {start: "03:00", Stop : "05:00" }}},
{upsert: true}
)

Concluzie

Partajarea și scalarea oricărei baze de date este o întreprindere complicată, dar, din fericire, MongoDB o face mai ușor de gestionat decât alte baze de date populare de acolo..

Într-adevăr, a existat o perioadă în care MongoDB nu a fost alegerea potrivită pentru niciun proiect (datorită mai multor probleme critice și comportamentelor implicite), dar acestea au dispărut de mult. Alături de ascuțire, reechilibrare, compresie automată, blocare distribuită la nivel agregat și multe astfel de caracteristici, MongoDB a venit cu câteva mile, este astăzi prima alegere a arhitectului software.

Sper că acest articol a reușit să arunce o lumină asupra ceea ce este ascuțirea în MongoDB și la ce trebuie să aibă grijă dezvoltatorul atunci când merge la scară. Pentru a afla mai multe, este posibil să obțineți acest lucru curs online pentru a stăpâni MongoDB.

ETICHETE:

  • Bază de date

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