[译]ElasticSearch vs. Solr

为什么日志服务商Loggly选择ElasticSearch而非Solr.
原文连接: http://loggly.wpengine.com/bl...

在Gen2产品的早期阶段, 咱们事实上是失败的, 这促使咱们从新审视咱们现有的技术栈. 咱们仔细分析系统中的每一个独立的组件,并记录下来, 固然其中也包括构成咱们核心功能的搜索引擎技术.

在咱们的通用日志管理系统场景中, 提供了对每条单独日志事件的查询以及对全部日志事件的分析图表以帮助客户他们了解他们的数据动态. 解决这些场景的基本要求以下:

• 一个可扩展且高容错能力的日志收集管道. 咱们团队使用了Apache Kafka做为数据管道;须要强调的是若是你须要为任何一个搜索引擎订阅大量数据, 你须要一个稳定的管道系统.

• 强大的搜索能力: 能给大量的数据提供准实时的索引支持, 同时也能提供高可用的搜索请求.

在咱们的第一代产品Gen1(2010)时, 咱们使用了当时具备云处理能力而且提供NRT(near real-time)搜索功能的Solr, 恰好Solr的这两项功能正是咱们所须要的. 起初基于初版具备云能力支持的Solr分支开始了咱们系统的构建. 因为一些缘由, 稳定版的SolrCloud + NRT功能直到2012年才基本可用. 那段时间, 咱们经过插件和直接修改源代码的形式持续扩展和使用Solr.

在2012年, 咱们准备启动Gen2, 当时SolrCloud4.0刚刚发布, 同时ElasticSearch也有了0.19.9版本. 在技术调研的时候,我是Solr技术的强烈支持者, 然而通过几个月的对比, 我终于意识到ElasticSearch才是咱们更好的选择.

在任何技术选型过程当中, 总有不少考虑因素. 下面是当时促使咱们选择ElasticSearch的一些重要考虑. 不过这些总结是基于2012年时候的场景, 最近几年可能已经发生了翻天覆地的变化.

1) 搜索特性

由于ES和Solr都是基于Lucene构建, 因此不管选择哪一个都能提供咱们所须要的搜索特性. 然而由于每一个系统的发展历程及其设计目标又让咱们必须面对和区分他们的强项和不足.

Solr的设计目标主要是为了解决困难的信息检索(IR: information retrieval)问题. 这也反映在它的API设计上, 比ES提供了更强大的搜索能力. ES, 如其名称所述, 主要是定位在弹性扩展能力, 所以在IR特性上稍有欠缺. 就咱们的业务场景, 并不须要当即使用这些复杂的高级特性. 尽管Solr具备更好的搜索技术优点, 然而ES知足了咱们当前的需求并所以胜出.

2) 搜索扩展性

由于在Gen1中已经使用了Solr, 因此咱们有能力对Solr进行扩展, 而且掌握了如何管理以及Solr在这方面的一些限制. ES有所不一样, 咱们必须验证它的扩展能力能够知足咱们的需求.

咱们开始为每一个系统各部署一个集群, 并经过加载大量的数据进行极限测试, 以及经过强制关停部分节点以观察每一个系统的表现. 那个时候, 咱们就像一群捣乱的猴子.

在测试中发现SolrCloud最大的问题在于它的集群管理能力. 同时在内存不足时, SolrCound也面临着稳定性的稳定. 另外还遇到了集群锁定(lock-up)问题, 只能整个集群的重启才能解决. 与此同时, 一样的场景下ES并未遇到不可恢复的失败. 虽然也有办法能让ES丢失数据, 但咱们清楚的知道何时会发生, 并能有办法解决这些问题.

3)配置管理

在Gen1中, 咱们耗费了大量的精力来处理Solr的配置管理,包括数据流向以及索引和分片的管理等. 当时咱们经过一系统的插件以及源代码修改来处理的.虽然这项技术挑战让人兴奋, 但咱们并不想在这上面耗费太多时间, 而是把更多的精力放在产品差别化上: 更好的展现经过引擎获取和分析后的结果, 并给客户提供更好的数据内涵.

