Cassandra Memtable 数据大小不正确答案

【问题标题】：Incorrect Cassandra Memtable data sizeCassandra Memtable 数据大小不正确
【发布时间】：2017-08-17 11:10:05
【问题描述】：

我正在评估 Apache Cassandra 2.0.14 上的插入过程。我正在使用一个名为 YCSB 的基准测试工具，它每秒向具有 1 个节点的单个 Cassandra 集群发送 1 条记录。

在每条记录中，我使用 Nodetool（命令 cfstats）检查 Memtable 数据大小，我发现 Memtable 数据大小按比例增长，直到第 29 条记录。但是，在第 30 条记录中，Memtable 数据大小与最新记录不成比例。检查以下结果：

记录数：(1, 10, 25, 30)

Memtable 数据大小（字节）：(11810, 118100, 295250, 217614)

相对于 1st 的比例：(-, 10, 25, 18.43*)

*: 应该是 30

为什么会这样？

在第 30 条记录之前没有刷新过程。

cassandra.yaml中的一些属性：

memtable_total_space_in_mb: 10

memtable_flush_writers: 1

memtable_flush_queue_size: 4

【问题讨论】：

标签： cassandra

【解决方案1】：

刚开始，2.0.14 已经很老了，这些设置（我假设只是为了这个测试？）远非最佳。我强烈建议至少使用 2.1，但出于多种原因，包括该指标的准确性，您应该考虑使用 3.11。 2.1以后这个计算就不一样了。

确保 jamm 代理正在运行，否则会导致 memtable 大小指标非常不准确。用于计算memtable的深度大小。

每次应用突变时，它都会决定是否应该重新计算存活率。从上一次开始每 10 次操作就为每个表计算一次。这是与MemoryMeter 线程池异步启动的，不会阻止突变的插入。当它运行时，它将找到内存表的实际“深度大小”，包括 JVM 开销。这与内存表的运行假设大小进行比较以找到 liveRatio。

为了计算当前活动内存表空间的估计值，最后计算的活动率乘以内存表的当前大小。这是一个非常粗略的估计，并且有一些界限，因为某些类型的数据（例如墓碑）与其他类型的数据有很大不同。

在 2.1 和 3.0 中，您可以期望该指标更符合预期（尽管可能仍然不完美），但在 2.0 中，memtable 数据大小是确定何时刷新的粗略启发式，不应该（很容易）确定性的。如果 LiveRatio 更新的异步性质没有其他问题。

【讨论】：