Cosmos DB: запрос документов по временному интервалу с использованием ключа разделения

Question

Как выбрать ключ раздела таким образом, чтобы я мог эффективно запрашивать все свои документы за определенный период времени?

Справочная информация:

Я создаю аналитический инструмент для приложение для чата, использующее Azure CosmosDB. У меня есть отдельный контейнер для хранения входящих и исходящих сообщений. Типичный документ Message выглядит следующим образом:

{
    "version": "v1",
    "partition_key": "user_id",
    "timestamp": "2020-01-30 14:02:32.402+00:00",
    "type": "incoming_message",
    "message": "hi there",
    "sender": "sender_id",
    "receiver": "receiver_id",
}

В качестве ключа раздела я рассмотрел следующие параметры:

1. Идентификатор пользователя : С этим подход, я могу легко запросить все сообщения пользователем. Но фильтрация на основе времени должна быть перекрестным запросом, а стоимость RU будет высокой, особенно если в контейнере находятся тысячи документов.
2. Указанная дата c значение : Согласно this , я могу использовать дату вместе со случайным числом в качестве ключа раздела (например, 2018-08-09.1,2018-08-09.2 и т. Д.). Но при таком подходе мне придется передавать сотни ключей разделов в в пункте , чтобы выполнить запрос для больших временных интервалов (например, последние 6 месяцев).

Есть ли у вас какие-либо рекомендации по выбору лучшего ключа раздела для поддержки запросов одного раздела для фильтрации документов по времени?

Answer 1

Дата обычно является плохим выбором для ключа раздела в многораздельном хранилище данных по трем причинам: эффективность, производительность и хранение.

В рабочих нагрузках с интенсивной записью текущая дата всегда является горячим разделом. Это означает, что вы будете когда-либо использовать лишь часть пропускной способности, которую вы предоставляете. Это неэффективно, потому что у вас будет пропускная способность, которая никогда не используется. Это также неэффективно, потому что вы никогда не сможете использовать всю предоставленную вами пропускную способность. В некоторых сценариях ios это может работать. Но, как правило, они маленькие и всегда будут маленькими. В целом, однако, вы всегда хотите избежать стратегии разделения, которая никогда не сможет масштабироваться, и это не поможет.

Второй вопрос, на который нужно ответить, - это объем данных для каждого логического раздела, чтобы определить степень детализации для этого. значение ключа раздела, выраженное как время. Если у вас есть 20 ГБ данных в день, то использование дня или чего-либо более длинного (неделя, месяц, год и т. Д. c.) Никогда не сработает.

Третий вопрос, на который нужно ответить, - это какие агрегаты вы хотите сделать, и сколько данных вы пытаетесь обработать в запросе. Cosmos DB не является хранилищем аналитических данных. Это основанное на строках хранилище JSON, которое лучше всего работает в качестве хранилища основных данных и обслуживающего слоя для вычисляемых пакетных представлений или представлений в реальном времени. По вашему вопросу это звучит так, как будто вы ищете аналитику, так что вы, вероятно, извлекли бы выгоду из ETL, помещающего эти данные в хранилище столбцов и выполняющего там агрегирование. Затем вы можете записать агрегаты в Космос и служить оттуда. В этой статье описывается лямбда-архитектура , которую я описываю. Я не говорю, что вам придется использовать Spark как часть этого. Но если вы пытаетесь выполнять аналитику и выполнять агрегирование больших наборов данных, которые охватывают разделы, вам необходим пакетный уровень и вычислительная платформа для аналитики.

Надеюсь, это полезно.