1.行鍵應該盡可能短
行鍵存在於hbase中的每乙個單元格中。如果行鍵越長，用於儲存單元格的i/o開銷就會越大。通常我們採用md5加密的定長鍵來代替行鍵
2.對於組合行鍵 排序順序應該取決於訪問模式
如果是乙個以主機名和事件型別儲存的日誌資料庫，可能的鍵值選取方法有以下幾種：
1.單調遞增的行鍵/時序資料
在乙個集群中，乙個匯入資料的程序一動不動，所有的client都在等待乙個region(就是乙個節點)，過了一會後，變成了下乙個region…如果使用了單調遞增或者時序的key就會造成這樣的問題。使用了順序的key會將本沒有順序的資料變得有順序，把負載壓在一台機器上。所以要盡量避免時間戳或者(e.g. 1, 2, 3)這樣的key。
2.盡量最小化行名和列名的字段大小
在hbase中，值是作為乙個單元(cell)儲存在系統的中的，要定位乙個單元，需要行，列名和時間戳。通常情況下，如果你的行和列的名字要是太大(甚至比value的大小還要大)的話，你可能會遇到一些有趣的情況。在hbase的儲存檔案中，有乙個索引用來方便值的隨機訪問，但是訪問乙個單元的座標要是太大的話，會占用很大的記憶體，這個索引會被用盡。所以要想解決，可以設定乙個更大的塊大小，當然也可以使用更小的列名。壓縮也能得到更大指數。大部分時候，小的低效不會影響很大。不幸的是，這裡會是個問題。無論是列族，屬性和行鍵都會在資料中重複上億次。所以我們設計habse時候盡量遵循以下幾點：
盡量使列族名小，最好乙個字元
屬性名盡量精簡
行鍵短到可讀即可
3.倒序時間戳
乙個資料庫處理的通常問題是找到最近版本的值。採用倒序時間戳作為鍵的一部分可以對此特定情況有很大幫助。也在tom white的hadoop書籍的hbase 章節能找到: the definitive guide (o』reilly), 該技術包含追加(long.max_value - timestamp) 到key的後面，如 [key][reverse_timestamp].表內[key]的最近的值可以用[key]進行 scan 找到並獲取第乙個記錄。由於 hbase 行鍵是排序的，該鍵排在任何比它老的行鍵的前面，所以必然是第乙個。
4.行鍵永遠不變
行鍵不能改變。唯一可以「改變」的方式是刪除然後再插入。這是乙個網上常問問題，所以要注意開始就要讓行鍵正確
HBase行鍵設計
唯一原則 行鍵對應關係型資料庫的唯一鍵，系統設計之初必須考慮有足夠的唯一行鍵去支援業務的資料量。長度原則 長度適中，一般從幾十到一百位元組，建議使用定長，方便從行鍵提取所需資料，而無須查詢出資料內容以節省網路開銷。雜湊原則 避免遞增，否則讀寫負載都會集中在某個熱點分割槽，降低效能，甚至引起分割槽伺服...
hbase動態更改行鍵設計 HBase 行鍵設計
hbase 有兩種基本的鍵結構 行鍵 row key 和列鍵 column key 兩者都可以儲存有意義的資訊，一種是鍵本身儲存的內容，另一種是鍵的排列順序。概念hbase 的表中資料分隔主要是使用列族 column family 而不是列，並非列式儲存，如下圖，表示了使用者邏輯上把乙個單元格的資料...
hbase 順序序列rowkey設計
import org.apache.hadoop.hbase.util.bytes import org.apache.hadoop.hbase.util.md5hash public class sequenceidrowkeyhash 暫時想到這種設計方法，可以避免寫入熱點問題，也可以進行預分割...