本文共 1215 字，大约阅读时间需要 4 分钟。
最近项目中用到了hbase，使用的原因在于HBase可以提供高并发读写操作的支持，同时自动切分数据，使得数据存储具有水平扩展性。
1 不能支持条件查询，只支持按照Row key来查询.
2 暂时不能支持Master server的故障切换,当Master宕机后,整个存储系统就会挂掉.
1.数据类型，Hbase只有简单的字符类型，所有的类型都是交由用户自己处理，它只保存字符串。而关系数据库有丰富的类型和存储方式。在使用过程中，创建表的时候只感知到了创建列簇，指定过期时间等等，没有感知到指定数据类型等操作。
2.数据操作：HBase只有很简单的插入、查询、删除、清空等操作，表和表之间是分离的，没有复杂的表和表之间的关系。 3.存储模式：HBase是基于列存储的，每个列族都由几个文件保存，不同的列族的文件时分离的。而传统的关系型数据库是基于表格结构和行模式保存的。 4.数据维护，HBase的更新操作不应该叫更新，它实际上是插入了新的数据，而传统数据库是替换修改 。这里理解是一个rowkey实际对应多份数据，按照插入数据的时间倒序，查询时返回最后插入的一份数据。split负载均衡。hbase会将数据split到一定数量的region中来实现负载均衡。一个table会被分到一个或者多个region中。这些region会被分配到一个或者多个regionServer中。在自动split策略中，每个region达到一定大小就会被自动split。split根据rowkey，同一个rowkey对应的行只会在一个region中。
如果没有presplit，table刚刚创建的时候，所有的读写操作都会访问到同一个regionServer的同一个region中。无法达到负载均衡的目的。同时，好像region自动split也是需要更多的性能和时间的（待确认，需要详细看下split的过程）。通过预测rowkey，确定需要pre-split的节点。
目前读写操作都需要通过rowkey，rowkey也决定了split的节点。
rowkey是一个二进制码流，可以是任意字符串，最大长度64kb，实际应用中一般为10-100bytes，以byte[]形式保存，一般设计成定长。建议越短越好，不要超过16个字节，原因如下：
数据的持久化文件HFile中是按照KeyValue存储的，如果rowkey过长，比如超过100字节，1000w行数据，光rowkey就要占用100*1000w=10亿个字节，将近1G数据，这样会极大影响HFile的存储效率；
MemStore将缓存部分数据到内存，如果rowkey字段过长，内存的有效利用率就会降低，系统不能缓存更多的数据，这样会降低检索效率。目前操作系统都是64位系统，内存8字节对齐，控制在16个字节，8字节的整数倍利用了操作系统的最佳特性。
转载地址：http://goyai.baihongyu.com/