Programovanie

Kedy použiť databázu založenú na CRDT

Roshan Kumar je senior produktový manažér v Redis Labs.

Ohýbanie konzistencie a dostupnosti, ako ich popisuje veta CAP, bolo pre architektov geodistribuovaných aplikácií veľkou výzvou. Sieťovému oddielu sa nedá vyhnúť. Vysoká latencia medzi dátovými centrami vždy vedie k určitému odpojeniu medzi dátovými centrami na krátke časové obdobie. Tradičné architektúry pre geodistribuované aplikácie sú teda navrhnuté tak, aby sa vzdali konzistencie údajov alebo znížili dostupnosť.

Bohužiaľ si nemôžete dovoliť obetovať dostupnosť pre interaktívne užívateľské aplikácie. V poslednej dobe si architekti dali záležať na konzistencii a prijali prípadný model konzistencie. V tomto modeli závisia aplikácie od systému správy databáz, aby zlúčili všetky miestne kópie údajov, aby boli nakoniec konzistentné.

S prípadným modelom konzistencie vyzerá všetko dobre, až kým nedôjde ku konfliktom údajov. Niekoľko prípadných modelov konzistencie sľubuje najlepšie úsilie na vyriešenie konfliktov, nedosahuje však záruku silnej konzistencie. Dobrou správou je, že modely postavené na bezkonfliktných replikovaných dátových typoch (CRDT) poskytujú silnú konečnú konzistenciu.

CRDT dosahujú silnú prípadnú konzistenciu prostredníctvom vopred určeného súboru pravidiel a sémantiky riešenia konfliktov. Aplikácie postavené na databázach založených na CRDT musia byť navrhnuté tak, aby vyhovovali sémantike riešenia konfliktov. V tomto článku sa budeme zaoberať návrhom, vývojom a testovaním geograficky distribuovaných aplikácií pomocou databázy založenej na CRDT. Preskúmame tiež štyri príklady použitia vzorky: počítadlá, distribuované ukladanie do medzipamäte, zdieľané relácie a príjem viacerých oblastí.

Môj zamestnávateľ, Redis Labs, nedávno oznámil podporu CRDT v Redis Enterprise, pričom bezkonfliktné replikované dátové typy sa pripojili k bohatému portfóliu dátových štruktúr - Strings, Hashes, Lists, Sets, Sorted Sets, Bitfields, Geo, Hyperloglog a Streams - v náš databázový produkt. Nasledujúca diskusia sa však netýka iba Redis Enterprise, ale všetkých databáz založených na CRDT.

Databázy pre geodistribuované aplikácie

V prípade geodistribuovaných aplikácií je bežné spúšťať služby lokálne pre klientov. To znižuje sieťový prenos a latenciu spôsobenú spiatočnou cestou. V mnohých prípadoch architekti navrhnú služby na pripojenie k miestnej databáze. Potom nastáva otázka, ako udržiavate konzistentné údaje vo všetkých databázach. Jednou z možností je zvládnuť to na úrovni aplikácie - môžete napísať periodický proces úlohy, ktorý synchronizuje všetky databázy. Alebo sa môžete spoľahnúť na databázu, ktorá bude synchronizovať údaje medzi databázami.

Vo zvyšku článku predpokladáme, že pôjdete s druhou možnosťou - necháme prácu databázy. Ako je znázornené na obrázku 1 nižšie, vaša geograficky distribuovaná aplikácia spúšťa služby vo viacerých regiónoch, pričom každá služba sa pripája k miestnej databáze. Základný systém správy databáz synchronizuje údaje medzi databázami rozmiestnenými v regiónoch.

Redis Labs

Modely konzistencie údajov

Model konzistencie je zmluva medzi distribuovanou databázou a aplikáciou, ktorá definuje, ako čisté sú údaje medzi operáciami zápisu a čítania.

Napríklad v silnom modeli konzistencie databáza zaručuje, že aplikácie vždy prečítajú posledný zápis. Vďaka postupnej konzistencii databáza zaisťuje, že poradie načítaných údajov je konzistentné s poradím, v akom boli zapísané do databázy. V modeli prípadnej konzistencie sľubuje distribuovaná databáza synchronizáciu a konsolidáciu údajov medzi replikami databázy v zákulisí. Preto ak napíšete svoje údaje do jednej repliky databázy a prečítate ich z inej, je možné, že si neprečítate najnovšiu kópiu údajov.

Silná konzistencia

Dvojfázové odovzdanie je bežnou technikou na dosiahnutie silnej konzistencie. Tu pre každú operáciu zápisu (pridanie, aktualizácia, odstránenie) v lokálnom uzle databázy rozšíri uzol databázy zmeny do všetkých uzlov databázy a čaká na potvrdenie všetkých uzlov. Lokálny uzol potom pošle potvrdenie všetkým uzlom a čaká na ďalšie potvrdenie. Aplikácia bude môcť čítať údaje až po druhom potvrdení. Keď sa sieť odpojí medzi databázami, distribuovaná databáza nebude k dispozícii na operácie zápisu.

