MongDB与HBase对比

MongDB与HBase对比
MongDB与HBase对比
MongDB：
介绍：MongoDB是一个基于分布式文件存储的开源数据库。

由C++语言编写，旨在为WEB应用提供可扩展的高性能数据存储解决方案。

主要特点：高性能、易部署、易使用、存储数据非常方便。

主要功能特性：
◆面向集合存储，易存储对象类型的数据：类JSON数据模式简单而强大，模式自由。

◆高效的传统存储方式：支持二进制数据及大型对象（如照片和视频）。

◆支持完全索引、动态查询。

◆支持JAVA、C++、PHP、RUBY、PYTHON等多种语言，原生支持地理位置索引，可以直接用于位置距离计算和查询。

◆自动处理碎片，支持Map/Reduce。

◆自动分片支持云级扩展性：自动分片功能支持水平的数据库集群，可动态添加额外的机器。

◆支持复制和故障恢复：MongoDB数据库支持服务器之间的数据复制，支持主-从模式及服务器之间的相互复制。

◆第三方支持丰富：现在网络上的很多NoSQL开源数据库完全属于社区型的，没有官方支持，给使用者带来了很大的风险。

而MongoDB背后有商业公司10gen 为其提供商业培训和支持，而且MongoDB社区非常活跃，很多开发框架都迅速提供了对MongDB的支持。

使用原理：
所谓“面向集合”（Collenction-Oriented），意思是数据被分组存储在数据集中，被称为一个集合（Collenction)。

每个集合在数据库中都有一个唯一的标识名，并且可以包含无限数目的文档（document）。

集合的概念类似关系型数据库（RDBMS）里的表
（table），文档（document）对应于关系型数据库中表的记录（record）。

不同的是它不需要定义任何模式（schema)。

模式自由（schema-free)，意味着对于存储在MongoDB数据库中的文件，我们不需要知道它的任何结构定义。

如果需要的话，你完全可以把不同结构的文件存储在同一个数据库里。

存储在集合中的文档，被存储为键-值对的形式。

键用于唯一标识一个文档，为字符串类型，而值则可以是各种复杂的文件类型，我们称这种存储形式为BSON （Binary JSON）。

缺点：
◆在32位系统上，不支持大于2.5G的数据，单个文档大小限制为16M。

◆不支持join操作和事务机制。

◆对内存要求比较大，至少要保证热数据（索引、数据及系统其它开销）都能装进内存。

◆锁粒度太粗，MongoDB使用的是一把全局的读写锁。

◆应用程度不够成熟，2010年Foursquare发生过11小时宕机事件。

MongoDB主要应用场景：
◆网站数据：MongoDB非常适合实时的插入、更新与查询，并具备网站实时数
据存储所需的复制及高度伸缩性；
◆缓存：由于性能很高，MongoDB也适合作为信息基础设施的缓存层。

在系统重启之后，由MongoDB搭建的持久化缓存层可以避免下层的数据源过载；
◆大尺寸，低价值的数据：使用传统的关系型数据库存储一些数据时可能会比较昂贵，在此之前，很多时候程序员往往会选择传统的文件进行存储；
◆高伸缩性的场景：MongoDB非常适合由数十或数百台服务器组成的数据库。

MongoDB对MapReduce引擎的内置支持；
◆用于对象及JSON数据的存储：MongoDB的BSON数据格式
非常适合文档化格式的存储及查询；
应用案例：Foursquare、思科的WebEx Social（企业版的facebook）。

HBase：
介绍：HBase是一个高可靠性、高性能、面向列、可伸缩的开源分布式存储系统，利用HBase技术可在廉价PC Server上搭建起大规模结构化存储集群。

优点：
◆首先它的数据由hdfs天然地做了数据冗余，云梯三年的稳定运行，数据100%可靠己经证明了hdfs集群的安全性，以及服务于海量数据的能力。

◆其次hbase本身的数据读写服务没有单点的限制，服务能力可以随服务器的增长而线性增长，达到几十上百台的规模。

◆LSM-Tree模式的设计让hbase的写入性能非常良好，单次写入通常在1-3ms 内即可响应完成，且性能不随数据量的增长而下降。

◆region（相当于数据库的分表）可以ms级动态的切分和移动，保证了负载均衡性。

◆由于hbase上的数据模型是按rowkey排序存储的，而读取时会一次读取连续的整块数据做为cache，因此良好的rowkey设计可以让批量读取变得十分容易，甚至只需要1次IO就能获取几十上百条用户想要的数据。

工作原理：
首先HBase Client端会连接Zookeeper Qurom(从下面的代码也能看出来，例如：HBASE_CONFIG.set("hbase.zookeeper.quorum","192.168.50.216" ) )。

通过Zookeeper 组件Client能获知哪个Server管理-ROOT-Region。

那么Client就去访问管理-ROOT-的Server，在META中记录了HBase中所有表信息，从而获取Region分布的信息。

一旦Client 获取了这一行的位置信息，比如这一行属于哪个Region，Client将会缓存这个信息并直接访问HRegionServer。

久而久之Client缓存的信息渐渐增多，即使不访问.META.表也能知道去访问哪个
HRegionServer。

HBase中包含两种基本类型的文件，一种用于存储WAL的log，另一种用于存储具体的数据，这些数据都通过DFS Client和分布式的文件系统HDFS进行交互实现存储。

缺点：
◆不能支持条件查询，只支持按照Row key来查询。

◆暂时不能支持Master server的故障切换，当Master宕机后，整个存储系统就会挂掉。

◆对企业应用开发的公司来说技术门槛很高。

Hbase主要适用场景：
◆大数据量（100s TB级数据）且有快速随机访问的需求。

例如淘宝的交易历史记录。

数据量巨大无容置疑，面向普通用户的请求必然要即
时响应。

◆容量的优雅扩展。

大数据的驱使，动态扩展系统容量的必须的。

例如：webPage DB。

◆业务场景简单，不需要关系数据库中很多特性（例如交叉列、交叉表，事务，连接等等）。

◆优化方面：合理设计rowkey。

因为hbase的查询用rowkey是最高效的，也几乎的唯一生产环境可行的方式。

所以把你的查询请求转换为查询rowkey的请求吧。

HBase在淘宝的应用：
a）实时推荐、实时报表、实时计费。

这类应用的特点是大量数据的实时写入以及读取。

b）大数据量类型项目。

比如历史类或需要长期保存的数据。

c）二次分析类型项目。

Hadoop集群做粗粒度分析，在线做二次分析，比如数据魔方。

Facebook应用场景：
Facebook主要给出了HBase三类应用场景：Facebook
Messaging、Facebook Insight 和FacebookMetrics System(ODS) 。

Messaging 就是Facebook 的新型消息服务，每个月存储1350亿条消息。

Insight 是提供给开发者和网站拥有者的数据分析工具，可以帮助他们清楚了解到访问者如何与他们网站交互，以便更好地优化他们的服务。

ODS 则是Facebook 内部的软硬件状态统计系统，对于每一个或者一组服务器，都可以有效地从不同的维度来监控他们的状态。

这三个应用场景都有各自的特色，但简单地来说，面临的问题是同样的：单机或者拆分的关系型数据库无法满足需求。

目前情况：
1.对MongoDB进行了初步研究，搭建了基于Spring4.1.6+MongoDB3.0.3的开发框架，封装实现了持久层增、删、改、查及操作地理空间信息等操作的相关接口，完成了部分基础操作的DEMO示例。

但是MongoDB的安全性、高性能及高扩展性有待进行测试。

2.只对Hbase的相关理论进行了解，尚未对Hbase进行实际操作分析。