Ohjelmointi

Milloin käyttää CRDT-pohjaista tietokantaa

Roshan Kumar on Redis Labsin vanhempi tuotepäällikkö.

YMP: n lauseessa kuvatun yhtenäisyyden ja käytettävyyden taivuttaminen on ollut suuri haaste maantieteellisesti hajautettujen sovellusten arkkitehdeille. Verkko-osio on väistämätön. Suuri viive datakeskusten välillä johtaa aina jonkin verran yhteyden katkaisemiseen palvelinkeskusten välillä lyhyeksi ajaksi. Siten maantieteellisesti hajautettujen sovellusten perinteiset arkkitehtuurit on suunniteltu joko luopumaan tietojen johdonmukaisuudesta tai ottamaan osuma saatavuudesta.

Valitettavasti sinulla ei ole varaa uhrata saatavuutta interaktiivisiin käyttäjäsovelluksiin. Viime aikoina arkkitehdit ovat ottaneet kuvan yhtenäisyydestä ja omaksuneet lopullisen johdonmukaisuusmallin. Tässä mallissa sovellukset riippuvat tietokannan hallintajärjestelmästä yhdistämään kaikki paikalliset kopiot tiedoista, jotta ne olisivat lopulta yhdenmukaisia.

Kaikki näyttää hyvältä mahdollisen johdonmukaisuusmallin kanssa, kunnes tietoristiriitoja esiintyy. Muutamat mahdolliset johdonmukaisuusmallit lupaavat parhaansa korjata konfliktit, mutta eivät takaa vahvaa johdonmukaisuutta. Hyvä uutinen on, että konfliktittomien replikoitujen tietotyyppien (CRDT) ympärille rakennetut mallit tarjoavat lopulta vahvan yhdenmukaisuuden.

CRDT: t saavuttavat vahvan lopullisen johdonmukaisuuden ennalta määrätyn konfliktinratkaisusääntöjen ja semantiikan avulla. CRDT-pohjaisten tietokantojen päälle rakennetut sovellukset on suunniteltava vastaamaan konfliktinratkaisun semantiikkaa. Tässä artikkelissa tutkitaan, miten suunnitellaan, kehitetään ja testataan maantieteellisesti hajautettuja sovelluksia CRDT-pohjaisen tietokannan avulla. Tutkimme myös neljää esimerkkitapaustapaa: laskurit, hajautettu välimuisti, jaetut istunnot ja monialueiden tietojen kulutus.

Työnantajani, Redis Labs, ilmoitti äskettäin CRDT-tuesta Redis Enterprise -yrityksessä, ja konfliktittomat replikoidut tietotyypit liittyivät kattavaan tietorakenteiden sarjaan - merkkijonot, hajautukset, luettelot, sarjat, lajitellut joukot, bittikentät, geo, hyperlogogi ja suoratoistot. tietokantatuotteemme. Seuraava keskustelu ei kuitenkaan koske vain Redis Enterprise -yritystä, vaan kaikkia CRDT-pohjaisia ​​tietokantoja.

Geohajautettujen sovellusten tietokannat

Maantieteellisesti hajautetuissa sovelluksissa on tavallista suorittaa paikallisia palveluja asiakkaille. Tämä vähentää verkkoliikennettä ja edestakaisen matkan aiheuttamaa viivettä. Monissa tapauksissa arkkitehdit suunnittelevat palvelut muodostamaan yhteyden paikalliseen tietokantaan. Sitten tulee kysymys siitä, kuinka säilytät yhdenmukaiset tiedot kaikissa tietokannoissa. Yksi vaihtoehto on käsitellä tämä sovellustasolla - voit kirjoittaa säännöllisen työprosessin, joka synkronoi kaikki tietokannat. Tai voit luottaa tietokantaan, joka synkronoi tiedot tietokantojen välillä.

Oletamme, että jatkat artikkelin loppuvaiheessa toista vaihtoehtoa - anna tietokannan tehdä työ. Kuten alla olevassa kuvassa 1 on esitetty, maantieteellisesti hajautettu sovelluksesi suorittaa palveluja useilla alueilla, ja jokainen palvelu muodostaa yhteyden paikalliseen tietokantaan. Taustalla oleva tietokannan hallintajärjestelmä synkronoi tiedot alueiden yli käyttöön otettujen tietokantojen välillä.

Redis Labs