Prípadná konzistencia

Hlavnou výhodou prípadného modelu konzistencie je, že databáza bude k dispozícii na vykonávanie operácií zápisu, aj keď sa sieťové pripojenie medzi replikami distribuovanej databázy pokazí. Všeobecne sa tento model vyhýba času obojsmerného potvrdenia dvojfázovým odovzdaním, a preto podporuje oveľa viac operácií zápisu za sekundu ako ostatné modely. Jedným z problémov, ktoré musí prípadná konzistencia riešiť, sú konflikty - súčasné zápisy na rovnakú položku na dvoch rôznych miestach. Na základe toho, ako sa vyhýbajú alebo riešia konflikty, sa nakoniec konzistentné databázy ďalej klasifikujú do nasledujúcich kategórií:

  1. Vyhráva posledný autor (LWW). V tejto stratégii sa distribuované databázy spoliehajú na synchronizáciu časovej značky medzi servermi. Databázy si vymieňajú časovú značku každej operácie zápisu spolu s údajmi samotnými. V prípade konfliktu vyhráva operácia zápisu s najnovšou časovou značkou.

    Nevýhodou tejto techniky je, že predpokladá synchronizáciu všetkých systémových hodín. V praxi je ťažké a nákladné synchronizovať všetky hodiny systému.

  2. Prípadná konzistencia založená na kvóre: Táto technika je podobná dvojfázovému odovzdaniu. Lokálna databáza však nečaká na potvrdenie zo všetkých databáz; len čaká na potvrdenie od väčšiny databáz. Uznesenie väčšiny predstavuje uznášaniaschopnosť. Ak dôjde ku konfliktu, vyhrá operácia zápisu, ktorá ustanovila kvórum.

    Na druhú stranu, táto technika pridáva k operáciám zápisu latenciu siete, čo robí aplikáciu menej škálovateľnou. Lokálna databáza nebude k dispozícii pre zápisy, ak sa izoluje od ostatných replík databázy v topológii.

  3. Zlúčiť replikáciu: V tomto tradičnom prístupe, ktorý je bežný v relačných databázach, centralizuje agent hromadnej fúzie všetky údaje. Táto metóda tiež ponúka určitú flexibilitu pri implementácii vašich vlastných pravidiel na riešenie konfliktov.

    Zlúčenie replikácie je príliš pomalé na to, aby podporilo pútavé aplikácie v reálnom čase. Má tiež jediný bod zlyhania. Pretože táto metóda nepodporuje prednastavené pravidlá riešenia konfliktov, vedie často k chybovým implementáciám riešenia konfliktov.

  4. Bezkonfliktný replikovaný dátový typ (CRDT): Podrobne sa o CRDT dozviete v nasledujúcich častiach. Stručne povedané, databázy založené na CRDT podporujú dátové typy a operácie, ktoré poskytujú prípadnú konzistenciu bez konfliktov. Databázy založené na CRDT sú k dispozícii, aj keď repliky distribuovanej databázy nemôžu vymieňať údaje. Pri operáciách čítania a zápisu vždy dodajú lokálnu latenciu.

    Obmedzenia? Nie všetky prípady použitia databázy majú úžitok z CRDT. Sémantika riešenia konfliktov pre databázy založené na CRDT je ​​tiež preddefinovaná a nemožno ich prepísať.

Čo sú CRDT?

CRDT sú špeciálne dátové typy, ktoré konvergujú údaje zo všetkých replík databáz. Populárne CRDT sú G-počítadlá (počítadlá iba pre rast), počítadlá PN (pozitívne-negatívne počítadlá), registre, G-množiny (množiny iba pre rast), súpravy 2P (dvojfázové súpravy), OR-súpravy ( pozorované-odstrániť množiny) atď. V zákulisí sa konvergujú údaje spoliehajú na nasledujúce matematické vlastnosti:

  1. Komutatívna vlastnosť: a ☆ b = b ☆ a
  2. Asociačný majetok: a ☆ (b ☆ c) = (a ☆ b) ☆ c
  3. Idempotencia: a ☆ a = a

Počítadlo G je dokonalým príkladom funkčného CRDT, ktorý spája operácie. Tu platí, že a + b = b + a a + (b + c) = (a + b) + c. Repliky si navzájom vymieňajú iba aktualizácie (doplnky). CRDT zlúči aktualizácie ich sčítaním. Sada G napríklad používa na zlúčenie všetkých prvkov idempotenciu ({a, b, c} U {c} = {a, b, c}). Idempotencia zabráni duplikácii prvkov pridaných do dátovej štruktúry pri ich cestovaní a konvergovaní rôznymi cestami.

Dátové typy CRDT a ich sémantika riešenia konfliktov

Konfliktné dátové štruktúry: G-počítadlá, PN-počítadlá, G-množiny

Všetky tieto dátové štruktúry sú zámerne bezkonfliktné. Tabuľky nižšie ukazujú, ako sa synchronizujú údaje medzi replikami databázy.

Redis Labs Redis Labs

