Как ускорить агрегированный запрос Cosmos DB?

Команда Cosmos DB внесла некоторые существенные изменения в производительность агрегирования и способы использования индексов. Это их стратегия индексирования "v2", которая была запущена совсем недавно (она может быть доступна не для всех учетных записей, обратитесь в MSFT, если у вас есть более старая база данных, которую необходимо обновить).

Вы можете сравнить новые результаты с картинкой, которую я изначально опубликовал.

Теперь вы заметите, что время загрузки документа отображается как 0 мс, а размер извлеченного документа равен 0 байтам. Время загрузки, которое я могу подтвердить, теперь действительно довольно быстрое, поэтому возможно, что оно составляет менее 1 мс при измерении со стороны сервера. И размер документа 0 имеет больше смысла, поскольку для этого не требуется извлекать документы (только подсчет на основе индекса).

Наконец, вы можете видеть, что количество RU упало с 3222 до 7,4 !!!! Довольно резкая разница.

Суммирование сразу нескольких столбцов в одном разделе теперь также достаточно эффективно, и мы можем делать около 8 сумм одновременно по 2 миллионам документов с ~ 50 RU, и это занимает около 20-70 мс при измерении от конечной точки функционального API (включая сеть время).

Группе Cosmos DB еще предстоит проделать дополнительную работу, чтобы обеспечить перекрестное разбиение на несколько столбцов, но улучшения, которые у нас есть сейчас, весьма многообещающие.

Для показанного конкретного запроса нет необходимости указывать имя таблицы, и вы можете попытаться ограничить 1, производительность будет улучшена. Например:

SELECT COUNT(1) FROM c WHERE country_code="FR" AND calculated.flag=1 LIMIT 1

Также не забывайте тщательно анализировать выполнение вашего запроса, я не уверен в Cosmos, но, как подход PostreSQL, EXPLAIN ANALYSE. Также убедитесь, что вы используете лучший тип переменных, например varchar (2) вместо varchar (3). Я бы рекомендовал изменить типы символов стран по номерам, если вы их фильтруете (как вы указываете). Например, FR = 1, GR = 2 и так далее. Это также улучшит производительность. Наконец, если код страны и рассчитанный флаг связаны, создайте уникальную переменную, определяющую их. Если ничего из этого не работает, проверьте производительность клиента и даже оборудование.

Две идеи:

Попробуйте запустить следующее, посмотрите, не изменится ли время выполнения:

SELECT COUNT(1) FROM c WHERE country_code="FR"

Важно! Поле calculated.flag1, если оно не является постоянным, может выдать проблему - как и для каждого документа / записи - механизм БД должен вычислить результат, отсюда и высокий RU. Можете ли вы оптимизировать вычисляемые поля? (разбить их или выполнить расчет как часть запроса?)

Второе предложение - попытаться определить составной индекс.

{  
        "automatic":true,
        "indexingMode":"Consistent",
        "includedPaths":[  
            {  
                "path":"/*"
            }
        ],
        "excludedPaths":[  

        ],
        "compositeIndexes":[  
            [  
                {  
                    "path":"/country_code",
                    "order":"ascending"
                },
                {  
                    "path":"/calculated",
                    "order":"descending"
                }
            ]
        ]
    }

См. Также Примеры правил составного индексирования

И управлять политиками индексирования в Azure Cosmos DB, чтобы увидеть, где вы его редактируете.