cassandra - 为什么在Cassandra中拥有大分区如此糟糕？

Question

我到处都看到了这个警告，但是找不到关于此主题的任何详细说明。

Answer 1

对于初学者

The maximum number of cells (rows x columns) in a single partition is 2 billion.

如果允许分区无限增长，则最终将达到此限制。

在该理论限制之外，还有与大分区对JVM和读取时间的影响相关的实际限制。这些实际限制在各个版本之间都在不断增加。这个实际的限制不是固定的，而是随数据模型，查询模式，堆大小和配置而变化的，这使得很难就太大的问题给出直接的答案。

从2.1和3.0早期版本开始，读取和压缩的主要成本来自反序列化索引，该索引将每个 column_index_size_in_kb标记为一行。您可以增加 key_cache_size_in_mb来进行读取，以防止不必要的反序列化，但这会减少堆空间并填充旧的gen。您可以增加列索引的大小，但会增加最坏情况下读取时的IO成本。 CMS和G1还有许多不同的设置，可以在读取这些大分区时调整对象分配中大量峰值的影响。我们正在积极努力改善这一状况，因此将来可能不再是瓶颈。

修复也只会降级(在最佳情况下)分区级别。因此，如果说您一直在追加一个分区，并且在不精确的时间比较该分区在2个节点上的哈希值(分布式系统实质上保证了这一点)，则必须对整个分区进行流式传输以确保一致性。增量维修可以减少这种影响，但是您仍在流式传输大量数据和磁盘波动很大，因此需要将它们不必要地压缩在一起。

您可能可以继续添加一些有问题的极端情况和方案。很多时候都可以读取大型分区，但是其中涉及的调整和极端情况并不值得，最好仅设计数据模型以使其与Cassandra期望的方式友好。我建议将目标定位为100mb，但您可以远远超出此范围。进入Gbs，您将需要开始考虑对其进行调整(取决于数据模型，用例等)。