（用於測試對比：AbutionGraph v.s Hbase）
測試環境
測試環境包括測試過程中HBase集羣的拓撲結構、以及需要用到的硬件和軟件資源，硬件資源包括：測試機器配置、網絡狀態等等，軟件資源包括操作系統、HBase相關軟件以及測試工具等。
集羣拓撲結構
本次測試中，測試環境總共包含3臺物理機作爲Hadoop數據存儲，其中2臺物理機作爲RegionServer部署宿主機，每個宿主機上起2個RegionServer節點，整個集羣一共4個RegionServer節點。生成數據的YCSB程序與數據庫並不運行在相同的物理集羣。
單臺機器主機硬件配置
軟件版本信息
測試工具
YCSB全稱Yahoo! Cloud Serving Benchmark，是Yahoo公司開發的專門用於NoSQL測試的基準測試工具。github地址：https://github.com/brianfrankcooper/YCSB
YCSB支持各種不同的數據分佈方式：
- Uniform：等概論隨機選擇記錄
- Zipfian：隨機選擇記錄，存在熱記錄
- Latest：近期寫入的記錄爲熱記錄
測試場景
YCSB爲HBase提供了多種場景下的測試，本次測試中，我們導入15億條數據，並對如下場景進行測試：
因爲是基準測試，寫入和查詢的數據具有以下特性：
測試核心配置參數
<!-- blockcache -->
<property>
<name>hfile.block.cache.size</name>
<value>0.05</value>
</property>
<property>
<name>hbase.bucketcache.ioengine</name>
<value>offheap</value>
</property>
<property>
<name>hbase.bucketcache.size</name>
<value>61440</value>
</property>
<!-- memstore -->
<property>
<name>hbase.regionserver.offheap.global.memstore.size</name>
<value>30720</value>
</property>
<property>
<name>hbase.hregion.compacting.memstore.type</name>
<value>BASIC</value>
</property>
<property>
<name>hbase.regionserver.global.memstore.lowerLimit</name>
<value>0.30</value>
</property>
<property>
<name>hbase.hregion.memstore.block.multiplier</name>
<value>5</value>
</property>
<property>
<name>hbase.hregion.memstore.flush.size</name>
<value>268435456</value>
</property>
測試結果說明
單純查詢場景
測試參數
總記錄數爲15億，分爲300個region，均勻分佈在4臺region server上；插入操作執行20億次，150客戶端線程；
測試結果
吞吐量
讀延遲
資源使用情況
結果分析
- 吞吐量曲線說明：單個實例節點穩定在3.3W左右，整個集羣2臺物理機穩定在11.5W左右，單臺物理機穩定在5.8W左右。
- 資源使用情況說明：IO利用率達到80%左右，磁盤單盤TPS達到1.1W次，達到比較高的使用水平。CPU使用率只有40%左右，遠遠沒有達到瓶頸。
讀多寫少場景
測試參數
總記錄數爲15億，分爲300個region，均勻分佈在4臺region server上；查詢操作執行20億次；查詢請求分佈遵從zipfian分佈；讀寫比例8:2；
測試結果
吞吐量
讀取延遲
資源使用情況
結果分析
- 吞吐量曲線說明：單個實例節點穩定在2.7W左右（其中讀TPS穩定在1.9W左右，寫TPS穩定在0.47W左右），整個集羣2臺物理機穩定在10W左右，單臺物理機穩定在5W左右。
- 讀取延遲說明：讀P999延遲穩定在18ms左右。寫P999延遲穩定在40ms左右。讀寫平均延遲都在1ms左右。
- 資源使用情況說明：IO利用率達到80%左右，磁盤單盤TPS達到0.8W次，達到較高的使用水平。CPU使用率達到50%。
異常情況分析
特別說明的是，測試過程中在2點28分~2點32分左右吞吐量有一個比較明顯的突降，對應的P999讀延遲有一個明顯的飆升。直觀上來看，根據資源使用情況，對應時間點測試節點的帶寬有一個非常明顯的突升，IOWait有一個明顯的增大，對應的FsPReadTime_P999也有一個明顯的增大，基本可以確定隨機讀P999讀延遲飆升是因爲IOWait突變引起的，那什麼情況導致了這次網絡帶寬、IOWait飆升呢？可以看下面一張圖：
很明顯，在2點28分~2點32分之間減少了十幾個HFile文件，很容易就猜測到RegionServer執行了compaction操作導致網絡帶寬和硬盤IO有一個明顯的消耗，導致了隨機讀P999飆升。不過，HBase可以通過將hbase.regionserver.throughput.controller設置爲org.apache.hadoop.hbase.regionserver.compactions.PressureAwareCompactionThroughputController開啓compaction的限流功能，通過參數hbase.hstore.compaction.throughput.higher.bound限制compaction執行過程中的最大使用網絡帶寬。
讀寫均衡場景
測試參數
總記錄數爲15億，分爲300個region，均勻分佈在4臺region server上；查詢操作執行20億次；查詢請求分佈遵從zipfian分佈；讀寫比例 5:5；
測試結果
吞吐量
讀取延遲
資源使用情況
結果分析
- 吞吐量曲線說明：單個實例節點穩定在2.5W左右，整個集羣2臺物理機穩定在10W左右，單臺物理機基本穩定在5W左右。
- 讀取延遲說明：讀P999延遲穩定在20ms左右，讀P99延遲穩定在3ms左右。寫P999延遲穩定在25ms左右。讀平均延遲在1ms以內，寫平均延遲在1ms以內。
寫多讀少場景
測試參數
總記錄數爲15億，分爲300個region，均勻分佈在4臺region server上；查詢操作執行20億次；查詢請求分佈遵從zipfian分佈；讀寫比例2:8；
測試結果
吞吐量
讀取延遲
資源使用情況
結果分析
- 吞吐量曲線說明：單個實例節點穩定在3.5W左右，整個集羣2臺物理機穩定在14W左右，單臺物理機穩定在7W左右。
- 讀取延遲說明：讀P999延遲穩定在30ms左右，讀P99延遲穩定在10ms左右。寫P999延遲穩定在27ms左右。讀平均延遲在1ms左右，寫平均延遲在1ms以內。
測試結果分析
這次測試主要針對HBase 2.2.1這個版本進行了基準性能測試，測試結果顯示無論是吞吐量還是隨機讀寫延遲都達到了較高的水準，可以滿足線上的應用場景。在我們另一個針對於真實線上數據場景（非基準數據，所以測試結果中的絕對值沒有實際意義）的性能測試中對HBase 2.2.1和HBase 1.4.1這兩個版本進行了對比測試，詳細的測試結果就不在這裏展開介紹，在讀寫均衡場景下，HBase 2.2.1相比HBase 1.4.1在吞吐量方面有60%的性能提升，同時隨機讀P999延遲從50ms降低到30ms，隨機讀P99從20ms降低到7ms，而且來說抖動大大減少。