Azure-docs: One document per partition key

[sumitt18]

Is one document per partition key a suggested/cost efficient partitioning scheme if it results in efficient querying? Any potential downsides to it?

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: d52f6d2e-f852-45ce-c205-ee4038d5ecd1
• Version Independent ID: e45b7f29-4d75-0dda-0f13-38b644213840
• Content: Partitioning in Azure Cosmos DB
• Content Source: articles/cosmos-db/partitioning-overview.md
• Service: cosmos-db
• GitHub Login: @markjbrown
• Microsoft Alias: mjbrown

[KalyanChanumolu-MSFT]

@sumitt18 Thank you for reaching out.
PartitionKey is defined at a container level. So there is one PartitionKey per container and one logical partition for each value of the PartitionKey.

I do not completely understand what you mean by one document per PartitionKey.
Please elaborate your concern or use case for us to better assist you.

[sumitt18]

@KalyanChanumolu-MSFT
If all the documents in my collection are independent of each other, is it a good idea to use partition key and id as the same value? This will cause each logical partition to contain exactly one document. Is this a good design?

An example would be using the emailId as the id and partition key for a user profile document.

[KalyanChanumolu-MSFT]

@sumitt18 Do you not have any other property in the document like user location, department etc that you can group the user profile information on?
Please evaluate what your access patterns would look like when you request this data. If you need to query on any other property then it will result in a cross partition query.

If you do not have any such requirement, you can go ahead and use the Id property.
You do not need to worry about creating too many logical partitions as it will be handled by CosmosDB.

[sumitt18]

@KalyanChanumolu-MSFT Thanks, closing this.

[vanthoainguyen]

I have a similar question. I have a large collection name orders and choose orderId as index and partition key. Obviously there is 1 document per partition. The order document size is quite large, about 90KB.

In Production, the metrics shows that Avg Throughput is 100K RU/s. The metrics page also show that we have about 16 partitions, 30GB each.

Is there any strategy to choose partition key to reduce the consuming RU & improve performance? When there is a spike of data to write, the throughput can be seen massively unevenly distributed like the photo below and we got a lot of exceptions

Command update failed: Message: {"Errors":["Request rate is large. More Request Units may be needed, so no changes were made. Please retry this request later. Learn more: http://aka.ms/cosmosdb-error-429"]}
ActivityId: 567b2295-0000-0000-0000-000000000000, Request URI: /apps/98d69d4b-03ce-48bb-aa1e-5e7bbd7b26a9/services/8904d4ba-be8d-494c-8a6f-7f7b0c1d3c32/partitions/41296cba-03c9-4d7b-bdcd-f983311b442c/replicas/132243222105318549p/, RequestStats: 
RequestStartTime: 2020-02-27T03:56:01.3650496Z, RequestEndTime: 2020-02-27T03:56:01.3650496Z,  Number of regions attempted:1
ResponseTime: 2020-02-27T03:56:01.3650496Z, StoreResult: StorePhysicalAddress: rntbd://cdb-ms-prod-australiaeast1-fd6.documents.azure.com:14332/apps/98d69d4b-03ce-48bb-aa1e-5e7bbd7b26a9/services/8904d4ba-be8d-494c-8a6f-7f7b0c1d3c32/partitions/41296cba-03c9-4d7b-bdcd-f983311b442c/replicas/132243222105318549p/, LSN: 5940891, GlobalCommittedLsn: 5940891, PartitionKeyRangeId: , IsValid: True, StatusCode: 429, SubStatusCode: 3200, RequestCharge: 0.38, ItemLSN: -1, SessionToken: , UsingLocalLSN: False, TransportException: null, ResourceType: StoredProcedure, OperationType: ExecuteJavaScript
, SDK: Microsoft.Azure.Documents.Common/2.9.2.

This doc say we can choose to limit the number of logical partitions. Can i use the result of orderId mod partition-count as the partition key value to do that?

Client : .NET core app with MongoDBDriver 2.8.1
Server: Cosmos MongoDB