Does more granular partition key play a role in RU cost, other things being equal?

user_2736919 0
Viewed 89

For example, let's say we have a total of 10Gb of data, and there is 1Gb of data for each partition key.

Now, lets consider a query:

SELECT * FROM c WHERE c.Amount > 100
AND c.partitionKey = "someKey"

Assumptions:

  1. This query always returns the same number of results.
  2. All partition keys fall into the same physical partition.

Question: Are there any cost implications in setting partitionKey more granular? In other words, if they are within the same physical partition, is there a difference if there are 1000s or 10000s or 100000s of documents with the same partitonKey value?

azure-cosmosdb
1 Answers

If all of your data resides on a single physical partition nothing you do with your partition key will have any impact on performance.

Your partition key only impacts your ability to scale out. In write-heavy scenarios you want to distribute your writes across as wide an array of partition keys as possible to best saturate or utilize available throughput. In read-heavy scenarios (generally), you want to focus your queries on one or a bounded set of partition key values to avoid fanning out across partitions which do not contain your data.

I say generally because in some cases, where the data you want resides on all partitions, cross-partition queries can be of use as they can run across multiple partitions in parallel. However this is often an edge case and only for queries without high concurrency.

In scenarios where you have both write and read heavy workloads you will need to decide whether to optimize for reads or writes or whether to optimize for writes and use Change Feed and duplicate the data into a second container to serve queries. However, this requires carefully measuring the cost of all operations and comparing it to the cost of not doing this.

user_8849310
Related