Elasticsearch

• Bulk API 的批次大小与并发控制
• 429 的状态码含义与产生原因
• 背压的必要性

Bulk API 是批量写入 ES 的接口，需合理调节批次大小、并发与重试。批次字节数（batch size）通常设为 5-15MB 或按条数（如 1000-5000 条），过大增加单次内存与网络压力、过小降低吞吐；并发数通过多线程/多连接控制，与集群分片数与资源匹配；重试需在客户端对瞬态失败（429、网络抖动）做指数退避重试。当 ES 返回 429（Too Many Requests）时，说明集群写入压力超过承载能力（队列满、线程池拒绝、分片繁忙），此时必须实施背压——暂停/减速写入让集群消化积压，而不是继续压测或盲目重试。因为持续写入会导致队列堆积、线程池耗尽、内存溢出甚至集群不稳定，背压（限制写入速率、并行度、增大批次）是保护集群稳定的关键。工程上常用 Java Client 的 BulkProcessor 管理批次/并发/重试，配合 flow control 实现背压。

429 是"集群忙"的信号，背压是"以退为进"的流控。核心是"不盲目重试、主动限速"。回答要体现批次-并发-重试-背压的系统性调节。

• ES Java Client 的异步 API（CompletableFuture）
• 虚拟线程（Virtual Thread）模型
• 异步与虚拟线程的协作与取舍

ES 8.x Java Client 提供同步与异步两类 API：同步 API 阻塞调用线程，异步 API 返回 CompletableFuture，通过回调/组合（thenApply、thenCompose）实现非阻塞并发，适合高并发异步编排。虚拟线程（Java 21 的 Virtual Thread）是轻量级线程，可数百万级创建，阻塞时被调度器挂起而不占用平台线程。二者协作：可以用虚拟线程运行同步 API，让每个请求占用一个虚拟线程但阻塞不消耗平台线程，从而获得"同步代码 + 异步并发"的简单性与高并发；也可以用异步 API + 虚拟线程实现更精细的编排与超时控制。优势：Java Client 的异步 API 底层仍用 Netty 事件循环，虚拟线程模式下可获得"写起来像同步、跑起来像异步"的吞吐。取舍：异步 API 需要回调/组合思维、调试复杂；虚拟线程更适合 I/O 密集（大量 ES 查询）且代码追求可读性的场景。

抓住"异步 API 返回 CompletableFuture"与"虚拟线程让阻塞不占平台线程"。核心收益是"高并发 + 低平台线程占用"。回答点到两者互补而非替代。

• Ingest Pipeline 的处理器链
• 预写入数据治理（清洗/转换/脱敏）
• 与 Spring Boot 数据写入的协同

Ingest Pipeline 是 ES 端的预处理管线，在文档写入前对数据执行一系列处理器（processor），如 set/rename/remove 字段、gsub 正则替换、date 日期解析、convert 类型转换、grok 解析、enrich 富化、脱敏（mask）、geoip 地理信息等，实现"写入即治理"。在 ES 8.15 与 Spring Boot 4.0 集成中，Spring Boot 应用通过 Java Client 写入文档时，可用 pipeline 参数指定预注册的 pipeline，让 ES 在索引前完成清洗/转换/脱敏，Spring 侧只负责业务数据组装与调用，职责分离。协同模式：轻量治理（类型转换、字段规整、脱敏）放 Ingest Pipeline（ES 侧、不占应用资源）；复杂业务治理（业务规则、关联查询、加密）放 Spring Boot 应用层。需注意 pipeline 失败会导致文档写入失败（除非 ignore_failure），应在 pipeline 中配置 ignore_failure 或 on_failure 处理。这样"应用层业务逻辑 + ES 层数据治理"协同，降低应用负担并统一数据入湖标准。

抓住"Ingest Pipeline 是在 ES 端预处理、写入即治理"。与 Spring 的协同是"轻量治理下沉 ES、复杂业务留应用"。回答要点到 pipeline 失败处理。

• ES|QL 的语法与特点
• 与传统 Query DSL 的对比
• 集成方式与适用场景

ES|QL（Elasticsearch Query Language）是 8.11+ 引入、8.15 增强的声明式查询语言，语法类似管道式的 SQL（FROM index | WHERE ... | STATS ... | LIMIT ...），支持过滤、聚合、排序、函数、多命令管道组合，适合复杂分析查询。与传统 Query DSL（JSON 结构化的查询对象）差异：ES|QL 是文本/管道式、更简洁直观、可表达端到端分析流程（查询+聚合+后处理），而 DSL 是 JSON 嵌套结构、适合精确的结构化查询与官方 API 集成；ES|QL 在复杂聚合/管道分析上更高效，但 DSL 生态（Java Client 的 .query().bool() 构建器）更成熟、类型安全。在 Spring Boot 4.0 集成中，可通过 Java Client 的 client.esql().query() 提交 ES|QL，或传统 client.search() 用 DSL。选择：需要快速分析/管道计算用 ES|QL，需要精细控制与类型安全查询构建用 DSL，二者可互补。

核心对比"管道式文本 SQL vs 结构化 JSON DSL"。ES|QL 强在分析管道，DSL 强在类型安全与生态。回答落到各自优势与集成调用。

• ES ML 异常检测（single/multi metric jobs）
• 异常检测结果（anomaly scorer、bucket）
• 与 Spring Boot 告警联动

ES 8.x 的 Machine Learning 提供异常检测（Anomaly Detection），通过创建 datafeed（数据源）+ job（检测任务）对指标流做单指标/多指标异常检测，输出异常分数（anomaly score）与分桶结果，识别数据中的离群点、趋势突变。与 Spring Boot 业务告警联动实现的思路：①在 ES 侧配置 ML job 与 datafeed，检测异常并把异常结果写入 ES 索引（或通过 anomaly records API 查询）；②Spring Boot 应用用 Java Client 定时拉取异常结果（ml.getRecords / 查询异常索引），过滤异常分数超过阈值（如 70）的记录；③将异常转换为业务告警（通过 Spring 的告警/消息中间件发送邮件、微信、钉钉，或调用告警服务），并写入告警库。此架构把"异常检测（ES ML）"与"业务告警（Spring Boot）"解耦：ES 负责时序检测，Spring 负责阈值判断与通知路由。也可用 ES 的 Alerting（Watcher）直接在 ES 侧触发告警，Spring 侧重业务编排。

抓住"ES ML 做检测、Spring 做告警联动"。核心是"拉取异常分数→阈值判断→通知路由"。回答要体现分层解耦。

• snapshot/restore API 与仓库
• 增量快照与恢复
• Spring Boot 定时灾备

ES 通过 snapshot/restore API 实现数据备份与恢复：先注册快照仓库（snapshot repository，如 S3、HDFS、本地文件系统），再对指定索引/整个集群执行快照（PUT /_snapshot/repo/snapshot），快照是增量的（只存改变的分片，去掉引用计数），可周期执行；恢复用 POST /_snapshot/repo/snapshot/_restore。与 Spring Boot 定时任务结合实现灾备：Spring 的 @Scheduled 定时任务调用 Java Client 的 snapshot API 创建周期快照（如每日凌晨 3 点），并对快照做保留策略（删除过期快照），同时可配置跨集群复制（CCR）实现异地容灾。灾备需验证：定期执行 restore 到测试环境验证可恢复性，并注意快照仓库的异机/异地保存。Spring Boot 定时任务负责"调度、执行、监控、失败告警"，ES snapshot 负责"数据备份"，两者结合形成"定时备份 + 验证恢复 + 告警"的完整灾备链路。

抓住"snapshot 增量备份 + @Scheduled 定时 + restore 验证"。核心是"定时创建、保留策略、恢复演练"。回答要强调"备份还需验证可恢复"。

• 倒排索引结构（term→posting list）
• TF-IDF 与 BM25 算法
• 两者差异

倒排索引（Inverted Index）是 ES 全文检索的核心：建立"词项（term）→ 包含该词的文档列表（posting list，含文档 id、位置、词频）"的映射，查询时先定位词项再快速定位文档，避免线性扫描全部文档。相关性评分用 BM25 算法（Lucene/ES 默认）：BM25 基于 TF（词频）、IDF（逆文档频率）与文档长度归一化。公式核心：score = IDF * (TF * (k1+1)) / (TF + k1 * (1 - b + b * docLen/avgLen))，其中 k1 控制词频饱和（词频越高边际收益递减），b 控制文档长度归一化（文档越长，词频贡献被稀释）。相比 TF-IDF，BM25 改进了 TF 的线性增长（饱和非线性）、引入文档长度归一化，避免长文档因词频高而虚高，评分更稳健、可解释。ES 默认 BM25，可调 k1 与 b 参数。

倒排索引是"反向映射"提速检索，BM25 是"相关性评分"。记住 BM25 相对 TF-IDF 的两点改进：TF 饱和 + 文档长度归一化。参数 k1、b 是常考点。

