• 全文搜索，这个是用的最多的。加上分词插件、拼音插件什么的可以做成强大的全文搜索引擎。
  • 数据库，挺奇葩的用法，因为 ES 存数相同数据，更费空间，不过确实不错，因为他的强大统计分析汇总能力，再加上分布式 P2P 扩展能力，现在硬件又那么便宜，所以就有人拿来当数据库了。
  • 在线统计分析引擎，日志系统，LogStash，不用解释了吧; 可以实时动态分析数据，很是爽。

三大场景（搜索、另类数据库、日志分析）是 ES 的经典画像，但生产落地还需要：ES 为什么快/为什么费空间（机制层）、与 MySQL 的分工边界、以及”当数据库用”的代价清单。本文补全机制与边界两层。

机制层：ES 的能力来源

  • 倒排索引（Lucene）：全文检索与关键词过滤的 O(词项) 基础（见倒排索引篇）
  • 列式存储 doc_values：聚合/排序走列存（按字段连续存储），而非倒排——这是”统计分析强”的物理基础
  • 分布式模型：索引分 shard（Lucene 实例），shard 分 primary/replica；查询 scatter-gather（各 shard 并行查再归并）；水平扩容靠加节点+rebalance
  • 近实时（NRT）：写入先进 index buffer + translog，refresh（默认 1s）生成 segment 后可搜——1 秒可见性是 ES 与”数据库即时一致”的根本差异
  • 聚合（aggs）：terms/date_histogram/cardinality 等在 shard 局部聚合再全局归并，日志看板/指标统计的引擎

场景一：全文搜索（主场）

  • 电商商品搜索、站内搜索、文档检索：分词（IK/拼音插件）、相关性排序（BM25+function_score 业务加权）、高亮、suggest 补全
  • 复杂查询组合：bool 组合 filter（缓存友好、不算分）与 query（算分）——filter 优先是性能第一原则

场景二：日志与可观测（ELK/EFK）

  • Logstash/Filebeat 采集 → ES 存储检索 → Kibana 看板；ILM（索引生命周期）按天滚动索引+热温冷分层+过期删除
  • 日志场景写入吞吐优先：bulk 批量写、refresh_interval 调大（30s）、translog 异步刷盘、replica 0 写入期后再补

场景三：”当数据库用”的代价清单

ES 能存能查，但替代主数据库前要认清代价：

  • 无事务：无跨文档原子提交；部分成功需应用补偿
  • 近实时而非即时：写后 1s 内可能查不到（refresh 间隔），”下单后立即查订单”类场景会踩坑
  • 更新是重写：文档不可变，update = 标记删除+重建整文档，高频小更新写放大严重
  • 深分页贵：from+size 深翻性能差（max_result_window 默认 1 万），用 search_after/scroll
  • 存储成本：倒排+doc_values+_source 多份结构，同数据量约为 MySQL 的 1.5-3 倍
  • 一致性语义弱：replica 同步异步、脑裂防护靠 quorum 配置（minimum_master_nodes/新版自动）

结论：**ES 做”检索与分析副本”，MySQL 做”权威源”**——双写/ Canal binlog 同步保持副本一致，是业界标准架构；把 ES 当唯一存储只适合日志这类”可丢可重建”数据。

与 MySQL 的查询分工

需求 归属
精确主键/事务/强一致 MySQL
模糊/全文/多字段组合检索 ES
复杂聚合看板（亿级） ES（或 ClickHouse 更优）
深分页浏览 ES search_after / 业务限深
实时计数精确值 MySQL（ES cardinality 是近似）

运维要点速记

  • mapping 先设计后写入（字段类型变更需 reindex）；keyword vs text 分清（聚合排序用 keyword）
  • 分片数规划：单分片 30-50GB 量级；分片过多 cluster state 膨胀、过少扩容受限
  • 写入用 bulk + 自动生成 _id 避免版本检查开销；查询熔断（circuit breaker）与慢日志常开

ES 的使用场景 = 倒排给检索、列存给聚合、分布式给规模；它的边界 = 无事务、近实时、更新贵。把能力与代价配对记忆，”什么时候用 ES、什么时候别用”就不再靠感觉。