缘起
随着hadoop系列的兴起，基于HDFS的大规模KV存储系统HBase也进入“大规模使用阶段”。网上的Hbase资料很多，学习成本正在下降。从公开的资料看，国外facebook、国内taobao均宣称在线上环境大规模使用hbase。一切都让人很兴奋。于是，在项目中引入Hbase做存储，最终却选择放弃。
HBase设计：看上去很美
HBase是模仿google bigtable的开源产品，又是hadoop的衍生品，hadoop作为离线计算系统已经得到业界的普遍认可，并经过N多公司大规模使用的验证，自然地认为Hbase也将随之获得成功。
《HBase: The Definitive Guide》第8章讲述hbase的架构，从架构上看，其架构很完美：
LSM - 解决磁盘随机写问题(顺序写才是王道)；
HFile - 解决数据索引问题(只有索引才能高效读)；
WAL - 解决数据持久化(面对故障的持久化解决方案)；
zooKeeper - 解决核心数据的一致性和集群恢复；
Replication - 引入类似MySQL的数据复制方案，解决可用性；
此外还有：自动分拆Split、自动压缩(compaction,LSM的伴生技术)、自动负载均衡、自动region迁移。
看上去如此美好，完全无需人工干预，貌似只要将Hbase搭建好，一切问题Hbase都将应对自如。面对如此完美的系统，不动心很难。
但是，如此完美的系统或许也意味着背后的复杂性是不容忽略的。hbase的代码量也不是一星半点的。假如系统工作不正常，谁来解决？这是至关重要的。
性能与测试
Hbase系统自身提供了性能测试工具：./bin/hbase org.apache.hadoop.hbase.PerformanceEvaluation，该工具提供了随机读写、多客户端读写等性能测试功能。根据工具测试的结果看，hbase的性能不算差。
对于hbase这样的系统长期稳定运行比什么都重要。然而，这或许就不那么"完美"。
测试版本：hbase 0.94.1、 hadoop 1.0.2、 jdk-6u32-linux-x64.bin、snappy-1.0.5.tar.gz
测试hbase搭建：14台存储机器+2台master、DataNode和regionserver放在一起。
hbase env配置：
View Code
hbase-size.xml关键配置(根据《HBase: The Definitive Guide》第11章优化)：
View Code
测试一：高并发读(4w+/s) + 少量写(允许分拆、负载均衡)
症状：1-2天后，hbase挂掉(系统性能极差，不到正常的10%)。其实并非全部挂掉，而是某些regionserver挂了，并在几个小时内引发其他regionserver挂掉。系统无法恢复：单独启regionserver无法恢复正常。重启后正常。
测试二：高并发读(4w+/s)
症状：1-2天后，hbase挂掉(系统性能极差，不到正常的10%)。后发现是由于zookeeper.session.timeout设置不正确导致(参见regionserver部分：http://hbase.apache.org/book.html#trouble)。重启后正常。
测试三：高并发读(4w+/s)
症状：1-2天后，hbase挂掉(系统性能极差，不到正常的10%)。从log未看出问题，但regionserver宕机，且datanode也宕机。重启后正常。
测试四：高并发读(4w+/s)+禁止分拆、禁止majorcompaction、禁止负载均衡(balance_switch命令)
症状：1-2天后，hbase挂掉(系统性能极差，不到正常的10%)。从log未看出问题，但regionserver宕机，且datanode也宕机。重启后正常。
测试期间，还发现过：无法获取".MATE."表的内容(想知道regionserver的分布情况)、hbase无法正确停止、hbase无法正确启动(日志恢复失败，文件错误，最终手动删除日志重启)。
其他缺陷
HBase使用JAVA开发，看上去很美的GC使用中代价可不小。Hbase为了保证数据强一致性，每个key只能由一个regionserver提供服务。在下列情况下，Hbase服务质量都将受损：
1) GC CMS -- CMS回收内存极其耗时，当hbase运行1-2天后，CMS可能耗时10分钟，这期间该regionserver无法服务。CMS经常被触发，这意味着hbase的服务经常会因为GC操作而部分暂停！
2) regionserver宕机 - 为了强一致性，每个key只由一个regionserver提供服务，故当regionserver宕机后，相应的region即无法服务！
3) major compaction、split不可控 - 大量磁盘操作将极大影响服务。(levelDB也需要major compaction，只是使用更加可控的方式做压缩，比如一次只有一个压缩任务。是否影响服务，待测试)
4) 数据恢复 - 数据恢复期间设置WAL log的相关操作，在数据恢复期间regionserver无法服务！
结论
或许通过研究hbase的源码可让hbase稳定运行，但从上述测试结果看：1）hbase还无法稳定长期运行；2）hbase系统很脆弱，故障恢复能力差。基于此，判断hbase还无法满足大规模线上系统的运维标准，只能放弃。考虑到hbase重启基本可恢复正常，故hbase还是可作为离线存储系统使用。
注：Hbase最初设计目标就是为了大规模在线存储。0.94.1版本的Hbase在高并发压力下测试并不稳定，但这不表示Hbase不能用于在线存储。放弃Hbase自有自己的判断逻辑，是否采用读者自己权衡。(见后面评论。2012.11.14)
替代方案
面对大规模数据，基于磁盘的存储系统是必不可少的。google虽然公开了bigtable的设计，但未开源，但google开源了levelDB KV存储系统库(http://code.google.com/p/leveldb/)。levelDB采用C++实现，1.7版本的代码量大概2W，实现了LSM(自动压缩)、LevelFile(基本同HFile)，WAL，提供了简单的Put、Get、Delete、Write(批量写、事务功能)等接口。levelDB库实现了单机单库的磁盘存储方案，开发者可根据自己需要开发定制的存储系统(比如：数据Replication、自动调度、自动恢复、负载均衡等)。
本文转自 zhenjing 博客园博客，原文链接： http://www.cnblogs.com/zhenjing/archive/2012/11/13/hbase_is_OK.html ，如需转载请自行联系原作者
