Kada koristiti bazu podataka temeljenu na CRDT-u

Roshan Kumar viši je voditelj proizvoda u Redis Labs.

Savijanje dosljednosti i dostupnosti kako je opisano u CAP teoremu bio je veliki izazov za arhitekte geo-distribuiranih aplikacija. Mrežna je particija neizbježna. Velika latencija između podatkovnih centara uvijek rezultira nekim prekidom veze između podatkovnih centara na kratko vrijeme. Tako su tradicionalne arhitekture za geo-distribuirane aplikacije osmišljene tako da se odreknu dosljednosti podataka ili pogodi dostupnost.

Nažalost, ne možete si priuštiti žrtvovanje dostupnosti interaktivnih korisničkih aplikacija. U novije vrijeme arhitekti su pokušali dosljednost i prihvatili konačni model dosljednosti. U ovom modelu aplikacije ovise o sustavu upravljanja bazom podataka kako bi spojile sve lokalne kopije podataka kako bi ih na kraju postale dosljedne.

S mogućim modelom dosljednosti sve izgleda dobro dok ne dođe do sukoba podataka. Nekoliko mogućih modela dosljednosti obećava najbolji napor za rješavanje sukoba, ali ne osigurava snažnu dosljednost. Dobra vijest je da modeli izgrađeni na osnovi repliciranih tipova podataka (CRDT) bez sukoba daju konačnu dosljednost.

CRDT postižu snažnu konačnu dosljednost unaprijed određenim skupom pravila i semantike rješavanja sukoba. Aplikacije izgrađene na vrhu baza podataka temeljenih na CRDT-u moraju biti dizajnirane tako da odgovaraju semantici rješavanja sukoba. U ovom ćemo članku istražiti kako dizajnirati, razvijati i testirati geo-distribuirane aplikacije pomoću baze podataka utemeljene na CRDT-u. Također ćemo ispitati četiri slučaja upotrebe: brojači, distribuirano predmemoriranje, dijeljene sesije i unos podataka iz više regija.

Moj poslodavac, Redis Labs, nedavno je najavio podršku za CRDT u Redis Enterpriseu, repliciranim vrstama podataka bez sukoba koji se pridružuju bogatom portfelju podatkovnih struktura - nizovi, hashovi, popisi, skupovi, razvrstani skupovi, bitna polja, Geo, Hyperloglog i Streamovi - u naš proizvod baze podataka. Međutim, sljedeća se rasprava odnosi ne samo na Redis Enterprise, već i na sve baze podataka temeljene na CRDT-u.

Baze podataka za geo-distribuirane aplikacije

Za geo-distribuirane aplikacije uobičajeno je pokretanje lokalnih usluga za klijente. To smanjuje mrežni promet i kašnjenje uzrokovano povratnim putovanjem. U mnogim slučajevima arhitekti dizajniraju usluge za povezivanje s lokalnom bazom podataka. Tada dolazi pitanje kako održavate dosljedne podatke u svim bazama podataka. Jedna je mogućnost da se to riješi na razini aplikacije - možete napisati periodični postupak posla koji će sinkronizirati sve baze podataka. Ili se možete osloniti na bazu podataka koja će sinkronizirati podatke između baza podataka.

Za ostatak članka pretpostavljamo da ćete pristati na drugu opciju - neka baza podataka obavi posao. Kao što je prikazano na slici 1 dolje, vaša geo-distribuirana aplikacija pokreće usluge u više regija, pri čemu se svaka usluga povezuje s lokalnom bazom podataka. Temeljni sustav upravljanja bazom podataka sinkronizira podatke između baza podataka raspoređenih po regijama.

Redis laboratoriji

Modeli konzistentnosti podataka

Model dosljednosti je ugovor između distribuirane baze podataka i aplikacije koji definira koliko su podaci čisti između operacija pisanja i čitanja.

Na primjer, u modelu jake dosljednosti, baza podataka jamči da će aplikacije uvijek čitati posljednje upisivanje. Slijedom dosljednosti, baza podataka osigurava da je redoslijed podataka koje ste pročitali u skladu s redoslijedom kojim su zapisani u bazu podataka. U konačnom modelu dosljednosti, distribuirana baza podataka obećava sinkronizaciju i konsolidaciju podataka između replika baze podataka iza kulisa. Stoga, ako svoje podatke zapišete u jednu repliku baze podataka i pročitate iz druge, moguće je da nećete pročitati najnoviju kopiju podataka.

Snažna dosljednost

Dvofazno predavanje uobičajena je tehnika za postizanje jake dosljednosti. Ovdje za svaku operaciju pisanja (dodavanje, ažuriranje, brisanje) na lokalnom čvoru baze podataka čvor baze podataka širi promjene na sve čvorove baze podataka i čeka da ih svi čvorovi potvrde. Lokalni čvor tada šalje predavanje svim čvorovima i čeka novo potvrđivanje. Aplikacija će moći čitati podatke tek nakon drugog urezivanja. Distribuirana baza podataka neće biti dostupna za operacije pisanja kada se mreža prekine vezu između baza podataka.

