一、主體思路
先確定查詢場景，再確定表結構。
二、主鍵設計
主鍵設計需要考慮兩個問題：1.選擇哪些作為主鍵？2.當主鍵大於1個時，如何排列。
2.1 邏輯上用於表示行的唯一性的列必須作為主鍵
2.2 單個查詢場景中一定出現的列可以考慮加入主鍵列，用於優化查詢效能
2.3 在多個查詢場景都出現的主鍵列要排在前面。
如果出現兩個列各佔部分場景，怎麼排列都會使一部分場景無法達到效能要求，這時候我們要考慮二級索引
三、普通列設計
在保持語義情況下盡量使用盡量使用更短的名字，節省空間
phoenix支援列族的概念，乙個列由列祖名+列名唯一指定。
四、熱點問題
分為讀熱點和寫熱點。
檢索hbase中的資料首先通過rowkey來定位資料行，當大量的client訪問hbase乙個或少數幾個節點，造成少數region server的讀/寫請求負載過大，其他region負載很小，這就造成了熱點現象。熱點現象會導致熱點region所在單個主機上負載過大，引起region效能下降甚至不可用。
熱點產生原因是因為大量連續編號的（大量相似的）rowkey的記錄集中在個別的region中，解決此問題思想在於：盡量均衡的把每條記錄均衡的分散到不同的region中。有很多方法可以達到這個目的，例如在行鍵前新增乙個不連續的字首。
4.1 隨機化
如果查詢都是get型別，即只查詢乙個物件，可以對主鍵進行hash，將hash作為第乙個主鍵列，常用的hash方式是：md5,反轉。
byterowkey = md5（timestamp）
採用md5之類的雜湊函式能將行鍵分散到所有region伺服器上。對於時間連續的資料，這種方法明顯不是好方法，因為隨機化後，使用者將不能再按時間範圍掃瞄資料。隨機化的方法很適合每次唯讀一行資料應用。如果使用者資料不需要連續掃瞄而只需要隨機讀取，使用者可以使用這種策略。
4.2 salting方式
使用者可以使用salting方法將資料雜湊到所有的region伺服器上去。
byteprefix = (byte)(long.hashcode(timestamp) % < number of region servers >)
byterowkey = bytes.add(bytes.tobyte(prefix),bytes.tobytes(timestamp))
這樣做的缺點是當使用者要掃瞄乙個連續範圍時，可能需要對每個region伺服器都發起請求(因為之前連續的資料，現在已經分散到不同的伺服器中)。這樣也會帶來好處，使用者可以並行的讀取資料，這有點類似於乙個小規模的mapreduce作業，這樣查詢的吞吐量有所提高。
HBase表結構設計
列簇設計 版本設計 資料壓縮 rowkey設計原則 在hbase有很多張表，這些表需要按照業務劃分開，為方便管理這些表，不同業務就有不同的命名空間，類似hive中的資料庫，不同的資料庫用來儲存不同型別的表。注 建立命名空間 create namespace momo chat 檢視命名空間列表 li...
結構設計 資料表設計 常用表結構設計
為了建立冗餘較小 結構合理的資料庫，設計資料庫時必須遵循一定的規則。在關係型資料庫中這種規則就稱為正規化。位址一般包括 省 市 縣 區 詳細位址 我們當然可以儲存乙個字段 使用分隔符 json 等儲存 介紹字段介紹 字段介紹 idbigint id parentid parentidlist chi...
RBAC 的表結構設計
一套能體現 rbac 的表結構設計 1 rbac 概述 2 表結構設計 2.1 使用者表 2.2 角色表 2.3 許可權表 2.4 使用者角色 關係 表 2.5 角色許可權 關係 表 3 總結1 rbac 概述 rbac role based access control 即基於角色的訪問控制，是一...