Počítadlá G a počitadlá PN sú populárne pre prípady použitia, ako je globálny prieskum, počty streamov, sledovanie aktivity atď. G-sady sa intenzívne používajú na implementáciu technológie blockchain. Napríklad bitcoiny využívajú blockchainové záznamy iba s pripojením.

Registre: Struny, Hashes

Registre nie sú svojou povahou bezproblémové. Spravidla sa riadia zásadami riešenia konfliktov na základe LWW alebo kvóra. Obrázok 4 zobrazuje príklad toho, ako register rieši konflikt dodržiavaním politiky LWW.

Redis Labs

Registre sa používajú hlavne na ukladanie údajov do pamäte cache a relácií, informácií o užívateľských profiloch, katalógu produktov atď.

2P-sady

Dvojfázové súpravy udržiavajú dve sady súprav G - jednu pre pridané položky a druhú pre odstránené položky. Repliky si pri synchronizácii vymieňajú doplnky G-sady. Konflikt nastáva, keď sa v oboch množinách nachádza rovnaký prvok. V niektorých databázach založených na CRDT, ako je napríklad Redis Enterprise, sa to riadi zásadou „Pridať, vyhrať nad odstránením.“

Redis Labs

Sada 2P je dobrá dátová štruktúra na ukladanie údajov zdieľaných relácií, ako sú nákupné košíky, zdieľaný dokument alebo tabuľka.

Ako zostaviť aplikáciu tak, aby používala databázu založenú na CRDT

Pripojenie vašej aplikácie k databáze založenej na CRDT sa nelíši od pripojenia vašej aplikácie k akejkoľvek inej databáze. Kvôli politike prípadnej konzistencie však musí vaša aplikácia dodržiavať určitú skupinu pravidiel, aby poskytovala konzistentné používateľské prostredie. Tri kľúče: 

  1. Urobte svoju žiadosť bez štátnej príslušnosti. Bezstavová aplikácia je zvyčajne riadená pomocou API. Výsledkom každého volania API je úplná správa od začiatku. Takto je zaistené, že vždy a kedykoľvek vytiahnete čistú kópiu údajov. Nízka lokálna latencia, ktorú ponúka databáza založená na CRDT, umožňuje rýchlejšiu a ľahšiu rekonštrukciu správ. 

  2. Vyberte správny CRDT, ktorý vyhovuje vášmu prípadu použitia. Počítadlo je najjednoduchší z CRDT. Môže sa použiť na prípady použitia, ako je globálne hlasovanie, sledovanie aktívnych relácií, meranie atď. Ak však chcete zlúčiť stav distribuovaných objektov, musíte brať do úvahy aj ďalšie dátové štruktúry. Napríklad pre aplikáciu, ktorá umožňuje používateľom upravovať zdieľaný dokument, možno budete chcieť zachovať nielen úpravy, ale aj poradie, v akom boli vykonané. V takom prípade by bolo uloženie úprav do zoznamu založeného na CRDT alebo do dátovej štruktúry frontu lepším riešením ako ich uloženie do registra. Je tiež dôležité, aby ste pochopili sémantiku riešenia konfliktov vynútenú CRDT a aby vaše riešenie bolo v súlade s pravidlami.
  3. CRDT nie je univerzálne riešenie. Aj keď je CRDT skutočne skvelým nástrojom pre mnoho prípadov použitia, nemusí byť najlepší pre všetky prípady použitia (napríklad transakcie s kyselinami). Databázy založené na CRDT sa všeobecne dobre hodia k architektúre mikroslužieb, kde máte vyhradenú databázu pre každú mikroslužbu.

Hlavným riešením je, že by sa vaša aplikácia mala sústrediť na logiku a delegovať zložitosť správy a synchronizácie údajov na základnú databázu.

Testovanie aplikácií s distribuovanou databázou viacerých vzorov

Ak chcete dosiahnuť rýchlejší prechod na trh, odporúčame vám neustále vývojové, testovacie, fázové a výrobné nastavenie. To okrem iného znamená, že vaše vývojové a testovacie nastavenie musí mať miniaturizovaný model vašej distribuovanej databázy. Skontrolujte, či je vaša databáza založená na CRDT k dispozícii ako kontajner Docker alebo ako virtuálne zariadenie. Umiestnite svoje databázové repliky do rôznych podsietí, aby ste mohli simulovať nastavenie pripojeného a odpojeného klastra.

Testovanie aplikácií s distribuovanou databázou viacerých vzorov môže znieť zložito. Väčšinu času však budete testovať iba konzistenciu údajov a dostupnosť aplikácií v dvoch situáciách: keď sú distribuované databázy pripojené a keď je medzi databázami sieťový oddiel.

Nastavením distribuovanej databázy s tromi uzlami vo vašom vývojovom prostredí môžete pokryť (a dokonca aj automatizovať) väčšinu testovacích scenárov pri testovaní jednotiek. Tu sú základné pokyny pre testovanie vašich aplikácií:

$config[zx-auto] not found$config[zx-overlay] not found