Partitionare si scalare orizontala in Azure Cosmos DB

• 04/07/2021
• 9 minute de citit

• • d

  • S

  • A

  • m

  • t

In acest articol

APLICA LA: SQL API Cassandra API Gremlin API API API Azure Cosmos DB API pentru MongoDB

Azure Cosmos DB utilizeaza partitionarea pentru a scala containerele individuale dintr-o baza de date pentru a satisface nevoile de performanta ale aplicatiei dvs. In partitionare, elementele dintr-un container sunt impartite in subseturi distincte numite partitii logice . Partitiile logice sunt formate pe baza valorii unei chei de partitie care este asociata cu fiecare element dintr-un container. Toate elementele dintr-o partitie logica au aceeasi valoare a cheii de partitie.

De exemplu, un container contine articole. Fiecare articol are o valoare unica pentru proprietatea UserID. Daca UserID serveste ca cheie de partitie pentru articolele din container si exista 1.000 de valori UserID unice, 1.000 de partitii logice sunt create pentru container.

In plus fata de o cheie de partitie care determina partitia logica a elementului, fiecare articol dintr-un container are un ID de articol (unic in cadrul unei partitii logice). Combinand cheia de partitie si ID-ul articolului se creeaza indexul articolului , care identifica in mod unic elementul. Alegerea unei chei de partitie este o decizie importanta care va afecta performanta aplicatiei dvs.

Acest articol explica relatia dintre partitiile logice si fizice. De asemenea, discuta cele mai bune practici pentru partitionare si ofera o imagine detaliata a modului in care functioneaza scalarea orizontala in Azure Cosmos DB. Nu este necesar sa intelegeti aceste detalii interne pentru a selecta cheia de partitie, dar le-am acoperit, astfel incat sa aveti clar despre modul in care functioneaza Azure Cosmos DB.

Partitii logice

O partitie logica consta dintr-un set de articole care au aceeasi cheie de partitie. De exemplu, intr-un recipient care contine date despre nutritia alimentelor, toate articolele contin o proprietate foodGroup. Puteti utiliza foodGroup ca cheie de partitie pentru container. Grupurile de articole care au valori specifice pentru grupul alimentar, cum ar fi produsele din carne de vita, produsele la cuptor si mezelurile si pranzul, formeaza partitii logice distincte.

O partitie logica defineste, de asemenea, sfera tranzactiilor bazei de date. Puteti actualiza elementele dintr-o partitie logica utilizand o tranzactie cu izolarea instantaneului. Cand elementele noi sunt adaugate la un container, noi partitii logice sunt create in mod transparent de catre sistem. Nu trebuie sa va faceti griji cu privire la stergerea unei partitii logice atunci cand datele de baza sunt sterse.

Nu exista nicio limita la numarul de partitii logice din container. Fiecare partitie logica poate stoca pana la 20 GB de date. O alegere buna a cheilor de partitie are o gama larga de valori posibile. De exemplu, intr-un container in care toate articolele contin o proprietate foodGroup, datele din partitia logica Beef Products pot creste pana la 20 GB. Selectarea unei chei de partitie cu o gama larga de valori posibile asigura faptul ca containerul este capabil sa se scala.

Partitii fizice

Un container este scalat prin distribuirea de date si transfer prin partitii fizice. Intern, una sau mai multe partitii logice sunt mapate la o singura partitie fizica. De obicei, containerele mai mici au multe partitii logice, dar necesita doar o singura partitie fizica. Spre deosebire de partitiile logice, partitiile fizice sunt o implementare interna a sistemului si sunt gestionate in totalitate de Azure Cosmos DB.

Numarul de partitii fizice din containerul dvs. depinde de urmatoarele:

• Numarul de debit furnizat (fiecare partitie fizica individuala poate furniza un debit de pana la 10.000 de unitati de solicitare pe secunda). Limita de 10.000 RU / s pentru partitiile fizice implica faptul ca partitiile logice au, de asemenea, o limita de 10.000 RU / s, deoarece fiecare partitie logica este mapata doar la o singura partitie fizica.

• Stocarea totala a datelor (fiecare partitie fizica individuala poate stoca pana la 50 GB date).

Nu exista nicio limita pentru numarul total de partitii fizice din container. Pe masura ce volumul de aprovizionare sau dimensiunea datelor creste, Azure Cosmos DB va crea automat partitii fizice noi prin impartirea celor existente. Diviziunile de partitii fizice nu afecteaza disponibilitatea aplicatiei dvs. Dupa impartirea partitiei fizice, toate datele dintr-o singura partitie logica vor fi stocate in continuare pe aceeasi partitie fizica. O impartire a partitiei fizice creeaza pur si simplu o noua mapare a partitiilor logice la partitiile fizice.

