Правильное хранение данных в Azure Космос

Question

У меня есть база данных, в которой есть два «Контейнера», один для «Пользователей» и другой для «Сообщений»:

Пользователи:

{
   id: 1,
   name: "Peter"
},
{
   id: 2,
   name: "Paul"
}

Сообщения:

{
    id: 1,
    title: "My First post"
    authorId : 1
},
{
    id: 2,
    title: "My Second post"
    authorId : 1
}

Если пользователь хочет опубликовать сообщение, значит, пользователю 2 нравится сообщение 1, где должна сохраняться эта база данных? Нужно ли обновлять элемент Post, чтобы сохранить ссылку на то, кому нравится этот пост в массиве? Если так, что происходит, когда миллионам людей нравится этот пост?

{
    id: 1,
    title: "My First post"
    authorId : 1,
    usersWhoLikeThis: [2,130,2341]
},

Должны ли эти данные храниться в данных пользователя, например:

{
   id: 2,
   name: "Paul",
   postsILike: [1,15,82,800]
}

Или эта информация должна храниться отдельно? Контейнер:

Любит:

{
   id: 1,
   userId: 2,
   postId: 1
},
{
   id: 2,
   userId: 2,
   postId: 2
}

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

Есть ли у кого-нибудь какие-либо советы или примеры о наилучшем способе хранить такие данные?

Большое спасибо

Answer 1

Я бы смоделировал запись и лайки как отдельный контейнер с postid в качестве ключа раздела, а затем использовал бы свойство "type", чтобы отличать guish "post" от "like". Каждый новый пост является вставкой, а каждый лайк - вставкой. Запрос, такой как «Выбрать * из c, где c .postid =« xxx », возвращает исходное сообщение и массив лайков.

В зависимости от сценария вы также можете смоделировать это так, чтобы« post "item" содержит свойство "likes", которое является счетчиком для каждого лайка, который увеличивается на каждую вставку из Change Feed. Это полностью зависит от того, как работает ваше приложение.

Например, если люди прокручивают записи и могут просмотрите общее количество лайков, прежде чем нажимать на них, и, возможно, вы захотите увеличить каждый новый лайк и обновлять каждое сообщение. Тогда ваш запрос для страницы фида будет "выбрать * из c, где c .type = 'post' ". Обратите внимание, что в приведенной ниже модели это будет запрос с несколькими разделами. Опять же, вы можете использовать Change Feed, чтобы потенциально поместить данные в отдельный контейнер с ключом раздела, который может легко отвечать на запросы с одним запросы на разделы.

Короче, вот как я бы смоделировал это.

Контейнер сообщений

{
    id: "xxxxx",
    postId: "abcdef"
    title: "My First post"
    likes: 2,
    userId : "aaaa",
    type: "post"
},
{
    id: "xxxxx",
    postId: "abcdef"
    userId : "bbbb",
    type: "like"
},
{
    id: "xxxxx",
    postId: "abcdef"
    userId : "cccc",
    type: "like"
},

Я wou Я обобщу авторов, чтобы они были просто пользователями и поместили их в один контейнер.

У нас есть пример реализации для создания движка блога поверх Cosmos DB. Это очень похоже на то, что вы пытаетесь сделать. Пожалуйста, смотрите, Как моделировать и разбивать данные на Azure Cosmos DB, используя реальный пример

Надеюсь, это полезно.

Answer 2

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

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

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

Подробнее о: Моделирование данных в Azure Cosmos DB