Introducere

există o binecunoscută teoremă a informaticii propusă de Eric Brewer care spune că pentru o bază de date cu date distribuite puteți promite doar două din următoarele trei calități:

• consistență
• disponibilitate
• toleranță la partiție

Acest lucru este foarte abstract și terminologia nu este tocmai intuitivă, așa că în acest articol vom face tot posibilul de la abstract la mai multe discuții și exemple din lumea reală. Această teoremă vă poate face să vă gândiți la arhitectura bazei de date în ceea ce privește ceea ce are nevoie cu adevărat aplicația dvs. și sacrificiile pe care ar putea trebui să le facă pentru a le atinge.

definirea terminologiei CAP

Să luăm câteva definiții de bază din drum, astfel încât să putem fi pe aceeași pagină pe măsură ce avansăm vorbind despre această teoremă.

CAP – consistență, disponibilitate, toleranță la partiție

• consistență – toate serverele dvs. de date au aceleași date, astfel încât să puteți interoga orice server din sistem și să obțineți exact aceleași date.
• disponibilitate-fiecare cerere către serverele de date primește un răspuns. Dacă un server este ocupat, acesta este direcționat către altul care este capabil să răspundă.
• toleranță partiție – capacitatea sistemului de a continua să funcționeze chiar dacă există eșecuri de rețea și unele dintre serverele nu pot comunica.

ipoteza de bază – P este imposibilă

într-un sistem de baze de date distribuite, datele dvs. sunt împărțite pe servere diferite și acele servere vorbesc între ele printr-o rețea, astfel încât să poată menține același set de date. Problema este că rețelele se rup și deci presupunem că va comunica întotdeauna, adică nu putem avea o rețea perfectă. În ceea ce privește această teorie, asta înseamnă că în lumea reală trebuie să sacrificați toleranța la partiție. Dacă rețeaua perfectă ar exista, atunci nu am avea o problemă în atingerea coerenței și disponibilității, dar aceasta este lumea reală construită pe fire fizice care eșuează și deci presupunem că va eșua.

dacă P este imposibil, care sunt alegerile noastre?

de când am renunțat la toleranța partiției teorema spune că acum trebuie să alegem între consistență și disponibilitate.

puteți alege să aveți disponibilitate acolo unde aplicația dvs. poate satisface toate solicitările primite, dar nu poate garanta că datele sunt cele mai recente.

de ce are nevoie aplicația dumneavoastră?

dacă aplicația dvs. este un site de socializare și nu trebuie să aibă în permanență cele mai recente date, atunci poate doriți să alegeți disponibilitatea. Contează că utilizatorii dvs. văd o postare după o întârziere de 30 de secunde? Dacă nu, atunci este posibil să preferați disponibilitatea, deoarece acordați prioritate faptului că utilizatorii dvs. pot accesa date chiar dacă nu sunt cele mai actualizate date.

dacă, pe de altă parte, aplicația dvs. necesită ca fiecare citire în baza de date să fie cele mai recente date absolute, atunci va trebui să sacrificați disponibilitatea și să alegeți coerența. Unele solicitări vor trebui să greșească din cauza faptului că informațiile nu pot fi garantate că sunt cele mai recente.

alegerile făcute de relaționale și NoSQL

baza de date tech ca SQL și alte sisteme de baze de date relaționale proiectate cu acid prioritate consistență. Pe de altă parte, majoritatea bazelor de date NoSQL acordă prioritate disponibilității.

concluzie

considerăm că examinarea acestei teoreme în ceea ce privește aplicația dvs. este un exercițiu excelent și vă ajută să evaluați prioritățile aplicației dvs. Dacă aveți un sistem de date distribuite, examinați-vă arhitectura și înțelegeți ce sacrificiu faceți.

MongoDB, CockroachDB și Postgres sunt astăzi o tehnologie excelentă de baze de date care fac arhitecturile noastre de baze de date extrem de robuste, dar așa cum am discutat, acestea nu sunt perfecte. Nu avem o rețea perfectă și există întotdeauna „eroare de utilizator”. Dacă vă mutați într-un mediu de producție și doriți să discutați cele mai bune opțiuni pentru aplicația dvs., vă rugăm să nu ezitați să ne contactați la Object Rocket.