對于Bigtable類型的分布式數據庫應用來說，用戶往往會對其性能狀況有極大的興趣，這其中又對實時數據插入性能更為關注。HBase作為Bigtable的一個實現，在這方面的性能會如何呢？這就需要通過測試數據來說話了。
數據插入性能測試的設計場景是這樣的，取隨機值的Rowkey長度為2000字節，固定值的Value長度為4000字節，由于單行Row插入速度太快，系統統計精度不夠，所以將插入500行Row做一次耗時統計。
這里要對HBase的特點做個說明，首先是Rowkey值為何取隨機數，這是因為HBase是對Rowkey進行排序的，隨機Rowkey將被分配到不同的region上，這樣才能發揮出分布式數據庫的性能優點。而Value對于HBase來說不會進行任何解析，其數據是否變化，對性能是不應該有任何影響的。同時為了簡單起見，所有的數據都將只插入到一個表格的同一個Column中。
在測試之初，需要對集群進行調優，關閉可能大量耗費內存、帶寬以及CPU的服務，例如Apache的Http服務。保持集群的寧靜度。此外，為了保證測試不受干擾，Hbase的集群系統需要被獨立，以保證不與HDFS所在的Hadoop集群有所交叉。
那么做好一切準備，就開始進行數據灌入，客戶端從Zookeeper上查詢到Regionserver的地址后，開始源源不斷的向Hbase的Regionserver上喂入Row。
這里，我寫了一個通過JFreeChart來實時生成圖片的程序，每3分鐘，喂數據的客戶端會將獲取到的耗時統計打印在一張十字坐標圖中，這些圖又被保存在制定的web站點中，并通過http服務展示出來。在通過長時間不間斷的測試后，我得到了如下圖形：
這個圖形非常有特點，好似一條直線上，每隔一段時間就會泛起一個波浪，且兩個高峰之間必有一個較矮的波浪。高峰的間隔則呈現出越來越大的趨勢。而較矮的波浪恰好處于兩高峰的中間位置。
為了解釋這個現象，我對HDFS上Hbase所在的主目錄下文件，以及被插入表格的region情況進行了實時監控，以期發現這些波浪上發生了什么事情。
回溯到客戶端喂入數據的開始階段，創建表格，在HDFS上便被創建了一個與表格同名的目錄，該目錄下將出現第一個region，region中會以family名創建一個目錄，這個目錄下才存在記錄具體數據的文件。同時在該表表名目錄下，還會生成一個“compaction.dir”目錄，該目錄將在family名目錄下region文件超過指定數目時用于合并region。
當第一個region目錄出現的時候，內存中最初被寫入的數據將被保存到這個文件中，這個間隔是由選項“hbase.hregion.memstore.flush.size”決定的，默認是64MB，該region所在的Regionserver的內存中一旦有超過64MB的數據的時候，就將被寫入到region文件中。這個文件將不斷增殖，直到超過由“hbase.hregion.max.filesize”決定的文件大小時（默認是256MB，此時加上內存刷入的數據，實際最大可能到256+64M），該region將被執行split，立即被一切為二，其過程是在該目錄下創建一個名為“.splits”的目錄作為標記，然后由Regionserver將文件信息讀取進來，分別寫入到兩個新的region目錄中，最后再將老的region刪除。這里的標記目錄“.splits”將避免在split過程中發生其他操作，起到類似于多線程安全的鎖功能。在新的region中，從老的region中切分出的數據獨立為一個文件并不再接受新的數據（該文件大小超過了64M，最大可達到（256+64）/2=160MB），內存中新的數據將被保存到一個重新創建的文件中，該文件大小將為64MB。內存每刷新一次，region所在的目錄下就將增加一個64M的文件，直到總文件數超過由“hbase.hstore.compactionThreshold”指定的數量時（默認為3），compaction過程就將被觸發了。在上述值為3時，此時該region目錄下，實際文件數只有兩個，還有額外的一個正處于內存中將要被刷入到磁盤的過程中。Compaction過程是Hbase的一個大動作，Hbase不僅要將這些文件轉移到“compaction.dir”目錄進行壓縮，而且在壓縮后的文件超過256MB時，還必須立即進行split動作。這一系列行為在HDFS上可謂是翻山倒海，影響頗大。待Compaction結束之后，后續的split依然會持續進行一小段時間，直到所有的region都被切割分配完畢，Hbase才會恢復平靜并等待下一次數據從內存寫入到HDFS的到來。
理解了上述過程，則必然對HBase的數據插入性能為何是上圖所示的曲線的原因一目了然。與X軸幾乎平行的直線，表明數據正在被寫入HBase的Regionserver所在機器的內存中。而較低的波峰意味著Regionserver正在將內存寫入到HDFS上，較高的波峰意味著Regionserver不僅正在將內存刷入到HDFS，而且還在執行Compaction和Split兩種操作。如果調整“hbase.hstore.compactionThreshold”的值為一個較大的數量，例如改成5，可以預見，在每兩個高峰之間必然會等間隔的出現三次較低的波峰，并可預見到，高峰的高度將遠超過上述值為3時的高峰高度（因為Compaction的工作更為艱巨）。由于region數量由少到多，而我們插入的Row的Rowkey是隨機的，因此每一個region中的數據都會均勻的增加，同一段時間插入的數據將被分布到越來越多的region上，因此波峰之間的間隔時間也將會越來越長。
再次理解上述論述，我們可以推斷出Hbase的數據插入性能實際上應該被分為三種情況，即直線狀態、低峰狀態和高峰狀態。在這三種情況下得到的性能數據才是最終Hbase數據插入性能的真實描述。那么提供給用戶的數據該是采取哪一個呢？我認為直線狀態由于其所占時間會較長，尤其在用戶寫入數據的速度也許并不是那么快的情況下，所以這個狀態下得到的性能數據結果更應該提供給用戶。