我一直在网上搜索一些文档，以更好地了解如何处理cassandra中的大分区。
我在下面的链接上关注了一个文档： https://www.safaribooksonline.com/library/view/cassandra-high-performance/9781849515122/ch13s10.html。 关于“具有约束限制的大行”，请参见以下内容：
” in_memory_compaction_limit_in_mb的默认值为64。此值在conf / cassandra.yaml中设置。对于具有固定列的用例，永远不要超过该限制。设置此值可以用作健全性检查确保进程不会无意中将多个列写入同一键。 使用行缓存时，具有很多列的键也可能会出现问题，因为它要求将整个行存储在内存中。”
在/conf/cassandra.yaml中，我确实找到了一个名为“ in_memory_compaction_limit_in_mb”的配置。
cassandra.yaml中的定义如下： 在Cassandra 2.0中： in_memory_compaction_limit_in_mb （默认值：64）在内存中压缩的行的大小限制。较大的行溢出到磁盘上，并使用较慢的两次通过压缩过程。发生这种情况时，将记录一条消息，指定行键。推荐值是可用Java堆大小的5％到10％。
在Cassandra 3.0中：（在cassandra.yaml中找不到此类条目） compaction_large_partition_warning_threshold_mb （默认值：100）当压缩大于设置值的分区时，Cassandra会记录警告
我正在仔细研究in_memory_compaction_limit_in_mb的设置。 它提到在内存中进行了一些压缩，而在磁盘上进行了一些压缩。 据我了解，当压缩过程运行时： 正在从磁盘读取SSTABLE->（比较，删除了逻辑删除，删除了过时的数据）所有情况都在内存中发生--->将新的sstable写入磁盘->将删除旧表 此操作说明了较高的磁盘空间要求和磁盘I / O（带宽）。 如果我对压实的理解是错误的，请帮助我。内存中是否发生任何压缩。 在我的环境中 in_memory_compaction_limit_in_mb设置为800。 我需要了解目的和含义。
预先感谢
答案 0 :(得分：1)
in_memory_compaction_limit_in_mb不再需要，因为在写入之前不需要知道大小。不再有2遍压缩，因此可以忽略。您不必一次完成整个分区，一次只需要一行。
现在的主要成本是在内存中出现的分区的开头反序列化大索引。您可以增加column_index_size_in_kb来减小该索引的大小（以读取期间增加的IO成本为代价，但与反序列化相比可能微不足道）。另外，如果您使用的是更新版本（3.11+），则索引在超过一定大小后会被延迟加载，这会大大改善性能。