由于主键约束，Cassandra CQL SELECT/DELETE 问题

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 查询进行排序日期列作为“第二个”条目进入主键字段（我必须这样做吗？）。

当我想通过只给出“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

我需要将日期列作为主键的一部分，因为我想在我的 ORDER BY 子句中使用它，另一方面，我必须在不知道它们的“日期”值的情况下删除一些行！

那么 Cassandra 是如何解决这些问题的呢？我应该修复我的数据模型并有不同的工作模式吗？

Answer 1

DataStax 的首席布道者 Pa​​trick McFadden 发表了一篇文章，展示了一些时间序列建模模式。绝对值得一读，并且应该对您有所帮助：Getting Started with Time Series Data Modeling。

我认为你的桌子很好。虽然，使用复合主键在 Cassandra 中的工作方式，如果您不能在查询中跳过主键组件。因此，如果您最终需要通过user_name、post_id 和/或post_type 以不同的方式查询数据（没有日期），您应该专门为该查询创建一个表（其中不包括主键中的日期） )。

但我会说，一般来说，创建一个处理常规删除操作的表并不是一个好主意。事实上，我很确定它已经被归类为 Cassandra 的“反模式”。数据确实没有从 Cassandra 中删除；它是墓碑。墓碑在压缩时进行协调（假设已达到墓碑阈值时间），并且已知墓碑过多会导致性能问题。

如果您阅读了我上面链接的文章，请转到名为“时间序列模式 3”的部分。您会注意到INSERT 语句与USING TTL 子句一起运行。这使数据在几秒钟内有一个生存时间，之后它将“安静地消失”。例如，如果您想将数据保留 24 小时（86400 秒），您可以执行以下操作：

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

使用 TTL 功能是DELETE 定期清理的更好替代方法。