Elasticsearch、MongoDB和Hadoop比较

IT界在过去几年中出现了一个有趣的现象。不少新的技术出现并当即拥抱了“大数据”。稍微老一点的技术也会将大数据添进本身的特性，避免落大部队太远，咱们看到了不一样技术之间的边际的模糊化。假如你有诸如Elasticsearch或者Solr这样的搜索引擎，它们存储着JSON文档，MongoDB存着JSON文档，或者一堆JSON文档存放在一个Hadoop集群的HDFS中。你可使用这三种配置完成不少同养的事情。

ES是否能够做为一个NoSQL数据库？粗看，这句话说的不太对，可是这是一个合理的场景。相似地，MongoDB在MapReduce的基础上使用分片的技术一样能够完成Hadoop能够作的工做。固然使用众多功能，咱们能够在Hadoop之上（Hive、HBase、Pig和一样的一些）你也能够用多种方式查询Hadoop集群中的数据。

那么，咱们如今是否能说Hadoop、MongoDB和Elasticsearch这三个是彻底相同的呢？显然不行！每一个工具都有自身最为适用的场景，可是每一个都有至关的灵活性可以胜任不一样的角色。如今的问题就变成“这些技术的最合适的使用场景是什么？”。下面咱们来瞧瞧。

Elasticsearch已经超越了其最初的纯搜索引擎的角色，如今已经增长了分析和可视化的特性——可是它的核心仍旧是一个全文搜索引擎。Elasticsearch创建在Lucene之上而且支持极其快速的查询和丰富的查询语法。若是你有数百万的文档须要经过关键词进行定位时，Elasticsearch确定是最佳选择。固然，若是你的文档是JSON的，你就能够把Elasticsearch看成一种轻量级的“NoSQL数据库”。可是Elasticsearch不是一个合适的数据库引擎，对复杂的查询和聚合并非很强，尽管统计facet能够提供必定的关于给定查询的统计信息的支持。Elasticsearch中的facet主要是用来支持分面的浏览功能。

目前Elasticsearch已经增长了aggregation的功能 若是你在寻找一个对应于一个关键词查询的少许的文档集合，而且要支持在这些结果中分面的导航，那么Elasticsearch确定是最好的选择。若是你须要进行更加复杂的计算，对数据执行服务端的脚本，轻松地运行MapReduce job，那么MongoDB或者Hadoop就进入待选项中。

MongoDB是NoSQL数据库，被设计成一个高可扩展，而且有自动分片的功能及一些额外性能优化的功能。MongoDB是一个面向文档的数据库，以JSON的形式进行数据的存储（准确地说能够称为BSON，对JSON进行了一些加强）——例如，一个native数据类型。MongoDB提供了一个文本索引类型来支持全文检索，因此咱们能够看到在Elasticsearch和MongoDB之间的界限，基本的关键词搜索对应于文档的集合。

MongoDB超过Elasticsearch的地方在于其对于服务器端js脚本的支持、聚合的管道、MapReduce的支持和capped collections。使用MongoDB，你可使用聚合管道来处理一个集合中的文档，经过一个管道操做的序列来多步地对文档进行处理。管道操做能够生成全新的文档而且从最终的结果中移除文档。这是一个在检索数据时的至关强的过滤、处理和转化数据的特色。MongoDB也支持对一个数据collection进行map/reduce job的执行，使用定制的js函数进行操做的map和reduce过程。这就保证了MongoDB能够对选定的数据执行任意类型的计算或者转换的终极的灵活性。

MongoDB另外一个极其强大的特性称之为“Capped collections”。使用这个特性，用户能够定义一个collection的最大size——而后这个collection能够被盲写，而且会roll-over必须的数据来获取log和其余供分析的流数据。

你看到，Elasticsearch和MongoDB有一个可能的应用场景的重叠，它们不是一样的工具。可是Hadoop呢？Hadoop就是MapReduce，这已经有MongoDB就地支持了啊！是否是还有一个专属于Hadoop的场景，MongoDB就只是适合。

有！Hadoop是老MapReduce了，提供了最为灵活和强大的环境来进行大量数据的处理，毫无疑问的是可以搞定不能使用Elasticsearch或者MongoDB处理的场景。

为了更加清楚地认识到这点，看看Hadoop如何使用HDFS抽象存储的——从关联的计算特性上。经过HDFS中存储的数据，任意job均可以对于数据进行运算，使用写在核心MapReduce API上，或者使用Hadoop流技术直接使用native语言编程。基于Hadoop 2和YARN，甚至核心编程模型都已经被抽象了，你再也不受到MapReduce的牵制了。使用YARN你能够在Hadoop上实现MPI而且用那种方式写job。

额外地，Hadoop生态系统提供了一个交错的工具集合，创建在HDFS和核心MapReduce之上，来进行数据的查询、分析和处理。Hive提供了一个相似SQL的语言，使得业务分析可使用一个用户习惯的语法进行查询。HBASE提供了一个基于Hadoop的面向列的数据库。Pig和Sizzle提供了两个更加不一样的编程模型来查询Hadoop数据。对存储在HDFS中的数据的使用，你能够继承Mahout的机器学习的能力至你的工具集。当使用RHadoop时，你能够直接使用R统计语言来对Hadoop数据执行高级的统计分析

因此，尽管Hadoop和MongoDB也有部分重叠的应用场景而且共同拥有一些有用的功能（无缝的水平扩展），可是二者之间仍是有着特定的场景。若是你仅仅想要经过关键字和简单的分析，那么Elasticsearch能够完成任务；若是你须要查询文档，而且包含更加复杂的分析过程，那么MongoDB至关适合；若是你有一个海量的数据，须要大量不一样的复杂处理和分析，那么Hadoop提供了最为普遍的工具和灵活性。

一个亘古不变的道理就是选择手头最适合的工具作事。在大数据这样的背景下，技术层出不穷，技术间的界限也是至关的模糊，这对咱们的选择是一件至关困难的事情。正如你所见，特定的场景有着最适合的技术，这种差别性是至关重要的。最好的消息就是你不在限定在某一种工具或者技术上。依赖于你面对的场景，这就使得咱们可以构建一个整合的系统。例如，咱们知道Elasticsearch和Hadoop是能够很好地一块儿共事的，使用Elasticsearch快速的关键词查询，Hadoop job则能处理至关复杂的分析。

最终，采用了最大的搜索和细致的分析来确认最为合适的选择。在选择任何技术或者平台时，须要仔细地验证它们，理解这个东东适合哪些场景，哪里能够进行优化，须要作出哪些牺牲。从一个小小的预研项目开始，确认完毕后，再将技术应用到真正的平台上，缓慢地升级到新的层级。

跟随这些建议，你能够成功地在大数据技术中遨游，而且得到相应的回报。

文／Not_GOD（简书做者） 原文连接：http://www.jianshu.com/p/2c7b0c76fa04 著做权归做者全部，转载请联系做者得到受权，并标注“简书做者”。