毫无疑问, ES赢得了这项比较. 由于ES团队对灵活性的追求几近疯狂. 具体以下:

• Solr的Collections API是最新提供的,而且很是简陋.而ES则提供了原生的, 稳定的索引管理功能.

• Solr和ES都默认提供了合理的分片分配策略, 但ES的路由框架相比Solr的Collections API更强大可靠.

• 咱们曾讨论过ES的Master/Slave模型是否不如Solr的分布式模型,事实上功能实现的质量远比完美的理论更重要.

4) 性能

尽管ES和Solr都基于Lucene, 但在咱们的性能测试过程当中发现了他们在使用方式上的不一样. 在索引速度上, Solr无疑更高效, 以下图所示:

上图中每一个结点都是一组独立的测试结果, 在每一组中咱们在一个固定的时间周期(2,5,10,20分钟等等)里每次批量索引8000次. 在测试结果中能够清楚的看到结果被分红了两组: Solr基本上能稳定的索引18000次/秒, 而ES在开始的时候速度至关(虽然也不太稳定), 但随着测试时间变长, ES的索引速度降低不能承受12000次/秒.

尽管看起来Solr赢了, 但很大的变数可能在于Solr使用的是Lucene4, 而ES使用的是Lucene3.6.因此很难客观的说哪一个更好. 而且ES也将引入Lucene4, 因此这项差别应该也将会不复存在.

最终, 在咱们的决定中性能只做为一个参考因素而非决定因素.

5) 社区支持

ES和Solr都是开源项目, 而且社区都很活跃. 咱们讨论了ES和Solr的模型在理论上的不一样, 更倾向于Solr的开放模型, 同时也对ES团队的管理工做印象深入. 虽然Solr在社区的规模和活跃度上都占优点, 但ES也在快速增加,而且增加速度飞快.

6) 其余因素

咱们对这两个产品还有不少讨论, 下面再简单看下其中的几个:

• ES的API很是优雅强大, 而且其REST服务很是适合咱们先后端分离的架构

• ES的扫描和过滤特性很是有趣, 而且发现了不少可能的使用场景

• 都原生支持JSON数据格式, 能节省不少咱们曾在Loggly Gen1中写的代码

• ES的类型自动解析和Solr的动态字段都很是有用, 能够避免对持续演进的输入数据的管理

• Solr4原生的分层/中心模型很赞

• ES的内存管理比Solr更简单

• 两者对插件支持都很是好, 但Solr支持更核心层的插件

还有一些咱们并未执拗坚持的因素, 以下;

• 索引一旦建立, 都不容许动态修改分片数量

• ES只有单层模型, 不过也不要紧

• 在ES中使用主分片和副本分片有数据不一致的状况, 在一个准实时系统中可能会带来潜在问题

在讨论的最后, 咱们认为这些影响并非很是严重. 随着讨论的深刻, 咱们更清晰的意识到哪些因素对系统具备更深的影响, 相应的这些因素被赋予了更高的权重.

咱们的选择

最后, 基于如下两点, 咱们选择了ES:

• 咱们但愿减小在配置管理上的精力, 更多的关注产品自己

• 咱们相信随着ES的强大, 一些相比于Solr的不一样也会逐步解决

固然这个选择也会有所付出. 虽然须要把ES配置归入咱们的管道, 而且先后端和架构团队须要实现管道管理, 但相比在Gen1中的付出, 这些都是更高层次的工做. 因此咱们能够更聚焦在本身的产品自己, 这也是开始时所想要的, 也是咱们的客户所须要获得的.

随着SolrCloud和ElasticSearch的成熟, 差距的缩小, 今天很难再对两者进行决择. 不过对你们来讲,这确是件好事: 两者的较力驱使它们以及Lucene的不断提高.