Konzisztenciaszintek az Azure Cosmos DB-ben
A KÖVETKEZŐKRE VONATKOZIK: 
Nosql MongoDB Cassandra Gremlin Táblázat
A magas rendelkezésre állás, alacsony késés vagy mindkettő replikációjára támaszkodó elosztott adatbázisoknak alapvető kompromisszumot kell hozniuk a PACELC-tétel által meghatározott olvasási konzisztencia, rendelkezésre állás, késés és átviteli sebesség között. Az erős konzisztenciamodell linearizitása az adatprogramozhatóság arany szabványa. Ez azonban meredek árat ad hozzá a magasabb írási késésektől, mivel az adatoknak nagy távolságokra kell replikálniuk és véglegesíteni magukat. Az erős konzisztenciát a rendelkezésre állás csökkenése is okozhatja (a hibák során), mert az adatok nem replikálhatók és nem véglegesítve minden régióban. A végleges konzisztencia magasabb rendelkezésre állást és jobb teljesítményt biztosít, de az alkalmazások programozása nehezebb, mert előfordulhat, hogy az adatok nem minden régióban konzisztensek.
A piacon jelenleg elérhető kereskedelmi forgalomban elérhető elosztott NoSQL-adatbázisok többsége csak erős és végleges konzisztenciát biztosít. Az Azure Cosmos DB öt jól meghatározott szintet kínál. A legerősebbtől a leggyengébbig a szintek a következők:
Az alapértelmezett konzisztenciaszinttel kapcsolatos további információkért lásd az alapértelmezett konzisztenciaszint konfigurálását vagy az alapértelmezett konzisztenciaszint felülbírálását.
Minden szint rendelkezésre állási és teljesítménybeli kompromisszumot biztosít. Az alábbi képen a különböző konzisztenciaszintek láthatók spektrumként.
Konzisztenciaszintek és Azure Cosmos DB API-k
Az Azure Cosmos DB natív támogatást nyújt a vezetékes protokollal kompatibilis API-khoz népszerű adatbázisokhoz. Ezek közé tartozik a MongoDB, az Apache Cassandra, az Apache Gremlin és az Azure Table Storage. A Gremlinhez vagy a Tablehez készült API-ban a rendszer az Azure Cosmos DB-fiókon konfigurált alapértelmezett konzisztenciaszintet használja. Az Apache Cassandra és az Azure Cosmos DB közötti konzisztenciaszint-leképezés részleteiért tekintse meg a Cassandra konzisztencia-leképezési API-t. A MongoDB és az Azure Cosmos DB közötti konzisztenciaszint-leképezés részleteiért lásd a MongoDB-konzisztencia-leképezéshez készült API-t.
Az olvasási konzisztencia hatóköre
Az olvasási konzisztencia egy logikai partíción belül hatókörrel rendelkező egyetlen olvasási műveletre vonatkozik. Egy távoli ügyfél, egy tárolt eljárás vagy egy eseményindító kiadhatja az olvasási műveletet.
Az alapértelmezett konzisztenciaszint beállítása
Az azure Cosmos DB-fiók alapértelmezett konzisztenciaszintje bármikor konfigurálható. A fiókon konfigurált alapértelmezett konzisztenciaszint az adott fiókban lévő összes Azure Cosmos DB-adatbázisra és -tárolóra vonatkozik. A tárolóra vagy adatbázisra vonatkozó összes olvasás és lekérdezés alapértelmezés szerint a megadott konzisztenciaszintet használja. A fiókszintű konzisztencia módosításakor győződjön meg arról, hogy újra üzembe helyezi az alkalmazásokat, és elvégez minden szükséges kódmódosítást a módosítások alkalmazásához. További információkért tekintse meg az alapértelmezett konzisztenciaszint konfigurálását. Egy adott kérés alapértelmezett konzisztenciaszintjének felülbírálásával további információt az alapértelmezett konzisztenciaszint-cikk felülbírálása című cikkben talál.
Tipp.
Az alapértelmezett konzisztenciaszint felülírása csak az SDK-ügyfélen belüli olvasásokra vonatkozik. Az erős konzisztenciára konfigurált fiókok alapértelmezés szerint továbbra is szinkron módon írnak és replikálnak adatokat a fiók minden régiójába. Ha az SDK-ügyfélpéldány vagy -kérés felülbírálja ezt a munkamenettel vagy gyengébb konzisztenciával, az olvasások egyetlen replikával lesznek végrehajtva. További információ: Konzisztenciaszintek és átviteli sebesség.
Fontos
Az alapértelmezett konzisztenciaszint módosítása után újra létre kell hoznia minden SDK-példányt. Ezt az alkalmazás újraindításával teheti meg. Ez biztosítja, hogy az SDK az új alapértelmezett konzisztenciaszintet használja.
Konzisztenciaszintekhez kapcsolódó garanciák
Az Azure Cosmos DB garantálja, hogy az olvasási kérelmek 100%-a megfeleljen a konzisztencia garanciájának a választott konzisztenciaszintre vonatkozóan. Az Azure Cosmos DB öt konzisztenciaszintjének pontos definícióit a TLA+ specifikációs nyelv használatával az azure-cosmos-tla GitHub-adattár tartalmazza.
Az öt konzisztenciaszint szemantikáját a következő szakaszok ismertetik.
Erős konzisztencia
Az erős konzisztencia garantálja a linearizálhatóságot. A linearizability a kérések egyidejű kiszolgálására utal. Az olvasások garantáltan visszaadják az elem legújabb véglegesített verzióját. Az ügyfél soha nem lát nem véglegesített vagy részleges írást. A felhasználók mindig garantáltan elolvassák a legújabb véglegesített írást.
Az alábbi ábra a zenei jegyzetek erős konzisztenciáját szemlélteti. Miután az adatokat az "USA 2. nyugati régiója" régióba írta, az adatok más régiókból való olvasása után a legújabb értéket kapja:
Korlátozott frissesség konzisztenciaszint
A két vagy több régióval rendelkező egyrégiós írási fiókok esetében a rendszer az adatokat az elsődleges régióból az összes másodlagos (írásvédett) régióba replikálja. A két vagy több régióval rendelkező többrégiós írási fiókok esetében a rendszer az eredetileg az összes többi írható régióba írt régióból replikálja az adatokat. Mindkét esetben előfordulhat, hogy az egyik régióból a másikba replikációs késés tapasztalható, bár nem gyakori.
A kötött elavultság konzisztenciájában az adatok két régió közötti késése mindig kisebb, mint egy megadott mennyiség. Az összeg lehet egy elem "K" verziója (vagyis "frissítések") vagy "T" időintervallumok szerint, attól függően, hogy melyik az első. Más szóval, ha a korlátozott elavultságot választja, az adatok maximális "elavultsága" bármely régióban kétféleképpen konfigurálható:
- Az elem verzióinak száma (K)
- Előfordulhat, hogy az időintervallum (T) olvasása elmarad az írástól
A korlátozott elavultság elsősorban a két vagy több régióval rendelkező egyrégiós írási fiókok esetében előnyös. Ha egy régióban (fizikai partíciónként meghatározva) az adatelmaradás meghaladja a konfigurált elavultsági értéket, a rendszer addig szabályozza a partíció írásait, amíg az elavultság vissza nem kerül a konfigurált felső határon belülre.
Egy régiós fiók esetén a kötött elavultság ugyanazokat az írási konzisztencia-garanciákat biztosítja, mint a munkamenet és az végleges konzisztencia. A határolt elavultság esetén az adatok replikálása helyi többségbe (három replika egy négy replikakészletben) történik az egyetlen régióban.
Fontos
A kötött elavultság konzisztenciája miatt az elavultsági ellenőrzések csak régiókon belül, régión belül nem. Egy adott régióban az adatok mindig helyi többségre replikálódnak (négy replikakészlet három replikája) a konzisztenciaszinttől függetlenül.
A Kötött elavultság használata esetén az olvasás az adott régióban elérhető legfrissebb adatokat adja vissza az adott régió két elérhető replikájából való olvasással. Mivel a régión belüli írások mindig helyi többségbe replikálódnak (négy replikából három), két replikával konzultálva a régióban elérhető legfrissebb adatokat adja vissza.
Fontos
A korlátozott elavultság konzisztenciája miatt előfordulhat, hogy a nem elsődleges régióban kiadott olvasások nem feltétlenül adják vissza az adatok legfrissebb verzióját globálisan, de garantáltan az adott régióban az adatok legújabb verzióját adják vissza, amely globálisan a maximális elavultsági határon belül lesz.
A határolt elavultság a legjobban a globálisan elosztott alkalmazásokhoz használható egyrégiós írási fiókokkal két vagy több régióval, ahol a régiók közötti szoros konzisztenciára van szükség. Két vagy több régióval rendelkező többrégiós írási fiókok esetén az alkalmazáskiszolgálóknak az olvasásokat és írásokat ugyanabba a régióba kell irányítaniuk, amelyben az alkalmazáskiszolgálók üzemelnek. A több írási fiókban lévő korlátos elavultság anti-minta. Ehhez a szinthez függőségre lenne szükség a régiók közötti replikációs késéstől, ami nem számít, hogy az adatok ugyanabból a régióból olvasnak-e be adatokat, amelybe írtuk.
Az alábbi ábra a zenei jegyzetekhez kötött elavultsági konzisztenciát mutatja be. Miután az adatok az "USA 2. nyugati régiója" régióba íródtak, az "USA 2. keleti régiója" és a "Kelet-Ausztrália" régió felolvassa az írott értéket a konfigurált maximális késési idő vagy a maximális műveletek alapján:
Munkamenet-konzisztencia
A munkamenet-konzisztenciában egyetlen ügyfél-munkameneten belül az olvasások garantáltan betartják az írási és íráskövetési garanciákat. Ez a garancia egyetlen "írói" munkamenetet feltételez, vagy több író munkamenet-jogkivonatát osztja meg.
Az erősnél gyengébb összes konzisztenciaszinthez hasonlóan az írások a helyi régióban legalább három replikára replikálódnak (négy replikakészletben), aszinkron replikációval az összes többi régióba.
Minden írási művelet után az ügyfél egy frissített munkamenet-jogkivonatot kap a kiszolgálótól. Az ügyfél gyorsítótárazza a jogkivonatokat, és elküldi őket a kiszolgálónak olvasási műveletekhez egy adott régióban. Ha az olvasási művelet alapjául szolgáló replika a megadott jogkivonat (vagy újabb jogkivonat) adatait tartalmazza, a rendszer visszaadja a kért adatokat. Ha a replika nem tartalmaz adatokat az adott munkamenethez, az ügyfél újrapróbálkozza a kérést a régió egy másik replikáján. Szükség esetén az ügyfél újrapróbálkozza az olvasást a további elérhető régiókkal, amíg a megadott munkamenet-jogkivonat adatai le nem kérhetők.
Fontos
A Munkamenet-konzisztencia szolgáltatásban az ügyfél munkamenet-jogkivonatának használata garantálja, hogy a régebbi munkamenetnek megfelelő adatok soha nem lesznek beolvasva. Ha azonban az ügyfél egy régebbi munkamenet-jogkivonatot használ, és újabb frissítések történtek az adatbázison, az adatok újabb verziója lesz visszaadva annak ellenére, hogy egy régebbi munkamenet-jogkivonatot használ. A munkamenet-jogkivonatot a rendszer minimális verziókorlátként használja, de nem az adatbázisból lekérendő adatok adott (esetleg előzmény)verziójaként.
Az Azure Cosmos DB munkamenet-jogkivonatai partícióhoz kötöttek, ami azt jelenti, hogy kizárólag egy partícióhoz vannak társítva. Annak érdekében, hogy biztosan elolvashassa az írásait, használja az adott elem(ek)hez legutóbb létrehozott munkamenet-jogkivonatot.
Ha az ügyfél nem kezdeményezett írást egy fizikai partícióra, az ügyfél nem tartalmaz munkamenet-jogkivonatot a gyorsítótárában, és a fizikai partícióra beolvasott adatok olvasásként viselkednek az Végleges konzisztencia használatával. Hasonlóképpen, ha az ügyfél újra létrejön, a munkamenet-jogkivonatok gyorsítótára is újra létrejön. Itt is az olvasási műveletek ugyanazt a viselkedést követik, mint az Végleges konzisztencia, amíg a későbbi írási műveletek újraépítik az ügyfél munkamenet-jogkivonatok gyorsítótárát.
Fontos
Ha a munkamenet-jogkivonatokat az egyik ügyfélpéldányból a másikba továbbítja, a jogkivonat tartalmát nem szabad módosítani.
A munkamenet-konzisztencia a legszélesebb körben használt konzisztenciaszint mind az egyetlen régióban, mind a globálisan elosztott alkalmazásokban. A végleges konzisztenciaéhoz hasonló írási késéseket, rendelkezésre állást és olvasási átviteli sebességet biztosít. A munkamenet-konzisztencia emellett olyan konzisztenciagaranciákat is biztosít, amelyek megfelelnek a felhasználó kontextusában való működéshez írt alkalmazások igényeinek. Az alábbi ábra a zenei jegyzetek munkamenet-konzisztenciáját szemlélteti. Az "USA 2. nyugati írója" és az "USA 2. keleti régiójának olvasója" ugyanazt a munkamenetet (A. munkamenetet) használja, így mindketten egyszerre olvassák be ugyanazokat az adatokat. Míg a "Kelet-Ausztrália" régió a "B munkamenetet" használja, az adatokat később, de az írások sorrendjében kapja meg.
Konzisztens előtag konzisztenciaszint
Az erősnél gyengébb összes konzisztenciaszinthez hasonlóan az írások a helyi régióban legalább három replikára (négy replikakészletben) replikálódnak, aszinkron replikációval az összes többi régióba.
A konzisztens előtagban az egy dokumentum írása során végrehajtott frissítések a végleges konzisztenciát látják.
Frissítések kötegként egy tranzakción belül, a rendszer konzisztensen adja vissza azt a tranzakciót, amelyben lekötötték őket. A több dokumentumból álló tranzakción belüli írási műveletek mindig együtt láthatók.
Tegyük fel, hogy két írási műveletet hajt végre tranzakciósan (az összes vagy semmi műveletet) a Dokumentum1 dokumentumon, majd a Dokumentum2 dokumentumon, a T1 és a T2 tranzakciókon belül. Amikor az ügyfél olvasást végez bármely replikában, a felhasználó a "Doc1 v1 és Doc2 v1" vagy a "Doc1 v2 és Doc2 v2" szöveget látja, vagy egyik dokumentumot sem, ha a replika nem működik, de a "Doc1 v1 és Doc2 v2" vagy a "Doc1 v2 és Doc2 v1" szöveget nem látja ugyanahhoz az olvasási vagy lekérdezési művelethez.
Az alábbi ábra a zenei jegyzetek konzisztenciájának konzisztenciáját szemlélteti. Az összes régióban az olvasások soha nem látják a tranzakciós írási köteg írásait:
Végleges konzisztencia
Az erősnél gyengébb összes konzisztenciaszinthez hasonlóan az írások a helyi régióban legalább három replikára replikálódnak (négy replikakészletben), aszinkron replikációval az összes többi régióba.
A végleges konzisztencia során az ügyfél olvasási kéréseket ad ki a megadott régióban lévő négy replika bármelyikével szemben. Előfordulhat, hogy ez a replika lemaradásban van, és elavult adatokat ad vissza, vagy nem.
A végleges konzisztencia a konzisztencia leggyengébb formája, mivel az ügyfél elolvashatja a korábbiaknál régebbi értékeket. A végleges konzisztencia akkor jó megoldás, ha az alkalmazásoknak nincs szüksége sorrenddel kapcsolatos biztosítékokra. Ilyenek például a retweetek, a kedvelések vagy a nem szálas megjegyzések száma. Az alábbi ábra a zenei jegyzetek végleges konzisztenciáját szemlélteti.
Konzisztenciagarancia a gyakorlatban
A gyakorlatban gyakran erősebb konzisztenciagaranciát kaphat. Az olvasási műveletek konzisztenciagaranciája megfelel a kért adatbázisállapot frissességének és sorrendjének. Az olvasási konzisztencia az írási/frissítési műveletek sorrendjéhez és propagálásához kapcsolódik.
Ha nincs írási művelet az adatbázison, a végleges, munkamenet vagy konzisztens előtagkonzisztenciaszinttel rendelkező olvasási művelet valószínűleg ugyanazokat az eredményeket fogja eredményezni, mint egy erős konzisztenciaszinttel rendelkező olvasási művelet.
Ha a fiókja konzisztenciaszinttel van konfigurálva az erős konzisztenciaszinten kívül, megtudhatja, hogy az ügyfelek erős és konzisztens olvasást kapnak-e a számítási feladatokhoz. Ezt a valószínűséget a probabilitásilag határolt elavultság (PBS) metrikával állapíthatja meg. Ez a metrika az Azure Portalon érhető el, további információkért lásd : Monitor Probabilistically Bounded Staleness (PBS) metrika.
A valószínűség szerint korlátozott elavultság azt mutatja, hogy milyen végleges a végleges konzisztencia. Ez a metrika bemutatja, hogy milyen gyakran kaphat erősebb konzisztenciát, mint az Azure Cosmos DB-fiókban jelenleg konfigurált konzisztenciaszint. Más szóval látható annak a valószínűsége (ezredmásodpercben mérve), hogy konzisztens olvasást kap az írási és olvasási régiók kombinációjához.
Konzisztenciaszintek és késés
Az összes konzisztenciaszint olvasási késése mindig 10 ezredmásodpercnél kisebb lesz a 99. percentilisnél. Az átlagos olvasási késés az 50. percentilisnél általában 4 ezredmásodperc vagy annál kisebb.
Az összes konzisztenciaszint írási késése mindig 10 ezredmásodpercnél kisebb lesz a 99. percentilisnél. Az átlagos írási késés az 50. percentilisnél általában 5 ezredmásodperc vagy annál kisebb. A garancia alól kivételt képeznek azok az Azure Cosmos DB-fiókok, amelyek több régióra is kiterjednek, és erős konzisztenciával vannak konfigurálva.
Írási késés és erős konzisztencia
Egynél több régióval erős konzisztenciával konfigurált Azure Cosmos DB-fiókok esetében az írási késés a két legtávolabbi régió között kétszeri menetidőnek (RTT) felel meg, valamint 10 ezredmásodperc a 99. percentilisnél. A régiók közötti magas hálózati RTT nagyobb késést fog eredményezni az Azure Cosmos DB-kérések esetében, mivel az erős konzisztencia csak azt követően fejez be egy műveletet, hogy meggyőződik arról, hogy egy fiók összes régiója számára elkötelezte magát.
A pontos RTT-késés a fénysebesség és az Azure hálózati topológiájának függvénye. Az Azure-hálózatkezelés nem biztosít késési SLA-kat az RTT-hez két Azure-régió között, azonban közzéteszi az Azure-beli hálózati késési statisztikákat. Az Azure Cosmos DB-fiók esetében a replikáció késései megjelennek az Azure Portalon. Az Azure Portalt a Metrikák szakaszra lépve, majd a Konzisztencia lehetőség kiválasztásával használhatja. Az Azure Portal használatával figyelheti az Azure Cosmos DB-fiókhoz társított különböző régiók közötti replikációs késéseket.
Fontos
A fiókok erős konzisztenciája az 5000 mérföldnél (8000 kilométernél) hosszabb régiókkal alapértelmezés szerint le van tiltva a magas írási késés miatt. A funkció engedélyezéséhez forduljon az ügyfélszolgálathoz.
Konzisztenciaszintek és átviteli sebesség
Az erős és korlátozott elavultság érdekében az olvasások négy replikakészlet két replikáján (kisebbségi kvórum) történik a konzisztencia garanciáinak biztosítása érdekében. Munkamenet, konzisztens előtag és végül egyetlen replika olvasása. Ennek az az eredménye, hogy ugyanannak a kérelemegységnek az olvasási sebessége az erős és a határos elavultság esetén a többi konzisztenciaszint fele.
Egy adott típusú írási művelet, például beszúrás, csere, upsert és delete esetében a kérelemegységek írási átviteli sebessége minden konzisztenciaszint esetében azonos. Az erős konzisztencia érdekében a módosításokat minden régióban (globális többségben) véglegesíteni kell, míg az összes többi konzisztenciaszint esetében helyi többséget (négy replikakészlet három replikáját) használnak.
| Konzisztenciaszint | Kvórumolvasások | Kvórum írásai |
|---|---|---|
| Erős | Helyi kisebbség | Globális többség |
| Korlátozott elavultság | Helyi kisebbség | Helyi többség |
| Munkamenet | Egyetlen replika (munkamenet-jogkivonat használatával) | Helyi többség |
| Konzisztens előtag | Egyetlen replika | Helyi többség |
| Esetleges | Egyetlen replika | Helyi többség |
Feljegyzés
A helyi kisebbségi olvasások olvasási kérelemegység-költsége kétszerese a gyengébb konzisztenciaszinteknek, mivel az olvasások két replikából készülnek, hogy konzisztenciagaranciát biztosítsanak az erős és a határolt elavultsági konzisztenciaszintekhez.
Konzisztenciaszintek és adatmegőrzés
Egy globálisan elosztott adatbázis-környezetben közvetlen kapcsolat áll fenn a konzisztenciaszint és az adatok tartóssága között régiószintű kimaradás esetén. Az üzletmenet-folytonossági terv kidolgozása során tisztában kell lennie azzal, hogy az alkalmazás a legutóbbi adatfrissítések maximális időtartama alatt milyen veszteségekkel bírhat, amikor egy zavaró esemény után helyreáll. Az esetlegesen elveszítendő frissítések időtartamát helyreállítási pont célkitűzésnek (RPO) nevezzük.
Ez a táblázat a konzisztenciamodell és az adatok tartóssága közötti kapcsolatot határozza meg régiószintű kimaradás esetén.
| Régió(k) | Replikációs mód | Konzisztenciaszint | RPO |
|---|---|---|---|
| 0 | Egy vagy több írási régió | Bármilyen konzisztenciaszint | < 240 perc |
| >1 | Egy írási régió | Munkamenet, Konzisztens előtag, Végleges | < 15 perc |
| >1 | Egy írási régió | Korlátozott frissesség | K > T |
| >1 | Egy írási régió | Erős | 0 |
| >1 | Több írási régió | Munkamenet, Konzisztens előtag, Végleges | < 15 perc |
| >1 | Több írási régió | Korlátozott frissesség | K > T |
K = Egy elem "K" verzióinak (vagyis frissítéseinek) száma.
T = A legutóbbi frissítés óta eltelt "T" időintervallum.
Egyetlen régiófiók esetében a K és a T minimális értéke 10 írási művelet vagy 5 másodperc. Többrégiós fiókok esetén a K és a T minimális értéke 100 000 írási művelet vagy 300 másodperc. Ez az érték határozza meg az adatok minimális RPO-értékét a kötött elavultság használatakor.
Erős konzisztencia és több írási régió
A több írási régióval konfigurált Azure Cosmos DB-fiókok nem konfigurálhatók erős konzisztenciára, mivel egy elosztott rendszer nem tud nulla RPO-t és nulla RTO-t biztosítani. Emellett nincs olyan írási késési előny, amely több írási régióval való erős konzisztenciát használ, mivel a bármely régióba történő írást replikálni kell és le kell kötelezni a fiók összes konfigurált régiójára. Ez a forgatókönyv ugyanolyan írási késést eredményez, mint egyetlen írási régiófiók.
További olvasás
A konzisztenciafogalmakkal kapcsolatos további információkért olvassa el a következő cikkeket:
- Az Azure Cosmos DB által kínált öt konzisztenciaszint magas szintű TLA+ specifikációi
- Doug Terry replikált adatkonzisztencia magyarázata baseballon keresztül (videó)
- Replikált adatkonzisztenciát magyarázta Baseball (tanulmány) Doug Terry
- Munkamenet-garanciák gyengén konzisztens replikált adatokra
- Konzisztencia-kompromisszumok a modern elosztott adatbázisrendszerek tervezésében: a CAP csak része a történetnek
- Probabilistic Bounded Staleness (PBS) a gyakorlati részleges kvórumokhoz
- Végül konzisztens – Újrafelfedezve
Következő lépések
Az Azure Cosmos DB konzisztenciaszintjeiről az alábbi cikkekben olvashat bővebben: