为什么在Cassandra中有大的分区这么糟糕？

Question

我已经看到了这个警告，但无法找到关于此主题的任何详细解释。

Answer 1

对于单一分区起动

细胞的最大数量（行×列）是 2十亿。

如果你允许分区增长无界，你最终会达到这个限制。

在这个理论极限之外，与大型分区对JVM和读取时间的影响相关联存在实际限制。这些实际限制从版本到版本不断增加。这种实际的限制并不是固定的，而是随着数据模型，查询模式，堆大小和配置的变化而变化，这使得很难直接回答太大的问题。

从2.1和早期的3.0版本开始，读取和压缩的主要成本来自对每个column_index_size_in_kb标记一行的索引进行反序列化。您可以增加key_cache_size_in_mb进行读取操作，以防止不必要的反序列化，但会减少堆空间并填充旧版本。您可以增加列索引大小，但会增加读取时最差的IO成本。 Theres还为CMS和G1设置了许多不同的设置，以便在阅读这些大分区时调整对象分配的巨大峰值的影响。在改善这一点方面正在积极努力，因此未来它可能不再是瓶颈。

维修工作也仅限于（在最好的情况下）分区级别。因此，如果说你不断地追加到一个分区，并且在两个节点上的该分区的散列不是在一个确切的时间进行比较（分布式系统本质上保证这一点），则必须对整个分区进行流式传输以确保一致性。增量修复可以减少这种影响，但是仍然会大量传输大量的数据和波动的磁盘，因此需要不必要地将它们压缩在一起。

您可以继续添加到具有问题的角落案例和场景中。很多时候，大型分区可能需要才能读取，但其中涉及的调整和转角情况并不是真的值得，而只是设计数据模型以便与Cassandra预期的方式更友好。我会建议瞄准100MB，但你可以远远超出这个舒适。进入千兆位，你需要开始考虑调整它（取决于数据模型，用例等）。