Сортировка Кассандры и изменяющийся ключ кластеризации
У меня есть вопрос моделирования данных для случаев, когда данные должны быть отсортированы по ключам, которые могут быть изменены. Итак, скажем, у нас есть таблица пользователей
{
dept_id text,
user_id text,
user_name text,
mod_date timestamp
PRIMARY KEY (dept_id,user_id)
}
Теперь я могу запросить cassandra, чтобы получить всех пользователей по dept_id.
Что делать, если я хочу запросить всех пользователей в отделе, отсортированном по mod_date.
Таким образом, одним из способов было бы
{
dept_id text,
mod_date timestamp,
user_id text,
user_name text,
PRIMARY KEY (dept_id, mod_date,user_id)
}
Но, mod_date изменяется каждый раз, когда имя пользователя обновляется. Так что это не может быть частью ключа кластеризации.
Попытка 1:
Не обновляйте строку, а создавайте новую запись для каждого обновления.
Итак, скажем, запись для пользователя foo, как показано ниже{'dept_id1',TimeStamp1','user_id1','foo'}
а затем имя было изменено на "бар", а затем на "баз". В этом случае мы добавляем еще одну строку в таблицу, чтобы она выглядела как
{'dept_id1',TimeStamp3','user_id1','baz'}
{'dept_id1',TimeStamp2','user_id1','bar'}
{'dept_id1',TimeStamp1','user_id1','foo'}
Теперь мы можем собрать всех пользователей в отдел, отсортированный по mod_date, но это представляет другую проблему.
Возвращенные данные дублируются
,
Попытка 2: добавьте еще один столбец, чтобы идентифицировать запись заголовка во многом как связанный список
{
dept_id text,
mod_date timestamp,
user_id text,
user_name text,
next_record text
PRIMARY KEY (dept_id,mod_date,user_id)
}
Каждый раз, когда происходит обновление, он добавляет строку, а также добавляет PK новой записи.
{'dept_id1',TimeStamp3','user_id1','baz','HEAD'}
{'dept_id1',TimeStamp2','user_id1','bar','dept_id1#TimeStamp3'}
{'dept_id1',TimeStamp1','user_id1','foo','dept_id1#TimeStamp2'}
а также добавить вторичный индекс в столбец "nex t_record".
Теперь я могу поддержать всех пользователей в отделе, отсортированном по mod_date по
выберите * из ПОЛЬЗОВАТЕЛЕЙ, где dept_id=':dept' И next_record='HEAD' порядок по mod_date.
Но это выглядит довольно сложным решением, и, возможно, я что-то упускаю, более простое решение..
Другим вариантом является удаление и вставка, но для высокочастотных изменений, я думаю, у Кассандры есть проблемы с надгробиями.
Предложения / Отзывы приветствуются. Спасибо!
1 ответ
Как я вижу, самый простой способ - сортировка пользователей на стороне приложения (кода клиента). Вы используете dept в качестве ключа раздела, это означает, что все пользователи в одном отделе могут обрабатываться одним узлом cassandra, поэтому в одном отделе нет большого количества пользователей, и эти пользователи могут быть отсортированы на стороне приложения достаточно быстро.