SSTables压缩（主要和次要）的边界在什么时候变得无效？
如果我有500G SSTables的主要压缩和我的最终SSTable将超过1TB - 这对于一个节点“重写”这个大数据集是否有效？
这可能需要大约一天的硬盘驱动器，并需要双倍的空间，所以有这方面的最佳做法吗？
答案 0 :(得分：9)
1 TB是单个节点可以处理多少数据的合理限制，但实际上，节点完全不受数据 size 的限制，只有速率运作。
一个节点上可能只有80 GB的数据，但是如果你绝对使用随机读取并且它没有大量的RAM，它甚至可能无法合理地处理这些数量的请求率。类似地，一个节点可能有10 TB的数据，但是如果你很少从中读取数据，或者你的数据的一小部分是热的（这样它可以被有效地缓存），它就会很好。
当您在一个节点上拥有大量数据时，压缩肯定是一个需要注意的问题，但有几点需要注意：
首先，“最大”的压缩，结果是单个巨大的SSTable，很少发生，甚至更多，因为节点上的数据量增加。 （在顶级压缩发生之前必须发生的次要压缩的数量会随着您已执行的顶级压缩的数量呈指数级增长。）
其次，您的节点仍然可以处理请求，读取速度会慢一些。
第三，如果您的复制因子高于1并且您没有以一致性级别ALL读取，则其他副本将能够快速响应读取请求，因此您不应该从客户端角度看到延迟的巨大差异
最后，有plans to improve the compaction strategy可能对某些较大的数据集有帮助。