反方 
Jonathan Ellis
HBase 受到太多缺点的困扰
联合创始人 & CTO, DataStax NoSQL包括了几个特性，比如图形数据库和文档存储，这些都是HBase不具备的，而且即使在它所属的分区行存储这一类型中，HBase也落后于领跑者。技术上的缺陷可以把HBase的失败使用案例分为两个主要类型: 一是工程问题，如果时间和人力充足，该问题可以处理，二是架构上的缺陷，这是设计层面固有的问题所以无法修复。 工程问题
--操作复杂，且容易发生故障。HBase的部署需要配置的文件包括：最小Zookeeper集群，一级HMaster,二级 HMaster,RegionServers，活动NameNode，备用NameNode，HDFS管理，还有DataNodes。尽管HBase可以 被自动安装，但是要是没有帮助就想成功安装太难了，比如说RegionServers出现故障或者一个低级别NameNode出现故障了怎么 办？HBase使用需要足够多的专业知识甚至需要知道要监视什么。只用上帝才能帮助你进行定期备份吧。
--RegionServer故障转移需要花费10到15分钟的时间，HBase将分区形成区域，每个区域由RegionServer来进行管理。
RegionServer对于其管理的区域来说只允许单次故障。当它发生故障时，就必须选择一个新的区域服务器，而且在新服务器工作之前还得必须重新写入
之前服务器的日志。 -- 用HBase进行开发很痛苦。HBase的 API很笨拙而且是以Java为中心的。非Java客户端被降级到第二级别的Thrift或REST入口。与此相对的是Cassandra 查询语言，它提供给开发者一个在所有语言中都熟悉的、富有成效开发体验。 -- HBase社区是一盘散沙。Apache的主线不稳定是广为人知的。Cloudera, Hortonworks,和高级用户们都在顶层维护着他们自己的补丁树。领导权被拆分开了而且没有清晰的发展路线图。相反的，开源的Cassandra社区的贡献者来自包括DataStax、Netflix、Spotify、Blue Mountain Capital和其他组织，并且没有派系或分支。
总体上，自从我关注NoSQL生态圈以来，HBase和其它NoSQL平台在工程上的差距已经变大了。在我第一次评估他们的时候，我就已经认定HBase在工程进度上落后于Cassandra6个月，但是今天这种落后已经扩大到2年左右。 架构上的缺陷
--面向Master的设计使得HBase的操作很不灵活。通过RegionServer master来路由所有的读和写意味着HBase不可能在多个数据中心之间进行主动/主动结构的异步复制，还意味着你不能把工作负载分给一个集群上的各个 复制者。相比之下，Cassandra的P2P复制允许在没有ETL的情况下无缝地集成Hadoop,Solar和Cassandra，而且在你需要极少 出现的线性一致性的情况下还允许你进行 轻量级事务处理。
--故障转移意味着停机。许多应用无法接受甚至一分钟的停机时间，然而这是HBase设计固有的问题；每一个RegionServer都是一个单节点故
障。而完全分布式设计意味着一个复制者停机，不需要任何特殊的动作就可以恢复；系统仍然与其他复制者一起正常的运转，而且在以后可以把停机的复制者纳入进来。 --
HDFS是主要为了以流的形式访问大文件而设计的。HBase建立在为批量分析而优化的分布式文件系统之上。这是HBase
低性能的直接原因，尤其对于读取，而且
在固态硬盘上读取更是如此。就像关系型数据库不能优化30年前为准大数据工作负载而设计的B树引擎一样，HDFS也不能在主要目的和缩小关键功能上的差距之间不做权衡： --在一个集群里混合一般硬盘和固态硬盘，并把表固定在适合工作负载的介质上。
让HBase的基础HDFS更适合于批量分析那样的设计将确保HBase仍天然地不适合于高速、随机访问的工作负载，而这些正是NoSQL市场所独有的。 Jonathan Ellis是DataStax的CTO和联合创始人，在DataStax他固定了技术方向并以项目领导人的身份领导着Apache Cassandra项目。
|
