Cassandra CQL SELECT/УДАЛИТЬ проблемы из-за первичный ключом

Question

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

CREATE TABLE newsfeed (user_name text, 
         post_id bigint, 
         post_type text, 
         favorited boolean, 
         shared boolean, 
         own boolean, 
         date timestamp, 
     PRIMARY KEY (user_name,date,post_id,post_type)); 

Первые три столбца (имя пользователя, postid и posttype) в комбинации будут строить фактический первичный ключ таблицы, однако, поскольку я хотел ЗАКАЗАТЬ запросы SELECT в этой таблице на основе «дат» строк, я поместил дату -column в поля первичного ключа как «вторая» запись (я должен был это сделать?).

Когда я хочу, чтобы удалить строку, давая только "user_name, POST_ID и post_type" следующим образом:

DELETE FROM newsfeed WHERE user_name='pooria' and post_id=36 and post_type='p'; 

Я получаю следующее сообщение об ошибке:

Bad Request: Missing PRIMARY KEY part date since post_id is set 

мне нужна дата -column, чтобы быть частью первичного ключа, поскольку я хочу использовать его в своих предложениях ORDER BY, а с другой стороны, мне нужно удалить некоторые строки, не зная их значений «даты»!

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

Answer 1

Главный евангелист DataStax Патрик Макфадден опубликовал статью, демонстрирующую несколько моделей моделирования временных рядов. Определенно делает для хорошего чтения и должен вам помочь: Getting Started with Time Series Data Modeling.

Я думаю, что ваш стол в порядке. Хотя, с тем, что составные первичные ключи работают в Cassandra, если вы не можете пропустить первичные ключевые компоненты в запросе. Поэтому, если вам нужно запросить данные по user_name, post_id и/или post_type по-другому (без даты), вы должны создать таблицу специально для этого запроса (которая не включает дату в первичный ключ).

Я, однако, скажу, что в целом создание таблицы, которая будет обрабатывать регулярные операции удаления, не является хорошей идеей. На самом деле, я уверен, что он был классифицирован как «анти-шаблон» Кассандры. Данные действительно не удаляются из Cassandra; он надгробный. Надгробные плиты сверяются во время уплотнения (при условии, что время порога надгробия было выполнено), и слишком многие из них, как известно, вызывают проблемы с производительностью.

Если вы прочитали статью, указанную выше, перейдите в раздел под названием «Временной рядный шаблон 3». Вы заметите, что операторы INSERT выполняются с помощью предложения USING TTL. Это дает данные время жизни в секундах, после чего оно «тихо исчезнет». Например, если вы хотите сохранить ваши данные вокруг в течение 24 часов (86400 секунд) вы могли бы сделать что-то вроде этого:

INSERT INTO newsfeed (...) VALUES (...) USING TTL 86400 

Использование функции TTL является предпочтительной альтернативой регулярной чистки с помощью DELETE.