首页 文章

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

提问于
浏览 次
2

我需要存储需要在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

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

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

cassandra cql

1 回答

  • 3

    DataStax的首席布道师Patrick McFadden发表了一篇文章，展示了一些时间序列建模模式 . 绝对是一个很好的阅读，应该对你有所帮助：Getting Started with Time Series Data Modeling .

    我觉得你的 table 很好 . 尽管如此，如果您无法跳过查询中的主键组件，那么复合主键在Cassandra中的工作方式 . 因此，如果最终需要以不同的方式（没有日期）按 user_name ， post_id 和/或 post_type 查询数据，则应该专门为该查询创建一个表（不包括主键中的日期） .

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

    如果您阅读我上面链接的文章，请转到名为"Time Series Pattern 3."的部分 . 您会注意到 INSERT 语句是使用 USING TTL 子句运行的 . 这样可以在几秒钟内为数据提供生存时间，之后它将"quietly disappear."例如，如果您想保持数据24小时（86400秒），您可以执行以下操作：

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

    使用TTL功能是 DELETE 定期清洁的首选替代方法 .

    回复于

相关问题