hbase表的設計原則

2021-09-26 07:18:48 字數 1097 閱讀 7147

1、列族的數量及列族的勢

建議將hbase列族的數量設定的越少越好.對於兩個或兩個以上的列族hbase並不能處理的很好。這是因為hbase的flushing和壓縮是基於region的。當乙個列族所儲存的資料達到flushing的閾值時,該表中所有列族將同時進行flushing操作。這將帶來不必要的i/o開銷,列族越多,該特性帶來的影響越大。

此外,還要考慮到同乙個表中不同列族所儲存的記錄數量的差別,即列族的勢(cardinality)。當兩個列族數量差別過大時會使包含記錄數量較少列族的資料分散在多個region上,而region有可能儲存在不同的regionserver上。這樣,當進行查詢或scan操作的時候,系統效率將會受到影響。

在多列簇的情況下,注意各列簇資料的數量級要一致。如果兩個列簇的數量級相差太大,會使數量級少的列簇的資料掃瞄效率低下。

將經常查詢和不經常查詢的資料放到不同的列簇。

2、行鍵(rowkey)的設計

首先應該避免使用時序或單調(遞減/遞增)行鍵。因為當資料到來的時候,hbase首先需要根據記錄的行鍵來確定儲存的位置,即region的位置,如果使用時序或單調行鍵,那麼連續到來的資料將被分配到同乙個region中,而此時系統的其他region/regionserver處於空閒狀態,這是分布式最不希望看到的狀態。

如果rowkey是整型,用二進位制的方式比用string來儲存更節約空間

合理的控制rowkey的長度,盡可能短,因為rowkey的資料也會存在每個cell中。

如果需要將表預**為多個region是,最好自定義**的規則。

3、盡量最小化行鍵和列族的大小

在hbase中,乙個具體的值由儲存該值的行鍵、對應的列(列族:列)以及該值的時間戳決定。hbase中索引是為了加速隨即訪問的速度,索引的建立是基於「行鍵+列族:列+時間戳+值」的,如果行鍵和列族的大小過大,甚至超過值本身的大小,納悶將會增加索引的大小。並且在hbase中資料記錄往往非常之多,重複的行鍵、列將不但使索引的大小過大,也將加重系統的負擔

4、版本的數量

預設情況下為3個,可以通過hcolumndescriptor進行設定,建議不要設定的過大

HBase表rowKey設計原則

rowkey設計首先應當遵循三大原則 rowkey是乙個二進位製碼流,可以為任意字串,最大長度為64kb,實際應用中一般為10 100bytes,它以byte形式儲存,一般設定成定長。一般越短越好,不要超過16個位元組,注意原因如下 1 目前作業系統都是64位系統,記憶體8位元組對齊,控制在16位元...

HBase的RowKey設計原則

hbase是三維有序儲存的,通過rowkey 行鍵 column key column family和qualifier 和timestamp 時間戳 這個三個維度可以對hbase中的資料進行快速定位。hbase中rowkey可以唯一標識一行記錄,在hbase查詢的時候,有以下幾種方式 通過get方...

HBase的RowKey設計原則

hbase是三維有序儲存的,通過rowkey 行鍵 column key column family和qualifier 和timestamp 時間戳 這個三個維度可以對hbase中的資料進行快速定位。hbase中rowkey可以唯一標識一行記錄,在hbase查詢的時候,有以下幾種方式 通過get方...