Înțelegerea bazei de date Sharding DigitalOcean
Publicat pe 7 februarie 2019
Introducere
Orice aplicație sau site web care vede o creștere semnificativă va trebui, în cele din urmă, să se extindă pentru a permite creșterea traficului. Pentru aplicațiile și site-urile bazate pe date, este esențial ca scalarea să se realizeze într-un mod care să asigure securitatea și integritatea datelor lor. Poate fi dificil să se prezică cât de popular va deveni un site web sau o aplicație sau cât va menține popularitatea respectivă, motiv pentru care unele organizații aleg o arhitectură de baze de date care le permite să își scaleze dinamic bazele de date.
În acest articol conceptual, vom discuta despre o astfel de arhitectură de baze de date: bazele de date fragmentate. Fragmentarea a primit multă atenție în ultimii ani, dar mulți nu au o înțelegere clară a ceea ce este sau a scenariilor în care ar putea avea sens să împărțim o bază de date. Vom trece peste ce este sharding-ul, unele dintre principalele sale avantaje și dezavantaje, precum și câteva metode comune de sharding.
Ce este Sharding?
Fragmentarea este un model de arhitectură a bazei de date legat de partiționarea orizontală - practica separării rândurilor unui tabel în mai multe tabele diferite, cunoscute sub numele de partiții. Fiecare partiție are aceeași schemă și coloane, dar și rânduri complet diferite. De asemenea, datele deținute în fiecare sunt unice și independente de datele deținute în alte partiții.
Poate fi util să ne gândim la partiționarea orizontală în ceea ce privește modul în care se referă la partiționarea verticală. Într-un tabel partiționat vertical, coloane întregi sunt separate și plasate în tabele noi, distincte. Datele păstrate într-o partiție verticală sunt independente de datele din toate celelalte și fiecare conține atât rânduri, cât și coloane distincte. Următoarea diagramă ilustrează modul în care un tabel ar putea fi partiționat atât pe orizontală, cât și pe verticală:
Fragmentarea implică divizarea datelor în două sau mai multe bucăți mai mici, numite cioburi logice. Cioburile logice sunt apoi distribuite pe noduri de baze de date separate, denumite cioburi fizice, care pot conține mai multe cioburi logice. În ciuda acestui fapt, datele deținute în toate fragmentele reprezintă în mod colectiv un întreg set de date logice.
Fragmentele bazei de date exemplifică o arhitectură fără nimic partajat. Aceasta înseamnă că cioburile sunt autonome; nu partajează niciuna dintre aceleași date sau resurse de calcul. În unele cazuri, totuși, poate avea sens să replicăm anumite tabele în fiecare fragment pentru a servi drept tabele de referință. De exemplu, să presupunem că există o bază de date pentru o aplicație care depinde de ratele de conversie fixe pentru măsurarea greutății. Replicând un tabel care conține datele necesare despre rata de conversie în fiecare fragment, ar contribui la asigurarea faptului că toate datele necesare pentru interogări sunt păstrate în fiecare fragment.
Adesea, sharding-ul este implementat la nivelul aplicației, ceea ce înseamnă că aplicația include un cod care definește ce shard să transmită citește și scrie. Cu toate acestea, unele sisteme de gestionare a bazelor de date au capabilități de partajare încorporate, permițându-vă să implementați partajarea direct la nivelul bazei de date.
Având în vedere această prezentare generală a fragmentării, să trecem în revistă unele dintre aspectele pozitive și negative asociate acestei arhitecturi de baze de date.
Avantajele fragmentării
Principalul apel al partajării unei baze de date este că aceasta poate ajuta la facilitarea redimensionării orizontale, cunoscută și sub denumirea de redimensionare. Scalarea orizontală este practica adăugării mai multor mașini într-o stivă existentă pentru a răspândi sarcina și a permite mai mult trafic și procesare mai rapidă. Acest lucru este adesea contrastat cu scalarea verticală, altfel cunoscută sub numele de scaling up, care implică actualizarea hardware-ului unui server existent, de obicei prin adăugarea mai multor RAM sau CPU.
Este relativ simplu să ai o bază de date relațională care rulează pe o singură mașină și să o mărești după cum este necesar prin actualizarea resurselor sale de calcul. În cele din urmă, însă, orice bază de date nedistribuită va fi limitată în ceea ce privește stocarea și puterea de calcul, astfel încât libertatea de a scala pe orizontală face ca configurarea dvs. să fie mult mai flexibilă.
Un alt motiv pentru care unii ar putea alege o arhitectură bazată pe baze de date este accelerarea timpilor de răspuns la interogare. Când trimiteți o interogare într-o bază de date care nu a fost împărțită, este posibil să fie nevoie să caute în fiecare rând din tabelul pe care îl interogați înainte de a găsi setul de rezultate pe care îl căutați. Pentru o aplicație cu o bază de date mare, monolitică, interogările pot deveni prohibitive. Prin împărțirea unui tabel în mai multe, totuși, interogările trebuie să depășească mai puține rânduri, iar seturile lor de rezultate sunt returnate mult mai rapid.
Fragmentarea poate ajuta, de asemenea, la îmbunătățirea fiabilității unei aplicații prin atenuarea impactului întreruperilor. Dacă aplicația sau site-ul dvs. web se bazează pe o bază de date neprelucrată, o întrerupere are potențialul de a face întreaga aplicație indisponibilă. Cu o bază de date fragmentată, totuși, o întrerupere poate afecta doar un singur fragment. Chiar dacă acest lucru ar putea face unele părți ale aplicației sau ale site-ului web indisponibile pentru unii utilizatori, impactul general ar fi totuși mai mic decât în cazul în care întreaga bază de date se prăbușea.
Dezavantaje ale fragmentării
Deși partajarea unei baze de date poate face scalarea mai ușoară și poate îmbunătăți performanța, poate impune, de asemenea, anumite limitări. Aici, vom discuta despre unele dintre acestea și de ce ar putea fi motive pentru a evita împrăștierea cu totul.
Prima dificultate pe care o întâmpină oamenii cu sharding-ul este complexitatea absolută a implementării corespunzătoare a unei arhitecturi de baze de date sharded. Dacă este făcut incorect, există un risc semnificativ ca procesul de partajare să poată duce la pierderea datelor sau tabele corupte. Chiar și atunci când este realizat corect, este posibil ca fragmentarea să aibă un impact major asupra fluxurilor de lucru ale echipei dvs. În loc să acceseze și să gestioneze datele cu un singur punct de intrare, utilizatorii trebuie să gestioneze datele în mai multe locații de fragmentare, ceea ce ar putea fi perturbator pentru unele echipe.
O problemă pe care utilizatorii o întâmpină uneori după ce au împărțit o bază de date este că fragmentele devin în cele din urmă dezechilibrate. Ca exemplu, să presupunem că aveți o bază de date cu două cioburi separate, una pentru clienții ale căror nume de familie încep cu literele de la A la M și alta pentru cei ale căror nume încep cu literele de la N la Z. Cu toate acestea, aplicația dvs. servește o sumă exagerată a persoanelor ale căror nume de familie încep cu litera G. În consecință, fragmentul AM acumulează treptat mai multe date decât cel din Noua Zeelandă, ceea ce face ca aplicația să încetinească și să se blocheze pentru o parte semnificativă a utilizatorilor dvs. Fragmentul A-M a devenit ceea ce este cunoscut sub numele de hotspot de bază de date. În acest caz, orice beneficii ale partajării bazei de date sunt anulate de încetiniri și blocări. Baza de date ar trebui probabil reparată și reparată pentru a permite o distribuție mai uniformă a datelor.