比较Solr和Elasticsearch:主要区别是什么?

两个搜索引擎都在迅速发展，因此，无需多说，以下是关于Elasticsearch和Solr之间差异的最新信息:

7. 切分位置

一般来说，就建立索引和碎片的位置而言，Elasticsearch是非常动态的。当某个动作发生时，它可以在集群周围移动碎片——例如，当一个新节点加入或从集群中删除一个节点时。我们可以通过使用感知标签来控制碎片应该放在哪里和不应该放在哪里，我们还可以告诉Elasticsearch使用API调用按需移动碎片。

Solr往往是更静态的开箱。默认情况下，当Solr节点加入或离开集群时，Solr自己不做任何事情。但是，在Solr 7及以后版本中，我们有了自动排序API:我们现在可以定义整个集群范围的规则和特定于集合的策略来控制分片的位置，我们可以自动添加副本，并告诉Solr根据已定义的规则在集群中使用节点。

8. API

如果您了解Apache Solr或Elasticsearch，您就会知道它们公开了HTTP API。

熟悉Solr的人都知道，为了从它获得搜索结果，需要查询一个已定义的请求处理程序，并传递定义查询条件的参数。根据您选择使用的查询解析器的不同，这些参数将有所不同，但方法仍然是相同的——将一个HTTP GET请求发送给Solr以获取搜索结果。

这样做的好处是您不必局限于单一的响应格式—您可以选择XML格式、JavaBin格式的JSON格式以及其他一些由响应编写器开发的格式来获得结果。因此，您可以选择对您和您的搜索应用程序最方便的格式。当然，Solr API不仅用于查询，因为您还可以获得关于不同搜索组件或控制Solr行为(例如集合创建)的一些统计信息。

那么Elasticsearch呢?Elasticsearch公开了一个可以使用HTTP GET、DELETE、POST和PUT方法访问的REST API。它的API不仅允许查询或删除文档，还允许创建索引、管理它们、控制分析并获得描述Elasticsearch当前状态和配置的所有指标。如果您需要了解有关Elasticsearch的任何信息，您可以通过REST API获得它(我们在Sematext云中也使用它来获取日志和事件)。

如果您习惯了Solr，那么有一件事在一开始可能会让您感到奇怪——Elasticsearch只能以JSON格式响应——例如，它没有XML响应。Elasticsearch和Solr之间的另一个大区别是查询。在Solr中，所有查询参数都是作为URL参数传递的，而在Elasticsearch中查询是JSON表示的。以JSON对象的形式结构化的查询给了一个很大的控制权，可以控制Elasticsearch应该如何理解查询，以及返回什么结果。

9. 缓存

另一个很大的不同是Elasticsearch和Solr的架构。为了不深入讨论这两个产品的缓存是如何工作的，我们只指出它们之间的主要区别。

让我们从什么是分段开始。段是Lucene索引的一部分，由各种文件构建，大部分是不可变的，并且包含数据。当你建立数据索引时，Lucene会生成段，并且可以在段合并的过程中将多个较小的、已经存在的段合并为较大的段。

Solr具有全局cashes，即一个片段的给定类型的单一缓存实例，用于其所有段。当单个段发生更改时，需要使整个缓存失效并刷新。这需要时间和硬件资源。

在Elasticsearch中，缓存是每段的，这意味着如果只有一个段更改，那么只有一小部分缓存的数据需要无效和刷新。我们将很快讨论这种方法的利弊。

10. 分析引擎

Solr非常大，有很多数据分析功能。我们可以从好的、旧的方面开始——第一个实现允许对数据进行切分以理解并了解它。然后是具有类似特性的JSON facet，但速度更快，占用内存更少，最后是基于流的表达式，称为流表达式，它可以组合来自多个来源的数据(如SQL、Solr、facet)，并使用各种表达式(排序、提取、计算重要术语等)对其进行修饰。

Elasticsearch提供了一个强大的聚合引擎，它不仅可以像Solr遗留平面（facet）一样进行一级数据分析但是也可以嵌套数据的分析(例如,计算平均价格为每一个产品类别在每个商店部门),但支持分析聚合结果,导致功能像移动平均计算。最后，虽然还处于实验阶段，但Elasticsearch提供了对矩阵聚合的支持，它可以计算一组字段的统计信息。

11. 全文搜索功能

当然，Solr和Elasticsearch都利用了Lucene接近实时的功能。这使得查询可以在文档被索引后立即匹配文档。

在查看Solr代码库时，与全文搜索相关的特性和接近全文搜索的特性非常丰富。

我们的Solr培训班上就满是这种东西!从广泛的请求解析器选择开始，通过各种建议器实现，到使用拼写检查器纠正用户拼写错误的能力，以及高度可配置的广泛突出显示支持。

Elasticsearch有专门建议案API隐藏了实现细节的用户给我们一个更简单的方法实现建议的成本降低灵活性和当然强调不如强调可配置在Solr(虽然都是基于Lucene高亮显示功能)。

Solr仍然更加面向文本搜索。另一方面，Elasticsearch通常用于过滤和分组(分析查询工作负载)，而不一定用于文本搜索。

Elasticsearch开发人员在Lucene和Elasticsearch级别上都投入了大量精力来提高查询效率(降低内存占用和CPU使用)。

12. DevOps友好

如果你问一个DevOps人员，他喜欢Elasticsearch的哪些方面，答案可能是它的API、可管理性和易于安装。当涉及到故障排除时，Elasticsearch很容易获得关于其状态的信息——从磁盘使用情况信息，通过内存和垃圾收集工作统计数据，到Elasticsearch内部的缓存、缓冲区和线程池使用情况。

Solr还没有到那一步——您可以通过JMX MBean和新的Solr Metrics API从它那里获得一些信息，但这意味着您必须查看一些地方，并不是所有的东西都在那里，尽管它正在到达那里。

13. 非平面数据处理

你有非平面数据，在一个嵌套对象中有很多嵌套对象在另一个嵌套对象中你不想让数据变得扁平，而只是索引你漂亮的MongoDB JSON对象并准备好全文搜索?Elasticsearch将是实现这一目标的完美工具，它支持对象、嵌套文档和父子关系。Solr可能不是最适合这里的，但请记住，在索引XML文档和JSON时，它还支持父-子文档和嵌套文档。此外，还有一件非常重要的事情—Solr支持不同集合内部和跨不同集合的查询时间连接，因此您不受索引时间父-子处理的限制。

14. 查询DSL

我们大声说，Elasticsearch的查询语言真的很棒。如果你喜欢JSON，那就是。它允许您使用JSON构造查询，因此它将具有良好的结构并使您能够控制整个逻辑。您可以混合不同类型的查询来编写非常复杂的匹配逻辑。当然，全文搜索不是一切，你可以包括聚合，结果崩溃等等-基本上你需要从你的数据的一切都可以用查询语言表达。

在Solr 7之前，Solr仍然在使用URI搜索，至少在其最广泛使用的API中是这样。所有参数都进入了URI，这可能导致长且复杂的查询。从Solr 7开始，JSON API部分得到了扩展，现在可以运行结构化查询来更好地表达您的需求。

15. 索引/收集领导人控制

当谈到集群周围的切分位置时，Elasticsearch本质上是动态的，但对于哪些切分将充当主切分，哪些切分将作为副本，我们并没有太多的控制权。这是我们无法控制的。

与Elasticsearch相比，在Solr中，你有这种控制，这是一件很好的事情，当你考虑到在索引期间，领导者做了更多的工作，因为他们把数据转发给所有的副本。通过对leader碎片位置的精确信息，我们能够重新平衡leader碎片的位置，或者明确地指出它们应该放在哪里，这样我们就能够在整个集群中平衡负载。

16. 机器学习

Solr中的机器学习以一种contrib模块的形式免费提供，并建立在流聚合框架之上。通过使用contrib模块中的其他库，您可以在Solr之上使用机器学习的排序模型和特征提取，而基于流聚合的机器学习主要关注使用逻辑回归的文本分类。

另一方面，我们有Elasticsearch和它的X-Pack商业产品，附带一个Kibana插件，支持机器学习算法，专注于异常检测和时间序列数据中的离群点检测。这是一套捆绑了专业服务的不错的工具，但价格相当昂贵。因此，我们对X-Pack进行了拆解，并列出了可用的X-Pack替代品:来自开源工具、商业替代品或云服务。

17. 生态系统

说到生态系统，Solr附带的工具很好，但它们让人感觉很谦虚。我们有一个叫做Banana的Kibana端口，它走自己的路，还有像Apache Zeppelin integration这样的工具，它允许在Apache Solr上运行SQL。当然，还有其他工具可以从Solr读取数据、将数据发送到Solr或使用Solr作为数据源—例如Flume。大多数工具都是由各种爱好者开发和支持的。

相比之下，如果你看看Elasticsearch周围的生态系统，它是非常现代和有序的。你有一个新版本的Kibana，每个月都有新功能出现。如果你不喜欢Kibana，你有Grafana，它现在是一个提供多种功能的产品，你有一长串的数据传送者和工具可以使用Elasticsearch作为数据源。最后，这些产品不仅得到了爱好者的支持，还得到了大型商业实体的支持。

18. 指标

如果你喜欢监控和测量，那么有了Elasticsearch，你将会感觉非常棒。除夕夜，它比你能挤进时代广场的人还要多!Solr提供了关键指标，但远不及Elasticsearch那么多。无论如何，如果您想处理指标和其他操作数据，那么拥有像Sematext Cloud这样全面的监控和集中的日志记录工具是非常必要的，尤其是当它们像这两者一样无缝地协同工作时。

综上所述，以下是Solr和Elasticsearch之间的主要区别:

Lucene呢?

由于Solr和Elasticsearch都基于Apache Lucene，您可能想知道是否使用纯Lucene会更好。可以这样想:Lucene是Linux内核，而Solr或Elasticsearch是Ubuntu。

您可以直接使用内核并在其上构建自己的应用程序。如果您对内核有很好的理解，并且用例比较狭窄，那么这将是您的选择。同样，Lucene是一个用Java编写的搜索引擎库。你可以在它上面写你自己的搜索引擎(用Java)，你可以完全控制Lucene做什么。

就像内核的例子一样，如果你不熟悉Lucene，可能会花费很长时间和大量的试验和错误。但是假设你知道Lucene。如果您有广泛的用例，比如需要使您的搜索引擎分布式，那么您可能最终会得到一个解决方案，它可以完成Solr和Elasticsearch已经完成的工作。

Solr和Elasticsearch都提供了最有用的功能——尽管不是全部!- Lucene功能通过一个REST API。就像Ubuntu对Linux所做的一样，Solr和Elasticsearch在上面添加了它们自己的功能。比如分布式模型、安全性、管理api、复杂分析(方面、流聚合)等等。大多数用例都需要这种功能。

Solr和Elasticsearch给我总结一下:哪个是最好的?

这显然不是Solr和Elasticsearch不同之处的详尽列表，当然也不是要告诉您选择哪一个。我们可以继续写几篇博客文章，然后把它写成一本书，但希望下面的列表能让你知道从其中一篇和另一篇中可以期待什么，这样你就可以根据你的需要来看待它。

总之，以下是我们认为对那些不得不做出选择的人来说影响最大的几点:

• 如果您已经在Solr上投入了大量时间，请坚持使用它，除非有它不能很好地处理的特定用例。如果您认为是这样的话，请与熟悉Solr和Elasticsearch项目的人交谈，以节省您的时间、猜测、研究和避免错误。
  
• 如果您是真正开源的忠实信徒，那么Solr比Elasticsearch更接近于此，由一家公司控制Elasticsearch可能会让您感到厌恶。
  
• 如果您需要一个除了文本搜索之外还能处理分析查询的数据存储，那么Elasticsearch是当前更好的选择，特别是考虑到更大的生态系统的可用性。
  

首席点评：

对于大型企业，优先建议使用Solr,因为Solr是Apache License，并且由开源社区和开源基金会主导，对于商业更友好，潜在的商业风险更小。如果使用ElasticSearch ，存在诸多风险，比如更改License ,新的或者高级的功能只能使用商业版本，闭源，政府出口禁令，或者因为使用量比较大，不得不使用商业版本的话面临很大的财务风险等。

对于中小企业或者创业企业就无所谓了。