Выбор ключа раздела Cosmos DB

Question

Я использую Cosmos DB для своего приложения, которое я разрабатываю для клиента. Клиент является многонациональным и насчитывает около 175 000 сотрудников по всему миру. Прикладная программа должна объединять уведомления из различных исходных систем и отображать их на портале пользователя, когда пользователь щелкает раскрывающийся список для своего имени, как и в любой другой онлайн-системе, например, LinkedIn et c.

Я пытаюсь определить «Ключ раздела» для Cosmos DB. Я считаю, что это «Идентификатор пользователя». Я хочу убедиться, что мне пригодятся люди с большим опытом проектирования баз данных Cosmos DB.

Вот мои соображения по выбору идентификатора пользователя в качестве ключа раздела. Я знаю, что потенциально может быть около 175 000 «логических» разделов, они будут сопоставлены с гораздо меньшим количеством «физических» разделов на базовой платформе хранения данных Azure. Выбор «Идентификатор пользователя» гарантирует, что ВСЕ записи уведомлений текущего пользователя хранятся в одном и том же «логическом» и, следовательно, «физическом» разделе.

Я ошибаюсь? Пожалуйста подтвердите. Если да, то какая стратегия лучше?

Спасибо.

Бхарат

Answer 1

Общее правило: вы хотите посмотреть на ваши операции с большими объемами и поставить нагрузочные тесты для вашей стратегии секционирования, чтобы проверить, будет ли она масштабироваться. Не нужно быть исчерпывающим. Здесь применяется принцип Парето.

На основании запроса, на который вы ссылаетесь, хотя ваша логика c выглядит надежной. Дополнительные вещи, чтобы следить за хранением. Максимальный размер раздела составляет 20 ГБ. Я понятия не имею, каков размер полезной нагрузки для каждого уведомления, но что-то, что можно измерить и проработать с учетом количества X уведомлений, как долго, пока вы не достигнете этого размера 20 ГБ. Кроме того, вы, вероятно, захотите избегать запросов к постоянно растущему разделу в какой-то момент в будущем, поэтому, возможно, захотите посмотреть и на стратегию TTL в будущем.

Надеюсь, это поможет.