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

Подумайте об использовании posts_by_user в качестве метаданных для информации о сообщении. Это позволит вам разместить user_id, post_id, message_text и т. д., но вы абстрагируете view_count, < em>likes_count и comments_count в таблицу счетчиков. Это позволит вам получить либо метаданные сообщения, либо счетчики, если у вас есть post_id, но вам нужно будет обновить counter_record только один раз.

Документация по счетчику DSE: https://docs.datastax.com/en/cql/3.1/cql/cql_using/use_counter_t.html

Тем не мение,

Статья ниже — действительно хорошая отправная точка в отношении моделирования данных для Cassandra. А именно, есть несколько моментов, которые следует учитывать при ответе на этот вопрос, многие из которых будут зависеть от внутреннего устройства вашей системы и от того, как структурированы ваши запросы. Первые два правила сформулированы так:

Правило 1. Равномерное распределение данных по кластеру

Правило 2. Минимизируйте количество читаемых разделов

Найдите минутку, чтобы рассмотреть таблицу «user_timeline».

1. user_id и created_on в качестве СОСТАВНОГО КЛЮЧА*. Это было бы идеально, если бы

   • You wanted to query for posts by a certain user and with the assumption that you would have a decent number of users. This would distribute records evenly, and your queries would only be hitting a partition at a time.

2. user_id и hash_prefix в качестве СОСТАВНОГО КЛЮЧА*. Это было бы идеально, если бы

   • You had a small number of users with a large number of posts, which would allow your data to be evenly spread across the cluster. However you run the risk of having to query across multiple partitions.

3. Follower_id и created_on в качестве СОСТАВНОГО КЛЮЧА*. Это было бы идеально, если бы

   • You wanted to query for posts being followed by a certain follower. The records would be distributed and you would minimize queries across partitions

Это были 3 примера для 1 таблицы, и я хотел донести до вас мысль, что ваши таблицы должны быть ориентированы на запросы, которые вы хотите выполнить. Также не бойтесь дублировать свои данные в нескольких таблицах, которые настроены для обработки различных запросов, именно так Cassandra должна была быть смоделирована. Потратьте немного времени, чтобы прочитать статью ниже и посмотреть курс DataStax Academy Data Modeling, чтобы ознакомиться с нюансами. Я также включил приведенный ниже пример схемы, чтобы охватить базовую схему счетчика, о которой я указывал ранее.

* Причина использования составного ключа связана с тем, что ваш ПЕРВИЧНЫЙ КЛЮЧ должен быть уникальным, иначе ВСТАВКА с существующим ПЕРВИЧНЫМ КЛЮЧОМ станет ОБНОВЛЕНИЕМ.

http://www.datastax.com/dev/blog/basic-rules-of-cassandra-data-modeling https://academy.datastax.com/courses

CREATE TABLE IF NOT EXISTS social_media.posts_by_user (
user_id uuid,
post_id uuid,
message_text text,
created_on timestamp,
deleted boolean,
user_full_name text,
PRIMARY KEY ((user_id, created_on))
);
CREATE TABLE IF NOT EXISTS social_media.user_timeline (
follower_id uuid,
post_id uuid,
user_id uuid,
location_name text,
user_full_name text,
created_on timestamp,
PRIMARY KEY ((user_id, created_on))
);
CREATE TABLE IF NOT EXISTS social_media.post_counts (
likes_count counter,
view_count counter,
comments_count counter,
post_id uuid,
PRIMARY KEY (post_id)
);