11 Cosmos DB

Run these three commands:

C:/> az cosmosdb create --name alpacacosmosdbaccount --resource-group AlpacaRG --kind MongoDB --locations regionName=australiacentral failoverPriority=0 isZoneRedundant=False --default-consistency-level "Session" --capabilities EnableMongo

C:/> az cosmosdb mongodb database create --account-name alpacacosmosdbaccount --name alpacacosmosdb --resource-group AlpacaRG

C:/> az cosmosdb mongodb collection create --account-name alpacacosmosdbaccount --database-name alpacacosmosdb --name alpacacontainer --resource-group AlpacaRG --shard "/alpacakey" --throughput 400

The collection command sets the partition (shard) key and the initial throughput in RU/s.

RUs are the performance currency in Cosmos DB. Every operation (reads, writes, queries) consumes RUs based on its size and complexity. Throughput is provisioned as RU/s per container or database.

• Performance: Higher RU/s allows more operations/sec and lower latency under load.
• Cost: You’re billed by provisioned or autoscaled RU/s and by regions; complex queries and multi-region replication increase RU consumption.
• Rule of thumb: A simple 1 KB read ≈ 1 RU; complex queries cost more.

Enable autoscale at the account or collection layer:

• Account-level capability:

  C:/> az cosmosdb update --name alpacacosmosdbaccount --resource-group AlpacaRG --capabilities EnableAutoScale --max-throughput 10000

• Collection-level autoscale:

  C:/> az cosmosdb mongodb collection update --account-name alpacacosmosdbaccount --database-name alpacacosmosdb --name alpacacontainer --resource-group AlpacaRG --throughput-type autoscale --max-throughput 10000

max-throughput sets the ceiling autoscale can reach during spikes, helping control costs.

Add regions and set priorities:

C:/> az cosmosdb update --name alpacacosmosdbaccount --resource-group AlpacaRG --locations regionName=australiaeast failoverPriority=0 isZoneRedundant=False regionName=westeurope failoverPriority=1 isZoneRedundant=False

• failoverPriority=0 is primary; higher numbers are lower priority.
• isZoneRedundant=True spreads replicas across zones in a region (higher availability and cost).

Multi-region reduces read latency and improves availability; consider the added cost and potential write latency if misconfigured.

• Schema-less: Each document can have different fields; design app logic to handle optional/missing properties safely.
• Denormalize for reads: Embed related data (e.g., supplier details in product documents) to avoid joins and reduce RU cost on reads.
• Manage variability: Store flexible JSON per product type; only include fields that matter to that item.

Trade-off: Denormalization can increase write cost and storage; update carefully to keep duplicates in sync.

The partition key determines how data is distributed and scaled. Pick a key that:

• Has high cardinality (many distinct values) to spread load.
• Aligns with common query filters to minimize cross-partition queries.
• Is immutable (doesn’t change over time).

Example (MongoDB API):

C:/> az cosmosdb mongodb collection create --account-name alpacacosmosdbaccount --database-name alpacacosmosdb --name alpacacontainer --resource-group AlpacaRG --shard "/category" --throughput 400

• Use higher-cardinality keys or composite keys (e.g., region-category) to distribute load:

  C:/> az cosmosdb mongodb collection create --account-name alpacacosmosdbaccount --database-name alpacacosmosdb --name alpacacontainer --resource-group AlpacaRG --shard "/region-category" --throughput 400

• For time-heavy workloads, include time in the key (e.g., region-date).
• Design queries to filter on the partition key.
• Leverage automatic indexing and tune policies to keep RU costs down.

• Strong: Always the latest write; higher latency/less throughput.
• Bounded Staleness: Reads lag by time/versions; balanced guarantees.
• Session: Consistent within a client session; great default for apps.
• Consistent Prefix: Ordered reads, not necessarily latest.
• Eventual: Fastest and most available; data may be stale/out of order.

Set the default via CLI:

C:/> az cosmosdb update --name alpacacosmosdbaccount --resource-group AlpacaRG --kind MongoDB --default-consistency-level <Strong|BoundedStaleness|Session|ConsistentPrefix|Eventual>

Cosmos DB uses optimistic concurrency. Each document has an ETag (version). Your app:

• Reads the item and gets its ETag.
• Updates the item only if the ETag matches (If-Match).
• If the ETag changed, another writer updated it; retry the read-update cycle.

This avoids locks, preserves integrity under load, and is ideal for scenarios like inventory updates.

• APIs: NoSQL, Table, MongoDB, PostgreSQL, Cassandra, Gremlin.
• SDKs: .NET, Java, Node.js, Python, Go, PHP. Apps connect via the account’s endpoint/key; the SDK handles region routing.
• Integrations:
  • Azure Synapse Analytics for near real-time analytics at scale.
  • Azure Functions to react to Cosmos DB changes (e.g., update inventory, send notifications).
  • Azure Stream Analytics to process streams from Cosmos DB and act on live data.

• Choose throughput mode: Provisioned RU/s for steady workloads; autoscale for spiky traffic (cap with --max-throughput).
• Monitor RUs/latency with Azure Monitor; alert on thresholds:

  C:/> az monitor metrics alert create --name "High RU Consumption" --resource-group AlpacaRG --scopes /subscriptions/{sub}/resourceGroups/AlpacaRG/providers/Microsoft.DocumentDB/databaseAccounts/alpacacosmosdbaccount --condition "avg totalRequestUnits > 900" --window-size 5m --evaluation-frequency 1m --action {action-group}

• Tune indexing and queries to lower RU consumption.
• Consider vCore-based pricing (for PostgreSQL/MongoDB scenarios) for predictable, CPU-bound workloads.