Tietojen johdonmukaisuusmallit

Johdonmukaisuusmalli on hajautetun tietokannan ja sovelluksen välinen sopimus, joka määrittää, kuinka puhtaat tiedot ovat kirjoitus- ja lukutoimintojen välillä.

Esimerkiksi vahvassa yhdenmukaisuusmallissa tietokanta takaa, että sovellukset lukevat aina viimeisen kirjoituksen. Peräkkäisellä yhdenmukaisuudella tietokanta varmistaa, että lukemiesi tietojen järjestys on yhdenmukainen sen kanssa, missä ne on kirjoitettu tietokantaan. Lopullisessa johdonmukaisuusmallissa hajautettu tietokanta lupaa synkronoida ja yhdistää tiedot kulissien takana olevien tietokannan kopioiden välillä. Siksi, jos kirjoitat tietosi yhteen tietokannan kopioon ja luet sen toisesta, on mahdollista, että et lue uusinta kopiota tiedoista.

Vahva sakeus

Kaksivaiheinen sitoutuminen on yleinen tekniikka vahvan johdonmukaisuuden saavuttamiseksi. Tässä jokaisessa paikallisen tietokannan solmun kirjoitusoperaatiossa (lisää, päivitä, poista) tietokannan solmu levittää muutokset kaikkiin tietokannan solmuihin ja odottaa kaikkien solmujen kuittaavan. Paikallinen solmu lähettää sitten sitoutumisen kaikille solmuille ja odottaa uutta kuittausta. Sovellus pystyy lukemaan tietoja vasta toisen sitoutumisen jälkeen. Jaettu tietokanta ei ole käytettävissä kirjoitusoperaatioille, kun verkko katkaisee yhteyden tietokantojen välillä.

Lopulta johdonmukaisuus

Mahdollisen johdonmukaisuusmallin tärkein etu on, että tietokanta on käytettävissäsi kirjoitusoperaatioiden suorittamiseen, vaikka hajautettujen tietokantakopioiden välinen verkkoyhteys hajoaisi. Yleensä tämä malli välttää kaksivaiheisen sitoutumisen edestakaisen lennon ajan ja tukee siksi paljon enemmän kirjoitusoperaatioita sekunnissa kuin muut mallit. Yksi ongelma, johon lopullisen johdonmukaisuuden on puututtava, on ristiriidat - samanaikainen kirjoitus samaan kohteeseen kahdessa eri paikassa. Lopulta yhdenmukaiset tietokannat luokitellaan edelleen seuraaviin luokkiin niiden konfliktien välttämisen tai ratkaisemisen perusteella:

  1. Viimeinen kirjailija voittaa (LWW). Tässä strategiassa hajautetut tietokannat tukeutuvat palvelinten väliseen aikaleiman synkronointiin. Tietokannat vaihtavat kunkin kirjoitusoperaation aikaleiman itse datan kanssa. Jos on ristiriita, viimeisimmällä aikaleimalla varustettu kirjoitusoperaatio voittaa.

    Tämän tekniikan haittana on, että siinä oletetaan, että kaikki järjestelmän kellot on synkronoitu. Käytännössä kaikkien järjestelmäkellojen synkronointi on vaikeaa ja kallista.

  2. Kvoorumiin perustuva mahdollinen johdonmukaisuus: Tämä tekniikka on samanlainen kuin kaksivaiheinen sitoutuminen. Paikallinen tietokanta ei kuitenkaan odota kuittausta kaikista tietokannoista; se vain odottaa kuittausta suurimmasta osasta tietokantoja. Enemmistön kuittaus muodostaa päätösvaltaisuuden. Jos on ristiriita, voiton on kirjoitusoperaatio, jolla on todettu koorumi.

    Kääntöpuolella tämä tekniikka lisää kirjoitusoperaatioihin verkon viiveen, mikä tekee sovelluksesta vähemmän skaalautuvan. Paikallinen tietokanta ei myöskään ole käytettävissä kirjoituksille, jos se eristetään muista topologian tietokantakopioista.

  3. Yhdistä replikointi: Tässä perinteisessä lähestymistavassa, joka on yleistä relaatiotietokantojen keskuudessa, keskitetty yhdistämisagentti yhdistää kaikki tiedot. Tämä menetelmä tarjoaa myös jonkin verran joustavuutta omien sääntöjen toteuttamisessa konfliktien ratkaisemiseksi.

    Yhdistämisreplikointi on liian hidas tukemaan reaaliaikaisia, kiinnostavia sovelluksia. Siinä on myös yksi epäonnistumispiste. Koska tämä menetelmä ei tue ennalta asetettuja sääntöjä konfliktien ratkaisemiseen, se johtaa usein virheellisiin toteutuksiin konfliktien ratkaisemiseksi.

  4. Ristiriitaton kopioitu tietotyyppi (CRDT): Opit CRDT: stä yksityiskohtaisesti seuraavissa osissa. Pähkinänkuoressa CRDT-pohjaiset tietokannat tukevat tietotyyppejä ja toimintoja, jotka mahdollistavat konfliktittoman mahdollisen yhtenäisyyden. CRDT-pohjaiset tietokannat ovat käytettävissä myös silloin, kun jaetut tietokannan kopiot eivät voi vaihtaa tietoja. Ne välittävät aina paikallisen viiveen luku- ja kirjoitusoperaatioihin.

    Rajoitukset? Kaikki tietokannan käyttötapaukset eivät hyödy CRDT: stä. CRDT-pohjaisten tietokantojen konfliktinratkaisun semantiikka on myös ennalta määritelty eikä sitä voida ohittaa.

