深入 Elasticsearch（17）：两种搜索引擎的设计选择
上一篇解决了生产运维——分层监控、扩缩容和故障排查。这篇作为系列收尾，回答一个经常被问到的问题：为什么选 Elasticsearch 而不是 Solr（或反过来）。
Elasticsearch 和 Solr 都基于 Apache Lucene。核心搜索能力——倒排索引、BM25 打分、文本分析——本质上相同，因为它们共享同一个底层引擎。差异在于分布式架构、配置哲学、生态绑定和许可协议这些"Lucene 之上"的设计选择。
本文不下"谁更好"的结论，而是给出一个选择框架。
共同基础：Apache Lucene
两者都基于 Lucene 构建。以下能力在两者中本质相同：
- 倒排索引（FST + Posting List）
- BM25 打分
- Analyzer（Character Filter → Tokenizer → Token Filter）
- Doc Values（列式存储，用于排序/聚合）
- BKD-tree（数值和地理范围查询）
- Segment 不可变 + 后台 merge
理解了 Lucene（本系列第 02 篇），两个搜索引擎的搜索能力就理解了大半。差异在于 Lucene 之上的封装。
差异一：分布式架构
| 维度 | Elasticsearch | Apache Solr |
|---|---|---|
| 分布式模式 | 原生内置 | SolrCloud 模式（依赖 ZooKeeper） |
| 协调机制 | 自选举 master（类 Raft，≥7.x） | ZooKeeper 外部协调 |
| 配置存储 | Cluster state（master 管理） | ZooKeeper ZNode |
| Shard 路由 | 内置哈希路由 | 内置哈希路由 |
| 运维依赖 | 只需 ES 节点 | 需要独立 ZooKeeper 集群 |
ES 的分布式能力是从第一天开始设计的。集群发现、master 选举、shard 分配、replica 同步都是内置功能。
Solr 的分布式能力通过 SolrCloud 模式实现，依赖外部 ZooKeeper 集群做协调。这意味着运维 Solr 集群需要同时运维 ZooKeeper 集群。对已有 ZooKeeper 基础设施的团队来说这不是问题，对从零搭建的团队来说是额外的运维负担。
两者的架构差异集中在协调层——ES 自治，Solr 外挂：
graph TB
subgraph ES["Elasticsearch 集群"]
EM[Master 节点<br/>自选举 / cluster state] --> ED1[Data 节点 1]
EM --> ED2[Data 节点 2]
EM --> ED3[Data 节点 3]
end
subgraph Solr["SolrCloud 集群"]
ZK[ZooKeeper 集群<br/>外部协调 / 配置存储] --> SD1[Solr 节点 1]
ZK --> SD2[Solr 节点 2]
ZK --> SD3[Solr 节点 3]
end
style EM fill:#4a90d9,color:#fff
style ZK fill:#e6a23c,color:#fffES 的运维依赖只有 ES 节点本身；Solr 集群必须同时保证 ZooKeeper 集群的可用性。
差异二：配置哲学
| 维度 | Elasticsearch | Apache Solr |
|---|---|---|
| API 风格 | RESTful JSON | RESTful（混合 XML/JSON） |
| Schema 定义 | Mapping（JSON，支持 dynamic） | schema.xml / managed-schema（XML） |
| 默认行为 | Convention over configuration | 显式配置 |
| 配置变更 | REST API 动态修改 | 需修改配置文件或用 Config API |
ES 倾向于"合理的默认值"——创建 index 不需要预定义 mapping，dynamic mapping 自动推断字段类型。这降低了入门门槛，但也带来了动态推断的类型陷阱（前面第 03 篇讨论过）。
Solr 倾向于"显式配置"——schema 需要预先定义，字段类型需要显式声明。这在大型项目中提供了更好的可控性，但入门门槛更高。
差异三：实时性
| 维度 | Elasticsearch | Apache Solr |
|---|---|---|
| 近实时搜索 | refresh_interval 默认 1 秒 | soft commit + hard commit |
| 可见性模型 | Refresh 生成新 segment | Soft commit 打开新 searcher |
| 持久化模型 | Translog + Flush | Transaction log + Hard commit |
两者的 NRT（near-real-time）机制在概念上相似——都是先写入内存，定期生成新的可搜索 segment。ES 默认 1 秒 refresh，Solr 的 soft commit 间隔需要手动配置。
差异四：聚合与分析
| 维度 | Elasticsearch | Apache Solr |
|---|---|---|
| 聚合框架 | Aggregation（bucket/metric/pipeline） | Facet + JSON Facet API |
| 嵌套聚合 | 原生支持多层嵌套 | JSON Facet API 支持嵌套 |
| 近似聚合 | cardinality (HLL++), percentiles (t-digest) | 有限 |
| Pipeline 聚合 | 支持（derivative, moving_avg 等） | 不支持 |
ES 的 Aggregation 框架在灵活性和功能丰富度上领先。Solr 的传统 Facet 功能较基础，JSON Facet API 改善了这一点但仍不及 ES。
差异五：生态系统
| 维度 | Elasticsearch | Apache Solr |
|---|---|---|
| 日志分析 | ELK Stack（Logstash + Kibana + Beats） | 无内置日志生态 |
| 可视化 | Kibana（官方） | Banana（社区，活跃度低） |
| 数据采集 | Beats, Logstash, Elastic Agent | DIH (Data Import Handler) |
| APM / 可观测性 | Elastic APM, Observability suite | 无 |
| 机器学习 | ML 节点（Platinum license） | 无内置 |
| 向量搜索 | kNN search, ELSER | 有限支持 |
ELK Stack 是 ES 在日志分析和可观测性领域占据主导地位的关键原因。Kibana 的可视化和仪表盘能力远超 Solr 生态的替代品。
差异六：License
这是一个有深远影响的差异：
| 版本/分支 | License |
|---|---|
| Elasticsearch < 7.11 | Apache License 2.0 |
| Elasticsearch ≥ 7.11 | SSPL + Elastic License（双许可） |
| Apache Solr | Apache License 2.0 |
| OpenSearch（AWS fork） | Apache License 2.0 |
2021 年 Elastic 将 Elasticsearch 和 Kibana 的许可从 Apache 2.0 改为 SSPL（Server Side Public License）+ Elastic License 双许可。SSPL 要求任何以 SaaS 方式提供 Elasticsearch 服务的厂商必须开源其整个服务栈。
这一变更直接导致 AWS fork 出 OpenSearch（基于 ES 7.10），保持 Apache 2.0 许可。
对最终用户的影响：
- 自建部署：Elastic License 允许免费使用，不受 SSPL 限制。
- 作为 SaaS 提供给第三方：需要评估 SSPL 的约束。
- 需要纯 Apache 2.0 许可：考虑 OpenSearch 或 Solr。
选择框架
不是"谁更好"，而是"哪个更适合"。按项目的核心需求走决策路径：
flowchart TD
Q1{核心需求?} -->|日志/可观测性| ES1[Elasticsearch<br/>ELK 生态成熟]
Q1 -->|全文搜索| Q2{License 约束?}
Q1 -->|复杂聚合分析| ES2[Elasticsearch<br/>Aggregation 框架强]
Q2 -->|必须 Apache 2.0| Q3{已有 ZK 集群?}
Q2 -->|无限制| Q4{团队规模?}
Q3 -->|是| Solr1[Solr<br/>复用 ZK 基础设施]
Q3 -->|否| OS[OpenSearch<br/>Apache 2.0 + 原生分布式]
Q4 -->|小团队/快速上手| ES3[Elasticsearch<br/>约定优于配置]
Q4 -->|大团队/需要显式控制| Either[两者都行<br/>按团队技术栈选]
style ES1 fill:#4a90d9,color:#fff
style ES2 fill:#4a90d9,color:#fff
style ES3 fill:#4a90d9,color:#fff
style Solr1 fill:#50b86c,color:#fff
style OS fill:#e6a23c,color:#fff下表展开各场景的对比：
| 场景 | 倾向 | 原因 |
|---|---|---|
| 日志分析 / 可观测性 | ES | ELK 生态成熟，开箱即用 |
| 传统企业搜索（电商、CMS） | 两者都行 | 搜索核心能力相当 |
| 已有 ZooKeeper 基础设施 | Solr 可能更自然 | 复用现有协调层 |
| 需要复杂聚合分析 | ES | Aggregation 框架更强 |
| 需要 Apache 2.0 许可 | Solr 或 OpenSearch | ES 已非 Apache 2.0 |
| 小团队快速上手 | ES | 默认配置合理，API 友好 |
| 向量搜索 / RAG 集成 | ES | kNN search + ELSER |
| 深度定制搜索排序 | 两者都行 | 都基于 Lucene Similarity |
其他搜索引擎
除了 ES 和 Solr，还有几个值得了解的搜索引擎：
| 搜索引擎 | 定位 | 底层 | License |
|---|---|---|---|
| OpenSearch | ES 7.10 的 Apache 2.0 fork | Lucene | Apache 2.0 |
| Meilisearch | 轻量级即时搜索 | 自研（Rust） | MIT |
| Typesense | 轻量级搜索，API 优先 | 自研（C++） | GPL-3.0 |
| Zinc | ES 兼容的轻量替代 | Bluge（Go） | Apache 2.0 |
| Manticore Search | Sphinx 的 fork | 自研（C++） | GPL-2.0 |
这些引擎在特定场景有各自的优势（如 Meilisearch 的毫秒级 typo-tolerant 搜索、Typesense 的简单部署），但在功能丰富度和生态成熟度上距离 ES 和 Solr 有差距。
模式提炼：搜索引擎的三个设计轴
1 | |
工程迁移表
| 维度 | Elasticsearch | Solr | OpenSearch | Meilisearch | Typesense |
|---|---|---|---|---|---|
| 底层引擎 | Lucene | Lucene | Lucene | 自研 (Rust) | 自研 (C++) |
| 分布式 | 原生内置 | SolrCloud + ZK | 原生内置 | 无（单节点） | 内置 Raft |
| API | JSON REST | XML/JSON REST | JSON REST (ES 兼容) | JSON REST | JSON REST |
| 聚合 | Aggregation 框架 | Facet + JSON Facet | Aggregation（同 ES） | 有限 facet | 有限 facet |
| 生态 | ELK Stack | DIH, Banana | OpenSearch Dashboards | 轻量独立 | 轻量独立 |
| License | SSPL + Elastic | Apache 2.0 | Apache 2.0 | MIT | GPL-3.0 |
常见误解
误解一：ES 比 Solr 搜索更快。 两者底层都是 Lucene，核心搜索性能相当。性能差异更多来自配置调优而不是引擎本身。
误解二：Solr 已经过时了。 Solr 仍在积极开发，有活跃的 Apache 社区。在传统企业搜索领域（图书馆系统、CMS、电商目录搜索）有大量成熟部署。
误解三：OpenSearch 和 ES 完全兼容。 OpenSearch 从 ES 7.10 fork，之后独立发展。两者的 API 在基本操作上兼容，但新特性和高级功能已经分化。
系列回顾
本系列从倒排索引出发，用 18 篇文章逐层展开了 Elasticsearch 的核心机制：
1 | |
贯穿系列的主线是：Elasticsearch 是一个以倒排索引为核心数据结构的分布式搜索与分析引擎。mapping、analysis、shard、replica、aggregation 五个机制围绕这个数据结构逐层展开。理解了这个结构，就能把 ES 的各种行为和配置归因到对应的层次上。
系列导航
| 上一篇 | 下一篇 |
|---|---|
| 生产运维：集群扩缩、监控指标与故障排查 | —（系列完结） |
参考资料
- Elasticsearch 官方文档
- Apache Solr 官方文档
- OpenSearch 官方文档
- Elastic License 2.0 FAQ
- Clinton Gormley, Zachary Tong. Elasticsearch: The Definitive Guide. O’Reilly.
- Doug Turnbull, John Berryman. Relevant Search. Manning, 2016.
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2026-06-26
深入 Elasticsearch（10）：数据分布的核心机制
上一篇解决了聚合分析框架——Bucket、Metric、Pipeline 三层聚合在搜索结果上提供实时分析。这一篇进入数据怎样分布到多个 shard 上。 ES 把一个 index 的数据分成多个 shard，分布到不同的节点上。分片的核心是路由公式——决定一条文档应该落在哪个 shard 上。这个公式看起来简单，但它的分母不可变这一约束影响了 ES 的整个容量规划思路。 本文只抓一个问题：分片路由公式怎样工作，以及分片数不可变的约束从何而来。 路由公式 1shard_num = hash(_routing) % number_of_primary_shards 默认情况下 _routing 等于文档的 _id。这个公式把文档 ID 的哈希值对 primary shard 数取模，得到目标 shard 编号。 5 条文档经过这个公式分配到 3 个 shard 的过程： graph LR D1["doc _id=1"] --> H["hash(_id) % 3"] D2["doc _id=2"] -...
2026-06-26
深入 Elasticsearch（08）：从 match 到 bool 的查询体系
上一篇解决了分数怎么算出来的——BM25 的三个因子决定了文档的相关性排序。这一篇进入 Query DSL 的查询类型体系和组合逻辑。 ES 的查询体系不是一个扁平的 API 列表。全文查询、精确查询、模糊查询、地理查询、复合查询分别对应不同的底层数据结构和匹配逻辑。理解这个分类，才能在具体场景中选对查询类型。 本文抓两个问题：ES 的查询类型怎样分类，以及 bool 查询怎样把不同类型的查询组合起来。 查询体系全景 123456789101112131415161718192021222324252627282930313233ES 查询体系├── 全文查询（走 analyzer，参与打分）│ ├── match 分词后多词项匹配│ ├── match_phrase 分词后要求位置相邻│ ├── multi_match 跨多个字段的 match│ └── match_phrase_prefix 短语前缀（输入补全）│├── 精确查询（不走 analyzer，通常用于 filter context）│ ...
2026-06-26
深入 Elasticsearch（14）：搜索延迟、写入吞吐与调优思路
上一篇解决了 segment 和索引的生命周期管理——merge 控制 segment 数量，ILM 管理索引的存储分层。这一篇进入 ES 的性能瓶颈在哪里、调优的思维框架是什么。 性能调优不是背参数表。参数是工具，瓶颈定位才是方法。ES 的性能受搜索延迟和写入吞吐两个维度的独立因素影响，先确定瓶颈在哪个维度的哪个因素上，再针对性调整。 本文只抓一个问题：ES 的性能模型——搜索延迟和写入吞吐分别受什么因素影响，用什么工具定位瓶颈。 搜索延迟的关键因素 1搜索延迟 = f(segment数, query复杂度, shard数, cache命中率, 数据结构选择) 因素 影响机制 观察方式 Segment 数量 每个 segment 独立搜索，结果合并 _segments API Query 复杂度 深层嵌套 bool、wildcard、regexp 代价高 _search?profile=true Shard 数量 scatter-gather 开销随 shard 数线性增长 _cat/shards Filesystem cache Lucene 文件...
2026-06-26
深入 Elasticsearch（01）：Node、Cluster 与集群状态
上一篇解决了 ES 的核心数据结构是什么——倒排索引。这一篇进入 ES 的运行时架构。 一个 Elasticsearch 集群不是若干台机器简单地连在一起。集群内部有明确的角色分工、中心化的状态管理和分布式的数据路径。理解这些，才能在后续文章中准确地定位每个机制发生在哪一层。 本文只抓一个问题：一个 ES 集群由哪些角色的节点组成，它们之间通过什么机制协调。 节点角色 一个 Elasticsearch 进程启动后就是一个节点（node）。多个节点通过相同的 cluster.name 组成一个集群（cluster）。每个节点可以承担一个或多个角色，角色通过配置文件或启动参数指定。 ES 8.x 中的主要节点角色： 角色 配置值 职责 Master-eligible master 参与 master 选举，管理集群状态 Data data 存储数据分片，执行搜索和聚合 Data Content data_content 存储非时序数据 Data Hot/Warm/Cold/Frozen data_hot 等 分层存储（ILM 相关） Ingest in...
2026-06-26
深入 Elasticsearch（13）：Segment Merge 与 Index Lifecycle Management
上一篇解决了集群协调——master 选举和 cluster state 同步。这一篇进入 segment 随时间增长后怎样管理。 第 02 篇介绍了 segment 是不可变的，写入产生新 segment。随着写入持续，segment 数量会不断增长。segment 太多搜索变慢，删除的文档占据的空间不会自动回收。Segment merge 和 ILM 分别在 Lucene 层和 index 层解决这个存储生命周期问题。 本文抓两个问题：为什么需要 segment merge，以及 ILM 怎样管理索引的生命周期。 Segment Merge 为什么需要 merge 每次 refresh 产生一个新 segment。持续写入的 index 会积累大量小 segment。问题有二： 搜索时需要遍历所有 segment。segment 越多，搜索越慢。 删除文档只是在 .liv 文件中打标记，物理空间不回收。只有 merge 时才真正删除标记文档、回收空间。 123456789101112写入阶段： refresh → seg0(10 docs) refresh → se...
2026-06-26
深入 Elasticsearch（05）：近实时、Translog 与 Refresh/Flush
上一篇解决了文本怎样变成词项——analysis pipeline 把原始文本标准化为可索引的 term。这一篇进入文档写入后怎样变成可搜索的。 一条文档经过 analysis 生成词项后，并不会立即对搜索可见。ES 的写入路径涉及内存缓冲、translog 持久化、refresh 生成新 segment、flush 提交到磁盘四个步骤。这套机制让 ES 在写入吞吐和搜索延迟之间取得平衡，也是"近实时搜索"（near-real-time, NRT）这个名字的由来。 本文只抓一个问题：ES 的近实时搜索是怎么实现的，refresh 和 flush 的区别在哪里。 写入路径的完整流程 一条文档从客户端发出到最终持久化到磁盘，经过以下步骤： 123456789101112131415Document → Coordinating Node（路由到目标 shard 的 primary） → Primary Shard： 1. 写入 in-memory buffer（indexing buffer） 2. 追加到 translog（顺序写磁盘，...