risc123456的博客

tvx/.tvd/.tvf TermVector 索引/数据 每篇文档每字段的 词、位置、偏移、payload 向量信息 高亮、ML 特征。.cfs/.cfe 复合文件/索引 把小文件合并成单个大文件 `.cfs` + 索引 `.cfe`（可选，减少句柄） 操作系统句柄紧张时启用。.fdx 存储字段索引 指向 `.fdt` 的 文档级别指针索引 快速随机访问 `.fdt`- 查词：`.tip` → `.tim` → `.doc/.pos/.pay`- 打分：`.nvd`/`nvm` + `.doc`

DirectoryReader` 打开后，`leaves()` 返回的每个 `LeafReaderContext` 就对应磁盘上的一个 segment。因此，`IndexReader.leaves()` 拿到的每个 LeafReaderContext 就等价于磁盘上的一个 segment，只是前者提供了 docBase 偏移、只读 API 等运行时信息，方便上层并行搜索与合并结果。概念 所在层次 含义 是否一一对应。

index 写：建索引、刷盘、合并；读：读倒排、正排、向量 `IndexWriter` `IndexWriterConfig` `DirectoryReader` `LeafReader`search 查询解析、打分、排序、翻页、聚合 `IndexSearcher` `Query` `TermQuery` `BooleanQuery` `TopDocsCollector`索引流程 分词 → 写倒排 → 刷盘/合并 `IndexWriter` `Analyzer` `Document` `Field`

如果改成 `"constant_score"` 或 `filter` 子句，则 `_score` 全为固定值（1.0），不会调用 BM25。"title": { "type": "text" } // 默认 similarity = BM25。- 响应中每个 hit 都有 `_score` 字段，值各不相同 → 证明走了 BM25。3️⃣ 触发 BM25 打分查询（非 filter）1️⃣ 创建索引（什么都不改，就是 BM25）3. 触发 BM25 打分的查询。1. 建索引（默认 BM25）

`IndexSearcher` → `TermQuery$TermWeight.scorer()` → `TermScorer` → `TermScorer.score()` 内部调用 `simScorer.score(freq, norm)`。- 每个 `Similarity` 实现（如 `BM25Similarity`）都会创建自己的 `SimScorer` 子类（如 `BM25Scorer`）。其中 `K(norm)` 已经预先缓存到 `cache[]` 中，保证每次打分只做一次乘除。

如果你使用了 同义词过滤器（synonym filter），多个同义词可能会落在 同一位置，这些 token 的 `positionIncrement=0`。> 在计算文档长度归一化因子（norm）时，是否忽略“重叠 token”（即位置增量 positionIncrement=0 的 token）。- 默认 `discount_overlaps=true` 会让这些 token 不影响文档长度，从而避免重复同义词“人为”拉长文档。✅ 配置示例（BM25）

节点启动时，`Environment` 会把 `elasticsearch.yml`、CLI 参数、jvm.options 等解析成一个全局的 `Settings` 实例。- 当你创建索引 `PUT /my_index` 时，如果没有显式指定 `number_of_shards`，就会用到这个全局默认值。- 此时 `my_index` 的 `number_of_replicas` 会自动取节点级的 `2`。那么最终该索引的 `Settings` 对象里就是 `5`，覆盖了全局的 `3`。

插件扩展点 允许插件通过 `IndexModule.add*()` 方法注册：- 自定义 `Similarity`（评分算法）- 自定义 `QueryCache`- 自定义 `Directory`（存储后端）- 自定义 `IndexEventListener`- 自定义 `MergePolicy`、`Codec`、`RecoveryStateFactory` …工厂角色 创建并返回 `IndexService` 实例（见 `IndexModule.newIndexService(...)`）。

IndexService 就是“一个索引在单个节点里的运行时总管”，负责把这个索引在本节点托管的所有分片（主/副）以及它们要用到的资源、配置、线程池、缓存、监听等全部管理起来。线程池 提供 `index`, `search`, `refresh`, `flush`, `merge` 等线程池的引用，让分片任务有地方跑。> IndexService 是“索引在当前节点上的总控制台”，负责管理该索引在本节点内的所有分片、配置、线程池和缓存等资源。✅ IndexService 的核心职责（节点维度）

在 Elasticsearch 的查询流程中，`dfsPhase` 是为了在进行“评分”时更准确地计算全局的 term 频率（TF-IDF），它需要先在每个数据节点上执行一次本地的 DFS 操作，收集该节点上每个字段的 term 统计信息（如 docFreq、totalTermFreq），然后将这些信息回传给协调节点。`dfsPhase`（即 DFS 阶段）是在每个数据节点本地执行的，而不是在协调节点执行的。因此，`dfsPhase` 的执行主体是每个数据节点，协调节点只负责收集和合并结果。

** 通过 **TCP 连接** 发出去、收回来，并管理 **连接生命周期、超时、重试、压缩、流控和反压**。- **SearchTransportService** 只是对 `TransportService` 的 **薄封装**，把搜索相关的 `ACTION_NAME` 和序列化逻辑注册到 `TransportService`。| **节点间 RPC** | 发送任意 `TransportRequest`，接收 `TransportResponse`，支持同步/异步/批量。

SearchTransportService` 是 **协调节点与数据节点之间“搜索子请求”通信的运输层**，它把**协调节点**发出的 **查询阶段、取回阶段、DFS 阶段、滚动上下文等** 请求 **序列化并通过 TCP 发送给各个数据节点**，再把数据节点的返回结果 **反序列化后交还给协调节点**。| **结果回调** | 所有方法都是 **异步** 的，返回 `ActionListener<SearchPhaseResult>` 给协调节点。### ✅ 核心职责（8.x）| 职责 | 说明 |

都**只运行在数据节点**上，它们通过 **SearchTransportService** 注册的请求处理器被远程调用；- 在 **InitialSearchPhase** / **FetchSearchPhase** 等 **SearchPhase** 子类里，通过 `SearchTransportService` 的 `sendExecuteQuery`、`sendExecuteFetch` 等接口把子请求 **转发到数据节点**；

• 字段类型（Field Types）：如`text`、`keyword`、`integer`、`date`等，决定了字段的存储和查询方式。• 创建索引（Create Index）：定义索引的结构、分片（Shards）数量、副本（Replicas）数量等。• 索引生命周期管理（Index Lifecycle Management）：自动管理索引的创建、更新、归档和删除。• 阶段管理（Phases）：如热阶段（Hot）、温阶段（Warm）、冷阶段（Cold）和删除阶段（Delete）。

Elasticsearch的代码库包含多个包，每个包负责不同的功能。封装了Elasticsearch的各种操作，如索引、搜索、删除等，提供了与集群交互的接口。提供客户端与Elasticsearch集群交互的内部实现，处理请求和响应。管理Elasticsearch的各种功能特性，包括启用、禁用和配置。管理存储库，如本地文件系统、HDFS等，用于存储索引数据。提供环境相关的配置和管理，如文件路径、系统属性等。提供对多个索引的管理功能，如索引别名、索引模板等。包含通用的工具类、数据结构和常量，被其他包引用。