HBase 的 Schema 设计

1.  Schema 创建
可以使用HBaseAdmin或者Chapter 4, The HBase Shell 来创建和编辑Hbase的schemas
2.  column families的数量
现在Hbase并不能很好的处理两个或者三个以上的column families，所以尽量让你的column families数量少一些。目前，flush和compaction操作是针对一个Region。所以当一个column family操作大量数据的时候会引发一个flush。那些不相关的column families也有进行flush操作，尽管他们没有操作多少数据。Compaction操作现在是根据一个column family下的全部文件的数量触发的，而不是根据文件大小触发的。当很多的column families在flush和compaction时,会造成很多没用的I/O负载(要想解决这个问题，需要将flush和compaction操作只针对一个column family)
尽量在你的应用中使用一个Column family。只有你的所有查询操作只访问一个column family的时候，可以引入第二个和第三个column family.例如，你有两个column family,但你查询的时候总是访问其中的一个，从来不会两个一起访问。
3.  单调递增Row Keys/时序数据(log)
在TomWhite的Hadoop: The Definitive Guide一书中，有一个章节描述了一个值得注意的问题：在一个集群中，一个导入数据的进程一动不动，所以的client都在等待一个region(就是一个节点)，过了一会后，变成了下一个region...如果使用了单调递增或者时序的key就会造成这样的问题。详情可以参见IKai画的漫画monotonically increasing values are bad。使用了顺序的key会将本没有顺序的数据变得有顺序，把负载压在一台机器上。所以要尽量避免时间戳或者(e.g.1, 2, 3)这样的key。
如果你需要导入时间顺序的文件(如log)到Hbase中，可以学习OpenTSDB的做法。他有一个页面来描述他的schema.OpenTSDB的Key的格式是[metric_type][event_timestamp]，乍一看，似乎违背了不将timestamp做key的建议，但是他并没有将timestamp作为key的一个关键位置，有成百上千的metric_type就足够将压力分散到各个region了。
4. 尽量最小化row和column的大小
在Hbase中，值是作为一个cell保存在系统的中的，要定位一个cell,需要row,column name和timestamp.通常情况下，如果你的row和column的名字要是太大(甚至比value的大小还要大)的话，你可能会遇到一些有趣的情况。例如Marc Limotte 在 HBASE-3551(recommended!)尾部提到的现象。在Hbase的存储文件Section 12.3.4.2, “StoreFile(HFile)”中，有一个索引用来方便value的随机访问，但是访问一个cell的坐标要是太大的话，会占用很大的内存，这个索引会被用尽。所以要想解决，可以设置一个更大的block size，当然也可以使用更小的column name `
5.  版本的时间
行的版本的数量是HColumnDescriptor设置的，每个column family可以单独设置，默认是3.这个设置是很重要的，在Chapter 11, 数据模型有描述，因为Hbase是不会去覆盖一个值的，他只会在后面在追加写，用timestamp来区分、过早的版本会在执行major compaction的时候删除。这个版本的值可以根据具体的应用增加减少。