前面，咱們已經打下了不少關於HBase的理論基礎，今天，咱們主要聊聊在實際開發使用HBase中，須要關注的一些最佳實踐經驗。git
1.Schema設計七大原則
1）每一個region的大小應該控制在10G到50G之間；github
2）一個表最好保持在 50到100個 region的規模；面試
3）每一個cell最大不該該超過10MB，若是超過，應該有些考慮業務拆分，若是實在沒法拆分，那就只能使用mob；算法
4）跟傳統的關係型數據庫不一樣，一個HBase的表中列族最多不超過3個，列族中的列能夠動態添加的，不要設計過多列族；數據庫
5）列族名必須儘可能短，由於咱們知道在存儲的時候，每一個keyvalue都會包含列族名；性能優化
6）若是一個表存在一個以上的列族，那麼必需要注意，不一樣列族之間行數相差不要太大。 例如列族A有10萬行，而列族B有1億行，那麼rowkey就有1億行，而region是按照行鍵進行切分的，所以列族A可能會被打散爲不少不少小region，這會致使在掃描列族A時會引起較多IO，效率低下。app
7）列族能夠設置TTL時間，HBase在超過設定時間後，會自動刪除數據。分佈式
設置方法有兩種：性能
# 建表時設置,TTL單位爲秒，此例中列簇'f1'的數據保留1天（86400秒）優化
hbase(main):002:0>create 'table', {NAME => 'f1', TTL => 86400}
# 經過修改表設置
hbase(main):002:0>alter 'table', {NAME => 'f1', TTL => 86400}
這裏須要注意，一旦超過設定時間後，該數據就沒法讀取了，可是，真正的過時數據刪除，是發生在major compaction時。
2.RowKey設計三大策略
HBase做爲一個分佈式存儲數據庫，雖然擴容很是容易，可是，對於「熱點」問題，仍是很是頭疼的。
所謂「熱點」問題（HotSpotting），就是請求（讀或者寫）短期內落在了集中的個別region上，致使了該region所在機器的負載急劇上升，超過了單點實例的承受能力，從而引發性能降低或者不可用。
要解決這個問題，就須要設計RowKey時，使得數據儘可能往多個region上去寫。
舉個例子：
假如region按照26個字母分紅26個，那麼同時寫入m開頭的rowkey的記錄都會同時寫入同一個region
好比m001,m002,m003,m004,m005。
所以，RowKey的設計很是關鍵。常見的設計策略有這麼幾種。
1）salting
salting策略就是將生成隨機數放在行鍵的開頭做爲前綴，使得每一個行鍵有隨機的字典序。
對上面的案例進行優化，咱們採用了salting策略，插入前給每一個rowkey生成一個隨機的字母，變成了
am001,zm002,nm003,qm004,lm005
這樣就能同時往5個region裏面寫入了，成功打散。
反作用：因爲前綴生成是隨機的，所以若是想要按照字典序查詢這些行，則須要作更多的事情。從這個角度上看，salting增長了寫操做的吞吐量，卻也增大了讀操做的開銷。
2）Hashing
Hashing策略也是一種特殊的salting，是用一個單向的 hash 來取代隨機指派前綴。
這樣能使一個給定rowkey的行在「salted」時有相同的前綴，所以，這樣既能夠分散RegionServer間的負載的，同時也容許在讀操做時可以預測這個前綴值是什麼。肯定性hash（ deterministic hash ）可讓客戶端重建完整的行鍵，而後就能夠像正常同樣用Get方法查詢肯定的行。
3）reverse key
第三種預防hotspotting的方法是反轉一段固定長度或者可數的鍵，讓變化最多的某個位置放在rowkey的第一位，
反作用：對於Get操做沒有影響，可是不利於Scan操做進行範圍查詢，由於數據在原RowKey上的順序已經被打亂。
3.預分區
在 HBase核心特性—region split 中，咱們知道已經提到過關於預分區。
主要緣由是當一張表被首次建立時，只會分配一個region給這個表。所以，在剛剛開始時，全部讀寫請求都會落在這個region所在的region server上，而無論你整個集羣有多少個region server。不能充分地利用集羣的分佈式特性。
所以，預分區主要也是解決「熱點」問題。
最爲常見的建表語句爲：
create ‘tb’,{NAME => ‘f1’,COMPRESSION => ‘snappy’ }, { NUMREGIONS => 50, SPLITALGO => ‘HexStringSplit’ }
- NUMREGIONS 爲 region的個數，通常按照每一個region 8-10GB左右來計算region數量，若是集羣規模很是大，那麼region數量能夠適當取大一些
- SPLITALGO 爲 rowkey分割的算法，Hbase自帶了三種pre-split的算法，分別是 HexStringSplit、DecimalStringSplit 和 UniformSplit。
各類Split算法適用場景：
- HexStringSplit: rowkey是十六進制的字符串做爲前綴的
- DecimalStringSplit: rowkey是10進制數字字符串做爲前綴的
- UniformSplit: rowkey前綴徹底隨機
4.讀性能優化
前面主要講一些設計方面的優化點。
那若是在HBase的使用過程當中，發現查詢較慢，那麼就須要根據具體狀況，分析查詢慢的緣由，並採起相應的策略。
看到這裏了，原創不易，點個關注、點個贊吧，你最好看了～
知識碎片從新梳理，構建Java知識圖譜：https://github.com/saigu/JavaKnowledgeGraph（歷史文章查閱很是方便）
掃碼關注個人公衆號「阿丸筆記」，第一時間獲取最新更新。同時能夠免費獲取海量Java技術棧電子書、各個大廠面試題。