• Index Template 的机制（match 匹配索引）
• 模板内容（settings/mappings/aliases）
• 优先级与 rollover 结合

索引模板（Index Template）用于在创建新索引时自动应用预设的 settings、mappings、aliases，从而保证同类索引配置一致。机制：当索引名匹配模板的 pattern 时，模板自动生效。新版（8.x）有数据流模板（Data Stream Template）与合成模板（composable template），模板可包含多个组件（component template）组合，优先级 priority 高的模板优先。典型场景：日志/时序数据按日期滚动（如 logs-2024.01.01），用模板统一字段 mapping（如 @timestamp 为 date、level 为 keyword）、副本数、分片数、ILM 别名，配合 rollover 自动切换新索引。模板优先级：显式索引创建时指定的 settings 覆盖模板，多个模板按 priority 决定。模板极大简化运维，避免每个索引手工配置且配置不一致。

抓住"模板在索引创建时自动套用，保证同类索引配置一致"。与 rollover/ILM 配合是时序数据的关键。注意优先级与模板定义。

• Segment 与段合并
• forceMerge 的作用
• 只读索引优化与代价

Lucene 索引以 Segment（段）为最小存储单元，写入先写内存生成小段，后台按 merge 策略合并。Segment 过多会降低查询性能（需搜索更多段）并增加文件句柄。forceMerge（POST /index/_forcemerge?max_num_segments=N）强制把索引合并为指定数量的段（通常为 1），把"只读索引"优化为单段，最大化查询性能并减少文件数。适用场景：只读/低频更新的索引（如历史归档、日报索引），因为 forceMerge 会消耗大量 IO 与 CPU、重写全量数据，频繁更新的索引不宜使用（会造成 merge 风暴）。Segment 数量控制：日常由 merge 策略（TieredMergePolicy）动态合并，index.merge.policy.max_merged_segment 等控制段大小；对只读索引用 forceMerge 收敛到理想段数。注意 forceMerge 后仍需 _flush 或等待 refresh 生效，且对正在写入的索引会阻塞写入。

抓住"forceMerge 把段合并到指定数量，适合只读索引"。核心是"段数影响查询性能，forceMerge 重度但一次性"。答题要强调"只读场景"。

• Reindex 到新索引
• 文档计数校验
• 原子别名切换与回滚

迁移 Mapping（如字段类型变更、新增字段）时采用"新索引 + 回滚机制"的发布策略：①建新索引：按新 mapping 创建新索引（如 index_v2），设置 index.write.wait_for_active_shards 等；②Reindex：用 POST /_reindex 把旧索引数据复制到新索引，可指定 source 与 dest，并配合 op_type=create 防冲突；③校验计数：对比新旧索引的文档数（_count）、字段值取样核对，确保迁移无损；④原子别名切换：用 POST /_aliases 在一个原子操作中把新索引加入别名并移除旧索引别名（actions: [{add:{index:index_v2, alias:app}}, {remove:{index:index_v1, alias:app}}]），应用通过别名访问，切换对应用无感知；⑤回滚：若切换后发现问题，再原子切换回旧索引别名即可回滚。此流程保证"数据校验 + 无感切换 + 可回滚"的安全发布。

抓住"别名作为访问入口 + 原子切换 + 计数校验"。回滚靠"别名再切回旧索引"。这是生产级 migration 的标准做法。

• filter 不参与评分、可用缓存
• must 参与评分
• 精确条件应放 filter

bool 查询的 clause 中：must子句必须匹配且参与相关性评分（影响 _score）；filter子句必须匹配但不参与评分（_score 恒为 0），且其条件可被**查询缓存（filter cache）**复用，因为不依赖评分，相同 filter 可命中缓存，执行更快。因此精确条件（如 term、range、exists、match 的精确过滤）应放在 filter 中：既保证过滤功能，又避免无谓的评分计算，且充分利用缓存提升同条件反复查询的性能。而全文检索（match 等）需要相关性排序时放 must。工程上常见模式：bool 中 filter 放精确过滤条件（category、status、时间范围），must 放全文关键词，must_not 放排除条件。注意 filter 的缓存是"条件结果缓存"，对高频重复查询收益大。

核心区别"filter 不评分、可缓存；must 评分、不缓存"。精确条件放 filter = 性能与正确性兼得。答题要点明"filter 结果缓存"。

• ES Connector 与数据同步
• 双写一致性挑战
• 一致性保障方案

ES 8.x 的 Connector 提供 MySQL 同步能力（基于 CDC 或轮询），把 MySQL 数据同步到 ES。但 Connector 同步与 Spring Boot 业务双写（应用同时写 MySQL 与 ES）会带来一致性问题：双写非原子，可能 MySQL 成功而 ES 失败，或顺序不一致导致数据不一致。保障方案：①以 MySQL 为唯一数据源：应用只写 MySQL，ES 通过 Connector/CDC 从 binlog 异步同步，避免应用双写，天然一致（最终一致）；②若需应用主动写 ES，用本地消息表 + 可靠消息：应用写 MySQL 并在同事务写消息表，由消费端异步同步 ES，失败重试；③重试与补偿：对 ES 写入失败做退避重试、幂等（用文档 id 幂等 upsert）；④对读场景容忍最终一致，用版本号/时间戳比较。主流方案是"应用只写 MySQL，ES 走 CDC 同步"，避免双写复杂性，保证一致性。

核心矛盾是"双写非原子"。最稳方案是"单一数据源 + CDC 异步同步"。回答要强调"避免双写"与"最终一致 + 重试补偿"。

• CCS（Cross-Cluster Search）原理
• 多机房远程集群配置
• 查询路由与本地优先

Cross-Cluster Search（CCS）允许在本地集群上查询远程集群的索引，通过 _cluster/remote 注册远程集群，查询时用 远端集群:索引 语法（如 remote1:logs*）跨集群聚合数据。在多机房 Spring Boot 微服务场景下，查询路由策略：①本地优先：多数查询只访问本地机房的集群，减少跨机房网络延迟；②跨机房聚合：当需要全局数据时，通过 CCS 路由到各机房集群，ccs_minimize_roundtrips 优化往返；③副本/索引分布：把同份数据在每个机房保留副本，查询就近；④代理层路由：Spring Boot 通过网关/代理按机房路由到对应集群，或配置多个 CCS 远程集群实现统一查询入口。CCS 适合"查询分散、数据可跨集群"的场景，但跨机房有网络延迟与带宽成本，需权衡；对强一致或低延迟建议数据本地化或按机房分片。Spring Boot 侧只需配置连接本地集群，用 CCS 远程引用即可。

抓住"远程集群注册 + 远端索引语法 + 本地优先路由"。核心是"就近查询 + 必要时跨集群聚合"。回答强调本地优先与延迟权衡。

• 异步 API 与 CompletableFuture
• 虚拟线程集成
• 并发与资源利用

在 Spring Boot 4.0（基于 Java 21+）中，可结合 ES Java Client 8.x 的异步 API 与虚拟线程提升并发。Java Client 的异步 API 返回 CompletableFuture，不阻塞调用线程；而虚拟线程使得大量阻塞 I/O（如 ES 同步 API 的阻塞调用）也不占用平台线程。两种配合方式：①用虚拟线程跑同步 API：每个 ES 请求占用一个虚拟线程，阻塞时被 Scheduler 挂起，可承载成千上万并发请求，代码是同步的可读性；②用异步 API + 虚拟线程编排：在外层用虚拟线程 join 等待 CompletableFuture，同时做超时/组合控制。Spring Boot 4.0 对虚拟线程默认支持（spring.threads.virtual.enabled=true），HTTP 容器与执行器可配置虚拟线程。收益：ES 查询是典型 I/O 密集，虚拟线程大幅提升并发吞吐、降低平台线程压力，配合异步 API 的编排能力实现高并发低延迟。注意池化虚拟线程或用 Semaphore 限制并发，避免过载。

核心是"ES I/O 密集 + 虚拟线程高并发 + 异步 API 编排"。回答要点到虚拟线程的开启方式与并发控制（信号量）。

• OpenTelemetry 分布式追踪
• ES 慢查询的 span 采集
• 根因分析（链路定位、耗时分解）

OpenTelemetry（OTel）提供标准的分布式追踪与指标采集，在 Spring Cloud 微服务中可用 OTel Java Agent 自动埋点 Java Client 的 ES 调用，生成 span（含 db.system=elasticsearch、查询 DSL、耗时、状态码等属性），把 span 关联到链路（trace）。分析 ES 慢查询根因的步骤：①采集：OTel Agent 自动捕获 ES 请求 span，配合 db.statement（查询语句）与耗时；②定位：在链路图（Jaeger/Tempo）中找出 ES span 耗时长的请求，对比同类请求耗时分布；③分解：结合 ES 侧指标（_cat/thread_pool、慢查询日志、JVM、断路器）判断是"查询本身慢（复杂 DSL/深分页/无缓存）"还是"集群资源紧张（查询饱和/GC/分片不均）"；④优化：针对查询加 filter 缓存、优化 mapping/字段类型、加索引、调整分片、排查慢查询日志（search.slowlog）。OTel 把"应用侧链路 + ES 侧指标"打通，快速定位慢查询是应用问题还是集群问题。

