Sisteme de baze de date - ce este teorema CAP?
Vrei ultima? oricare disponibilă? sau ce-am scris înainte să se ia curentul? Alege două.
Acronimul CAP vine de la Consistency, Availabilty and Partition tolerance, după teorema propusă de Eric Brewer1. Aceasta nu se referă doar la sistemele de baze de date, ci la sistemele distribuite în general și afirmă următoarele:
Este imposibil ca un sistem distribuit de stocare a datelor, să furnizeze simultan mai mult de două dintre urmatoarele trei garanții:
Consistență: Fiecare citire primește cea mai recentă versiune sau o eroare.
Disponibilitate: fiecare cerere primește un răspuns care nu este o eroare, fără garanția că acesta reprezintă cea mai recentă versiune.
Toleranță la partiționare: sistemul continuă să opereze chiar daca un număr arbitrar de mesaje sunt pierdute sau întârziate în rețeaua dintre noduri.
Uitându-ne la aceste trei constrângeri este ușor de observat, de ce sunt imposibil de implementat. Însă în designul sau alegerea unui sistem baze de date se prioritizează de obicei două dintre ele:
fie ai consistență și disponibilitate (CA), dar în cazul unei partiții între noduri sistemul va returna erori: MySQL, MariaDb2, SQL Server.
(CP) consistență și toleranță la partiționare, fără garanția disponibilității: Hbase, MongoDb3, Redis, BigTable.
(AP) disponibilitate și toleranță crescută, cu renunțarea la consistență: Cassandra, ScyllaDb4, Riak, CouchDb.
Legat de baze de date, mai două concepte importante de menționat: eventual consistency și ACID.
Eventual consistency - orice bază de date devine consistentă în urma unui eveniment, și respectiv toate nodurile care comunică între ele vor avea aceeași versiune. Și cum menționam consistența mai sus, care este sacrificată în cazul sistemelor AP (availability & partition tolerance), asta nu înseamnă că aceste sisteme nu au consistență, dar nu sunt proiectate să garanteze consistența datelor - devin consistente eventual.
De exemplu, în urma unei erori de rețea ireconciliabile, în care nodurile nu pot comunica unul cu celălalt - un server din Australia nu mai poate comunica cu cel din București, aceste sisteme vor returna valori diferite pentru clienții din Australia decât pentru cei din București. Odată restabilită conexiunea, cea mai recentă versiunea va fi distribuită între noduri.
Simlar cu o pană de curent la un datacenter, asta poate fi o problemă cu impact minor, pentru o aplicație de email. Însă în cazul unei aplicații pentru tranzacții financiare este innacceptabil să obții valori diferite pentru aceleași cereri. Și de aceea în acest caz se va alege un sistem CP (consistency & partition tolerance).
De asemenea să nu confundăm CAP cu ACID. Acesta din urmă specifică un mod de operare al tranzacțiilor, și este specific RDBMS-urilor5.
Când sunt importante limitările CAP?
Desigur, această ”clasificare” este irelavantă dacă aplicația încă în stadiul de dezvoltare cu baza de date pe un singur server (nod). Dar în momentul când va fi nevoie să scaleze la mai multe noduri, cu replicare și sincronizare, sau când volumul de date necesită adoptarea unei soluții alternative pentru baza de date, cunoașterea acestor limitări ne va ajuta să facem o evaluare solidă.
De asemenea, și bazele de date proprietare, pe care le lansezi în cloud, au aceste limitări plus detalii despre latență și consistență între datacenters. Pentru unele seturi de date, de exemplu, cazul în care monitorizezi nivelul apei unui fluviu - mai mult de 1 secundă de latență este inacceptabil.
Mai este relevantă CAP în 2023?
O întrebare validă, mai ales că această teoremă a fost publicată în 1998. Însăși autorul, Eric Brewer menționează că ”regulile s-au schimbat” într-un articol din InfoQ publicat în 20126.
Un alt articol7, din 2015 argumentează că ar trebui să abandonăm această clasificare, deoarece este de cele mai multe ori ambiguă și în funcție de vendor poate fi interpretată.
Eu cred că aceste concepte sunt importante, și utile de știut chiar dacă aplicabilitatea lor este mai puțin relevantă în ziua de azi. CAP pornește cu o serie de întrebări ”ce se întâmplă dacă…?”, și ne amintește despre limitările de care le vom întâlni când proiecteăm sisteme distribuite.
CAP Twelve Years Later: How the "Rules" Have Changed (Eric Brewer)
Please stop calling databases CP or AP (Martin Kleppmann)