Fragmentarea bazei de date este o tehnică pentru a obține scalabilitate orizontală în sistemele la scară largă.
Aproape toate sistemele din lumea reală constau dintr-un server de baze de date care primește o mulțime de solicitări de citire și o cantitate deloc neglijabilă de solicitări de scriere. Acest lucru ar putea supraîncărca serverul și poate afecta performanța sistemului.
Pentru a atenua astfel de impacturi și pentru a îmbunătăți performanța unui sistem, există abordări precum replicarea bazei de date și fragmentarea bazei de date. În acest ghid, vom explora mai întâi tehnici de îmbunătățire a performanței sistemului, inclusiv:
- Creșterea serverului de baze de date
- Replicarea bazei de date
- Compartimentare orizontală
După discutarea acestor tehnici, vom continua să învățăm cum funcționează fragmentarea bazei de date și, de asemenea, vom analiza avantajele și limitările acestei abordări.
Sa incepem!
Cuprins
Tehnici de îmbunătățire a performanței sistemului
Să începem prin a discuta despre tehnicile de îmbunătățire a performanței sistemului atunci când există blocaje din cauza serverului de baze de date:
#1. Creșterea serverului de baze de date
Creșterea instanței serverului de baze de date poate părea o abordare simplă pentru a îmbunătăți performanța sistemului. Aceasta include creșterea puterii de procesare, adăugarea de mai multă memorie RAM și altele asemenea.
Cu toate acestea, această tehnică vine cu următoarea limitare. Nu putem avea un server cu putere infinită de stocare și procesare. Și dincolo de o anumită limită, obținem profituri descrescătoare.
#2. Replicarea bazei de date
Când supraîncărcarea instanței serverului de bază de date are loc din cauza solicitărilor primite, putem lua în considerare replicarea bazei de date.
Sub replicarea bazei de date, avem un nod master care primește de obicei cereri de scriere. Există mai multe replici citite.
Acest lucru îmbunătățește disponibilitatea și atenuează supraîncărcarea sistemului. Acum putem procesa mai multe interogări în paralel, deoarece cererile de citire pot fi direcționate către una dintre replicile de citire.
Dar aceasta introduce o altă problemă. Solicitările de scriere către nodul master pot modifica datele, iar aceste actualizări sunt propagate periodic la replicile citite.
Să presupunem că există o solicitare de citire către una dintre replicile citite în același timp în care o operație de scriere este în desfășurare la nodul principal.
Modificările din nodul master nu se vor fi propagat încă la replicile citite. În acest caz, este posibil să citim date învechite, ceea ce nu este de dorit.
#3. Compartimentare orizontală
Partiționarea orizontală este o altă tehnică de optimizare a performanței sistemului. Este posibil să avem un singur tabel mare cu miliarde de rânduri (cum ar fi un tabel cu clienți și date despre tranzacții).
Operațiile de citire dintr-un astfel de tabel de bază de date sunt mai lente. Dar folosind partiționarea orizontală, un singur tabel mare este acum împărțit în mai multe partiții (sau tabele mai mici) din care putem citi. Bazele de date relaționale, cum ar fi PostgreSQL, acceptă în mod nativ partiționarea.
Cu toate acestea, toate partițiile sunt încă într-o singură instanță de server de bază de date. Singura diferență este că acum putem citi din partiții în loc de un singur tabel mare.
Prin urmare, atunci când există o creștere a numărului de solicitări primite, este posibil ca serverul să nu poată suporta cererea crescută.
Cum funcționează partajarea bazei de date?
Acum că am discutat despre abordările de îmbunătățire a performanței sistemului și limitările acestora, să înțelegem cum funcționează fragmentarea bazei de date.
În sharding, împărțim o singură bază de date mare în mai multe baze de date mai mici, fiecare rulând pe o instanță de server de baze de date. Fiecare astfel de bază de date mai mică se numește shard. Și fiecare fragment conține un subset unic de date.
Dar cum împărțim baza de date în fragmente? Și cum determinăm care dintre rânduri intră în care dintre cioburi?
🔑 Introduceți cheia de fragmentare.
Înțelegerea cheii Sharding
Să înțelegem rolul cheii de fragmentare.
Cheia de sharding, care este de obicei o coloană (sau o combinație de coloane) în tabelul bazei de date, ar trebui aleasă astfel încât distribuția datelor să fie egală pe mai multe fragmente. Pentru că nu vrem ca o anumită cioburi să fie mult mai mare decât celelalte cioburi.
Într-o bază de date care stochează date despre clienți și tranzacții, client_ID este un bun candidat pentru cheia de fragmentare.
Odată ce ne-am hotărât asupra cheii de fragmentare, putem veni cu o funcție de hashing care determină care dintre rânduri intră în care dintre fragmente.
În acest exemplu, să presupunem că trebuie să împărțim baza de date în cinci shard-uri (shard #0 la shard #4) folosind client_ID ca cheie de sharding. În acest caz, o funcție simplă de hashing este customer_ID % 5.
Toate valorile customer_ID care lasă un rest de zero atunci când sunt împărțite la 5 vor fi mapate la fragmentul #0. Și valorile customer_ID care lasă resturile de la 1 la 4 se vor mapa la fragmentul #1 până la fragmentul #4, respectiv.
După ce sharding-ul bazei de date este implementat în acest fel, este important să existe un strat de rutare care direcționează cererile primite către shard-ul corect al bazei de date.
Avantajele partajării bazei de date
Iată câteva dintre avantajele sharding-ului bazei de date:
#1. Scalabilitate ridicată
Este întotdeauna posibil să fragmentați o bază de date mai mare în mai multe fragmente mai mici. Deci, fragmentarea bazei de date ne permite să ne extindem pe orizontală.
#2. Valabilitate ridicată
Când există o singură instanță de server de bază de date care se ocupă de toate solicitările primite, avem un singur punct de eșec. Dacă serverul de baze de date este oprit, întreaga aplicație este oprită.
Cu fragmentarea bazei de date, probabilitatea ca toate fragmentele bazei de date să fie în jos la un moment dat este relativ scăzută. Prin urmare, dacă un anumit fragment este în jos, nu vom putea procesa solicitările de citire către acel fragment. Dar celelalte fragmente pot procesa în continuare cererile primite. Acest lucru are ca rezultat o disponibilitate ridicată și o toleranță crescută la erori.
Limitări ale partajării bazei de date
Acum să trecem peste câteva dintre limitările sharding-ului bazei de date:
#1. Complexitate
Deși sharding-ul are avantaje în ceea ce privește scalabilitatea și toleranța la erori, introduce complexitate în sistem.
De la maparea înregistrărilor la partiții la implementarea stratului de rutare până la rutarea interogărilor către fragmentele respective, există o complexitate considerabilă implicată în bazele de date sharding.
#2. Recondiţionarea
O altă limitare a sharding-ului este necesitatea re-sharding-ului.
Deși folosim funcția de hashing pentru a obține o distribuție uniformă a înregistrărilor de date, este posibil ca una dintre fragmente să fie mult mai mare decât celelalte fragmente și să se epuizeze mai devreme. În acest caz, trebuie să ținem cont de reîncărcare (sau remaniere), iar asta vine cu o suprasolicitare substanțială.
#3. Rularea de interogări complexe
Când trebuie să rulați interogări pentru analiză care implică îmbinări, trebuie să utilizați înregistrări din mai multe fragmente, spre deosebire de o singură bază de date. Deci, aceasta poate fi o provocare atunci când trebuie să rulați prea multe interogări analitice. Puteți ocoli acest lucru prin denormalizarea bazelor de date, dar necesită totuși ceva efort!
Concluzie
Să încheiem discuția cu un rezumat a ceea ce am învățat.
Extinderea hardware-ului nu este întotdeauna optimă. Prin urmare, nu este recomandată creșterea instanței serverului. De asemenea, am analizat tehnici precum replicarea bazei de date și partiționarea orizontală și limitările acestora.
Apoi, am învățat cum funcționează fragmentarea bazei de date prin împărțirea unei baze de date mari în fragmente mai mici și ușor de gestionat. Am discutat despre cum ar trebui aleasă cu atenție cheia de sharding pentru a obține partiții egale și necesitatea unui strat de rutare pentru a direcționa cererile primite către fragmentul corect de bază de date.
Sharding-ul bazei de date are avantaje precum disponibilitatea ridicată și scalabilitatea. Unele dintre dezavantaje includ complexitatea instalării sharding-ului și re-sharding-ului atunci când una sau mai multe fragmente se epuizează.
Deci, puteți lua în considerare sharding-ul atunci când credeți că avantajele depășesc complexitatea introdusă de sharding. Apoi, consultați compararea diferitelor baze de date relaționale AWS.