当前位置: 首页 > elasticsearch, solr, 搜索 > 正文

Solr4.0(SolrCloud)和 ElasticSearch(ES) 比较(一)

1 星2 星3 星4 星5 星 (3 次投票, 评分: 5.00, 总分: 5)
Loading ... Loading ...
baidu_share

team之前的search解决方案不同于行业常见架构(solr及其它开源项目),其searcher和indexer在分布式环境下是分离的,而solr等open source project 基本都是放在单个instance的。两者以单独的instance 存在,甚至可以searcher部署在A机器上,indexer部署在B机器上。当然我们也支持将两者放在同一个instance里。这种架构足以满足之前的需求,并且运行良好。

刚好组织变动,有机会升级我们的架构。所以我们决定转向开源项目,既然开源是目前的主流。这种转变并不是说我们之前的架构比Solr的差,两种架构决策很难说孰优孰劣。我们也没有对两者做具体的测试。

在此决定下,我们面对很多open source 可以选择,在高层和team自己的筛选后初步选项有两个:solrcloud 既即将发布的solr4.0,ElasticSearch--一个炒的较火的开源项目(ElasticSearch)。

SolrCloud(SC)对solr3.0进行较多的改进。具体可参考solr官方介绍:http://wiki.apache.org/solr/SolrCloud ,目前Solr4.0还没正式发布,但solrcloud可以run ES 主要正对solr3.0的缺点而开发。而SC在solr3.0的基础上做了大量工作,新的SC的架构和ES在整体上很相似了。所以原先ES相对与solr3.0的优势对于SC就不明显了。 但目前这两项目在开源中走在最前面。所以我们决定对ES和SC做详细的评估,以决定我们最后的选择。详细测试结果发布在下面两篇文章中 SolrCloud performance test ElasticSearch(ES) performance Test 这里补充两点:1.SC内嵌jetty和zookeeper。2. ES实用netty实现自己的web容器。 对于上面两个结果中SolrCloud 的结果doesn’t make sence。由于要在规定的时间内完成评估,所以分别对es和sc的源码进行了概略的研究。寻找她们各自search和index策略。再三check了测试环境,并且用yourkit等工具分析了ES和SC的运行状态和性能。并没有找到SC为什么出现这样异常的表现。昨晚总于在一些异常状态中有了新的发现。SC中jetty设置了默认的线程池大小,为100,这直接影响了在大量请求到来时SC的处理能力。而ES线程数理论上是没有限制的。所以我们将jetty的线程池大小改为60000个以保证不会是因为线程数受限而影响其性能。新的测试结果暂时还未发布。

总结:

比小新的SC和ES的测试结果后,可以看出,ES在search和index的性能上高于SC,无论是单独进行search或index,还是两者同时进行。ES不用依赖很多的包(其实是通过将很多open source源码加入自己项目实现的),ES配置很简单,很方便就能运行,基本不用调优。但ES community并不活跃,严重缺乏文档,主要代码贡献者和维护者只有一个人,另为ES的源码看起来并不容易,很难理清其中关系,调用层次太深。相对而言SOLR有成熟活跃的社区,大量牛人维护和contributor,文档齐全,代码易读性强。 在扩张性上不相上下,当然必须基于完全理解ES的源码后。 ES比较适合较小的search应用。稳定性还不好说,因为实用者不多,目前仅有的一些商用公司也仅将其应用于小项目和公司内部。对比solr则有大量的商业产品应用,经过了足够的考验。所以最终我们倾向于实用SC。不过ES也有其自身的优势,目前看至少其吞吐量表现较好,也值得大家深入研究其优点。

下一步:

目前我们还在对ES和solrcloud进行进一部的测试。同时review他们的代码,期望能在规定时间内发现更多细节上的差异。目前已有部分发现,将在后面的逐一贴出来。

本文固定链接: http://www.chepoo.com/solrcloud-vs-elasticsearches-1.html | IT技术精华网

Solr4.0(SolrCloud)和 ElasticSearch(ES) 比较(一):等您坐沙发呢!

发表评论