Chr*_*ink 16
对于初学者
单个分区中的最大单元数(行x列)为20亿.
如果您允许分区无限增长,您最终会遇到此限制.
超出理论限制,存在与大型分区对JVM和读取时间的影响相关的实际限制.这些实际限制在不同版本之间不断增加.这个实际限制并不固定,但随着数据模型,查询模式,堆大小和配置的变化而变化,这使得很难直接回答过多的问题.
从2.1和3.0版本开始,读取和压缩的主要成本来自反序列化索引,该索引每次都标记一行column_index_size_in_kb.您可以增加key_cache_size_in_mbfor读取以防止不必要的反序列化,但这会减少堆空间并填充旧的gen.您可以增加列索引大小,但会增加读取时的最坏情况IO成本.还有许多不同的CMS和G1设置,可以在读取这些大分区时调整对象分配中巨大峰值的影响.积极努力改善这一点,以便将来可能不再是瓶颈.
修复也只限于(在最好的情况下)分区级别.因此,如果说您经常附加到分区,并且在不准确的时间比较2个节点上的该分区的散列(分布式系统基本上保证这一点),则必须对整个分区进行流式传输以确保一致性.增量修复可以减少对此的影响,但是仍会大量传输大量数据和波动的磁盘,这些都需要不必要地压缩在一起.
您可以继续添加有问题的角落案例和场景.很多时候大型分区都可以读取,但是它们中涉及的调整和极端情况并不值得,更好的方法是设计数据模型以便与Cassandra的预期相符.我建议瞄准100mb,但你可以远远超出这个范围.进入Gbs,你需要开始考虑调整它(取决于数据模型,用例等).
| 归档时间： |
|
| 查看次数： |
2353 次 |
| 最近记录： |