Кассандра IN против многих запросов против изменения модели - PullRequest
Новая
       18

Кассандра IN против многих запросов против изменения модели

1 голос
/ 21 апреля 2020

У меня есть таблица cassandra 

CREATE TABLE users_by_id (
id bigint PRIMARY KEY,
name text,
email text,
password text,
);

и 

CREATE TABLE members_by_org_id_user_id (
organisation bigint,
user bigint,
roles set<bigint>,
PRIMARY KEY (organisation, user)
) WITH CLUSTERING ORDER BY (user DESC);

Если я хочу получить name каждого члена организации, я мог бы:

  1. SELECT user FROM members_by_org_id_user_id WHERE organisation = ? и затем выполните SELECT name FROM users_by_id WHERE id in ? (координатор должен связаться со многими узлами ? = плохо Плохо ли отношение IN в Кассандре для запросов? )
  2. SELECT user from MEMBERS_by_org_id_user_id WHERE organisation = ?, а затем выполнить запрос для пользователя SELECT name FROM users_by_id WHERE id = ? (приложение должно связываться со многими узлами, поскольку первичные ключи пользователей различаются ? = менее плохо? Не идеально)
  3. Изменить members_by_org_id_user_id на 
CREATE TABLE members_by_org_id_user_id (
organisation bigint,
user bigint,
name text,
email text,
PRIMARY KEY (organisation, user)
) WITH CLUSTERING ORDER BY (user DESC);

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

Как я могу смоделировать свои данные, чтобы уменьшить каждую из этих проблем или полностью избавиться от них?

Теоретически организация может состоять из до 2000 членов и использование Может быть до 20 организаций.

1 Ответ

1 голос
/ 21 апреля 2020

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

приложение должно связаться со многими узлами

, поскольку вы использовали user id в качестве первичного ключа (id столбец) в своей таблице users_by_id, тогда Кассандра не будет проходить через каждый узел один за другим - он знает, где найти вашего пользователя. Поскольку вы используете один первичный ключ, то это также ключ раздела. Это один из наиболее эффективных способов запроса таблицы в Cassandra.

На мой взгляд, вариант 2 - лучший подход для моделирования данных, но, как указал вопрос @Alex Ott, размеры этих таблиц могут быть ключевой фактор для решения с предложением «где в».

Редактировать:

Datastax's Как выполняются запросы на чтение? Статья является отличным ресурсом для понимания стратегии чтения Cassandra.

...