Elasticsearch vs Solr 选型对比#

#Elasticsearch vs Solr 选型对比

候选人小孙在面试时被问到："你们为什么选 ES 而不是 Solr？"

小孙说："因为 ES 是 Lucene 的升级版，功能更强。"

面试官追问："ES 和 Solr 都是基于 Lucene 的，你知道它们的核心区别是什么吗？"

小孙愣了一下："ES 比较新？"

面试官继续追问："SolrCloud 和 ES 的分布式架构有什么区别？"

小孙答不上来了。

【面试官心理】 这道题我是在测试候选人对搜索引擎领域的宏观理解。能把架构差异讲清楚的占 30%，能说出 CAP 权衡的占 10%，能给出选型决策矩阵的占 5%。能答到最后的，基本都调研过这两个引擎的选型过程。

#一、架构差异 🟡

#1.1 天生分布式 vs 需要插件

这是 ES 和 Solr 最根本的区别。

ES 的分布式设计：每个 Index 按分片分布，每个分片是一个 Lucene 实例。主分片和副本分布在不同节点上，ES 自动处理分片路由、负载均衡和故障转移。

SolrCloud 的架构：依赖 ZooKeeper 做集群协调，Solr 节点需要向 ZooKeeper 注册，分片 Leader 由 ZooKeeper 选举。这意味着你不仅需要运维 Solr 集群，还需要运维 ZooKeeper 集群。

#1.2 ZooKeeper 的负担

很多团队选择 SolrCloud 后才发现这个坑：

SolrCloud 集群：
  ├── ZooKeeper 集群（至少 3 节点，HA）
  │     ├── ZooKeeper 节点 A
  │     ├── ZooKeeper 节点 B
  │     └── ZooKeeper 节点 C
  └── Solr 集群
        ├── Solr 节点 1
        ├── Solr 节点 2
        └── Solr 节点 3

运维复杂度：double
故障排查复杂度：triple

#二、实时性与近实时搜索 🔴

#2.1 两者都支持近实时

#2.2 写入链路对比

ES 写入链路（见 ES 写入流程）： 协调节点 → 主分片 → Translog → Memory Buffer → refresh → 可搜索

Solr 写入链路： 协调节点（Cloud 模式下）→ ZooKeeper 获取 Leader → Leader 写入 → 同步到 Replica → ZooKeeper 确认

关键差异：Solr 的写入需要 ZooKeeper 协调，每次写入都多一次网络往返；ES 的写入只需要节点间直接通信，无 ZooKeeper 中转。

#三、搜索能力对比 🟡

#3.1 核心搜索功能

#3.2 聚合能力的差距

ES 的 Aggregations 比 Solr 的 Facets 强大很多：

ES Aggregations：

• 支持嵌套聚合（terms → avg → percentiles）
• 支持 Pipeline 聚合（对聚合结果再聚合）
• 支持 Cardinality、HDR Histogram 等高级指标

Solr Facets：

• 支持基本 Facet（terms、range、query）
• 支持 Pivot Facet（多维交叉）
• 但不支持嵌套的指标计算

// ES 嵌套聚合示例：一个查询搞定"每个品牌的订单数 + 平均价格 + 价格百分位数"
{
  "aggs": {
    "by_brand": {
      "terms": { "field": "brand.keyword" },
      "aggs": {
        "avg_price": { "avg": { "field": "price" } },
        "price_percentiles": { "percentiles": { "field": "price" } }
      }
    }
  }
}

这种嵌套聚合在 Solr 中需要多个 Facet 请求才能实现。

#四、生态与社区 🟡

#4.1 社区活跃度对比

ES 的社区规模和商业化程度远超 Solr。这意味着：

• 更多中文资料和踩坑博客
• 更多插件和集成方案
• 更快的 bug 修复和安全补丁
• 更完善的监控和管理工具（X-Pack / APM）

#4.2 互联网采用率

根据 DB-Engines 的统计，ES 连续多年排名搜索引擎第一，远超 Solr。

• 2010 年：ES 刚发布，Solr 占据主导
• 2015 年：ES 用户数超过 Solr
• 2020 年至今：ES 市场占有率约 70%，Solr 约 20%

为什么 ES 赢了？

1. 开箱即用的分布式：SolrCloud 晚了 ES 至少 3 年
2. JSON-first 的 API：RESTful 接口更符合现代开发习惯
3. 更低的运维门槛：不需要 ZooKeeper
4. ELK 生态绑定：Elasticsearch + Logstash + Kibana 一体化

#五、选型决策矩阵 🔴

#5.1 决策树

是否需要分布式搜索？
  │
  ├── 否（单机，数据量小 < 100万）
  │     └── 推荐 Solr（功能完整，上手简单）
  │
  └── 是
        │
        ├── 是否已有 ZooKeeper 集群？
        │     ├── 是 → 可考虑 SolrCloud
        │     └── 否 → 倾向 ES（减少运维复杂度）
        │
        ├── 是否需要强大的嵌套聚合能力？
        │     ├── 是 → ES Aggregations 更强
        │     └── 否 → 两者皆可
        │
        └── 数据量规模？
              ├── < 10 亿文档 → ES / Solr 皆可
              ├── 10 亿 ~ 100 亿 → ES 更稳
              └── > 100 亿 → 需要定制化优化

#5.2 核心对比表

#5.3 真实场景案例

案例 1：日志分析平台 选型：ELK 栈（Elasticsearch + Logstash + Kibana） 原因：日志场景需要海量数据写入 + 聚合分析 + 可视化，ELK 生态完整。开箱即用，不需要自己搭建。

案例 2：电商商品搜索 选型：ES（国内） / Solr（国外部分） 原因：中文分词（IK/HanLP）对 ES 支持更好；电商搜索需要复杂的 Aggregations 做 facets；ES 的热度更高，插件更丰富。

案例 3：传统企业搜索 选型：Solr 原因：传统企业数据量有限，不需要分布式；团队可能已有 Java 背景，Solr 的 XML 配置更直观；数据源多为结构化数据，不需要复杂的全文搜索。

#六、错误示范

#❌ 错误示范 1

候选人原话："ES 比 Solr 新，所以 ES 更好。"

问题诊断：

• 把"新旧"当成了选型标准
• 不知道两者都基于 Lucene，核心算法相同
• 不理解"新"可能意味着"不成熟"

#❌ 错误示范 2

候选人原话："Solr 比 ES 稳定，因为 Apache 基金会在维护。"

问题诊断：

• 不了解 ES 的商业公司（Elastic N.V.）也有大量投入
• 不知道 ES 的生产装机量远大于 Solr
• 混淆了"开源治理模式"和"稳定性"

面试官内心 OS："这两个候选人都没有真正调研过选型过程。他们可能用过 ES 或 Solr，但没有从架构、成本、生态等多个维度对比过。一个合格的 P6/P7 工程师，至少应该能说出 5 条选 ES 或选 Solr 的具体理由。"

#七、面试追问升级

追问 1：你们公司如果从 Solr 迁移到 ES，需要注意什么？

考察点：迁移成本评估 期望回答：mapping 兼容性问题、停词和同义词配置差异、零停机迁移方案（双写 + 切换别名）

追问 2：ES 的 CAP 是什么？它牺牲了什么换取了什么？

考察点：分布式系统理论 期望回答：ES 是 AP 系统，牺牲了强一致性（C）。主分片写入成功后即返回客户端，副本同步是异步的，存在数据暂时不一致的窗口。

追问 3：什么场景下 Solr 比 ES 更合适？

考察点：全局视野 期望回答：数据量不大但查询复杂度极高的场景；需要深度定制评分模型的场景；已有 Solr 集群没有迁移必要的场景。

【面试官心理】 这道题能给出完整选型矩阵和真实案例的候选人，说明他有技术选型的实战经验。他不是在背概念，而是在告诉面试官"我踩过坑，我知道什么时候该选哪个"。这种候选人在 P7 层面非常稀缺。