導讀：衆所周知，2006年Google公佈了自己的BigTable論文，作爲Google繼GFS和MapReduce兩項創新之後的又一項創新，其在設計用來針對海量數據處理情形下的管理結構型數據方面具有着巨大的技術優勢。而Hypertable和HBase是最知名的兩款基於BigTable爲藍本設計的數據庫，他們的不同之處在於Hypertable基於C++實現，而HBase則基於Java。兩種數據庫的性能也一直是人們爭論的熱點話題。在最近的一次性能測試中Hypertable在吞吐率測試中以2倍的性能優勢完全壓倒HBase。
近日，Hypertable和HBase進行了類似隨機讀取統一的測試， 結果表明Hypertable在吞吐量測試中以2倍的性能優勢壓倒HBase。HBase在410億和1670億的數據插入測試中不堪重負（垃圾數據收集）。在此次測試中Hypertable選用了0.9.5.5版，而HBase版本爲0.90.4（CDH3u2運行於Zookeeper）。
關於Hypertable
Hypertable高可用改進架構示意圖
| Hypertable系統主要包括Hyperspace、Master和Range Server三大組件。Hyperspace是一個鎖服務，地位相當於Google的Chubby，主要用於同步、檢測節點是否發生故障和存放頂層位置信息；Master主要用於完成任務分配，未來會有負載均衡以及災後重建（Range Server失效後自動恢復服務）等其他作用；Range Server是Hypertable的實際工作者，主要負責對一個Range中的數據提供服務，此外它還肩負起災後重建的責任，即重放本地日誌恢復自身故障前狀態；另外，還有訪問Hypertable的客戶端Client等組件。 |
介紹
Hypertable和HBase都是開源的可擴展的數據庫產品，它們的設計藍本同時基於Google BigTable。兩者的主要區別是Hypertable依靠C++語言實現，而HBase則基於Java編寫。 本次測試的環境爲16臺服務器，這16臺服務器通過千兆網絡連接在一起。
測試環境如下
操作系統：CentOS 6.1
CPU：2X AMD C32 Six Core Model 4170 HE 2.1Ghz
內存：24GB 1333MHz DDR3
硬盤：4X 2TB SATA Western Digital RE4-GP WD2002FYPS
Hypertable和HBase在HDFS的NameNode運行在1號測試機之上。而DataNodes則運行在4號測試機到15測試機之上。與此同時RangeServer和RegionServers運行在同一組計算機之中，並且配置使之可用所有的內存資源。三個Zookeeper和Hyperspace副本運行在1號測試機在3號測試機。在測試中，表被配置使用Snappy壓縮，同時使用Bloom filters加載Row Key。
隨機寫入測試
在隨機寫入測試中，Hypertable和HBase分別測試寫入4個不同的5TB數據。 使用的值大小分別爲10000、1000、100和10。同時固定爲20字節並將範圍內的隨機整數（隨機值的數據段取自英文Wiki百科XML頁面的200MB樣本）格式化爲零填充（0..number_of_keys_submitted*10）。
以下圖表爲測試結果
下表提供了詳細的性能測試結果
從圖中我們可以看出HBase在410億以及1670億的鍵測試中由於HBase的RegionServers併發模式失敗而拋出異常。無論如何配置當RegionServer產生無用數據的速度超過Java垃圾收集器就會發生如上的故障。爲了解決這一問題，建造新的垃圾回收計劃以克服問題，但這也會爲運行時的性能帶來沉重的代價。
在2005年的OOPSLA會議上Matthew Hertz和Emery D. Berger公佈了《Garbage Collection vs. Explicit Memory Management》的研究文檔，這爲相關研究提供堅實的信念。
隨機讀取測試
此次測試主要利用一組隨機讀取請求測試查詢吞吐量。每個系統運行兩個測試，一個測試採用Zipfian分佈，另一個測試採用均勻分佈。同時插入的鍵/值固定了大小，鍵採用固定的20字節，值的大小則固定1KB。鍵取值範圍來自ASCII中的整數，每次查詢測試返回一對鍵值。在每個系統上分別做兩次測試。一個加載5TB的數據，而另一個加載0.5TB數據。這使得實驗能夠測量每個系統內存到磁盤性能係數的高低。在加載5TB測試中共載入4,901,960,784的鍵值，而加載0.5TB測試中共載入490,196,078的鍵值。測試客戶端運行128個進程（總共爲512進程），同時在測試的整個過程中都保持最大的512查詢。這意味着每個測試共發出1億次查詢。
Zipfian分佈環境測試
在測試中將Hypertable查詢緩存配置爲2GB，同時爲了HBase保持良好的性能，將HBase的block cache和memstore限制使用默認值。測試結果見下圖
下表提供了詳細的性能測試結果
導致性能的差異主要是因爲Hypertable提供了查詢緩存，HBase也可以實現查詢緩存，但它是HBase的子系統。這個子系統生成了很多垃圾。雖然這會提高HBase的性能，但同時也帶來了一些弊端。尤其是在超大規模寫入以及超大的單元計算的混合工作負載。
在測試中出現了一個有趣的現象，當我們增加兩個系統的緩存塊的大小後對性能產生了不利的影響。事實上系統內有大量閒置CPU計算能力以維持減輕壓力的需求。通過消除高速緩存塊用於存儲未壓縮的塊，同時依靠操作系統的文件緩存存儲壓縮的塊可獲取更好的性能，因爲更多的數據集可以容納在內存之中。
均勻分佈測試環境
查詢的鍵集遵循均勻分佈的原則，下圖爲測試結果
下表提供了詳細的性能測試結果
在均勻分佈測試中HBase的性能接近Hypertable，這應該是磁盤IO瓶頸導致的，同時在測試期間產生一些垃圾數據。
結論
在過去5年，Hypertable社區一直在致力於努力完善產品。旨在將Hypertable構建成爲大數據領域高性能、高擴展性數據庫解決方案。（李智/編譯）
原文鏈接：Highscalability