Hbase Schema 設計注意事項及最佳實踐總結

        一個列族的全部列在硬盤上存放在一塊兒，使用這個特性能夠把不一樣訪問模式的列放在不一樣列族，以便隔離它們。這也是HBase被稱爲面向列族的存儲(column-family-oriented store)的緣由。

一、RowKey設計

        在設計HBase表時，行鍵是惟一重要的事情，應該基於預期的訪問模式來爲行鍵建模。 
        行鍵決定了訪問HBase表時能夠獲得的性能。這個結論根植於兩個事實：region基於行鍵爲一個區間的行提供服務，而且負責區間內每一行；HFile在硬盤上存儲有序的行。當region刷寫留在內存裏的行時生成了HFile。這些行已經排過序，也會有序地刷寫到硬盤上。HBase表的有序特性和底層存儲格式可讓你根據如何設計行鍵以及把什麼放入列限定符來推理其性能表現。 
        有效的行鍵設計不只要考慮把什麼放入行鍵中，並且要考慮它們在行鍵裏的位置。 信息在行鍵裏的位置和選擇放入什麼信息同等重要。
HBase中的數據是三維有序存儲的，經過rowkey（行鍵），column key（column family和qualifier）和TimeStamp（時間戳）這個三個維度組合能夠對HBase中的數據進行快速定位。

RowKey長度控制

        RowKey是一個二進制字節數組，能夠是任意字符串，最大長度 64kb ，實際應用中通常爲10-100bytes，以byte[] 形式保存，通常設計成定長。建議越短越好，不要超過16個字節。由於Hbase按照column family列族組織存儲，每一個列族存儲時都包含RowKey，防止RowKey自己佔用過多空間，64位OS，內存8字節對齊，控制在16個字節，8字節的整數倍利用了OS的最佳特性。

RowKey惟一原則

        必須在設計上保證其惟一性。因爲在HBase中數據存儲是Key-Value形式，若HBase中同一表插入相同Rowkey，則原先的數據會被覆蓋掉(若是表的version設置爲1的話)，因此務必保證Rowkey的惟一性。

Rowkey的排序原則

        HBase的Rowkey是按照ASCII有序設計的，在設計Rowkey時要充分利用這點。一般不將有序的信息放置在RowKey的高位，防止出現熱點問題。

Rowkey散列原則

        實際應用中須要將數據均衡分佈在每一個RegionServer，以實現負載均衡的概率。若是沒有散列字段，首字段直接是時間信息，全部的數據都會集中在一個RegionServer上，這樣在數據檢索的時候負載會集中在個別的RegionServer上，形成熱點問題，會下降查詢效率。

Region熱點問題

        HBase中的行是按照rowkey的字典順序排序的，這種設計優化了scan操做，能夠將相關的行以及會被一塊兒讀取的行存取在臨近位置，便於scan。然而糟糕的rowkey設計是熱點的源頭。 熱點發生在大量的client直接訪問集羣的一個或極少數個節點（訪問多是讀，寫或者其餘操做）。大量訪問會使熱點region所在的單個機器超出自身承受能力，引發性能降低甚至region不可用，這也會影響同一個RegionServer上的其餘region，因爲主機沒法服務其餘region的請求。 設計良好的數據訪問模式以使集羣被充分，均衡的利用。

二、避免熱點問題的策略

Reverse反轉

        針對固定長度的Rowkey反轉後存儲，這樣可使Rowkey中常常改變的部分放在最前面，能夠有效的隨機Rowkey。如手機號反轉，就避免了以手機號那樣比較固定開頭(137x、15x等)致使熱點問題；爲放置時間戳致使熱點問題，能夠將時間反轉Long.Max_Value - timestamp 追加到key的末尾。但這樣作的缺點是犧牲了Rowkey的有序性。

Salt加鹽

        Salting是將每個Rowkey加一個前綴，前綴使用一些隨機字符，使得數據分散在多個不一樣的Region，達到Region負載均衡的目標。Salt增長了寫操做的吞吐量，不過缺點是同時增長了讀操做的開銷。

Hash散列或者Mod

        用Hash散列來替代隨機Salt前綴的好處是能讓一個給定的行有相同的前綴，這在分散了Region負載的同時，使讀操做也可以推斷。肯定性Hash(好比md5後取前4位作前綴)能讓客戶端重建完整的RowKey，可使用get操做直接get想要的行。若是Rowkey是數字類型的，也能夠考慮Mod方法。

三、Column Family

        ColumnFamily儘可能少，緣由是過多的columnfamily之間會互相影響。

四、column

        對於column須要擴展的應用，column能夠按普通的方式設計，可是對於列相對固定的應用，最好採用將一行記錄封裝到一個column中的方式，這樣可以節省存儲空間。

五、Hbase Schema設計的最佳實踐彙總

• 在HBase中，Value永遠和它的Key一塊兒傳輸。若是你的RowKey和列名很大，會佔據大量的存儲空間傳輸IO壓力，同時影響Hbase的緩存和總體性能。列族儘量越短越好，最好是一個字符，冗長的屬性名雖然可讀性好，可是更短的屬性名存儲在HBase中會更好。
• HBase沒有跨行事務的概念，在單個API調用裏而不是多個API調用裏完成訪問模式。HBase不支持跨行事務，要避免在客戶端代碼裏維護這種複雜的邏輯。
• 經過合理hbase 行鍵（rowkey)設計實現快速的多條件查詢，所採用的方法將全部要用於查詢中的列通過一些處理後存儲在rowkey中，查詢時經過rowkey進行查詢，提升rowkey的利用率，加快查詢速度。
• 嵌套的實體是從關係型映射到非關係型的又一個工具。若是你獲得子實體的惟一方法是經過父實體，而且你但願在一個父實體的全部子實體上有事務級保護，這種技術是最正確的選擇。
• 在列限定符和時間戳上創建索引，可讓你在一行上不用掃描前面全部的列而直接跳到正確的列。 
• 在同一列族裏存儲類似訪問模式的全部數據。
• 列限定符能夠用來存儲數據，就像單元同樣。