我在运行“ nodetool cfhistograms”时看到表格数据。
Percentile SSTables Write Latency Read Latency Partition Size Cell Count
(micros) (micros) (bytes)
50% 2.00 0.00 8239.00 924 20
75% 4.00 0.00 9887.00 1109 20
95% 4.00 0.00 51012.00 1916 24
98% 4.00 0.00 51012.00 2299 29
99% 4.00 0.00 51012.00 2759 35
Min 0.00 0.00 150.00 73 2
Max 4.00 0.00 51012.00 3973 60
能否请您解释一下这些是如何计算的？我理解％le的概念，但是我想知道多少读/写被认为可以计算上述结果。
最佳答案
现在是nodetool tablehistograms。每个表都有一个用于读取和写入的直方图，该直方图在本地读取/写入完成后会更新。这不包括等待副本达到一致性级别等的网络时间，即nodetool proxyhistograms。
有一些历史，它们随时间变化，因此取决于cassandra的版本来解释输出。几年前，我在峰会上做了一次演讲，可以解释一些“为什么”。至于一段时间（仅2.1），使用度量标准以指数方式衰减的储层报告了cfhistograms，这是非常不准确的。在2.1之前，cfhistograms的显示方式完全不同，但此时不值得一提。
当前，它们由真实的直方图表示，而不是由存储库（here）表示。这些直方图具有固定的桶，每个桶比以前大20％。因为它是固定的，所以存储的值只是一个long []（atomiclongarray / longadder []取决于版本）。它确定哪个存储桶拥有该值，因此在更坏的情况下，它报告的值比实际值差20％。根据该直方图，使用标准机制计算百分位数。
这些直方图中保留了2个。 “所有时间”直方图和“最近”直方图。自从Cassandra启动以来，所有时段的直方图一直在不断增加。通过发现它们之间的差异，可以使用它来准确区分自您上次查看以来哪个桶中发生了多少事件。一直以来的直方图都应该是对其进行监视和警报的准确性。 “最近”直方图EstimatedHistogram存储桶的值。然后，较新的值要比以前的值成指数地增加，从而给出“大约最后15分钟”的视图，这并不是真正用于监视，而是用于即席查看现在的状态。注意：直到forward decays（在2.2与cfhistogram之间），才报告所有时间值，直到最近的直方图才存在。
“ SSTables”列是读取时接触的sstable的数量。 3.0.9/3.8中“感动”的含义已更改。以前，如果检查sstable上的Bloomfilter意味着可能包括了磁盘IO，但后来它仅按令牌范围和时间戳过滤掉了东西。现在，如果Bloomfilter从读取中排除了sstable，则不计算在内。然后将其保存在上面提到的2个直方图中。
分区大小和单元数是根据磁盘上的数据生成的。每个sstable保持分区大小的直方图和写入时计算的单元数。读取表的该值时，它将合并所有sstable的统计信息，以生成此处在百分位计算中使用的表范围直方图。