Azure DocumentDB Query by Id is very slow

Question

I got a 16GB collection with 2 partitions. When I query a document by it\'s Id, it is very slow. But querying by an indexed field is fast. Both are cross-partition query and

Answer 1

Microsoft support responded and they've resolved the issue. They've added IndexVersion 2 for the collection. Unfortunately, it is not yet available from the portal and newly created accounts/collection are still not using the new version. You'll have to contact Microsoft Support to made changes to your accounts.

Here are the new results from a collection with index version 2 and there's a massive improvement.

SELECT * FROM c where c.id = 'uniqueValue'
-- Index Version 1: Request Charge: 344,940.79 RUs
-- Index Version 2: Request Charge: 3.31 RUs

SELECT * FROM c WHERE c.indexedField = 'value' AND c.id = 'uniqueValue'
-- Index Version 1: Request Charge: 150,666.22 RUs 
-- Index Version 2: Request Charge: 5.65 RUs

Answer 2

The "Id" field is only unique within a partition key. This is probably party of why your query is so costly, if you have manually configured indexing.

Unfortunately, it is not possible to control the indexing of the 'id' field. You could try checking if the query performance improves if you index everything. It would be interesting if it changed anything for your data, altough it changed nothing for my small sample set.

The specified path '/id/?' could not be accepted because it overrides system property 'id'.

In my experience, DocumentDB queries actually can get cheaper if you have a couple of results in each partition. They can be very costly if there no results within a partition. Try putting a second document with the same id in a different partition and look how the performance changes. Without the cross-partition-query the responses are always extremely fast when querying with an indexed field, regardless of the result count.

I never investigated more since it never bothered me for real use cases. It might also be that the amount of items per partition has no real impact and my data itself is responsible.