#azure-cosmosdb
#azure-cosmosdb
Вопрос:
Я храню миллионы документов в cosmos db с помощью правильного ключа раздела. Мне нужно получить, скажем, 500 000 документов, чтобы выполнить некоторые вычисления и отобразить вывод в пользовательском интерфейсе, это должно произойти, скажем, за 10 секунд. Возможно ли это? Я пробовал это, но это заняло почти минуту. Итак, для такого рода требований это правильный подход?
"id": "Latest_100_Sku1_1496188800",
"PartitionKey": "Latest_100_Sku1
"SnapshotType": 2,
"AccountCode": "100",
"SkuCode": "Sku1",
"Date": "2017-05-31T00:00:00",
"DateEpoch": 1496188800,
"Body": "rVNBa4MwFP4v72xHElxbvYkbo4dBwXaX0UOw6ZRFIyaBFfG/7zlT0EkPrYUcku 9fO/7kvca"
Размер одного документа: 825 байт
Я использую пропускную способность autoscale 4000
Статистика запросов — я использую 2 запроса.
Запрос 1 — выберите * из c, где c.id в ({ids}) здесь я использую PartitionKey в параметрах запроса.
Статистика запроса ЗНАЧЕНИЕ ПОКАЗАТЕЛЯ Стоимость запроса 102.11 RUs Отображение результатов 1 — 100 Количество извлеченных документов Дополнительная информация 200 Размер извлеченного документа Дополнительная информация 221672 байта Количество выходных документов Дополнительная информация 200 Размер выходного документа Дополнительная информация 221972 байта Количество попаданий в индекс количество документов Дополнительная информация 200 Время поиска индекса Дополнительная информация 17.0499 мс Время загрузки документа Дополнительная информация 1.59 мсВремя выполнения механизма запросов Дополнительная информация 0,3401 мс Время выполнения системной функции Дополнительная информация 0,060000000000000005 мс Время выполнения пользовательской функции Дополнительная информация 0 мс Время записи документа Дополнительная информация 0,16 мс Туда и обратно 1
Запрос 2 — выберите * из c, где c.PartitionKey в ({keys}) и c.DateEpoch>={StartDate .ToEpoch()} и c.DateEpoch<={Дата окончания.ToEpoch()}
Статистика запроса ЗНАЧЕНИЕ ПОКАЗАТЕЛЯ Стоимость запроса 226,32 RUs Отображение результатов 1 — 100 Количество извлеченных документов Дополнительная информация 200 Размер извлеченного документа Дополнительная информация 176580 байт Количество выходных документов Дополнительная информация 200 Размер выходного документа Дополнительная информация 176880 байт Количество попаданий в индекс Дополнительная информация 200 Время поиска индекса Дополнительная информация 88,31 мс Время загрузки документа Дополнительная информация 4,2399000000000004 мсВремя выполнения механизма запросов Дополнительная информация 0,4701 мс Время выполнения системной функции Дополнительная информация 0,060000000000000005 мс Время выполнения пользовательской функции Дополнительная информация 0 мс Время записи документа Дополнительная информация 0,19 мс Туда и обратно 1
Комментарии:
1. Для ответа на этот вопрос недостаточно информации. Пожалуйста, включите образец документа в свой контейнер, запрос, который вы пытаетесь выполнить, ключ раздела для вашего контейнера, количество предоставленных RU / s и выходные данные из обозревателя данных, показывающие статистику запроса.
2. Я отредактировал детали со всеми заданными вами вопросами.
Ответ №1:
Запрос # 1 выглядит нормально. Запрос № 2, скорее всего, выиграет от составного индекса в DateEpoch. Я не уверен, что такое UDF, но если вы конвертируете даты в эпохи, вы хотите прочитать новое сообщение в блоге, новые функции системы даты и времени в Azure Cosmos DB
В целом, извлечение 500 Тыс. документов в 1-2 запросах для выполнения некоторых вычислений кажется странным вариантом использования. Обычно большинство пользователей предварительно вычисляют значения и сохраняют их, используя шаблон материализованного представления с использованием ленты изменений. В зависимости от того, как часто вы выполняете эти два запроса, это часто является более эффективным использованием вычислительных ресурсов.
Комментарии:
1. Спасибо, Марк, я попробовал составной индекс в DateEpoch, но это не очень помогло. Я не могу сохранить предварительно рассчитанные результаты, потому что в моем сценарии пользователь может выбрать любой диапазон дат от 4 лет, и я не могу загружать документы для этих выбранных дат и выполнять вычисления. Я увеличил пропускную способность, но не улучшил. Когда я перевел службу на P3V2, это лучший план приложения с большей вычислительной мощностью, я получаю лучший отклик. Я вызываю эти 2 запроса параллельно.
2. Этот сценарий лучше подходит для Synapse Link, чем для Cosmos DB. Cosmos — это операционная база данных, которая больше подходит для OLTP большого объема, чем для больших запросов типа OLAP. Я бы взглянул на ссылку Synapse и посмотрел, подходит ли она вам лучше.