精準 密碼學 表示 ems 格式 就會 特性 存儲 可能

2019/2/28 星期四

hbase表設計優化原則
https://www.cnblogs.com/qingyunzong/p/8696962.html
表設計
1、列簇設計
　　追求的原則是：在合理範圍內能盡量少的減少列簇就盡量減少列簇。
　　最優設計是：將所有相關性很強的 key-value 都放在同一個列簇下，這樣既能做到查詢效率 最高，也能保持盡可能少的訪問不同的磁盤文件。
　　以用戶信息為例，可以將必須的基本信息存放在一個列族，而一些附加的額外信息可以放在 另一列族。
2、RowKey 設計
　　HBase 中，表會被劃分為 1...n 個 Region，被托管在 RegionServer 中。Region 二個重要的 屬性：StartKey 與 EndKey 表示這個 Region 維護的 rowKey 範圍，當我們要讀/寫數據時，如 果 rowKey 落在某個 start-end key 範圍內，那麽就會定位到目標 region 並且讀/寫到相關的數 據

　　那怎麽快速精準的定位到我們想要操作的數據，就在於我們的 rowkey 的設計了
Rowkey 設計三原則
1、 rowkey 長度原則
　　Rowkey 是一個二進制碼流，Rowkey 的長度被很多開發者建議說設計在 10~100 個字節，不 過建議是越短越好，不要超過 16 個字節。
　　原因如下：
　　　　1、數據的持久化文件 HFile 中是按照 KeyValue 存儲的，如果 Rowkey 過長比如 100 個字 節，1000 萬列數據光 Rowkey 就要占用 100*1000 萬=10 億個字節，將近 1G 數據，這會極大 影響 HFile 的存儲效率；
　　　　2、MemStore 將緩存部分數據到內存，如果 Rowkey 字段過長內存的有效利用率會降低， 系統將無法緩存更多的數據，這會降低檢索效率。因此 Rowkey 的字節長度越短越好。
　　　　3、目前操作系統是都是 64 位系統，內存 8 字節對齊。控制在 16 個字節，8 字節的整數 倍利用操作系統的最佳特性。
2、rowkey 散列原則
　　如果 Rowkey 是按時間戳的方式遞增，不要將時間放在二進制碼的前面，建議將 Rowkey 的高位作為散列字段，由程序循環生成，低位放時間字段，這樣將提高數據均衡分布在每個 Regionserver 實現負載均衡的幾率。如果沒有散列字段，首字段直接是時間信息將產生所有 新數據都在一個 RegionServer 上堆積的熱點現象，這樣在做數據檢索的時候負載將會集中 在個別 RegionServer，降低查詢效率。
小結：高位->散列 無序 低位-> 時間戳方式
數據熱點 //上面叫數據熱點問題
　　HBase 中的行是按照 rowkey 的字典順序排序的，這種設計優化了 scan 操作，可以將相 關的行以及會被一起讀取的行存取在臨近位置，便於 scan。然而糟糕的 rowkey 設計是熱點 的源頭。 熱點發生在大量的 client 直接訪問集群的一個或極少數個節點（訪問可能是讀， 寫或者其他操作）。大量訪問會使熱點 region 所在的單個機器超出自身承受能力，引起性能 下降甚至 region 不可用，這也會影響同一個 RegionServer 上的其他 region，由於主機無法服 務其他 region 的請求。 設計良好的數據訪問模式以使集群被充分，均衡的利用。 為了避免寫熱點，設計 rowkey 使得不同行在同一個 region，但是在更多數據情況下，數據 應該被寫入集群的多個 region，而不是一個。

防止數據熱點的有效措施
1、加鹽
　　這裏所說的加鹽不是密碼學中的加鹽，而是在 rowkey 的前面增加隨機數，具體就是給 rowkey 分配一個隨機前綴以使得它和之前的 rowkey 的開頭不同。分配的前綴種類數量應該 和你想使用數據分散到不同的 region 的數量一致。加鹽之後的 rowkey 就會根據隨機生成的 前綴分散到各個 region 上，以避免熱點。
小結：在設計表的時候，就分好4個region 那麽在rk前面就增加4個種類不同的隨機數。
2、哈希 //哈希加鹽法
　　哈希會使同一行永遠用一個前綴加鹽。哈希也可以使負載分散到整個集群，但是讀卻是 可以預測的。使用確定的哈希可以讓客戶端重構完整的 rowkey，可以使用 get 操作準確獲取 某一個行數據
小結：哈利加鹽法就是，在rk前面使用一個固定的前綴。有幾個region就指定幾個固定的前綴，那麽寫和讀就很方便了，充分的利用get。獲取某一行數據。 我更傾向使用哈希加鹽法
3、反轉
　　第三種防止熱點的方法是反轉固定長度或者數字格式的 rowkey。這樣可以使得 rowkey 中經常改變的部分（最沒有意義的部分）放在前面。這樣可以有效的隨機 rowkey，但是犧 牲了 rowkey 的有序性。
　　反轉 rowkey 的例子以手機號為 rowkey，可以將手機號反轉後的字符串作為 rowkey，這 樣的就避免了以手機號那樣比較固定開頭導致熱點問題
小結：比如 15295001286 翻轉出來就是65210059251 //我們公司就是做手機的，hbase表中用的這種方式避免熱點問題
4、時間戳反轉
　　一個常見的數據處理問題是快速獲取數據的最近版本，使用反轉的時間戳作為 rowkey 的一部分對這個問題十分有用，可以用 Long.Max_Value - timestamp 追加到 key 的末尾，例 如 [key][reverse_timestamp] , [key] 的最新值可以通過 scan [key]獲得[key]的第一條記錄，因 為 HBase 中 rowkey 是有序的，第一條記錄是最後錄入的數據。比如需要保存一個用戶的操 作記錄，按照操作時間倒序排序，在設計 rowkey 的時候，可以這樣設計 [userId 反轉][Long.Max_Value - timestamp]，在查詢用戶的所有操作記錄數據的時候，直接指 定 反 轉 後 的 userId ， startRow 是 [userId 反 轉 ][000000000000],stopRow 是 [userId 反 轉][Long.Max_Value - timestamp]
　　如果需要查詢某段時間的操作記錄，startRow 是[user 反轉][Long.Max_Value - 起始時間]， stopRow 是[userId 反轉][Long.Max_Value - 結束時間]

hbase表設計優化原則 ***** 生產環境中使用小結