我正在评估Apache Cassandra 2.0.14上的插入过程。我使用一个名为YCSB的基准测试工具，它每秒向一个带有1个节点的Cassandra集群发送1条记录。
在每条记录中，我使用Nodetool（命令cfstats）检查Memtable数据大小，我意识到Memtable数据大小按比例增长直到第29条记录。但是，在第30条记录中，Memtable数据大小与最新记录的比例并不相同。检查以下结果：
N of Records：（1,10,25,30）
可记录数据大小（字节）:( 11810,118100,295250,217614）
与第1名相关的比例：（ - ，10,25,18.43 *）
*：应为30
为什么会这样？
直到第30条记录才有冲洗过程。
cassandra.yaml 中的一些属性：
memtable_total_space_in_mb: 10
memtable_flush_writers: 1
memtable_flush_queue_size: 4
答案 0 :(得分：1)
刚开始，2.0.14很老了，这些设置（我假设只是针对这个测试？）远非最佳。我强烈建议至少使用2.1，但出于多种原因（包括此指标的准确性），您应该考虑3.11。在2.1之后，这个计算是不同的。
确保jamm代理正在运行，否则会使memtable size metric非常不准确。它用于计算记忆的深度大小。
每次应用突变时，都会决定是否重新计算实时比率。从上次为每个表计算的每10次操作。这是异步启动到MemoryMeter线程池，并不阻止突变的插入。当它运行时，它将找到memtable的实际“深度”，包括JVM开销。将其与memtable的运行假定大小进行比较，以找到liveRatio。
要计算当前实时可记忆空间的估计值，将上次计算的实时比率乘以memtable的当前大小。这是一个非常粗略的估计并且有一些界限，因为某些类型的数据（即墓碑）与其他数据有很多不同的足迹。
在2.1和3.0中，你可以期望这个指标更符合预期（虽然可能仍然不完美）但是在2.0中，可记忆数据大小是一个粗略的启发式，用于确定何时刷新并且不应该（很容易）确定性。如果没有其他任何东西来自liveRatio的异步性质。