Atvik
Mar 17, 9 PM - Mar 21, 10 AM
Taktu þátt í fundarröðinni til að byggja upp skalanlegar gervigreindarlausnir byggðar á raunverulegum notkunartilvikum með öðrum forriturum og sérfræðingum.
Nýskrá núnaÞessi vafri er ekki lengur studdur.
Uppfærðu í Microsoft Edge til að nýta þér nýjustu eiginleika, öryggisuppfærslur og tæknilega aðstoð.
APPLIES TO:
MongoDB
Unlike Azure Cosmos DB, the native MongoDB does not provide precisely defined consistency guarantees. Instead, native MongoDB allows users to configure the following consistency guarantees: a write concern, a read concern, and the isMaster directive - to direct the read operations to either primary or secondary replicas to achieve the desired consistency level.
When using Azure Cosmos DB’s API for MongoDB, the MongoDB driver treats your write region as the primary replica and all other regions are read replica. You can choose which region associated with your Azure Cosmos DB account as a primary replica.
Athugasemd
The default consistency model for Azure Cosmos DB is Session. Session is a client-centric consistency model which is not natively supported by either Cassandra or MongoDB. For more information on which consistency model to choose see, Consistency levels in Azure Cosmos DB
While using Azure Cosmos DB’s API for MongoDB:
The write concern is mapped to the default consistency level configured on your Azure Cosmos DB account.
Azure Cosmos DB will dynamically map the read concern specified by the MongoDB client driver to one of the Azure Cosmos DB consistency levels that is configured dynamically on a read request.
You can annotate a specific region associated with your Azure Cosmos DB account as "Primary" by making the region as the first writable region.
The following table illustrates how the native MongoDB write/read concerns are mapped to the Azure Cosmos DB consistency levels when using Azure Cosmos DB’s API for MongoDB:
If your Azure Cosmos DB 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. This metric is exposed in the Azure portal, to learn more, see Monitor Probabilistically Bounded Staleness (PBS) metric.
Probabilistic bounded staleness shows how eventual is your eventual consistency. 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 DB account. In other words, you can see the probability (measured in milliseconds) of getting strongly consistent reads for a combination of write and read regions.
Learn more about global distribution and consistency levels for Azure Cosmos DB:
Atvik
Mar 17, 9 PM - Mar 21, 10 AM
Taktu þátt í fundarröðinni til að byggja upp skalanlegar gervigreindarlausnir byggðar á raunverulegum notkunartilvikum með öðrum forriturum og sérfræðingum.
Nýskrá núnaÞjálfun
Eining
Use consistency models in Azure Cosmos DB for NoSQL - Training
Configure consistency on a sliding scale for Azure Cosmos DB for NoSQL.
Vottorð
Microsoft Certified: Azure Cosmos DB Developer Specialty - Certifications
Write efficient queries, create indexing policies, manage, and provision resources in the SQL API and SDK with Microsoft Azure Cosmos DB.
Skjöl
Manage consistency in Azure Cosmos DB
Learn how to configure and manage consistency levels in Azure Cosmos DB using Azure portal, .NET SDK, Java SDK, and various other SDKs
Global distribution with Azure Cosmos DB- under the hood
This article provides technical details relating to global distribution of Azure Cosmos DB
Consistency level choices - Azure Cosmos DB
Azure Cosmos DB has five consistency levels to help balance eventual consistency, availability, and latency trade-offs.