SSTables压缩的边界（主要和次要）在哪里，何时无效？
如果我有几个500G SSTable的主要压缩对象，而我的最终SSTable将超过1TB，这对于一个节点“重写”这个大数据集是否有效？
对于HDD，这可能需要一天的时间，并且需要双倍的空间，那么是否有最佳实践呢？
最佳答案
1 TB是一个单个节点可以处理的数据量的合理限制，但实际上，一个节点完全不受数据大小的限制，而仅受操作速率的限制。
一个节点上可能只有80 GB的数据，但是如果您用随机读取的方式对它进行绝对重击并且它没有太多的RAM，则它甚至可能无法以合理的速率处理该数量的请求。同样，一个节点可能有10 TB的数据，但是如果您很少从中读取数据，或者一小部分数据很热（以便可以有效地缓存它），那么它就可以了。
当您在一个节点上拥有大量数据时，压缩当然是一个要注意的问题，但是要牢记以下几点：
首先，“最大”压缩（其结果是单个巨大的SSTable）很少发生，甚至随着节点上数据量的增加而发生的次数甚至更多。 （在进行顶级压缩之前必须进行的次要压缩的数量成倍增加，这取决于您已经执行的顶级压缩的数量。）
其次，您的节点仍将能够处理请求，读取速度将变慢。
第三，如果您的复制因子大于1并且未以ALL的一致性级别进行读取，则其他副本将能够快速响应读取请求，因此从客户端的角度来看，您应该不会在延迟方面看到很大的差异。
最后，有些plans to improve the compaction strategy可能有助于处理一些较大的数据集。
关于nosql - Cassandra群集中每个节点有多少数据？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/4775388/