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

来源：http://www.tnove.com/?p=36

   本文针对solr4.0 。solr4.1 ,solr4.2,solr4.3, 在性能上无太多改变。

          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他们的代码，期望能在规定时间内发现更多细节上的差异。目前已有部分发现，将在后面的逐一贴出来。