我的表是时间序列表。查询将处理最新条目，并且 TTL 在成功处理后使它们过期。如果未成功处理，则不会设置 TTL。
我计划对此运行的唯一查询是选择给定 entry_type 的所有条目。它们将被处理，对应于已处理条目的记录将过期。
这样每次我运行这个查询时，我都会得到表中所有未处理的记录，并完成处理。这是一个合理的方法吗？
考虑到执行选择的线程只是在处理，是否会在我自己的执行程序中使用可侦听的未来添加任何价值。
我担心 TTL 和墓碑。但是，如果我使用 timeuuid 类型的集群键，可以吗？
【问题讨论】：
标签： cassandra
你是对的，有一件重要的事情会阻碍你的工作，那就是墓碑。默认情况下，您会将它们保留 10 天。根据您的访问模式，这可能会导致严重的问题。您可以通过直接在表上设置或在 cassandra yaml 文件中更改它来降低此值。那么它将对所有新创建的表gc_grace_seconds有效
http://docs.datastax.com/en/cql/3.1/cql/cql_reference/tabProp.html
确保在此期间内对整个集群运行一次修复非常重要。因此，如果您将此设置降低到 2 天，那么您必须在两天内对集群进行一次全面修复。这非常重要，因为处理过的数据将会收割。我多次看到这种情况发生，并且永远不会令人愉快，特别是如果您将 cassandra 用作队列并且在我看来您可能会在您的解决方案中使用它。我会尝试在答案的最后给出一些提示。
我有点担心你会根据结果动态设置 ttl。插入成功的 ttl 数据并永久保留未成功的数据有什么意义。我猜是某种审计或类似的东西。这又是一个队列模式，如果可能的话尽量避免这种情况。另外要记住的一件事是，如果您的处理正常，您几乎总是会在开始时插入数据一次，然后再次使用 ttl。
同时获取所有条目可能有点棘手。对于非常中等的负载 10-100 请求/秒，这可能是合理的，但如果您每秒有数千次获取所有请求可能不是一个好主意。至少如果你把它们放在一个分区中就不会。
分离工作负载也是个好主意。所以是的，使用可听的未来似乎完全合法。
将集群键设置为 timeuuid 通常是时间序列的情况，我完全同意你的观点。
实际上，正如我之前提到的，您必须考虑到无论您做什么，您都将节省 10 天的数据（除非您对其进行调整），如果您 ttl 也没关系。它仍然会在那里，并且每次 cassandra 扫描分区时都必须读取 ttl-ed 列。简而言之，这只是痛苦。如果我是你，我会认真考虑实际使用一些东西作为 kafka，因为你所描述的内容在我看来就像一个队列。
如果您仍想坚持使用 cassandra，请考虑使用存储桶（将日期信息添加到分区键并具有复合分区键）。根据您期望的负载，您将不得不按月、周、日、小时甚至分钟来存储。在某些情况下，您甚至可能想要添加人工列来减少集群的负载。但话又说回来，这可能超出了这个问题的范围。
使用 cassandra 作为队列时要非常小心，这是一种已知的反模式。你可以做到，但有很多变量，这很大程度上取决于你使用的负载。我曾经咨询过一个团队，该团队沿着 cassandra 的路径作为队列。因为基本上使用 cassandra，所以我必须建议他们按天存储数据（做了一些计算证明这是好的时间单位），我还查看了这个解决方案 https://github.com/paradoxical-io/cassieq 基本上这里面有很多好东西使用 cassandra 作为队列、数据模型等时的 repo。基本上这个团队有僵尸行，由于墓碑等原因导致读取速度缓慢。
按照您描述的方式，基本上可能会发生“热行”，因为您只有一个宽分区，所有数据都将进入集群中的某些节点，甚至可能没有得到很好的利用。这可以通过人工列来避免。
当使用 cassandra 作为队列时，很容易搞砸很多事情。 （但对于中等工作负载是可能的）
【讨论】：