Cosmos DB日期索引无效

Question

I have a collection with a Date field that is populated by a C# application using a DateTime object. This field is serialized to the following format "2018-06-10T17:32:48.3285735Z".

I haven't touched the Index Policy in the collection, so strings are using the Range index type. From what I've read in the documentation, that's the most efficient way to index dates, however, when I use the Date field in an ORDER BY clause, the query consumes at least 10x more RUs than if I were to query using the timestamp (_ts) number field. That means paying 10x more for this single collection.

To illustrate the issue:

SELECT TOP 100 * FROM c ORDER BY c.Date DESC
//query consumes a minimum of 500 RUs

SELECT TOP 100 * FROM c ORDER BY c._ts DESC
//query consumes 50 RUs

Is this how it is supposed to work or am I missing something? I suspect that if this was the expected behavior, it would be emphasized in the index documentation, and storing dates as numbers would be highlighted as the best practice.

EDIT: This is the index policy for the collection (I never changed it).

{
    "indexingMode": "consistent",
    "automatic": true,
    "includedPaths": [
        {
            "path": "/*",
            "indexes": [
                {
                    "kind": "Range",
                    "dataType": "Number",
                    "precision": -1
                },
                {
                    "kind": "Range",
                    "dataType": "String",
                    "precision": -1
                },
                {
                    "kind": "Spatial",
                    "dataType": "Point"
                }
            ]
        }
    ],
    "excludedPaths": []
}

Answer 1

This may have to do with index collisions (multiple values map to the same index term). You may want to narrow the range of the filed Date and see if that helps. Basically, try this query:

SELECT TOP 100 * FROM c WHERE (c.Date BETWEEN '2000-01-01' AND '2100-01-01') ORDER BY c.Date DESC

Please note that the added filter should not charge the query result set.

Answer 2

Did you try specifically configuring for Range Queries?

I think by default strings are hashed and you have to specify indexing for range queries.

I found this in the documentation:

By default, Azure Cosmos DB indexes all string properties within documents consistently with a Hash index.

Documentation link

For setting up a range query index on the collection:

DocumentCollection collection = new DocumentCollection { Id = "orders" }; 

collection.IndexingPolicy = new IndexingPolicy(new RangeIndex(DataType.String) 
                                { Precision = -1 });     

await client.CreateDocumentCollectionAsync("/dbs/orderdb", collection);

The document they are querying against looks like this:

{
 "id": "09152014101",
 "OrderDate": "2014-09-15T23:14:25.7251173Z",
 "ShipDate": "2014-09-30T23:14:25.7251173Z",
 "Total": 113.39 
}

Documentation link

Answer 3

I believe this is an optimisation deficiency when the query uses TOP and ORDER BY. I've found that whilst there is not much difference in RU for a range query using timestamp as number and timestamp as string, in scenarios such as yours the range index on string appears to be ignored.

User Voice issue here: https://feedback.azure.com/forums/263030-azure-cosmos-db/suggestions/32345410-optimise-top-with-order-by-clause-queries