是否可以避免 Cassandra 出现墓碑问题？

Question

我正在为使用 Cassandra 作为数据库系统的 CMS 编写代码。

CMS 的优势之一是使用后端计算机预先计算各种事情，该后端计算机针对 CMS 中发生变化的数据永久运行。

例如，CMS 告诉列表系统页面已创建或更改。列表系统将该信息保存在名为list 的表中。该信息只是告诉我必须处理哪个页面的一个衬里。

Column family: list
   Row: concerned website (i.e. http://www.example.com/)
     Column: full URI (i.e. http://www.example.com/this/page)
        Value: true (because you need something for the column to exist)

偶尔（通常在简单的页面编辑后不到一秒钟），该列表后端系统会唤醒并看到某个页面已更改并开始通过更新所有列表来处理它，包括（或不不再包含）该页面作为元素。这允许前端立即知道列表中的元素数量并非常快速地读取列表，而无需在需要列表时运行复杂的查询（与许多 CMS 使用 SQL.. .)

实际上，我使用list 表作为TODO 列表。我必须处理的一组页面。因此，前端将页面引用添加到该列表，而后端在完成后将其删除。结果，我可以在list 表中得到大量的墓碑。现实世界的影响：我有墓碑故障，系统开始在随机地方出现故障。一旦列表停止工作，系统中的许多其他东西都会停止工作，网站将变得无法使用。

我减少了 Cassandra 处理该特定表（以及其他一些表）中墓碑的时间，但我想知道我是否按预期使用了 Cassandra。在这种环境下是否有更好的方法来处理此类 TODO 列表？

附带说明：TODO 列表可以在各种不同的后端计算机上处​​理。在小型系统上，您可能只有一个后端针对列表数据运行，而在拥有数千名用户的大型系统上，您不太可能有 2 或 3 个后端来处理列表。因此，将数据保存在 Cassandra 中非常实用，可以在计算机之间快速共享。

Answer 1

您实际上实现了一个队列，该队列被认为是 cassandra 的反模式： http://www.datastax.com/dev/blog/cassandra-anti-patterns-queues-and-queue-like-datasets

人们有一些变通方法和一些事情可以让他们变得更好，但这是一场很难玩的游戏。请务必使用 LeveledCompactionStrategy 而不是默认值，这将对较小的工作负载有很大帮助。考虑一些变通方法，例如对分区进行时间装箱（旧的节俭术语中的行）以及上面链接的文章中的内容，但您可能想要寻找不同的解决方案。