Mitä ovat CRDT: t?

CRDT: t ovat erityisiä tietotyyppejä, jotka kokoavat tietoja kaikista tietokannan kopioista. Suosittuja CRDT-laitteita ovat G-laskurit (vain kasvavat laskurit), PN-laskurit (positiiviset-negatiiviset laskurit), rekisterit, G-sarjat (vain kasvavat sarjat), 2P-sarjat (kaksivaiheiset sarjat), OR-sarjat ( havaittu-poista sarja) jne. Kulissien takana he luottavat seuraaviin matemaattisiin ominaisuuksiin tietojen lähentämiseksi:

  1. Kommutatiivinen ominaisuus: a ☆ b = b ☆ a
  2. Assosiatiivinen ominaisuus: a ☆ (b ☆ c) = (a ☆ b) ☆ c
  3. Idempotenssi: a ☆ a = a

G-laskuri on täydellinen esimerkki operatiivisesta CRDT: stä, joka yhdistää toiminnot. Tässä a + b = b + a ja a + (b + c) = (a + b) + c. Kopiot vaihtavat vain päivityksiä (lisäyksiä) keskenään. CRDT yhdistää päivitykset lisäämällä ne yhteen. Esimerkiksi G-joukko soveltaa idempotenssia ({a, b, c} U {c} = {a, b, c}) kaikkien elementtien yhdistämiseen. Idempotenssi välttää tietorakenteeseen lisättyjen elementtien päällekkäisyydet, kun ne kulkevat ja lähestyvät eri polkuja.

CRDT-tietotyypit ja niiden konfliktinratkaisun semantiikka

Ristiriitattomat tietorakenteet: G-laskurit, PN-laskurit, G-setit

Kaikki nämä tietorakenteet ovat rakenteeltaan konfliktittomia. Alla olevat taulukot osoittavat, miten tiedot synkronoidaan tietokannan kopioiden välillä.

Redis Labs Redis Labs

G-laskurit ja PN-laskurit ovat suosittuja käyttötapauksissa, kuten yleinen kysely, virtojen laskenta, toiminnan seuranta ja niin edelleen. G-sarjoja käytetään voimakkaasti blockchain-tekniikan toteuttamiseen. Esimerkiksi bitcoinit käyttävät vain liitteenä olevia blockchain-merkintöjä.

Rekisterit: Jouset, Hashes

Rekisterit eivät ole luonteeltaan konfliktittomia. He noudattavat yleensä LWW: n tai koorumipohjaisen konfliktinratkaisun periaatteita. Kuvassa 4 on esimerkki siitä, kuinka rekisteri ratkaisee ristiriidan seuraamalla LWW-käytäntöä.

Redis Labs

Rekisteriä käytetään pääasiassa välimuistin ja istuntotietojen, käyttäjäprofiilitietojen, tuoteluettelon jne. Tallentamiseen.

2P-sarjat