Randamentul asigurat pentru un container este impartit in mod egal intre partitiile fizice. Un design de cheie de partitie care nu distribuie solicitarile in mod uniform ar putea duce la prea multe solicitari directionate catre un subset mic de partitii care devin „fierbinti”. Partitiile fierbinti duc la utilizarea ineficienta a randamentului furnizat, ceea ce ar putea duce la limitarea ratei si costuri mai mari.

Puteti vedea partitiile fizice ale containerului dvs. in sectiunea Stocare a lamei Metrici a portalului Azure:

In captura de ecran de mai sus, un container are / foodGroup ca cheie de partitie. Fiecare dintre cele trei bare din grafic reprezinta o partitie fizica. In imagine, gama de chei de partitie este aceeasi cu o partitie fizica. Partitia fizica selectata contine primele 3 partitii logice de dimensiuni cele mai semnificative: Produse din carne de vita, Produse vegetale si vegetale si Supe, Sosuri si Gravies.

Daca furnizati un debit de 18.000 de unitati de solicitare pe secunda (RU / s), atunci fiecare dintre cele trei partitii fizice poate utiliza 1/3 din debitul total furnizat. In cadrul partitiei fizice selectate, cheile partitiei logice Produse din carne de vita, produse vegetale si vegetale, precum si supe, sosuri si gravuri pot, in mod colectiv, sa utilizeze cele 6.000 RU / s ale partitiei fizice. Deoarece transferul asigurat este impartit in mod egal intre partitiile fizice ale containerului dvs., este important sa alegeti o cheie de partitie care sa distribuie in mod egal consumul de transfer, alegand cheia de partitie logica potrivita.

Gestionarea partitiilor logice

Azure Cosmos DB gestioneaza in mod transparent si automat plasarea partitiilor logice pe partitiile fizice pentru a satisface in mod eficient nevoile de scalabilitate si performanta ale containerului. Pe masura ce cerintele de transfer si stocare ale unei aplicatii cresc, Azure Cosmos DB muta partitii logice pentru a raspandi automat incarcatura intr-un numar mai mare de partitii fizice. Puteti afla mai multe despre partitiile fizice.

Azure Cosmos DB foloseste partitionarea bazata pe hash pentru a raspandi partitiile logice intre partitiile fizice. Azure Cosmos DB hasheaza valoarea cheii de partitie a unui element. Rezultatul hash determina partitia fizica. Apoi, Azure Cosmos DB aloca spatiul cheie al hashurilor cheii de partitie uniform intre partitiile fizice.

Tranzactiile (in proceduri sau declansatoare stocate) sunt permise numai impotriva elementelor dintr-o singura partitie logica.

Seturi de replici

Fiecare partitie fizica consta dintr-un set de replici, denumit si un set de replici . Fiecare set de replici gazduieste o instanta a motorului bazei de date. Un set de replici face ca datele stocate in partitia fizica sa fie durabile, extrem de disponibile si coerente. Fiecare replica care alcatuieste partitia fizica mosteneste cota de stocare a partitiei. Toate replicile unei partitii fizice accepta in mod colectiv randamentul alocat partitiei fizice. Azure Cosmos DB gestioneaza automat seturile de replici.

De obicei, containerele mai mici necesita doar o singura partitie fizica, dar vor avea in continuare cel putin 4 replici.

Urmatoarea imagine arata cum partitiile logice sunt mapate la partitiile fizice distribuite la nivel global:

Alegerea unei chei de partitie

O cheie de partitie are doua componente: calea cheii de partitie si valoarea cheii de partitie . De exemplu, luati in considerare un element {“userId”: “Andrew”, “worksFor”: “Microsoft”} daca alegeti “userId” ca cheie de partitie, urmatoarele sunt cele doua componente ale cheii de partitie:

• Calea cheii partitiei (De exemplu: “/ userId”). Calea cheii de partitie accepta caractere alfanumerice si de subliniere (_). De asemenea, puteti utiliza obiecte imbricate utilizand notatia standard a caii (/).

• Valoarea cheii partitiei (De exemplu: „Andrew”). Valoarea cheii de partitie poate fi de tip sir sau numeric.

Pentru a afla despre limitele de transfer, stocare si lungime a cheii de partitie, consultati articolul Cotele serviciului Azure Cosmos DB.

Selectarea cheii de partitie este o alegere de proiectare simpla, dar importanta in Azure Cosmos DB. Odata ce ati selectat cheia de partitie, nu este posibil sa o modificati in loc. Daca trebuie sa va schimbati cheia de partitie, ar trebui sa mutati datele intr-un container nou cu noua cheie de partitie dorita.

