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