Elasticsearch：倒排索引原理

可视化演示

展示ES倒排索引的Term→Document映射结构、Segment不可变段与Commit Point机制、以及倒排索引与B+树索引的结构对比，切换模式查看不同层面。

索引概念：从翻书到翻卡片

你接手图书馆第一天，就收到一个刁钻需求：把所有提到“数据仓库”的书找出来。书架是按编号排的，编号和内容毫无关系，你只能拿起第一本，从第一页翻到最后一页，做满记号再放下——几十万本翻完，天都亮了。你意识到：书架适合“按编号找书”，却回答不了“按内容找书”。

于是你想了个聪明办法：与其每次翻书，不如提前把“书里有哪些词”登记起来。正着登记，以每本书为开头，记“《数据库大全》包含：数据库、索引、查询……”；另一种做法是倒过来，以每个词为开头，记“数据库：出现在《数据库大全》《存储漫谈》……”。第二种，就是倒排索引。

在 Elasticsearch 中，文档（documents）先交给分词器切成词条（terms），系统为每个词条维护一个倒排表。查询时只需在词条字典里定位关键词，再取出倒排表，就能瞬间知道命中哪些文档，而不用逐篇全文匹配。这就是“反向映射”的精髓：把“文档→词”的对应翻转成“词→文档”。

现在你再遇到“找数据仓库相关的书”这种需求，只要翻开那张写着“数据仓库”的卡片，背后就是完整书单。从“一本本翻书”到“一翻卡片就有”，这就是倒排索引带来的质变。

倒排结构：一张卡片，三重信息

卡片柜搭好后，你发现光有“书单”还不够。读者常追问：“这几本书里，哪本讲'数据库'讲得最细？”如果卡片只写书名，你还是答不上来。于是你给每张卡片背面的每本书旁，记上两个数字：这个词在这本书里出现了几次、分别在第几章第几页。

这就是倒排结构的三要素：Term Dictionary 是卡片的“标签区”，所有关键词按字典序排列，方便快速定位；Posting List 是卡片背面的“书单区”，记录文档编号；Posting 里还带词频与位置。三者合起来，才构成一张完整的倒排卡片。

技术上，ES 的 Posting List 不止记录 docID，还记录 term frequency（词频，用于相关度打分）和 positions（词位置，用于短语查询与高亮）。Lucene 还进一步用跳表、位图等结构压缩倒排表，让“书单”更省空间、遍历更快。

现在卡片柜每一格都能回答三个层次的问题：这本书有没有提到（编号）、讲得多不多（词频）、讲到哪（位置）。读者再刁钻的“细节追问”，你翻翻卡片背面就有答案。

核心流程：分三步走完一次搜索

一个读者走到柜台：“我想找同时讲'搜索引擎'和'倒排索引'的书。”你抽出两张卡片：一张写着“搜索引擎”，一张写着“倒排索引”。把两张书单摆在一起，找出都出现的编号——这就是查询的“与”运算。

一次完整搜索有四步：分词（把 query 切成词条）、构建（写入时已经建好索引）、匹配（查词典→取倒排表→求交集/并集）、排序（按相关性打分返回 Top N）。对用户来说这只是眨眼之间，对系统来说是一场流水线作业。

布尔查询是基础。多个词条按 AND 处理时，就是对各倒排表做集合交集；OR 则是并集。实际生产环境还会用 BM25 打分排序：词频越高、文档越短，得分越高，这就是“结果排序”环节的职责。

有了卡片柜，任何复杂问题都被拆成“翻哪几张卡片、怎么合并书单”的小事。图书馆的服务台从此再也不怕刁钻提问——分词、查卡、合并、排序，四步流水线各司其职。

Segment机制：不可变的“新书册子”

图书馆每天都有新书到货。最初你把新书硬塞进旧册子重新编目，结果每加一本书，几十万张卡片就要重写，图书馆直接瘫痪。你痛定思痛：新书不再改旧册，而是装订成一本新册子，单独上架。

ES 的每个分片（shard）由多个 Segment 组成。Segment 一旦生成就不可修改（immutable），这带来三个好处：无需加锁，并发读安全；文件缓存友好，热数据命中率高；崩溃恢复简单，已落盘段不用重写。代价是多次写入会产生很多小段，查询时要跨段汇总结果。

后台的 merge 线程会定期把小段合并成大段，减少段数量，同时真正清理被标记删除的文档。合并是纯后台操作，但会占用 IO，所以 ES 提供了按段数量、按段大小等触发策略，让管理员能控制“多久合并一次、合并到什么规模”。

就像图书馆每天闭馆后把散落的小册子并成大册、顺手清掉破损书页，合并让书架永远保持“恰到好处的整洁”，查询效率也稳定在最佳状态。

提交与更新：登记簿与流水账

一次断电事故让管理员惊出一身冷汗：临时架上几十本新书“凭空消失”，因为它们只存在于记忆里，没有登记。为了让数据万无一失，你立了两本账：一本“入库登记簿”，记录哪些册子正式盖章入库（已落盘）；一本“流水账”，记住每次“书到了”但还没来得及盖章的操作。

对应 ES：Commit Point 是登记簿，记录所有已落盘的 Segment 及文件信息；写入先进内存 buffer 和 translog（流水账），当触发 flush 时，buffer 生成新 Segment 并 fsync 落盘，同时更新 Commit Point。translog 本身也会定时 fsync 到磁盘，防止内存丢失。

崩溃恢复时，ES 先根据最近一次 Commit Point 找到已落盘的数据，再重放 translog 里尚未提交的写入，从而做到不丢数据。这正是“先写日志、再改数据”的 WAL（Write-Ahead Logging）思想的体现：流水账永远是第一道保险。

有了登记簿和流水账，哪怕半夜突然断电，第二天你也能把书一本不差“找回来”。对数据密集型系统来说，这种双账本机制就是持久化的定心丸。

FST压缩：把卡片标签折叠起来

卡片柜越来越大，几十万张卡片堆满了三个房间。管理员想省钱省空间，仔细观察发现很多卡片标签重叠：“数据库”、“数据仓库”、“数据结构”都共享前缀“数据”。与其每张卡片都完整写一遍，不如做一个“树状折叠柜”：公共前缀只写一次，后面的分支各自展开。

ES 的词典（Term Dictionary）必须常驻内存才能快速定位词条，而海量词条会让内存爆炸。Lucene 用 FST（Finite State Transducer，有限状态转换器）来压缩词典：它把词条集合编码成一张有向无环图，共享前缀与后缀，既大幅节省内存，又能在图上做精确查找和前缀查询。

FST 的构建是贪心算法：按字典序插入词条，尽量复用已有路径，最终得到最小化的状态机。查询时从起点沿着字符边走，走完即找到词条及其对应的 value（如 docID 区间）。它是无损的，不会因为压缩丢掉任何一个词，这也是“快速查找”的底气所在。

换用折叠柜后，房间空出一大半，找卡片的速度反而更快——因为路径更短了。内存省了、查询快了，FST 是 ES 在万亿词条下依然轻盈的秘密武器。

近实时性：先上架，后编目

新书上架流程很长：编目、盖章、入库、登记，一套走完往往要等很久。但读者等不及。于是你开了一个“新书快借区”：新书到货，先在内存里整理成临时小册子，每隔一秒统一摆上快借区，读者立刻能借到；至于盖章入库、登记账本，那是后台慢慢做的事。

ES 的写入默认先进内存 buffer，每 refresh（默认 1 秒）把 buffer 生成一个新 Segment，并让这段数据对搜索可见。所以“写入到可搜”的时延约为一个 refresh 周期，这就是近实时（Near Real-Time）的含义——不是实时，但足够快。

如果业务要求“写入后立刻可见”，可以把 refresh_interval 调小甚至手动 refresh，但这会频繁生成小 Segment，拖累写入吞吐。反之，批量导入时把 refresh 调大（如 30 秒），写入性能显著提升。真正的持久化仍要靠 translog fsync 与 flush 落盘完成。

“先上架，后编目”的策略让图书馆在“及时可用”与“严谨归档”之间找到了平衡——你还可以根据客流（写入压力）灵活调整快借区的刷新频率，这正是 ES 近实时设计的精髓。

B+树对比：书架与卡片柜各有所长

你发现隔壁老图书馆用的是另一种体系：每本书有固定编号，按编号顺序排满书架，想找编号 1000 到 2000 之间的书，沿着书架走一趟就有；但想找“提到某词的书”，依然得一本本翻。而你的卡片柜呢？找关键词秒回，却回答不了“编号 1000 到 2000 之间有哪些书”这种范围问题。

关系型数据库（如 MySQL InnoDB）用 B+树做主索引：叶子节点有序存放行数据，擅长范围查询、排序、精确匹配；ES 的倒排索引则把“词→文档”映射前置，擅长全文检索，“哪个词出现在哪些文档”是它的主场。两者解决的其实是不同维度的问题，这就是“原理差异”的本质。

B+树查询复杂度是 O(log n + k)，n 是记录数、k 是结果数；倒排索引查询要先在 FST 词典中定位词条，再取倒排表，复杂度与命中结果规模相关，与文档总数基本无关。所以文档越多，倒排索引的“免扫描”优势越明显。

书架与卡片柜并不冲突：成熟系统往往两者并用——MySQL 用 B+树管行、ES 用倒排管词，再由业务层协调。理解了各自的边界，你才能在设计检索系统时让它们各司其职。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-# 迷你倒排索引: 用 Python 字典实现 "词条 -> 文档" 的翻转映射import refrom collections import defaultdict  class MiniInvertedIndex(object):    def __init__(self):        self.doc_texts = {}                # doc_id -> 原文        self.term_docs = defaultdict(set)  # term -> 命中的 doc_id 集合        self.term_total = defaultdict(int) # term -> 全局出现次数     def add_doc(self, doc_id, text):        self.doc_texts[doc_id] = text        tokens = re.findall(r"\w+", text.lower())        local_count = defaultdict(int)        for token in tokens:            local_count[token] += 1        for token, freq in local_count.items():            self.term_docs[token].add(doc_id)            self.term_total[token] += freq     def query_and(self, query_text):        tokens = re.findall(r"\w+", query_text.lower())        hit = None        for token in tokens:            cur = self.term_docs.get(token, set())            hit = cur if hit is None else hit & cur        return sorted(hit) if hit else []     def top_terms(self, limit=5):        items = sorted(self.term_total.items(), key=lambda kv: kv[1], reverse=True)        return [(t, c) for t, c in items[:limit]]  if __name__ == "__main__":    idx = MiniInvertedIndex()    docs = {        1: "Elasticsearch is a distributed search engine",        2: "A search engine builds an inverted index",        3: "The inverted index powers full text search",    }    for did, content in docs.items():        idx.add_doc(did, content)    print("query 'search engine':", idx.query_and("search engine"))    print("query 'inverted index':", idx.query_and("inverted index"))    print("query 'database':", idx.query_and("database"))    print("top terms:", idx.top_terms())

1. self.term_docs[token].add(doc_id)核心一步：把词条 token 映射到文档 doc_id，这就是“倒排”关系的建立。
2. re.findall(r"\w+", text.lower())简易分词：按单词切分并统一小写，模拟 ES 的 analyzer 分词器。
3. local_count[token] += 1统计词频，对应正文里“卡片背面的次数记录”。
4. hit = cur if hit is None else hit & cur多个词条做集合交集，实现布尔 AND 查询。
5. idx.query_and("inverted index")复现“翻两张卡片、合并书单”的完整查询过程。

常见误区

面试题