Azure Cosmos DB 能否创建全集合级唯一键而非按分区键？

Unfortunately, Azure Cosmos DB doesn't natively support collection-wide unique keys—all built-in unique key constraints are inherently scoped to a single partition key value.

Here's the reasoning behind this design: Cosmos DB is built for global scalability and low-latency performance, which depends on partitioning data across multiple physical nodes. Enforcing cross-partition uniqueness would require constant coordination across all partitions during every write operation, which would eliminate the performance and scalability benefits of partitioning (introducing cross-node locks and significant latency). The unique key policy is intentionally partition-scoped to preserve the system's core performance guarantees.

If you need to enforce collection-wide uniqueness, here are practical workarounds tailored to different use cases:

1. Use a Single Partition Key for the Entire Collection #

If your dataset is small (under 20GB, the maximum size of a single Cosmos DB partition) and doesn't require high throughput scaling, you can assign a fixed partition key value to all documents (e.g., {"_pk": "global"}). With all data in one partition, your unique key policy will effectively apply across the entire collection.

Pros: Straightforward to implement using native Cosmos DB features.
Cons: Not scalable for large datasets—you'll hit partition size limits and won't be able to scale throughput beyond a single partition's capacity.

2. Application-Level Validation with a Dedicated Unique Index Collection #

For scalable scenarios, create a separate "unique index" collection to track values that need to be globally unique. This collection can use a fixed partition key (if the number of unique values is manageable) or use the unique value itself as the partition key.

The workflow would look like this:

• Before inserting a document into your main collection, first attempt to insert a tiny document into the index collection. Use the unique value as either the id (which is inherently unique per partition) or define a unique key policy on the index collection for that value.
• If the index insertion succeeds (no duplicate error), proceed to insert the main document.
• If the index insertion fails due to a unique key violation, reject the main insert and notify the user of the duplicate.

To reduce race conditions, you can use Cosmos DB's transactional batch operations if both the index and main document inserts target the same partition. For cross-partition cases, implement retries and conflict resolution logic to handle concurrent writes.

Pros: Scalable for large datasets, maintains low latency.
Cons: Adds extra write operations and complexity to your application logic. Requires careful handling of race conditions.

3. Reactive Cleanup (Not Ideal for Strict Uniqueness) #

You can use Cosmos DB triggers or Azure Functions to detect duplicates after insertion and delete or flag them. However, this approach is reactive—duplicates may exist temporarily before being cleaned up, so it's only suitable for use cases where strict, real-time uniqueness isn't critical.

Pros: Minimal changes to your core write logic.
Cons: Doesn't prevent duplicates, only resolves them after the fact. Can lead to temporary data inconsistency.

In short, while native collection-wide unique keys aren't available, you can pick a workaround based on your scalability needs and how strictly you need to enforce uniqueness.

内容的提问来源于stack exchange，提问作者apero