Consistentieniveaus in Azure Cosmos DB

Gedistribueerde databases die afhankelijk zijn van replicatie voor hoge beschikbaarheid, lage latentie of beide moeten de leesconsistentie, beschikbaarheid, latentie en doorvoer verdelen zoals gedefinieerd door de PACELC-theorema. De lineariseerbaarheid van het sterke consistentiemodel is de standaard voor de programmeerbaarheid van gegevens. Het verhoogt echter schrijflatenties omdat gegevens moeten worden gerepliceerd en doorgevoerd op grote afstanden. Sterke consistentie vermindert ook de beschikbaarheid tijdens fouten, omdat gegevens niet in elke regio kunnen worden gerepliceerd en doorgevoerd. Uiteindelijke consistentie biedt hogere beschikbaarheid en betere prestaties, maar het is moeilijker om toepassingen te programmeren, omdat gegevens mogelijk niet consistent zijn in alle regio's.

De meeste gedistribueerde NoSQL-databases op de markt bieden momenteel alleen een sterke en uiteindelijke consistentie. Azure Cosmos DB biedt vijf goed gedefinieerde niveaus. Van sterkste naar zwakste, de niveaus zijn:

• Sterk
• Begrensde veroudering
• Sessie
• Consistent voorvoegsel
• Uiteindelijk

Zie het standaardconsistentieniveau configureren of het standaardconsistentieniveau overschrijven voor meer informatie over het standaardconsistentieniveau.

Elk niveau zorgt voor een balans tussen beschikbaarheid en prestaties. In de volgende afbeelding ziet u de consistentieniveaus als een spectrum.

Consistentieniveaus en Azure Cosmos DB-API's

Azure Cosmos DB biedt ondersteuning voor met wire-protocol compatibele API's voor populaire databases, waaronder MongoDB, Apache Cassandra, Apache Gremlin en Azure-tabelopslag. Voor de API voor Gremlin of Table gebruikt Azure Cosmos DB het standaardconsistentieniveau dat is geconfigureerd voor het account. Zie API voor Cassandra-consistentietoewijzing voor Apache Cassandra en API voor MongoDB-consistentietoewijzing voor MongoDB voor meer informatie over toewijzing op consistentieniveau.

Bereik van leesconsistentie

Leesconsistentie is van toepassing op één leesbewerking binnen een logische partitie. Een externe client, opgeslagen procedure of trigger kan de leesoperatie uitgeven.

Het standaardconsistentieniveau configureren

Configureer op elk gewenst moment het standaardconsistentieniveau voor uw Azure Cosmos DB-account. Het standaardconsistentieniveau dat voor uw account is geconfigureerd, is van toepassing op alle Azure Cosmos DB-databases en -containers onder dat account. Alle lees- en query's die zijn uitgegeven voor een container of een database, gebruiken standaard het opgegeven consistentieniveau. Wanneer u de consistentie op accountniveau wijzigt, moet u uw toepassingen opnieuw implementeren en de benodigde codewijzigingen aanbrengen om deze wijzigingen toe te passen. Meer informatie over het configureren van het standaardconsistentieniveau. U kunt ook het standaardconsistentieniveau voor een specifieke aanvraag overschrijven. Meer informatie vindt u in het artikel over onderdrukking van het standaardconsistentieniveau .

Tip

Het overschrijven van het standaardconsistentieniveau is alleen van toepassing op leesbewerkingen binnen de SDK-client. Een account dat standaard is geconfigureerd voor sterke consistentie, schrijft en repliceert gegevens synchroon naar elke regio in het account. Wanneer de SDK-clientinstantie of -aanvraag afwijkt van deze consistentie met sessieconsistentie of zwakkere consistentie, worden leesbewerkingen uitgevoerd met één replica. Zie consistentieniveaus en doorvoer voor meer informatie.

Important

Maak een SDK-exemplaar opnieuw nadat u het standaardconsistentieniveau hebt gewijzigd door de toepassing opnieuw te starten. Deze stap zorgt ervoor dat de SDK gebruikmaakt van het nieuwe standaardconsistentieniveau.

