rowkey及建表方式設計(舊)
場景
單次查詢條件
查詢
方式
rowkey設計
建表
存在的問題
指標牆時間、地域、指標都固定
get指標 + 時間 + 子region
三種場景乙個表
第一種場景沒問題
指標分析
地域、指標固定、時間範圍查詢
scan+過濾器
scan後有大量的資料需要過濾(多達數十萬以上的資料)，直接影響查詢效率
報表時間、指標固定、指定父地域查詢父子地域的指標
scan+過濾器
rowkey及建表方式設計(新)
場景
單次查詢條件
查詢
方式
rowkey設計
rowkey字首設計
建表
設計理由
指標牆時間、地域、指標都固定
get指標-地域-時間
地域+指標一起做hash
兩個場景用乙個表
rowkey是固定的用get能夠快速返回
指標分析
地域、指標固定、時間範圍查詢
scan
地域、指標固定後，最大的時間範圍就是365天，scan的資料很小，能快速返回
報表時間、指標固定、指定父地域查詢父子地域的指標
scan
指標-時間-父地域-子地域
時間+指標一起做hash
單獨乙個表
1、時間、指標、父地域三者固定，scan來查子地域掃瞄的範圍就少多了
(父地域下的子地域最多有幾千個)
2、時間、指標、父地域三者固定，可以從前兩個場景對應的表裡用get快速
查出父地域的資料
HBase表rowKey設計原則
rowkey設計首先應當遵循三大原則 rowkey是乙個二進位製碼流，可以為任意字串，最大長度為64kb，實際應用中一般為10 100bytes，它以byte形式儲存，一般設定成定長。一般越短越好，不要超過16個位元組，注意原因如下 1 目前作業系統都是64位系統，記憶體8位元組對齊，控制在16位元...
Hbase中rowkey設計原則
1.rowkey長度原則 rowkey不宜過長 建議不要超過16個位元組 若rowkey長度過長，memorystore會將部分快取資料存入記憶體降低記憶體利用率，降低檢索效率，hfile進行資料持久化時也會極大影響儲存效率 2.rowkey雜湊原則 設計目標 將資料均勻的分布在每個regionse...
Hbase中rowkey設計原則
1.熱點問題 在某一時間段，有大量的資料同時對乙個region進行操作 2.原因 對rowkey的設計不合理 對rowkey的劃分不合理 3.解決方式 rowkey是hbase的讀寫唯一標識 最大長度是64kb。4.核心原則 設計必須按照業務需求進行設計 5.長度原則 經驗 10 100位元組可以 ...