Consistentieniveaus in Azure Cosmos DB

VAN TOEPASSING OP: SQL-API Cassandra-API Gremlin-API Table-API Azure Cosmos DB-API voor MongoDB

Gedistribueerde databases die afhankelijk zijn van replicatie voor hoge beschikbaarheid, lage latentie of beide, moeten een fundamentele afweging maken tussen de leesconsistentie, beschikbaarheid, latentie en doorvoer, zoals gedefinieerd door het PACELC-theorema. De linearisatie van het model voor sterke consistentie is de goudkleurige standaard voor programmeerbaarheid van gegevens. Maar het voegt een hoge prijs toe vanwege hogere schrijflatentie omdat gegevens over grote afstanden moeten worden gerepliceerd en commit. Sterke consistentie kan ook last hebben van verminderde beschikbaarheid (tijdens storingen), omdat gegevens niet in elke regio kunnen worden gerepliceerd en commit. Uiteindelijke consistentie biedt hogere beschikbaarheid en betere prestaties, maar het is moeilijker om toepassingen te programmeren, omdat gegevens mogelijk niet volledig consistent zijn in alle regio's.

De meeste commercieel beschikbare gedistribueerde NoSQL-databases die momenteel beschikbaar zijn in de markt, bieden alleen sterke en uiteindelijke consistentie. Azure Cosmos DB biedt vijf goed gedefinieerde niveaus. Van het sterkste tot het zwakste niveau zijn:

• Sterk
• Gebonden veroudering
• Sessie
• Consistent voorvoegsel
• Uiteindelijk

Elk niveau biedt een afweging tussen beschikbaarheid en prestaties. In de volgende afbeelding ziet u de verschillende consistentieniveaus als een spectrum.

De consistentieniveaus zijn regio-agnostisch en worden gegarandeerd voor alle bewerkingen, ongeacht de regio van waaruit de lees- en schrijfbewerkingen worden uitgevoerd, het aantal regio's dat is gekoppeld aan uw Azure Cosmos-account of of uw account is geconfigureerd met één of meerdere schrijfregio's.

Consistentieniveaus en Azure Cosmos DB-API's

Azure Cosmos DB biedt systeemeigen ondersteuning voor wire-protocol compatibele API's voor populaire databases. Dit zijn onder andere MongoDB, Apache Cassandra, Gremlin en Azure Table Storage. Wanneer u de Gremlin-API en Table-API, wordt het standaardconsistentieniveau gebruikt dat is geconfigureerd voor het Azure Cosmos-account. Zie Cassandra-API consistency mapping and API for MongoDB consistency mapping(Toewijzing van consistentie en API voor MongoDB-consistentietoewijzing) voor meer informatie over de toewijzing van consistentieniveaus tussen Cassandra-API of de API voor MongoDB en de consistentieniveaus van Azure Cosmos DB.

Bereik van de leesconsistentie

Leesconsistentie is van toepassing op één leesbewerking binnen een logische partitie. De leesbewerking kan worden uitgegeven door een externe client of een opgeslagen procedure.

Het standaardconsistentieniveau configureren

U kunt op elk moment het standaardconsistentieniveau voor uw Azure Cosmos-account configureren. Het standaardconsistentieniveau dat voor uw account is geconfigureerd, is van toepassing op alle Azure Cosmos-databases en -containers onder dat account. Alle lees- en query's die zijn uitgegeven voor een container of database gebruiken standaard het opgegeven consistentieniveau. Zie Het standaardconsistentieniveau configureren voor meer informatie. U kunt ook het standaardconsistentieniveau voor een specifieke aanvraag overschrijven. Zie het artikel Override the default consistency level (Het standaardconsistentieniveau overschrijven) voor meer informatie.

Garanties die zijn gekoppeld aan consistentieniveaus

Azure Cosmos DB garandeert dat 100 procent van de leesaanvragen voldoet aan de consistentiegarantie voor het gekozen consistentieniveau. De precieze definities van de vijf consistentieniveaus in Azure Cosmos DB met behulp van de taal van de TLA+-specificatie worden opgegeven in de azure-cosmos-tla-GitHub-repo.

De semantiek van de vijf consistentieniveaus wordt beschreven in de volgende secties.

Consistentie Sterk

Sterke consistentie biedt garantie op linearisabiliteit. Linearizability verwijst naar het gelijktijdig verwerken van aanvragen. De leesitem retourneert gegarandeerd de meest recente vastgelegde versie van een item. Een client ziet nooit een niet-doorgestuurde of gedeeltelijke schrijf- of schrijfbestand. Gebruikers kunnen altijd gegarandeerd de meest recente vastgelegde schrijf lezen.

