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