Pentru toate containerele, cheia de partitie ar trebui:

• Fii o proprietate care are o valoare care nu se schimba. Daca o proprietate este cheia de partitie, nu puteti actualiza valoarea proprietatii respective.

• Au o cardinalitate ridicata. Cu alte cuvinte, proprietatea ar trebui sa aiba o gama larga de valori posibile.

• Raspanditi consumul de unitati de solicitare (RU) si stocarea datelor in mod egal pe toate partitiile logice. Acest lucru asigura chiar si consumul de RU si distributia stocarii pe partitiile dvs. fizice.

Daca aveti nevoie de tranzactii ACID cu mai multe articole in Azure Cosmos DB, va trebui sa utilizati proceduri sau declansatoare stocate. Toate procedurile si declansatoarele stocate bazate pe JavaScript sunt cuprinse intr-o singura partitie logica.

Chei de partitie pentru containere greu de citit

Pentru majoritatea containerelor, criteriile de mai sus sunt tot ceea ce trebuie sa luati in considerare atunci cand alegeti o cheie de partitie. Cu toate acestea, pentru containerele mari cu greutate de citire, va recomandam sa alegeti o cheie de partitie care apare frecvent ca filtru in interogarile dvs. Interogarile pot fi directionate in mod eficient doar catre partitiile fizice relevante prin includerea cheii de partitie in predicatul filtrului.

Daca cele mai multe solicitari ale volumului dvs. de munca sunt interogari si majoritatea interogarilor dvs. au un filtru de egalitate pe aceeasi proprietate, aceasta proprietate poate fi o alegere buna pentru cheia de partitie. De exemplu, daca rulati frecvent o interogare care se filtreaza pe UserID, atunci selectarea UserID ca cheie de partitie va reduce numarul de interogari intre partitii.

Cu toate acestea, daca containerul dvs. este mic, probabil ca nu aveti suficiente partitii fizice pentru a va face griji cu privire la impactul de performanta al interogarilor cu partitii incrucisate. Majoritatea containerelor mici din Azure Cosmos DB necesita doar una sau doua partitii fizice.

Daca containerul dvs. poate ajunge la mai mult de cateva partitii fizice, atunci ar trebui sa va asigurati ca alegeti o cheie de partitie care sa minimizeze interogarile cu partitii incrucisate. Containerul dvs. va necesita mai mult de cateva partitii fizice atunci cand oricare dintre urmatoarele este adevarata:

• Containerul dvs. va avea peste 30.000 RU aprovizionate

• Containerul dvs. va stoca peste 100 GB de date

Folosind ID-ul elementului ca cheie de partitie

Daca containerul dvs. are o proprietate care are o gama larga de valori posibile, este probabil o alegere excelenta pentru cheia de partitie. Un exemplu posibil al unei astfel de proprietati este ID-ul articolului . Pentru containerele mici cu greutate redusa sau containerele cu greutate redactata de orice dimensiune, ID-ul articolului este in mod natural o alegere excelenta pentru cheia de partitie.

ID-ul elementului proprietatii sistemului exista in fiecare articol din container. Este posibil sa aveti alte proprietati care reprezinta un ID logic al articolului dvs. In multe cazuri, acestea sunt, de asemenea, alegeri cheie de partitie excelente din aceleasi motive ca ID-ul articolului .

ID – ul de produs este o alegere excelenta cheie partitie pentru urmatoarele motive:

• Exista o gama larga de valori posibile (un ID unic de articol pentru fiecare articol).
• Deoarece exista un ID unic de articol pe articol, ID-ul articolului face o treaba excelenta la echilibrarea uniforma a consumului de RU si a stocarii datelor.
• Puteti efectua cu usurinta citiri punctuale eficiente, deoarece veti cunoaste intotdeauna cheia de partitie a unui articol daca ii cunoasteti ID-ul articolului .

Unele lucruri de luat in considerare atunci cand selectati ID-ul articolului ca cheie de partitie includ:

• Daca ID-ul articolului este cheia de partitie, acesta va deveni un identificator unic pe intregul container. Nu veti putea avea articole care au un ID de articol duplicat .
• Daca aveti un container greu de citit care are o multime de partitii fizice, interogarile vor fi mai eficiente daca au un filtru de egalitate cu ID-ul articolului .
• Nu puteti rula proceduri sau declansatoare stocate pe mai multe partitii logice.

Pasii urmatori

• Aflati despre fluxul aprovizionat in Azure Cosmos DB.
• Aflati despre distributia globala in Azure Cosmos DB.
• Aflati cum sa asigurati transferul pe un container Azure Cosmos.
• Aflati cum sa asigurati transferul intr-o baza de date Azure Cosmos.