In de volgende afbeelding ziet u de sterke consistentie met notities. Nadat de gegevens naar de regio VS - west 2 zijn geschreven en u de gegevens uit andere regio's leest, krijgt u de meest recente waarde:

Consistentie Gebonden veroudering

Bij de consistentie Gebonden veroudering worden de lees lezen gegarandeerd conform de garantie voor consistent voorvoegsel. De lees- of schrijfitem kan een vertraging hebben op schrijfingen van ten hoogste 'K'-versies (dat wil zeggen 'updates') van een item of door het tijdsinterval 'T', wat het eerst wordt bereikt. Met andere woorden, wanneer u gebonden veroudering kiest, kan de 'veroudering' op twee manieren worden geconfigureerd:

• Het aantal versies (K) van het item
• Het tijdsinterval (T) kan achterlopen op de schrijf schrijfingen

Voor één regioaccount is de minimumwaarde van K en T 10 schrijfbewerkingen of 5 seconden. Voor accounts voor meerdere regio's is de minimumwaarde K en T 100.000 schrijfbewerkingen of 300 seconden.

Gebonden veroudering biedt de totale globale bestelling buiten het 'verouderingsvenster'. Wanneer een client leesbewerkingen uitvoert binnen een regio die schrijfbewerkingen accepteert, zijn de garanties die worden geboden door de consistentie Gebonden veroudering identiek aan die garanties door de sterke consistentie. Naarmate het verouderingsvenster nadert voor tijd of updates, wordt de nieuwe schrijftijd beperkt door de service, zodat replicatie de consistentiegarantie kan inhalen.

In het venster veroudering biedt Gebonden veroudering de volgende consistentiegaranties:

• Consistentie voor clients in dezelfde regio voor een account met één schrijfregio = Sterk

• Consistentie voor clients in verschillende regio's voor een account met één schrijfregio = consistent voorvoegsel

• Consistentie voor clients die naar één regio schrijven voor een account met meerdere schrijfregio's = Consistent voorvoegsel

• Consistentie voor clients die naar verschillende regio's schrijven voor een account met meerdere schrijfregio's = Mogelijk

  Gebonden veroudering wordt vaak gekozen door wereldwijd gedistribueerde toepassingen die lage schrijflatentie verwachten, maar een garantie voor de totale globale volgorde vereisen. Gebonden veroudering is zeer goed voor toepassingen met groepssamenwerking en -delen, ticker voor voorraad, publiceren-abonneren/in de wachtrij, enzovoort. In de volgende afbeelding ziet u de consistentie gebonden veroudering met notities. Nadat de gegevens naar de regio VS - west 2 zijn geschreven, lezen de regio's VS - oost 2 en Australië - oost de geschreven waarde op basis van de geconfigureerde maximale vertragingstijd of de maximale bewerkingen:

  

Consistentie Sessie

In sessieconsistentie worden binnen één clientsessie gegarandeerd de garanties voor consistent voorvoegsel, monotone lees- en monotone schrijf- en schrijfvolgers gegarandeerd. Dit gaat uit van één schrijfsessie of het delen van het sessie-token voor meerdere schrijvers.

Clients buiten de sessie die schrijfingen uitvoeren, zien de volgende garanties:

• Consistentie voor clients in dezelfde regio voor een account met één schrijfregio = consistent voorvoegsel

• Consistentie voor clients in verschillende regio's voor een account met één schrijfregio = consistent voorvoegsel

• Consistentie voor clients die naar één regio schrijven voor een account met meerdere schrijfregio's = Consistent voorvoegsel

• Consistentie voor clients die naar meerdere regio's schrijven voor een account met meerdere schrijfregio's = Mogelijk

• Consistentie voor clients die gebruikmaken van de Azure Cosmos DB geïntegreerde cache = Uiteindelijk

  Sessieconsistentie is het meest gebruikte consistentieniveau voor zowel één regio als wereldwijd gedistribueerde toepassingen. Het biedt schrijflatentie, beschikbaarheid en leesdoorvoer die vergelijkbaar zijn met die van uiteindelijke consistentie, maar biedt ook de consistentiegaranties die geschikt zijn voor de behoeften van toepassingen die zijn geschreven om te worden gebruikt in de context van een gebruiker. In de volgende afbeelding ziet u de consistentie van de sessie met notities. De schrijver vs - west 2 en de lezer van VS - west 2 gebruiken dezelfde sessie (sessie A), zodat ze beide dezelfde gegevens op hetzelfde moment lezen. Waar de regio Australië - oost 'sessie B' gebruikt, ontvangt deze later gegevens, maar in dezelfde volgorde als de schrijfgegevens.

  

Consistent Consistent voorvoegsel

Bij de optie consistent voorvoegsel bevatten geretourneerde updates een voorvoegsel van alle updates, zonder hiaten. Consistent consistentieniveau voor voorvoegsels garandeert dat lees- en schrijf schrijfsels nooit out-of-order worden gelezen.

Als schrijfingen in de volgorde zijn uitgevoerd, ziet een client ofwel , of , maar nooit A, B, C A A,B A,B,C out-of-order-permutaties zoals A,C of B,A,C . Consistent voorvoegsel biedt schrijflatentie, beschikbaarheid en leesdoorvoer die vergelijkbaar zijn met die van uiteindelijke consistentie, maar biedt ook de volgordegaranties die aansluiten op de behoeften van scenario's waarin volgorde belangrijk is.

Hieronder vindt u de consistentiegaranties voor consistent voorvoegsel:

• Consistentie voor clients in dezelfde regio voor een account met één schrijfregio = consistent voorvoegsel
• Consistentie voor clients in verschillende regio's voor een account met één schrijfregio = consistent voorvoegsel
• Consistentie voor clients die naar één regio schrijven voor een account met meerdere schrijfregio =Consistent voorvoegsel
• Consistentie voor clients die naar meerdere regio's schrijven voor een account met meerdere schrijfregio's = Mogelijk

In de volgende afbeelding ziet u de consistentie voorvoegselconsistentie met notities over de consistentie. In alle regio's zien de lees-en-lees-tekst nooit schrijf-outs:

Consistentie Uiteindelijk

In uiteindelijke consistentie is er geen garantie voor het orden van lees lezen. Als er verder geen schrijfbewerkingen worden uitgevoerd, convergeren de replica's uiteindelijk.
Uiteindelijke consistentie is de zwakste vorm van consistentie omdat een client de waarden kan lezen die ouder zijn dan de waarden die eerder zijn gelezen. Uiteindelijke consistentie is ideaal als de toepassing geen garanties voor orden vereist. Voorbeelden hiervan zijn het aantal retweets, vind-ik-leuks of niet-threaded opmerkingen. In de volgende afbeelding ziet u de uiteindelijke consistentie met notities.

Consistentiegaranties in de praktijk

In de praktijk krijgt u vaak betere consistentiegaranties. Consistentiegaranties voor een leesbewerking komen overeen met de nieuwheid en volgorde van de databasetoestand die u aanvraagt. Leesconsistentie is gekoppeld aan het orden en doorgeven van de schrijf-/updatebewerkingen.

Als er geen schrijfbewerkingen op de database zijn, levert een leesbewerking met uiteindelijke consistentieniveaus, sessies of consistente voorvoegsels waarschijnlijk dezelfde resultaten op als een leesbewerking met een sterk consistentieniveau.

Als uw Azure Cosmos-account is geconfigureerd met een ander consistentieniveau dan de sterke consistentie, kunt u de waarschijnlijkheid ontdekken dat uw clients sterke en consistente leesgegevens voor uw workloads kunnen krijgen door te kijken naar de probabilistische metrische gegevens van Bounded Staleness (PBS). Deze metrische gegevens worden in de Azure Portal. Zie Monitor Probabilistically Bounded Staleness (PBS) metriek voor meer informatie.

Probabilistisch gebonden veroudering laat zien hoe mogelijk uw uiteindelijke consistentie is. Deze metrische gegevens geven inzicht in hoe vaak u een sterkere consistentie kunt krijgen dan het consistentieniveau dat u momenteel hebt geconfigureerd voor uw Azure Cosmos-account. Met andere woorden, u kunt de waarschijnlijkheid (gemeten in milliseconden) zien van het verkrijgen van sterk consistente lees- en leesregio's voor een combinatie van schrijf- en leesregio's.

Consistentieniveaus en latentie

De leeslatentie voor alle consistentieniveaus is altijd gegarandeerd minder dan 10 milliseconden op het 99e percentiel. De gemiddelde leeslatentie bij het 50e percentiel is doorgaans 4 milliseconden of minder.

De schrijflatentie voor alle consistentieniveaus is altijd gegarandeerd minder dan 10 milliseconden in het 99e percentiel. De gemiddelde schrijflatentie, in het 50e percentiel, is meestal 5 milliseconden of minder. Azure Cosmos-accounts die meerdere regio's bespannen en zijn geconfigureerd met sterke consistentie vormen een uitzondering op deze garantie.

Schrijflatentie en sterke consistentie

Voor Azure Cosmos-accounts die zijn geconfigureerd met een sterke consistentie met meer dan één regio, is de schrijflatentie gelijk aan twee keer de retourtijd (RTT) tussen een van de twee verste regio's, plus 10 milliseconden in het 99e percentiel. Hoge netwerk-RTT tussen de regio's leidt tot een hogere latentie voor Cosmos DB-aanvragen, omdat een bewerking met sterke consistentie pas wordt voltooid nadat deze is vastgelegd in alle regio's binnen een account.

De exacte RTT-latentie is een functie van de snelheid van de lichte afstand en de Azure-netwerktopologie. Azure-netwerken bieden geen latentie-SLA's voor de RTT tussen twee Azure-regio's, maar het publiceert wel statistieken over retourlatentie in het Azure-netwerk. Voor uw Azure Cosmos-account worden replicatielatenties weergegeven in de Azure Portal. U kunt de Azure Portal gebruiken (ga naar de blade Metrische gegevens, selecteer het tabblad Consistentie) om de replicatielatentie te bewaken tussen verschillende regio's die zijn gekoppeld aan uw Azure Cosmos-account.

Consistentieniveaus en doorvoer

• Voor sterke en gebonden veroudering worden lees leesingen uitgevoerd op twee replica's in een vier replicaset (quorum voor het quorum) om consistentiegaranties te bieden. Sessie, consistent voorvoegsel en uiteindelijke leesbare replica's. Het resultaat is dat voor hetzelfde aantal aanvraageenheden de leesdoorvoer voor sterk en gebonden veroudering de helft is van de andere consistentieniveaus.

• Voor een bepaald type schrijfbewerking, zoals invoegen, vervangen, upsert en verwijderen, is de schrijfdoorvoer voor aanvraageenheden identiek voor alle consistentieniveaus. Voor een sterke consistentie moeten wijzigingen worden doorgevoerd in elke regio (globale meerderheid), terwijl voor alle andere consistentieniveaus de lokale meerderheid (drie replica's in een vier replicaset) wordt gebruikt.

Consistentieniveaus en duurzaamheid van gegevens

Binnen een wereldwijd gedistribueerde databaseomgeving is er een rechtstreekse relatie tussen het consistentieniveau en de duurzaamheid van gegevens in de aanwezigheid van een storing in de hele regio. Bij het ontwikkelen van uw plan voor bedrijfscontinuïteit moet u weten wat de maximale periode van recente gegevensupdates is die de toepassing kan tolereren bij het herstellen na een verstorende gebeurtenis. De periode van updates die u mogelijk verliest, wordt herstelpuntdoelstelling (RPO) genoemd.

De onderstaande tabel definieert de relatie tussen het consistentiemodel en de duurzaamheid van gegevens in de aanwezigheid van een storing in de hele regio.

K = het aantal K-versies (dat wil zeggen updates) van een item.

T = het tijdsinterval 'T' sinds de laatste update.

Voor één regioaccount is de minimumwaarde van K en T 10 schrijfbewerkingen of 5 seconden. Voor accounts voor meerdere regio's is de minimale waarde van K en T 100.000 schrijfbewerkingen of 300 seconden. Hiermee definieert u de minimale RPO voor gegevens bij gebruik van Gebonden veroudering.

Sterke consistentie en meerdere schrijfregio's

Cosmos-accounts die zijn geconfigureerd met meerdere schrijfregio's kunnen niet worden geconfigureerd voor sterke consistentie, omdat het niet mogelijk is voor een gedistribueerd systeem om een RPO van nul en een RTO van nul te bieden. Bovendien zijn er geen voordelen voor schrijflatentie bij het gebruik van sterke consistentie met meerdere schrijfregio's, omdat een schrijf naar een regio moet worden gerepliceerd en moet worden vastgelegd in alle geconfigureerde regio's binnen het account. Dit resulteert in dezelfde schrijflatentie als één schrijfregioaccount.

Meer artikelen

Lees de volgende artikelen voor meer informatie over consistentieconcepten:

• TLA+-specificaties op hoog niveau voor de vijf consistentieniveaus die door de Azure Cosmos DB
• Gegevensconsistentie gerepliceerd, uitgelegd via het amerikaanse voetbalteam (video) door Doug Clip
• Gegevensconsistentie gerepliceerd, uitgelegd via het whitepaper (whitepaper) van Doug
• Sessiegaranties voor zwak consistente gerepliceerde gegevens
• Consistentie-afwegingen in modern ontwerp van gedistribueerde databasesystemen: CAP is slechts een deel van het verhaal
• Probabilistic Bounded Verouderingess (PBS) voor praktische gedeeltelijke quorums
• Uiteindelijk consistent - opnieuw bezocht

Volgende stappen

Lees de volgende artikelen voor meer informatie over consistentieniveaus in Azure Cosmos DB:

• Het standaardconsistentieniveau configureren
• Het standaardconsistentieniveau overschrijven
• Azure Cosmos DB SLA