自测与场景辨析

概念层 A

1. _source 是写入时原始 JSON 的完整副本，和"用于搜索的倒排/列式结构"是两份独立存储。搜索结构只存切词、统计这些便于检索的派生数据、不保留原文，所以命中后要靠 _source 把整条文档还原给调用方。
2. 一个 text 字段（过 analyzer、可全文检索）+ 一个 .keyword 子字段（multi-field，原样、有 doc_values、可精确匹配/排序/聚合）。两者互补：全文搜用字段本身，聚合排序用 .keyword。
3. cluster ⊃ node ⊃（index 被切成的）shard ⊃ Lucene segment。其中 index 是横跨多个 shard 的逻辑集合，shard 才是物理上的 Lucene index 边界，segment 在 shard 内部只增不改。
4. 因为 Lucene segment 一旦写出就不可变；一个 shard 是若干 segment 累加而成。所谓"改"数据，实际是写新 segment + 在旧 segment 里把老版本标记为已删，而不是原地修改。
5. 因为 text 字段存的是经 analyzer 切分、规范化（如小写化）后的 term，例如 "Hello World" 存成 [hello, world]；而 term 查询不分词，拿整串原文去比对，对不上。改法：用 match（会分词），或查 field.keyword（原样存储的子字段）。

原理层 B

1. refresh 把内存 buffer 写成一个新 segment 并打开新 reader，决定文档能不能被搜到（默认 1s，near-real-time）；flush 把 segment fsync 落盘并清空 translog，配合 translog 决定崩溃会不会丢。一个管可见性，一个管持久化，是两条正交的轴。
2. 等到后台 merge 把包含该文档的若干 segment 重写成新 segment 时才回收。因为 segment 不可变，删除当下只能在 .liv 位图里标记 soft delete，旧文档仍占空间；merge 前磁盘甚至可能因新旧 segment 并存而先涨。
3. 倒排索引把每个 term 映射到一个有序的 postings list（doc id 升序）。查询词用同一 analyzer 处理后，在有序 term 词典里二分定位，再对多个 term 的有序 postings 做归并求交/并——全程不碰不相关文档；行存则要逐行扫描、对每个字段做匹配。
4. shard = hash(_routing) % number_of_primary_shards，_routing 默认是 _id。主分片数是公式里的除数（模数），一旦改变，hash % N 会把已存在的每条文档解析到不同分片，旧数据再也定位不到——所以创建后不可变，要改只能 reindex / split / shrink。
5. filter 只问"是/否"、跳过打分，结果按每个不可变 segment缓存成一个 bitset；因为 segment 永不改，这个缓存永不需要失效、可被任意复用。must（query context）要算 _score、无法这样缓存，把本该是 filter 的精确/范围条件放进去，白算分还不进缓存。
6. k1 控制词频饱和：tf 以 tf/(tf+k1) 形式进入，是渐近线，第 10 次出现某词几乎不再加分；b 控制字段长度归一，长于平均的字段被惩罚。所以一个把查询词塞进很短标题的文档，因为字段短、长度归一几乎不罚、词频占比又高，会被 BM25 顶到前面——即使它整体并不相关。
7. 默认不一定一样。IDF 是每个分片用本地文档频率算的，相同 term 在不同分片 IDF 不同；文档少或路由不均时，两条相同文档因落在不同分片而得到不同分。dfs_query_then_fetch 先加一轮收集全局词频，让所有分片用同一套统计打分（多一次往返、更准）。分片填满后偏差自然收敛。
8. 聚合/排序需要"doc → value"的访问方向，倒排索引是反方向的"term → docs"。keyword 默认有 doc_values（写入时就建好的列式磁盘结构，走 OS 文件缓存、堆外读取），所以能聚合排序；text 默认没有 doc_values，要聚合/排序就退化到查询时在 JVM 堆上反转索引的 fielddata，几十 GB、触发 GC/OOM。

应用判别层 C

1. 场景 1：写入路径问题，不是 bug。文档写入后默认要等下一次 refresh（最长约 1s）才进入可搜索的 segment，这就是 near-real-time。验证：等 1s 再搜，或对写入加 ?refresh=wait_for。不要用 ?refresh=true 批量刷，会制造大量小 segment、加重 merge。
2. 场景 2：两个方向。①分片维度：两条文档可能落在不同分片，per-shard IDF 不同导致打分不同——可用 dfs_query_then_fetch 或在数据量足够时观察是否收敛。②字段维度：BM25 的字段长度归一（b）和词频，使较短字段、词频占比高的那条打分更高。先确认是不是同一分片，再看字段长度差异。
3. 场景 3：根因是对 text 字段聚合。text 没有 doc_values，聚合退化到堆上的 fielddata，把整列加载进 JVM 堆 → 熔断/OOM。换成 keyword（或字段的 .keyword 子字段）就好，因为它有列式、堆外的 doc_values。正确做法：聚合/排序一律用 keyword，不要打开 text 的 fielddata。
4. 场景 4：删除已生效，但只是 soft delete——在 .liv 里标记为删，文档仍占着不可变 segment 的空间，所以磁盘不立刻降；新写入/标记还会产生新 segment，短期甚至先涨。等后台 merge 把旧 segment 重写、丢弃被删文档后，空间才回收。可观察 segment 数与 merge 进度，必要时（谨慎）触发 force merge。
5. 场景 5：不合理。分片数创建后不可变，"以防万一先开多"意味着把一个错误锁死；而过度分片本身有代价——每个 shard 是一个独立 Lucene 实例，带固定的堆、文件句柄、集群状态开销，并占用搜索线程。数据量不大时，几百个小分片只会拖慢查询、加重集群状态管理。正确做法：按目标单分片 10–50GB 估算分片数，需要时用 rollover / ILM 扩展。

选型 D

按图 4.2 的顺序排除：海量日志聚合 → ClickHouse；纯向量大规模 → Milvus/Qdrant；要相关性排序的全文/混合检索且规模大 → Elasticsearch；其余中小规模优先 PostgreSQL（FTS / pgvector），少维护一个系统。核心判断：ES 的不可替代价值在"相关性排序的全文 + 混合检索 + 聚合"三合一；只要其中没有"相关性全文检索"这一项，几乎都有更省的专用或通用方案。