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