Космический БД Указатель даты не эффективен

Question

У меня есть коллекция с полем Date, которая заполняется приложением C # с использованием объекта DateTime.Это поле сериализовано в следующий формат: «2018-06-10T17: 32: 48.3285735Z».

Я не затрагивал политику индексирования в коллекции, поэтому в строках используется тип индекса Range.Из того, что я прочитал в документации, это самый эффективный способ индексации дат, однако, когда я использую поле Date в предложении ORDER BY, запрос потребляет как минимум в 10 раз больше RU, чем если бы я запрашивал с использованием метки времени(_ts) числовое поле.Это означает, что нужно платить в 10 раз больше за эту коллекцию.

Чтобы проиллюстрировать проблему:

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

Это то, как это должно работать, или я что-то упустил?Я подозреваю, что если бы это было ожидаемое поведение, это было бы подчеркнуто в документации по индексу, и сохранение дат в виде чисел будет выделено как лучшая практика.

РЕДАКТИРОВАТЬ: Это политика индекса для коллекции (яникогда не менял).

{
    "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

Вы пытались специально настроить Range Queries?

Я думаю, что по умолчанию строки хэшируются, и вы должны указать индексацию для запросов диапазона.

Я нашел это в документации:

По умолчанию Azure Cosmos DB индексирует все строковые свойства в документах в соответствии с хэш-индексом.

Ссылка на документацию

Для настройки индекса запроса диапазона для коллекции:

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

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

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

Документ, с которым они запрашивают, выглядит следующим образом:

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

Документация ссылка

Answer 2

Я полагаю, что это недостаток оптимизации, когда запрос использует TOP и ORDER BY.Я обнаружил, что, хотя в RU нет большой разницы для запроса диапазона, использующего метку времени в качестве числа и метку времени в виде строки, в таких сценариях, как ваш, индекс диапазона в строке кажется игнорируемым.

Проблема с голосом пользователяздесь: https://feedback.azure.com/forums/263030-azure-cosmos-db/suggestions/32345410-optimise-top-with-order-by-clause-queries

Answer 3

Это может быть связано с конфликтами индексов (несколько значений отображаются на один и тот же индексный термин).Возможно, вы захотите сузить диапазон поданной даты и посмотреть, поможет ли это.По сути, попробуйте этот запрос:

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

Обратите внимание, что добавленный фильтр не должен взимать набор результатов запроса.