检索、相关性与聚合

检索路径上的每一个反直觉行为，根都扎在一句话里：数据被切成了固定数量的 shard，一次查询要在所有 shard 上并行跑、再归并。打分会偏、分片数改不了、聚合要走另一套存储——全是这句话的推论。本章五节顺着"一条查询从落点到结果"的链路走：先定位（路由），再筛选与打分（filter / query / BM25），再分布式归并（两阶段），最后是聚合走的那条独立数据通道（doc_values）。

3.1分片路由：文档落在哪个分片，分片数为什么不能改

一条文档落在哪个 shard，由一个取模公式唯一决定；而除数就是主分片数——这就是它创建后不能改的全部原因。

写入一条文档、或按 _id 读取一条文档时，Elasticsearch 不会去问每个分片"这条在不在你这"，而是用一个确定性公式直接算出它该在哪个分片：

shard = hash(_routing) % number_of_primary_shards
# _routing 默认取文档的 _id
# 写入、按 id GET、按 id 删除，都用这同一个公式定位分片

公式是确定的，所以同一个 _id 永远算到同一个分片——写进 shard 1 的文档，之后按 id 取也只会去 shard 1 找，不必广播。代价是这个除数被钉死了：number_of_primary_shards（下文记作 N）一旦在建索引时定下，就不能再改。

为什么不能改？把 N 从 3 改成 4，对同一条文档，hash(_id) % 3 和 hash(_id) % 4 几乎必然得到不同的余数。换句话说，旧文档当初按"模 3"写进了 shard 1，新公式却按"模 4"去 shard 3 找它——找不到。主分片数不可变，不是一条人为限制，而是它在路由公式里当除数这一身份的直接后果：动了除数，等于把整张已经建好的映射表作废。

既然主分片数定死，分片数估错了怎么补救？三条现实路径，代价递增：

3.2query context 与 filter context

query 问"有多相关"、算出 _score；filter 问"是 / 否"、跳过打分，并把结果缓存成一个永不失效的 bitset。

同一个查询子句，放在 query context 还是 filter context，跑的是两套完全不同的逻辑。query context 要回答"这条文档跟查询有多相关"，于是算出一个浮点 _score，结果按分数排序。filter context 只回答一个布尔问题——"这条文档符不符合这个条件"，不打分、不参与排序。

filter 缓存为什么能"免失效"——这是 02 章红利

filter 的结果会被缓存成一个 bitset：一个 segment 内有多少文档，就有多少个 bit，命中该 filter 的文档对应位置 1，其余置 0。下次任何查询用到同一个 filter，直接复用这个位图，连判断都省了。

关键在于这份缓存永远不需要失效。回忆 02 章那根支柱——段不可变：bitset 是按 segment 缓存的，而 segment 一旦写出就再不改动。既然底层数据不会变，"哪些文档命中这个 filter"这个答案在该 segment 的整个生命周期里恒定，缓存自然无需失效。新数据进来只会形成新的 segment，老 segment 的 bitset 原封不动继续用；老 segment 被 merge 掉时，它的 bitset 一起丢弃即可。filter 缓存的"免失效"，是直接吃了 02 章"段不可变"的红利。

落到一个 bool 查询上，正确的分工是：相关性条件进 must（要打分），过滤条件进 filter（不打分、走缓存）。

{
  "query": {
    "bool": {
      "must": [
        { "match": { "title": "elasticsearch 路由" } }
      ],
      "filter": [
        { "range": { "created_at": { "gte": "now-7d/d" } } },
        { "term":  { "status": "published" } }
      ]
    }
  }
}

3.3BM25：相关性怎么算出来

BM25 用三个旋钮——词频饱和、字段长度归一、逆文档频率——把"一条文档对一个查询有多相关"压成一个分数。

query context 要打分，打的就是 BM25 分。一个查询有多个词项 qᵢ，每个词项贡献一份分，加起来就是文档的 _score：

score = Σᵢ  IDF(qᵢ) · ( tf · (k1 + 1) )
                      ─────────────────────────────────────
                      tf + k1 · ( 1 − b + b · (fieldLen / avgLen) )

