我正在使用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中获取数据非常实用，可以在计算机之间快速共享。
答案 0 :(得分：3)
你基本上实现了一个被认为是cassandra的反模式的队列： http://www.datastax.com/dev/blog/cassandra-anti-patterns-queues-and-queue-like-datasets
有一些工作和人们做的事情可以使它们变得更好，但这是一场艰苦的比赛。一定要使用LeveledCompactionStrategy而不是默认值，这对小型工作负载有很大帮助。考虑周围的工作，如时间装箱分区（旧节约用语中的行）和上面链接的文章中的内容，但您可能想要寻找不同的解决方案。