SSTables的压缩边界（主要和次要），在什么情况下会变得无效？
如果我将500G的SSTables进行主要压缩，最终的SSTable将超过1TB - 是否对一个节点来说“重写”这个大型数据集是有效的？
这可能需要一天时间才能完成，并且需要双倍的空间，因此是否有最佳实践可用？
1个回答
8
单个节点处理数据的合理限制是1TB，但实际上，一个节点并不受数据大小的限制，只受操作速率的限制。
一个节点可能只有80GB的数据，但如果你大量进行随机读取，并且它没有很多RAM，它甚至可能无法以合理的速度处理那么多的请求。同样，一个节点可能有10TB的数据，但如果你很少从中读取，或者你只有一小部分热数据（可以有效地缓存），那么它就可以很好地运行。
当一个节点上有大量数据时，压缩确实是需要注意的问题，但还有几件事情需要记住：
首先，“最大”的压缩（结果为单个巨大的SSTable）很少发生，尤其是当节点上的数据量增加时。（在执行顶级压缩之前必须发生的次要压缩的数量按已执行的顶级压缩数量呈指数增长。）
其次，你的节点仍然能够处理请求，只是读取会变慢。
第三，如果你的复制因子高于1，并且你不使用ALL一致性级别进行读取，其他副本将能够快速响应读取请求，因此从客户端的角度来看，你不应该看到延迟的大差异。
最后，有一些改进压缩策略的计划可能会对一些更大的数据集有所帮助。
- Tyler Hobbs
1
2我想补充一点，如果你有TB级别的数据，你可能不会进行太多的覆盖操作，这种情况下多个SSTable甚至不会因为布隆过滤器而减慢读取速度。 - jbellis
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接