首先分析一下IO性能。HBase写入有memstore作为缓存，写入时可以忽略LSMT的处理，如果开启WAL，写入操作效率近似于hdfs性能。顺序读取的话，有block catch，它每次加载一个Store file的block，因此这个策略对于顺序读取具有独特的优势，测试的时候单机能有几万的QPS。但是这个策略是随机读取的噩梦，因为当读取足够随机的话，一方面缓存内容会被频繁置换，无法达到缓存的目的，并频繁引发GC；另一方面，缓存读取过程是读取整个block，然后从block中选出记录，从这一层次来看，每次get实际上并非单纯的key value查找，而是相当于多次二分查找。基于以上两方面，增大内存无法解决根本问题，而用SSD作为二级缓存的话，会浪费较多的io，测试时单机QPS最高25000左右(与之前的测试基于相同的数据特征)。一般的做法是在前端加入memcache这样的纯key value缓存。

         综上，我们分析一下HBase的应用场景。

         首先从数据特征来看适合存储于的数据类型：HBase适合结构化(单纯的、海量的key value)或半结构化的(基于key索引的图片、音乐、二进制文件等)非关系型的数据。举例来说，网页搜索相关数据、软件下载站、各种快照信息、非关系型业务二维表等。

         然后，从IO来看适合做什么样的处理：HBase适合大规模写入(注意适时禁用auto split)、扫库的业务，对于随机读取，需要特殊处理。举例来说在线业务适合分页的、单表的、无基于列族做排序和分组处理的查询和展现，少量随机查询和展现；离线业务适合更灵活的统计分析处理和报表导出等。

         对于不同的业务数据，有几个参数需要针对不同情况进行调整：maxfilesize、blocksize、memstore大小。