SolrCloud和ElasticSearch(ES)比较

  categories:资料  author:

来源:http://www.wxdl.cn/index/solr4-solrcloud-elasticsearch-es.html

solrcloud 既即将发布的solr4.0,ElasticSearch--一个炒的较火的开源项目(ElasticSearch)。

SolrCloud(SC)对solr3.0进行较多的改进。具体可参考Solr官方介绍 ,目前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也有其自身的优势,目前看至少其吞吐量表现较好,也值得大家深入研究其优点。

开始solr4.0(cloud)之前我们先看看ElasticSearch(ES)与solr3.6对一些常见feature支持情况的比较。强调这里是solr3.6而非solr4.0。两者的根本区别是后者基于分布式的架构。


1
上面是一些常见feature的比较。这里要说的是最后的两项。

索引的rebuild 索引的重构需要对源数据的存储。这是搜素引擎自己要关心的安全问题。目前存储选择主要是传统的数据库或者分布式数据库(DDB)和类似的NoSql数据 库。传统的数据库免费的自然是MySql。商业数据库以oracal居多。而云存储的备份选择就比较多了:CouchDBRedisMongoDBMembaseNeo4jHBaseCassandra等等,选择原则各有不同。参考8种Nosql数据库系统对比

不管是传统RDB或者新兴Nosql存储都涉及到搜索引擎和存储系统的整合。以冗余的数据空间来换取索引内容的安全。这种妥协对于商用搜索引擎是十分必要的。

跨DC的备份 目前尚未有开源搜索项目支持。实际上开源搜索项目主要还是针对大中型搜索集群,对于跨DC的超大规模集群并不是目前开源项目的目标。可能是考虑到主流用户群的需求还是集中在中大型甚至小型搜索上(google是在好几年前就实现了跨DC的能力)。

下面再看看对一些重要feature在ElasticSearch和Solr3.6上进行添加或修改的难易程度
2
可以看到除了在添加、删除shard上ES不能支持外。其特征是多余solr3.6的

Chang shard这里主要指在服务运行时增加或删除shard,尤其是增加shard通常是一个重要的 feature。我们知道应用数据是不断增加的,随着数据的积累,索引请求的增加,加入新的shard来出理不断增长的数据就成为一个和合理而自然的需 要。然而ES的架构决定其很难做到shard的伸缩。而同样的solr包括现在的4.0版也不支持shard数的热增长。假如要强行在shard层做修改 以试图支持这种Scalability,那么ES的代价将高于solr(4.0) 。但对于shard的热增长两者都可以通过其它方式去较好的解决。此处不详述。

上面我们看了ES和Solr3.6的比较。我们看SOlr4.0有哪些变动,先看看4.0的架构
3

Solr4.0相对于Solr3.6的新特征:

•统一配置集群.
•查询自动负载均衡和失败回滚.
•使用ZooKeeper进行集群协调和配置.

Solr4.0 与ES的feature比较
4

上面是Solr4.0 alpha版的特征为基础。Solr4.0在Beta版之后又增加了collection的概念,相当于Tennacy。所以此处Multi Tenancy 在Solr4.0中是支持的了。其他重要的feaure两者相差不大。

权限控制:这里要特别提出权限验证的问题。对于商用产品权限验证是必须的。两者都不支持权限验证。需要用户自己 增加这一块的功能。然而就目前来看,两者在增加该功能的难易程度来说,ES是相对容易很多。原因为ES内部节点之间使用自定义协议;而Solr4.0内部 节点之间使用了和外部一样的http协议,并且节点间的通信关系混乱,所以对目前的Solr4.0增加权限验证以及ACL将很难寻找到一个优雅的解决方 案,但并不是不可以。

除此之外solr4.0还有一些其它难于再次开发的地方,以后再叙述。

下一次将把Solr4.0 alpha同ES的性能测试比较结果列出来,以作参考。由于alpha版并不成熟,性能上可能会和正式版有一定差距。

总结

总体来说Solr4.0正式版也刚发布不到半年。存在的问题不少,其架构能否经得起考验,还有待时间来证明。从代码的优雅程度还是和ES有一定的差距,但代码的易读性上好于ES(ES大量使用模式,且调用层次太深,方法的追踪麻烦)



快乐成长 每天进步一点点      京ICP备18032580号-1