IDF(qᵢ) = log( (N − n + 0.5) / (n + 0.5) )     # N=文档总数, n=含该词的文档数
k1 = 1.2   # 词频饱和速度
b  = 0.75  # 字段长度归一强度

三个旋钮各管一件事：

• 词频饱和（k1=1.2）：词频 tf 以 tf / (tf + k1·…) 的形式进入——这是一条渐近线。一个词出现第 1 次贡献很大，第 2 次还不错，到第 10 次几乎不再加分。k1 控制这条曲线压平的快慢。
• 字段长度归一（b=0.75）：分母里的 fieldLen / avgLen 让长于平均的字段被惩罚——同样出现 3 次某词，出现在一篇万字长文里，远不如出现在一句标题里有分量。b 控制惩罚强度。
• 逆文档频率 IDF：含某词的文档数 n 越大，IDF 越小。"的""是"这种到处都有的词权重被压到接近 0，区分度高的稀有词权重高。

3.4分布式检索两阶段，与相关性偏差

一次检索分两阶段在所有分片上跑——先各自返回 top-K 的 id+score 归并，再只对胜出的 K 条去取原文。

3.1 说过数据被切成固定数量的分片。于是一次 search 不可能只问一个分片——它要在每个分片上跑，再把结果归并。默认策略叫 query_then_fetch，顾名思义两个阶段：

阶段一（query）：协调节点把查询发到每个分片，每个分片在自己的数据上算分、只返回本地 top-K 的 doc id + score（不含原文）。协调节点收齐所有分片的候选，归并出全局 top-K。阶段二（fetch）：只对这 K 条，去它们各自所在的分片取完整 _source。这样网络上搬运的，第一阶段是轻量的 id+score、第二阶段只有最终 K 条原文，而不是每个分片的全部候选文档。

3.5doc_values 与聚合：为什么 text 不能直接聚合

聚合和排序要"按文档读字段值"，方向和倒排索引正相反——doc_values 是写入时就建好的列式磁盘结构，专门提供这个反方向。

倒排索引解决的是"给一个 term，找出哪些文档含它"——方向是 term → docs。但聚合和排序问的是反方向的问题："给一个文档，它这个字段的值是多少"——doc → value。要对 price 求平均、按 created_at 排序，都需要快速地按文档拿到字段值，而倒排索引天生不擅长这个方向。

历史上这个反方向是用 fielddata 解决的：查询时把倒排索引临时反转成"按字段排列的数组"，整个加载进 JVM 堆。字段一大，这个数组几十 GB，触发长时间 GC，严重时直接 OOM 把节点打挂。

doc_values 把这件事提前到写入时做。它在文档落盘、生成 segment 时就把每个字段写成一份列式磁盘结构（同一字段的所有值连续存放）。查询时通过操作系统的文件缓存（堆外、mmap 映射）读取，不占 JVM 堆。这就是为什么聚合 / 排序密集的负载能在一个不大的堆上跑——数据的重量压在堆外的文件缓存里，由操作系统按需换页，而不是全堆驻留。

这正是 01 章 text / keyword 分水岭的底层原因

回到 01 章那条最高频的分水岭——text 与 keyword。现在能看清它在检索路径上的后果了：

• text 默认没有 doc_values（它被分词、为全文检索而生，列式存原文意义不大）。所以直接对一个 text 字段做聚合或排序，会退回到老的 fielddata 路径——在堆上临时反转倒排索引，正是 01 章提到的那个易 OOM 的陷阱。ES 默认还把 text 的 fielddata 关掉，逼你显式开启或改用 keyword。
• keyword 默认有 doc_values（它整体存原值、不分词）。于是它天生能聚合、能排序，走的是堆外列式读取，安全又高效。

"一个字段该用 text 还是 keyword"这道 01 章的选择题，底层就是"它要参与全文检索（走倒排）还是聚合 / 排序（走 doc_values）"。需要两者兼顾时，常见做法是一个字段配两个映射：text 主体 + 一个 .keyword 子字段。