Я использую 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>
.
.
}