抓住"OTel Agent 自动埋点 ES span + 结合 ES 侧慢查询日志/指标定位根因"。核心是"链路定位 + 集群侧验证"。回答要体现"应用 vs 集群"二分。

• JVM 堆与 GC
• 断路器（circuit breaker）
• 线程池拒绝、分片恢复、磁盘水位

排查 ES 集群不稳定需从多个子系统联动分析：①JVM 堆：堆使用率过高（如 >75%）触发 GC 频繁，导致 CPU 高、查询变慢，需关看 _nodes/stats 的 heap 与 GC；②断路器：当某一操作（查询/写入/request）预计内存超过启发式阈值时，断路器触发 429 拒绝，防止 OOM，需看 _nodes/stats 的 circuit breaker 数；③线程池拒绝：search/write 线程池队列满时拒绝请求（rejected），说明并发超载，需降并发或扩容；④分片恢复：分片恢复（recovery）期间占用资源、集群状态可能 yellow/red，需监控 _cluster/health 与恢复进度；⑤磁盘水位：磁盘达 low/high/flood 水位时，ES 不再分配/迁移分片或只读，需扩容或清理。关联分析：往往"堆满→GC 慢→查询慢→线程池拒绝→触发断路器→429"是一条因果链，磁盘水位影响分片分配与恢复。排查时用 _cluster/health、_nodes/stats、_cat/thread_pool、_cat/recovery 等综合定位。

抓住"JVM 堆、断路器、线程池、分片恢复、磁盘水位"是多维指标，需联动看因果链。核心是"用集群监控 API 综合诊断"。回答要体现"链式关联"。

• Dynamic Template 的匹配规则
• 字段名/类型匹配
• 规则顺序与不可逆后果

Dynamic Template（动态模板）在动态 mapping 时，根据字段名或检测的 JSON 类型把字段映射为指定类型。匹配方式：match（字段名匹配）、match_mapping_type（检测类型匹配，如 long/string/date）、path_match（按路径匹配）、以及 unmatch 排除。例如：{ "match": "created_at", "mapping": { "type": "date" } } 把 created_at 字段映射为 date；{ "match_mapping_type": "string", "mapping": { "type": "keyword" } } 把字符串字段映射为 keyword。规则顺序错误的后果：模板按顺序匹配，先匹配到第一条即生效，若更通用的规则（如匹配所有 string→keyword）排在更具体的规则（如特定字段→date）之前，具体字段会被错误映射为 keyword，导致日期无法按日期查询/聚合。更严重的是mapping 一旦创建不可原地修改（field 类型无法变更），错误映射只能 reindex 到新索引，可能造成数据迁移与不可逆的查询语义错误。因此规则应从"具体到通用"排列，并先在测试索引验证。

抓住"模板按顺序匹配、先匹配先生效"与"mapping 不可变"两个要点。规则顺序错误导致"错误类型 + 需 reindex 修复"。答题强调"具体优先"。

• lambda 构建器（类型安全）
• JSON 字符串查询
• 取舍与错误规避

ES 8.x Java API Client 提供两种查询构建方式：①lambda 构建器（类型安全）：SearchRequest.of(s -> s.index("idx").query(q -> q.bool(b -> b.must(m -> m.match(mt -> mt.field("title").query("kv"))))))，用类型安全的 builder 方法，IDE 可自动补全、编译期检查字段/方法名，减少拼写错误与运行时 DSL 语法错误，是推荐方式；②JSON 字符串：new SearchRequest.Builder().query(Query.of(q -> q.withJson(jsonString))) 或 SearchRequest.Builder().source(Sources.string(json))，直接传 JSON 字符串，灵活、可复用现成 DSL，但无编译期检查、易出错、难维护。取舍：大部分场景用 lambda 构建器（安全、可读），需要动态拼接复杂 DSL 或复用模板 JSON 时用 JSON 字符串。lambda 构建器底层同样生成 DSL 结构，只是类型安全封装。注意 lambda 的 withJson 与 source 混用时的 JSON 解析错误。

核心是"lambda 类型安全 vs JSON 灵活"。推荐 lambda 构建器，JSON 用于动态/复用场景。答题要点明"编译期检查"的价值。

• Index Sorting 机制
• 高基数字段排序的代价
• 内存/磁盘权衡

Index Sorting（索引排序）让索引在写入时按指定字段值排序存储，使相近值集中在相邻段/块，从而提升范围查询（range）与聚合的局部性、降低排序开销。其代价：排序本身需要额外 CPU 与磁盘 IO（写入时排序），且排序字段会限制文档的物理顺序。对高基数字段（如唯一的 UUID、时间戳）排序时：①排序字段值分布均匀、无重复，无法利用相邻值分组，范围查询的局部性收益有限，还需维护排序的索引结构，磁盘占用与内存（fielddata/排序缓存）增加；②高基数排序字段使每个文档的排序键唯一，排序树/缓存开销大，内存与磁盘代价显著。因此 Index Sorting 适合低基数/高重复字段（如时间桶、分类）以提升范围查询，不适合高基数字段（收益低、代价高）。权衡：排序字段选低基数、高频过滤字段，避免高基数唯一字段。

抓住"Index Sorting 靠值集中提升局部性，高基数值不集中、收益低代价高"。核心是"低基数字段受益、高基数字段吃亏"。答题要落到字段选择。

• 8.x 默认安全开启
• TLS 加密与 HTTPS
• 认证与证书配置

ES 8.x 默认开启安全防护（security），与 7.x 默认关闭不同：8.x 首次启动自动生成 TLS 证书，启用 HTTPS（443/9200）加密传输，并默认启用用户认证（如内置 elastic 超级用户，自动生成密码）。这改变了连接方式：客户端需用 HTTPS 协议、配置 CA 证书（ca.crt）、提供用户名/密码或 API key，curl 需 -k 或指定证书。TLS 加密保障传输层安全（防窃听/篡改），认证保障身份（认证谁在访问）。若需关闭安全（如内部测试）可显式配置 xpack.security.enabled=false 与 xpack.security.http.ssl.enabled=false，但生产必须开启。Java Client 连接需配置 SSLContext（加载 CA 证书）与 BasicAuth 或 API key。8.x 默认安全是"安全默认开启"的云原生转变，防止默认暴露。

抓住"8.x 默认 TLS + 认证"，与 7.x 默认关闭对比。核心是"HTTPS 传输 + 证书 + 认证"三要素。回答强调与旧版本连接方式差异。

• OpenSearch 的由来与兼容性
• Elasticsearch 与 OpenSearch 的关系
• 选择考虑

OpenSearch 是 AWS 在 Elasticsearch 7.10（Apache 2.0 许可）基础上 fork 出来的开源分支，与 Elasticsearch 7.10 有 API 兼容性（支持大部分 7.x 的 DSL、REST API），但后续各自独立演进：Elasticsearch 8.x 走向"默认安全、ES|QL、与 Elastic 商业生态深度绑定（部分高级功能如 ML 为付费/白金版）"；OpenSearch 延续 Apache 2.0 开源、免费，加入自己的 OpenSearch Dashboards、安全插件等。边界：两者底层同为 Lucene，但 ES 8.x 与 OpenSearch 已有 API 差异（如 ES 8 的 ILM/DSL 细节、OpenSearch 的 _search 兼容层），不能简单互换。选择考虑：①是否需 ES 8.x 新特性（ES|QL、默认安全、K8s Operator 等）——选 ES；②开源免费、无商业授权约束、AWS 生态——选 OpenSearch；③迁移成本：已有 ES 7.x 代码需评估兼容性。本质是"Elastic 商业生态 vs 完全开源分支"的取舍。

抓住"OpenSearch 是 ES 7.10 的 fork，8.x 后两者分道扬镳"。核心是"许可与生态差异 + 兼容性边界"。回答要客观。

• 主分片数不可变的原因
• 分片大小与并行度权衡
• 容量规划建议

ES 主分片数量在索引创建时确定，无法原地修改（reindex 才能改变），因为主分片是数据路由与分布的物理单元，routing = hash(id) % num_primary_shards，改变分片数会导致路由全部失效、需全量重分布。因此分片数规划必须谨慎。权衡分片大小与并行度：①分片是查询与写入的并行度单位，分片越多并行度越高，但分片过多带来元数据开销、文件句柄、merge 与 GC 压力；②分片过大会导致单分片查询慢、恢复慢、写入瓶颈；③业界经验：单分片 20-50GB 为宜，单分片过大（>100GB）查询与恢复性能差。分片数设计公式：分片数 = 数据量 / 单分片目标大小，且考虑节点数与副本（总分片 ≈ 主分片 × (1+副本数)）。容量规划：按数据增长率预留分片，宁多勿少（因为不能增加主分片），结合 ILM 与 rollover 管理滚动索引。对大数据量用 ILM 按时间滚动，避免单索引分片无限增长。

