最近我一直在纠结 TWCS 的具体工作原理。在我们的工作流程中,我们有一些包含时间序列数据的表,这些数据的 TTL 大部分是静态的。因此,决定使用 TWCS 作为压缩策略。然而,不幸的是,其中一些表似乎比平时占用了更多的空间,即它们似乎被最旧的 SSTable 阻塞。我们已经查明了一个潜在的根本原因。在一种情况下,现有记录可能会发生 TTL 重写,例如减少该现有记录的 TTL。在这种情况下,这条记录将驻留在多个具有较高和较低 TTL 的 SSTable 中,因此应该阻止其他 SSTable 被压缩,这是有意义的。事实上,过了一段时间,这些更新的记录似乎已过期,随后所有记录都被解锁。然而,
因此我开始阅读一些有关此的文章。我参考的一些文章例如https://thelastpickle.com/blog/2016/12/08/TWCS-part1.html或https://www.redshots.com/cassandra-twcs-must-have-ttls/。尤其是后者引起了我的怀疑,即“新”记录之间的 TTL 更改是否也会产生阻塞效果。后一篇文章特别提到,只有当 sstable 充满 TTL 时,才会删除整个 sstable,因此,一旦无法删除,后续的 sstable 也无法删除。
我们使用 TWCS 考虑以下场景:
例如,我们写入 TTL 为 5000 的 100 条记录,这些记录最终都在同一个 SSTable 中,然后随后,我们写入 100 条不同 TTL 为 100 的新记录,写入新列(但也许相同的分区)。
根据我的测试,我推测“TTL out”的前 100 条记录不会释放任何磁盘空间,直到包含具有最旧 TTL 的记录的 SSTable 到期。
然而,我对此并不完全有信心,特别是因为两个 SSTable 本质上不包含任何应该相互遮蔽的内容。因此,我认为逻辑上不应该有理由不从磁盘中删除这些表。此外,我还考虑了较旧的 TTL 数据和较新的 TTL 数据混合在最旧的 SSTable 中的可能性。我想这也会有同样的表现。总的来说,问题仍然存在。因此我想验证这个结论。
简而言之:使用 TWCS,从磁盘中删除 TTL 较低的新记录是否会被驻留在不同 SSTable 中的任何具有较高 TTL 的旧记录阻止?