Događaji
Izgradite inteligentne aplikacije
M03 17 21 - M03 21 10
Pridružite se seriji susreta kako biste sa kolegama programerima i stručnjacima izgradili skalabilna AI rješenja zasnovana na stvarnim slučajevima korištenja.
Registrirajte seOvaj preglednik više nije podržan.
Nadogradite na Microsoft Edge da iskoristite najnovije osobine, sigurnosna ažuriranja i tehničku podršku.
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.
Bilješka
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:
Događaji
Izgradite inteligentne aplikacije
M03 17 21 - M03 21 10
Pridružite se seriji susreta kako biste sa kolegama programerima i stručnjacima izgradili skalabilna AI rješenja zasnovana na stvarnim slučajevima korištenja.
Registrirajte seObučavanje
Modul
Use consistency models in Azure Cosmos DB for NoSQL - Training
Configure consistency on a sliding scale for Azure Cosmos DB for NoSQL.
Certifikacija
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.
Dokumentacija
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
Consistency level choices - Azure Cosmos DB
Azure Cosmos DB has five consistency levels to help balance eventual consistency, availability, and latency trade-offs.
How to convert session token formats in .NET SDK - Azure Cosmos DB
Learn how to convert session token formats to ensure compatibilities between different .NET SDK versions