Модель данных социальных сетей в Cassandra

Представьте, что есть социальная сеть, и вот таблица для хранения понравившихся (избранных) действий и в отличие от этого удаления из этой таблицы:

CREATE TABLE IF NOT EXISTS post_likes(
  post_id timeuuid,
  liker_id uuid, //liker user_id
    like_time timestamp,
    PRIMARY KEY ((post_id) ,liker_id, like_time)
) WITH CLUSTERING ORDER BY (like_time DESC);

В приведенной выше таблице есть проблема в Cassandra, потому что, когда liker_id является первым clustering_key, мы не можем отсортировать по второму ключу кластеризации, который равен like_time.

Нам нужно отсортировать данные наших таблиц по like_time, мы используем его, когда пользователь хочет увидеть, кому понравился этот пост, и мы показываем список людей, которым понравился этот пост, отсортированный по времени (like_time DESC)

и нам также нужно удалить (в отличие от), и нам снова нужно иметь post_id и liker_id

Что вы предлагаете? Как мы можем отсортировать эту таблицу по like_time?


database cassandra datastax datastax-enterprise datastax-startup
person Mohammad Kermani    schedule 06.06.2016    source источник
comment
ты найдешь какое-нибудь решение? : D   -  person vchakoshy    schedule 13.06.2016
comment
@vahidchakoshy Да, я сделал! Но мы все еще ищем лучший способ! Вы знаете, что Кассандра действительно великолепна, но трудно найти хорошие отзывы о ней! Есть ли у вас предложения?   -  person Mohammad Kermani    schedule 13.06.2016
comment
@vahidchakoshy Вы использовали Кассандру для Wisgoon.com?   -  person Mohammad Kermani    schedule 13.06.2016
comment
Я все еще ищу лучшее решение для хранения лайков в кассандре. для wisgoon просто просмотрите источник страницы: D   -  person vchakoshy    schedule 14.06.2016
comment
мы переходим с Redis на Cassandra;)   -  person vchakoshy    schedule 14.06.2016
comment
@vahidchakoshy Мы также используем Cassandra помимо Redis. Пути записи и чтения Кассандры действительно быстрые, но поиск - это проблема. Мы используем Solr для поиска нужных нам данных. Мы разработали моделирование данных для лайков Strucher в Cassandra, я поделюсь им здесь или, возможно, отправлю вам на электронную почту   -  person Mohammad Kermani    schedule 14.06.2016
comment
спасибо, вчакоший [at] gmail.com   -  person vchakoshy    schedule 14.06.2016

Ответы (1)


arrow_upward
1
arrow_downward

После дополнительных исследований я нашел следующее решение: Выбор правильной модели данных - самая сложная часть использования Cassandra, и вот решение, которое мы нашли для таблиц лайков в Cassandra, прежде всего, я должен сказать read и write путь удивительно быстрый, и вам не нужно беспокоиться о записи в таблицах вашей Cassandra, вам нужно моделировать вокруг ваши запросы и помните, дублирование данных - это нормально. Многие из ваших таблиц могут повторять одни и те же данные. и не забудьте равномерно распределить данные по кластеру и минимизировать количество считываемых разделов

Поскольку мы используем Cassandra, которая является NoSQL, мы знаем, что одно из правил в NoSQL - денормализация, и мы должны денормализовать данные и просто думать о запросах, которые вы хотите иметь; Здесь для моделирования данных подобных таблиц у нас будет две таблицы, эти таблицы в основном ориентированы на легкое чтение или, проще говоря, мы сосредоточились на запросах, которые нам нужны:

CREATE TABLE IF NOT EXISTS post_likes(
    post_id timeuuid,
    liker_id uuid, //liker user_id
    like_time timestamp,
    PRIMARY KEY ((post_id) ,liker_id)
);

CREATE TABLE IF NOT EXISTS post_likes_by_time(
    post_id timeuuid,
    liker_id uuid, //liker user_id
    like_time timestamp,
    PRIMARY KEY ((post_id), like_time, liker_id)
) WITH CLUSTERING ORDER BY (like_time DESC);

Когда пользователю нравится сообщение, мы просто вставляем его в обе указанные выше таблицы.

почему у нас post_likes_by_time таблица?

В социальной сети вы должны показывать список пользователей, которым понравился пост, обычно вам нужно сортировать лайки по like_time DESC, а поскольку вы собираетесь сортировать лайки по like_time, вам нужно иметь like_time в качестве ключа кластеризации, чтобы иметь возможность сортировать лайки по времени.

Тогда почему у нас тоже post_likes таблица?

В post_likes_by_time наш ключ кластеризации - like_time, нам также нужно удалить такой же! Мы не можем этого сделать при сортировке данных в нашей таблице, когда ключ кластеризации равен like_time. По этой причине у нас также есть post_likes таблица

Почему у вас может быть не только одна таблица, но и выполнение с ней обоих действий, сортировки и удаления?

Чтобы удалить один лайк из таблицы post_likes, нам нужно предоставить user_id (здесь liker_id) и post_id (вместе), а в post_likes_by_time у нас есть like_time в качестве ключа кластеризации, и нам нужно отсортировать таблицу по like_time, тогда это должен быть первый ключ кластеризации, а второй ключ кластеризации может быть liker_id, и вот в чем суть! like_time - это первый ключ кластеризации, тогда для выбора или удаления с помощью liker_id вам также необходимо указать like_time, но в большинстве случаев like_time у вас его нет.

person Mohammad Kermani    schedule 14.06.2016