Rafal Kuć on January 7, 2021 原文地址
“Solr 或 Elasticsearch？“好吧，至少这是我们从Sematext的咨询服务客户和潜在客户那里听到的常见问题。哪个更好，Solr还是Elasticsearch？哪一个更快？哪一个更好缩放?哪一个更容易管？我们应该用哪一个?从Solr迁移到Elasticsearch有什么优势吗?这样的例子不胜枚举。
这些都是很好的问题，尽管并不总是有明确的、普遍适用的答案。那么我们推荐你用哪一种呢？你最终会如何选择？好了，让我们来分享一下Solr和Elasticsearch的过去、现在和未来，让我们做一些比较，通过总结Solr和Elasticsearch之间最重要的差异，希望能帮助您做出正确的选择，以满足您的特殊需求。
如果您是新的Elasticsearch和Solr，您可能会从阅读我们的 Elasticsearch Tutorial 和 Solr Tutorial 并受益匪浅。
Elasticsearch和Solr是两个领先的、相互竞争的开源搜索引擎，凡是研究过(开源)搜索的人都知道这两个引擎。它们都是围绕核心底层搜索库Lucene构建的，但在可伸缩性、易于部署以及社区存在等功能上有所不同。在处理静态数据时，Solr有更多的优势，因为它有缓存，并且能够使用非反向读取器进行faceting和sorting(例如，电子商务)。另一方面，Elasticsearch更适合并且更频繁地用于时间序列数据用例，比如log analysis 用例。
当谈到选择Solr和Elasticsearch时，它们都有自己的优缺点，所以没有对错之分。虽然Elasticsearch似乎更受欢迎，但根据您的需求和期望，每种搜索都可能更好或更差。
我们希望这两种领先的开源搜索引擎的比较能够提供足够的信息和指导，帮助您为您的组织做出正确的选择:
比较Solr和Elasticsearch:主要区别?
这两种搜索引擎都在迅速发展，所以，这里就简单介绍一下Elasticsearch和Solr之间的最新区别：
1. Apache Solr vs. Elasticsearch引擎性能和可伸缩性
在性能方面，Solr和Elasticsearch大致相同。我们说粗略是因为没有人做过好的、全面的、公正的基准测试。对于95%的用例来说，任何一种选择在性能方面都很好，剩下的5%需要用它们特定的数据和特定的访问模式来测试这两种解决方案。
也就是说，如果您拥有的大多是静态数据，并且需要数据分析的完全精度和惊人的性能，那么您应该考虑Solr。
您还可以观看我们的两位工程师Radu和Rafał在Berlin Buzzwords上发表的《Side by Side with Elasticsearch & Solr Part 2性能和可伸缩性》(或者您可以查看演示幻灯片)演讲。本次演讲包括现场演示、视频演示和幻灯片，深入探讨了Elasticsearch和Solr的规模和性能，这些见解在2015年依然有效。
Radu和Rafal向与会者展示了如何调优Elasticsearch和Solr的两个常用用例:日志记录和产品搜索。然后他们展示调谐后得到的数字。还有一些关于向外扩展大规模Elasticsearch和Solr集群的最佳实践分享;例如，如何将数据划分为用于增长的分片和索引/集合，何时使用路由，以及如何确保协调的节点不会失去响应。
在这个视频中提到的测试中，我们看到Solr在静态数据上非常棒。
更重要的是，与Elasticsearch相比，Solr中的facet是精确的，并且不会失去精度，而Elasticsearch并不总是这样。在某些边缘情况下，您可能会发现Elasticsearch聚合的结果并不精确，这是取决于数据在shard中如何放置。
2.成熟度和搜索趋势 Maturity and Search Trends
[图片上传失败...(image-e9baec-1641452268884)]
Solr并没有死。在DB-Engines中，Elasticsearch和Solr在开发人员社区中都是最受欢迎的。以下是支持这一观点的最新使用统计数据。
Apache Solr是一个成熟的项目，其背后有一个庞大而活跃的开发和用户社区，以及Apache品牌。
Solr于2006年首次发布开源版本，长期以来一直主导着搜索引擎领域，是任何需要搜索功能的人的首选引擎。它的成熟意味着超越普通文本索引和搜索的丰富功能;如 faceting、grouping(字段折叠)、强大的过滤、可插文档处理、可插搜索链组件、语言检测等。
Elasticsearch在2010年左右，作为另一个选择出现在市场上。那时，它还远没有Solr稳定，没有Solr的功能深度，也没有知名度和品牌等等。但它还有其他一些优点:Elasticsearch还很年轻，建立在更现代的原则之上，目标是更现代的用例，它的构建是为了更容易地处理大型索引和高查询率。
此外,因为Elasticsearch是那么年轻,没有一个社区,它在跳跃前进的自由,不需要任何形式的共识或与他人合作(用户或开发人员),向后兼容,或者其他更成熟的软件通常必须处理。因此，它在Solr之前暴露了某些非常受欢迎的功能(例如，接近实时搜索)。
从技术上讲，NRT Search的能力实际上来自于Lucene, Solr和Elasticsearch都使用底层的搜索库。具有讽刺意味的是，因为Elasticsearch首先公开了NRT Search，所以人们将NRT Search与Elasticsearch联系在一起，尽管Solr和Lucene都是同一个Apache项目的一部分，因此，人们会期待Solr首先拥有如此高要求的功能。
Elasticsearch搜索更现代，吸引了一些人群和组织：
- 那些还没有搜索引擎，没有投入大量时间、金钱和精力在它的采用和整合等方面的人。
- 他们必须处理大量数据，需要更容易地分割和复制数据(搜索索引)，并缩小或扩大他们的搜索集群
当然，我们必须承认，总有一些人喜欢跳上新的闪亮的东西。
快进到2021年。Elasticsearch不再是新产品，但它仍然很闪亮。它弥补了与Solr在功能上的差距，在某些情况下甚至超越了Solr。当然，围绕它有更多的议论。在这一点上，两个项目都非常成熟。两者都有很多功能。两者都是稳定的。我们不得不说，尽管我们确实看到更多的Elasticsearch集群存在问题，但我们认为这主要是因为以下几个原因:
- Elasticsearch，传统上更容易开始，使任何人都可以开箱即用，而不需要太多的理解如何工作。这对于开始是很好的，但是当数据/集群增长时就很危险了。
- Elasticsearch，更容易扩展，吸引了需要更多数据和更多节点的更大集群的用例。
- Elasticsearch，更动态的数据，可以在节点来来去去的时候轻松地在集群中移动，这可能会影响集群的稳定性和性能。
- 虽然Solr传统上更倾向于文本搜索，但Elasticsearch也致力于处理分析类型的查询，而这类查询是有代价的。
虽然这听起来有点吓人，但我还是这么说吧，Elasticsearch提供了大量的控制按钮，可以用来控制怪兽。当然，关键的一点是，你必须意识到所有可能的旋钮，知道它们在做什么，并利用它们。例如，尽管您刚刚阅读了关于Elasticsearch的内容，但在我们的组织中，许多不同的产品都依赖于它，即使我们像了解Elasticsearch一样了解Solr。
Solr：不完全黯然失色
Solr呢？Solr并没有完全静止。Elasticsearch的出现实际上对Solr及其开发人员和用户社区非常有利。尽管Solr已经成立了14年多，但它的发展速度却比以往任何时候都要快。它现在也有一个友好的API。它也能够更轻松地增长和收缩集群，更动态地创建索引，动态地对它们进行分片，路由文档和查询，等等。注意:当人们提到SolrCloud时，他们指的是这种非常分布式的、类似elasticsearch的Solr部署。
我们参加了在华盛顿举行的Lucene/Solr革命会议，并惊喜地看到:一个强大的社区，健康的项目，许多大公司不仅使用Solr，而且通过采用它投资，通过开发/工程时间贡献，等等。如果你只关注新闻，你会认为Solr已经死了，所有人都在涌向Elasticsearch。事实并非如此。Elasticsearch是更新的，写起来自然会更有趣。Solr在十多年前是新闻。当然，当Elasticsearch出现时，也有一些人从Solr转向Elasticsearch——一开始，根本没有Elasticsearch用户。
3. 开源&许可 Open source & Licenses
Elasticsearch在开源log management用例中占主导地位，许多组织在Elasticsearch中索引他们的日志，使其可搜索。虽然Solr现在也可以用于此(Solr for Indexing and Searching Logs and Tuning Solr for Logs)，但它在这一点上错过了mindshare这条船。
Elasticsearch和Solr都是在Apache软件许可下发布的，然而，Solr是真正的源代码开源社区。Solr代码并不总是很漂亮，但一旦特性出现了，它通常就会留在那里，不会从代码库中删除。任何人都可以为Solr做出贡献，新的Solr开发人员(也就是提交者)将根据你的优点被选出来，只要你表现出你的兴趣并继续支持这个项目。此外，提交者来自不同的公司，没有单一的公司控制代码库。
另一方面，Elasticsearch在技术上是开源的，但在精神上就不那么重要了。任何人都可以在Github上看到源代码，任何人都可以修改它并提供贡献，但只有Elastic的员工可以对Elasticsearch进行修改，所以你必须成为Elastic公司本身的一员才能成为提交者。
此外，Elasticsearch背后的公司Elastic混合了Apache 2.0软件许可下发布的代码，而代码one只能在商业许可下使用。不用说，Elasticsearch用户社区对此并不满意。AWS在Apache许可下构建了自己的Elasticsearch发行版，并捆绑了许多特性，如警报、安全等。你可以看到Sematext的 review of AWS Open Distribution for Elasticsearch。
许多组织选择Solr而不是Elasticsearch作为他们在搜索竞赛中的一匹马(例如Cloudera、Hortonworks、MapR等)，尽管他们也与Elasticsearch合作。
Community and Developers
Solr和Elasticsearch都有活跃的用户和开发人员社区，并且正在迅速发展。
如果您需要向Solr或Elasticsearch添加某些缺失的功能，那么使用Solr可能会更幸运。确实，古老的Solr JIRA问题仍然存在，但至少它们仍然是开放的，而不是关闭的。在Solr的世界中，社区有更多的发言权，尽管最终必须由Solr的一名开发人员来接受和处理贡献。
这里有几个图表来说明我们的意思
Elasticsearch vs. Solr Contributors
Elasticsearch vs. Solr Commits (source: Open Hub)
可以看到，Elasticsearch的数量呈急剧上升趋势，现在Solr Commit活动增加了一倍多。这不是一个非常精确或绝对正确的比较开源项目的方法，但它给了我们一个想法。例如，Elasticsearch是在Github上开发的，这使得合并其他Pull Requests变得非常容易，而Solr贡献者倾向于创建补丁，并将它们上传到JIRA，在那里，他们会在应用一个较低效的流程之前得到Solr提交者的审查。此外，Elasticsearch存储库包含文档，而不仅仅是代码，而Solr将文档保存在Wiki中。这为Elasticsearch提供了更高的提交和贡献者数量。
4.学习曲线和支持 Learning Curve and Support
Elasticsearch更容易启动，只需一个下载和一个命令就可以启动一切。传统上，Solr需要更多的工作和知识，但Solr最近在消除这一点上取得了很大的进步，现在只需要努力改变自己的声誉。
从操作上讲，Elasticsearch使用起来稍微简单一些——它只有一个进程。Solr采用类似elasticsearch的完全分布式部署模式，即SolrCloud，它依赖于Apache ZooKeeper。ZooKeeper超级成熟，超级广泛使用，等等，但它仍然是另一个感人的部分。也就是说，如果您正在使用Hadoop、HBase、Spark、Kafka或其他一些较新的分布式软件，那么您可能已经在您的组织中的某个地方运行了ZooKeeper。
虽然Elasticsearch有内置的类似ZooKeeper的组件Zen，但ZooKeeper在防止有时在Elasticsearch集群中看到的可怕的大脑分裂问题上做得更好。公平地说，Elasticsearch开发人员已经意识到了这个问题，并在过去的几年里改进了Elasticsearch的这方面。
两者都有良好的商业支持(咨询、生产支持、培训、集成等)。两者都有很好的操作工具，尽管Elasticsearch因为其更易于使用的API吸引了更多的DevOps用户，从而使围绕它的工具生态系统更加活跃。
5.配置 Configuration
让我们快速了解一下Solr和Elasticsearch是如何配置的。让我们从索引结构开始。
在Solr中，您需要managed-schema文件(以前的schema.xml)来定义索引结构，定义字段及其类型。当然，您可以将所有字段定义为动态字段并动态地创建它们，但您仍然至少需要某种程度的索引配置。不过，在大多数情况下，您将创建一个schema.xml来匹配您的数据结构。
Elasticsearch有点不同，它可以称为无模式搜索。你可能会问，这到底意味着什么。简而言之，这意味着可以启动Elasticsearch并开始向它发送文档，以便为它们建立索引，而无需创建任何类型的索引模式，Elasticsearch将尝试猜测字段类型。它并不总是100%准确，至少与手动创建索引映射相比是这样，但它工作得相当好。
当然，您也可以定义索引结构(所谓的映射)，然后使用这些映射创建索引，或者甚至为索引中存在的每种类型创建映射文件，并让Elasticsearch在创建新索引时使用它。听起来很酷，对吧?此外，当在索引的文档中发现一个新的、以前不可见的字段时，Elasticsearch将尝试创建该字段并尝试猜测其类型。可以想象，这种行为是可以关闭的。
让我们稍微讨论一下Solr和Elasticsearch的实际配置。在Solr中，所有组件的配置、搜索处理程序、索引特定的东西，如合并因子或缓冲区、缓存等，都在solrconfig.xml文件中定义。每次更改之后，都需要重新启动Solr节点或重新加载它。
Elasticsearch中的所有配置都会写入elasticsearch.yml文件，它只是另一个配置文件。然而，这并不是存储和更改Elasticsearch设置的唯一方法。Elasticsearch公开的许多设置(尽管不是全部)都可以在活动集群上更改，例如，您可以更改碎片和副本在集群中的放置方式，而且Elasticsearch节点不需要重新启动。在Elasticsearch Shard Placement Control中了解更多。
6.节点发现 Node Discovery
Elasticsearch和Solr的另一个主要区别是节点发现和集群管理。发现的主要目的是监视节点状态、选择主节点，在某些情况下还存储共享的配置文件。
当集群最初形成时，当一个新节点加入时，或者当集群中的某个节点发生了一些不好的事情时，必须基于给定的标准来决定应该做什么。这是所谓的节点发现的职责之一。
Elasticsearch使用自己的发现实现Zen，为了实现完全容错(即不受网络分裂的影响)，建议至少有三个专用主节点。Solr使用Apache ZooKeeper进行发现和leader选举。在这种情况下，建议使用外部ZooKeeper集成，这对于容错和完全可用的SolrCloud集群至少需要三个ZooKeeper实例。
Apache Solr使用不同的方法来处理搜索集群。Solr使用Apache ZooKeeper集成，基本上是一个或多个ZooKeeper实例一起运行。ZooKeeper主要用于存储配置文件和监控，用于跟踪所有节点的状态和整个集群的状态。为了让新节点加入现有集群，Solr需要知道要连接到哪个ZooKeeper集合。
7.分片布置 Shard Placement
一般来说，就索引和构建shard的布置而言，Elasticsearch是动态的。当某个操作发生时，例如当一个新节点加入集群或从集群中删除一个节点时，它可以在集群中移动shard。我们可以通过使用感知标签来控制shard应该放在哪里，不应该放在哪里，我们可以告诉Elasticsearch使用API调用按需移动shard。
Solr更倾向于静态。默认情况下，当一个Solr节点加入或离开集群时，Solr自己不做任何事情。但是，在Solr 7和以后的版本中，我们有了AutoScaling API:我们现在可以定义集群范围的规则和特定于集合的策略来控制分片的位置，我们可以自动添加副本，并告诉Solr根据定义的规则利用集群中的节点。
8.API
如果您了解Apache Solr或Elasticsearch，您就会知道它们公开了HTTP API。
熟悉Solr的人都知道，为了从它获得搜索结果，需要查询一个已定义的请求处理程序，并传入定义查询条件的参数。根据您选择使用的查询解析器的不同，这些参数会有所不同，但方法仍然是相同的，即向Solr发送HTTP GET请求以获取搜索结果。
好的方面是，您可以不受单一响应格式的限制，可以选择XML、JavaBin格式的JSON和其他几种有响应编写器为它们开发的格式来获得结果。因此，您可以选择对您和您的搜索应用程序最方便的格式。当然，Solr API不仅仅是关于查询的，因为您还可以获得关于不同搜索组件的一些统计信息，或者控制Solr行为，例如集合创建。
那么Elasticsearch呢?Elasticsearch公开了一个REST API，可以使用HTTP的GET、DELETE、POST和PUT方法访问它。它的API不仅允许查询或删除文档，还允许创建索引、管理索引、控制分析和获取描述Elasticsearch当前状态和配置的所有指标。如果您需要了解关于Elasticsearch的任何信息，您可以通过REST API获得它(我们在 Sematext Cloud for logs and events中也使用它)。
如果你习惯了Solr，有一件事可能会让你在开始时感到奇怪Elasticsearch只能以JSON格式响应没有XML响应。Elasticsearch和Solr的另一个大区别是查询。在Solr中，所有查询参数都作为URL参数传入，而在Elasticsearch中，查询是用JSON表示的。以JSON对象结构的查询在很大程度上控制了Elasticsearch应该如何理解查询以及返回什么结果。
9.Caches
另一个大的区别是Elasticsearch和Solr的架构。为了不深入了解这两个产品中的缓存是如何工作的，我们只指出它们之间的主要区别。
我们先来看看什么是segment。segment是Lucene索引的一部分，它是由各种文件构建的，大部分是不可变的，并且包含数据。当你索引数据时，Lucene会生成segment，并且在segment合并过程中，还可以将多个较小的、已经存在的segment合并成较大的segment。
Solr有全局cache，对于一个shard的所有segment，会给定类型一个单一缓存实例。当单个segment发生变化时，整个cache需要失效并刷新。这需要时间和硬件资源。
在Elasticsearch中，缓存是每个segment的，这意味着如果只改变了一个segment，那么缓存的数据中只有一小部分需要失效和刷新。我们将很快讨论这种方法的利弊。
10.分析引擎 Analytics Engine
Solr非常大，具有大量的数据分析功能。我们可以从好的、旧的方面开始——第一个实现允许对数据进行切片，以便理解和了解它。然后是具有类似特性的JSON facet，但速度更快，内存要求更低，最后是基于流的表达式，称为streaming expressions ，它可以组合来自多个来源的数据(如SQL, Solr, facet)，并使用各种表达式(排序，提取，计数重要的术语，等等)来修饰它们。
Elasticsearch提供了一个强大的聚合引擎，它不仅可以像大多数Solr遗留方面一样进行一级数据分析，还可以嵌套数据分析(例如，计算每个商店部门的每个产品类别的平均价格)，还支持聚合结果之上的分析。这就产生了移动平均线计算等功能。最后，尽管标记为实验性的，Elasticsearch提供了对矩阵聚合的支持，它可以在一组字段上计算统计信息。
11.全文搜索
当然，Solr和Elasticsearch都利用了Lucene的近实时功能。这使得查询可以在索引完成后立即匹配文档。
在查看Solr代码库时，与全文搜索相关的特性和与全文搜索相近的特性非常丰富。
Solr从广泛选择的请求解析器开始，到各种建议实现，再到使用拼写检查器纠正用户拼写错误的能力，以及高度可配置的广泛高亮显示支持。
Elasticsearch有一个专门的suggesters API，它向用户隐藏了实现细节，为我们提供了一种更简单的方式来实现suggesters，但降低了灵活性，当然高亮显示的可配置性比Solr中高亮显示要低(尽管两者都是基于Lucene的高亮功能)。
Solr仍然更加面向文本搜索。另一方面，Elasticsearch通常用于过滤和分组分析查询工作负载，而不一定是文本搜索。
Elasticsearch开发人员在Lucene和Elasticsearch级别上都投入了大量精力来提高查询效率(降低内存占用和CPU占用)。
12.DevOps Friendliness
如果你问一个DevOps的人他喜欢Elasticsearch什么，答案会是API、可管理性和易于安装。在进行故障排除时，可以很容易地从磁盘使用信息、内存和垃圾收集工作统计信息到Elasticsearch内部(如缓存、缓冲区和线程池利用率)获取关于其状态的信息。
Solr还不存在，您可以通过JMX MBean和新的Solr Metrics API从它获得一些信息，但这意味着有几个地方必须查看，但不是所有的东西都在那里，尽管它正在那里。
13. Non-flat Data Handling
你有non-flat的数据，在一个嵌套的对象和另一个嵌套的对象中有很多嵌套的对象，你不想扁平化数据，但只是索引你漂亮的MongoDB JSON对象，并准备好全文搜索?Elasticsearch将是一个完美的工具，它支持对象、嵌套文档和父子关系。在这里，Solr可能不是最适合的，但请记住，在索引XML文档和JSON时，它也支持父子文档和嵌套文档。此外，Solr支持在不同集合内部和跨不同集合的查询时间连接，因此不受索引时间parent-child处理的限制。
14.Query DSL
让我们大声说出来，Elasticsearch的查询语言真的很棒。如果你喜欢JSON，那就是。它允许您使用JSON构造查询，因此它将具有良好的结构，并使您能够控制整个逻辑。您可以混合使用不同类型的查询来编写非常复杂的匹配逻辑。当然，全文搜索不是万能的，你可以包括聚合，结果折叠等等，基本上你需要的所有数据都可以用查询语言来表达。
直到Solr 7, Solr仍然使用URI搜索，至少在其最广泛使用的API中。所有参数都进入了URI，这可能导致长而复杂的查询。从Solr 7 JSON API部分开始扩展，现在您可以运行结构化查询，更好地表达您的需求。
15.Index/Collection Leader Control
虽然Elasticsearch本质上是动态的，但当涉及到集群周围的分片布局时，它并没有给我们太多的控制权，让我们知道哪些分片将成为主要分片，哪些分片将成为复制分片。这是我们无法控制的。
与Elasticsearch相比，在Solr中，您可以进行这种控制，这是一件非常好的事情，因为在索引期间，前导项要做更多的工作，因为要将数据转发给它们的所有副本。有了重新平衡leader的能力，或者明确地说明它们应该放在哪里，我们就有了在整个集群中平衡负载的完美能力，通过提供关于leader分片应该放在哪里的确切信息。
16.Machine Learning
Solr中的机器学习以贡献模块的形式免费提供，并建立在流聚合框架之上。通过在contrib模块中使用额外的库，您可以使用machine-learned ranking models and feature extraction on top of Solr，而基于流聚合的机器学习专注于使用逻辑回归进行文本分类。
另一方面，我们有Elasticsearch和它的X-Pack商业产品，它附带了Kibana的插件，支持机器学习算法，专注于时间序列数据中的异常检测和离群值检测。这是一个很好的工具包，与专 业服务捆绑在一起，但相当昂贵。因此，我们解压了X-Pack并列出了可用的X-Pack alternatives:来自开源工具、商业替代方案或云服务。
17.生态系统 The Ecosystem
当涉及到生态系统时，Solr自带的工具很好，但它们感觉很谦虚。我们有Kibana移植的Banana，它有自己的方式，还有Apache Zeppelin 集成工具，允许在Apache Solr上运行SQL。当然，还有其他工具，它们既可以从Solr读取数据，也可以将数据发送到Solr，或者使用Solr作为数据源，例如Flume。大多数工具都是由各种各样的爱好者开发和支持的。
相比之下，如果你看看围绕Elasticsearch的生态系统，你会发现它非常现代，而且是有序的。每个月都会有一个新版本的Kibana出现。如果您不喜欢Kibana，那么您可以使用Grafana，它现在本身就是一个产品，提供了各种各样的特性，您还可以使用一长串的数据传送器和工具来使用Elasticsearch作为数据源。最后，这些产品不仅得到了狂热者的支持，还得到了大型商业实体的支持。
18.Metrics
如果您喜欢监视和metrics，那么使用Elasticsearch，您将置身天堂。这个东西比除夕夜在时代广场挤进去的人还多!Solr公开了关键指标，但远不及Elasticsearch。无论如何，如果您想要处理指标和其他可操作数据，那么拥有全面的监控和集中日志工具(如Sematext Cloud)是至关重要的，特别是当它们像这两种工具那样无缝地协同工作时。
总结一下，这些就是我们上面讨论过的Solr和Elasticsearch之间的主要区别
Top Solr vs Elasticsearch Differences
| Feature | Solr/SolrCloud | Elasticsearch |
|---|---|---|
| Community & Developers | Apache Software Foundation and community support | Single commercial entity and its employees |
| Node Discovery | Apache Zookeeper,在大量的项目中已经成熟和经受了考验 | Zen，内置在Elasticsearch本身，需要专门的主节点分裂脑防 |
| Shard Placement | 本质上是静态的，需要手动迁移分片，从Solr 7开始——自动缩放API允许一些动态操作 | Dynamic, shards 可以根据需要移动，取决于集群状态 |
| Caches | 全局的，每次segment更改都会使其无效 | 每个segment，更适合动态更改数据 |
| Analytics Engine | Facets 和 强大的 streaming aggregations | 复杂且高度灵活的 aggregations |
| Optimized Query Execution | 目前没有 | 根据上下文更快的范围查询 |
| Search Speed | 最适合静态数据，因为 caches 和 uninverted reader | 对于快速变化的数据非常好，因为每segment缓存 |
| Analysis Engine Performance | 伟大的静态数据与精确计算 | 结果的准确性取决于数据放置 |
| Full Text Search Features | 基于Lucene的语言分析，多种建议，拼写检查，丰富的高亮显示支持 | 基于Lucene语言分析，单建议API实现，高亮评分 |
| DevOps Friendliness | 还没有完全实现，但即将实现 | 非常好的 APIs |
| Non-flat Data Handling | Nested 文档 和 parent-child 的支持 | 原生支持 nested 和 object 类型 允许无线嵌套 parent-child |
| Query DSL | JSON (limited), XML (limited) or URL parameters | JSON |
| Index/Collection Leader Control | Leader placement control and leader rebalancing possibility to even the load on the nodes | Not possible |
| Machine Learning | Built-in – on top of streaming aggregations focused on logistic regression and learning to rank contrib module | Commercial feature, focused on anomalies and outliers and time-series data |
| Ecosystem | Modest – Banana, Zeppelin with community support | Rich – Kibana, Grafana, with large entities support and big user base |
What about Lucene?
由于Solr和Elasticsearch都是基于Apache Lucene的，您可能会想，使用纯Lucene是否更适合您。可以这样想:Lucene是Linux内核，而Solr或Elasticsearch是Ubuntu内核。
您可以直接使用内核，并在其上构建自己的应用程序。如果您对内核和狭窄的用例有很好的理解，这将是您的选择。同样，当提到Lucene时，Lucene是一个用Java编写的搜索引擎库。你可以在它上面写你自己的搜索引擎(用Java)，你可以完全控制Lucene的功能。
与内核示例一样，如果您不熟悉Lucene，可能需要很长时间和大量的尝试和错误。但是让我们假设你知道Lucene。如果您有一个广泛的用例，例如需要使您的搜索引擎是分布式的，那么您最终可能会得到一个解决方案，它可以完成Solr和Elasticsearch已经完成的工作。
Solr和Elasticsearch都公开了最有用的，但不是全部!通过REST API实现Lucene功能。就像Ubuntu在Linux上做的一样，Solr和Elasticsearch在上面添加了自己的功能。比如分布式模型、安全、管理api、复杂分析(方面、流聚合)等等。大多数用例都需要这种功能。
Apache Solr vs. Elasticsearch。让我来总结一下:哪一个是最好的
这显然不是Solr和Elasticsearch之间区别的详尽列表，当然也不是要告诉您应该选择哪一个。我们可以继续写几篇博客文章，并以此为基础写一本书，但希望下面的列表能让你对其中一种和另一种的期望有所了解，这样你就可以根据自己的需要来看待它。
总之，以下是我们认为对每个人做出选择最重要的几点：
- 如果您已经在Solr上投入了大量时间，那么就坚持使用它，除非有一些具体的用例它不能很好地处理。如果您认为是这种情况，请与与Solr和Elasticsearch项目关系密切的人交谈，以节省您的时间、猜测、研究和避免错误。
- 如果您是真正的开源的忠实信徒，那么Solr比Elasticsearch更接近开源，让一家公司控制Elasticsearch可能会让您感到厌烦。
- 如果您需要一个除了文本搜索之外还能处理分析性查询的数据存储，那么Elasticsearch在今天是一个更好的选择，特别是由于更大的生态系统的可用性。