Elasticsearch
基于倒排索引的搜索与分析引擎，搜得准排得快
Elasticsearch 建在 Lucene 之上，把文本切成词、建立“词 → 文档”的倒排索引，所以能在亿级文档里毫秒级返回相关结果。它同时是个分布式系统：索引被切成主分片和副本分片散在多个节点上，扩容只需加机器。
它解决什么问题
MySQL 的 like '%手机%' 在千万级数据上要扫全表，还不支持分词、同义词、相关性排序。
真实场景：典型场景：电商搜索框输入“无线蓝牙耳机”，ES 分词后匹配标题、类目、品牌，再按相关性和销量排序，20ms 返回结果。
核心概念
每个概念一句话 + 一个类比。点击卡片看更详细的解释。
数据流转动画
跟着步骤看一条数据从进入系统到被处理完的完整路径，可以暂停、重播和调速。
一次搜索在分片间的分布与执行
← 左右滑动查看完整流程图 →
客户端把查询发给任意节点，这个节点本次担任协调节点。
提示：写请求先到主分片再同步副本；查询是 scatter-gather，协调节点负责合并排序。 悬停图中的节点可以看概念解释。
优劣势
短句说清适合什么、不适合什么，选型时先看这一栏。
- 全文检索、分词、相关性排序能力强
- 水平扩展简单，加节点自动分片均衡
- 聚合分析快，日志场景的事实标准（ELK）
- 近实时搜索，写入 1 秒后可见
- 不是数据库，事务和强一致能力弱
- 内存和磁盘开销大，运维成本高
- 分片数建索引时定死，改要 reindex
- 深分页（from+size）性能急剧下降
常见使用场景
每个场景都配一句「为什么用它」。
站内搜索
商品、文章、视频的搜索框，支持分词、纠错、同义词。
为什么用它：倒排索引 + 相关性打分，MySQL 的 like 做不到。
日志检索与可观测
Filebeat 采集日志进 ES，Kibana 查询和做看板。
为什么用它：按时间范围 + 关键词检索亿级日志，秒级响应。
聚合分析
按地区、品类做多维统计和趋势分析。
为什么用它：聚合框架在分片内并行计算，比 SQL group by 快得多。
常见问题
上手第一个月最容易卡住的地方。
Q1分片和副本怎么设？
单分片建议 10~50GB，按数据总量除以这个区间估算主分片数，副本至少 1。分片不是越多越好，每个分片都有固定开销，几百个小分片反而拖慢集群。
Q2为什么 ES 搜得快？
倒排索引把“找包含某词的文档”变成一次词表查询；查询在多个分片上并行；结果只需要 Top N，用堆归并。相反，MySQL 的 like 需要逐行扫描。
Q3和 MySQL 怎么配合？
MySQL 存权威数据，ES 存检索副本。写入 MySQL 后通过 binlog（Canal）或双写同步到 ES，接受秒级延迟。绝不要把 ES 当唯一数据源。
Q4深分页为什么慢？
from=10000 需要每个分片都取 10010 条再归并。用 search_after + 排序游标替代，或者限制用户只能翻前 100 页。