Выбор ключа раздела, когда у сообщения нет нужного свойства для разнообразия документов

У меня есть одно приложение, которое отправляет сообщения в Cosmos DB, читая сообщения из другой базы данных приложения. Единственная информация, которую я могу получить из другого приложения, - это documentId, то есть первичный ключ из базы данных приложения и тело сообщения. Структура выглядит примерно так:

{
   "id":<documentid>,
   "body":<body picked up from App>,
   "Timestamp":<today's date time>
}

Тело содержит простое текстовое сообщение типа «Привет, мир! Сегодня среда». У меня следующие требования: 1. Требуется запросить документ по documentId. 2. Требуется запросить документы между двумя отметками даты / времени.

  • DocumentId уникален, повторяющиеся значения не допускаются.

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

Любые материалы приветствуются.


azure-cosmosdb azure-cosmosdb-sqlapi data-partitioning
person Seasoned Developer    schedule 02.04.2020    source источник
comment
Это тяжелое приложение для чтения или для записи?   -  person Hasan Savran    schedule 03.04.2020
comment
Привет, Савран, это как тяжелая запись (~ 20 миллионов сообщений в день), так и чтение (будут запрошены и отправлены в очереди заинтересованных клиентов)   -  person Seasoned Developer    schedule 12.04.2020

Ответы (2)


arrow_upward
0
arrow_downward

Для запроса по идентификатору: если вы знаете идентификатор, вы можете выполнить прямое чтение (вместо запроса). Для этого необходимо знать как идентификатор, так и ключ раздела; если это ваш основной метод получения, вы можете установить ключ раздела равным /id, и это станет наиболее простым подходом (и наименее затратным, с точки зрения RU).

Для запросов между отметками времени: вам нужно переосмыслить разделение, так как в конечном итоге вы будете выполнять запросы между разделами, если используете /id в качестве ключа раздела. На самом деле нет «правильного» ответа на эту часть, поскольку мы просто недостаточно знаем о вашем приложении и ваших шаблонах запросов (или объеме данных с точки зрения скорости транзакций, размера и т. Д.). Просто знайте, что если вы разбиваете свои данные, вы в идеале захотите ограничить свои запросы одним логическим разделом; в противном случае вам нужно будет выполнять межраздельные запросы, что будет стоить больше RU.

person David Makogon    schedule 03.04.2020
comment
Makagon, извините, что не предоставил полную информацию. Данные, которые будут записаны в базу данных cosmos, - это метрическая информация, созданная некоторым приложением. Каждое сообщение с метрикой имеет следующие поля: - MetricId, который будет использоваться в качестве идентификатора документа - Datetimestamp - Подробное сообщение - Источник (одинаковое значение для всех сообщений, поскольку оно создается одним приложением). Ожидаемый объем составляет ~ 20 миллионов сообщений журнала в день. . Требуется возможность запрашивать сообщения по MetricId, сообщения между двумя отметками даты и времени. Я ищу лучший ключ раздела для сценария. - person Seasoned Developer; 12.04.2020

arrow_upward
0
arrow_downward

На вашем месте я бы выделил часть метки времени как строку и использовал бы ее как ключ раздела. Например, если метка времени - «15.04.2020 13:20 PM». Создайте новое свойство со значением «15.04.2020» и сделайте это новое свойство ключом раздела. Это будет гарантировать, что у вас будет 20 миллионов сообщений в каждом. раздел. У вас не возникнет проблем, выбрав данные по идентификатору. Если вам нужно выполнить поиск по дате, вы будете знать, что это за ключ раздела, поскольку он зависит от метки времени. Единственная проблема, которую я вижу, это то, что вам нужно получить данные в диапазоне дат , вам нужно задействовать несколько разделов. Посмотрите мой пост о синтетических ключах разделов. https://h-savran.blogspot.com/2019/08/synthetic-partition-keys-in-azure.html Надеюсь, это поможет!

person Hasan Savran    schedule 15.04.2020