4.1 Consecvență despre Brewera
Pentru început, Eric Brewer nu este și nu a pretins niciodată că este un expert în baze de date. El face parte din comunitatea sistemelor distribuite, iar celebra sa conferință, în care a apărut „teorema” CAP, a fost susținută la conferința „Principii de calcul distribuit”. (Apropo, zece ani mai târziu, în 2010, a ținut din nou o conferință invitată la aceeași conferință, iar în această discuție a oferit, în special, o serie de exemple de sisteme distribuite, a căror dezvoltare a ținut cont de „ teorema" a CAP.) În acest domeniu are propria interpretare a termenilor utilizați în domeniul bazelor de date.
În special, termenul „coerență imediată” înseamnă că, după ce utilizatorul primește notificare de la sistem despre finalizarea cu succes a unei operațiuni de actualizare a datelor, rezultatul acestei operațiuni devine instantaneu vizibil pentru toți observatorii.
Consecvența eventuală înseamnă că, dacă nicio operațiune nouă de actualizare a datelor nu intră în sistem pentru o perioadă de timp suficient de lungă, atunci se poate aștepta ca rezultatele tuturor operațiunilor anterioare de actualizare a datelor să se răspândească în cele din urmă la toate nodurile sistemului și toate datele replicilor să fie consistent (aparent, acest lucru ar trebui înțeles ca „toate replicile vor avea aceeași stare”.
Având în vedere acest sentiment de consistență, „teorema” lui Brewer poate fi considerată destul de înțeleasă și evidentă: în orice sistem distribuit cu date partajate, pot fi asigurate simultan numai oricare două proprietăți de consistență, disponibilitate și toleranță de partiție a rețelei. În acest sens, Brewer chiar contrastează setul de proprietăți ACID cu setul propus de proprietăți de BAZĂ (Basically Available, Soft-state, Eventuale consistență - disponibilitate în majoritatea cazurilor; stare instabilă; consistență finală). Dar această opoziție, în opinia mea, este nejustificată, deoarece în primul caz vorbim despre caracteristicile logice ale tranzacțiilor, iar în al doilea - despre proprietățile fizice ale sistemelor distribuite.
4.2 Demonstrarea „teoremei”
Mulți cred că „teorema” lui Brewer a fost dovedită oficial. Într-adevăr, lucrarea lui Seth Gilbert și Nancy Lynch introduce câteva definiții (aproape) formale în care context „teorema” devine într-adevăr o teoremă și este demonstrată. Totuși, să vedem cum sunt determinate acele trei proprietăți ale unui sistem distribuit, dintre care, conform „teoremei lui Brewer”, doar două proprietăți pot fi suportate simultan.
Consistența se numește consistență atomică sau liniarizată (consistență atomică sau liniizabilă), care este o proprietate a sistemului, toate obiectele de date individuale ale cărora sunt atomice (liniizabile). La rândul său, un obiect atomic este un obiect cu mai multe operații, astfel încât apelul operației și primirea datelor de răspuns au loc ca instantaneu, adică. obiectul nu acceptă apelul următoarei operații până când operațiunea anterioară nu este complet finalizată. Ordinea în care sunt primite operațiile trebuie să fie astfel încât, dacă o operație de tip citire sosește după ce a fost efectuată o operație de tip scriere, atunci operația de citire trebuie să returneze valoarea scrisă de această operație de scriere sau de o operație de scriere ulterioară.
Un sistem distribuit este întotdeauna disponibil dacă fiecare solicitare primită de un nod care nu a eșuat trebuie să primească răspuns. Reziliența sistemului la partiția rețelei este modelată ca păstrarea viabilității sistemului în cazul pierderii unui număr arbitrar de mesaje trimise de la un nod la altul.
Pe baza acestor definiții, Hilbert și Lynch formulează următoarea teoremă (nu există un ceas în modelul de rețea asincronă, iar nodurile ar trebui să ia decizii numai pe baza mesajelor primite și a calculelor locale):
Într-un model de rețea asincronă, nu este posibilă implementarea unui obiect de date de citire/scriere care să garanteze disponibilitatea și proprietățile de consistență atomică pentru toate execuțiile valide (inclusiv cele care pierd mesaje).
Această teoremă este într-adevăr destul de simplu demonstrată formal prin metoda „prin contradicție”. Articolul continuă la concluzia că:
Într-un model de rețea asincron, nu este posibilă implementarea unui obiect de date de citire/scriere care să garanteze proprietăți de accesibilitate pentru toate execuțiile valide și consistența atomică pentru execuțiile valide în care mesajele nu sunt pierdute.
În plus, adevărul teoremei principale este dovedit pentru un model de rețea parțial sincron, în care fiecare nod are un ceas, timpul arătat de care crește în aceeași rată, dar care nu sunt sincronizate, adică. poate arăta momente diferite în același moment real. Se arată că pentru acest caz nu se derivă o consecință similară și, prin urmare, pentru rețelele parțial sincrone există mai multe posibilități de organizare a sistemelor distribuite cu proprietăți „bune”.
Da, într-un sens (nu neapărat același cu intenția lui Brewer) se poate considera că Gilbert și Lynch au demonstrat că este imposibil să se asigure simultan proprietățile consistenței atomice, disponibilitatea și toleranța de partiție a unei rețele într-un singur sistem distribuit. Dar ce legătură are asta cu tranzacțiile cu bazele de date în general și cu tranzacțiile ACID în special?
4.3 Tranzacții cu ACID
Iată ce scrie Julian Browne despre aceasta în nota sa despre discuția despre „teorema” CAP:
În demonstrația lor, Hilbert și Lynch folosesc termenul de atomicitate în loc de consistență, ceea ce are mai mult sens din punct de vedere tehnic deoarece, strict vorbind, consistența în sensul de ACID se referă la proprietățile ideale ale tranzacțiilor cu baze de date și înseamnă că nicio dată nu va devin persistente dacă încalcă unele restricții prestabilite. Dar dacă presupunem că o limitare prestabilită a sistemelor distribuite este interzicerea prezenței mai multor valori diferite pentru același element de date, atunci, în opinia mea, acest defect în abstractizarea consistenței poate fi luat în considerare. nesemnificativ (în plus, dacă Brewer ar folosi termenul de atomicitate, atunci ar apărea teorema AAP, al cărei nume ar fi extrem de incomod de pronunțat).
Acesta este scris nu foarte serios, dar sincer. Și, de fapt, cerința de consistență atomică nu trebuie amestecată cu cerințele de consistență tranzacțională în sensul de ACID. Constrângerile de integritate a bazei de date sunt logice, dacă vreți, cerințe de afaceri. Ele provin din logica domeniului aplicației. Cerința de consistență atomică este de un fel foarte diferit. Aceasta este o cerință de implementare care se încadrează în categoria la care se face referire în mod tradițional în industria bazelor de date ca consistență fizică (de exemplu, atunci când se efectuează orice operație de modificare a indexului, toate blocurile arborelui B+ corespunzător trebuie să conțină valori valide și să fie legate prin referințe valide ).
Și iată ce scriu destul de serios reprezentanții comunității bazei de date Daniel Abadi și Alexander Thomson în nota lor:
... cerința de disponibilitate a sistemelor tranzacționale scalabile devine din ce în ce mai critică, iar aceasta este de obicei îndeplinită prin replicarea și redirecționarea automată a cererilor în cazul unei defecțiuni a unuia dintre noduri. Prin urmare, dezvoltatorii de aplicații se așteaptă ca garanțiile de consistență ale sistemelor ACID (constând inițial în suport local pentru invarianții definiti de utilizator) să fie extinse pentru a asigura o consistență puternică (că toate replicile acelorași date la un moment dat vor fi copii identice, adică în această consistență a cazului este implicată în sensul CAP/PACELC.
Cu alte cuvinte, consistența Brewer nu are nimic de-a face cu consistența în sensul ACID, dar este de dorit să se mențină o consistență puternică a replicii în sistemele concentrate pe furnizarea de disponibilitate ridicată prin replicarea datelor. Aceasta nu este o proprietate ACID, ci o caracteristică tehnică (fizică) a DBMS masiv paralel care facilitează dezvoltarea aplicațiilor.
Potrivit lui Michael Stonebreaker, cheia construirii unui DBMS modern de înaltă calitate este alegerea corectă a compromisurilor tehnice. Atunci când alegeți o soluție de inginerie specifică, trebuie luați în considerare mulți factori - cerințele viitorilor utilizatori, probabilitatea diferitelor situații de defecțiune etc., și să nu fie ghidați dogmatic de niciun ghid teoretic general (inclusiv „teorema CAP”).
Stonebreaker consideră că în domeniul sistemelor de baze de date paralele tranzacționale, abandonarea consecvenței lui Brewer în favoarea suportării disponibilității ridicate și toleranței partițiilor de rețea este un compromis slab, deoarece (a) consistența replica este o caracteristică foarte utilă a sistemului; (b) SGBD-uri tranzacționale masiv paralele nu au nevoie de clustere cu un număr foarte mare de noduri, astfel încât situațiile de împărțire a rețelei sunt puțin probabile; (c) sistemul poate deveni cu ușurință indisponibil, nu din cauza unei partiții de rețea, ci, de exemplu, din cauza prezenței erorilor software care apar în mod regulat.
Astfel, activitatea înaltă a reprezentanților taberei NoSQL (a se citi NoACID), care se referă adesea la „teorema” lui Brewer, nu este legată de imposibilitatea teoretică a construirii SGBD tranzacționale masiv paralele care suportă tranzacțiile ACID, ci de faptul că sistemele simplificate care nu acceptă doar tranzacțiile ACID, ci și consistența replica, sunt create mai ușor și mai rapid. Datorită organizării lor simpliste, acestea sunt capabile de procesare foarte rapidă a datelor, iar pentru unele aplicații acest lucru este mai important decât toate facilitățile inerente tehnologiei bazelor de date.
Să vedem cum răspunde comunitatea bazei de date la această provocare.