名词地图与集群拓扑

这一章只做一件事：把名词钉死。后面两章讲机制（写入为什么近实时、检索为什么打分会偏），靠的全是这一章建立的词汇——如果"shard 和 segment 谁装谁"还含糊，那两章会读得磕磕绊绊。所以这里给每个名词一个 ≤30 字的硬定义，再往下挖一层机制，最后用一个类比收尾（并指出类比在哪里失效）。

图 1.1 是这一章的总纲。下面五节，就是把这张图里的每个框单独拎出来定义。读的顺序是从最小的单位（一条文档）往外扩，再下钻到最底层（segment），最后落到那条最高频的字段分水岭。

1.1文档与字段 · document / field / _source

document 是一条 JSON 对象，写入与检索的基本单位；field 是它的键值对；_source 是原始 JSON 的完整副本。

field 就是文档里的每一个键值对："title": "无线降噪耳机" 是一个 field，"price": 899 是另一个。每个 field 有自己的类型（由 mapping 决定，见 1.2），类型决定它怎么被存、怎么被搜。

底层机制（比文档深一层）：_source 和"用于搜索的结构"是两份存储

这是全章第一个、也是最容易被忽略的机制点。把一条文档写进 ES，它在底层至少被拆成两份不同的存储：

• 用于搜索的倒排结构：把字段值切成一个个 term，记录"哪个 term 出现在哪些文档里"。这份结构不保留原文——它只知道 "无线" 这个 term 出现在文档 1、文档 7，但拼不回原始那句 "无线降噪耳机"。
• _source：写入时原始 JSON 的一份完整、未经处理的副本，单独存在磁盘上。

检索时，倒排结构负责"找到哪些文档命中"，但返回给你看的那段 JSON 是从 _source 里取出来的——因为倒排结构根本还原不了原文。这就解释了一个常被当成理所当然、其实很关键的事实：索引结构 ≠ 原文，两者是分开存的。关掉 _source（"_source": {"enabled": false}）能省磁盘，但代价是命中后拿不回原始文档、也没法 reindex——这正是因为搜索结构里没有原文可还原。

类比（带边界）

document 像数据库里的一行记录，field 像一个列。但边界在于：行记录的 schema 是建表时定死的、所有行共享一套列；ES 文档则是 schema-on-write 的 JSON，每条文档可以带不同的字段，mapping 在第一次见到新字段时才动态长出来（见 1.2）。把它当成"严格的表行"会在这里翻车。

小例子

PUT /products/_doc/1
{
  "title": "无线降噪耳机",
  "brand": "Acme",
  "price": 899,
  "tags": ["audio", "wireless"]
}

• products 是 index（这类文档的集合，见 1.2），_doc 是固定端点，1 是这条文档的 _id。
• 请求体整段就是这条 document；title / brand / price / tags 是它的 field。
• 这段 JSON 会被原样存进 _source；同时每个字段按各自类型被拆进搜索结构。两份存储，一次写入。

与下一个概念的关系：一条文档要被存、被搜，ES 得先知道每个字段是什么类型、走哪条索引路径——这套"字段规则"就是 mapping，下一节。

1.2索引与 mapping · index / mapping

index 是一类文档的集合（逻辑分组）；mapping 是定义每个字段如何被存储和索引的 schema。

底层机制（比文档深一层）：mapping 决定字段走哪条索引路径

mapping 不是"声明一下类型"那么轻。它实际决定了每个字段在底层被处理成什么：

• 要不要分词：text 类型的字段会过 analyzer 被切成多个 term；keyword 不分词、整串存一个 term（详见 1.5）。
• 要不要建 doc_values：大多数非 text 字段默认建 doc_values——一份列式磁盘结构，专门支撑排序和聚合（细节在 03 章）。text 默认不建，所以直接对 text 聚合会失败或退化。

同一个字符串值，因为 mapping 不同，可以走完全不同的两条路。这就是为什么 1.5 那条分水岭如此重要——而它的根，就在 mapping。

类比（带边界）

mapping 像关系数据库的表结构（CREATE TABLE 里的列类型）。但边界有两条：① 它默认是动态的，能在写入时自动长出新列，而建表语句是静态的；② 一个字符串字段默认会被映射成两个可用形态——字段本身是 text，外加一个 .keyword 子字段（这叫 multi-field），相当于"一列同时存了分词版和原样版"。关系数据库没有这种"一列两形态"的概念。

小例子

PUT /products
{
  "mappings": {
    "properties": {
      "title": { "type": "text" },
      "brand": { "type": "keyword" },
      "price": { "type": "integer" }
    }
  }
}

• title 声明为 text：会被分词，用于全文检索（搜"耳机"能命中"无线降噪耳机"）。
• brand 声明为 keyword：原样存，用于精确过滤和聚合（按品牌分组统计）。
• price 声明为 integer：默认建 doc_values，可做范围过滤、排序、求和。
• 这里显式区分了 text 和 keyword；若不写 mapping，title 和 brand 都会被 dynamic mapping 推断成 text + .keyword 子字段的组合形态。

与下一个概念的关系：到这里"一条文档怎么被定义、被拆分"清楚了。但这些文档物理上存在哪、怎么扛住单机放不下的数据量？答案是被切片分到多台机器上——这就是集群拓扑。

1.3集群拓扑 · cluster / node / shard 主副本

cluster 是一组协同的 node；node 是一个 ES 进程；shard 是 index 被切成的片，每片是一个独立的 Lucene index。

底层机制（比文档深一层）：写读如何在分片上并行

index 在创建时被切成 N 个 primary shard，由 ES 分布到不同 node 上。每个 primary 可以配置若干 replica（副本）。三条关键规则：

