我们如何跟踪过期条目对时间序列表的影响？

Question

我们正在处理时间序列表中最旧的数据。我正在注意确保最旧的条目一经处理就会过期。期望是在TimeUUID的集群列的底部具有所有删除。因此查询将始终读取时隙而不删除任何条目。

这个方案有用吗？我应该注意过期列的影响吗？

Answer 1

您可以使用TWCS轻松管理过期数据，并通过查询时间的某个时间戳列执行过滤，以确保您的查询始终获得最后结果。

你如何“照顾”最老的条目到期？ Cassandra不会显示过期ttl的记录，但是它们会持续存在于sstables中，直到下一次压缩为sstable。如果您要自己删除行，则无法确保查询始终读取最新记录，因为Cassandra最终是一致的，理论上可能会有一些时刻，当您将读取陈旧数据（或许多此类时刻，根据您的一致性设置）。

Answer 2

因此，将timeuuid作为群集密钥的一部分保证了排序顺序以提供最新数据。

如果Cassandra 3.1（DSE 5.x）及以上： -

现在关于删除，“避免手动和使用TWCS ”：这是如何

假设您的工作每隔X分钟处理一次数据。让我们说X = 5分钟，（希望小于24小时）。将压缩设置为TWCS：时间窗口压缩策略，并假设TTL为24小时。

WITH compaction= {
'compaction_window_unit': 'HOURS',
'compaction_window_size': '1',                                                                                      
};

现在每天创建24个桶，每个都有一个小时的数据。这24个桶只涉及Cassandra数据目录中的24个sstables（压缩后）。现在在25小时内，整个第一桶/ sstable将自动被TTL掉落。因此，不要编写删除代码，让Cassandra负责清理工作。 TWCS的美妙之处在于将整个数据转换为sstable。

现在，您的应用程序中的READ总是会转到最近的存储桶，在这种情况下总是第24个sstable。因此，读取将永远不必扫描墓碑（由TTL引起）。

如果是Cassandra 2.x或DSE 4.X，如果TWCS尚不可用： -

直到你升级到Cassandra 3.1或以上的方法是使用人造水桶。假设您将时间桶变量作为分区键的一部分引入，并将桶值保持为日期和小时。这样每个分区都不同，您可以调整存储桶大小以匹配作业处理间隔。

因此，当您删除时，只有已处理的分区会被删除，并且在读取未处理的分区时不会受到影响。因此可以避免扫描墓碑。

它在应用程序端的额外工作是根据当前日期/时间桶开始写入正确的分区。但是在生产场景中它值得避免使用Tombstone扫描。