Eventualna dosljednost

Glavna prednost mogućeg modela dosljednosti je što će vam baza podataka biti dostupna za obavljanje operacija upisivanja čak i kada se prekine mrežna povezanost između distribuiranih replika baze podataka. Općenito, ovaj model izbjegava vrijeme povratnog putovanja nastalog dvofaznim urezivanjem, pa prema tome podržava daleko više operacija pisanja u sekundi od ostalih modela. Jedan od problema s kojim se eventualna dosljednost mora pozabaviti jesu sukobi - istovremeno upisivanje iste stavke na dvije različite lokacije. Na temelju načina na koji izbjegavaju ili rješavaju sukobe, eventualno dosljedne baze podataka dalje se klasificiraju u sljedeće kategorije:

  1. Posljednji pisac pobjeđuje (LWW).  U ovoj se strategiji distribuirane baze podataka oslanjaju na sinkronizaciju vremenske oznake između poslužitelja. Baze podataka razmjenjuju vremensku oznaku svake operacije upisivanja zajedno sa samim podacima. Ako dođe do sukoba, pobjeđuje operacija pisanja s najnovijom vremenskom oznakom.

    Nedostatak ove tehnike je taj što pretpostavlja da su svi satovi sustava sinkronizirani. U praksi je teško i skupo sinkronizirati sve sistemske satove.

  2. Eventualna dosljednost zasnovana na kvorumu: Ova tehnika slična je dvofaznom predavanju. Međutim, lokalna baza podataka ne čeka potvrdu iz svih baza podataka; samo čeka potvrdu iz većine baza podataka. Priznanje većine uspostavlja kvorum. Ako dođe do sukoba, pobjeđuje operacija upisa koja je uspostavila kvorum.

    Sa druge strane, ova tehnika dodaje mrežno kašnjenje operacijama pisanja, što aplikaciju čini manje skalabilnom. Također, lokalna baza podataka neće biti dostupna za upisivanje ako se izolira od ostalih replika baze podataka u topologiji.

  3. Replikacija spajanja: U ovom tradicionalnom pristupu, koji je uobičajen među relacijskim bazama podataka, centralizirani agent spajanja spaja sve podatke. Ova metoda također nudi određenu fleksibilnost u primjeni vlastitih pravila za rješavanje sukoba.

    Replikacija objedinjavanja prespora je za podržavanje zanimljivih aplikacija u stvarnom vremenu. Također ima jednu točku neuspjeha. Kako ova metoda ne podržava unaprijed postavljena pravila za rješavanje sukoba, često dovodi do implementacije programskih pogrešaka za rješavanje sukoba.

  4. Replicirani tip podataka bez sukoba (CRDT): Pojedinosti o CRDT-ovima saznat ćete u sljedećih nekoliko odjeljaka. Ukratko, baze podataka temeljene na CRDT-u podržavaju vrste podataka i operacije koje pružaju eventualnu dosljednost bez sukoba. Baze podataka temeljene na CRDT-u dostupne su čak i kada distribuirane replike baze podataka ne mogu razmijeniti podatke. Uvijek isporučuju lokalnu latenciju operacijama čitanja i pisanja.

    Ograničenja? Nisu svi slučajevi upotrebe baze podataka korisni od CRDT-a. Također, semantika rješavanja sukoba za baze podataka temeljenih na CRDT-u unaprijed je definirana i ne može se nadjačati.

Što su CRDT?

CRDT-ovi su posebne vrste podataka koje konvergiraju podatke iz svih replika baze podataka. Popularni CRDT-ovi su G-brojači (brojači samo za rast), PN-brojači (pozitivno-negativni brojači), registri, G-skupovi (skupovi samo za rast), 2P-setovi (dvofazni setovi), ILI-skupovi ( promatrano-uklanjanje skupova) itd. Iza kulisa oslanjaju se na sljedeća matematička svojstva kako bi konvergirali podatke:

  1. Komutativno svojstvo: a ☆ b = b ☆ a
  2. Asocijativno svojstvo: a ☆ (b ☆ c) = (a ☆ b) ☆ c
  3. Idempotencija:  a ☆ a = a

G-brojač savršen je primjer operativnog CRDT-a koji spaja operacije. Ovdje su a + b = b + a i a + (b + c) = (a + b) + c. Replike međusobno razmjenjuju samo nadogradnje (dodatke). CRDT će spojiti ažuriranja njihovim dodavanjem. G-skup, na primjer, primjenjuje idempotenciju ({a, b, c} U {c} = {a, b, c}) za spajanje svih elemenata. Idempotencija izbjegava dupliciranje elemenata dodanih u strukturu podataka dok putuju i konvergiraju različitim putovima.

CRDT tipovi podataka i njihova semantika rješavanja sukoba

Strukture podataka bez sukoba: G-brojači, PN-brojači, G-skupovi

Sve su ove strukture podataka dizajnirane bez sukoba. Tablice u nastavku prikazuju kako se podaci sinkroniziraju između replika baze podataka.

