我有一个48个节点的C *群集（3.11.4），分布在RF = 3的4个AWS区域中。几个月前，我开始注意到某些节点上的磁盘使用率持续增加。最初，我通过销毁节点并重建它们来解决了问题，但问题仍然存在。
最近我进行了更多调查，这就是我发现的内容：
-通过简单地查看磁盘空间使用情况，我将问题缩小到使用TWCS的CF（并且所有写入的行都具有ttl）
-在每个区域中，有3个节点存在磁盘空间增加（匹配复制因子）的问题
-在每个节点上，我使用sstableexpiredblockers跟踪到特定的SSTable问题。这个SSTable阻止所有其他SSTable被清理
-在SSTable中，使用sstabledump，发现一行没有其他行那样的ttl，并且似乎是来自团队中其他人的测试内容，却忘记了添加ttl
-除该行外，其他所有行均显示“ expired：true”，因此我很怀疑
-当我查询该特定分区键时，没有任何结果
-我还是尝试删除该行，但这似乎并没有改变任何内容
-我也尝试过nodetool scrub，但这也无济于事
没有ttl的这个流氓行会解释这个问题吗？如果是这样，为什么？如果没有，还有其他想法吗？为什么该行在sstabledump中显示，但在我查询时却不显示？
感谢您的帮助或建议！
答案 0 :(得分：1)
一个可能的原因是模式的定义，更确切地说是分区键，因为您可能有记录的大部分被分配给几个令牌，因此这种情况称为“热点”。
例如，假设您的表中有汽车的信息，而分区令牌是它所在的国家，那么被分配来保存来自美国或德国的汽车数据的节点将有更多的数据compared to the ones that have the tokens for cars in Bangladesh or Pakistan
您可能要使用复合分区键，以使数据碎片均匀分布。
答案 1 :(得分：0)
我能够通过在CF上进行大型压实来解决问题。
这是我对它为什么起作用的理解：
TWCS将数据存储在时间窗口中，并且当所有数据在sstable中到期时，它将删除整个文件。 TWCS不会在不同的时间窗口中压缩sstables
在没有ttl的情况下写入数据意味着您无法删除sstable，因为它的某些数据没有过期。甚至删除它还不够，因为删除该行只会在另一个sstable
cassandra出于性能原因将仅自动执行次要压缩，这意味着在这种情况下，它将永远无法压缩掉无效数据