Request unit charge impact on mongo DB Projection

Question

Hi All

I see the RU is impacted due to retrieved document size as per the documentation. Is it the size of stored document or the result of a query response. I have a document with lot of entries under the nested level. If I retrieve only the property at level 1 will it reduce the RU?

For example the document is show below. Consider the association level has more than 15000 entries

Blockquote

{
"name": "hi",
"data":"demo",
"associations": [
{
"name": "assoc1"
},
{
"name": "assoc2"
},
{
"name": "assoc3"
},
{
"name": "assoc4"
},
{
"name": "assoc5"
}
]
}

Blockquote

Wil there a difference in RU between the two mongo queries

Query without projection:

db.getCollection("oracle").find({"name":"hi"})

Query with projection:
db.getCollection("oracle").find( {"name":"hi"} , {"data":true} )

I noticed a change in RU between this two query. But I didn't see this mentioned in the document I searched.

Thanks
Guru

Answer 1

Hi @Thanakodi, Guru Prashanth , thanks for your patience.

When using projections to select few properties in Azure Cosmos DB Mongo API, we would see a little difference in Request charges. Please find below the comparison when selecting one property vs all:

Total properties were close to 30,000 in single document. First record shows when we selected all the properties and second one shows when we selected just one property. Please note the difference in request length then also there is little difference in RU charges. Read operation will not have much impact.

However if we talk about write operation there is a lot of difference we observe when we insert the document with these many properties. Below in first record, we have indexes defined on all the properties and 2nd record with indexes on just couple of properties. This is for same number of properties in a document.

By default, Azure Cosmos DB automatically indexes every property of every record. This is intended to ease development and ensure excellent performance across many different types of ad hoc queries. If you have large records with thousands of properties, paying the throughput cost for indexing every property may not be useful, especially if you only query against 10 or 20 of those properties. As you get closer to getting a handle on your specific workload, our guidance is to tune your index policy.

Optimize by changing indexing policy

Please let us know if this helps or else we can discuss further on the same.

----------

Please don't forgot to click on accept it as answer button wherever the information provided helps you. This can be beneficial to other community members as well.