Elasticsearch（全文检索引擎）

Elasticsearch 是构建在倒排索引之上的分布式检索与分析引擎：文本写入时经过分词建立词到文档的映射，查询时按词快速定位候选文档再打分排序，同时支持结构化过滤与聚合统计。它要解决的是海量文本里按关键词找相关内容的问题，是关键词召回、混合检索与日志查询最常见的落地方式。

关键机制

• 分词器：分词方式直接决定召回，中文需要专门的分词配置，按单字切分虽然不易漏词，但精度明显更差。
• 分片与副本：主分片数在建索引时确定，之后调整代价很高；副本数影响查询并发与容错能力，可以随时增减。
• 打分与排序：默认按词频与逆文档频率一类统计量打分，可与向量召回结果融合成混合检索，再叠加业务权重。
• 字段映射：字段类型与是否索引要提前定，动态映射容易把数值、日期或标识类字段识别错。
• 近实时可见：写入先落内存缓冲与事务日志，刷新之后才能被搜索到，因此检索结果与刚写入的数据之间存在一段延迟。

写入与查询流程

写入路径大致是：请求先落到主分片，同时追加事务日志以保证可恢复；文档进入内存缓冲并定期刷新成可搜索的段，段再在后台合并以减少文件数量。查询路径则是把请求广播到每个分片，各分片本地打分并返回候选，由协调节点合并排序后取前若干条。理解这两条路径有助于解释常见现象：批量导入时查询变慢，多半是刷新与段合并抢占资源；深分页开销大，是因为要每个分片返回大量候选；聚合查询的内存压力，则来自参与聚合的字段基数。

边界与常见误区

• 不适合当主数据库：它擅长查询，但不提供跨文档事务保证，权威数据仍应落在关系库或对象存储，索引随时可以重建。
• 与专用向量库的关系：它内置的向量检索同样基于近邻图结构，召回质量取决于分片规模、段结构与调参投入，并非天然更差；是否单独引入向量库，要看数据规模、调参成本与运维复杂度，各有取舍。
• 分片数不是越多越好：分片过多会带来大量小索引的固定开销，过少又无法水平扩展，要按数据量与增长速度预估。
• 字段膨胀：把任意键值对直接建成字段会让映射与内存失控，结构不固定的字段应集中存放或改为嵌套结构。

实践中更稳妥的做法是把检索索引当成派生数据：上游写入数据库，再用同步或异步方式更新索引，并保留全量重建的能力。这样即使映射设计失误或分词器更换，也能通过重建修正，而不必担心数据丢失。判断检索效果时不要只看能不能查到，还要看排序是否合理，因此通常需要准备一批带标注的查询样例，用它比较不同分词与打分配置。