mongdo 减少访问量_MongoDB vs. HBase - 常见几种大数据技术比较分析

9. MongoDB vs. HBase

事实上HBase正式作为一个NoSQL通常是Hadoop生态系统里用来支持操作型大数据的实时读写需求的。可惜HBase 是个扶不起的刘阿斗，跟着Hadoop的大旗沾了不少光，用起来问题一堆：

1、原生不支持二级索引，只能通过主键访问。社区实现的二级索引功能支持和数据更新有时延，导致头疼的一致性问题

2、宽表模型概念拗考，难于理解并且要求实现建模，不够灵活

3、数据类型低级，只支持比特流，开发很不友好

4、支持程序语言种类少(Java，Thrift， RESTful API)

5、集群结构复杂，有8种不同类型节点

6、无一致性快照功能

7、需要定时compact，对持续读写场景影响很大

因为这些原因，HBase只能在真的是超级大量数据的场景下才值得去忍受着种种不便去使用。和HBase相比，MongoDB也有一些自己的不足：

1、多表事务还在研发中，导致对原子性要求较高需要回滚的时候只能通过变通手段来实现，增加了开发复杂度(所有NoSQL基本都不支持事务)

2、常为读性能优化而鼓励冗余，但是又不提供这些冗余数据变化时候的自动同步

但是MongoDB在取悦开发者，提高开发效率上可是做的淋漓尽致：支持数十种程序语言；有最大的开发社区；JSON文档模型是个程序员都懂，API式管理数据库，非常自然；支持二级索引，关系型数据库的复杂查询基本都能支持；MEAN stack，全JS开发；无须ORM，减少服务层和持久化层的摩擦；动态模型，无须显式建模，适合快速开发；傻瓜式水平扩展。正是这些原因，DBTA 2017年的“读者最喜欢的数据库”里面，MongoDB傲视群雄，夺得了桂冠。

10. 后Hadoop时代： 数据即服务

今天的企业在其数字化转型、双模IT及企业上云策略下，纷纷在重新审视企业的平台级数据库产品策略。企业已经大手笔投入了大量的资源构建基于Hadoop的数据湖，但是由于Hadoop本身特性所限，很多部署变成了 “数据垃圾堆”(Data Dump)，空有数据，但无法实现价值。企业真正需要的是一套在线操作型大数据解决方案可以满足：

1、汇聚来自各个独立隔离系统的客户、行销、生产等数据，提供360度统一视图

2、海量的性能扩展来应付日益增加的数据量及业务需求

3、提供秒级数据API 服务来驱动实时面板和快速应用开发

4、大规模减少ETL流程，降低成本

这种方案应该充分企业已经投入的Hadoop体系架构，但是在此之上铺设一个以低延迟高并发支持灵活API为特色的DaaS(Data as a Service)数据即服务层。

数据即服务就是一种操作型大数据平台的具体体现。这种基于MongoDB的架构的优势在于：

除上述之外，基于分片机制的自动扩容的机制更可以支持数以百TB级的业务数据量；异构数据库实时同步工具可以把来自于数十个业务系统库内的数据同步到数据服务层，并提供秒级的数据一致；在同步过程中实现数据模型转换，快速搭建服务；批量方式或者连接器方式直接接受来自Hadoop集群的分析结果，如个性化标签及推荐信息等，提高Hadoop的可操作性 等等优势。

RBS银行在2015年就开始实施了这样的DaaS架构，短短两年时间，RBS声称已经获得了以下的价值：

1、降低的成本：数百万欧元的Coherence及Oracle商业授权的节省

2、简化的技术栈：一套方案已经支持了数十个数据应用

3、开发加速：新应用上线时间从12个月到数个星期

与此类似的成功案例还有巴克莱银行，Vodafone电信公司等，均是在其数字化转型中经过审慎评估，选择了操作性强，易用性高，分布式能力可靠的MongoDB作为其新一代数据服务平台。

11. 结语

每一种技术都有它的应用场景，在这篇文章里我们想要讨论的是一种操作型大数据解决方案，所以我们花了不少笔墨在NoSQL并认为MongoDB是一个非常不错的选择。NewSQL或许会是一个潜在的选择，如果不是因为现在它还没发展成熟。况且，NewSQL对半结构化、非结构化数据的需求支持估计也还是无法很好满足， 所以我们拭目以待。最后，在做一个大型决策的时候，我们要充分考虑到企业对技术能力的需求，把需求列出来，然后对照数据产品各自的长短板，有理论有方法的进行选型，并对最后2-3个选择进行POC验证，最终确定合适的方案。