Garanties die zijn gekoppeld aan consistentieniveaus

Azure Cosmos DB garandeert dat 100% leesaanvragen voldoen aan de consistentiegarantie voor het gekozen consistentieniveau. De exacte definities van de vijf consistentieniveaus in Azure Cosmos DB met behulp van de TLA - Tijdelijke logica van acties - specificatietaal zijn beschikbaar in de GitHub-opslagplaats azure/azure-cosmos-tla .

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

Grote consistentie

Sterke consistentie biedt garantie op linearisabiliteit. Lineariseerbaarheid betekent dat aanvragen gelijktijdig worden verwerkt. De leesbewerkingen retourneren gegarandeerd de meest recente vastgelegde versie van een item. Een client ziet nooit een niet-bevestigde of gedeeltelijke schrijfbewerking. Gebruikers kunnen altijd gegarandeerd de meest recente vastgelegde schrijfbewerking lezen.

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

Dynamisch quorum

Voor een account met een sterke consistentie wordt onder normale omstandigheden een schrijfbewerking geacht te zijn vastgelegd wanneer alle regio's de replicatie van het record erkennen. Als uw account drie of meer regio's heeft, kan het systeem het aantal regio's verlagen dat nodig is voor een quorum wanneer sommige regio's traag zijn of niet reageren. Dit helpt sterke consistentie te behouden, zelfs als een paar regio's problemen hebben. Op dat moment worden niet-reagerende regio's uit de quorumgroep van regio's verwijderd om sterke consistentie te behouden. Ze worden alleen weer toegevoegd wanneer ze consistent zijn met andere regio's en naar verwachting presteren. Het aantal regio's dat mogelijk uit de quorumset kan worden gehaald, is afhankelijk van het totale aantal regio's. In een account van drie of vier regio's is de meerderheid bijvoorbeeld respectievelijk twee of drie regio's, dus in beide gevallen kan slechts één regio worden verwijderd. Voor een vijf regioaccount is de meerderheid drie, dus maximaal twee niet-reagerende regio's kunnen worden verwijderd. Deze mogelijkheid wordt 'dynamisch quorum' genoemd en kan zowel de beschikbaarheid als de replicatielatentie voor accounts met drie of meer regio's verbeteren.

Opmerking

Wanneer regio's worden verwijderd uit de quorumset als onderdeel van een dynamisch quorum, kunnen deze regio's geen leesverzoeken meer verwerken totdat ze weer aan het quorum zijn toegevoegd.

Consistentie met begrensde veroudering

Voor schrijfaccounts met een enkele regio waarbij twee of meer regio's betrokken zijn, worden gegevens gerepliceerd van de primaire regio naar alle secundaire (alleen-lezen) regio's. Voor schrijfaccounts met meerdere regio's worden gegevens gerepliceerd van de regio waarin ze oorspronkelijk geschreven zijn naar alle andere schrijfbare regio's. In beide scenario's, hoewel dit niet gebruikelijk is, kan er af en toe een replicatievertraging optreden van de ene regio naar de andere.

In gebonden verouderingsconsistentie is de vertraging van gegevens tussen twee willekeurige regio's altijd kleiner dan een opgegeven hoeveelheid. De hoeveelheid kan "K"-versies (dat wil zeggen "updates") van een item zijn of door "T"-tijdsintervallen, afhankelijk van wat het eerst wordt bereikt. Met andere woorden, wanneer u gebonden veroudering kiest, kunnen de maximum 'veroudering' van de gegevens in elke regio op twee manieren worden geconfigureerd:

• Het aantal versies (K) van het item
• De leesbewerkingen voor het tijdsinterval (T) kunnen achterblijven bij de schrijfbewerkingen

Gebonden veroudering is voornamelijk nuttig voor schrijfaccounts met één regio met twee of meer regio's. Als de gegevensvertraging in een regio (bepaald per fysieke partitie) de geconfigureerde verouderingswaarde overschrijdt, worden schrijfbewerkingen voor die partitie beperkt totdat veroudering weer binnen de geconfigureerde bovengrens valt.