Redis Labs Redis Labs

G-brojači i PN-brojači popularni su za slučajeve upotrebe kao što su globalno anketiranje, brojanje streamova, praćenje aktivnosti i tako dalje. G-setovi se u velikoj mjeri koriste za primjenu blockchain tehnologije. Bitcoini, na primjer, koriste unose blockchaina samo za dodavanje.

Registri: žice, hashovi

Registri po svojoj prirodi nisu bez sukoba. Oni obično slijede politike LWW-a ili rješavanje sukoba na temelju kvoruma. Slika 4 prikazuje primjer kako registar rješava sukob slijedeći politiku LWW.

Redis laboratoriji

Registri se uglavnom koriste za pohranu podataka iz predmemorije i sesija, podataka o korisničkom profilu, kataloga proizvoda itd.

2P-setovi

Dvofazni kompleti održavaju dva seta G-setova - jedan za dodane stavke, a drugi za uklonjene. Replike razmjenjuju dodatke G-skupa kada se sinkroniziraju. Sukob nastaje kada se u oba skupa pronađe isti element. U nekim bazama podataka temeljenim na CRDT-u, kao što je Redis Enterprise, ovim se upravlja pravilo "Dodaj pobjede nad brisanjem".

Redis laboratoriji

2P-set dobra je podatkovna struktura za pohranu dijeljenih podataka sesija poput košarica, zajedničkog dokumenta ili proračunske tablice.

Kako oblikovati aplikaciju za upotrebu baze podataka temeljenu na CRDT-u

Povezivanje aplikacije s bazom podataka temeljenom na CRDT-u ne razlikuje se od povezivanja aplikacije s bilo kojom drugom bazom podataka. Međutim, zbog mogućih pravila o dosljednosti, vaša aplikacija mora slijediti određeni skup pravila kako bi pružila dosljedno korisničko iskustvo. Tri tipke: 

  1. Neka vaša aplikacija bude bez državljanstva. Aplikacija bez državljanstva obično se temelji na API-ju. Svaki poziv API-u rezultira rekonstrukcijom kompletne poruke od nule. To osigurava da uvijek izvučete čistu kopiju podataka u bilo kojem trenutku. Niska lokalna latencija koju nudi baza podataka temeljena na CRDT-u čini rekonstrukciju poruka bržom i lakšom. 

  2. Odaberite pravi CRDT koji odgovara vašem slučaju upotrebe. Brojač je najjednostavniji od CRDT-ova. Može se primijeniti na slučajeve upotrebe kao što su globalno glasanje, praćenje aktivnih sesija, mjerenje itd. Međutim, ako želite spojiti stanje distribuiranih objekata, tada morate uzeti u obzir i druge strukture podataka. Na primjer, za aplikaciju koja omogućuje korisnicima uređivanje zajedničkog dokumenta, možda ćete htjeti sačuvati ne samo uređivanja, već i redoslijed kojim su izvršena. U tom bi slučaju spremanje uređivanja na popis temeljen na CRDT-u ili u strukturi podataka o redu čekanja bilo bi bolje rješenje od pohrane u registar. Također je važno da razumijete semantiku rješavanja sukoba koju provode CRDT-ovi i da vaše rješenje bude u skladu s pravilima.
  3. CRDT nije jednoznačno rješenje. Iako je CRDT doista izvrstan alat za mnoge slučajeve upotrebe, možda nije najbolji za sve slučajeve korištenja (na primjer, ACID transakcije). Baze podataka temeljene na CRDT-u općenito se dobro uklapaju u arhitekturu mikro usluga, gdje za svaku mikro uslugu imate namjensku bazu podataka.

Ovdje je glavno da se vaša aplikacija treba usredotočiti na logiku i prenijeti složenost upravljanja podacima i sinkronizacijom na temeljnu bazu podataka.

Testiranje aplikacija s distribuiranom multi-master bazom podataka

Da biste postigli brže izlazak na tržište, preporučujemo da imate dosljedan razvoj, testiranje, postavljanje i proizvodnju. Između ostalog, to znači da vaša postavka za razvoj i testiranje mora imati minijaturizirani model vaše distribuirane baze podataka. Provjerite je li vaša baza podataka bazirana na CRDT dostupna kao Docker spremnik ili virtualni uređaj. Postavite replike baze podataka na različite podmreže kako biste mogli simulirati postavljanje povezanih i odvojenih klastera.

Testiranje aplikacija s distribuiranom multi-master bazom podataka može zvučati složeno. No, većinu vremena sve za što ćete testirati je dosljednost podataka i dostupnost aplikacija u dvije situacije: Kada su distribuirane baze podataka povezane i kada između baza podataka postoji mrežna particija.

Postavljanjem distribuirane baze podataka s tri čvora u vašem razvojnom okruženju možete pokriti (pa čak i automatizirati) većinu scenarija testiranja u jedinstvenom testiranju. Evo osnovnih smjernica za testiranje vaših aplikacija: