Roshan Kumar je višja produktna vodja v laboratorijih Redis.
Upoštevanje doslednosti in razpoložljivosti, kot je opisano v izreku CAP, je bil velik izziv za arhitekte geodistribuiranih aplikacij. Omrežni particiji se ni mogoče izogniti. Velika zakasnitev med podatkovnimi centri vedno povzroči kratko prekinitev povezave med podatkovnimi centri. Tako so tradicionalne arhitekture za geo-distribuirane aplikacije zasnovane tako, da se bodisi odrečejo skladnosti podatkov bodisi zadenejo glede razpoložljivosti.
Žal si ne morete privoščiti žrtvovanja razpoložljivosti za interaktivne uporabniške aplikacije. V zadnjem času so arhitekti poskusili doslednost in sprejeli morebitni model skladnosti. V tem modelu so aplikacije odvisne od sistema za upravljanje baz podatkov, da združijo vse lokalne kopije podatkov, da bodo sčasoma skladne.
Z morebitnim modelom skladnosti je vse videti dobro, dokler ne pride do konfliktov podatkov. Nekaj možnih modelov doslednosti obljublja najboljše napore za odpravo konfliktov, vendar ne zagotavlja močne doslednosti. Dobra novica je, da modeli, ki temeljijo na brezkonfliktnih podvojenih vrstah podatkov (CRDT), zagotavljajo močno končno doslednost.
CRDT dosežejo močno skladnost s predhodno določenimi pravili in semantiko reševanja sporov. Aplikacije, zgrajene nad bazami podatkov, ki temeljijo na CRDT, morajo biti zasnovane tako, da ustrezajo semantiki reševanja sporov. V tem članku bomo raziskali, kako oblikovati, razviti in preizkusiti geo-distribuirane aplikacije z uporabo baze podatkov, ki temelji na CRDT. Preučili bomo tudi štiri vzorčne primere uporabe: števci, porazdeljeno predpomnjenje, skupne seje in vnos podatkov iz več regij.
Moj delodajalec Redis Labs je pred kratkim napovedal podporo CRDT v podjetju Redis Enterprise, tako da se replicirani tipi podatkov, ki se ne konfliktno pridružijo bogatemu portfelju podatkovnih struktur - nizi, razpršilci, seznami, nabori, razvrščeni nabori, bitna polja, geo, hiperloglogi in pretoki - v naš izdelek zbirke podatkov. Naslednja razprava pa ne velja samo za Redis Enterprise, temveč tudi za vse zbirke podatkov, ki temeljijo na CRDT.
Zbirke podatkov za geografsko porazdeljene aplikacije
Pri georazdeljenih aplikacijah je običajno, da se odjemalcem izvajajo lokalne storitve. To zmanjša omrežni promet in zakasnitev, ki jo povzroča povratno potovanje. V mnogih primerih arhitekti storitve oblikujejo tako, da se povežejo z lokalno bazo podatkov. Nato pride vprašanje, kako vzdržujete dosledne podatke v vseh zbirkah podatkov. Ena od možnosti je, da to rešite na ravni aplikacije - lahko napišete periodični postopek opravila, ki bo sinhroniziral vse baze podatkov. Lahko pa se zanesete na bazo podatkov, ki bo sinhronizirala podatke med bazami podatkov.
V preostalem delu članka predvidevamo, da se boste odločili za drugo možnost - pustite, da delo opravi baza podatkov. Kot je prikazano na sliki 1 spodaj, vaša geografsko porazdeljena aplikacija izvaja storitve v več regijah, pri čemer se vsaka storitev poveže z lokalno bazo podatkov. Osnovni sistem za upravljanje baz podatkov sinhronizira podatke med zbirkami podatkov, razporejenimi po regijah.
Redis Labs Modeli skladnosti podatkov
Model skladnosti je pogodba med porazdeljeno bazo podatkov in aplikacijo, ki določa, kako čisti so podatki med operacijami pisanja in branja.
Na primer, v močnem modelu doslednosti baza podatkov zagotavlja, da bodo aplikacije vedno prebrale zadnji zapis. Z zaporedno skladnostjo zbirka podatkov zagotavlja, da je vrstni red podatkov, ki jih berete, skladen z vrstnim redom, v katerem so bili zapisani v bazo podatkov. V končnem modelu doslednosti porazdeljena baza podatkov obljublja sinhronizacijo in konsolidacijo podatkov med replikami baze podatkov v ozadju. Če torej svoje podatke zapisujete v eno kopijo baze podatkov in berete iz druge, je verjetno, da ne boste prebrali najnovejše kopije podatkov.
Močna doslednost
Dvofazni prevzem je običajna tehnika za doseganje močne doslednosti. Tu za vsako operacijo pisanja (dodajanje, posodabljanje, brisanje) na lokalnem vozlišču baze podatkov vozlišče baze podatkov razširja spremembe na vsa vozlišča baze podatkov in čaka, da vsa vozlišča potrdijo. Lokalno vozlišče nato pošlje zavezo vsem vozliščem in čaka na drugo potrditev. Aplikacija bo lahko prebrala podatke šele po drugem prevzemu. Razdeljena baza podatkov ne bo na voljo za pisanje, ko se omrežje prekine med bazami podatkov.
Morebitna doslednost
Glavna prednost morebitnega modela skladnosti je, da vam bo baza podatkov na voljo za izvajanje operacij pisanja, tudi ko se prekine omrežna povezava med distribuiranimi replikami baze podatkov. Ta model se na splošno izogiba času povratnega potovanja, ki nastane zaradi dvofazne odobritve, in zato podpira veliko več operacij pisanja na sekundo kot drugi modeli. Težava, ki jo je treba obravnavati pri morebitni doslednosti, so konflikti - hkratno pisanje istega elementa na dveh različnih lokacijah. Glede na to, kako se izognejo konfliktom ali jih rešijo, so morebitne skladne baze podatkov nadalje razvrščene v naslednje kategorije:
- Zmaga zadnji pisatelj (LWW). V tej strategiji se porazdeljene zbirke podatkov zanašajo na sinhronizacijo časovnega žiga med strežniki. Baze podatkov izmenjujejo časovni žig vsake operacije pisanja skupaj s podatki. Če pride do konflikta, zmaga operacija zapisovanja z najnovejšim časovnim žigom.
Pomanjkljivost te tehnike je, da predvideva, da so vse sistemske ure sinhronizirane. V praksi je težko in drago sinhronizirati vse sistemske ure.
- Morebitna skladnost na podlagi kvoruma: Ta tehnika je podobna dvofaznemu prevzemu. Vendar lokalna baza podatkov ne čaka na potrditev iz vseh baz podatkov; čaka le na potrditev iz večine baz podatkov. Priznanje večine je sklepčnost. Če pride do navzkrižja, zmaga operacija pisanja, ki je vzpostavila sklepčnost.
Na drugi strani ta tehnika operacijam pisanja doda mrežno zakasnitev, zaradi česar je aplikacija manj razširljiva. Tudi lokalna baza podatkov ne bo na voljo za zapise, če se v topologiji izolira od drugih replik baze podatkov.
- Replikacija spajanja: V tem tradicionalnem pristopu, ki je pogost med relacijskimi bazami podatkov, centralizirani agent združevanja združi vse podatke. Ta metoda ponuja tudi nekaj prilagodljivosti pri izvajanju lastnih pravil za reševanje sporov.
Replikacija spajanja je prepočasna, da bi podpirala privlačne programe v realnem času. Ima tudi eno samo točko okvare. Ker ta metoda ne podpira vnaprej določenih pravil za reševanje konfliktov, pogosto vodi do napak pri reševanju konfliktov.
- Podvojena vrsta podatkov brez konfliktov (CRDT): Podrobneje boste izvedeli o CRDT v naslednjih nekaj razdelkih. Na kratko, baze podatkov, ki temeljijo na CRDT, podpirajo vrste podatkov in operacije, ki zagotavljajo morebitno doslednost brez konfliktov. Podatkovne baze, ki temeljijo na CRDT, so na voljo tudi takrat, ko distribuirane replike baz podatkov ne morejo izmenjati podatkov. Vedno zagotavljajo lokalno zakasnitev pri operacijah branja in pisanja.
Omejitve? CRDT nimajo koristi vseh primerov uporabe zbirke podatkov. Tudi semantika reševanja konfliktov za zbirke podatkov, ki temeljijo na CRDT, je vnaprej določena in je ni mogoče preglasiti.
Kaj so CRDT?
CRDT so posebne vrste podatkov, ki konvergirajo podatke iz vseh replik baz podatkov. Priljubljeni CRDT-ji so G-števci (števci, ki rastejo samo), PN-števci (pozitivno-negativni števci), registri, G-nizi (nizi, ki rastejo samo), 2P-nizi (dvofazni nizi), ALI nizi ( opazili-odstranili nabore) itd. V ozadju se za konvergiranje podatkov opirajo na naslednje matematične lastnosti:
- Komutativna lastnost: a ☆ b = b ☆ a
- Pridružitvena lastnina: a ☆ (b ☆ c) = (a ☆ b) ☆ c
- Idempotenca: a ☆ a = a
G-števec je odličen primer operativnega CRDT, ki združuje operacije. Tu sta a + b = b + a in a + (b + c) = (a + b) + c. Replike si izmenjujejo samo posodobitve (dodatke). CRDT bo posodobitve združil tako, da jih bo sestavil. G-niz na primer uporabi idempotenco ({a, b, c} U {c} = {a, b, c}) za združitev vseh elementov. Idempotenca preprečuje podvajanje elementov, dodanih v podatkovno strukturo, ko potujejo in se konvergirajo po različnih poteh.
Tipi podatkov CRDT in njihova semantika reševanja konfliktov
Strukture podatkov brez konfliktov: G-števci, PN-števci, G-kompleti
Vse te podatkovne strukture so zasnovane brez konfliktov. Spodnje tabele prikazujejo, kako se podatki sinhronizirajo med replikami baze podatkov.
Redis Labs 
Redis Labs G-števci in PN-števci so priljubljeni za primere uporabe, kot so globalno anketiranje, štetje tokov, sledenje dejavnostim itd. Kompleti G se pogosto uporabljajo za izvajanje tehnologije veriženja blokov. Bitcoini, na primer, uporabljajo vnose blockchain, ki se samo dodajajo.
Registri: Strings, Hashes
Registri po naravi niso brez konfliktov. Običajno sledijo politikam LWW ali reševanju sporov na podlagi sklepčnosti. Slika 4 prikazuje primer, kako register razreši konflikt z upoštevanjem politike LWW.
Redis Labs Registri se uporabljajo predvsem za shranjevanje podatkov predpomnjenja in sej, podatkov o uporabniškem profilu, kataloga izdelkov itd.
2P-kompleti
Dvofazni sklopi vzdržujejo dva sklopa sklopov G - enega za dodane predmete in drugega za odstranjene predmete. Kopije si med sinhronizacijo izmenjajo dodatke G-nabora. Konflikt nastane, če v obeh nizih najdemo isti element. V nekaterih zbirkah podatkov, ki temeljijo na CRDT, kot je Redis Enterprise, to ureja pravilnik »Dodaj zmage nad brisanjem«.
Redis Labs Komplet 2P je dobra podatkovna struktura za shranjevanje skupnih podatkov sej, kot so nakupovalni vozički, dokument v skupni rabi ali preglednica.
Kako zgraditi aplikacijo za uporabo baze podatkov, ki temelji na CRDT
Povezava aplikacije z bazo podatkov, ki temelji na CRDT, se ne razlikuje od povezave aplikacije s katero koli drugo bazo podatkov. Zaradi morebitnih pravilnikov o skladnosti pa mora vaša aplikacija upoštevati določena pravila, da bo zagotovila dosledno uporabniško izkušnjo. Tri tipke:
- Naj bo vaša aplikacija brez državljanstva. Aplikacija brez državljanstva običajno temelji na API-ju. Vsak klic API-ja povzroči popolno rekonstrukcijo celotnega sporočila. To zagotavlja, da vedno izvlečete čisto kopijo podatkov kadar koli. Nizka lokalna zakasnitev, ki jo ponuja baza podatkov, ki temelji na CRDT, omogoča hitrejše in enostavnejše obnavljanje sporočil.
- Izberite pravi CRDT, ki ustreza vašemu primeru uporabe. Števec je najpreprostejši od CRDT-jev. Uporablja se lahko za primere uporabe, kot so glasovanje po vsem svetu, sledenje aktivnim sejam, merjenje itd. Če pa želite združiti stanje porazdeljenih predmetov, morate upoštevati tudi druge podatkovne strukture. Na primer, za aplikacijo, ki uporabnikom omogoča urejanje skupnega dokumenta, boste morda želeli ohraniti ne samo urejanja, temveč tudi vrstni red njihovega izvajanja. V tem primeru bi bila shranjevanje sprememb na seznamu, ki temelji na CRDT, ali v strukturi podatkov o čakalni vrsti boljša rešitev kot shranjevanje v register. Pomembno je tudi, da razumete semantiko reševanja sporov, ki jo uveljavljajo CRDT, in da vaša rešitev ustreza pravilom.
- CRDT ni univerzalna rešitev. Čeprav je CRDT resnično odlično orodje za številne primere uporabe, morda ni najboljši za vse primere uporabe (na primer transakcije ACID). Podatkovne baze, ki temeljijo na CRDT, se na splošno dobro ujemajo z arhitekturo mikro storitev, kjer imate namensko bazo podatkov za vsako mikro storitev.
Tukaj je glavno izhodišče, da se mora vaša aplikacija osredotočiti na logiko in zapletenost upravljanja podatkov in sinhronizacije prenesti na osnovno bazo podatkov.
Testiranje aplikacij z razdeljeno večnamensko bazo podatkov
Če želite hitreje iti na trg, priporočamo, da imate dosleden razvoj, preskušanje, uprizoritev in proizvodnjo. To med drugim pomeni, da mora imeti vaša namestitev za razvoj in testiranje miniaturiziran model vaše porazdeljene baze podatkov. Preverite, ali je vaša baza podatkov, ki temelji na CRDT, na voljo kot Dockerjev vsebnik ali navidezna naprava. Razmnožite replike baze podatkov v različnih podomrežjih, tako da lahko simulirate nastavitve povezane in odklopljene gruče.
Testiranje aplikacij z razdeljeno večnamensko bazo podatkov se morda sliši zapleteno. Toda večino časa boste preizkusili le doslednost podatkov in razpoložljivost aplikacij v dveh situacijah: Ko so distribuirane zbirke podatkov povezane in ko je med bazami omrežna particija.
Z nastavitvijo porazdeljene baze podatkov s tremi vozlišči v svojem razvojnem okolju lahko v preskušanju enote zajemate (in celo avtomatizirate) večino preskusnih scenarijev. Tu so osnovne smernice za preizkušanje aplikacij:
