【发布时间】：2011-06-14 02:34:47
【问题描述】：
SSTables 压缩的边界在哪里（主要和次要）以及何时失效？
如果我有 500G SSTables 的主要压缩，并且我的最终 SSTable 将超过 1TB - 这对于一个节点“重写”这个大数据集是否有效？
这对于 HDD 来说可能需要大约一天的时间，并且需要双倍大小的空间，那么有没有最佳实践呢？
【问题讨论】：
【发布时间】：2011-06-14 02:34:47
【问题描述】：
1 TB 是单个节点可以处理多少数据的合理限制，但实际上，一个节点完全不受数据的 size 限制，只有 rate操作次数。
一个节点上可能只有 80 GB 的数据，但如果你绝对用随机读取来冲击它并且它没有很多 RAM，它甚至可能无法以合理的方式处理这么多的请求速度。类似地，一个节点可能有 10 TB 的数据，但如果您很少从它读取数据，或者您有一小部分数据是热的（以便可以有效地缓存它），它就可以了。
当您在一个节点上有大量数据时，压缩肯定是一个需要注意的问题，但有几点需要牢记：
首先，“最大”的压缩，即结果是一个巨大的 SSTable 的压缩很少发生，随着节点上数据量的增加更是如此。 （在顶级压缩发生之前必须发生的次要压缩的数量随着您已经执行的顶级压缩的数量而呈指数增长。）
其次，您的节点仍然能够处理请求，只是读取速度会变慢。
第三，如果您的复制因子高于 1 并且您没有以一致性级别 ALL 读取，则其他副本将能够快速响应读取请求，因此从客户端的角度来看，您不应该看到延迟有很大差异.
最后，plans to improve the compaction strategy 可能有助于处理一些更大的数据集。
【讨论】：