Elasticsearch详解es

文章目录

• • 概述
  • es架构
  • 为什么要使用ElasticSearch
  • ElasticSearch的优势
  • 使用场景
  • es为什么这么快
  • 倒排索引
  • 如何保证ES和数据库的数据一致性
  • • 监听binlog同步
    • 双写
  • [elasticsearch 是如何实现 master 选举的](#elasticsearch 是如何实现 master 选举的)
  • Elasticsearch与Solr的区别

概述

ES全称是Elastic Search，它是一个建立在全文搜索引擎库Lucene基础上的开源搜索和分析引擎。ES它本身具

有分布式存储、检索速度快的特性。所以，我们经常会用它来实现全文检索的功能。

Elastic官网对ES的定义已经不再是ElasticSearch这一个组件，而是指Elastic Stack生态。

而Elastic Stack主要包括ElasticSearch、Logstash、Kibana，这三个经典组合也称之为ELK。ElasticSearch主

要用来做数据存储、Logstash主要用来做数据采集，Kibana主要用来做数据可视化展示。

因为ES应用更广泛的场景还是ElasticSearch，所以，下面我们给大家分享的ES还是单指ElasticSearch。比如，

网站搜索，日志聚集和检索，这些都可能会涉及到TB级别的数据场景，用ES是一个比较好的选择。

es架构

Elasticsearch 是一个分布式的开源搜索和分析引擎，其架构由多个组件组成，包括节点、索引、分片和副本等。

1. 节点（Node）：节点是 Elasticsearch 集群中的单个服务器实例。每个节点都是一个独立的 Elasticsearch 进程，具有自己的名称和唯一标识符。一个节点可以是主节点（Master Node）或数据节点（Data Node），也可以同时担任两种角色。
2. 集群（Cluster）：集群是由一个或多个节点组成的逻辑组合。所有节点都共享相同的集群名称，通过该名称彼此通信和协调工作。集群中的节点通过相互发现和加入，形成一个统一的搜索和存储环境。
3. 索引（Index）：索引是将数据逻辑上分组的容器。它类似于关系型数据库中的表，但在 Elasticsearch 中并不直接映射到底层文件系统，而是由一个或多个分片组成。
4. 分片（Shard）：分片是索引的子集，每个分片是一个独立的、可被部署在不同节点上的 Lucene 索引。分片允许水平扩展索引，使得 Elasticsearch 可以处理大量数据和高并发请求。
5. 副本（Replica）：副本是分片的复制，用于提高数据的冗余性和可用性。每个分片可以有多个副本，副本分布在不同的节点上，当主分片不可用时，副本可以自动接管服务。
   Elasticsearch 的架构允许通过水平扩展和分布式处理来处理大规模数据和高并发负载。节点之间通过集群协调和通信，实现数据的分布、搜索请求的路由和负载均衡等功能。
   此外，Elasticsearch 还提供了各种功能组件，如查询解析器、分布式文档存储、分布式聚合计算等，以支持全文搜索、实时数据分析和复杂查询等应用场景。
   总结起来，Elasticsearch 的架构由节点、索引、分片和副本等组成，通过分布式计算和数据分片来实现高性能的搜索和分析能力。

为什么要使用ElasticSearch

Elasticsearch 是一个基于 Apache Lucene 的开源搜索引擎，它提供了分布式的全文搜索和分析功能。以下是一些使用 Elasticsearch 的主要原因：

1. 强大的全文搜索和分析能力：Elasticsearch 提供了快速、灵活的全文搜索和分析功能，支持复杂的查询、聚合和过滤，能够有效地处理海量数据。
2. 分布式和高可用性：Elasticsearch 是一个分布式的搜索引擎，能够轻松扩展到多个节点，实现水平扩展和高可用性，同时提供了自动数据复制和故障恢复机制。
3. 实时数据处理：Elasticsearch 支持实时索引和实时搜索，能够快速地处理新加入的数据，并且可以通过各种 API 实时获取搜索结果。
4. 多样化的数据分析功能：Elasticsearch 提供了丰富的聚合功能，可以方便地进行数据统计、分析和可视化。同时，它也擅长处理结构化数据、地理空间数据和时间序列数据。
5. 整合性：Elasticsearch 与许多其他流行的开源工具和框架（如 Logstash、Kibana 等）集成紧密，能够提供完整的日志分析、监控和可视化解决方案。
6. 开源和活跃的社区：Elasticsearch 是一个开源项目，拥有庞大的用户社区和活跃的开发者社区，能够及时获得技术支持和更新。
   综上所述，Elasticsearch 在全文搜索、数据分析和大规模数据处理方面具有显著的优势，适合用于构建复杂的搜索引擎、日志分析系统、监控系统等应用场景。因此，许多组织选择使用 Elasticsearch 来满足其对搜索和分析能力的需求。

ElasticSearch的优势

Elasticsearch 作为一款流行的开源搜索引擎和数据分析引擎，具有许多优势，包括但不限于以下几点：

1. 强大的全文搜索功能：Elasticsearch 提供了高效、灵活和强大的全文搜索能力，支持复杂的查询、多字段搜索、近实时搜索等功能，能够快速准确地检索大规模数据。
2. 分布式架构：Elasticsearch 是基于分布式架构设计的，可以轻松地扩展到多个节点，支持水平扩展和高可用性，可以处理海量数据并保证服务的稳定性和可靠性。
3. 实时数据索引与搜索：Elasticsearch 支持实时数据的索引和搜索，能够快速地将新数据加入到索引中，并且支持实时查询，使用户可以立即获取最新的搜索结果。
4. 多样化的数据分析功能：Elasticsearch 提供了丰富的聚合功能，可以进行数据统计、分析和可视化，支持地理空间数据的处理和时间序列数据的分析，满足了各种数据分析需求。
5. 易用的 RESTful API：Elasticsearch 提供了简单易用的 RESTful API，用户可以通过 HTTP 请求与 Elasticsearch 进行交互，进行索引数据、执行搜索、进行聚合等操作，方便集成到各种应用程序中。
6. 整合性：Elasticsearch 与 Logstash、Kibana 等工具形成 ELK Stack，提供了完整的日志管理、数据分析和可视化解决方案，能够快速构建强大的监控系统和日志分析平台。
7. 活跃的社区支持：Elasticsearch 拥有庞大的用户社区和活跃的开发者社区，提供了丰富的文档、教程和技术支持，用户可以及时获取帮助和解决问题。
   综上所述，Elasticsearch 具有全文搜索、数据分析、分布式架构、实时性、易用性和整合性等多方面的优势，适用于各种场景下的数据搜索和分析需求。

使用场景

Elasticsearch 是一个强大的开源搜索和分析引擎，适用于多种场景和应用。以下是 Elasticsearch 的一些适用场景：

1. 全文搜索：Elasticsearch 提供快速、灵活和准确的全文搜索功能，适用于各种需要搜索大量文本数据的应用，如网站搜索引擎、电子商务平台等。
2. 日志管理：Elasticsearch 可以用于实时索引和搜索大量日志数据，帮助用户快速定位和分析问题，监控系统运行状态等。
3. 指标分析：通过将结构化数据存储在 Elasticsearch 中，可以进行实时的指标分析和数据可视化，帮助企业做出数据驱动的决策。
4. 应用性能监控：利用 Elasticsearch 存储和分析应用程序的性能指标和日志数据，可以实现应用性能监控和故障排查。
5. 安全信息与事件管理（SIEM）：Elasticsearch 被广泛用于构建安全信息与事件管理系统，用于检测安全威胁、分析安全事件和日志等。
6. 实时数据分析：Elasticsearch 可以处理大规模实时数据的索引和查询，支持快速的数据分析和可视化。
7. 内容推荐系统：通过结合 Elasticsearch 的搜索功能和推荐算法，可以构建基于用户喜好的内容推荐系统。
   总的来说，Elasticsearch 在需要处理大量文本数据、实时索引和搜索、复杂查询和数据分析等方面有着广泛的应用场景。如果您有特定的应用场景或需求，欢迎进一步探讨。

es为什么这么快

Elasticsearch 之所以如此快速，主要是因为其基于分布式架构、倒排索引和内存缓存等方面的设计和优化。

1. 分布式架构：Elasticsearch 是基于分布式架构设计的，可以水平扩展以处理大规模数据和高并发请求。数据被分片存储在多个节点上，查询可以并行执行，从而提高了整体性能。 ES扩展性很好，支持通过水平扩展的方式来动态增加节点，从而提升ES的处理性能。能够支持上百台服务 器节点的扩展，并且支持TB级别的结构化数据和非结构化数据
2. 倒排索引：Elasticsearch 使用倒排索引来加速搜索。倒排索引是一种将文档中的每个词映射到包含该词的文档的数据结构。这种索引结构能够快速定位包含特定词语的文档，从而提高搜索效率。
   所谓倒排索引就是通过属性值来确定数据记录位置的索引，从而避免全表扫描的问题。
3. 分词和分析：Elasticsearch 支持灵活的文本分析和分词功能，可以根据不同语言和需求进行文本处理，从而提高搜索的精确度和效率。
4. 近实时搜索：Elasticsearch 提供了近实时的搜索和索引功能，使得数据的变化可以几乎立即反映在搜索结果中，满足了对实时性要求较高的场景。
5. 内存缓存：Elasticsearch 在查询过程中会利用内存缓存来存储频繁访问的数据和查询结果，以加速后续的查询响应速度。
6. 分布式文档存储：Elasticsearch 使用 Lucene 作为底层搜索引擎，能够高效地存储和检索大量文档数据。 ES是基于Lucene开发的一个全文搜索引擎，一方面Lucene是擅长管理大量的索引数据；另外一方面，它会对数据进行分词以后再保存索引。这样，能够去提升数据的检索效率。
7. ES存储数据采用了分片机制。
   8、ES内部提供的数据汇总和索引生命周期管理的功能，更加便于高效地存储和检索数据。
   当然，ES并不是万能，如果使用不恰当，也会带来一些性能瓶颈。不太建议使用复杂的关联查询，这对ES的性能影响非常大。
   另外，还要避免深度分页查询。因为，ES的分页是通过from和size参数来实现，也就是说，在查询的时候，每个分片必须要先构造一个长度为from + size的优先队列，然后回传的网关节点。网关节点再对这些优先队列进行排序，再找到正确的size文档。而当from足够大的情况下，容易造成OOM以及网络传输性能下降的问题。
   综合来看，Elasticsearch 的快速主要得益于其分布式计算、高效的索引结构、灵活的文本分析和内存缓存等多方面的设计和实现。这些优秀的特性使得 Elasticsearch 成为一个在搜索、日志分析和实时数据分析等方面都表现出色的引擎。

倒排索引

传统的我们的检索是通过文章，逐个遍历找到对应关键词的位置。

而倒排索引，是通过分词策略，形成了词和文章的映射关系表，这种词典+映射表即为倒排索引。有了

倒排索引，就能实现 o（1）时间复杂度的效率检索文章了，极大的提高了检索效率。

学术的解答方式：

倒排索引，相反于一篇文章包含了哪些词，它从词出发，记载了这个词在哪些文档中出现过，由两部分

组成------词典和倒排表。

加分项：倒排索引的底层实现是基于：FST（Finite State Transducer）数据结构。

lucene 从 4+版本后开始大量使用的数据结构是 FST。FST 有两个优点：

（1）空间占用小。通过对词典中单词前缀和后缀的重复利用，压缩了存储空间；

（2）查询速度快。O(len(str))的查询时间复杂度。

倒排索引（Inverted Index）是 Elasticsearch 中用于加速搜索的核心数据结构。在传统的索引结构中，我们通过文档ID来查找对应的词语，而倒排索引则是通过词语来查找对应的文档。

倒排索引的基本原理是将文档中的每个词语都映射到包含该词语的文档列表。具体来说，倒排索引由两个主要的部分组成：词项（Term）和倒排列表（Inverted List）。

1. 词项（Term）：词项是文档中的一个词语或者术语，可以是单个单词或者短语。在倒排索引中，每个词项都有一个唯一的标识符（Term ID）。
2. 倒排列表（Inverted List）：倒排列表是一个包含文档ID的有序列表，表示包含特定词项的文档集合。每个词项都有一个对应的倒排列表。倒排列表中的文档ID可以按照不同的排序方式存储，例如升序或者按照文档相关性排序。
   倒排索引的建立过程可以简单概括为以下几个步骤：
3. 文档分词：首先，将待索引的文档进行分词处理，将文本拆分为词项。
4. 词项标准化：对每个词项进行标准化处理，例如转换为小写、去除停用词等。
5. 构建倒排索引：遍历文档集合，对于每个词项，将其映射到包含该词项的文档列表中。如果倒排列表已存在，则将文档ID添加到列表中；否则创建新的倒排列表。
   倒排索引的优势在于它可以快速地定位包含特定词语的文档。当我们进行搜索时，只需要在倒排索引中查找包含搜索词的倒排列表，然后根据倒排列表中的文档ID获取相应的文档内容。这种方式避免了全文扫描，大大加快了搜索的速度。
   Elasticsearch 利用倒排索引来支持全文搜索、关键词匹配和相关性排序等功能。它使用高效的数据结构和算法来管理和查询倒排索引，使得搜索引擎具有出色的性能和可扩展性。

如何保证ES和数据库的数据一致性

无论采取哪种方式，都需要考虑到数据同步的性能、实时性和一致性，并且需要做好错误处理和容错机制，确保即使出现同步失败或者数据丢失的情况，也能够及时恢复和修复。

要保证 Elasticsearch（ES）和数据库之间的数据一致性，可以采取以下一些方法：

1. 实时同步：通过监听数据库的变更事件（如增删改操作），并将变更实时同步到 Elasticsearch 中。这可以通过编写自定义的同步程序或使用数据同步工具来实现。
2. 定时全量同步：定期对数据库中的数据进行全量同步到 Elasticsearch，确保Elasticsearch中的数据与数据库中的数据保持一致。这种方式适合于数据量较小或者对实时性要求不是非常高的场景。
3. 使用消息队列：在数据库数据发生变化时，将变更事件发送到消息队列，再通过消费者将变更同步到 Elasticsearch。这种方式可以实现异步处理，降低对数据库性能的影响。
4. 双写模式：在应用层面同时对数据库和 Elasticsearch 进行写入操作，确保数据同时写入两个存储中，以保证数据一致性。这种方式需要确保写入操作的原子性和可靠性。
5. 使用事务消息：如果数据库支持事务消息，可以利用事务消息机制将数据库操作和 Elasticsearch 操作放在一个事务中，保证它们的一致性。
6. 采用数据变更触发器：在数据库中设置数据变更触发器，当数据发生变化时触发对应的操作，使得 Elasticsearch 中的数据可以及时更新。

监听binlog同步

监听数据库的 binlog（二进制日志）变更是一种常见且高效的方式，用于实现数据库和 Elasticsearch 之间的数据同步。通过监听数据库的 binlog，可以捕获数据库中的增删改操作，并将这些操作实时同步到 Elasticsearch 中，从而保持数据的一致性。

以下是一般步骤：

1. 开启数据库的 binlog 日志功能：确保数据库中的 binlog 功能已经开启，以便记录数据库中的增删改操作。
2. 编写监听程序：编写一个监听程序，连接至数据库并实时监控数据库的 binlog 变化。可以使用开源工具如 Canal、Debezium 等来简化监听 binlog 的操作。
3. 解析 binlog 数据：监听程序捕获到 binlog 数据后，需要对其进行解析，提取出数据变更的类型、表名、字段值等信息。
4. 同步到 Elasticsearch：根据解析出的数据变更信息，将数据同步到 Elasticsearch 中相应的索引中。可以通过 Elasticsearch 的 API 实现数据的写入和更新操作。
5. 处理异常情况：在同步过程中可能会遇到网络故障、数据格式不匹配等异常情况，需要编写相应的异常处理机制，确保同步能够稳定运行。
6. 监控和日志：建立监控系统，实时监测同步状态和性能指标，同时记录同步过程中的日志，方便排查问题和进行优化调整。

通过监听数据库的 binlog 实现数据同步，可以实现较为实时的数据更新，减少了数据同步的时间延迟。但需要注意的是，binlog 同步也会对数据库的性能产生一定影响，因此在实际应用中需要综合考虑数据一致性、性能和实时性等因素。

双写

双写是一种常见的数据同步策略，即在应用层面同时对数据库和 Elasticsearch 进行写入操作，以确保数据同时写入两个存储中，从而保证数据的一致性。这种方式可以有效避免数据同步延迟和错误，确保数据在数据库和 Elasticsearch 中的一致性。

下面是一般实现双写的步骤：

1. 应用层编程：在应用程序中编写相应的逻辑，在进行数据写入操作时，同时向数据库和 Elasticsearch 执行写入操作。
2. 事务管理：如果支持事务操作的数据库，可以将数据库写入操作和 Elasticsearch 写入操作放在同一个事务中，确保它们要么同时成功，要么同时失败，从而保证数据的一致性。
3. 错误处理：在双写过程中，需要考虑错误处理机制，例如处理写入失败的情况，进行重试或者回滚操作，以确保数据不会出现不一致的情况。
4. 性能优化：双写会增加系统的写入负载，因此需要结合实际情况进行性能优化，例如批量写入、异步写入等方式来提高写入效率。
5. 监控与日志：建立监控系统，实时监测双写操作的状态和性能指标，记录双写过程中的日志，便于排查问题和进行优化调整。
   尽管双写能够保证数据的一致性，但也需要注意双写可能会增加系统复杂度和维护成本。在使用双写策略时，需权衡考虑系统的性能需求、数据一致性要求以及开发成本等因素，选择适合自身业务场景的数据同步方案。

elasticsearch 是如何实现 master 选举的

前置前提：

1）只有候选主节点（master：true）的节点才能成为主节点。

2）最小主节点数（min_master_nodes）的目的是防止脑裂。

核对了一下代码，核心入口为 findMaster，选择主节点成功返回对应 Master，否则返回 null。选举流

程大致描述如下：

第一步：确认候选主节点数达标，elasticsearch.yml 设置的值

discovery.zen.minimum_master_nodes；

第二步：比较：先判定是否具备 master 资格，具备候选主节点资格的优先返回； 若两节点都为候选主节点，则 id 小的值会主节点。注意这里的 id 为 string 类型。

题外话：获取节点 id 的方法

1GET /_cat/nodes?v&h=ip,port,heapPercent,heapMax,id,name

2ip port heapPercent heapMax id name复制代码

Elasticsearch 是一个分布式系统，其中的节点可以分为主节点（master-eligible node）和数据节点（data node）。在 Elasticsearch 中，Master 节点负责集群管理的任务，如索引的创建和删除、集群状态的监控等。当一个 Elasticsearch 集群中的 Master 节点失效或需要选举新的 Master 节点时，集群会进行 Master 选举来选择新的 Master 节点。

以下是 Elasticsearch 实现 Master 选举的一般过程：

1. 节点角色判断：在 Elasticsearch 集群中，每个节点都有一个配置参数来标识自己是否是 Master-eligible 节点。只有 Master-eligible 节点才有资格成为主节点。
2. Master 节点失效检测：当当前的 Master 节点失效或无法与其他节点通信时，集群中的其他 Master-eligible 节点会开始竞选新的 Master 节点。
3. 选举过程：Elasticsearch 使用基于 Zen Discovery 协议的节点发现机制，通过多播和单播来进行节点间的通信和协调。在进行 Master 选举时，节点会相互通信，比较各自的节点信息和集群状态，最终选举出新的 Master 节点。
4. 节点权重判断：在进行 Master 选举时，每个节点都有一个权重值，用于帮助集群选择最适合的 Master 节点。通常情况下，节点的权重值受到节点硬件配置、性能等因素的影响。
5. 选举结果确认：选举出新的 Master 节点后，集群中的所有节点会更新自己的集群状态，并将新的 Master 节点信息广播给其他节点，确保集群中所有节点都知道新的 Master 节点身份。
   通过以上步骤，Elasticsearch 集群可以在 Master 节点失效或需要选举新的 Master 节点时，通过节点间的通信和协调来完成 Master 选举，确保集群的稳定运行和高可用性。

Elasticsearch与Solr的区别

比较类目 solr Elasticsearch

诞生时间 2004 2010

搜索基础 Lucene搜索

实时建立索引 solr会产生io阻塞，效率低 不阻塞，效率高

不断动态添加数据 检索效率变低 变化不大

自身系统管理 利用zookeeper进行分布式管理 自身带有分布式系统管理功能

部署 一般都要部署到web服务器上，如tomcat。启动tomcat的时候需要配置tomcat与solr的关联 自带运行功能，下载安装包直接安装就行

功用范围 官网提供的功能 更专注核心搜索，其它依赖第三方插件

支持索引方式 HTML、PDF、微软 Office 系列软件格式以及 JSON、XML、CSV 等纯文本格式 仅支持json文件格式

社区和开发者 apache 软件基金和社区支持 单一商业实体及其员工

节点发现 Apache Zookeeper ,在大师项目中成熟且经过实战测试 Zen内置于ES本身，需要专用的主节点才能进行分裂脑保护

高速缓存 全局，每个段更改无效 每段，更适合动态更改数据

分析引挚性能 非常适合精确计算的静态数据 结果的准确性取决于数据放置

全文搜索功能 基于lucene语文分析，多建议，拼写检查，丰富的高亮显示支持 基于Lucene语文分析，单一建议API实现

DevOps支持 尚未完全，还在完善中。。 非常好的API

机器学习 内置-在流聚合之上，专注于逻辑回归和学习排名贡献模块 商业功能，专注于异常和异常值以及时间序列数据

【搜素引擎】

Solr的优缺点

优点

Solr有一个更大、更成熟的用户、开发和贡献者社区。

支持添加多种格式的索引，如：HTML、PDF、微软 Office 系列软件格式以及 JSON、XML、CSV 等纯文本格式。

Solr比较成熟、稳定。不考虑建索引的同时进行搜索，速度更快

当单纯的对已有数据进行搜索时，Solr更快。

当实时建立索引时, Solr会产生io阻塞，查询性能较差, Elasticsearch具有明显的优势

随着数据量的增加，Solr的搜索效率会变得更低，而Elasticsearch却没有明显的变化。

二者安装都很简单；

Solr 利用 Zookeeper 进行分布式管理，而 Elasticsearch 自身带有分布式协调管理功能;

Solr 支持更多格式的数据，而 Elasticsearch 仅支持json文件格式；

Solr 官方提供的功能更多，而 Elasticsearch 本身更注重于核心功能，高级功能多有第三方插件提供；

Solr 在传统的搜索应用中表现好于 Elasticsearch，但在处理实时搜索应用时效率明显低于 Elasticsearch。

Solr 是传统搜索应用的有力解决方案，但 Elasticsearch 更适用于新兴的实时搜索应用

Elasticsearch使用Lucene作为内部引擎，但是在使用它做全文搜索时，只需要使用统一开发好的API即可，而不需要了解其背后复杂的Lucene的运行原理。当然Elasticsearch并不仅仅是Lucene这么简单，它不但包括了全文搜索功能，还可以进行以下工作:分布式实时文件存储，并将每一个字段都编入索引，使其可以被搜索。实时分析的分布式搜索引擎。可以扩展到上百台服务器，处理PB级别的结构化或非结构化数据。

Elasticsearch的优缺点**:

优点：Elasticsearch是分布式的。不需要其他组件，分发是实时的，被叫做"Push replication"。Elasticsearch 完全支持 Apache Lucene 的接近实时的搜索。处理多租户（multitenancy）不需要特殊配置，而Solr则需要更多的高级设置。Elasticsearch 采用 Gateway 的概念，使得完备份更加简单。各节点组成对等的网络结构，某些节点出现故障时会自动分配其他节点代替其进行工作。

缺点只有一名开发者（当前Elasticsearch GitHub组织已经不只如此，已经有了相当活跃的维护者）还不够自动（不适合当前新的Index Warmup API）Solr（读作"solar"）是Apache Lucene项目的开源企业搜索平台。其主要功能包括全文检索、命中标示、分面搜索、动态聚类、数据库集成，以及富文本（如Word、PDF）的处理。

Solr是高度可扩展的，并提供了分布式搜索和索引复制。Solr是最流行的企业级搜索引擎，Solr4 还增加了NoSQL支持。Solr是用Java编写、运行在Servlet容器（如 Apache Tomcat 或Jetty）的一个独立的全文搜索服务器。 Solr采用了 Lucene Java 搜索库为核心的全文索引和搜索，并具有类似REST的HTTP/XML和JSON的API。Solr强大的外部配置功能使得无需进行Java编码，便可对 其进行调整以适应多种类型的应用程序。

Solr有一个插件架构，以支持更多的高级定制。因为2010年 Apache Lucene 和 Apache Solr 项目合并，两个项目是由同一个Apache软件基金会开发团队制作实现的。提到技术或产品时，Lucene/Solr或Solr/Lucene是一样的。优点Solr有一个更大、更成熟的用户、开发和贡献者社区。支持添加多种格式的索引，如：HTML、PDF、微软 Office 系列软件格式以及 JSON、XML、CSV 等纯文本格式。Solr比较成熟、稳定。不考虑建索引的同时进行搜索，速度更快。缺点建立索引时，搜索效率下降，实时索引搜索效率不高。当单纯的对已有数据进行搜索时，Solr更快。当实时建立索引时, Solr会产生io阻塞，查询性能较差, Elasticsearch具有明显的优势。随着数据量的增加，Solr的搜索效率会变得更低，而Elasticsearch却没有明显的变化。综上所述，Solr的架构不适合实时搜索的应用。实际生产环境测试下图为将搜索引擎从Solr转到Elasticsearch以后的平均查询速度有了50倍的提升。
Elasticsearch 与 Solr 的比较总结二者安装都很简单；Solr 利用 Zookeeper 进行分布式管理，而 Elasticsearch 自身带有分布式协调管理功能;
Solr 支持更多格式的数据，而 Elasticsearch 仅支持json文件格式；
Solr 官方提供的功能更多，而 Elasticsearch 本身更注重于核心功能，高级功能多有第三方插件提供；Solr 在传统的搜索应用中表现好于 Elasticsearch，但在处理实时搜索应用时效率明显低于 Elasticsearch。
Solr 是传统搜索应用的有力解决方案，但 Elasticsearch 更适用于新兴的实时搜索应用。
其他基于Lucene的开源搜索引擎解决方案直接使用 Lucene说明：Lucene 是一个 JAVA 搜索类库，它本身并不是一个完整的解决方案，需要额外的开发工作。优点：成熟的解决方案，有很多的成功案例。apache 顶级项目，正在持续快速的进步。庞大而活跃的开发社区，大量的开发人员。它只是一个类库，有足够的定制和优化空间：经过简单定制，就可以满足绝大部分常见的需求；经过优化，可以支持 10亿+ 量级的搜索。缺点：需要额外的开发工作。所有的扩展，分布式，可靠性等都需要自己实现；非实时，从建索引到可以搜索中间有一个时间延迟，而当前的"近实时"(Lucene Near Real Time search)搜索方案的可扩展性有待进一步完善