4
votes

This query cost 265 RU/s: SELECT top 1 * FROM c WHERE c.CollectPackageId = 'd0613cbb-492b-4464-b66b-3634b5571826' ORDER BY c.StartFetchDateTimeUtc DESC

StartFetchDateTimeUtc is a string property, serialized by using the Cosmos API

This query cost 5 RU/s: SELECT top 1 * FROM c WHERE c.CollectPackageId = 'd0613cbb-492b-4464-b66b-3634b5571826' ORDER BY c._ts DESC

_ts is a built in field, a Unix-based numeric timestamp.

Example result (only including this field and _ts): "StartFetchDateTimeUtc": "2017-08-08T03:35:04.1654152Z", "_ts": 1502163306

The index is in place and follows the suggestions & tutorials how to configure a sortable string/timestamp. It looks like: { "path": "/StartFetchDateTimeUtc/?", "indexes": [ { "kind": "Range", "dataType": "String", "precision": -1 } ] }

1

1 Answers

2
votes

According to this article, the "Item size,Item property count,Data consistency,Indexed properties,Document indexing,Query patterns,Script usage" variables will affect the RU.

So it is very strange that different property costs different RU.

I also create a test demo on my side(with your index and same document property). I have inserted 1000 records to the documentdb. The two different query costs same RU. I suggest you could start a new collection and test again.

The result is like this:

Order by StartFetchDateTimeUtc

enter image description here

Order by _ts

enter image description here