我们为什么在这里?我存在的目的是什么?我应该运动还是休息并节省能量?早起上班或晚起并整夜工作?我应该将炸薯条和番茄酱或蛋黄酱一起吃吗?
这些都是古老的问题,可能有也可能没有答案。其中一些是非常困难或非常主观的。但是,让我付出一些努力来尝试回答其中之一:我应该使用Elasticsearch还是Solr?
这是场景。您的组织正在寻求实现您的第一个搜索引擎,并切换到另一个搜索引擎-呼吁所有Google Search Appliance(GSA)用户寻找替代品!-或尝试通过开源来省钱。作为一个熟练而有能力的开发人员,您已经被要求解决一个难题。您的问题有许多业务需求,但从根本上讲,这是一个“大数据和搜索”问题。
您需要从多个数据源中提取大量内容,并从这些数据中获取见解,以帮助您的公司发展并实现其今年的目标。
这里有很多危险。您不会错过任何一个镜头。您需要合适的搜索引擎来工作,您正在考虑开放源代码,并且有两个受欢迎的选择:Elasticsearch或Solr,根据DB-的说法,这两个都稳居开放源和商业搜索引擎的前两位。引擎。
这不是抛硬币也不是容易的选择。两种搜索引擎都很棒,没有一个“正确”的选择。这完全取决于您的要求。
因此,第一步是了解您必须构建什么应用程序。然后,下一步是查看每个搜索引擎必须提供的功能。顺便说一句,如果您仍处于开源与商业解决方案的交汇处,请获取我们的免费电子书,以深入了解选择搜索引擎时要考虑的10个关键标准。
功能概要
几年前,我们写了一个关于Elasticsearch vs. Solr的高级概述博客,其中讨论了总体趋势和非技术见解。现在,随着Elasticsearch的发展壮大并成为开放源代码搜索引擎市场的主导者,让我们重新审视一下每个领域,看看它将带给我们什么。
在这种情况下,可以说Solr的历史悠久,它由CNET Networks的Yonik Seely于2004年创建,后来在2006年将其贡献给Apache。它最终在2007年毕业于顶级项目。我们拥有的是Elasticsearch,该软件于2010年正式创建,尽管它实际上是由其创始人Shay Bannon于2001年以Compass的名字开始的。从那时起,Kibana,Logstash和Beats的创建者加入了Elasticsearch,创建了Elastic Stack产品系列,该产品系列已成为搜索和日志分析领域的强大参与者。话虽如此,Solr的优势在于可以较早地在市场上看到。
两者都有非常活跃的社区。如果您查看Github,您会发现它们是非常受欢迎的开源项目,发布了很多版本。
一个非常重要的细节是,尽管两者都是在Apache许可下发布的,并且都是开源的,但是它们的工作方式却有所不同。Solr确实是开源的-任何人都可以提供帮助和贡献。使用Elasticsearch,尽管人们仍然可以提供他们的捐款,但是只有Elastic的员工(Elasticsearch和Elastic Stack背后的公司)可以接受这些捐款。
这是好事还是坏事?这取决于你怎么看了。这意味着,如果有您需要的功能,并且您以足够的质量向社区做出了贡献,那么它可以被Solr接受。借助Elasticsearch,由Elastic来决定是否接受捐助。因此,Solr上可能有更多功能选项。另一方面,对Elasticsearch的贡献要经过更高级别的质量检查,可能会提供更高的一致性和质量。
Elasticsearch和Solr都有文档齐全的参考指南。Elasticsearch在Github之上运行,而Solr使用Atlassian Confluence。您可以通过下面的链接找到它们。
Elasticsearch参考指南 Solr参考指南
让我们多一点技术。Elasticsearch和Solr是两个不同的搜索引擎。但在下面,它们都使用Lucene,这意味着两者都建立在“巨人的肩膀”上。
对于那些想知道为什么我将Lucene视为“巨人”的人来说,它是许多搜索引擎支持下的实际信息检索软件库。它非常快速,稳定,并且可能无法比这更好。Lucene是由Hadoop的创建者之一Doug Cutting于1999年创建的。因此,Lucene是在搜索引擎中使用的理想选择。
Elasticsearch具有更多的“ Web 2.0” REST API,但是Solr的SolrJ确实有更好的Java API-如果使用Microsoft技术,则为SolrNet。Elasticsearch拥有Nest和Elasticsearch.Net。Solr的REST API可能没有那么灵活,但是它可以很好地满足您的需求:建立索引和查询。Elasticsearch会说JSON,因此,如果您周围都使用JSON,那么这是一个不错的选择。Solr也支持JSON,但是它是在以后的阶段添加的,因为它最初是针对XML的。
内容处理由于它们都公开了API,因此很容易从您的自定义应用程序或已经存在且可配置的应用程序中索引内容。例如,我们的Aspire内容处理框架能够连接到多个数据源并发布到Elasticsearch或Solr。
Solr还具有使用Apache Tika从二进制文件提取文本的功能。因此,您可以通过ExtractRequestHandler上传PDF,Solr将知道如何处理它。
另一方面,Elasticsearch与Logstash配合良好,后者可以处理任何来源的数据并为其编制索引。
缩放是一个关键的考虑因素。在这种情况下,当Solr仍然受限于Master-Slave时,Elasticsearch赢得了比赛。但是,SolrCloud最近才进入游戏。在Zookeeper的帮助下,现在可以以更加轻松快捷的方式扩展Solr集群-与具有Master-Slave的旧版本Solr相比,这是一个增强。仍然需要进行大量改进,但是就可以在Solr中摄取和搜索的数据集的大小而言,前途一片光明。
有几家公司不得不决定哪种产品最适合他们。例如,Cloudera选择了Solr作为他们的搜索引擎,以集成到开源CDH(包括Hadoop的Cloudera Distribution)中。另一方面,还有其他供应商选择Elasticsearch作为其解决方案的搜索引擎。Search Technologies的我们将为两个搜索引擎提供咨询,部署和支持。
Solr更加侧重于文本搜索。Elasticsearch迅速树立了自己的利基市场,通过创建Elastic Stack(以前称为ELK Stack)来进行日志分析,Elastic Stack代表Elasticsearch,Logstash,Kibana和Beats。双方都有清晰的愿景,并且正在朝着自己的方向大步前进。
值得重申的一件事是,如何将两个搜索引擎用作许多领先搜索和大数据平台的基础。例如,Elasticsearch是Microsoft Azure搜索的一部分,而Solr已集成到Cloudera Search中。
在性能方面,根据我从许多开发人员那里获得的经验,我们可以说这两个引擎都表现出色。因此,对于大多数用例而言,无论是内部还是外部搜索应用程序,只要开发人员正确设计和配置它们,性能都不会成为问题。
Solr捆绑了Web管理,而Elasticsearch还有其他多个高级插件可用于安全性,警报和监视。此列表展示了Elastic的整个产品系列。
有许多方法可以在Elasticsearch和Solr中可视化数据-您可以构建自定义可视化仪表板,也可以使用搜索引擎的标准可视化功能(可能需要进行一些调整)。但是有一个区别值得一提。
Solr主要专注于文本搜索。它在这方面做得很好,成为了搜索应用程序的标准。但是,Elasticsearch朝着另一个方向发展,它超越了搜索范围,可以通过Elastic Stack解决日志分析和可视化问题。以下是您可以使用Kibana 5进行的一些可视化处理。
这并不意味着一个人胜于另一个。它仅表示每个搜索引擎在不同的用例和需求中都有自己的优势,而您的选择将在很大程度上取决于您的组织要完成的工作。
长话短说,Elasticsearch和Solr都是出色的开源选择,将帮助您从数据中获取更多收益。这完全取决于您的要求,预算,时间安排以及项目的复杂性。