Kaksivaiheisissa sarjoissa on kaksi G-sarjaa - yksi lisätyille ja toinen poistetuille. Kopiot vaihtavat G-joukon lisäyksiä synkronoidessaan. Ristiriita syntyy, kun sama elementti löytyy molemmista sarjoista. Joissakin CRDT-pohjaisissa tietokannoissa, kuten Redis Enterprise, tätä käsittelee käytäntö "Lisää voittaa poiston".

Redis Labs

2P-sarja on hyvä tietorakenne jaettujen istuntotietojen, kuten ostoskorien, jaetun asiakirjan tai laskentataulukon, tallentamiseen.

Kuinka suunnitella sovellus käyttämään CRDT-pohjaista tietokantaa

Sovelluksen yhdistäminen CRDT-pohjaiseen tietokantaan ei eroa sovelluksen yhdistämisestä mihinkään muuhun tietokantaan. Mahdollisten johdonmukaisuuskäytäntöjen vuoksi sovelluksesi on kuitenkin noudatettava tiettyjä sääntöjä yhtenäisen käyttökokemuksen tarjoamiseksi. Kolme avainta: 

  1. Tee hakemuksestasi valtioton. Valtaton sovellus on tyypillisesti API-pohjainen. Jokainen sovellusliittymän kutsu johtaa koko viestin rekonstruoimiseen alusta alkaen. Tämä varmistaa, että vedät aina puhtaan kopion tiedoista milloin tahansa. CRDT-pohjaisen tietokannan tarjoama pieni paikallinen viive tekee viestien rekonstruoinnista nopeampaa ja helpompaa. 

  2. Valitse oikea CRDT, joka sopii käyttötarkoitukseesi. Laskuri on yksinkertaisin CRDT: stä. Sitä voidaan käyttää käyttötapauksissa, kuten yleinen äänestys, aktiivisten istuntojen seuranta, mittaus jne. Jos kuitenkin haluat yhdistää jaettujen objektien tilan, sinun on otettava huomioon myös muut tietorakenteet. Esimerkiksi sovelluksessa, jonka avulla käyttäjät voivat muokata jaettua asiakirjaa, kannattaa säilyttää paitsi muokkaukset myös niiden järjestys. Tällöin muokkausten tallentaminen CRDT-pohjaiseen luetteloon tai jonotietorakenteeseen olisi parempi ratkaisu kuin niiden tallentaminen rekisteriin. On myös tärkeää, että ymmärrät CRDT: n pakottaman konfliktinratkaisun semantiikan ja että ratkaisusi on sääntöjen mukainen.
  3. CRDT ei ole kaikille sopiva ratkaisu. Vaikka CRDT on todellakin loistava työkalu moniin käyttötapauksiin, se ei ehkä ole paras kaikissa käyttötapauksissa (esimerkiksi ACID-tapahtumissa). CRDT-pohjaiset tietokannat sopivat yleensä hyvin mikropalveluarkkitehtuuriin, jossa jokaiselle mikropalvelulle on oma tietokanta.

Tärkein takeaway on, että sovelluksesi tulisi keskittyä logiikkaan ja siirtää tietojen hallinta ja synkronoinnin monimutkaisuus taustalla olevaan tietokantaan.

Sovellusten testaaminen hajautetulla multi-master-tietokannalla

Jotta markkinoille pääsy olisi nopeampaa, suosittelemme, että sinulla on johdonmukainen kehitys, testaus, vaiheistus ja tuotannon määritys. Tämä tarkoittaa muun muassa sitä, että kehitys- ja testausasetuksissasi on oltava hajautetun tietokannan pienoismalli. Tarkista, onko CRDT-pohjainen tietokantasi saatavilla Docker-säilönä tai virtuaalisena laitteena. Asenna tietokannan kopiot eri aliverkkoihin, jotta voit simuloida yhdistettyjä ja irrotettuja klusterin asetuksia.

Sovellusten testaaminen hajautetulla multi-master-tietokannalla saattaa kuulostaa monimutkaiselta. Mutta yleensä testaat vain tietojen yhdenmukaisuutta ja sovellusten saatavuutta kahdessa tilanteessa: Kun hajautetut tietokannat ovat yhteydessä toisiinsa ja kun tietokantojen välillä on verkko-osio.

Perustamalla kolmen solmun hajautettu tietokanta kehitysympäristöön, voit kattaa (ja jopa automatisoida) suurimman osan testaustilanteista yksikötestauksessa. Tässä ovat sovellusten testaamisen perusohjeet:

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