HBase and Schema Design
從官網翻譯的，怎麼設計hbase表
32 Schema Creation
hbase的schema使用hbase的shell命令和使用JavaAPI的Admin類來創建和更新。在做列簇的修改的時候，必須要是表失效（disabled），最新的貌似不用了。
java的列子，增加一個新列簇，修改一個列簇
Configuration config = HBaseConfiguration.create();
Admin admin = new Admin(conf);
TableName table = TableName.valueOf("myTable");
admin.disableTable(table);
HColumnDescriptor cf1 = ...;
admin.addColumn(table, cf1); // adding new ColumnFamily
HColumnDescriptor cf2 = ...;
admin.modifyColumn(table, cf2); // modifying existing ColumnFamily
admin.enableTable(table);ps:
1在0.92.x版本中支持在線修改schme，但是在0.90.以下版本需要使hbase得表disabled時候在修改。
33 On the number of column families
Hbase現在在列簇個數大於2,3之上的應用支持的不是很好，所以要讓你在應用中的schema保持的2,3三個列簇之下。當前，如果一個列簇中包含了大部分數據，在每一個region中，flushing（內存緩衝區要滿了寫到磁盤）和compactions（數據壓縮)就會執行，而且臨近的列簇也會flushed，儘管這個列簇攜帶的數據量很少。當許多列簇存在flushing和compaction交互的時候會產生大量的不不要的io操作（但是可以對每個列簇設置flushing和compaction，詳細情況看http://hbase.apache.org/book.html#compaction以後再看）。
儘可能的保證在你的schema中只有一個列簇。當引入了2,3個列簇之後，數據接入成了列掃描，這意味着當你查詢一個列簇的時候，另外一個列簇不能同時查詢。
關於列簇的基數，就是每個列簇有多少條記錄數。當一個表中存在許多列簇的時候，要明白列簇的基數的影響。如果列簇A擁有1百億條記錄，列簇B擁有10億條几率，那麼列簇A的數據就會被分散到許多，許多的region（還有regionservers）中。這就會導致列簇A的掃描查詢會沒有效率（慢）。
34 Rowkey Design
34.1 Hotsportting
在Hbase中，行是根據主鍵的字典順序排序。這個設計對於掃描有優勢，這樣就允許你把相關的行存儲在一起，或者是把一起讀的數據存在一起，或者兩者都行。然後糟糕的行健設置會導致一個常見的現象，數據過熱。數據過熱有以下常見，1絕大部分的客戶端流量和一個節點交互（數據都放在一個節點裏面了），2對於集羣環境，數據集中在少數幾個節點中。客戶端流量有讀數據，寫數據或者其他操作。這種流量頻繁訪問單個節點的，甚至單個region，導致了執行力的下降（其他region空閒吧），潛在的導致了其他分區的不可使用性。這是分佈式嘛，你數據都在同一個機器上，這叫什麼事嘛。 數據過熱也會導致相同regionserver中的其他region有不利的影響，導致無法處理請求。設計數據接入模式，使集羣完全和均勻的被利用是很重要的。
爲了阻止關於寫操作的數據過熱，設置好主鍵
