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