hbase存儲優化

 

 

 

 

 

 

一、上面的2張圖主要說明hbase的存儲特色

(1)、每一個值（每條記錄的每個列的值）的存儲，都完整的存儲了rowkey、column family、column、版本(時間戳)，以及該列的值。

     這樣其實很浪費存儲空間。對應的最直接的存儲優化方案就是縮短rowkey、column family、column、版本(時間戳)的長度。在建表的時候就把這幾項設置的極其短。

(2)、hbase是列式存儲，天生就適合進行壓縮等優化。

(3)、也能夠經過（合併多個記錄爲一條記錄）減小rowkey來減小表的記錄數，達到減小key查找的效果，從而提高查詢性能。代價就是每次查詢的結果須要解析拆開，而且讀取的對象比原來的單個記錄要大。

 

 

 

 

二、hbase的存儲優化的方案選擇：壓縮仍是編碼

 

(1)、參照這篇文章，對比了hbase編碼和壓縮2種優化方案的優缺點

A、REFIX_TREE編碼方式不只能起到壓縮的效果

B、並且比較省CPU和內存。

http://blog.csdn.net/javastart/article/details/51820212

 

(2)、下面這篇文章，列出了PREFIX_TREE編碼方式的優勢：

A、REFIX_TREE提高從DataBlock中查找數據的效率。

B、省內存和cpu。

http://zjushch.iteye.com/blog/1843793

 

 

三、具體的優化命令

==========hbase命令================================================

 

disable 'logs:radwa'

alter 'logs:radwa', NAME => 'info', DATA_BLOCK_ENCODING => 'PREFIX_TREE' #修改編碼（此編碼效果最好）

#alter 'logs:radwa', NAME => 'info', COMPRESSION => 'snappy'     #修改壓縮

enable 'logs:radwa'                                            #enable表後壓縮還不會生效, 須要當即生效

major_compact 'logs:radwa'                                     #這個命令執行的時間會至關長, 會對整個集羣的CPU, IO有大量的佔用

 

 

==========hbase命令================================================

 

 

四、優化效果

   線上實測500G的表，編碼後變爲140G，效果仍是不錯的。

   至於查詢效率的提高，我並無測試。理論上是應該有提高的，固然您須要根據本身的業務實際選擇本身的優化方式。

   這裏任然有巨大的優化空間，好比把rowkey等設置的比較短，也能夠省下不少存儲空間。