我的桌子是时间系列之一。查询将处理最新的条目，TTL将在成功处理后过期。如果他们没有成功处理，TTL将不会被设置。用cassandra查询时间序列数据的最佳方法是什么？
我计划在此上运行的唯一查询是为给定的entry_type选择所有条目。它们将被处理并且对应于处理的条目的记录将会过期。
这样每次我运行这个查询时，我都会得到表中所有未处理的记录，并且处理完成。这是一个合理的方法吗？
将我自己的执行程序使用listenablefuture添加任何值，考虑到执行select的线程正在处理。
我很关心TTL和墓碑。但是如果我使用timeuuid类型的聚簇键，这是否正确？
你是对的一个重要的事情，你的方式将是墓碑。默认情况下，你将保持他们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来处理数据。
同样获取所有条目可能有点棘手。对于非常适中的负载10-100 req/s，这可能是合理的，但如果每秒有数千次获得所有请求，那么每次都可能不是一个好主意。至少不是如果你把它们放入单个分区。
分离工作量也是个好主意。因此，使用可听的未来似乎完全合法。
将聚簇键设置为timeuuid通常是时间序列的情况，我和这个人完全同意你的观点。
实际上，正如我前面提到的，你必须考虑到你将会保存10天的数据（除非你调整了它），无论你做什么，它都无关紧要。它仍然会是，并且每次cassandra扫描分区都必须读取ttl-ed列。总之这只是痛苦。如果我是你，我会认真考虑实际使用卡夫卡这样的东西，因为你所描述的只是看起来像一个队列。
如果你仍然想坚持cassandra，那么请考虑使用桶（添加日期信息分区键和有一个复合分区键）。根据您所期望的负载，您将不得不按月，周，日，小时甚至几分钟进行存储。在某些情况下，您甚至可能需要添加人造列以减少群集上的负载。但是，这又可能超出了这个问题的范围。
使用cassandra作为队列时非常小心，它是一个已知的反模式。你可以做到这一点，但是有很多变量，它非常依赖于你使用的负载。我曾经咨询过一支像卡桑德拉队一样排队的队伍。由于基本上使用cassandra，所以我必须推荐他们在一天之内收集数据（做了一些计算，证明这是正确的时间单位），我也看到了这个解决方案https://github.com/paradoxical-io/cassieq基本上这个回购中有很多好东西使用cassandra作为队列，数据模型等基本上这个团队有僵尸行，由于墓碑等缓慢阅读等。
此外，你描述它的方式可能会发生，你有“热行”基本上是因为你只会有一个宽分区，所有的数据都会在集群中的某些节点上使用，甚至没有那么好用。这可以通过人造色谱柱来避免。
当使用cassandra作为队列时，很容易混淆了很多东西。 （但是对于中等工作负载是可能的）