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无疑更高效, 如下图所示:

clipboard.png

 

上图中每个结点都是一组独立的测试结果, 在每一组中我们在一个固定的时间周期(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的不断提升.

 

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/576608.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

android 工程结构,它到底是怎么运行的。

为了帮助理解,我决定先上传一个工程截图,这个是我做的一个小作业,3、4个小时完成,没什么含金量,就是交差用的,这里给大家做个模板吧。 我把一个工程分6个部分,如左面的图所示,然后…

为什么ElasticSearch应用开发者需要了解cluster state

原文链接: https://www.loggly.com/blog/p... 在前面的文章(ES vs Solr)中我们提到, ES构建了Loggly的很多核心功能. 在把这项通用搜索技术用于我们的日志管理系统, 并为超过5000多客户提供准实时服务的过程中, 我们在技术上成长颇多. 按照我们对开源社区的尊重, 在此希望能把我…

给 MySQL 增加 Sequence 管理功能

-- Sequence 管理表 DROP TABLE IF EXISTS sequence; CREATE TABLE sequence ( name VARCHAR(50) NOT NULL, current_value INT NOT NULL, increment INT NOT NULL DEFAULT 1, PRIMARY KEY (name) ) ENGINEInnoDB; -- 取当前值的函数 DROP FUNCTION IF EXISTS currval; DE…

最优化学习笔记(六)——牛顿法性质分析

一、牛顿法存在的问题 在单变量的情况下&#xff0c;如果函数的二阶导数f′′<0&#xff0c;牛顿法就无法收敛到极小点。类似的&#xff0c;在多变量的情况下&#xff0c;目标函数的hessian矩阵F(x(k))非正定&#xff0c;牛顿法的搜索方向并不一定是目标函数值的下降方向。甚…

从FLC中学习的设计模式系列-创建型模式(3)-工厂方法

工厂方法是一组方法&#xff0c; 他们针对不同条件返回不同的类实例&#xff0c;这些类一般有共同的父类。 工厂方法模式 来自&#xff1a; http://zh.wikipedia.org/wiki/工厂方法模式 工厂方法模式 是一种面向对象的设计模式。通过调用不同的方法返回需要的类&#xff0c;而不…

Elasticsearch索引的数据存储路径是如何确定的

Elasticsearch中&#xff0c;在node的配置中可以指定path.data用来作为节点数据的存储目录&#xff0c;而且我们可以指定多个值来作为数据存储的路径&#xff0c;那么Elasticsearch是如何判断应该存储到哪个路径下呢&#xff1f;今天我就记录一下这个问题。 Elasticsearch的索…

带分页码的分页算法

int start 1, end 10;//如果总页数小于结束页码if (PageCount < end){//则结束页码为总页数end PageCount;}else{//当前页大于5后开始重新计算起始页,否则起始页为1start PageIndex > 5 ? PageIndex - 5 : start;//起始页码加9减去总页数,用于查看是否超过了总页数i…

最优化学习笔记(七)——Levenberg-Marquardt修正(牛顿法修正)

上节末尾谈到牛顿法中隐含的另外一个问题在于hessian矩阵可能不是正定的。因此&#xff0c;d(k)−F(x(k))−1g(x(k))\boldsymbol{d}^{(k)} = -\boldsymbol{F}(\boldsymbol{x}^{(k)})^{-1}\boldsymbol{g(x^{(k)})} 可能不会是下降方向。Levenberg-Marquardt修正可以解决这个问…

Elasticsearch内存

核心概念 基于LuceneJava应用 内存使用分析 Lucene的内存消耗 倒排索引。&#xff08;堆内存&#xff09; Lucene中&#xff0c;索引是存储在磁盘中&#xff0c;一个索引&#xff08;Index&#xff09;由多个段&#xff08;Segment&#xff09;组成。当启动IndexSearcher时&…

Canal数据堆积

记录一下canal的问题。数据同步一直使用阿里开源的canal&#xff0c;最近使用过程中遇到一些问题&#xff0c;在这里记录一下。 原因 我们使用canal监听MySQL&#xff0c;然后通过client获取发送到mq&#xff08;自定义格式&#xff09;。最近数据组的同事批量更新了一次数据…

最优化学习笔记(八)——共轭方向法

从这节开始&#xff0c;将学习共轭方向法的相关内容&#xff0c;本篇先做一个简短的开篇。共轭方向法的计算效率不如之前的牛顿法&#xff0c;但是也优于最速下降法。它有以下优势&#xff1a; 对于n维二次型问题,能够在n步之内得到结果&#xff1b;作为共轭方向的典型代表&am…

解决PhoneGap在Android手机上的全屏问题

目前&#xff0c;结合PhoneGap 框架使用HTML5JavaScriptCSS3开发Android或IOS系统上的应用和游戏已经成为可能性&#xff0c;这两天自己使用HTML5开发了一款小型悠闲游戏&#xff0c;使用PhoneGap打包成APK运行在Android手机上&#xff0c;却遇到不能全屏&#xff0c;想了好久&…

ES学习笔记之-ClusterState的学习

前面研究过ES的get api的整体思路&#xff0c;作为编写ES插件时的借鉴。当时的重点在与理解整体流程&#xff0c;主要是shardOperation()的方法内部的调用逻辑&#xff0c;就弱化了shards()方法。实际上shards()方法在理解ES的结构层面&#xff0c;作用更大一些。我们还是从get…

最优化学习笔记(九)——基本的共轭方向算法

一、基本共轭方向算法 对于n维二次型函数的最小化问题: f(x)=12xTQx−xTb f(x)=\frac{1}{2}\boldsymbol{x^TQx-x^Tb}其中&#xff0c;QQT>0,x∈Rn。因为Q>0,所以函数f有一个全局极小点,可以通过求解Qx=b得到。 基本共轭方向算法 给定初始点x(0)和一组关于Q共轭的方向…

HTML简单实例加表单的显示效果

HTML可以说是一种十分简单的标记语言&#xff0c;但是对于Web开发还是必不可少的&#xff0c;所以对HTML的标记进行适当的了解 还是十分有必要的。下面我们来演示一下基本的HTML效果和一些简单的标签&#xff0c;以及在表单界面的各种提交方式。 首先是HTML的常用简单标签。 &l…

机器学习笔记(十二)——马尔科夫模型

马尔科夫模型是一种概率图模型&#xff0c;它描述了一类重要的随机过程(随机过程又称为随机函数&#xff0c;是随时间而随机变化的过程)。我们常常需要考察一个随机变量序列&#xff0c;这些随机变量序列并不是相互独立的&#xff0c;每个随机变量的值都依赖于这个序列前边的状…

用Java代码在ElasticSearch中索引PDF文件?

以下是我的代码&#xff1a; InputStream inputStream new FileInputStream(new File("mypdf.pdf"));try {byte[] fileByteStream IOUtils.toByteArray(inputStream );String base64String new String(Base64.getEncoder().encodeToString(fileByteStream).getBy…

美国影视演员协会选择了Windows Azure

娱乐行业的主要组织之一的美国影视演员协会&#xff08;SAG&#xff09;最近因云计算的需要选择Windows Azure解决方案。美国影视演员协会将他们的网站从基于Linux的服务器迁移到支持他们的最大年度事件——美国演员工会奖的Windows Azure上。 每年的年度颁奖典礼的到来标志着一…

最优化学习笔记(十)——对偶线性规划

一、对偶问题 每个线性规划问题都有一个与之对应的对偶问题。对偶问题是以原问题的约束条件和目标函数为基础构造而来的。对偶问题也是一个线性规划问题&#xff0c;因此可以采用单纯形法&#xff08;有关单纯形法会在以后的笔记中补充&#xff09;求解。对偶问题的最优解也可以…

elasticsearch基本查询二(英文分词)term和terms查询

term和terms查询(查找zhaoliu这个人的信息) term query会去倒排索弓|中寻找确切的term,它并不知道分词器的存在。这种查询适合keyword、numeric. date. term:查询某个字段里含有某个关键词的文档 GET /lib3/user/_search/ { "query":{ "term": {interests&…