他们为甚么在这儿？我存在的目的是甚么？我如果运动却是休息并节约能量？清早下班或杉轩并彻夜组织工作？我如果将薯条和调料或鸡肉一起吃吗？

那些都是有名的痛点，可能将有也可能将没有标准答案。当中许多是十分困难或十分直觉的。但是，让我牺牲许多努力来试著回答当中之一：我如果使用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是在浏览器中使用的理想优先选择。

Java API和REST

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都是出色的对外开放源码优先选择，将帮助您从数据中以获取更多收益。 这完全依赖于您的明确要求，预算，时间安排以及项目的复杂性。