由于主键限制导致 Cassandra CQL SELECT/DELETE 问题

我需要在 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 是如何解决这些问题的呢？我应该修复我的数据模型并有不同的工作模式吗？

DataStax 的首席传播者 Patrick McFadden 发表了一篇文章，演示了一些时间序列建模模式。绝对值得一读，并且应该对您有所帮助：时间序列数据建模入门 http://planetcassandra.org/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.