Venture into the world of Azure Infrastructure, where design meets functionality. Harness your skills and gain mastery over complex cloud structures to ace the AZ-305 Designing Microsoft Azure Infrastructure Solutions exam!
Gauge your current knowledge
Gauge your current knowledge
Azure Cosmos DB is a globally distributed, multi-model database service built for handling semi-structured data such as JSON documents. It provides automatic indexing, rich query capabilities, and tunable performance, all while scaling across regions. The service is designed to meet requirements for throughput, latency, consistency, and query flexibility, making it a central choice for storing semi-structured data in Azure.
Azure Cosmos DB offers several APIs, each optimized for different data models and existing application ecosystems. The SQL API lets you query JSON documents using a SQL-like syntax, which is the most common choice for new applications. The MongoDB API allows applications that already use MongoDB to connect to Cosmos DB with minimal code changes. The Cassandra API supports Cassandra-compatible workloads, and the Gremlin API is used for graph-based data. Select an API based on your team’s existing skills, the query patterns you need, and the consistency and latency requirements of your application.
Partitioning is the key to distributing data evenly across physical partitions. Choose a partition key with high cardinality—many unique values—so that no single partition becomes a hotspot. The partition key is part of every document and determines how writes and reads are distributed. Indexing is automatic by default: Azure Cosmos DB indexes every property unless you explicitly override the policy. You can tune the indexing policy to include or exclude paths, or to use composite indexes for complex queries, which reduces RU consumption and improves query performance.
Throughput is measured in Request Units (RUs) per second. You can provision throughput at the database or container level, and you can scale it up or down manually or with autoscale. For workloads with unpredictable traffic, serverless mode is available, where you pay only for the RUs consumed, with no minimum provisioning. This mode is ideal for development, test, or low-traffic scenarios. When designing for production, choose provisioned throughput for predictable performance and cost control, or autoscale to handle spikes without manual intervention.
Azure Cosmos DB offers five consistency levels that form a spectrum from strongest to weakest. Strong consistency guarantees that reads always see the latest write, but it adds latency because writes must be acknowledged by all replicas. Bounded staleness allows reads to lag behind writes by a configurable time interval or number of versions, reducing latency while providing a predictable bound. Session consistency is the default and works well for most applications: within a single client session, reads see the writes from that session. Consistent prefix guarantees that reads never see out-of-order writes, while eventual consistency gives the lowest latency and highest throughput, with no ordering guarantee. Choose the weakest level that your application’s correctness requirements allow, because weaker levels lower latency and RU cost.
Cost in Azure Cosmos DB comes from two main components: provisioned throughput (RUs) and data storage. RU cost depends on the operations you perform—reads, writes, and queries—and the size of documents. Storage cost is based on the amount of data you store, including indexes. Denormalizing data (storing duplicate or aggregated data) can improve read performance but increases storage cost. You should evaluate the trade-off between RU savings and additional storage expense. Using the JSON format reduces payload size compared to XML or other formats, lowering both RU and storage costs.
When designing your data model, store data in JSON format to keep documents small and queries efficient. Design tables and partitions so that frequent updates or queries target the same partition, which allows atomic batch transactions. Implement retry policies for transient errors such as rate limiting (HTTP 429), but do not retry non-retryable errors without proper handling. For operations that span multiple documents, use transactional batch operations within the same partition key to maintain consistency. These practices help you build a scalable, cost-effective solution for semi-structured data using Azure Cosmos DB.
StudyCerts
StudyCerts