核心是"主分片数=路由依据，不可变"。权衡是"分片多＝并行高但开销大、分片少＝单片大但慢"。规划要"一次性定准 + 用 rollover 缓解"。

• ILM 的 phase（Hot/Warm/Cold/Delete）
• 策略与 rollover
• 索引生命周期管理

ILM（Index Lifecycle Management）自动管理索引生命周期，通过策略（policy）定义索引的 phase 与动作。标准 phase：Hot（热，写入/高频访问）、Warm（温，只读/低频）、Cold（冷，只读/低访问，可缩副本）、Frozen（冻结，极冷）、Delete（删除，到期清理）。每个 phase 可配置 action，如 rollover（按大小/时间/文档数滚动新索引）、shrink（缩分片）、forcemerge（合并段）、allocate（迁移到特定节点）、delete（删除过期索引）。机制：索引被策略关联后，随 rollover 或条件进入下一 phase，ILM 自动执行动作。用于时序/日志数据管理：热索引接收写入，随规模增长 rollover 出新索引，旧索引逐步 warm/cold/delete，实现存储分层与自动化清理。配置：PUT /_ilm/policy/xxx + 索引 index.lifecycle.name。ILM 减少人工运维，结合"分片+段+副本"优化各阶段存储。

抓住"phase 流水线 + 各 phase 动作"。核心是"热写冷读删 + rollover 自动滚动"。回答要体现"生命周期自动化"。

• Mapping 的定义与作用
• 常用字段类型
• 类型选择与 text/keyword 区别

Mapping 定义索引中文档的字段结构（字段名、类型、分析器、参数），决定数据如何被索引与检索。常用字段类型：keyword（精确值，不分析，用于 term/聚合/排序）、text（全文，经过分析，用于 match 全文检索）、long/integer/double（数值，用于 range/聚合）、date（日期，支持格式与时间范围）、boolean、object/nested（嵌套对象）、ip（IP 地址）、geo_point（地理位置）、binary、flattened（扁平对象）等。关键点：text 与 keyword 的选择——text 分词可全文检索，keyword 不分词可精确匹配/聚合/排序；同一字段可同时用 text 与 keyword（多字段 fields）。Mapping 分 dynamic（自动映射）与 explicit（显式定义）。Mapping 一旦创建，字段类型大多不可修改，需在写入前规划好类型，避免 reindex 成本。

抓住"Mapping 决定字段如何索引检索"。核心是"text 全文 vs keyword 精确"的类型选择。回答要覆盖常见类型与不可变性。

• Dynamic Mapping 自动映射
• Explicit Mapping 显式定义
• 选择与禁用 dynamic

Mapping 分两种定义方式：Dynamic Mapping（动态）：索引写入新字段时，ES 根据字段的 JSON 值自动推断类型（如字符串→text、数值→long、日期→date），默认开启，方便快速写入但类型不被控制（如字符串被默认映射为 text+keyword、大数字溢出字段类型）；Explicit Mapping（显式）：在创建索引时预先定义每个字段的类型与参数，类型可控、可优化，避免 dynamic 的错误推断。选择：生产环境、类型敏感或需精确控制的分词/聚合/排序字段用显式 mapping；快速原型或字段不确定时用 dynamic。可用 dynamic 参数控制新字段行为：true（自动映射）、strict（未知字段报错）、false（忽略，不索引）。最佳实践：核心字段显式定义，配合 dynamic template 统一次要字段，避免 dynamic 的失控映射导致后续 reindex。

核心是"dynamic 自动推断 vs explicit 显式控制"。生产用 explicit + dynamic template。回答要点到 dynamic 三态（true/strict/false）。

• PIT 的概念与创建
• 一致性读与深分页
• 与 search_after 配合

PIT（Point In Time）是 ES 提供的一致快照读取机制：通过 POST /index/_pit 创建 PIT，返回一个 point-in-time id，之后所有查询在"该时间点创建的索引视图"上执行，保证数据在查询期间保持一致（不受后续写入/删除影响）。PIT 常用于：①深分页：配合 search_after 做稳定分页，避免 from+size 的深分页限制，且 PIT 保证分页过程中数据一致（scroll 已被替代）；②一致性读：在嵌套查询/多次查询间保证同一数据视图，避免数据漂移。PIT 需在 keep_alive 内使用，用完删除（DELETE /_pit）。用法：先创建 PIT 得到 id，search 请求带 pit: {id} 与 search_after，滚页时传入上一页的 sort 值。与 scroll 相比，PIT 更轻量、支持任意查询、与 search_after 天然配合，是 ES 8 推荐的分页方案。

抓住"PIT 是时间点快照视图 + 一致性读 + 深分页"。核心是"固定数据视图 + search_after 稳定分页"。答题要点到 PIT 取代 scroll。

• dense_vector 与 HNSW 索引
• 向量相似度（余弦等）
• 语义搜索/kNN 与 RAG

ES 8.x 支持向量检索（Vector Search）：通过 dense_vector 字段类型存储向量（如文本/图片的 embedding），用 HNSW（Hierarchical Navigable Small World）图索引做近似最近邻（ANN）检索，支持余弦相似度、欧氏距离、内积等度量。语义搜索流程：①用模型（如 BERT、OpenAI embedding）把文本转为向量；②写入 ES 的 dense_vector 字段；③查询时把查询文本转向量，用 knn 查询做近邻检索，返回语义最相近的文档。HNSW 通过多层图加速近邻查找，牺牲较小精度换取高吞吐，num_candidates 控制候选规模。语义搜索与关键词（BM25）互补：可做混合检索（hybrid search，结合 keyword 与向量），或用于 RAG（检索增强生成）——先向量检索相关文档，再喂给 LLM 生成答案。ES 配合 Spring AI 等可构建文档问答系统。

抓住"dense_vector + HNSW 近似近邻 + 相似度度量"。核心是"embedding 向量化 + kNN 检索 + 语义相近"。答题要点到与 BM25 混合与 RAG。

• _source 字段的作用
• stored_fields 与 doc values
• 存储与查询取舍

_source 是文档的原始 JSON 存储，默认保存，用于返回文档内容、reindex、脚本（painless 访问 ctx._source）、部分更新等；stored_fields 是另外显式存储的字段（默认不存，只有显式 store: true 的字段），用于快速返回特定字段而不读整个 _source。取舍：_source占用额外存储（约为原始数据量的 1-2 倍），但提供完整原始数据与回写能力；若对存储敏感且不需要原始文档，可 _source: false 关闭，但将失去 reindex/部分更新/脚本能力（只能靠 doc_values 或 stored_fields 取字段）。stored_fields存储特定字段，缩短读路径但增加存储，且对字段更新/聚合（需 doc_values）无帮助。doc_values（列式）用于聚合/排序/精确查询，与 _source 分离。实际选择：默认保留 _source（灵活），超大存储敏感场景用 _source: false + 需要的 stored_fields/doc_values，用 _source 过滤（_source: ["field1","field2"]）只返回部分字段。

抓住"_source 存原始 JSON、stored_fields 存指定字段、doc_values 存列式"。取舍是"存储 vs 功能"。答题要点到关闭 _source 的代价。

• bulk API 的格式与批量操作
• 批量导入优化
• 与性能（429/refresh）关系

bulk API 用于批量执行多个写操作（index/create/update/delete），格式为 NDJSON（每操作一行元数据 + 可选数据行），一次请求可含多条操作，显著减少网络往返、提升写入吞吐。优化要点：①批次大小：按条数（如 1000-5000）或字节（如 5-15MB）控制，过大增加内存与单次耗时、过小降低吞吐；②并发：多线程并发提交，配合 refresh 策略（refresh=false 减少每次刷新开销，批量导入一般用 refresh=wait_for 或 false）；③禁用/降低 refresh：批量导入时临时提高 refresh_interval 或关闭 refresh，减少段刷新开销；④处理 429：对拒绝做退避重试（背压）；⑤使用 Java Client 的 BulkProcessor：自动管理批次、并发、重试、flush。批量导入是大数据写入 ES 的主流方式，比逐条写入快一个数量级。

抓住"bulk 一次多操作、NDJSON"与"批次/并发/refresh 优化"三个要点。核心是"减少往返 + 控制 refresh"。答题要点到 BulkProcessor。

• cat API 的用途
• 常用 cat 命令
• 监控/诊断价值