• 写入只走 primary：一条文档先被路由到某个 primary shard 写入，再由它同步给自己的 replica。primary 是这条文档的"写入权威"。
• 读可走 primary 或 replica：查询时，每个 shard（primary 或它的某个 replica，由协调节点挑）并行执行，结果再汇总。replica 越多，并发读吞吐越高。
• primary 与它的 replica 不同 node：否则那台 node 一挂，主副本一起没，容灾就失效了。

类比（带边界）

shard 像分库分表里的一个"分片"——数据按某种规则散到多个库。但边界在于：分库分表的分片是逻辑划分，底层还是普通的库表；ES 的每个 shard 是一个完整、独立、自包含的 Lucene index——它自己有完整的倒排索引、自己的 segment、能独立完成一次搜索。换句话说，shard 不是"半个索引"，而是"一个小而全的索引"。这一点直接通向下一节。

小例子

PUT /products
{
  "settings": {
    "number_of_shards": 2,
    "number_of_replicas": 1
  }
}

• number_of_shards: 2：这个 index 被切成 2 个 primary shard（图 1.1 里的 P0、P1）。这个数之后不能改。
• number_of_replicas: 1：每个 primary 配 1 个副本，于是共 2 primary + 2 replica = 4 个 shard，分布到不同 node。这个数可以随时改。
• 查"耳机"时，2 个 primary（或它们的 replica）并行各搜一半数据，结果汇总返回。

与下一个概念的关系：既然一个 shard 就是一个完整的 Lucene index，那 Lucene index 内部又长什么样？下钻最后一层——segment。

1.4Lucene segment

segment 是 Lucene 写在磁盘上的不可变数据文件；一个 shard 由多个 segment 累加组成。

底层机制（关键，比文档深一层）：shard 是一摞只增不改的 segment

把一个 shard 的内部摊开，它不是一块整数据，而是一摞 segment——每个 segment 自己是一个迷你倒排索引，包含一批文档的全部索引结构。核心性质只有一条，但它撑起后面整整一章：

每个 segment 一旦写出，就再也不被修改——immutable。

"不可变"带来三个直接推论，这里只点名、细节全在 02 章：

• 近实时（refresh）：新文档要先被打包成一个新 segment、且这个 segment 对搜索可见，才能被搜到。这个动作默认每 1 秒做一次——这就是"写完默认 1 秒内搜不到"的来源。细节在 02 章。
• 删除不真删：既然 segment 不可改，删一条文档就不能从 segment 里抠掉，只能在一个单独的 .del 标记里记一笔"这条已删"，搜索时跳过。磁盘空间当时并不释放。细节在 02 章。
• 段合并（merge）：segment 越攒越多会拖慢搜索，ES 在后台把多个小 segment 合并重写成一个大的——这时被标删的文档才真正被丢弃、磁盘才回收。细节在 02 章。

与下一个概念的关系：到这里"东西的层级"从 cluster 一路下钻到了 segment。但有一个贯穿始终、决定字段能不能搜、能不能聚合的分叉还没正面讲——它发生在字段类型这一层，是日常最高频的错配来源。

1.5text vs keyword · 认知分水岭

text 过 analyzer 切成多个 term，可全文检索、不可直接聚合排序；keyword 原样存一个 term，可精确匹配/排序/聚合、不做全文相关性匹配。

底层机制（比文档深一层）：分词路径 vs 列式路径

两种类型在底层是两条完全不同的处理流水线：

• text → 过 analyzer → 进倒排：analyzer 是一条三段流水线——char filter（预处理字符）→ tokenizer（切词）→ token filters（如小写化、去停用词）。"Quick Fox" 经标准 analyzer 产出 term [quick, fox]（注意：小写、拆成两个），这些 term 进倒排索引。text 默认不建 doc_values，所以直接对它聚合/排序会退化到一种叫 fielddata 的堆上结构——把字段值临时加载进 JVM 堆，数据量一大极易 OOM。fielddata / doc_values 的细节在 03 章。
• keyword → 不分词 → 进倒排 + doc_values："Quick Fox" 原封不动作为单个 term 存入（大小写、空格全保留），同时默认建 doc_values——一份列式磁盘结构，专供聚合和排序高效读取。所以 keyword 能分组统计、能排序，但你搜"fox"匹配不到它（它存的是整串 "Quick Fox"，不是 fox）。

这是全章最重要的一节：term 不分词，match 才分词

错配几乎都源于一个混淆：term 查询不分词，match 查询会分词。对一个 text 字段用 term 查原始整句，往往一条都命中不了——因为倒排里存的是小写切词后的 token，不是你给的原句。

小例子

# 写入（title 走 dynamic mapping，得到 text + title.keyword）
PUT /docs/_doc/1
{ "title": "Hello World" }

# ① term 查 analyzed text 字段 —— 0 命中（倒排里是 [hello, world]）
GET /docs/_search
{ "query": { "term": { "title": "Hello World" } } }

# ② match 会分词 —— 命中
GET /docs/_search
{ "query": { "match": { "title": "Hello World" } } }

# ③ 精确匹配 / 聚合，走 .keyword 子字段
GET /docs/_search
{
  "query": { "term": { "title.keyword": "Hello World" } },
  "aggs":  { "by_title": { "terms": { "field": "title.keyword" } } }
}

与全章的关系：1.1–1.4 建立了"东西的层级"，1.5 这条分水岭则贯穿其中——它发生在 1.2 的 mapping 这一层，决定字段值在 1.4 的 segment 倒排里以什么形态存在。下一章（02 写入路径）会把 1.4 的"段不可变"展开成完整的写入与近实时机制；再下一章（03 检索路径）会把 1.5 里点到的 doc_values / fielddata、以及 1.3 里点到的分片路由公式补全。