不正確的卡桑德拉的memTable數據大小

Question

我評價一個基於Apache 2.0.14卡桑德拉插入過程。我正在使用名爲YCSB的基準測試工具，它每秒發送1條記錄到一個單節點的Cassandra集羣。

在每個記錄予檢查的memTable數據大小與Nodetool（命令cfstats）和I意識到MemTable中數據大小長大成比例，直到第29記錄。但是，在第30條記錄中，Memtable數據大小與最新記錄不成比例。檢查以下的結果：

記錄的N：（1，10，25，30）

MemTable中數據大小（字節）：（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 

Answer 1

剛下手，2.0.14是很舊，這些設置（我假設只是對這個測試？）遠遠沒有達到最佳。我強烈建議至少使用2.1，但出於多種原因，包括此度量標準的準確性，您應該考慮3.11。在2.1之後，這個計算是不同的。

確保JAMM代理正在運行或會令的memTable大小的度量非常不準確。它用於計算memtable的深度大小。

應用突變時，它都會將決定是否應該重新計算活率。從上次計算每個表的每10次操作。這是與MemoryMeter線程池異步啓動的，並且不會阻止突變的插入。當它運行時，它會發現memtable的實際「深度」，包括JVM開銷。這與memtable的正在運行的假定大小進行比較以查找liveRatio。

爲了計算當前直播的memTable空間的最後計算出的活比由memTable中的當前大小相乘的估計值。這是一個非常粗略的估計，並且有一些界限，因爲某些類型的數據（即墓碑）與其他數據有很大不同。

在2.1和3.0中，你可以預期這個度量與期望值更加一致（雖然可能還不完美），但在2.0中，memtable數據的大小對於確定何時刷新和不應該被期望爲）確定性的。如果沒有其他來自liveRatio更新的異步本質。