2. 搜索索引基础：倒排索引原理、分词与词项词典、索引写入与合并策略
搜索索引是信息检索系统的核心数据结构，其设计直接决定了查询的响应速度、存储效率与领域模型的映射能力。本节从倒排索引的底层原理出发，逐步拆解分词、词典构建、写入与合并等关键环节，为后续领域驱动的索引聚合查询奠定基础。
2.1 倒排索引原理
倒排索引（Inverted Index）是一种以词项（Term）为键、文档列表为值的索引结构。与正向索引（文档→词项）相反，倒排索引能够实现“给定一个词，快速找到包含该词的所有文档”，是搜索引擎实现亚秒级全文检索的根本保障。
倒排索引的核心由两部分组成：
- 词项词典（Term Dictionary）：存储所有出现过的不重复词项，以及指向倒排列表的指针。
- 倒排列表（Posting List）：每个词项对应的文档ID列表，通常还包含词频（TF）、位置信息（Position）等元数据。
关键指标：倒排索引的查询时间复杂度为 O(1) 到 O(log N)（取决于词典实现），远优于正向索引的 O(N) 全表扫描。
下图展示了从原始文档到倒排索引的完整构建流程：
2.2 分词与词项词典
2.2.1 分词器（Tokenizer）
分词是将连续文本切分为独立词项的过程。分词质量直接影响索引的召回率与精确率。不同语言、不同领域对分词器的要求差异显著：
| 分词器类型 | 典型实现 | 适用场景 | 优势 | 劣势 |
|---|---|---|---|---|
| 空白分词 | WhitespaceTokenizer | 英文、代码、日志 | 速度快、无歧义 | 无法处理复合词、标点粘连 |
| 标准分词 | StandardTokenizer | 通用英文、多语言混合 | 支持Unicode、标点处理 | 对中文无效 |
| 中文分词 | IK Analyzer、jieba、HanLP | 中文全文检索 | 语义切分、词典支持 | 速度较慢、歧义消解复杂 |
| N-gram分词 | NGramTokenizer | 模糊匹配、拼写纠错 | 覆盖所有子串 | 索引膨胀严重 |
领域建模提示：在领域驱动设计中，分词器应作为领域服务（Domain Service）注入索引构建流程。不同聚合根（Aggregate Root）可能使用不同的分词策略，例如“商品名称”使用中文分词，“SKU编码”使用空白分词。
2.2.2 词项词典（Term Dictionary）
词项词典是倒排索引的“目录”，负责将词项映射到其在倒排文件中的偏移位置。词典的实现方式直接影响索引的查询性能与内存占用：
- 哈希表（HashMap）：O(1) 查询，但内存占用高，不支持前缀/范围查询。
- B+树（B+ Tree）：O(log N) 查询，支持范围扫描，磁盘友好，是 Lucene 的默认选择。
- 有限状态转换器（FST, Finite State Transducer）：O(len(term)) 查询，内存压缩率高，支持前缀查询，Elasticsearch/Lucene 4.0+ 使用。
下表对比了三种主流词典实现：
| 实现方式 | 查询复杂度 | 内存占用 | 前缀查询 | 磁盘友好 | 典型应用 |
|---|---|---|---|---|---|
| HashMap | O(1) | 高 | 不支持 | 否 | 小型内存索引 |
| B+ Tree | O(log N) | 中 | 支持 | 是 | 传统数据库索引 |
| FST | O(len(term)) | 低 | 支持 | 是 | Lucene/ES |
避坑指南：FST 虽然内存效率极高，但构建过程是增量不可变的——一旦构建完成，无法动态添加新词项。因此，在索引写入阶段需要配合“段（Segment）”机制实现增量更新。
2.3 索引写入与合并策略
2.3.1 写入流程：段（Segment）机制
现代搜索引擎（如 Lucene、Elasticsearch）采用“写时复制（Copy-on-Write）”与“段（Segment）”相结合的写入策略。每个段是一个独立的、不可变的倒排索引子集。写入流程如下：
- 内存缓冲（In-Memory Buffer）：新文档先写入内存缓冲区，不直接落盘。
- 生成段（Flush）：当缓冲区满或达到刷新间隔时，将缓冲区内容写入磁盘生成一个新的段。
- 段不可变：段一旦写入磁盘即不可修改，后续更新通过写入新段+标记旧段删除实现。
- 段合并（Merge）：后台线程定期将多个小段合并为一个大段，减少段数量，提升查询性能。
下图展示了索引写入与合并的完整生命周期：
2.3.2 合并策略（Merge Policy）
合并策略决定了何时触发合并、合并哪些段。选择合适的合并策略对索引性能至关重要：
| 合并策略 | 核心算法 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|---|
| Log ByteSize | 按段大小对数分级合并 | 通用场景、写入均匀 | 合并次数可控 | 大段合并时IO压力大 |
| Tiered | 按段大小分层，每层独立合并 | 写入吞吐量高、段数多 | 合并与写入并行性好 | 内存占用略高 |
| NoMerge | 不合并 | 日志型、只写不读 | 零合并开销 | 段数无限增长，查询退化 |
性能调优参数：在 Elasticsearch 中，
index.merge.scheduler.max_thread_count 控制合并线程数，index.merge.policy.segments_per_tier 控制每层允许的段数。对于写入密集型场景，建议将 segments_per_tier 设置为 10~20，减少合并频率。
2.3.3 写入优化：批量提交与近实时搜索
为了平衡写入吞吐量与搜索可见性延迟，现代搜索引擎引入了“近实时搜索（Near Real-Time, NRT）”机制：
- Refresh Interval：控制内存缓冲区中的数据多久可见（默认 1 秒）。刷新频率越高，数据可见越快，但 CPU 开销越大。
- Flush Threshold：控制缓冲区大小（如 100MB 或 10,000 条文档）。达到阈值后强制生成段。
- Translog（事务日志）：在数据写入内存缓冲区的同时写入 translog，确保崩溃后数据不丢失。
领域建模建议：在领域事件驱动架构中，索引写入应作为领域事件的消费者。通过批量聚合领域事件（如每 100 条或每 500ms 提交一次），可以显著降低索引写入的 I/O 开销，同时保证最终一致性。