Можно ли смоделировать масштабируемое отношение подписчик / подписчик в базе данных Azure Cosmos DB?

Question

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

public class Relationship
{
  public Guid PartitionKey { get; set; }

  public Guid Id { get; set; }

  public DateTime CreatedOn { get; set; }
}

• PartitionKey - это ключ раздела контейнера Relationship, который представлен идентификатором пользователя, за которым следят. (Приемник)

• Id - это идентификатор контейнера, который представлен идентификатором пользователя, который следует за другим пользователем. (Отправитель)

Эта модель гарантирует, что один и тот же Id не может быть добавлен к одному и тому же PartitionKey, так что отношение подписчик / подписчик может быть создано только один раз между двумя пользователями. Это также позволяет мне легко просматривать список всех подписчиков для конкретного человека, что крайне важно.

Проблема в том, что каждый логический раздел ограничен 10 ГБ данных. Учитывая, что фактическая модель Relationship, вероятно, имеет больше свойств, и есть автоматическое индексирование, которое происходит за кулисами, и у некоторых пользователей есть миллионы подписчиков, этот предел будет достигнут, и будет невозможно разрешить новые отношения для того же ключа раздела.

Как можно разработать эту модель в Cosmos DB, чтобы она была действительно масштабируемой?

Answer 1

Стандартный подход здесь заключается в том, чтобы вручную обрабатывать данные между несколькими разделами, обычно с помощью синтетического ключа раздела , который состоит из нескольких элементов вместе взятых.

Простая стратегия заключается в использованиицелочисленное поле в пользовательской записи, чтобы отслеживать количество «сегментов», используемых для хранения всех записей последователей, а затем при необходимости отправлять запросы каждому разделу сегмента.Количество сегментов можно увеличивать по мере роста данных.

Ключ раздела будет затем вручную установлен в поле, составленное как [user_id]+[follower_bucket_count].Вы также можете вести подсчет для каждого сегмента для более продвинутой балансировки нагрузки, но, возможно, нет необходимости начинать.