Voor een account met één regio biedt Bounded Staleness dezelfde garanties voor schrijfconsistentie als sessie- en uiteindelijke consistentie. Met Bounded Staleness worden gegevens gerepliceerd naar de lokale meerderheid (drie replica's in een vier replica set) in één regio.

Important

Met de consistentie van Gebonden veroudering worden verouderingscontroles alleen uitgevoerd tussen regio's en niet binnen een regio. Binnen een bepaalde regio worden gegevens altijd gerepliceerd naar een lokale meerderheid (drie replica's in een set met vier replica's), ongeacht het consistentieniveau.

Leesbewerkingen bij het gebruik van Bounded Staleness retourneren de meest recente gegevens die beschikbaar zijn in die regio door te lezen uit twee beschikbare replica's in die regio. Omdat schrijfbewerkingen steeds worden gerepliceerd naar een lokale meerderheid (drie van de vier replica's) binnen een regio, levert het raadplegen van twee replica's de actueelste gegevens op die beschikbaar zijn in die regio.

Important

Met Bounded Staleness-consistentie kunnen leesverzoeken vanuit een niet-primaire regio mogelijk niet de meest recente gegevens uit alle regio's weergeven. Ze retourneren echter altijd de nieuwste gegevens die beschikbaar zijn in die regio, binnen de toegestane verouderingslimiet.

Bounded Staleness werkt het beste voor wereldwijd gedistribueerde toepassingen die gebruikmaken van schrijfaccounts voor één regio, waarbij twee of meer regio's betrokken zijn en er bijna sterke consistentie tussen regio's gewenst is. Voor schrijfaccounts met meerdere regio's met twee of meer regio's moeten toepassingsservers lees- en schrijfbewerkingen doorsturen naar dezelfde regio waarin de toepassingsservers worden gehost. Gebonden veroudering in een account met meerdere schrijfbewerkingen is een antipatroon. Dit niveau vereist een afhankelijkheid van replicatievertraging tussen regio's, wat niet uitmaakt of gegevens worden gelezen uit dezelfde regio waarnaar ze zijn geschreven.

In de volgende afbeelding ziet u de beperkte verouderingsconsistentie met muzieknoten. Nadat de gegevens naar de regio US - 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:

Sessieconsistentie

In sessieconsistentie, binnen één clientsessie, garanderen leesbewerkingen de lees-je-schrijven en write-follows-reads-garanties. Hierbij wordt ervan uitgegaan dat er één 'writer'-sessie wordt gebruikt of dat het sessietoken voor meerdere schrijvers wordt gedeeld.

Net als alle consistentieniveaus die zwakker zijn dan Sterk, worden schrijfbewerkingen gerepliceerd naar minimaal drie replica's (in een set van vier replica's) in de lokale regio, met asynchrone replicatie naar alle andere regio's.

Na elke schrijfbewerking ontvangt de client een bijgewerkt sessietoken van de server. De client slaat de tokens in de cache op en verzendt deze naar de server voor leesbewerkingen in een opgegeven regio. Als de replica waarmee de leesbewerking wordt uitgegeven gegevens bevat voor het opgegeven token (of een recenter token), worden de aangevraagde gegevens geretourneerd. Als de replica geen gegevens voor die sessie bevat, probeert de client de aanvraag opnieuw uit te voeren op een andere replica in de regio. Indien nodig probeert de client de leesbewerking opnieuw uit te voeren op extra beschikbare regio's totdat de gegevens voor het opgegeven sessietoken worden opgehaald.

Important

In sessieconsistentie gebruikt de client een sessietoken om ervoor te zorgen dat er nooit gegevens worden gelezen die betrekking hebben op een oudere sessie. Als de client een oud sessietoken gebruikt, maar nieuwere gegevens beschikbaar zijn in de database, retourneert het systeem de nieuwste versie. Zelfs met een verouderd token krijgt u altijd de meest recente gegevens. Het sessietoken wordt gebruikt als minimale versiebarrière, maar niet als een specifieke (mogelijk historische) versie van de gegevens die moeten worden opgehaald uit de database.

Sessietokens in Azure Cosmos DB zijn partitiegebonden, wat betekent dat ze exclusief zijn gekoppeld aan één partitie. Gebruik het sessietoken dat voor het laatst is gegenereerd voor de relevante items om ervoor te zorgen dat u uw schrijfbewerkingen kunt lezen.

Als de client geen schrijfbewerking naar een fysieke partitie heeft gestart, bevat de client geen sessietoken in de cache en worden de leesbewerkingen naar die fysieke partitie behandeld met uiteindelijke consistentie. Als de client opnieuw wordt gemaakt, wordt ook de cache met sessietokens opnieuw gemaakt. Leesbewerkingen volgen hier ook hetzelfde gedrag als Uiteindelijke consistentie totdat volgende schrijfbewerkingen de cache van sessietokens van de client herbouwen.

Important

Als sessietokens van het ene clientexemplaren naar het andere worden doorgegeven, mag de inhoud van het token niet worden gewijzigd.

Sessieconsistentie is het meest gebruikte consistentieniveau voor toepassingen met één regio en wereldwijd gedistribueerde toepassingen. Het biedt schrijflatenties, beschikbaarheid en leesdoorvoer die vergelijkbaar is met die van uiteindelijke consistentie. Sessieconsistentie biedt ook de consistentiegaranties die aansluiten bij de behoeften van toepassingen die zijn geschreven om te werken in de context van een gebruiker. In de volgende afbeelding ziet u de consistentie van de sessie met muzieknotities. De schrijver VS - west 2 en de lezer VS - oost 2 gebruiken dezelfde sessie (sessie A), zodat ze beide dezelfde gegevens tegelijk lezen. In de regio "Australië Oost" wordt 'Sessie B' gebruikt, waardoor gegevens later worden ontvangen, maar wel in dezelfde volgorde als de schrijfbewerkingen.

Consistente consistentie van voorvoegsels

Net als alle consistentieniveaus die zwakker zijn dan Sterk, worden schrijfbewerkingen gerepliceerd naar minimaal drie replica's (in een set met vier replica's) in de lokale regio, met asynchrone replicatie naar alle andere regio's.

In consistente prefix zien updates die zijn aangebracht als schrijfbewerkingen voor een enkel document uiteindelijk consistentie.

Updates die zijn gemaakt als een batch binnen een transactie, worden consistent geretourneerd voor de transactie waarin ze zijn doorgevoerd. Schrijfbewerkingen binnen een transactie van meerdere documenten zijn altijd samen zichtbaar.

Stel dat twee schrijfbewerkingen transactioneel (alle of niets) worden uitgevoerd op document Doc1, gevolgd door document Doc2, binnen transacties T1 en T2. Wanneer de client een replica leest, ziet de gebruiker 'Doc1 v1 en Doc2 v1' of 'Doc1 v2 en Doc2 v2' of geen van beide documenten als de replica traag is, maar nooit 'Doc1 v1 en Doc2 v2' of 'Doc1 v2 en Doc2 v1' voor dezelfde lees- of querybewerking.

In de volgende afbeelding ziet u de consistentievoorvoegselconsistentie met muzieknotities. In alle regio's zien leesbewerkingen nooit schrijfbewerkingen die uit volgorde zijn voor een transactionele batch schrijfbewerkingen.

**

Uiteindelijke consistentie

Net als alle consistentieniveaus die zwakker zijn dan Sterk, worden schrijfbewerkingen gerepliceerd naar minimaal drie replica's (in een set van vier replica's) in de lokale regio, met asynchrone replicatie naar alle andere regio's.

In uiteindelijke consistentie geeft de client leesaanvragen op voor een van de vier replica's in de opgegeven regio. Deze replica kan vertraging ondervinden en kan verouderde of helemaal geen gegevens teruggeven.

Uiteindelijke consistentie is de zwakste vorm van consistentie, omdat een client waarden kan lezen die ouder zijn dan die waarden die in het verleden zijn gelezen. Eventual consistency is ideaal wanneer de toepassing geen volgorde-garanties vereist. Voorbeelden hiervan zijn het aantal Retweets, Vind-ik-leuks of niet-gelezen opmerkingen. In de volgende afbeelding ziet u de uiteindelijke consistentie met muzieknotities.

Consistentiegaranties in de praktijk

In de praktijk kunt u vaak sterkere consistentiegaranties krijgen. Consistentiegaranties voor een leesbewerking komen overeen met de versheid en volgorde van de databasestatus die u aanvraagt. Leesconsistentie is gekoppeld aan de volgorde en doorgifte van de schrijf- en updatebewerkingen.

Als er geen schrijfbewerkingen in de database zijn, kan een leesbewerking met uiteindelijke, sessie- of consistente consistentieniveaus voor voorvoegsels dezelfde resultaten opleveren als een leesbewerking met het sterke consistentieniveau.

Als uw account is geconfigureerd met een ander consistentieniveau dan de sterke consistentie, kunt u de waarschijnlijkheid vaststellen waarmee uw clients sterke en consistente leesbewerkingen voor uw workloads kunnen uitvoeren. Bepaal deze waarschijnlijkheid door naar de Probabilistically Bounded Staleness (PBS) metriek te kijken. Deze metrische waarde wordt weergegeven in Azure Portal. Voor meer informatie, zie de Monitor Probabilistically Bounded Staleness (PBS) metric.

Probabilistisch gebonden veroudering toont hoe uiteindelijk uw uiteindelijke consistentie is. Deze metrische waarde biedt inzicht in hoe vaak u sterkere consistentie krijgt dan het consistentieniveau dat momenteel is geconfigureerd in uw Azure Cosmos DB-account. Met andere woorden, u kunt de waarschijnlijkheid (gemeten in milliseconden) zien van het verkrijgen van consistente leesbewerkingen voor een combinatie van schrijf- en leesregio's.

Consistentieniveaus en latentie

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

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

Schrijflatentie en sterke consistentie

Voor Azure Cosmos DB-accounts die zijn geconfigureerd met sterke consistentie met meer dan één regio, is de schrijflatentie gelijk aan twee keer retourtijd (RTT) tussen een van de twee meest verre regio's, plus 10 milliseconden op het 99e percentiel. Hoge netwerk-RTT tussen regio's verhoogt de latentie van azure Cosmos DB-aanvragen omdat sterke consistentie een bewerking pas voltooit nadat de bewerking is doorgevoerd in alle regio's in het account.

De exacte RTT-latentie is afhankelijk van de snelheid van lichtafstand en de Azure-netwerktopologie. Azure-netwerken bieden geen latency SLA's (service level agreements) voor RTT tussen Azure-regio's, maar publiceren Azure-netwerk latentiestatistieken. Voor uw Azure Cosmos DB-account worden replicatielatenties weergegeven in Azure Portal. Gebruik Azure Portal door naar de sectie Metrische gegevens te gaan en de optie Consistentie te selecteren. Met behulp van Azure Portal kunt u de replicatielatenties bewaken tussen verschillende regio's die zijn gekoppeld aan uw Azure Cosmos DB-account.

Important

Sterke consistentie voor accounts met regio's die meer dan 5.000 mijl (8.000 kilometer) omvatten, wordt standaard geblokkeerd vanwege een hoge schrijflatentie. Neem contact op met de ondersteuning om deze mogelijkheid in te schakelen.

Consistentieniveaus en doorvoer

• Voor sterke en begrensde veroudering worden leesbewerkingen uitgevoerd op twee replica's binnen een set van vier replica's (minderheidsquorum) om de garanties voor consistentie te waarborgen. Sessie, consistent voorvoegsel en uiteindelijke consistentie maken gebruik van leesbewerkingen met één replica. Als gevolg hiervan is de leesdoorvoer voor sterke en begrensde veroudering bij hetzelfde aantal aanvraageenheden de helft van die bij de andere consistentieniveaus.

• Voor een bepaald type schrijfbewerking, zoals invoegen, vervangen, upsert of verwijderen, is de schrijfdoorvoersnelheid voor aanvraageenheden identiek bij 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 set met vier replica's) wordt gebruikt.

Consistentieniveau	Quorumlezen	Quorumschrijfbewerkingen
Sterk	Lokale minderheid	Wereldwijde meerderheid
Beperkte veroudering	Lokale minderheid	Lokale meerderheid
Session	Enkele replica (met sessietoken)	Lokale meerderheid
Consistent voorvoegsel	Eén replica	Lokale meerderheid
Gebeurlijk	Eén replica	Lokale meerderheid

Opmerking

De RU-kosten van leesbewerkingen voor lokale minderheidsleesbewerkingen zijn twee keer dat van zwakkere consistentieniveaus, omdat leesbewerkingen worden gemaakt van twee replica's om consistentiegaranties te garanderen voor de sterke en gebonden verouderingsniveaus.

Consistentieniveaus en duurzaamheid van gegevens

In een wereldwijd gedistribueerde databaseomgeving is het consistentieniveau rechtstreeks van invloed op de duurzaamheid van gegevens tijdens een storing in de hele regio. Wanneer u een bedrijfscontinuïteitsplan ontwikkelt, moet u begrijpen wat de maximale periode is van recente gegevensupdates die de toepassing kan verdragen te verliezen tijdens het herstel van een verstorende gebeurtenis. De periode van updates die verloren kunnen gaan, wordt aangeduid als de beoogde herstelpunt (RPO).

In deze tabel ziet u de relatie tussen consistentiemodellen en duurzaamheid van gegevens tijdens een regiobrede storing.

Regions	Replicatiemodus	Consistentieniveau	RPO
1	Schrijfregio's voor één of meerdere locaties	Elk consistentieniveau	< 240 minuten
>1	Regio met één schrijffunctie	Sessie, consistent voorvoegsel, uiteindelijk	< 15 minuten
>1	Regio met één schrijffunctie	Beperkte Veroudering	K & T
>1	Regio met één schrijffunctie	Sterk	0
>1	Meerdere schrijfregio's	Sessie, consistent voorvoegsel, uiteindelijk	< 15 minuten
>1	Meerdere schrijfregio's	Beperkte Veroudering	K & T

K = Het aantal K-versies (updates) van een item.

T = het tijdsinterval T sinds de laatste update.

Voor een account met één regio is de minimale waarde van K en T 10 schrijfbewerkingen of 5 seconden. Voor accounts met meerdere regio's is de minimale waarde van K en T 100.000 schrijfbewerkingen of 300 seconden. Deze waarde definieert het minimale herstelpuntdoel (RPO) voor gegevens bij gebruik van Begrensde Stalenheid.

Sterke consistentie en meerdere schrijfregions

Azure Cosmos DB-accounts met meerdere schrijfregio's kunnen geen sterke consistentie gebruiken omdat een gedistribueerd systeem geen RPO (Recovery Point Objective) van nul en een RTO (Recovery Time Objective) van nul kan bieden. Bovendien verbetert sterke consistentie met meerdere schrijfregio's de schrijflatentie niet, omdat schrijfbewerkingen moeten worden gerepliceerd en vastgelegd in alle regio's in het account. Deze instelling resulteert in dezelfde schrijflatentie als een account met één schrijfregio.

Meer lezen

Lees de volgende artikelen voor meer informatie over consistentieconcepten:

• Hoogwaardige TLA⁺-specificaties voor de vijf consistentieniveaus die worden aangeboden door Azure Cosmos DB
• Gerepliceerde gegevensconsistentie uitgelegd via honkbal (video) door Doug Terry
• Gerepliceerde gegevensconsistentie uitgelegd via honkbal (technisch document) door Doug Terry
• Sessiegaranties voor zwak consistente gerepliceerde gegevens
• Consistentie-compromissen in het ontwerp van moderne gedistribueerde databasesystemen: CAP maakt slechts deel uit van het verhaal
• Probabilistisch gebonden veroudering (PBS) voor praktische gedeeltelijke quorums
• Uiteindelijk consistent - opnieuw bezocht

Verwante inhoud

• Het standaardconsistentieniveau configureren
• Het standaardconsistentieniveau overschrijven
• Meer informatie over de SLA van Azure Cosmos DB.