In today's global, data-intensive landscape, applications need more than just a simple database. They require a service that can handle massive scale, near-instantaneous response times, and a variety of data models across multiple regions. This is where Azure Cosmos DB shines. As Microsoft's globally distributed, multi-model database service, it's designed for applications that demand high availability, low latency, and massive scalability anywhere in the world.
This comprehensive guide will provide a deep dive into Azure Cosmos DB, exploring its unique architecture, powerful features, and tangible benefits. We'll also compare it to other cloud database services, address common misconceptions, and walk through a practical design example. By the end, you'll have a clear understanding of why Cosmos DB is a go-to choice for building modern, globally-distributed applications.
1. What is Azure Cosmos DB?
Azure Cosmos DB is a fully managed, globally distributed, NoSQL database service offered by Microsoft. It's built from the ground up to provide guaranteed low latency at the 99th percentile, elastic scalability, and high availability. Unlike traditional databases, Cosmos DB is a multi-model database, meaning it supports multiple popular data models and APIs, including:
SQL (Core) API: The default API for document data, using a SQL-like query language.
MongoDB API: For applications already using MongoDB, offering a familiar experience.
Cassandra API: For applications that require a wide-column store.
Gremlin API: For graph-based data models.
Table API: For key-value data models, compatible with Azure Table Storage.
This multi-model capability gives you the flexibility to choose the right data model for your application's needs without having to switch database services.
2. Key Features of Azure Cosmos DB
Cosmos DB stands out from the competition with a set of powerful, integrated features:
Global Distribution: With a single click, you can replicate your data across any of the Azure regions worldwide. This brings your data closer to your users, significantly reducing latency.
Guaranteed Low Latency: Cosmos DB offers a 99.999% availability SLA and a guaranteed end-to-end latency for reads and writes at the 99th percentile.This is a crucial feature for real-time applications.
Elastic Scalability: You can scale both storage and throughput (measured in Request Units or RUs) independently and elastically. This allows your database to handle sudden traffic spikes without manual intervention.
Multi-Model and Multi-API Support: As mentioned, this is a core differentiator, enabling you to use the right data model for the job, be it document, key-value, graph, or wide-column.
Five Consistency Models: Cosmos DB provides a spectrum of five well-defined consistency models: Strong, Bounded Staleness, Session, Consistent Prefix, and Eventual. This allows you to fine-tune the trade-off between consistency, latency, and throughput.
Change Feed: A persistent, append-only log of changes to your Cosmos DB containers.It's perfect for building event-driven architectures and microservices.
3. Architecture of Azure Cosmos DB
The internal architecture of Cosmos DB is a distributed, horizontally scalable system designed for global reach and high performance. Here are the key components:
Logical Partitioning: Data is automatically partitioned across multiple physical servers based on a partition key. This partitioning is a crucial component for horizontal scaling. You define the partition key, which is used to distribute data and queries. A well-chosen partition key is essential for balanced throughput and storage.
Physical Partitions: Each logical partition is stored on one or more physical partitions. A physical partition is a set of replicas, a concept that is fundamental to Cosmos DB's high availability.
Replica Sets: Within each physical partition, data is replicated across a set of replica machines for high availability and durability. This is part of the system's fault tolerance, ensuring data is available even if a replica fails.
Resource Governance: Cosmos DB uses Request Units (RUs) as a single, normalized currency to measure the cost of database operations. This abstraction simplifies resource governance. Every database operation, from a simple point read to a complex query, consumes a certain number of RUs. This provides a predictable performance model.
Global Distribution: When you add a new region, Cosmos DB automatically replicates your data to that region and makes it available for both reads and writes. It also handles the complex replication and conflict resolution behind the scenes.
4. What are the Benefits of Azure Cosmos DB?
The unique architecture and features of Cosmos DB translate into significant benefits for developers and businesses:
Massive Scalability: It can handle petabytes of data and billions of requests per day, making it suitable for even the largest applications.
Low-Latency Guarantee: The built-in, global distribution and the five consistency models allow you to meet the demanding latency requirements of modern applications.
High Availability: With its multi-region replication and 99.999% availability SLA, your application can remain online even during regional outages.
Cost-Effective: You only pay for the throughput and storage you provision. The serverless tier allows you to pay per operation, making it ideal for unpredictable workloads.
Simplified Development: The multi-model APIs allow developers to use familiar tools and SDKs, reducing the learning curve. The Change Feed also simplifies building event-driven, responsive applications.
5. Compare Azure Cosmos DB with AWS and Google Service
When considering a globally distributed NoSQL database, you'll likely compare Cosmos DB with its main competitors.
Feature | Azure Cosmos DB | AWS DynamoDB | Google Cloud Firestore |
Managed Service | Fully managed, multi-model, globally distributed NoSQL. | Fully managed key-value and document database. | Fully managed document database. |
Pricing Model | Provisioned Throughput (RUs) or Serverless. | Provisioned Throughput (RCU/WCU) or On-Demand. | Pay-per-read/write and storage. |
Consistency | Five well-defined consistency models. | Strong and Eventual consistency. | Strong consistency. |
Global Distribution | Single-click, multi-region replication. | Global Tables for multi-region replication. | Automatic multi-region replication for High Availability. |
Data Models | Multi-model: Document, Key-Value, Graph, Wide-Column. | Key-Value, Document. | Document, Collections. |
Unique Features | Five consistency levels, Change Feed. | Global Tables, Streams. | Real-time listeners, offline support for mobile apps. |
While all three services are excellent, Cosmos DB's combination of five consistency models and its multi-model support gives it a distinct advantage for applications that need fine-grained control over performance and data types.
6. Hard Limits and Misconceptions on Azure Cosmos DB
While Cosmos DB is incredibly powerful, it's important to be aware of its limits and common misconceptions:
Partition Key is Critical: A poorly chosen partition key is the biggest performance killer. If all your writes go to a single partition, you create a "hot partition," limiting your scalability and consuming all your throughput on one node.
RU Consumption: All operations, even a simple point read, consume RUs Understanding and optimizing your RU consumption is key to managing costs.
Storage and Throughput: While they are elastic, they are not infinite. Each physical partition has limits on both storage (currently up to 50 GB) and throughput (currently up to 10,000 RUs). You need to plan your partitioning to avoid hitting these limits.
"Serverless means free": The Serverless tier bills you per operation, but it is not free. It's cost-effective for spiky or low-traffic workloads but can become more expensive than the provisioned throughput model for consistently high-traffic applications.
7. Top 10 Real-World Use Case Scenarios
IoT: Ingesting and processing massive streams of telemetry data from millions of devices with low latency.
Gaming: Storing and synchronizing player data, game states, and leaderboards globally with low latency.
E-commerce: Providing a scalable catalog, user profiles, and order history for online retail.
Retail and Marketing: Storing user sessions, personalization data, and real-time marketing analytics.
Mobile Applications: Serving as a globally-distributed backend for mobile apps that need a highly available and low-latency data store.
Web and Mobile Catalogs: Handling high-volume reads for product catalogs and user-generated content.
Financial Services: Processing real-time financial transactions and market data.
Real-Time Analytics: Ingesting and serving data for real-time dashboards and analytics.
Change Feed for Microservices: Building event-driven microservices that react to changes in the database.
Global B2B Applications: Serving a global customer base with a single, highly available database.
8. Azure Cosmos DB Availability, Resilience, Failover, and Backup
Cosmos DB's design is inherently resilient and built for high availability.
High Availability: Cosmos DB offers an SLA of 99.999% for multi-region accounts. Within a single region, it guarantees 99.99% availability. This is achieved through its replication model, where data is synchronously replicated across at least four replicas in the primary region.
Resilience and Failover: When you enable multi-region writes, the service automatically handles conflict resolution. If a region fails, Cosmos DB automatically detects it and fails over to another designated region. This failover process is nearly instantaneous and happens without any application downtime.
Backup and Restore: Cosmos DB provides two backup modes:
Continuous Backup: The default, offering a point-in-time restore to any second within the last 30 days. This is great for recovering from accidental deletions or corruptions.
Periodic Backup: A legacy mode that backs up your data every 4 hours and retains the last two backups.
9. Design Step-by-Step on Azure Cosmos DB with Code Example
Let's design a simple social media application's data model in Azure Cosmos DB using the SQL API.
Scenario: A social media platform that needs to store user profiles and their posts. We need to handle a large number of reads and writes and distribute data globally.
Step 1: Choose a Partition Key
A great partition key will have high cardinality and distribute data evenly. For user profiles and posts, userId
is an excellent choice. This allows us to store a user's profile and their posts in the same logical partition, enabling efficient queries.
Step 2: Create a Cosmos DB Account and Database
Using the Azure CLI, you can create a new Cosmos DB account.
az cosmosdb create --name my-cosmos-db --resource-group my-resource-group \
--locations "East US" "West Europe" --default-consistency-level Session \
--kind GlobalDocumentDB
Step 3: Create a Container (Collection)
Now, create a container for users
and a container for posts
within the database. We'll use the same userId
as the partition key for both.
// C# example using the Cosmos DB .NET SDK
// Create the 'users' container
ContainerResponse userContainerResponse = await database.CreateContainerIfNotExistsAsync(
"users",
"/userId" // Partition key path
);
// Create the 'posts' container
ContainerResponse postContainerResponse = await database.CreateContainerIfNotExistsAsync(
"posts",
"/userId" // Partition key path
);
Step 4: Insert and Query Data
Now you can write and query data. By using the partition key in your queries, you can ensure they are "single-partition" queries, which are the most efficient and consume the fewest RUs.
// Insert a new user and post
var user = new { id = "user-123", userId = "user-123", name = "John Doe" };
await userContainer.CreateItemAsync(user, new PartitionKey(user.userId));
var post = new { id = "post-abc", userId = "user-123", content = "Hello, world!" };
await postContainer.CreateItemAsync(post, new PartitionKey(post.userId));
// Query for a single user and their posts (an efficient, single-partition query)
var sqlQuery = "SELECT * FROM c WHERE c.userId = 'user-123'";
FeedIterator<dynamic> queryResultSetIterator = postContainer.GetItemQueryIterator<dynamic>(sqlQuery);
This design ensures that all a single user's data is co-located, allowing for fast reads and writes. It also makes it easy to add more regions as your user base grows.
10. Final Conclusion
Azure Cosmos DB is a game-changer for building modern, globally-distributed applications. Its unique architecture, with features like global distribution, multi-model support, and guaranteed low latency, makes it a top-tier choice for mission-critical workloads. By understanding its key concepts, especially partitioning and Request Units, you can design a database that is not only scalable and performant but also cost-effective. Embrace the power of Cosmos DB and unlock the true potential of your applications.
11. Run an N-tier application in multiple Azure Stack Hub regions for high availability
Running an N-tier application across multiple Azure Stack Hub regions for high availability requires a distributed architecture with a global traffic manager and data synchronization. The process involves deploying an identical application stack to each Stack Hub and configuring cross-region connectivity for failover.
1. Architectural Design
The core architectural pattern for this scenario is a multi-region active-passive or active-active deployment. We'll design for an active-passive setup, which is simpler and more common for disaster recovery. A global traffic manager routes all user traffic to the primary region. In the event of a failure, it automatically redirects traffic to the secondary region.
Primary Region (Azure Stack Hub A): All application tiers are deployed here and are actively serving traffic.
Secondary Region (Azure Stack Hub B): A hot standby for disaster recovery. All application tiers are deployed here, and data is replicated from the primary.
Global Traffic Manager: An Azure-based service (like Azure Traffic Manager) or a third-party equivalent, is used to route traffic and monitor endpoint health.
2. Step-by-Step Implementation
Step 1: Network Configuration
First, set up a virtual network (VNet) in each Azure Stack Hub instance. These VNets will host your application tiers.
Code: Use Azure CLI to create a VNet and subnets in each Stack Hub.
# In Azure Stack Hub A (Primary Region)
az network vnet create \
--name app-vnet \
--resource-group rg-primary \
--address-prefix 10.0.0.0/16 \
--location "StackHubLocationA"
az network vnet subnet create \
--name web-subnet \
--resource-group rg-primary \
--vnet-name app-vnet \
--address-prefixes 10.0.1.0/24
# Repeat for business and data subnets
# Repeat for Azure Stack Hub B (Secondary Region), using a different IP range (e.g., 10.1.0.0/16)
Step 2: Deploy and Configure Application Tiers
Deploy identical VMs and application components to the corresponding subnets in both Stack Hub regions.
a. Web Tier Deployment
Deploy web servers (VMs) and a public load balancer in the web-subnet of each Stack Hub.
Code: Use Azure CLI to create a public IP and load balancer.
# In Azure Stack Hub A
az network public-ip create \
--resource-group rg-primary \
--name web-tier-ip \
--allocation-method Static
az network lb create \
--resource-group rg-primary \
--name web-lb
# Create VMs and associate with the load balancer backend pool. Repeat for Stack Hub B.
b. Business Tier Deployment
Deploy application VMs in the business-subnet of each Stack Hub. These are typically accessed privately from the web tier.
c. Data Tier Deployment
This is the most critical step for high availability. Use a data synchronization technology to replicate data between regions. For SQL Server, Always On Availability Groups are a great choice.
Code: Use Transact-SQL (T-SQL) to configure an Always On Availability Group.
-- On the primary SQL Server instance in Stack Hub A
CREATE AVAILABILITY GROUP [MyAG]
WITH (AUTOMATED_BACKUP_PREFERENCE = SECONDARY)
FOR DATABASE [MyDatabase]
REPLICA ON 'PrimarySQLServer' WITH (
ENDPOINT_URL = 'tcp://PrimarySQLServer.domain:5022',
AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
FAILOVER_MODE = AUTOMATIC,
SEEDING_MODE = AUTOMATIC
),
'SecondarySQLServer' WITH (
ENDPOINT_URL = 'tcp://SecondarySQLServer.domain:5022',
AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT, -- Use async for cross-region
FAILOVER_MODE = MANUAL,
SEEDING_MODE = AUTOMATIC
);
GO
Note: For cross-region replication, asynchronous commit is generally used to avoid high latency impacting the primary region's performance.
Step 3: Configure Global Traffic Manager
In your global Azure subscription, create an Azure Traffic Manager profile to direct user traffic to the public endpoints of your application in each Stack Hub.
Code: Use Azure CLI to create a Traffic Manager profile and add endpoints.
# In your global Azure subscription
az network traffic-manager profile create \
--name app-traffic-manager \
--resource-group global-rg \
--routing-method Priority --unique-dns-name myapp
az network traffic-manager endpoint create \
--resource-group global-rg \
--profile-name app-traffic-manager \
--name endpoint-primary \
--type external-endpoints \
--target-resource-id "/subscriptions/.../publicIPAddresses/web-tier-ip" \
--endpoint-location "StackHubLocationA" \
--priority 1
az network traffic-manager endpoint create \
--resource-group global-rg \
--profile-name app-traffic-manager \
--name endpoint-secondary \
--type external-endpoints \
--target-resource-id "/subscriptions/.../publicIPAddresses/web-tier-ip-secondary" \
--endpoint-location "StackHubLocationB" \
--priority 2
Priority Routing: This configuration sends all traffic to
endpoint-primary
. If that endpoint fails a health check, Traffic Manager automatically fails over toendpoint-secondary
.
Step 4: Testing and Monitoring
Finally, rigorously test the failover process.
Simulate Failure: Shut down a web server or the entire application stack in the primary region.
Verify Failover: Confirm that Traffic Manager detects the failure and redirects all traffic to the secondary region.
Monitor Health: Set up monitoring and alerts for both endpoints within Traffic Manager to ensure you are notified of any outages.
12. Azure Cosmos Database Knowledge Practice Questions
What is the primary purpose of Azure Cosmos DB?
A. A relational database for structured data.
B. A globally distributed, multi-model NoSQL database.
C. A key-value store for in-memory caching.
D. A data warehouse for large-scale analytics.
Answer: B. Cosmos DB is a globally distributed, multi-model NoSQL service designed for low-latency, high-availability applications.
53
What is a "Request Unit" (RU)?
A. A unit of data storage.
B. A unit of data transfer.
C. A performance currency to measure the cost of database operations.
D. A unit of CPU usage.
Answer: C. RUs are a single, normalized measure of the throughput consumed by database operations.
How many consistency models does Azure Cosmos DB offer?
A. 2
B. 3
C. 4
D. 5
Answer: D. It offers five models: Strong, Bounded Staleness, Session, Consistent Prefix, and Eventual.
What is the main purpose of a "partition key"?
A. To encrypt data at rest.
B. To define the schema for a collection.
C. To distribute data and throughput across physical partitions.
D. To enforce referential integrity.
Answer: C. The partition key is crucial for horizontal scaling and data distribution.
Which of the following is a supported API in Azure Cosmos DB?
A. Oracle
B. PostgreSQL
C. MongoDB
D. SQL Server
Answer: C. Cosmos DB has native APIs for MongoDB, Cassandra, Gremlin, and Table in addition to its Core SQL API.
What does a "hot partition" refer to?
A. A partition with too much data.
B. A partition that is receiving a disproportionate amount of requests.
C. A partition that is encrypted.
D. A partition that is offline.
Answer: B. A hot partition is a key anti-pattern that can limit your application's performance.
What is the primary benefit of global distribution in Cosmos DB?
A. It reduces storage costs.
B. It provides a single point of failure.
C. It brings data closer to users to reduce latency.
D. It simplifies data modeling.
Answer: C. Global distribution is all about reducing latency and improving availability for a global user base.
What is the SLA for a multi-region Azure Cosmos DB account?
A. 99.9%
B. 99.99%
C. 99.999%
D. 100%
Answer: C. Cosmos DB guarantees 99.999% availability for multi-region accounts.
Which of the following describes the "Change Feed" feature?
A. A way to update existing documents.
B. A synchronous log of changes to a container.
C. A persistent, append-only log of changes to a container.
D. A way to change the consistency level.
Answer: C. The Change Feed is used for building event-driven architectures.
When would you use the "Strong" consistency model?
A. When you need the highest performance and don't care about data staleness.
B. When you need to read the most up-to-date data with no exceptions.
C. When you need to read the data from a specific session.
D. When you need to ensure writes are ordered.
Answer: B. Strong consistency guarantees that a read always returns the most recent committed version of an item.
61
What is the maximum storage for a single logical partition?
A. 10 GB
B. 20 GB
C. 30 GB
D. 50 GB
Answer: D. A logical partition can grow up to 50 GB.
Which backup mode allows for point-in-time restore to any second within the last 30 days?
A. Periodic Backup
B. Continuous Backup
C. Manual Backup
D. All of the above
Answer: B. Continuous Backup is a key feature for fine-grained recovery.
What is the main benefit of the Serverless tier?
A. You pay for provisioned throughput.
B. It provides a guaranteed 99.999% uptime.
C. You only pay for the operations you consume.
D. It supports all five consistency models.
Answer: C. The Serverless tier's pay-per-operation model is ideal for spiky workloads.
How does Cosmos DB handle a regional failover?
A. It requires a manual script to be run.
B. It automatically fails over to a designated region without any downtime.
C. It fails over to the public internet.
D. It requires a third-party service to manage the failover.
Answer: B. Automatic failover is a built-in feature for high availability.
True or False: A single Cosmos DB container can hold multiple data models.
A. True
B. False
Answer: B. Each container is tied to a single API and data model.
Which of the following is NOT a good partition key?
A.
userId
B.
productId
C.
sessionId
D.
timestamp
Answer: D.
timestamp
is a poor partition key because it can lead to hot partitions as all new writes go to the same partition.
Which consistency model is the default for a single-region account?
A. Strong
B. Session
C. Eventual
D. Consistent Prefix
Answer: B. Session consistency is the default, offering a good balance of performance and consistency for a single session.
What is a "physical partition"?
A. A logical division of data.
B. A set of replicas on a server.
C. The entire database.
D. A single document.
Answer: B. A physical partition is the actual unit of scale for storage and throughput.
Which API would you use to store key-value data in a legacy application?
A. Gremlin API
B. Table API
C. MongoDB API
D. SQL (Core) API
Answer: B. The Table API is compatible with Azure Table Storage and is ideal for key-value data.
What is the primary benefit of the multi-model capability?
A. It is easier to use.
B. It reduces latency.
C. It allows you to use the right data model for the job.
D. It guarantees a 99.999% uptime.
Answer: C. The multi-model approach provides unparalleled flexibility in data modeling.
What is the primary competitor to Cosmos DB from AWS?
A. AWS RDS
B. AWS DynamoDB
C. AWS S3
D. AWS Aurora
Answer: B. AWS DynamoDB is the direct competitor for a globally distributed NoSQL database.
What is the main purpose of the "Gremlin API"?
A. To store document data.
B. To store key-value data.
C. To store graph-based data.
D. To store wide-column data.
Answer: C. The Gremlin API is used for graph databases.
Which of the following is a common use case for the Change Feed?
A. Building a backup solution.
B. Triggering a function to resize an image when a document is created.
C. Running complex SQL queries.
D. Changing the partition key.
Answer: B. The Change Feed is perfect for building event-driven microservices that react to data changes.
When would you use the "Bounded Staleness" consistency model?
A. When you need the most up-to-date data.
B. When you need to read from a specific session.
C. When you need to read data that is guaranteed to be within a certain number of versions or time interval behind the primary.
D. When you can tolerate high data staleness.
Answer: C. Bounded Staleness provides a predictable level of staleness.
What is the purpose of the Cosmos DB Emulator?
A. To run Cosmos DB on a Linux VM.
B. To test and develop applications locally without an Azure account.
C. To emulate a different database service.
D. To test a multi-region setup.
Answer: B. The Emulator is a local version of Cosmos DB for development purposes.
Which of the following statements about Cosmos DB pricing is correct?
A. You pay for storage and data transfer only.
B. You pay for storage and provisioned throughput (RUs).
C. You pay for each individual query.
D. You pay for CPU usage.
Answer: B. The primary cost components are storage and throughput
What is the main difference between "single-partition" and "cross-partition" queries?
A. Single-partition queries are more expensive.
B. Single-partition queries are faster and more efficient.
C. Cross-partition queries do not require a partition key.
D. Cross-partition queries are always faster.
Answer: B. Single-partition queries are highly efficient because they are routed to a single physical partition.
What does the "Consistent Prefix" consistency model guarantee?
A. All reads will be perfectly consistent.
B. Updates are seen in the same order they were written, but can be out of date.
C. All reads will be from the same session.
D. All reads are guaranteed to be from a single replica.
Answer: B. Consistent Prefix ensures that you will not see a write out of order.
What is the primary use case for the "Cassandra API"?
A. Document storage.
B. Graph database.
C. Wide-column store.
D. Relational database.
Answer: C. The Cassandra API is for applications that use the wide-column data model.
74
What is the purpose of the "Indexing" policy in Cosmos DB?
A. To increase latency.
B. To improve query performance.
C. To reduce storage costs.
D. To enforce data integrity.
Answer: B. The indexing policy determines which properties are indexed to improve query performance.
75
What is the main benefit of the Continuous Backup mode?
A. It only backs up data once a day.
B. It provides granular point-in-time restore to any second.
C. It is a free feature.
D. It automatically restores data on a schedule.
Answer: B. Continuous Backup is a key feature for fine-grained recovery.
When you add a new region to a Cosmos DB account, what happens to the data?
A. It is manually moved to the new region.
B. It is automatically replicated to the new region.
C. A new database is created.
D. The old data is deleted.
Answer: B. Cosmos DB's global distribution automatically handles data replication.
What is the key difference between the Cosmos DB SQL API and the MongoDB API?
A. The SQL API is for relational data.
B. The MongoDB API uses a different query language.
C. The SQL API is for document data only.
D. The MongoDB API does not support indexing.
Answer: B. The MongoDB API uses the familiar MongoDB query language.
What is the
_ts
property in a Cosmos DB document?A. The time-to-live setting.
B. The document's ID.
C. A system property that contains the timestamp of the last modification.
D. The partition key.
Answer: C.
_ts
is a system property used for optimistic concurrency and change feed.
What is a logical partition in Cosmos DB?
A. A physical server.
B. A group of items that share the same partition key value.
C. A single item in a collection.
D. A database.
Answer: B. A logical partition is a conceptual grouping of data.
Which of the following is a common anti-pattern in Cosmos DB design?
A. Choosing a partition key with high cardinality.
B. Using a "point read" to get a single document.
C. Using a partition key with low cardinality.
D. Creating multiple containers.
Answer: C. A partition key with low cardinality can lead to hot partitions.
What is the main benefit of using Cosmos DB for an IoT application?
A. Its strong consistency model.
B. Its ability to handle massive data streams with low latency.
C. Its relational data model.
D. Its fixed cost model.
Answer: B. Cosmos DB's scalable throughput and low latency are perfect for IoT data ingestion
Which of the following is a common reason for high RU consumption?
A. Running a simple point read.
B. Performing a single-partition query.
C. Running a cross-partition query.
D. All of the above are equally expensive.
Answer: C. Cross-partition queries are more expensive because they have to fan out to multiple physical partitions.
True or False: Cosmos DB automatically handles conflict resolution in a multi-region, multi-write setup.
A. True
B. False
Answer: A. Cosmos DB has built-in conflict resolution policies.
What is the purpose of the
id
property in a Cosmos DB document?A. It is the partition key.
B. It is the unique identifier within a logical partition.
C. It is the timestamp.
D. It is a system property.
Answer: B. The
id
property, along with the partition key, forms the unique key of a document.
What is the main benefit of the session consistency model?
A. It is the fastest.
B. It is the strongest.
C. It ensures that reads within a single client session are consistent.
D. It is the most cost-effective.
Answer: C. Session consistency is a good balance for most single-session applications.
What is the primary difference between a provisioned throughput and a serverless account?
A. Provisioned throughput is always cheaper.
B. Serverless is always faster.
C. Provisioned throughput has a fixed cost, while serverless bills per operation.
D. There is no difference.
Answer: C. The billing model is the core difference.
Which API would you use for a gaming application that needs to store and query player relationships?
A. SQL (Core) API
B. MongoDB API
C. Gremlin API
D. Table API
Answer: C. The Gremlin API is designed for graph-based data.
What is a "point read" in Cosmos DB?
A. A query that reads multiple documents.
B. The most efficient way to retrieve a single document.
C. A cross-partition query.
D. A query that uses a SQL-like language.
Answer: B. A point read is an efficient lookup by ID and partition key.
What is a "collection" in the MongoDB API equivalent to in the SQL API?
A. A database.
B. A container.
C. An item.
D. A partition key.
Answer: B. In the SQL API, a "container" is the equivalent of a "collection" in MongoDB.
What is the purpose of the TTL (Time-to-Live) feature?
A. To limit the number of documents in a container.
B. To automatically delete items after a specified time.
C. To encrypt a document.
D. To set the document's consistency level.
Answer: B. TTL is used for scenarios like session management and event history.
What is the main benefit of using a "Single-region" deployment?
A. It provides the highest availability.
B. It is the cheapest option.
C. It guarantees the lowest latency for a global audience.
D. It is the only way to use the SQL API.
Answer: B. A single-region deployment is the most cost-effective option.
How does Cosmos DB ensure high availability within a single region?
A. It replicates data to another region.
B. It relies on the client application to handle failover.
C. It synchronously replicates data across multiple replicas.
D. It has a manual backup and restore process.
Answer: C. The synchronous replication across replicas within a region is key to its high availability.
What happens if a logical partition exceeds 50 GB of data?
A. The database will become read-only.
B. The partition will be split into new physical partitions by Cosmos DB.
C. The application will receive an error.
D. The data will be automatically deleted.
Answer: B. Cosmos DB automatically handles the splitting of logical partitions into new physical partitions.
What is the main benefit of the multi-write feature in a multi-region account?
A. It is cheaper.
B. It reduces latency for reads only.
C. It allows clients to write data to any region, reducing latency for writes.
D. It is a legacy feature.
Answer: C. The multi-write feature is a key component for building global applications with low latency for both reads and writes.
No comments:
Post a Comment