cat API（_cat/*）以紧凑、易读的表格形式返回集群各类信息，用于命令行监控与诊断。常用命令：_cat/health（集群健康状态/红黄绿）、_cat/nodes（节点 CPU/内存/负载/磁盘）、_cat/indices（索引分片/文档数/存储大小）、_cat/shards（分片分布与状态）、_cat/thread_pool（线程池队列/拒绝）、_cat/master（主节点）、_cat/allocation（分片节点分配）、_cat/recovery（分片恢复进度）、_cat/segments（段信息）。cat 命令支持 ?v（带表头）、?h（指定列）、?s（排序）、?format=json（JSON 输出）。价值：快速定位集群健康、节点负载不均、分片未分配、磁盘水位、线程池拒绝等问题，是运维排障的第一手工具。例如 curl -s localhost:9200/_cat/indices?v&s=pri.store.size:desc 查看存储最大的索引。

抓住"cat API 是紧凑表格化集群监控"。核心是"按需选命令 + 用标志位格式化"。答题要点到 health/nodes/indices/shards 等常用命令。

• index.sort 索引排序
• _doc 排序（文档分段顺序）
• 场景与性能

index.sort 是索引级配置，让文档在写入时按指定字段物理排序，使相近值集中，提升范围查询/聚合的局部性，但会改变文档顺序、增加写入开销。_doc 排序是按文档在段内的存储顺序排序，不按任何字段值，是最快、几乎零开销的排序方式。区别：index.sort 定义"索引数据如何物理排列"，_doc 是"查询时按物理顺序返回的排序键"。场景：_doc 排序常用于推进滚动/分页（配合 search_after 按 _doc 顺序翻页，无需额外字段，开销最小），适合按"存储顺序"检索不需逻辑排序的场景；index.sort 用于需要按特定字段（如时间戳）做高效的 range 查询/最新数据取数。使用 _doc 排序时需注意结合 PIT 保证一致性，且 _doc 的物理顺序在索引 sort 生效时可能改变。若已配置 index.sort，_doc 排序会返回按 index.sort 顺序排列的文档。

抓住"index.sort 是写入时物理排序、_doc 是按存储顺序的查询排序键"。核心是"_doc 零开销翻页 + index.sort 提升范围查询"。答题要点到两者关系。

• text 分词全文检索
• keyword 精确值
• 选择与多字段

text 与 keyword 是 ES 最常用的字符串字段类型，二者核心区别在于是否分词（analyze）：text 类型会经过分析器分词（如按空格/中文分词器切分），支持全文检索（match、match_phrase），用于"搜索内容"（如标题、描述）；keyword 类型不分词，作为一个整体索引，支持精确匹配（term）、聚合（aggs）、排序（sort），用于"精确值"（如状态、ID、标签、URL）。选择：需要全文模糊检索用 text；需要精确匹配/聚合/排序用 keyword。同一字段可同时用两者（多字段 fields）：定义 name 为 text，加 name.keyword 为 keyword，既支持全文搜索又支持聚合/排序。注意：对 keyword 做 term 查询需完全匹配；对 text 做聚合需 fielddata（内存开销大，不推荐）。生产常把"可搜索+可聚合"字段配置为 text+keyword 双字段。

核心是"text 分词、keyword 不分词"。text 全文、keyword 精确/聚合/排序。回答要点到多字段 fields 的用法。

• nested 嵌套对象
• join 父子关系
• 使用场景与代价

nested 与 join 都用于处理对象之间的关系，但机制不同：nested把数组中的每个对象作为独立隐藏文档存储，保证对象内部字段的关联（如 users: [{name: A, age: 20}, {name: B, age: 30}] 中 A 与 20 的关联），nested 查询（nested query）可跨对象内字段精确匹配；适合一对多、对象内部字段需同时匹配的场景（如订单项、评论）。join定义父子关系（parent/child），通过 join 字段类型实现，父子文档在同一分片存储，支持 has_child/has_parent 查询；适合父子文档独立更新、关系重度的场景（如文档与其回复）。代价：nested 每个对象都是独立文档，查询/更新需处理隐藏文档，写入与查询成本高、内存占用大；join 父子查询需额外 join 操作，且父子文档耦合（父更新会重写子分片）。选择：维护对象内关联用 nested，维护父子多对一关系用 join；对简单数组关系用 object（不做关联）更省。

抓住"nested 独立隐藏文档保数组内关联、join 父子同分片"。核心是"对象内 vs 父子间"。回答要点到两者代价与适用区别。

• pipeline 聚合（对聚合结果再聚合）
• 常用 pipeline 类型
• 与可视化结合

Pipeline 聚合是对其他聚合的结果做二次聚合/计算，而非直接对源文档。常见类型：bucket_script（对多桶值做脚本计算）、bucket_selector（按条件过滤桶）、avg_bucket/sum_bucket/min_bucket/max_bucket（对桶结果求统计）、derivative（桶间差值/变化率）、moving_avg（移动平均）、stats_bucket 等。pipeline 聚合通过 pipelines 引用父聚合（如 buckets_path）结果，常用于"在时间桶聚合基础上计算趋势、占比、变化率"。与可视化结合：pipeline 聚合结果可直接用于 Kibana 的指标/图表（如趋势图、移动平均线、环比变化），支撑仪表盘分析。示例：先 date_histogram 按天聚合，再 moving_avg 做平滑、derivative 看变化率，从而在可视化中呈现趋势。注意 pipeline 聚合基于父聚合结果，父聚合需返回桶。

抓住"pipeline 是对聚合结果再聚合"。核心是"buckets_path 引用父桶 + 二次计算"。答题要点到常用类型与可视化应用。

• 两种查询执行阶段
• dfs 的全局词频
• 相关性准确性与性能取舍

ES 默认的查询执行机制是 query_then_fetch：分两步——query 阶段在各分片本地搜索并返回文档 id 与本地评分，fetch 阶段按全局排序取回文档。因为评分在分片本地计算（基于本地分片的词频 IDF），对多分片索引，全局 IDF 与分片 IDF 有偏差，导致相关性评分全局不一致。dfs_query_then_fetch 增加 dfs 阶段：先查询所有分片统计全局词频/IDF，再分片查询，从而评分更准确、与"单分片"评分一致。取舍：dfs_query_then_fetch 准确性高（全局词频），但多一次 dfs 查询所有分片的额外开销，性能下降，适合精确相关性场景（如搜索排序、分片少时）；query_then_fetch 性能好（默认），但多分片时评分有偏差。对多数场景 query_then_fetch 足够，需要精确相关性且分片不平衡时用 dfs。也可用 search_type 或配合调优减少偏差。

核心是"query_then_fetch 分片本地评分 vs dfs 加全局词频阶段"。取舍是"准确性 vs 性能"。答题要点到 dfs 的额外开销。

• reindex 的机制
• 数据迁移场景（mapping 变更、跨集群）
• 注意事项与优化

reindex 把数据从一个索引复制到另一个索引（POST /_reindex），用于：①mapping 变更（字段类型/分词器修改后需重建索引）；②调整分片数/副本；③索引合并/拆分（_split/_shrink）；④跨集群迁移（POST /_reindex 配合 remote）；⑤数据清理/过滤（reindex 时用 query 过滤）。注意事项：①reindex 消耗集群资源，大索引需控制并发（slices 并行切片）与请求大小，避免写放大；②reindex 前需建好目标索引（含新 mapping），用 op_type=create 防冲突；③跨集群时需配置远程集群白名单与网络；④reindex 后需校验文档数一致（_count）；⑤用 _source 决定是否复制原始数据。优化：用 slices 自动并行、refresh 批量后刷新、wait_for_completion 异步执行。reindex 是 ES 数据迁移与 mapping 演进的核心工具。

抓住"reindex 从源索引复制到目标索引"。核心是"mapping 变更/迁移/重建"。答题要点到并行切片、校验、op_type。

• runtime fields 定义与查询
• 动态计算字段
• 与索引字段取舍

Runtime Fields（运行时字段）是在查询时动态计算的字段，不预先存储于索引，通过脚本（painless）或从已有字段推导，在查询/聚合时按需计算。定义方式：runtime_mappings 中声明（如从 timestamp 提取日期、用 source 字段解析、grok 解析日志），查询时 ES 用脚本计算字段值参与过滤/聚合/排序。场景：①对未索引或 _source 中的字段直接查询/聚合（无需 reindex）；②在已有字段上做转换/派生（如日期格式化、字符串拼接）；③快速原型/临时字段，避免重建索引。取舍：runtime fields 不占索引存储、灵活，但查询性能差（运行时计算，无倒排索引/doc values 加速，需扫描并计算），适合低频、字段量少、或临时分析；对高频查询/大字段应改用正式索引字段（写入时计算）。ES 8.x 支持 runtime fields 用于 _source、索引字段、match_only_text 等。注意 runtime fields 无法用于 doc_values 优化，聚合性能受限。

抓住"runtime fields 查询时动态计算、不索引存储"。核心是"灵活省存储但性能差"。答题要点到"临时/低频场景 + 避免高频"。

• search_after 滚动分页
• from+size 深分页限制
• 与 PIT 配合

ES 分页方式：from+size简单（从第 N 条开始取 size 条），但深分页有性能上限：index.max_result_window（默认 10000）限制 from+size 的跨度，且深分页时每个分片都要取 from+size 条候选再合并，from 越大资源开销越大，故深分页不可用。search_after用上一页最后一条的排序值（sort 数组）作为下一页起点，向后滚动取下一页，避免重新计算前 N 条，适合深分页/滚动翻页。search_after 要求：①排序字段唯一（避免并列时丢数据），常加 _shard_doc 或唯一字段作 tiebreaker；②配合PIT（point-in-time）保证分页期间数据一致（避免滚动中数据变化导致重复/遗漏）。search_after 无法随机跳页（只能顺序向后），适合"瀑布流/无限滚动"；需要跳页用 from+size（浅分页）或 PIT 组合。ES 8 推荐 search_after + PIT 做深分页，替代已废弃的 scroll。

抓住"from+size 深分页超限、search_after 用排序值滚动"。核心是"排序值起点 + PIT 一致性 + 唯一 tiebreaker"。答题要点到 max_result_window。

• Analyzer 的三组件（char filter/tokenizer/token filter）
• 内置分词器
• 中文 IK 分词器

Analyzer（分析器）用于把文本字段分词，由三部分组成：Character Filter（字符过滤，如 HTML 剥离、替换）、Tokenizer（分词器，把文本切成词项，如 standard、whitespace、keyword）、Token Filter（词项过滤，如小写化、停用词、词干化、同义词）。内置分析器：standard（默认）、keyword（不分词）、simple、whitespace、english 等。中文分词（IK）：IK 是常用的中文分词器，支持 ik_max_word（细粒度/最细切分，召回多）与 ik_smart（粗粒度/智能切分，精准）。配置：安装 ik 插件后，在 mapping 的 analyzers 中指定 "analyzer": "ik_max_word"（索引时）与 "search_analyzer": "ik_smart"（查询时），并配置自定义词典（IKAnalyzer.cfg.xml + 自定义词典文件）扩展业务词。中文分词需注意：索引与查询分词器可不同（索引用 max_word 召回、查询用 smart 精准），并配合词库维护提升准确率。分词的粒度影响检索召回与准确率，需按业务权衡。

抓住"Analyzer 三组件 + IK 双粒度"。核心是"char filter→tokenizer→token filter 流水线"。答题要点到 ik_max_word/ik_smart 与自定义词典。

• Cluster 与 Node 的角色
• Index 与 Shard 的划分
• 分片与副本

ES 架构层级：Cluster（集群）由多个 Node（节点）组成，通过节点发现机制通信，有主节点（master）负责集群元数据与分片分配；Node按角色分：master-eligible（可竞选主节点）、data（数据节点，存分片）、ingest（预处理节点）、coordinate（协调节点，接收请求路由）。Index（索引）是逻辑上的文档集合，分成多个 Shard（分片）：**主分片（primary shard）**数在索引创建时固定，决定数据路由与并行度；**副本分片（replica）**是主分片的拷贝，提供高可用与读写分离（读可走副本）。每个分片内部是一个 Lucene 索引（由多个 Segment 组成）。数据分布：routing = hash(document_id) % num_primary_shards 决定文档落在哪个主分片。写入先写主分片再同步副本，读可路由到主或副本。协调节点聚合各分片结果。理解"索引→分片→段"的层级是 ES 运维与调优的基础。

抓住"Cluster→Node→Index→Shard→Segment"层级。核心是"主分片定路由、副本保高可用"。答题要点到分片内部是 Lucene 索引。

• match 全文检索
• term 精确匹配
• bool 组合查询

ES 查询 DSL 是 JSON 结构化查询，核心组件：match（全文检索）：对查询文本分词后与字段的倒排索引匹配，返回相关性评分（如 match: {title: "elastic search"}），用于 text 字段；term（精确匹配）：对字段做精确值匹配、不分词（如 term: {status: "active"}），用于 keyword/数值字段，匹配倒排索引中的词项；bool（组合）：组合查询逻辑，含 must（必须匹配且评分）、filter（必须匹配不评分可缓存）、should（至少一个匹配，可提升相关性）、must_not（必须不匹配），用于构建复杂过滤与检索；agg（聚合）：对查询结果做统计聚合（aggs），如 terms（按字段分组）、date_histogram（时间桶）、avg/sum/min/max 等，可与查询（query）组合，实现"先过滤后聚合"。DSL 通过 query（检索）与 aggs（聚合）区分布尔。示例：bool 中 filter 放精确条件、must 放 match 全文，aggs 做分组统计。选择依据：全文检索用 match，精确匹配用 term/keyword，组合用 bool，统计用 agg。

抓住"match vs term 是全文 vs 精确、bool 组合、agg 聚合"四个核心。答题要点到 term 不分词、filter 不评分。

• BM25 公式与因子
• k1、b 参数
• 评分与字段配置

ES（Lucene）默认使用 BM25 算法计算相关性评分（_score）。BM25 公式：score = IDF * (tf * (k1 + 1)) / (tf + k1 * (1 - b + b * (docLen / avgDocLen)))。其中：tf（词频）：词在文档中出现的次数，BM25 对词频做饱和处理（超过一定次数后边际收益递减，由 k1 控制，默认 1.2）；IDF（逆文档频率）：词在所有文档中的稀有度（越稀有贡献越大），term 出现在越少文档得分越高；b（长度归一化系数）：控制文档长度的影响，默认 0.75，b 越大则长文档中词频贡献被稀释越多。参数 k1、b 可通过 index.analysis.similarity 或索引设置调整（similarity 配置），影响评分偏好。评分基于字段计算（每个字段独立 IDF），多字段可用 multi_match 或权重（boost）调整。BM25 相对 TF-IDF 的改进是词频饱和与长度归一化，使评分更稳健。理解 BM25 有助于解释"为什么短文档常得分更高""稀有词权重更大"。

抓住"BM25 的 tf 饱和 + IDF + 长度归一化"。k1 控词频饱和、b 控长度影响。答题要点到"长文档词频被稀释"。

• 聚合类型（metric/bucket/pipeline）
• 聚合与查询组合
• 性能与限制

ES 聚合（Aggregation）用于对查询结果做统计分析，分三类：Metric 聚合（数值统计）：avg、sum、min、max、cardinality（去重计数）、percentiles 等，对字段做统计；Bucket 聚合（分组分桶）：terms（按字段值分组）、date_histogram（按时间分桶）、range（数值区间）、histogram（数值桶）、nested/filter 等，返回分组桶；Pipeline 聚合（对聚合结果再聚合）：avg_bucket、derivative、moving_avg 等。聚合与查询（query）组合：先 query 过滤文档，再 aggs 聚合，实现"先过滤后统计"。聚合的关键机制：依赖 doc_values（列式存储）而非倒排索引，因此聚合字段需为 keyword/数值/date 且开启 doc_values。性能：聚合在分片并行执行后合并，terms 聚合 shard_size 控制分片返回候选数，cardinality 用近似算法（HLL）省内存。注意：高基数字段聚合耗内存、text 字段聚合需 fielddata（内存大，不推荐）。聚合是 ES 分析与可视化（Kibana）的基础。

抓住"metric 统计、bucket 分桶、pipeline 二次聚合"三类。核心是"依赖 doc_values + 先查询后聚合"。答题要点到 shard_size 与 cardinality 近似。

• 写入与 refresh 流程
• refresh_interval
• 近实时性与可见性

ES 是近实时（Near Real Time, NRT）搜索：写入的数据不会立即可见，需经过 refresh才可被搜索。写入流程：文档先写入内存缓冲（buffer）与 translog（事务日志，保证持久性），系统默认每1 秒（index.refresh_interval）执行一次 refresh，把缓冲数据生成一个可搜索的 Segment，之后文档才可被查询。因此"写入到可搜索"默认约 1 秒延迟，这就是近实时。refresh 只是"让数据可搜索"，不保证持久化（持久化靠 translog flush 与段落盘）。可调 refresh_interval：调大（如 30s）可减少段数与刷新开销、提升批量写吞吐，但降低搜索可见性；调小（或 refresh=true 强制刷新）提升可见性但增加开销。批量导入常用 refresh_interval=-1 或 refresh=false 先关闭刷新，导入完再刷新。理解 refresh 与 translog 的区别：refresh 管"可见性"，translog/flush 管"持久性"。

抓住"refresh 每秒生成段使数据可搜索、translog 管持久性"。核心是"近实时=1 秒可见性 + 可调 refresh_interval"。答题要点到 refresh 与 flush 分工。

• 向量检索叠加过滤
• 过滤选择性对召回率影响
• 候选扩展参数（num_candidates）

HNSW 向量检索（kNN）叠加结构化过滤（如 filter 条件）时，过滤的选择性（selectivity）显著影响召回率。原因是：HNSW 的先做近似近邻搜索（在向量图上找候选），再做过滤；若过滤条件选择性高（命中的文档很少），则过滤后候选可能不足 k 个，或真正相关的向量被过滤掉，导致召回率下降。缓解：增大候选数 num_candidates（kNN 查询时先取更多候选向量再过滤，如把默认候选从 k 提升到 k×倍数），以在过滤后仍有足够候选；同时可配合 filter 在搜索前先缩小范围（filter 先执行缩小候选集）。取舍：num_candidates 过大增加计算与内存（需在图上扩搜）、查询变慢；过小则过滤后召回不足。因此对高选择性过滤应增大候选、对低选择性可保持默认。工程上需结合召回率（recall）评估实验调参，验证过滤后召回是否达标。ES 8.x 的 knn 查询支持 filter 与 num_candidates 参数。

抓住"先近似近邻再过滤，过滤选择性高会削减候选"。核心是"增大 num_candidates 补偿召回"。答题要点到"过滤后候选不足"的机理。

• rollover 触发条件（age/size/doc_count）
• 多条件组合
• 主分片差异影响

ILM 的 rollover 用于把写入索引滚动到新索引，触发条件可基于年龄（age）、大小（size）、文档数（doc_count）或其组合：max_age（超过指定时间滚动）、max_size（主分片总大小超过阈值）、max_docs（主分片文档数超过阈值）。多条件满足其一即触发（OR 语义）。选择依据：按大小触发最贴近"分片规模"（避免单片过大），如 max_size: 50gb；按文档数触发适合文档体积小但量大、需控制分片内文档量的场景；按年龄触发适合固定时间周期（如每天/每周一个索引）。主分片差异影响：rollover 的 size/docs 阈值基于主分片（primary shards）的总量，而非整个索引（含副本）。若主分片数据分布不均（各主分片大小不同），max_size 基于所有主分片总和，可能部分主分片已超阈值而整体未达到，导致部分分片过大未及时滚动；因此阈值设置需考虑主分片数量与分布，避免单片过大。通常用 max_size 与 max_age 组合，并用 max_primary_shard_size（8.x）按最大单个主分片触发，更精确。

抓住"rollover 按 age/size/docs 其一触发、基于主分片"。核心是"主分片大小差异影响阈值判断"。答题要点到 max_primary_shard_size。

• Segment 写入与 merge
• TieredMergePolicy 策略
• merge 对写入的影响与配置

Lucene 写入先在内存生成小段，后台把多个段合并（merge）成大段，以控制段数量、提升查询性能。但 merge 需要重写数据（读源段写新段），消耗 IO 与 CPU，若写入频繁导致 merge 追不上写入，会造成 merge 风暴（merge 排队、写入变慢、磁盘 IO 高）。TieredMergePolicy（ES 默认 merge 策略）按"分层（tier）"思想合并：将段按大小分层，优先合并大小相近的段（同层段），避免大段与小段频繁合并（大段合并成本高），用 max_merged_segment（默认 5GB）控制合并后段大小上限、max_segments 控制段数、segments_per_tier（默认 10）控制每层段数。策略目的：在"合并成本"与"段数量（查询性能）"间平衡，减少大段重复合并。对写入性能的影响：merge 是后台异步进行，但占用 IO 与 CPU，与写入竞争资源；可通过 index.merge.policy 调整（如调大 max_merged_segment 减少合并频率）、限制 merge 线程数、或对只读索引用 forceMerge 一次性合并。理解 merge 是"写入性能与段数量"的平衡关键。

抓住"merge 重写数据、TieredMergePolicy 按同层合并控成本"。核心是"平衡 merge 成本与段数"。答题要点到 merge 风暴与 max_merged_segment。

• from+size 深分页的候选保留
• max_result_window 限制
• 替代方案（search_after/PIT/scroll）

from+size 深分页时，协调节点需要每个分片都取 from+size 条候选再合并排序取前 size 条，因为无法预知全局排序，各分片都保留完整候选。随着 from 增大，每个分片保留的候选数线性增长，内存与网络开销剧增，故 ES 设置 index.max_result_window（默认 10000）限制 from+size 跨度，超过即报错。替代方案：①search_after：基于上一页排序值滚动下一页，每页只取 size 条，配合唯一排序键（tiebreaker）与 PIT 保证一致性，适合顺序深分页；②PIT：提供一致时间点视图，与 search_after 配合实现稳定深分页；③scroll：维护滚动游标（快照），适合大量数据导出/聚合，但已废弃（不适合实时交互）；④key set / 游标分页：业务层用唯一 id 游标。选择：交互式深分页用 search_after+PIT，数据导出用 scroll 或 search_after 批量，跳页用浅分页限制。深分页的教训是"避免超大 from，用游标语义"。

抓住"每分片取 from+size 候选导致深分页开销大、max_result_window 限制"。核心是"滚动游标替代跳页"。答题要点到 search_after+PIT。

• object 数组的扁平化问题
• nested 隐藏文档机制
• 查询与更新成本

普通 object 字段存储数组时，对象会被扁平化（fields 平铺），导致数组内对象间的关联丢失。例如 users: [{name: "A", age: 20}, {name: "B", age: 30}] 扁平化后，name: A 与 age: 20 的配对关系丢失，无法查询"name 为 A 且 age 为 20"（结果可能匹配错误对象）。nested 类型通过隐藏文档（hidden document）解决：数组中的每个对象被存为独立的隐藏文档，保持对象内部字段的关联，nested 查询可精确匹配对象内字段。代价：①查询成本：nested 查询（nested query）需遍历隐藏文档做 join，比普通 object 慢；②更新成本：更新一个嵌套对象会重写整个父文档（因为父文档是整体结构），更新开销大；③存储与内存：隐藏文档增加存储，nested 聚合（nested aggs）内存开销大。普通 object 适合"对象间无需关联"的简单数组（本身扁平化即可），nested 适合"需保持对象内字段关联"的场景（如订单项、评论）。选择：需要对象内字段匹配用 nested，否则用 object 以省成本。

抓住"object 扁平化丢关联、nested 隐藏文档保关联"。核心是"nested 用独立文档换关联、代价是查询/更新重"。答题要点到更新重写父文档。

• RAG 模式与向量检索
• Spring AI 集成
• 文档问答工程实践

RAG（Retrieval-Augmented Generation）通过"先检索相关文档、再喂给 LLM 生成"实现文档问答，可结合 ES 8.x 的向量检索与 Spring AI 2.0 实现。工程实践：①文档切分与向量化：把文档切分为块（chunk），用 embedding 模型（如 Spring AI 的 OpenAI/BGE 适配）转为向量，写入 ES 的 dense_vector 字段（含元数据：来源、页码、时间戳）；②检索增强：用户提问时，把问题向量化，用 ES 的 knn 查询（可选混合 BM25 关键词提升召回）检索最相关文档块；③生成：把检索到的文档块作为上下文（prompt）与问题一起交给 LLM（Spring AI 的 ChatClient）生成回答，并用 source 引用增强可信度；④工程要点：文档更新用增量索引/ID 幂等、向量维度与模型一致、语义切分大小调优、检索结果截断到 token 预算、评估检索召回率与答案质量、加缓存与限流。Spring AI 2.0 提供 VectorStore 抽象（可对接 ES）、ChatClient、EmbeddingModel，简化 RAG 流水线。架构上"ES 管检索、Spring AI 管 LLM 编排"。

抓住"切块→向量化→kNN 检索→LLM 生成"的 RAG 流水线。核心是"ES 检索 + Spring AI 编排"。答题要点到混合检索与工程细节。

• mapping explosion 原因
• 动态字段失控
• 治理（模板/字段上限/扁平对象）

Mapping explosion（映射爆炸）：当动态 mapping 开启且字段名无限增长（如每个文档引入新的动态字段名，或字段名含随机后缀），mapping 字段数会无限膨胀。每个字段都占用集群元数据（cluster state）内存，且新增字段会触发全索引 mapping 更新，导致集群元数据膨胀、更新频繁、性能下降甚至拖垮集群。治理手段：①禁用/限制动态 mapping：设置 dynamic: strict（未知字段报错）或 dynamic: false（忽略），避免字段失控；②字段上限：ES 默认 index.mapping.total_fields.limit（默认 1000）限制字段数，超限报错，可据此规划；③动态模板（Dynamic Template）：用模板统一映射未知字段类型，避免字段类型乱变；④扁平对象（flattened）：对"键值不确定"的字段（如大量自定义属性）用 flattened 类型，把整个对象作为单个 keyword 处理，不逐个建字段，大幅减少字段数；⑤日志数据：配合 index.mapping.depth.limit 与 ignore_dynamic_beyond_limit 限制深度。治理核心是"控制字段数量增长、避免每个 value 独立建字段"。

抓住"mapping explosion 因动态字段无限增长、元数据膨胀"。核心是"用 flattened/模板/上限/禁用动态控制字段数"。答题要点到 flattened 类型。

• text 与 keyword 多字段
• 全文检索用 text
• 聚合/排序用 keyword

同一字符串用多字段（fields）同时定义为 text 与 keyword 时，应根据操作选择：全文相关性检索（如 match、match_phrase、相关性排序）用 text字段——text 分词后可做倒排检索与相关性评分；精确聚合（terms/cardinality 等）与排序（sort）用 keyword 字段——keyword 基于 doc_values 精确匹配，支持聚合与排序，而 text 需字段级 fielddata（内存开销大、不推荐）且语义是分词后，不适合精确聚合/排序。因此查询 DSL 中：全文匹配用 title（text），聚合/排序用 title.keyword（keyword）。示例："match": {"title": "elastic"} 检索，"aggs": {"terms": {"field": "title.keyword"}} 聚合，"sort": [{"title.keyword": "asc"}] 排序。注意：对 keyword 字段做 term 查询需精确值；对 text 字段聚合会因 fielddata 内存溢出不推荐。多字段设计让"一个字段既能全文检索又能精确聚合/排序"。

抓住"全文用 text、聚合/排序用 keyword"的分工。核心是"text 检索、keyword 精确（doc_values）"。答题要点到 text 聚合需 fielddata 的坑。

• 向量量化（int8/标量量化）
• 内存与召回权衡
• 离线标注集与线上指标验证

向量量化（如 int8 标量量化）把浮点向量（如 float32）压缩为低位（如 int8），显著减少内存占用与存储，但引入精度损失，可能降低近来邻检索的召回率（recall@k）。验证取舍需离线 + 线上双轨：①离线标注集验证：构建带标注的评估集（query 对应的真实相关文档），分别用量化前后向量做检索，计算召回率（recall@k）、MAP、NDCG 等指标，对比量化引起的召回损失是否在可接受范围（如 <1-2%）；②线上指标验证：量化上线后，用线上真实流量监控检索质量指标（如点击率、转化率、用户反馈、人工评估），确认召回损失未影响业务效果；③成本对比：量化节省的内存/存储（如 4 倍）能否换来同等的成本收益，配合 num_candidates 调整是否可补偿召回。若量化后召回损失过大，可部分回退（保留高精度字段）或调参（增大候选）。核心是"用数据量化内存收益与召回损失，做成本-效果权衡，而非凭感觉取舍"。

抓住"量化省内存但损召回、用指标验证"。核心是"离线召回率 + 线上业务指标 + 成本收益对比"。答题要点到 recall@k 评估。

• 快照的增量分片机制
• 跨版本恢复兼容性
• 验证与限制

ES 快照（snapshot）不是文件系统复制，而是基于分片级别的增量备份：只保存"相对上次快照改变的分片数据 + 元数据（索引结构、mapping、settings）"，通过引用计数复用未改变的分片，节省存储。这带来跨版本恢复的兼容限制：快照依赖 Lucene 段格式与 ES 元数据格式，跨大版本恢复可能不兼容（如 ES 7 快照不能直接恢复到 ES 8，或受版本限制）。恢复前需验证：①版本兼容：快照的创建版本与目标版本需兼容（ES 官方定义了版本兼容矩阵，通常支持向"相近更高版本"恢复，但跨多个大版本可能需中间版本过渡）；②映射/索引配置：验证目标版本能解析快照中的索引 mapping、settings、字段类型；③数据完整性：恢复后校验文档数、shard 状态、健康度（green）与数据抽样；④功能兼容：如 ILM、pipeline、安全配置在目标版本的行为。验证方式：先在测试环境从快照恢复，跑校验与 smoke test，通过后再正式恢复。跨版本迁移时建议先升级到中间版本再恢复，避免直接大版本跳转。

抓住"快照是增量分片元数据 + 依赖版本兼容"。核心是"跨版本恢复需验证段格式与元数据兼容"。答题要点到版本兼容矩阵与测试恢复。

• refresh_interval 与写吞吐
• 实时搜索可见性
• refresh 等待语义

提高 refresh_interval（如从 1s 调到 30s）能减少 refresh 次数，从而提高批量写入吞吐（refresh 次数少、段生成少、merge 压力小）。但代价是搜索可见性下降：数据写入后要等更久才可被搜索（近实时延迟从 1s 变长），实时搜索需求（如刚写入的数据要立刻查到）会受影响，因此对实时搜索场景不宜调大。refresh 后等待语义：refresh=wait_for（等 refresh 完成后才返回）用于确保写入后立即可见，若调大 refresh_interval（或关闭 refresh），wait_for 会等待更久甚至超时（index.refresh_interval 大时 wait_for 可能等待该间隔），导致写入延迟增加；refresh=false 则完全不等，写入返回更快但可见性差。权衡：批量导入/日志写入用 refresh_interval=-1（关闭）或 refresh=false 提升吞吐，导入完再刷新；实时/交互场景保持较小 refresh_interval 或 refresh=true。核心是"refresh 频率决定吞吐与可见性的平衡"。

抓住"refresh_interval 大→吞吐高但可见性低、wait_for 等待变长"。核心是"吞吐与实时可见性的权衡 + wait_for 语义"。答题要点到 refresh=false 与 wait_for。

• routing 机制
• 业务键同一分片
• 路由倾斜的热点问题

自定义 routing（路由）允许在写入/查询时指定 routing 值，ES 用 hash(routing) % num_primary_shards 决定文档落在哪个分片，从而把同一业务键（如 user_id）的文档定位到同一分片。好处：同一业务键的文档聚在同一分片，可提升局部更新、批量查询的本地性（如一次查询某用户全部数据）。但路由倾斜会带来热点问题：若某业务键的数据量远超其他（如大客户、热点用户），其所在分片数据量与负载远超其他分片，形成热点分片——该分片 CPU/IO/内存拥塞、查询慢、写入堵塞，而其他分片空闲，整体吞吐与稳定性受损。治理：①按业务键合理设计路由（避免把超大数据量键单路由）；②对超大业务键拆分（如加后缀/盐把大键拆到多分片）；③监控分片数据量与负载，发现倾斜及时调整；④用 routing 时配合 _search 的 routing 参数以减少分片扫描。路由是"提升局部性"与"潜在热点"的权衡。

抓住"routing 把业务键路由到同一分片、提升局部性"。核心是"倾斜导致热点分片"。答题要点到拆分大键与监控。

• PIT + search_after 深分页
• 排序稳定性
• 唯一 tiebreaker 的必要性

PIT（Point In Time）提供一致的时间点索引视图，配合search_after可实现稳定深分页：PIT 保证分页过程中数据视图不变（不被后续写入/刷新影响），search_after 用上一页末条排序值滚动下一页，避免每次重算前 N 条，深分页开销小且稳定。排序键必须包含唯一 tiebreaker：search_after 向后翻页依赖"上一页末条的唯一确定位置"，若排序字段有并列值（如多个文档排序值相同），分页时无法确定下一条从哪开始，可能出现重复或遗漏文档。加入唯一 tiebreaker（如 _shard_doc、_id 或单调递增的字段）作为排序键的最后一个字段，保证排序完全确定、无并列，从而分页翻页稳定不重不漏。示例：sort: [{timestamp: "desc"}, {"_shard_doc": "asc"}]，search_after 传上一页末条的 [timestamp, _shard_doc]。PIT 保证一致性 + tiebreaker 保证确定性，二者共同实现可靠深分页。

抓住"PIT 保一致性、tiebreaker 保确定性"。核心是"无并列排序才能稳定滚动"。答题要点到 _shard_doc 作 tiebreaker。

• refresh 与搜索可见性
• flush 与 translog 持久性
• 三者职责区分

refresh、flush、translog 是 ES 写入流程中三个不同职责的机制，不能混为一谈：①refresh：把内存缓冲（buffer）的数据生成可搜索的 Segments，影响搜索可见性（是否能被搜到），默认 1 秒一次，不落盘（段在内存/文件系统缓存），不保证持久性；②translog：写入时先记录到 translog（事务日志），保证持久性（崩溃后可从 translog 重放），是"数据不丢"的保障；③flush：把内存中的段**强制落盘（fsync）**并清空 translog，生成新的 commit point，是"持久化到磁盘"的完整操作，影响持久性（段落盘）。区分原因：refresh 只"让数据可见"（在内存生成段），translog 只"防数据丢失"（日志），flush 才"真正落盘"（fsync 段 + 清 translog）。三者时机不同：refresh 每秒多次、flush 按条件（translog 超阈值/间隔）、translog 实时写。理解：refresh 管"能搜到"，translog+flush 管"不丢掉"。若混为一谈，会误以为 refresh 即持久化，导致数据安全误解。ES 崩溃恢复依赖 translog 与 flush 的落盘段。

抓住"refresh 管可见性、translog/flush 管持久性"。核心是"三者职责与时机不同"。答题要点到 fsync 与清 translog。