table key-value 功能 建表 額外 version 前綴 size 必須

1、compression 　　默認值是 NONE 即不使用壓縮， 這個參數意思是該列族是否采用壓縮，采用什麽壓縮算 法 　　方法: create ‘table‘,{NAME=>‘info‘,COMPRESSION=>‘SNAPPY‘} 建議采用 SNAPPY 壓縮算法 ， HBase 中，在 Snappy 發布之前（ Google 2011 年對外發布 Snappy），采用的 LZO 算法，目標是達到盡可能快的壓縮和解壓速度，同時減少對 CPU 的消耗； HBase修改壓縮格式，需要一個列族一個列族的修改 alter ‘test‘, NAME => ‘f‘, COMPRESSION => ‘snappy‘

。 而且這個地方要小心，別將列族名字寫錯，或者大小寫錯誤。因為這個地方任何錯誤，都會創建一個新的列族，且壓縮格式為snappy（修改之前需要先disable，修改完之後需要enable，然後 major_compact ‘test‘） 2、TTL (time to live) 設置方法和versions類似 3、disable_all enable_all drop_all：支持正則表達式，並列出當前匹配的表，之後給出確認提示。 4、Hbase 預分區 　　HBase表在剛剛被創建時，只有1個分區（region），當一個region過大（達到hbase.hregion.max.filesize屬性中定義的閾值，默認10GB）時，表將會進行split，分裂為2個分區。表在進行split的時候，會耗費大量的資源，頻繁的分區對HBase的性能有巨大的影響。HBase提供了預分區功能，即用戶可以在創建表的時候對表按照一定的規則分區。分區是針對表級，不是列族級，因為region是根據rowkey來劃分的。 　　目的：減少由於region split帶來的資源消耗。從而提高HBase的性能。 方案1：Hbase shell 創建，16010端口可以查看具體region 　　 方案2：Hbase shell ，通過文件來創建 　　 5、表的設計 　　列簇設計： 　　原則：在合理範圍內能盡量少的減少列簇就盡量減少列簇，因為列簇是共享region的，每個列簇數據相差太大導致查詢效率低下 　　最優：將所有相關性很強的 key-value 都放在同一個列簇下，這樣既能做到查詢效率 最高，也能保持盡可能少的訪問不同的磁盤文件。以用戶信息為例，可以將必須的基本信息存放在一個列族，而一些附加的額外信息可以放在 另一列族 　　rowkey設計： 　　　　長度原則：100字節以內，8的倍數最好，可能的情況下越短越好。因為HFile是按照keyvalue存儲的，過長的rowkey會影響存儲效率；其次，過長的rowkey在memstore中較大，影響緩沖效果，降低檢索效率。最後，操作系統大多為64位，8的倍數，充分利用操作系統的最佳性能。 　　　　散列原則：高位散列，低位時間字段。避免熱點問題 　　　　唯一原則：分利用這個排序的特點，將經常讀取的數據存儲到一塊，將最近可能會被訪問 的數據放到一塊。 6、數據熱點問題 　　措施一：加鹽 　　　　隨機前綴，高位散列，講數據隨機分散到region上 　　措施二：哈希 　　　　哈希前綴，負債均衡，並且可以利用哈希重構rowkey，使用get獲取準確數據 　　措施三：反轉 　　　　反轉固定長度或者數字格式的rowkey，犧牲了有序性，避免類似手機號固定開頭的熱點問題 　　措施四：時間戳反轉

Hbase 表設計和高級屬性