Roshanas Kumaras yra „Redis Labs“ vyresnysis produktų vadovas.
Išlaikyti nuoseklumą ir prieinamumą, kaip aprašyta BŽŪP teoremoje, buvo didelis iššūkis geografiškai paskirstytų programų architektams. Tinklo skaidinys neišvengiamas. Didelė vėlavimo trukmė tarp duomenų centrų visada lemia tam tikrą duomenų centrų atjungimą trumpam laikui. Taigi tradicinės geografiškai paskirstytų programų architektūros yra skirtos atsisakyti duomenų nuoseklumo arba įvertinti pasiekiamumą.
Deja, jūs negalite sau leisti aukoti interaktyvių vartotojų programų prieinamumo. Pastaruoju metu architektai nufotografavo nuoseklumą ir pritaikė galimo nuoseklumo modelį. Šiame modelyje programos priklauso nuo duomenų bazės valdymo sistemos, kad sujungtų visas vietines duomenų kopijas, kad jos galiausiai būtų nuoseklios.
Kol nėra duomenų prieštaravimų, viskas atrodo gerai su galimo nuoseklumo modeliu. Keli galimi nuoseklumo modeliai žada geriausias pastangas išspręsti konfliktus, tačiau neužtikrina tvirto nuoseklumo. Geros naujienos yra tai, kad modeliai, sukurti pagal nekonfliktuojamus duomenų tipus (CRDT), užtikrina galimą nuoseklumą.
CRDT pasiekia tvirtą galimą nuoseklumą naudodamiesi iš anksto nustatytu konfliktų sprendimo taisyklių ir semantikos rinkiniu. CRDT pagrįstų duomenų bazių pagrindu sukurtos programos turi būti suprojektuotos taip, kad būtų pritaikytos konfliktų sprendimo semantikai. Šiame straipsnyje mes ištirsime, kaip kurti, kurti ir išbandyti geografiškai paskirstytas programas naudojant CRDT pagrįstą duomenų bazę. Mes taip pat išnagrinėsime keturis pavyzdinius naudojimo atvejus: skaitikliai, paskirstytos talpyklos, bendri seansai ir daugelio regionų duomenų suvartojimas.
Mano darbdavys „Redis Labs“ neseniai paskelbė apie CRDT palaikymą „Redis Enterprise“, be jokių konfliktų atkartotų duomenų tipų, prisijungiančių prie gausaus duomenų struktūrų portfelio - eilutės, maišos, sąrašai, rinkiniai, rūšiuojami rinkiniai, „Bitfields“, „Geo“, „Hyperloglog“ ir srautai. mūsų duomenų bazės produktas. Tačiau ši diskusija taikoma ne tik „Redis Enterprise“, bet ir visoms CRDT pagrįstoms duomenų bazėms.
Geografiškai paskirstytų programų duomenų bazės
Geografiškai paskirstytose programose klientams dažniausiai teikiamos vietinės paslaugos. Tai sumažina tinklo srautą ir vėlavimą, kurį sukelia pirmyn ir atgal. Daugeliu atvejų architektai kuria paslaugas, kad prisijungtų prie vietinės duomenų bazės. Tada kyla klausimas, kaip jūs palaikote nuoseklius duomenis visose duomenų bazėse. Viena iš galimybių yra tai tvarkyti programos lygiu - galite parašyti periodinį darbo procesą, kuris sinchronizuos visas duomenų bazes. Arba galite pasikliauti duomenų baze, kuri sinchronizuos duomenis tarp duomenų bazių.
Manome, kad likusioje straipsnio dalyje pasirinksite antrąją parinktį - leiskite duomenų bazei atlikti darbą. Kaip parodyta 1 paveiksle, jūsų geografiškai paskirstyta programa teikia paslaugas keliuose regionuose, kiekvienai paslaugai prisijungus prie vietinės duomenų bazės. Pagrindinė duomenų bazių valdymo sistema sinchronizuoja duomenis tarp regionuose įdiegtų duomenų bazių.
„Redis Labs“ Duomenų nuoseklumo modeliai
Nuoseklumo modelis yra sutartis tarp paskirstytos duomenų bazės ir programos, apibrėžianti duomenų švarumą tarp rašymo ir skaitymo operacijų.
Pavyzdžiui, naudojant tvirtą nuoseklumo modelį, duomenų bazė garantuoja, kad programos visada skaitys paskutinį rašymą. Nuosekliai nuosekliai duomenų bazė užtikrina, kad jūsų perskaitytų duomenų eiliškumas atitiktų jų įrašymo į duomenų bazę tvarką. Galutiniame nuoseklumo modelyje paskirstyta duomenų bazė žada sinchronizuoti ir konsoliduoti duomenis tarp duomenų bazės kopijų užkulisiuose. Todėl, jei įrašysite savo duomenis į vieną duomenų bazės kopiją ir perskaitysite iš kitos, gali būti, kad neskaitysite naujausios duomenų kopijos.
Stiprus nuoseklumas
Dviejų fazių įsipareigojimas yra įprasta technika norint pasiekti tvirtą nuoseklumą. Čia kiekvienai vietinės duomenų bazės mazgo rašymo operacijai (pridėti, atnaujinti, ištrinti) duomenų bazės mazgas paskleidžia pakeitimus į visus duomenų bazės mazgus ir laukia, kol visi mazgai patvirtins. Tada vietinis mazgas siunčia įsipareigojimą visiems mazgams ir laukia kito patvirtinimo. Programa galės perskaityti duomenis tik po antro įsipareigojimo. Išplatinta duomenų bazė nebus prieinama rašymo operacijoms, kai tinklas atsijungs tarp duomenų bazių.
Galutinis nuoseklumas
Pagrindinis galimo nuoseklumo modelio privalumas yra tas, kad duomenų bazė bus prieinama rašymo operacijoms atlikti, net kai sugenda tinklo ryšys tarp paskirstytos duomenų bazės kopijų. Apskritai šiuo modeliu išvengiama dviejų fazių įsipareigojimų trukmės pirmyn ir atgal, todėl palaikoma kur kas daugiau rašymo operacijų per sekundę nei kitų modelių. Viena problema, kurią turi spręsti galimas nuoseklumas, yra konfliktai - tuo pačiu metu rašant tą patį daiktą dviejose skirtingose vietose. Atsižvelgiant į tai, kaip jie išvengia ar išsprendžia konfliktus, galiausiai nuoseklios duomenų bazės toliau skirstomos į šias kategorijas:
- Laimi paskutinis rašytojas (LWW). Šioje strategijoje paskirstytos duomenų bazės remiasi laiko žymių sinchronizavimu tarp serverių. Duomenų bazės keičiasi kiekvienos rašymo operacijos laiko žyma kartu su pačiais duomenimis. Jei kiltų konfliktų, laimi rašymo operacija su naujausia laiko žyme.
Šios technikos trūkumas yra tas, kad ji daro prielaidą, kad visi sistemos laikrodžiai yra sinchronizuoti. Praktiškai sunku ir brangu sinchronizuoti visus sistemos laikrodžius.
- Kvorumu pagrįstas galimas nuoseklumas: Ši technika yra panaši į dviejų fazių įsipareigojimą. Tačiau vietinė duomenų bazė nelaukia patvirtinimo iš visų duomenų bazių; ji tiesiog laukia patvirtinimo iš daugumos duomenų bazių. Daugumos pritarimas nustato kvorumą. Jei kiltų konfliktas, laimi kvorumą nustatanti rašymo operacija.
Kita vertus, ši technika prideda tinklo vėlavimą prie rašymo operacijų, todėl programa tampa mažiau keičiama. Be to, vietinė duomenų bazė nebus prieinama rašant, jei ji bus izoliuota nuo kitų topologijos duomenų bazių kopijų.
- Sujungti replikaciją: Taikant šį tradicinį metodą, kuris yra įprastas tarp reliacinių duomenų bazių, centralizuotas sujungimo agentas sujungia visus duomenis. Šis metodas taip pat suteikia tam tikrą lankstumą įgyvendinant savo taisykles konfliktams spręsti.
Sujungimo replikacija yra per lėta, kad būtų palaikomos realiu laiku veikiančios programos. Jis taip pat turi vieną nesėkmės tašką. Kadangi šis metodas nepalaiko iš anksto nustatytų konfliktų sprendimo taisyklių, tai dažnai sukelia klaidų konfliktų sprendimo įgyvendinimą.
- Replikuotų duomenų tipas be konfliktų (CRDT): Apie CRDT išsamiai sužinosite keliuose tolesniuose skyriuose. Trumpai tariant, CRDT pagrįstos duomenų bazės palaiko duomenų tipus ir operacijas, užtikrinančias galimą nuoseklumą be konfliktų. CRDT pagrįstos duomenų bazės yra prieinamos net tada, kai paskirstytos duomenų bazės kopijos negali keistis duomenimis. Jie visada pateikia vietinę vėlavimą skaitymo ir rašymo operacijoms.
Apribojimai? Ne visi duomenų bazių naudojimo atvejai naudingi CRDT. Be to, CRDT pagrįstų duomenų bazių konfliktų sprendimo semantika yra iš anksto apibrėžta ir jos negalima nepaisyti.
Kas yra CRDT?
CRDT yra specialūs duomenų tipai, kurie suartina visų duomenų bazių kopijų duomenis. Populiarūs CRDT yra G skaitikliai (tik auginimo skaitikliai), PN skaitikliai (teigiami-neigiami skaitikliai), registrai, G rinkiniai (tik auginimo rinkiniai), 2P rinkiniai (dviejų fazių rinkiniai), OR rinkiniai ( stebimi-pašalinami rinkiniai) ir kt. Užkulisiuose jie remiasi šiomis matematinėmis savybėmis, kad suartintų duomenis:
- Komutacinė nuosavybė: a ☆ b = b ☆ a
- Asociacinis turtas: a ☆ (b ☆ c) = (a ☆ b) ☆ c
- Idempotencija: a ☆ a = a
G skaitiklis yra puikus operatyvaus CRDT, sujungiančio operacijas, pavyzdys. Čia a + b = b + a ir a + (b + c) = (a + b) + c. Replikos tarpusavyje keičiasi tik atnaujinimais (papildymais). CRDT sujungs atnaujinimus juos susumuodamas. Pavyzdžiui, G rinkinys taiko idempotenciją ({a, b, c} U {c} = {a, b, c}), kad sujungtų visus elementus. Idempotencija išvengia elementų, pridėtų prie duomenų struktūros, dubliavimo, kai jie keliauja ir suartėja skirtingais keliais.
CRDT duomenų tipai ir jų konfliktų sprendimo semantika
Duomenų struktūros be konfliktų: G skaitikliai, PN skaitikliai, G rinkiniai
Visos šios duomenų struktūros pagal konstrukciją neturi konfliktų. Žemiau pateiktose lentelėse parodyta, kaip duomenys sinchronizuojami tarp duomenų bazės kopijų.
„Redis Labs“ 
„Redis Labs“ G skaitikliai ir PN skaitikliai yra populiarūs tokiems naudojimo atvejams kaip visuotinis balsavimas, srautų skaičiavimas, veiklos stebėjimas ir kt. „G-rinkiniai“ yra labai naudojami „blockchain“ technologijai įgyvendinti. Pavyzdžiui, „Bitcoins“ naudoja tik „blockchain“ priedus.
Registrai: stygos, maišos
Registrai iš prigimties nėra be konfliktų. Jie paprastai laikosi LWW ar kvorumu pagrįsto konfliktų sprendimo politikos. 4 paveiksle pateiktas pavyzdys, kaip registras išsprendžia konfliktą, vadovaudamasis LWW politika.
„Redis Labs“ Registrai daugiausia naudojami talpyklos ir sesijos duomenims, vartotojo profilio informacijai, produktų katalogui ir kt.
2P rinkiniai
Dviejų fazių rinkiniai palaiko du G rinkinių rinkinius - vienas skirtas pridėtiems daiktams, kitas - pašalintiems daiktams. Sinchronizuodamos kopijos keičiasi G rinkinio papildymais. Konfliktas kyla, kai abiejuose rinkiniuose randamas tas pats elementas. Kai kuriose CRDT pagrįstose duomenų bazėse, tokiose kaip „Redis Enterprise“, tai tvarko politika „Pridėti laimi ištrynus“.
„Redis Labs“ 2P rinkinys yra gera duomenų struktūra, skirta saugoti bendrų sesijų duomenis, tokius kaip pirkinių krepšeliai, bendras dokumentas ar skaičiuoklė.
Kaip sukurti programą naudojant CRDT pagrįstą duomenų bazę
Programos prijungimas prie CRDT pagrįstos duomenų bazės nesiskiria nuo programos prijungimo prie bet kurios kitos duomenų bazės. Tačiau dėl galimo nuoseklumo politikos jūsų programa turi laikytis tam tikrų taisyklių rinkinio, kad vartotojui būtų teikiama nuosekli patirtis. Trys raktai:
- Padarykite savo prašymą be pilietybės. Programa be pilietybės paprastai valdoma API. Kiekvienas skambutis į API lemia viso pranešimo rekonstravimą nuo nulio. Tai užtikrina, kad bet kuriuo metu visada išspausdinsite švarią duomenų kopiją. CRDT pagrįstos duomenų bazės siūlomas mažas vietinis vėlavimas leidžia greičiau ir lengviau rekonstruoti pranešimus.
- Pasirinkite tinkamą CRDT, kuris tinka jūsų naudojimo atvejui. Skaitiklis yra paprasčiausias iš CRDT. Tai gali būti taikoma tokiems naudojimo atvejams kaip visuotinis balsavimas, aktyvių sesijų stebėjimas, matavimas ir kt. Tačiau, jei norite sujungti paskirstytų objektų būseną, turite atsižvelgti ir į kitas duomenų struktūras. Pavyzdžiui, programoje, leidžiančioje vartotojams redaguoti bendrinamą dokumentą, galbūt norėsite išsaugoti ne tik pakeitimus, bet ir jų atlikimo tvarką. Tokiu atveju redagavimų išsaugojimas CRDT pagrįstame sąraše arba eilės duomenų struktūroje būtų geresnis sprendimas nei jų saugojimas registre. Taip pat svarbu, kad suprastumėte CRDT vykdomą konfliktų sprendimo semantiką ir kad jūsų sprendimas atitiktų taisykles.
- CRDT nėra universalus sprendimas. Nors CRDT iš tiesų yra puiki priemonė daugeliui naudojimo atvejų, ji gali būti ne pati geriausia visiems naudojimo atvejams (pvz., ACID operacijoms). CRDT pagrįstos duomenų bazės paprastai gerai derinamos su mikropaslaugų architektūra, kur kiekvienai mikropaslaugai turite specialią duomenų bazę.
Pagrindinis pasirinkimas yra tai, kad jūsų programa turėtų sutelkti dėmesį į logiką ir perduoti duomenų valdymą ir sinchronizavimo sudėtingumą pagrindinei duomenų bazei.
Programų testavimas naudojant paskirstytą daugialypę duomenų bazę
Norėdami greičiau patekti į rinką, rekomenduojame nuosekliai kurti, išbandyti, pakopų ir gamybos sąranką. Be kita ko, tai reiškia, kad jūsų kūrimo ir testavimo sąrankoje turi būti miniatiūrinis paskirstytos duomenų bazės modelis. Patikrinkite, ar jūsų CRDT pagrindu sukurta duomenų bazė yra prieinama kaip „Docker“ talpykla arba virtualusis prietaisas. Įdiekite savo duomenų bazės kopijas skirtinguose potinkliuose, kad galėtumėte imituoti prijungtų ir atjungtų grupių sąranką.
Programų testavimas naudojant paskirstytą daugialypę duomenų bazę gali atrodyti sudėtingas. Tačiau dažniausiai jūs tikrinsite duomenų nuoseklumą ir programų prieinamumą dviem atvejais: kai prijungtos paskirstytos duomenų bazės ir kai tarp duomenų bazių yra tinklo skaidinys.
Sukūrę trijų mazgų paskirstytą duomenų bazę savo kūrimo aplinkoje, galite aprėpti (ir net automatizuoti) daugumą testavimo scenarijų atlikdami vieneto testavimą. Čia pateikiamos pagrindinės programų testavimo gairės:
