Consistentieniveaus in Azure Cosmos DBConsistency levels in Azure Cosmos DB

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

Gedistribueerde data bases die afhankelijk zijn van replicatie voor hoge Beschik baarheid, lage latentie of beide, moeten een fundamentele verhouding tot stand brengen tussen de Lees consistentie, Beschik baarheid, latentie en door Voer, zoals gedefinieerd door de PACLC theorema.Distributed databases that rely on replication for high availability, low latency, or both, must make a fundamental tradeoff between the read consistency, availability, latency, and throughput as defined by the PACLC theorem. De linearizability van het sterke consistentie model is de Gold Standard van data Programmable.The linearizability of the strong consistency model is the gold standard of data programmability. Er wordt echter een steile prijs van meer schrijf latenties toegevoegd als gevolg van gegevens die op grote afstanden moeten worden gerepliceerd en doorgevoerd.But it adds a steep price from higher write latencies due to data having to replicate and commit across large distances. Sterke consistentie kan ook afwegen tegen een gereduceerde Beschik baarheid (tijdens fouten) omdat gegevens niet in elke regio kunnen worden gerepliceerd en doorgevoerd.Strong consistency may also suffer from reduced availability (during failures) because data cannot replicate and commit in every region. Uiteindelijke consistentie biedt hogere Beschik baarheid en betere prestaties, maar zijn moeilijker te Program meren omdat gegevens mogelijk niet volledig consistent zijn in alle regio's.Eventual consistency offers higher availability and better performance, but its more difficult to program applications because data may not be completely consistent across all regions.

De meeste in de handel Verkrijg bare, gedistribueerde NoSQL-data bases die tegenwoordig beschikbaar zijn, bieden alleen een krachtige en uiteindelijke consistentie.Most commercially available distributed NoSQL databases available in the market today provide only strong and eventual consistency. Azure Cosmos DB biedt vijf duidelijk gedefinieerde niveaus.Azure Cosmos DB offers five well-defined levels. Van het sterkst tot het zwakst zijn de niveaus:From strongest to weakest, the levels are:

  • SterkStrong
  • Gebonden verouderingBounded staleness
  • BeëindigenSession
  • Consistent voor voegselConsistent prefix
  • UiteindelijkeEventual

Elk niveau biedt Beschik baarheid en prestatie afwegingen.Each level provides availability and performance tradeoffs. In de volgende afbeelding ziet u de verschillende consistentie niveaus als een spectrum.The following image shows the different consistency levels as a spectrum.

Consistentie als een spectrum

De consistentie niveaus zijn neutraal en worden gegarandeerd voor alle bewerkingen, ongeacht de regio van waaruit de lees-en schrijf bewerkingen worden uitgevoerd, het aantal regio's dat aan uw Azure Cosmos-account is gekoppeld, of of uw account is geconfigureerd met één of meerdere schrijf regio's.The consistency levels are region-agnostic and are guaranteed for all operations regardless of the region from which the reads and writes are served, the number of regions associated with your Azure Cosmos account, or whether your account is configured with a single or multiple write regions.

Consistentieniveaus en Azure Cosmos DB-API'sConsistency levels and Azure Cosmos DB APIs

Azure Cosmos DB biedt systeem eigen ondersteuning voor Api's die compatibel zijn met wire-protocol voor populaire data bases.Azure Cosmos DB provides native support for wire protocol-compatible APIs for popular databases. Dit zijn onder andere MongoDB, Apache Cassandra, Gremlin en Azure Table Storage.These include MongoDB, Apache Cassandra, Gremlin, and Azure Table storage. Wanneer u Gremlin-API en Table-API gebruikt, wordt het standaard consistentie niveau gebruikt dat is geconfigureerd voor het Azure Cosmos-account.When using Gremlin API and Table API, the default consistency level configured on the Azure Cosmos account is used. Zie Cassandra-API consistentie toewijzing en API voor MongoDb-consistentie toewijzingvoor meer informatie over de toewijzing van het consistentie niveau tussen Cassandra-API of de API voor MongoDb en de consistentie niveaus van Azure Cosmos db.For details on consistency level mapping between Cassandra API or the API for MongoDB and Azure Cosmos DB's consistency levels see, Cassandra API consistency mapping and API for MongoDB consistency mapping.

Bereik van de Lees consistentieScope of the read consistency

Lees consistentie is van toepassing op één Lees bewerking binnen een logische partitie.Read consistency applies to a single read operation scoped within a logical partition. De Lees bewerking kan worden uitgegeven door een externe client of een opgeslagen procedure.The read operation can be issued by a remote client or a stored procedure.

Het standaardconsistentieniveau configurerenConfigure the default consistency level

U kunt op elk gewenst moment het standaard consistentie niveau configureren voor uw Azure Cosmos-account.You can configure the default consistency level on your Azure Cosmos account at any time. Het standaard consistentie niveau dat voor uw account is geconfigureerd, is van toepassing op alle Azure Cosmos-data bases en containers onder dat account.The default consistency level configured on your account applies to all Azure Cosmos databases and containers under that account. Alle Lees bewerkingen en query's die zijn uitgegeven voor een container of een Data Base, gebruiken standaard het opgegeven consistentie niveau.All reads and queries issued against a container or a database use the specified consistency level by default. Zie het standaard consistentie niveau configurerenvoor meer informatie.To learn more, see how to configure the default consistency level. U kunt ook het standaard consistentie niveau voor een specifieke aanvraag overschrijven. Zie How to override the default Consistency level article voor meer informatie.You can also override the default consistency level for a specific request, to learn more, see how to Override the default consistency level article.

Garanties die zijn gekoppeld aan de consistentie niveausGuarantees associated with consistency levels

Azure Cosmos DB garandeert dat 100 procent van de Lees aanvragen voldoet aan de consistentie garantie voor het gekozen consistentie niveau.Azure Cosmos DB guarantees that 100 percent of read requests meet the consistency guarantee for the consistency level chosen. De exacte definities van de vijf consistentie niveaus in Azure Cosmos DB met behulp van de TLA + specificatie taal zijn opgenomen in de Azure-Cosmos-TLA github opslag plaats.The precise definitions of the five consistency levels in Azure Cosmos DB using the TLA+ specification language are provided in the azure-cosmos-tla GitHub repo.

De semantiek van de vijf consistentie niveaus worden hier beschreven:The semantics of the five consistency levels are described here:

  • Sterk : sterke consistentie biedt een linearizability-garantie.Strong : Strong consistency offers a linearizability guarantee. Linearizability verwijst naar de gelijktijdigheid van aanvragen.Linearizability refers to serving requests concurrently. De Lees bewerkingen worden gegarandeerd de meest recente doorgevoerde versie van een item te retour neren.The reads are guaranteed to return the most recent committed version of an item. Een client ziet nooit een niet-doorgevoerde of gedeeltelijke schrijf bewerking.A client never sees an uncommitted or partial write. Gebruikers worden altijd gegarandeerd de laatste vastgelegde schrijf bewerkingen te lezen.Users are always guaranteed to read the latest committed write.

    In de volgende afbeelding ziet u de sterke consistentie met muzikale notities.The following graphic illustrates the strong consistency with musical notes. Wanneer u de gegevens van andere regio's hebt geschreven naar de regio vs-West 2, krijgt u de meest recente waarde:After the data is written to the "West US 2" region, when you read the data from other regions, you get the most recent value:

    Afbeelding van het niveau van sterke consistentie

  • Gebonden veroudering : de Lees bewerkingen worden gegarandeerd de consistentie van het voor voegsel garanderen.Bounded staleness : The reads are guaranteed to honor the consistent-prefix guarantee. De Lees bewerkingen kunnen vertraging oplopen bij schrijf bewerkingen door de meeste "K" -versies (dat wil zeggen "updates") van een item of door een T -outinterval, afhankelijk van wat het eerst wordt bereikt.The reads might lag behind writes by at most "K" versions (that is, "updates") of an item or by "T" time interval, whichever is reached first. Met andere woorden, wanneer u de gebonden veroudering kiest, kan de ' verouderd ' op twee manieren worden geconfigureerd:In other words, when you choose bounded staleness, the "staleness" can be configured in two ways:

  • Het aantal versies ( K ) van het itemThe number of versions ( K ) of the item

  • De tijds interval ( T ) Lees bewerkingen kunnen vertraging oplopen achter de schrijf bewerkingenThe time interval ( T ) reads might lag behind the writes

Voor een account van één regio is de minimum waarde K en T 10 schrijf bewerkingen of 5 seconden.For a single region account, the minimum value of K and T is 10 write operations or 5 seconds. Voor accounts met meerdere regio's is de minimale waarde van K en T 100.000 schrijf bewerkingen of 300 seconden.For multi-region accounts the minimum value of K and T is 100,000 write operations or 300 seconds.

Gebonden veroudering bieden de totale wereld wijde volg orde buiten het verouderde venster.Bounded staleness offers total global order outside of the "staleness window." Wanneer een client lees bewerkingen uitvoert binnen een regio die schrijf acties accepteert, zijn de garanties die worden geboden door de gebonden verouderde consistentie, identiek aan die garanties van de sterke consistentie.When a client performs read operations within a region that accepts writes, the guarantees provided by bounded staleness consistency are identical to those guarantees by the strong consistency. Naarmate het verouderde venster benaderingen voor tijd of updates, afhankelijk van wat dichter bij elkaar ligt, wordt door de service nieuwe schrijf bewerkingen voor het toestaan van replicatie om de consistentie garantie te controleren en te voldoen.As the staleness window approaches for either time or updates, whichever is closer, the service will throttle new writes to allow replication to catch up and honor the consistency guarantee.

Binnen het verouderde venster biedt gebonden veroudering de volgende consistentie garanties:Inside the staleness window, Bounded Staleness provides the following consistency guarantees:

  • Consistentie voor clients in dezelfde regio voor een account met één schrijf regio = StrongConsistency for clients in the same region for an account with single write region = Strong

  • Consistentie voor clients in verschillende regio's voor een account met één schrijf regio = consistent voor voegselConsistency for clients in different regions for an account with single write region = Consistent Prefix

  • Consistentie voor clients die schrijven naar één regio voor een account met meerdere schrijf regio's = consistent voor voegselConsistency for clients writing to a single region for an account with multiple write regions = Consistent Prefix

  • Consistentie voor clients die schrijven naar verschillende regio's voor een account met meerdere schrijf regio's = uiteindelijkConsistency for clients writing to different regions for an account with multiple write regions = Eventual

    Gebonden verouderd wordt vaak gekozen door wereld wijd gedistribueerde toepassingen die weinig schrijf latentie verwachten, maar die de totale garantie voor de globale bestelling vereisen.Bounded staleness is frequently chosen by globally distributed applications that expect low write latencies but require total global order guarantee. Gebonden verouderd is handig voor toepassingen met groeps samenwerking en delen, aandelen tikker, publiceren/abonneren/wachtrij, enzovoort. In de volgende afbeelding ziet u de gebonden consistentie van veroudering met muzikale notities.Bounded staleness is great for applications featuring group collaboration and sharing, stock ticker, publish-subscribe/queueing etc. The following graphic illustrates the bounded staleness consistency with musical notes. Nadat de gegevens zijn geschreven naar de regio vs-West 2, lezen de regio's ' vs Oost 2 ' en ' Australië-oost ' de geschreven waarde op basis van de geconfigureerde maximale vertragings tijd of het maximum aantal bewerkingen:After the data is written to the "West US 2" region, the "East US 2" and "Australia East" regions read the written value based on the configured maximum lag time or the maximum operations:

    Afbeelding van het consistentie niveau van de gebonden veroudering

  • Sessie : in een enkele client sessie Lees bewerkingen worden gegarandeerd het consistente voor voegsel, monotone Lees bewerkingen, monotone schrijf bewerkingen, lees-uw-schrijf bewerkingen en lees-en schrijf bewerkingen.Session : Within a single client session reads are guaranteed to honor the consistent-prefix, monotonic reads, monotonic writes, read-your-writes, and write-follows-reads guarantees. Hierbij wordt ervan uitgegaan dat u één schrijver-sessie hebt of het sessie token deelt voor meerdere schrijvers.This assumes a single "writer" session or sharing the session token for multiple writers.

Clients buiten de sessie die schrijf bewerkingen uitvoeren, zien de volgende garanties:Clients outside of the session performing writes will see the following guarantees:

  • Consistentie voor clients in dezelfde regio voor een account met één schrijf regio = consistent voor voegselConsistency for clients in same region for an account with single write region = Consistent Prefix

  • Consistentie voor clients in verschillende regio's voor een account met één schrijf regio = consistent voor voegselConsistency for clients in different regions for an account with single write region = Consistent Prefix

  • Consistentie voor clients die schrijven naar één regio voor een account met meerdere schrijf regio's = consistent voor voegselConsistency for clients writing to a single region for an account with multiple write regions = Consistent Prefix

  • Consistentie voor clients die schrijven naar meerdere regio's voor een account met meerdere schrijf regio's = uiteindelijkConsistency for clients writing to multiple regions for a account with multiple write regions = Eventual

    Sessie consistentie is het meest gebruikte consistentie niveau voor zowel de ene regio als wereld wijd gedistribueerde toepassingen.Session consistency is the most widely used consistency level for both single region as well as globally distributed applications. Het biedt schrijf latentie, Beschik baarheid en lees doorvoer die vergelijkbaar zijn met die van uiteindelijke consistentie, maar biedt ook de consistentie garanties die van toepassing zijn op de behoeften van toepassingen die zijn geschreven om te kunnen worden gebruikt in de context van een gebruiker.It provides write latencies, availability, and read throughput comparable to that of eventual consistency but also provides the consistency guarantees that suit the needs of applications written to operate in the context of a user. In de volgende afbeelding ziet u de consistentie van de sessie met muzikale notities.The following graphic illustrates the session consistency with musical notes. De "West US 2 Writer" en de "West US 2 Reader" gebruiken dezelfde sessie (sessie A), zodat ze beide dezelfde gegevens op hetzelfde moment lezen.The "West US 2 writer" and the "West US 2 reader" are using the same session (Session A) so they both read the same data at the same time. Terwijl de regio ' Australië-oost ' gebruikmaakt van ' sessie B ', worden gegevens later ontvangen, maar in dezelfde volg orde als de schrijf bewerkingen.Whereas the "Australia East" region is using "Session B" so, it receives data later but in the same order as the writes.

    Afbeelding van consistentie niveau van de sessie

  • Consistent voor voegsel : updates die worden geretourneerd, bevatten een voor voegsel van alle updates, zonder onderbrekingen.Consistent prefix : Updates that are returned contain some prefix of all the updates, with no gaps. Consistent consistentie niveau van het voor voegsel zorgt ervoor dat lees bewerkingen die nooit worden uitgevoerd, niet worden weer gegeven.Consistent prefix consistency level guarantees that reads never see out-of-order writes.

Als schrijf bewerkingen zijn uitgevoerd in de volg orde A, B, C , ziet een client een A van de, A,B , of A,B,C , maar niet-beschik bare permutaties zoals A,C of B,A,C .If writes were performed in the order A, B, C, then a client sees either A, A,B, or A,B,C, but never out-of-order permutations like A,C or B,A,C. Consistent voor voegsel biedt schrijf latentie, Beschik baarheid en lees doorvoer die vergelijkbaar zijn met die van uiteindelijke consistentie, maar biedt ook de volg orde van de bestellingen die voldoen aan de behoeften van scenario's waarin de volg orde belang rijk is.Consistent Prefix provides write latencies, availability, and read throughput comparable to that of eventual consistency, but also provides the order guarantees that suit the needs of scenarios where order is important.

Hieronder vindt u de consistentie garanties voor consistent voor voegsel:Below are the consistency guarantees for Consistent Prefix:

  • Consistentie voor clients in dezelfde regio voor een account met één schrijf regio = consistent voor voegselConsistency for clients in same region for an account with single write region = Consistent Prefix
  • Consistentie voor clients in verschillende regio's voor een account met één schrijf regio = consistent voor voegselConsistency for clients in different regions for an account with single write region = Consistent Prefix
  • Consistentie voor clients die schrijven naar één regio voor een account met meerdere schrijf regio's = consistent voor voegselConsistency for clients writing to a single region for an account with multiple write region = Consistent Prefix
  • Consistentie voor clients die schrijven naar meerdere regio's voor een account met meerdere schrijf regio's = uiteindelijkConsistency for clients writing to multiple regions for an account with multiple write region = Eventual

In de volgende afbeelding ziet u de consistentie van het consistentie voorvoegsel met muzikale notities.The following graphic illustrates the consistency prefix consistency with musical notes. In alle regio's zien de Lees bewerkingen nooit buiten de juiste volg orde:In all the regions, the reads never see out of order writes:

Afbeelding van consistent voor voegsel

  • Uiteindelijk : er is geen garantie voor lees bewerkingen.Eventual : There's no ordering guarantee for reads. Als er verder geen schrijfbewerkingen worden uitgevoerd, convergeren de replica's uiteindelijk.In the absence of any further writes, the replicas eventually converge.
    Uiteindelijke consistentie is de zwakke vorm van consistentie, omdat een client de waarden kan lezen die ouder zijn dan de waarde die het eerder had gelezen.Eventual consistency is the weakest form of consistency because a client may read the values that are older than the ones it had read before. Uiteindelijke consistentie is ideaal wanneer de toepassing geen garantie voor het ordenen van de toepassingen vereist.Eventual consistency is ideal where the application does not require any ordering guarantees. Voor beelden zijn het aantal retweeten, leuk of niet-threaded opmerkingen.Examples include count of Retweets, Likes, or non-threaded comments. In de volgende afbeelding ziet u de uiteindelijke consistentie met muzikale notities.The following graphic illustrates the eventual consistency with musical notes.

    viIllustration van de uiteindelijke consistentie

Consistentie garanties in de praktijkConsistency guarantees in practice

In de praktijk kunt u vaak sterkere consistentie garanties krijgen.In practice, you may often get stronger consistency guarantees. Consistentie garanties voor een lees bewerking komen overeen met de versheid en volg orde van de database status die u aanvraagt.Consistency guarantees for a read operation correspond to the freshness and ordering of the database state that you request. Lees consistentie is gekoppeld aan de volg orde en doorgifte van de schrijf-en bijwerk bewerkingen.Read-consistency is tied to the ordering and propagation of the write/update operations.

Als er geen schrijf bewerkingen zijn op de data base, kan een Lees bewerking met een mogelijke consistentie niveau, een sessie of een consistent voor voegsel dezelfde resultaten opleveren als een lees bewerking met een hoog consistentie niveau.If there are no write operations on the database, a read operation with eventual , session , or consistent prefix consistency levels is likely to yield the same results as a read operation with strong consistency level.

Als uw Azure Cosmos-account is geconfigureerd met een ander consistentie niveau dan de sterke consistentie, kunt u de kans ontdekken dat uw clients sterke en consistente Lees bewerkingen voor uw werk belastingen krijgen door te kijken naar de metrische gegevens van de Probabilistically-gebonden veroudering (PBS).If your Azure Cosmos account is configured with a consistency level other than the strong consistency, you can find out the probability that your clients may get strong and consistent reads for your workloads by looking at the Probabilistically Bounded Staleness (PBS) metric. Deze metriek wordt weer gegeven in de Azure Portal voor meer informatie, Zie Probabilistically gebonden verouderde waarde (PBS) controleren.This metric is exposed in the Azure portal, to learn more, see Monitor Probabilistically Bounded Staleness (PBS) metric.

Probabilistic gebonden veroudering laten zien hoe uiteindelijk uw uiteindelijke consistentie is.Probabilistic bounded staleness shows how eventual is your eventual consistency. Deze metrische gegevens bieden een inzicht in hoe vaak u een sterkere consistentie kunt krijgen dan het consistentie niveau dat u momenteel hebt geconfigureerd in uw Azure Cosmos-account.This metric provides an insight into how often you can get a stronger consistency than the consistency level that you have currently configured on your Azure Cosmos account. Met andere woorden, u kunt de waarschijnlijkheid (gemeten in milliseconden) voor het verkrijgen van sterk consistente Lees bewerkingen voor een combi natie van de regio's schrijven en lezen zien.In other words, you can see the probability (measured in milliseconds) of getting strongly consistent reads for a combination of write and read regions.

Consistentie niveaus en latentieConsistency levels and latency

De lees latentie voor alle consistentie niveaus is altijd gegarandeerd minder dan 10 milliseconden bij het 99e percentiel.The read latency for all consistency levels is always guaranteed to be less than 10 milliseconds at the 99th percentile. De gemiddelde lees latentie, op het 50e percentiel, is doorgaans 4 milliseconden of minder.The average read latency, at the 50th percentile, is typically 4 milliseconds or less.

De schrijf latentie voor alle consistentie niveaus is altijd gegarandeerd minder dan 10 milliseconden bij het 99e percentiel.The write latency for all consistency levels is always guaranteed to be less than 10 milliseconds at the 99th percentile. De gemiddelde schrijf latentie, op het 50e percentiel, is meestal 5 milliseconden of minder.The average write latency, at the 50th percentile, is usually 5 milliseconds or less. Azure Cosmos-accounts die verschillende regio's omvatten en die zijn geconfigureerd met sterke consistentie vormen een uitzonde ring op deze garantie.Azure Cosmos accounts that span several regions and are configured with strong consistency are an exception to this guarantee.

Schrijf latentie en sterke consistentieWrite latency and Strong consistency

Voor Azure Cosmos-accounts die zijn geconfigureerd met een sterke consistentie van meer dan één regio, is de schrijf latentie gelijk aan twee maal een round-trip tijd (RTT) tussen de twee versste regio's, plus 10 milliseconden in het 99e percentiel.For Azure Cosmos accounts configured with strong consistency with more than one region, the write latency is equal to two times round-trip time (RTT) between any of the two farthest regions, plus 10 milliseconds at the 99th percentile. Een hoge netwerk-RTT tussen de regio's wordt omgezet naar een hogere latentie voor Cosmos DB aanvragen omdat de sterke consistentie pas een bewerking heeft voltooid nadat u hebt gecontroleerd of deze is doorgevoerd voor alle regio's binnen een account.High network RTT between the regions will translate to higher latency for Cosmos DB requests since strong consistency completes an operation only after ensuring that it has been committed to all regions within an account.

De exacte RTT-latentie is een functie van de snelheid van de afstand en de Azure-netwerk topologie.The exact RTT latency is a function of speed-of-light distance and the Azure networking topology. Azure-netwerken bieden geen latentie-Sla's voor de RTT tussen twee Azure-regio's, maar het publiceert Azure Network round-trip-latentie statistieken.Azure networking doesn't provide any latency SLAs for the RTT between any two Azure regions, however it does publish Azure network round-trip latency statistics. Voor uw Azure Cosmos-account worden replicatie latenties weer gegeven in de Azure Portal.For your Azure Cosmos account, replication latencies are displayed in the Azure portal. U kunt de Azure Portal (Ga naar de Blade metrische gegevens, het tabblad consistentie selecteren) gebruiken om de replicatie latentie te controleren tussen verschillende regio's die zijn gekoppeld aan uw Azure Cosmos-account.You can use the Azure portal (go to the Metrics blade, select Consistency tab) to monitor the replication latencies between various regions that are associated with your Azure Cosmos account.

Belangrijk

Sterke consistentie voor accounts met regio's van meer dan 5000 mijl (8000 kilo meters) wordt standaard geblokkeerd als gevolg van een hoge schrijf latentie.Strong consistency for accounts with regions spanning more than 5000 miles (8000 kilometers) is blocked by default due to high write latency. Neem contact op met de ondersteuning om deze functie in te scha kelen.To enable this capability please contact support.

Consistentie niveaus en door VoerConsistency levels and throughput

  • Voor sterke en gebonden veroudering worden Lees bewerkingen uitgevoerd voor twee replica's in een vier replicaset (minderheids quorum) om consistentie garanties te bieden.For strong and bounded staleness, reads are done against two replicas in a four replica set (minority quorum) to provide consistency guarantees. Sessie, consistent voor voegsel en uiteindelijk mogelijke lees bewerkingen met één replica.Session, consistent prefix and eventual do single replica reads. Het resultaat is dat, voor hetzelfde aantal aanvraag eenheden, de Lees doorvoer voor sterke en gebonden veroudering de helft van de andere consistentie niveaus is.The result is that, for the same number of request units, read throughput for strong and bounded staleness is half of the other consistency levels.

  • Voor een bepaald type schrijf bewerking, zoals invoegen, vervangen, upsert en verwijderen, is de schrijf doorvoer voor aanvraag eenheden identiek voor alle consistentie niveaus.For a given type of write operation, such as insert, replace, upsert, and delete, the write throughput for request units is identical for all consistency levels.

Consistentie niveauConsistency Level Quorum Lees bewerkingenQuorum Reads Quorum schrijf bewerkingenQuorum Writes
SterkStrong Lokale minderheidLocal Minority Wereld wijde meerderheidGlobal Majority
Gebonden verouderingBounded Staleness Lokale minderheidLocal Minority Lokale meerderheidLocal Majority
BeëindigenSession Enkele replica (met sessie token)Single Replica (using session token) Lokale meerderheidLocal Majority
Consistent voor voegselConsistent Prefix Enkele replicaSingle Replica Lokale meerderheidLocal Majority
UiteindelijkeEventual Enkele replicaSingle Replica Lokale meerderheidLocal Majority

Notitie

De kosten voor het lezen van de RU/s voor lokale minderheids Lees bewerkingen zijn twee keer zoveel consistentie niveaus, omdat Lees bewerkingen worden uitgevoerd van twee replica's om consistentie garanties te bieden voor sterke en gebonden veroudering.The RU/s cost of reads for Local Minority reads are twice that of weaker consistency levels because reads are made from two replicas to provide consistency guarantees for Strong and Bounded Staleness.

Consistentie niveaus en gegevens duurzaamheidConsistency levels and data durability

Binnen een wereld wijd gedistribueerde database omgeving is er een rechtstreekse relatie tussen het consistentie niveau en de duurzaamheid van de gegevens in de aanwezigheid van een regionale storing.Within a globally distributed database environment there is a direct relationship between the consistency level and data durability in the presence of a region-wide outage. Wanneer u uw bedrijfs continuïteits plan ontwikkelt, moet u weten wat de Maxi maal toegestane tijd is voordat de toepassing volledig wordt hersteld na een storende gebeurtenis.As you develop your business continuity plan, you need to understand the maximum acceptable time before the application fully recovers after a disruptive event. De tijd die nodig is om een toepassing volledig te herstellen, wordt de beoogde herstel tijd ( RTO ) genoemd.The time required for an application to fully recover is known as recovery time objective ( RTO ). U moet ook inzicht krijgen in de maximale periode van recente gegevens updates die de toepassing kan afnemen bij het herstellen na een storende gebeurtenis.You also need to understand the maximum period of recent data updates the application can tolerate losing when recovering after a disruptive event. De tijds periode van updates die u mogelijk wilt verliezen, is Recovery Point Objective ( RPO ) genoemd.The time period of updates that you might afford to lose is known as recovery point objective ( RPO ).

In de onderstaande tabel wordt de relatie tussen consistentie model en gegevens duurzaamheid gedefinieerd in aanwezigheid van een regionale storing.The table below defines the relationship between consistency model and data durability in the presence of a region wide outage. Het is belang rijk te weten dat in een gedistribueerd systeem, zelfs met sterke consistentie, geen gedistribueerde data base met een RPO en RTO van nul is vanwege Cap theorema.It is important to note that in a distributed system, even with strong consistency, it is impossible to have a distributed database with an RPO and RTO of zero due to CAP Theorem.

Regio (s)Region(s) Replicatie modusReplication mode ConsistentieniveauConsistency level RPORPO RTORTO
11 Enkele of meerdere schrijf regio'sSingle or Multiple write regions Elk consistentie niveauAny Consistency Level < 240 minuten< 240 Minutes <1 week<1 Week
>1>1 Enkele schrijf regioSingle write region Sessie, consistent voor voegsel, uiteindelijkSession, Consistent Prefix, Eventual < 15 minuten< 15 minutes < 15 minuten< 15 minutes
>1>1 Enkele schrijf regioSingle write region Gebonden verouderingBounded Staleness K & TK & T < 15 minuten< 15 minutes
>1>1 Enkele schrijf regioSingle write region SterkStrong 00 < 15 minuten< 15 minutes
>1>1 Meerdere schrijf regio'sMultiple write regions Sessie, consistent voor voegsel, uiteindelijkSession, Consistent Prefix, Eventual < 15 minuten< 15 minutes 00
>1>1 Meerdere schrijf regio'sMultiple write regions Gebonden verouderingBounded Staleness K & TK & T 00

K = het aantal "K" versies (bijvoorbeeld updates) van een item.K = The number of "K" versions (i.e., updates) of an item.

T = het tijds interval ' t ' sinds de laatste update.T = The time interval "T" since the last update.

Voor een account van één regio is de minimum waarde K en T 10 schrijf bewerkingen of 5 seconden.For a single region account, the minimum value of K and T is 10 write operations or 5 seconds. Voor accounts met meerdere regio's is de minimale waarde van K en T 100.000 schrijf bewerkingen of 300 seconden.For multi-region accounts the minimum value of K and T is 100,000 write operations or 300 seconds. Hiermee wordt de minimale RPO voor gegevens gedefinieerd wanneer gebonden veroudering wordt gebruikt.This defines the minimum RPO for data when using Bounded Staleness.

Sterke consistentie en meerdere schrijf regio'sStrong consistency and multiple write regions

Cosmos-accounts die zijn geconfigureerd met meerdere schrijf regio's, kunnen niet worden geconfigureerd voor sterke consistentie omdat het niet mogelijk is dat een gedistribueerd systeem een RPO van nul en een RTO van nul levert.Cosmos accounts configured with multiple write regions cannot be configured for strong consistency as it is not possible for a distributed system to provide an RPO of zero and an RTO of zero. Daarnaast zijn er geen schrijf latentie voordelen voor het gebruik van sterke consistentie met meerdere schrijf regio's, omdat een schrijf bewerking naar een regio moet worden gerepliceerd en doorgevoerd voor alle geconfigureerde regio's binnen het account.Additionally, there are no write latency benefits on using strong consistency with multiple write regions because a write to any region must be replicated and committed to all configured regions within the account. Dit resulteert in dezelfde schrijf latentie als een account voor een enkele schrijf regio.This results in the same write latency as a single write region account.

Meer artikelenAdditional reading

Lees de volgende artikelen voor meer informatie over consistentie concepten:To learn more about consistency concepts, read the following articles:

Volgende stappenNext steps

Lees de volgende artikelen voor meer informatie over de consistentie niveaus in Azure Cosmos DB:To learn more about consistency levels in Azure Cosmos DB, read the following articles: