Как спроектировать структуру Azure Cosmos DB для конкретного сценария c, чтобы ограничить количество создаваемых коллекций? - PullRequest
2 голосов
/ 11 марта 2020

Я использую Azure Cosmos DB для MongoDB API.

У меня есть сценарий, в котором у меня есть различные локации, которые будут содержать модули. Эти модули будут содержать данные. Будет отображение Location-Module, которое будет уникальным. Чтобы сделать это более ясным, я опишу это, используя структуру таблицы ниже,

Расположение -> Модули -> Данные

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

У нас есть ModuleDataDB, в нем есть коллекции (имена, уникальные благодаря комбинации местоположения и модуля, сгенерированного динамически),

ModuleDataDB -> Location1-Module1 (collection)
             -> Location1-Module2 (collection)
             -> Location1-Module3 (collection)
             -> Location2-Module1 (collection)
             -> Location2-Module2 (collection)
             -> Location2-Module3 (collection)
             .
             .

Теперь проблема заключается в том, что ранее мы использовали Shared RU (для сокращения затрат). для всей коллекции в этой БД, но теперь Azure установил ограничение в 25 коллекций на БД, если мы используем общие RU.

Я думаю о переходе этой структуры к более традиционному подходу, т.е. модули из одного места в одной коллекции, например,

ModuleDataDB     -> Location1 (collection)                 
                 -> Location2 (collection)
                 -> Location3 (collection)
                 .
                 .

Мне нужны предложения о том, как сделать его экономически эффективным, а также ограничить количество коллекций, которые я делаю. Есть ли лучший способ сделать это? Также имеет ли смысл переключаться на виртуальную машину с MongoDB в ней, а не на Azure Cosmos?

EDIT1 (Решение): Как подсказывает @ Cedri c ниже, сейчас я использую одну коллекцию для отображение всех модулей местоположения и использование ключа разделения Syntheti c, который будет иметь несколько уникальных значений, таких как "Location-1_Module-1"

, поэтому он будет иметь структуру, подобную приведенной ниже,

ModuleDataDB     -> Client-1(collection) --> (Data) {
                                           LocationID : ""
                                           ModuleID : ""
                                           PartitionKey : <LocationID + ModuleID>
                                             .
                                             .
                                              }                                         

1 Ответ

2 голосов
/ 11 марта 2020

Использование одной коллекции может быть хорошим подходом. Чтобы обеспечить производительность при росте вашей коллекции, вам необходимо установить правильный ключ раздела.

https://docs.microsoft.com/en-us/azure/cosmos-db/partition-data

...