HBase設計原則
HBase設計原則
HBase是一個分散式資料庫，其效能的好壞主要取決於內部表的設計和資源的分配是否合理。
7.1、Rowkey設計
rowkey是HBase實現分散式的基礎，HBase通過rowkey範圍劃分不同的region，分散式系統的基本要求就是在任何時候，系統的訪問都不要出現明顯的熱點現象，所以rowkey的設計至關重要，一般我們建議rowkey的開始部分以hash或者MD5進行雜湊，儘量做到rowkey的頭部是均勻分佈的。禁止採用時間、使用者id等明顯有分段現象的標誌直接當作rowkey來使用。
7.2、列簇設計
HBase的表設計時，根據不同需求有不同選擇，需要做線上查詢的資料表，儘量不要設計多個列簇，我們知道，不同的列簇在儲存上是被分開的，多列簇設計會造成在資料查詢的時候讀取更多的檔案，從而消耗更多的I/O。
7.3、TTL設計
選擇合適的資料過期時間也是表設計中需要注意的一點，HBase中允許列簇定義資料過期時間，資料一旦超過過期時間，可以被major compact進行清理。大量無用歷史資料的殘餘，會造成region體積增大，影響查詢效率。
7.4、Region設計
一般地，region不宜設計成很大，除非應用對階段性效能要求很多，但是在將來執行一段時間可以接受停服處理。region過大會導致major compact呼叫的週期變長，而單次major compact的時間也相應變長。major compact對底層I/O會造成壓力，長時間的compact操作可能會影響資料的flush，compact的週期變長會導致許多刪除或者過期的資料不能被及時清理，對資料的讀取速度等都有影響。
相反，小的region意味著major compact會相對頻繁，但是由於region比較小，major compact的相對時間較快，而且相對較多的major compact操作，會加速過期資料的清理。
當然，小region的設計意味著更多的region split風險，region容量過小，在資料量達到上限後，region需要進行split來拆分，其實split操作在整個HBase執行過程中，是被不怎麼希望出現的，因為一旦發生split，涉及到資料的重組，region的再分配等一系列問題。所以我們在設計之初就需要考慮到這些問題，儘量避免region的執行過程中發生split。
HBase可以通過在表建立的時候進行region的預分配來解決執行過程中region的split產生，在表設計的時候，預先分配足夠多的region數，在region達到上限前，至少有部分資料會過期，通過major compact進行清理後， region的資料量始終維持在一個平衡狀態。
region數量的設計還需要考慮記憶體上的限制，通過前面的介紹我們知道每個region都有memstore，memstore的數量與region數量和region下列簇的數量成正比,一個RS下memstore記憶體消耗：
Memory = memstore大小 * region數量 * 列簇數量
如果不進行前期資料量估算和region的預分配，通過不斷的split產生新的region，容易導致因為記憶體不足而出現OOM現象。