Non progredi est regredi. Nu merge mai departe - apoi du-te înapoi. Ancient, spunând această înțelepciune universală, a prevăzut, desigur, că ar fi aplicabil chiar și după secole. Și sa întâmplat.
Time-testat și operarea cu succes în zeci de servicii NoSQL-decizie Bigtable a fost în măsură să facă față cu cerința principală Google+, - coerența datelor de utilizator, mii de copii din care sunt împrăștiate pe sute de mii de servere Google.
Depozitul Bigtable pur și simplu nu avea mecanismele care oferă comenzi absolute în timpul acțiunilor pe replicile datelor de utilizator Google+. Mecanisme care funcționează bine în bazele de date relaționale care susțin conceptul de ACID în legătură cu execuția tranzacțiilor SQL distribuite.
NewSQL - sistem de scalabilitate și consistență a datelor într-un ham
De ce NewSQL? E simplu. Produsele care îndeplinesc acest concept de stocare a datelor reprezintă un compromis între nevoia de a diminua stocarea și asigurarea unei coerențe stricte a datelor stocate în ele.
Spannerul Google, desigur, nu este singura soluție NewSQL, dar este cu siguranță cea mai mare, iar arhitectura unică o face deosebit de interesantă.
Strămoșul arhitectural al lui Spanner este, cu siguranță, Bigtable, din care începătorul a moștenit principiul diviziunii tabelelor în tablete și distribuirea lor pe mai multe servere span.
Datele stocate în Spanner, la fel ca în Bigtable, suportă multiversiuni cu marcatori de timp, însă tabela Spanner nu este plană, însă se bazează pe un model logic și suportă interogări SQL. O astfel de soluție hibridă oferă dreptul să se refere la Spanner ca sistem de gestionare a datelor semi-releu.
Arhitectura clusterului Spanner este atât de mare încât se numește Universul. În zonele sale "galaxiilor" trăiesc o varietate de span-servere, capabile să proceseze interogări SQL.
Sprijinul pentru SQL și tranzacțiile distribuite este important, dar principalul avantaj al Spanner constă în celălalt. Noul sistem de stocare Google poate garanta faptul că atunci când tranzacționați în mai multe replici ale tabelelor sale, nu vor exista discrepanțe care să afecteze integritatea și coerența datelor.
Cum rezolvă Spanner această problemă? Folosind o interfață software specială, numită API-ul TrueTime (de la ora adevărată engleză - "timp real").
Ceasuri de perete și maeștri ai lui Armageddon în slujba unei coerențe stricte
Baza API-ului TrueTime este conceptul unei singure opere, care funcționează în întreg spațiul de stocare Spanner, distribuit în mai multe centre de date. Se numește ora globală a ceasului, care este comună pentru toate centrele de date.
Timpul global în Spanner, desigur, nu este stocat într-un singur loc. De asemenea, este distribuit. În cadrul fiecărui centru de date, se desemnează servere speciale, denumite "time master" (Time Master Devices - TMD). Cele mai multe dintre ele primește semnalul de timp de la sistemul de sateliți GPS, dar pentru a fi sigur (nu știi niciodată ce se poate întâmpla cu canal prin satelit la momentul crucial) între TMD au cazuri speciale, care sunt numite „Maeștrii Armageddon» (Armageddon Masters). Acești "ceasornicari" au la bord ... cel mai bun ceas atomic. Și chiar și asta nu este totul. Toate serverele TMD sincronizează în mod constant timpul, comunicând între ele folosind serviciul special timeslave. Cu adevărat TrueTime.
Pentru a permite TrueTime să returneze ora globală exactă pentru fiecare dintre serverele Span, Spanner include "time masters" - nodurile conectate la sistemul GPS și chiar folosind propriile ceasuri atomice.
Timpul global în API-ul TrueTime nu este atât de global. Ar fi mai corect să numim timpul cu o incertitudine limitată. De ce? Într-un sistem distribuit este practic imposibil să se realizeze un răspuns instant al tuturor nodurilor "aici și acum". Prin urmare, funcția TT.now () din biblioteca TrueTime returnează valoarea de timp ca un interval (TT.now ().) Ultimele - TT.now () mai devreme), care ia în considerare eroarea inevitabilă. Astfel, apelul către orice nod Spanner al funcției TT.now () are ca rezultat întoarcerea timpului global curent, dar sub forma unui interval de timp.
Prezența acestui decalaj temporar permite nodurilor Spanner să rezolve problemele legate de coerența datelor care sunt modificate în timpul tranzacției. În acest caz, elementul de bază este așa-numitul protocol de comitere în două faze (Protocolul 2-Phase Commit), care sa dovedit în bazele de date relaționale distribuite. Ea se bazează pe un principiu foarte simplu: dacă tranzacția este efectuată într-un singur nod afectează schimbările în nodurile care conțin o replică a datelor de nod, acesta trebuie să fie fixă (rezultatul schimbării stocate pe disc gazdă), în toate aceste noduri, sau nu efectuate (rollback) pe niciuna dintre ele.
În centrul conceptului TrueTime se află combinația dintre principiul unui timp global definit în mod liber și al unui protocol de comitere în două faze, care asigură o coerență strictă a datelor.
Pentru a implementa protocolul de comitere în două etape în Spanner, algoritmul utilizat în operarea Bigtable este folosit pentru a verifica algoritmul de rezoluție a coliziunii Paxos.
Ce se întâmplă dacă cel puțin unul dintre noduri nu are timp să raporteze despre disponibilitatea de a fi fixat în intervalul de timp alocat? Coordonatorul va returna tranzacția și nu va da comanda să o fixeze la nodurile participante, care vor trebui să revină și ele. După aceasta, se va repeta încercarea de a efectua tranzacția.
Evident, implementarea protocolului de comitere în două faze în serverele de baze de date extrem de fiabile pe care se execută DBMS-urile relaționale este foarte diferită de implementarea clusterelor Google în mod deliberat de nesigure. Și de ce este o combinație unică de hardware implementat în tehnologia de sincronizare TMD-nod și timp global TrueTime funcții de bibliotecă care reprezintă de această dată sub forma unui interval în care nodurile au timp să „negocieze“ cu privire la consistența datelor.
Nu e de mirare că Google a apelat la noul magazin Spanner ("cheie"). Conceptele descrise în acest newSQL-sistem, ferm legat de reciproc toate cele bune pe care a fost atins în domeniul Bigtable scalabilitate fără precedent și reziliență, cu consistență strictă a datelor caracteristice stocate bazei de date relaționale distribuite. Cinci ani de efort petrecut de inginerii Google pentru a obține această conexiune puternică de tehnologie nu sunt irosiți.
Trimiteți-le prietenilor: