1.1 从图书馆检索说起#

假设你在图书馆查找所有包含”Elasticsearch”这个词的书籍：

传统方法：逐本书翻阅，检查每一页是否包含目标词。

索引方法：图书馆有索引卡片，列出每个关键词出现在哪些书中、哪些页。

1.2 全文检索的定义#

全文检索（Full-Text Search）是指：

从大量非结构化文本数据中，根据关键词快速找到包含这些词的文档，并按相关性排序返回结果。

1.3 核心挑战#

全文检索面临的核心挑战：

2.1 正排索引：文档到词的映射#

正排索引（Forward Index）是从文档视角出发，记录每个文档包含哪些词：

正排索引的结构：

1
{
2
  "doc_1": ["elasticsearch", "搜索", "引擎"],
3
  "doc_2": ["数据库", "mysql", "索引"],
4
  "doc_3": ["elasticsearch", "性能", "优化"]
5
}

查询方式：要查找包含”elasticsearch”的文档，需要遍历所有文档的词列表。

1
def search_forward_index(query, forward_index):
2
    """正排索引搜索：O(N×M)"""
3
    results = []
4
    for doc_id, words in forward_index.items():
5
        if query in words:
6
            results.append(doc_id)
7
    return results

2.2 倒排索引：词到文档的映射#

倒排索引（Inverted Index）反转了这个关系，从词出发，记录每个词出现在哪些文档中：

倒排索引的结构：

1
{
2
  "elasticsearch": [1, 3],
3
  "搜索": [1],
4
  "引擎": [1],
5
  "数据库": [2],
6
  "mysql": [2],
7
  "索引": [2],
8
  "性能": [3],
9
  "优化": [3]
10
}

查询方式：直接通过词定位文档列表。

1
def search_inverted_index(query, inverted_index):
2
    """倒排索引搜索：O(1)"""
3
    return inverted_index.get(query, [])

2.3 两种索引的对比#

2.4 为什么叫”倒排”？#

“倒排”（Inverted）这个名字源于关系反转：

理解方式：

1. 正排：顺着文档的顺序，文档在前、词在后
2. 倒排：把关系倒过来，词在前、文档在后

3.1 核心组件#

倒排索引由两个核心部分组成：

词典（Term Dictionary）：

• 存储所有不重复的词项（Term）
• 有序排列，支持二分查找
• 每个词项指向对应的倒排表

倒排表（Posting List）：

• 存储包含该词的所有文档 ID
• 有序排列，便于求交集
• 包含位置信息、词频等元数据

3.2 完整的倒排表结构#

实际应用中，倒排表不仅存储文档 ID，还包含丰富的元数据：

倒排表项的字段：

3.3 词典的组织结构#

词典需要支持高效的查找，Lucene（Elasticsearch 的底层）使用多层结构：

三层结构：

1. Term Index：内存中的前缀索引，快速定位词典块
2. Term Dictionary：磁盘上的有序词典，存储完整词项
3. Posting List：倒排表，存储文档列表

3.4 为什么需要 Term Index？#

如果词典完全存储在内存中，内存开销巨大；如果完全在磁盘上，查找效率低下。

Term Index 的设计思想：

• 只存储词项的前缀，大幅减少内存占用
• 通过前缀快速定位到词典中的数据块
• 然后在数据块中进行二分查找

4.1 词典存储的挑战#

假设词典有 100 万个词，平均每个词 10 字节，仅词典就需要约 10MB 内存。对于大规模应用，这个数字会更大。

4.2 FST 的原理#

FST（Finite State Transducer，有限状态转换器）是一种高效的有向无环图结构，用于压缩存储有序字符串集合：

FST 的特点：

1. 前缀共享：相同前缀只存储一次
2. 后缀共享：相同后缀也可共享
3. 有序存储：词项有序，支持二分查找
4. 输出函数：每个词项关联一个输出值

4.3 FST 与其他结构的对比#

4.4 FST 在 Lucene 中的应用#

查找流程：

1
def search_term_fst(term):
2
    # 1. 在 FST 中查找前缀
3
    block = fst.search(term[:prefix_len])
4

5
    # 2. 定位到磁盘块
6
    block_data = disk.read(block)
7

8
    # 3. 在块中二分查找
9
    term_info = binary_search(block_data, term)
10

11
    # 4. 获取倒排表指针
12
    posting_list = read_posting(term_info.pointer)
13

14
    return posting_list

5.1 为什么需要相关性排序？#

搜索”elasticsearch 性能优化”，可能返回数千个文档，用户需要最相关的排在前面。

5.2 TF-IDF 算法#

早期的相关性算法，基于两个概念：

词频（TF, Term Frequency）：词在文档中出现的次数越多，越相关。

逆文档频率（IDF, Inverse Document Frequency）：词在所有文档中出现得越少，区分度越高。

公式：

$TF\text{-}IDF(t, d) = TF(t, d) \times IDF(t)$

其中：

• $TF(t, d) = \frac{\text{词}t\text{在文档}d\text{中的出现次数}}{\text{文档}d\text{的总词数}}$
• $IDF(t) = \log\frac{\text{文档总数}}{\text{包含词}t\text{的文档数}}$

5.3 BM25 算法#

BM25 是 TF-IDF 的改进版本，解决了 TF-IDF 的一些问题：

BM25 公式：

$BM25(d, q) = \sum_{i=1}^{n} IDF(q_i) \times \frac{f(q_i, d) \times (k_1 + 1)}{f(q_i, d) + k_1 \times (1 - b + b \times \frac{|d|}{avgdl})}$

参数说明：

| 参数 | 含义 | 默认值 | | ----------- | ---------------------------- | ------ | --------------- | --- | | $f(q_i, d)$ | 词 $q_i$ 在文档 $d$ 中的频率 | - | | $| d |$ | 文档 $d$ 的长度 | - | | $avgdl$ | 平均文档长度 | - | | $k_1$ | 词频饱和参数，控制饱和速度 | 1.2 | | $b$ | 文档长度归一化参数 | 0.75 |

5.4 词频饱和曲线#

关键差异：

• TF-IDF：得分随词频线性增长，可能出现过度匹配
• BM25：得分有饱和上限，避免长文档过度得分

5.5 BM25 参数调优#

1
# Elasticsearch 中 BM25 参数配置
2
PUT /my_index
3
{
4
  "settings": {
5
    "index": {
6
      "similarity": {
7
        "my_bm25": {
8
          "type": "BM25",
9
          "k1": 1.2,      # 词频饱和参数
10
          "b": 0.75       # 文档长度归一化参数
11
        }
12
      }
13
    }
14
  }
15
}

参数调优建议：

6.1 为什么需要分词？#

搜索”搜索引擎”，期望同时找到包含”搜索”、“引擎”、“搜索引擎”的文档：

6.2 分词器的工作流程#

三个阶段：

1. Character Filters：预处理，如去除 HTML 标签
2. Tokenizer：分词，将文本切分为词项
3. Token Filters：后处理，如小写转换、词干提取

6.3 常见分词器#

中文分词示例：

1
# IK 分词器两种模式
2
text = "中华人民共和国"
3

4
# smart 模式（智能分词）
5
smart_result = ["中华人民共和国"]  # 作为一个整体
6

7
# max_word 模式（最细粒度）
8
max_result = ["中华人民共和国", "中华人民", "中华", "华人", "人民共和国", "人民", "共和国", "共和", "国"]

6.4 规范化处理#

规范化处理确保不同形式的词能够匹配：

6.5 分词对索引的影响#

关键原则：索引和查询必须使用相同的分词器，否则无法匹配。

7.1 设计目标的差异#

7.2 查询模式对比#

7.3 结构对比#

7.4 性能特征对比#

7.5 为什么数据库不适合全文检索？#

1
-- 数据库的 LIKE 查询
2
SELECT * FROM articles WHERE content LIKE '%elasticsearch%';
3

4
-- 问题：无法使用索引，全表扫描
5
-- 原因：前导通配符 % 导致索引失效

8.1 倒排索引的写入挑战#

倒排索引设计为读优化结构，写入面临挑战：

8.2 Lucene 的段机制#

Lucene 采用写时复制策略，将索引分为多个段（Segment）：

段的特点：

1. 不可变：段一旦写入，不再修改
2. 追加写入：新增文档创建新段
3. 查询合并：查询时合并所有段的结果
4. 后台合并：定期合并小段为大段

8.3 写入流程详解#

写入步骤：

1. 文档写入内存缓冲区（Memory Buffer）
2. 同时写入事务日志（Translog）保证可靠性
3. 缓冲区满或定时刷新到磁盘生成新段
4. 新段立即可被搜索

8.4 段合并（Segment Merge）#

随着写入增多，段数量增加，查询性能下降：

合并策略：

1
# Tiered Merge Policy（分层合并策略）
2
# 将大小相近的段合并在一起
3

4
def find_merge_candidates(segments):
5
    """
6
    选择合并候选：
7
    1. 段数量超过阈值触发合并
8
    2. 优先合并小段
9
    3. 避免合并大段（开销大）
10
    """
11
    candidates = []
12
    for segment in sorted(segments, key=size):
13
        if segment.size < merge_threshold:
14
            candidates.append(segment)
15
        if len(candidates) >= max_merge_count:
16
            break
17
    return candidates

8.5 删除与更新的实现#

关键设计：

8.6 近实时搜索#

Lucene 通过近实时搜索（Near Real-Time Search）实现写入后立即可搜索：

关键参数：

1
{
2
  "refresh_interval": "1s", // 内存段刷新间隔
3
  "translog": {
4
    "durability": "async" // 异步刷盘提高性能
5
  }
6
}

9.1 整体架构#

9.2 关键设计决策#

9.3 适用场景分析#

10.1 倒排索引的核心价值#

10.2 最佳实践建议#

索引设计：

1. 合理设置分片数量，避免过多或过少
2. 选择合适的分词器，匹配业务语言特性
3. 禁用不需要的字段索引，节省空间
4. 使用 nested 类型处理数组对象

查询优化：

1. 使用 filter 代替 query 利用缓存
2. 避免深度分页，使用 scroll 或 search_after
3. 合理使用聚合，避免内存溢出
4. 监控慢查询，优化查询语句

写入优化：

1. 批量写入减少请求开销
2. 调整 refresh_interval 平衡实时性和性能
3. 合理设置段合并策略
4. 避免高频更新同一文档

10.3 与其他技术的对比#

10.4 核心要点回顾#

倒排索引是搜索引擎的基石，它通过反转文档与词的关系，实现了毫秒级的关键词查找。理解倒排索引的设计原理，有助于我们更好地使用 Elasticsearch，并在合适的场景做出正确的技术选型。