服务端5月29日 00:51
Elasticsearch 的 suggest 功能如何实现自动补全？ES 提供四种 suggester：Completion Suggester 基于内存 FST（有限状态转换器）做前缀匹配，延迟极低，适合自动补全；Term Suggester 基于编辑距离做拼写纠错；Phrase Suggester 在 Term 基础上加 n-gram 语言模型优化整句建议；Context Suggester 为 Completion 增加分类/地理上下文过滤。自动补全场景用 Completion Suggester：索引时将建议词存入 completion 类型字段构建 FST，查询时用 prefix 参数匹配，毫秒级返回。
## 追问
**Completion Suggester 为什么快？**
它将建议词构建为 FST 结构常驻内存，前缀匹配是 O(k) 复杂度（k 为前缀长度），不涉及倒排索引扫描和评分计算，所以延迟在毫秒级。
**Completion 和 search_as_you_type 有什么区别？**
Completion 是独立建议通道，返回建议词而非文档；search_as_you_type 是特殊 text 子类型，本质还是全文检索返回文档。Completion 更适合输入框补全，search_as_you_type 更适合边输边搜文档内容。
**拼写纠错用哪个？**
Term Suggester。它基于倒排索引中的词项做编辑距离计算，返回相似词建议。需要指定 suggest_mode：missing（仅缺词建议）、popular（热门词优先）、always（始终建议）。
**如何给建议词加权重？**
在 completion 字段中设置 weight 属性，权重高的建议优先返回。常用于热门搜索词提权："suggest": {"input": "laptop", "weight": 100}。
**FST 内存开销大吗？**
FST 是高度压缩的有向无环图，百万级建议词通常只占几十 MB。但建议词总量达亿级时需评估内存，可用 context 过滤减少单次匹配范围。
## 写段代码
```json
PUT /search-suggest
{
"mappings": {
"properties": {
"title": { "type": "keyword" },
"suggest": {
"type": "completion",
"analyzer": "standard"
}
}
}
}
GET /search-suggest/_search
{
"suggest": {
"auto": {
"prefix": "elas",
"completion": { "field": "suggest", "size": 5 }
}
}
}
```标签
ElasticSearch
Elasticsearch（常写作 Elasticsearch）是基于 Lucene 的分布式搜索与分析引擎，面向海量数据提供近实时（NRT）的全文检索、结构化查询与聚合分析能力。它以 JSON 文档为核心数据模型，通过 索引（index）—分片（shard）—副本（replica） 的机制实现横向扩展与高可用：数据被切分到多个分片分布在不同节点上，副本用于容灾与提升读取吞吐。Elasticsearch 支持倒排索引、相关性排序、过滤与聚合（如 `terms`、`date_histogram`），常用于日志与监控检索、站内搜索、指标分析、异常排查等场景；并通常与 Beats/Logstash/Kibana（即 Elastic Stack）配合完成采集、处理、可视化。总体而言，它的价值在于用可扩展的集群把“搜索 + 分析”能力标准化、服务化，兼顾性能、灵活查询与运维可扩展性。
服务端5月29日 00:51
Elasticsearch 如何实现地理空间搜索？ES 通过 geo_point 和 geo_shape 两种类型支持地理搜索。geo_point 存储经纬度坐标点，支持 geo_distance（圆形范围）、geo_bounding_box（矩形范围）、geo_polygon（多边形范围）查询；geo_shape 存储复杂几何形状（线、多边形），支持相交、包含等空间关系查询。底层使用 geohash 编码将二维坐标映射为一维字符串，利用 BKD tree 索引加速范围检索。查询时先通过 geohash 前缀粗筛，再计算精确距离过滤。
## 追问
**geo_point 和 geo_shape 怎么选？**
存储门店位置等点数据用 geo_point，存储配送区域等面数据用 geo_shape。geo_point 查询更快，geo_shape 支持更复杂的空间关系但索引开销更大。
**geo_distance 查询性能如何优化？**
先用 geo_bounding_box 缩小候选集，再在结果上做精确距离计算。也可设置 geo_point 的 geohash_precision 控制索引精度。
**经纬度顺序容易搞混怎么办？**
ES 的 geo_point 支持多种格式：字符串 "lat,lon"、数组 [lon,lat]（GeoJSON 标准）、对象 {lat,lon}。数组格式是 lon 在前，容易出错，推荐用对象格式避免歧义。
**geohash 精度怎么选？**
精度越高定位越准但索引越大。常见选择：1km 精度用 geohash_precision=5（约 4.9km 边长），100m 用 6，10m 用 7。业务精度需求决定精度设置。
**geo 查询能和普通查询组合吗？**
可以，放在 bool query 的 filter 子句中。geo 查询不计算评分，适合做过滤条件配合全文检索使用。
## 写段代码
```json
PUT /stores
{
"mappings": {
"properties": {
"name": { "type": "keyword" },
"location": { "type": "geo_point" }
}
}
}
GET /stores/_search
{
"query": {
"bool": {
"filter": {
"geo_distance": {
"distance": "5km",
"location": { "lat": 39.9, "lon": 116.4 }
}
}
}
}
}
```服务端5月29日 00:51
Elasticsearch 的 fielddata 和 doc_values 有什么区别？fielddata 是基于 JVM 堆内存的倒排索引补充结构，仅在搜索时按需加载到内存，专用于 text 字段的聚合和排序，内存消耗不可控，易引发 OOM；doc_values 是基于磁盘的列式存储，索引时随文档写入持久化，默认对 keyword 和数值类型启用，不占堆内存，ES 5.x 后成为默认方案。核心区别：存储位置（堆 vs 磁盘）、加载时机（搜索时 vs 索引时）、内存风险（高 vs 低）、适用类型（text vs keyword/numeric）。生产环境中应优先用 doc_values，若字段不需聚合/排序可关闭 doc_values 节省磁盘。
## 追问
**为什么 fielddata 容易 OOM？**
fielddata 将字段的全部唯一词项加载到 JVM 堆，高基数字段（如 UUID）可能占用数 GB。且被 LRU 缓存持有，不会主动释放，直到触发 circuit breaker。
**text 字段需要聚合怎么办？**
推荐用 multi-fields：主字段 text 做全文检索，子字段 keyword 启用 doc_values 做聚合。避免在 text 上开启 fielddata: true。
**关闭 doc_values 有什么影响？**
该字段将无法用于聚合、排序和脚本访问。如果字段只做全文检索不需要这些操作，关闭可节省约 10-15% 磁盘空间。
**doc_values 的列式存储如何加速聚合？**
列式存储按字段值连续排列，对同一字段的遍历只需顺序读磁盘，CPU 缓存命中率高。行式存储需跳行读取，I/O 散乱。
**ES 7.x 后还有必要了解 fielddata 吗？**
需要。排查旧索引的内存问题时仍需检查 fielddata 占用，GET _nodes/stats/indices?fielddata 可定位高消耗字段。
## 写段代码
```json
PUT /products
{
"mappings": {
"properties": {
"title": {
"type": "text",
"fields": {
"keyword": {
"type": "keyword",
"doc_values": true
}
}
},
"status": {
"type": "keyword",
"doc_values": true
}
}
}
}
```服务端5月29日 00:50
Elasticsearch 如何优化写入性能？核心思路是减少刷新频率、批量提交、降低副本开销。具体操作：将 refresh_interval 设为 -1 禁用自动刷新，写入完成后手动 refresh；使用 Bulk API 批量提交文档（建议 5-15MB 一批）；写入期间将 number_of_replicas 设为 0，写完后恢复；调大 translog.flush_threshold_size 减少 flush 次数；合理路由使热点数据集中写入少数分片，避免跨节点协调开销。
## 追问
**bulk 请求多大合适？**
建议单次 bulk 请求体 5-15MB，文档数不超 10000。过大易触发 GC 甚至 OOM，过小则网络开销占比高。用 BulkProcessor 可自动攒批提交。
**refresh_interval=-1 写完忘改回来怎么办？**
新写入文档对搜索不可见，但不丢数据。生产中可在索引模板中设置正常值，仅写入任务启动时临时覆盖。
**副本数为 0 风险多大？**
单节点故障会丢分片数据。建议仅在大批量初始导入时使用，写完立即恢复副本并等待 allocation 完成。
**translog 配置怎么调？**
将 translog.durability 改为 async，translog.sync_interval 设为 30s，flush_threshold_size 从默认 512MB 调到 1GB，减少磁盘 fsync 次数。
**冷热数据如何隔离写入？**
用 ILM 策略将新数据写入热节点（SSD），rollover 后迁移到冷节点（HDD）。hot 阶段设短 refresh_interval，cold 阶段恢复默认。
## 写段代码
```json
PUT /logs-write
{
"settings": {
"refresh_interval": "-1",
"number_of_replicas": 0,
"translog": {
"durability": "async",
"sync_interval": "30s"
}
}
}
```服务端5月28日 02:00
Elasticsearch 如何实现近实时搜索？Elasticsearch 实现近实时搜索的核心机制是 **refresh 操作**：写入的数据先进入内存缓冲区（Memory Buffer），默认每秒执行一次 refresh，将缓冲区中的文档生成新的 Lucene Segment 并写入文件系统缓存（Filesystem Cache），此时数据即可被搜索——无需等待刷盘，这就是"近实时"的来源。
## 为什么 Elasticsearch 是"近实时"而不是"实时"？
数据从写入到可搜索，中间存在约 1 秒的延迟（默认 refresh interval），这是性能与实时性的权衡：
- **如果要求完全实时**：每次写入都立即 fsync 到磁盘，I/O 开销巨大，写入吞吐量会急剧下降
- **如果延迟过大**：数据长时间不可搜索，用户体验差
Elasticsearch 选择了 1 秒的折中方案，既保证了写入性能，又让数据几乎"立即可搜"。
## 数据写入的完整流程
一条文档从写入到可搜索，经历三个关键阶段：
**阶段一：写入 Memory Buffer + Translog**
```
写入请求到达
→ 文档写入 Memory Buffer（此时不可搜索）
→ 同时写入 Translog（保证可靠性）
```
- Memory Buffer 是 JVM 堆内存中的一块区域，暂存未 refresh 的文档
- Translog（事务日志）同步写磁盘（可配置），防止宕机丢数据
- 此时文档**不可被搜索**
**阶段二：Refresh（默认每秒一次）**
```
Refresh 触发
→ Memory Buffer 中的文档生成新 Segment
→ Segment 写入 Filesystem Cache（OS 缓存，非磁盘）
→ 清空 Memory Buffer
→ 新 Segment 立即可被搜索
```
- Segment 是 Lucene 的倒排索引文件，一旦生成就是不可变的
- 关键点：Segment 只需进入 OS 的文件系统缓存即可被读取，不必等到 fsync 刷盘
- 这就是"近实时"的直接原因
**阶段三：Flush（默认每 30 分钟或 Translog 超 512MB）**
```
Flush 触发
→ 执行 commit，将所有 Segment fsync 到磁盘
→ 清空 Translog
→ 生成新的 commit point
```
Flush 是真正的持久化操作，但频率远低于 Refresh，避免频繁磁盘 I/O。
## Translog 如何保证数据不丢？
Translog 是 Elasticsearch 数据可靠性的核心保障，有两种同步策略：
| 配置 | 行为 | 可靠性 | 性能 |
|------|------|--------|------|
| `async`（默认） | 每 5 秒 fsync 一次 | 可能丢 5 秒数据 | 高 |
| `request` | 每次写请求都 fsync | 不丢数据 | 较低 |
```json
// 配置每次请求都同步 Translog
PUT /my_index/_settings
{
"index.translog.durability": "request",
"index.translog.sync_interval": "5s"
}
```
大多数场景用默认的 `async` 即可。如果业务对数据丢失零容忍（如金融交易），建议设为 `request`。
## Refresh Interval 调优实战
**场景一：批量导入数据时关闭 refresh**
```json
// 批量导入前关闭 refresh
PUT /my_index/_settings
{
"index.refresh_interval": "-1"
}
// 导入完成后恢复
PUT /my_index/_settings
{
"index.refresh_interval": "1s"
}
```
关闭 refresh 后，批量导入速度可提升 2-5 倍，因为省去了每秒生成 Segment 的开销。
**场景二：对实时性要求不高的场景增大间隔**
日志分析场景中，数据延迟 30 秒可搜索完全可接受：
```json
PUT /log_index/_settings
{
"index.refresh_interval": "30s"
}
```
这能显著降低 Segment 生成频率，减少 Segment Merge 压力。
## Segment Merge：不可忽视的后台开销
每次 refresh 都会生成一个新 Segment。Segment 数量过多会严重影响搜索性能，Elasticsearch 后台会自动执行 Segment Merge：
- 小 Segment 合并为大 Segment，减少文件数
- Merge 过程消耗 CPU 和磁盘 I/O
- 如果 refresh 过于频繁（如 100ms），Segment 数量暴增，Merge 压力大
这就是为什么 refresh interval 不能无限缩短——看似搜索更快了，实际上 Merge 开销可能拖垮整个集群。
## 常见踩坑
**1. 写入后立即搜索不到**
这是最常见的问题。解决方案：
```json
// 手动触发 refresh
POST /my_index/_refresh
// 或在写入时指定 refresh 参数
PUT /my_index/_doc/1?refresh=true
{
"title": "test"
}
```
`?refresh=true` 会在写入后立即执行 refresh，但会显著降低写入性能，不建议在批量写入时使用。
**2. Translog 过大导致恢复慢**
如果 Translog 积累过多（如关闭了 flush），节点重启时回放 Translog 会很慢。监控 Translog 大小：
```json
GET /my_index/_stats?filter_path=indices.*.translog
```
**3. Refresh 间隔设太短**
有人将 refresh_interval 设为 `100ms` 追求"更实时"，结果 Segment 数量暴增，搜索性能反而下降。1 秒已经是工程实践的最佳平衡点。
## 追问：能否做到真正的实时搜索？
Elasticsearch 8.x 引入了**索引排序**（index sorting）等优化，但 refresh 机制的本质没有变。如果业务确实需要毫秒级延迟，可以考虑：
- 使用 `_refresh` API 手动刷新（牺牲写入吞吐量）
- 使用 Elasticsearch 的 **Point-in-Time (PIT)** API 保证查询一致性
- 对实时性要求极高的场景，考虑用 Redis 等内存数据库做前置缓存
但归根结底，Elasticsearch 的定位就是"近实时"搜索引擎，1 秒延迟是架构层面的权衡结果，并非缺陷。理解 refresh、translog、flush 三者的协作关系，是掌握 Elasticsearch 写入机制的关键。
服务端5月28日 02:00
Elasticsearch 集群架构中分片和副本的作用是什么？Elasticsearch 的分布式能力建立在两个核心机制之上：**分片（Shard）** 和 **副本（Replica）**。分片解决"一台机器存不下、算不快"的问题，副本解决"一台机器挂了数据丢了"的问题。理解这两者的工作方式，是掌握 Elasticsearch 集群架构的关键。
## 分片（Shard）：水平拆分，并行提速
分片是将一个索引拆分为多个独立存储单元的机制。每个分片本质上是一个完整的 Lucene 索引，可以独立存储和检索数据，分布在集群的不同节点上。
**水平扩展存储容量**
单节点存储有上限。假设一个索引有 60GB 数据，设置 `number_of_shards=5`，则每个分片存储约 12GB，可分散到 5 个节点上。数据量增长时，通过增加节点即可承载更多分片。
**并行提升查询性能**
搜索请求到达后，协调节点将查询分发到所有相关分片并行执行，各分片返回局部结果后由协调节点合并排序。5 个分片意味着 5 路并行，查询延迟显著降低。
**分片数量在索引创建时确定，不可修改**
这是一个常考的面试点。主分片数一旦设定就无法更改（因为文档路由公式依赖分片数）。如果需要调整，只能通过 Reindex 重建索引。设置时需预估数据规模：
```
PUT /my_index
{
"settings": {
"number_of_shards": 3,
"number_of_replicas": 1
}
}
```
## 副本（Replica）：高可用与读扩展
副本是主分片的完整拷贝，与主分片存储在不同节点上。它的核心价值有两个：故障容错和读性能提升。
**故障容错——节点宕机数据不丢失**
当持有主分片的节点故障时，集群会自动将对应的副本提升为主分片，保证数据可继续读写。故障节点恢复后，集群会重新同步数据，恢复副本。整个过程中，用户无感知。
**读请求负载均衡**
读操作（搜索、聚合）可以在主分片和副本上同时执行。3 个主分片 + 1 副本 = 6 个可读分片，查询吞吐量翻倍。写操作仍然只发生在主分片上，之后异步复制到副本。
**副本数量可以随时修改**
与分片不同，副本数可动态调整，不需要重建索引：
```
PUT /my_index/_settings
{
"number_of_replicas": 2
}
```
## 分片与副本的协作机制
**文档写入流程**
1. 客户端发送写请求到协调节点
2. 协调节点根据文档 ID 计算目标分片：`shard = hash(routing) % number_of_primary_shards`
3. 请求转发到主分片所在节点，主分片完成写入
4. 主分片将数据同步到所有副本分片
5. 所有副本确认后，返回成功响应给客户端
**文档读取流程**
1. 协调节点收到读请求
2. 根据路由信息确定目标分片组（主分片 + 副本）
3. 采用轮询策略在主分片和副本间选择一个执行查询，实现负载均衡
4. 返回结果
**故障转移流程**
当节点宕机时，集群执行以下步骤：
- 主节点检测到节点离线，将集群状态标记为 yellow（有副本丢失）或 red（有主分片丢失）
- 若主分片丢失，将对应副本提升为新主分片
- 在剩余节点上重新分配分片，恢复副本数量
- 数据通过副本重新同步，最终恢复为 green 状态
## 配置原则与最佳实践
**分片数设置**
- 单分片建议大小 30-50GB，不超过 50GB
- 分片数 = 预估数据量 / 单分片目标大小
- 避免过度分片：每个分片消耗内存和文件句柄，分片过多导致性能下降
- 官方建议：每个节点分片数不超过 `堆内存(GB) × 20`
**副本数设置**
- 生产环境至少 1 个副本，保证单节点故障不丢数据
- 对读吞吐要求高的场景可增加到 2 个副本
- 副本会增加存储开销和写入延迟（写操作需同步到所有副本），需要权衡
**常见配置错误**
- 小索引设置过多分片（如 1GB 数据设 5 个分片），浪费资源
- 副本数为 0 且只有单节点，节点故障即数据丢失
- 分片大小不均，部分热点分片成为瓶颈
## 面试常见追问
**Q: 分片数为什么创建后不能改？**
文档路由公式 `hash(routing) % primary_shards` 依赖分片数。如果分片数变化，已有文档的路由结果改变，查询时无法定位到正确的分片。
**Q: 副本同步是同步还是异步？**
写入时是同步的——主分片写入后等待所有副本确认才返回成功（可通过 `consistency` 参数调整）。副本之间的分段合并等操作则是异步进行。
**Q: 如何选择分片数量？**
基于数据量和节点数预估。核心公式：分片数 = 总数据量 / 30GB（单分片建议上限）。同时确保分片数不超过 `节点数 × 每节点分片上限`。实际场景中需结合写入频率和查询复杂度调整。
服务端5月28日 01:59
Elasticsearch 有哪些字段类型？如何正确选择？Elasticsearch 的字段类型直接决定了索引的存储方式、查询性能和分析能力。选错类型会导致分词异常、聚合失败、存储膨胀，甚至需要重建索引。下面从类型分类、核心类型详解、选型原则三个层面系统梳理。
## 字段类型总览
Elasticsearch 的字段类型可分为以下几类：
| 类别 | 主要类型 | 典型场景 |
|------|---------|---------|
| 文本 | `text`、`keyword` | 全文搜索 / 精确匹配 |
| 数值 | `integer`、`long`、`float`、`double`、`scaled_float` | 范围查询、排序、聚合 |
| 日期 | `date` | 时间范围过滤 |
| 布尔 | `boolean` | 状态标记 |
| 复杂结构 | `object`、`nested`、`flattened` | 嵌套文档 |
| 地理 | `geo_point`、`geo_shape` | 位置搜索 |
| 语义搜索 | `dense_vector`、`sparse_vector` | 向量检索 |
| 排序特征 | `rank_feature`、`rank_features` | 影响相关性评分 |
| 自动补全 | `search_as_you_type`、`completion` | 搜索建议 |
| 其他 | `ip`、`alias`、`constant_keyword`、`wildcard` | 特殊用途 |
## 核心类型详解
### text 与 keyword：最常混淆的一对
`text` 和 `keyword` 是 Elasticsearch 中最基础也最容易被误用的两种类型。
**text** 会经过分词器处理，拆分为多个 token 后建立倒排索引，适合 `match` 查询：
```json
"title": {
"type": "text",
"analyzer": "ik_max_word"
}
```
在 `text` 字段上执行 `term` 查询是常见错误——分词后的 token 与原始值不一致，`term` 查询会返回空结果。
**keyword** 不分词，原样存储，适合 `term` 查询、排序和聚合：
```json
"status": {
"type": "keyword",
"ignore_above": 256
}
```
**多字段模式**是生产环境的标准做法，同一个业务字段同时提供 `text` 和 `keyword` 两种能力：
```json
"title": {
"type": "text",
"analyzer": "ik_max_word",
"fields": {
"keyword": { "type": "keyword" }
}
}
```
这样 `title` 用于全文搜索，`title.keyword` 用于精确匹配和聚合。
### 数值类型：够用就行，不必贪大
`integer`（4字节）、`long`（8字节）、`float`（4字节）、`double`（8字节）是最常用的数值类型。选型原则很简单：**能满足需求的最小类型优先**。
`scaled_float` 适合货币等固定精度场景，它存储时自动乘以 `scaling_factor` 取整，查询时还原：
```json
"price": {
"type": "scaled_float",
"scaling_factor": 100
}
```
这样 `99.99` 实际存储为 `9999`（long），既省空间又避免浮点精度问题。
**注意**：存储标识符（如数据库主键 ID）应使用 `keyword` 而非 `long`。数字类型的 term 查询会做数值比较，而标识符需要的是精确字符串匹配。
### date 类型：格式必须显式声明
```json
"created_at": {
"type": "date",
"format": "yyyy-MM-dd'T'HH:mm:ss.SSSZ||epoch_millis"
}
```
`format` 支持用 `||` 分隔多种格式。不指定时 Elasticsearch 会猜测，一旦数据中混入不同格式就会导致解析失败。始终显式声明 `format` 是最佳实践。
### object 与 nested：嵌套数据的两种处理方式
`object` 类型会将嵌套字段扁平化存储。当数组中包含多个对象时，扁平化会导致跨字段的关联丢失：
```json
// 文档内容
{"users": [{"name": "张三", "age": 25}, {"name": "李四", "age": 30}]}
// object 扁平化后实际存储
{"users.name": ["张三", "李四"], "users.age": [25, 30]}
```
此时查询 `name=张三 AND age=30` 会误匹配，因为扁平化后张三和 30 没有关联。
`nested` 类型为每个数组元素建立独立文档，保证字段间关联：
```json
"users": {
"type": "nested",
"properties": {
"name": { "type": "keyword" },
"age": { "type": "integer" }
}
}
```
查询时必须使用 `nested` 查询：
```json
{
"query": {
"nested": {
"path": "users",
"query": {
"bool": {
"must": [
{ "term": { "users.name": "张三" } },
{ "term": { "users.age": 25 } }
]
}
}
}
}
}
```
`nested` 的代价是查询更复杂、索引更大。如果数组元素之间不需要跨字段关联查询，用 `object` 即可。
### flattened：动态元数据的轻量选择
当日志或事件中包含大量不确定 key 的元数据字段时，逐个定义 mapping 既繁琐又浪费。`flattened` 将整个对象作为一个 keyword 存储：
```json
"metadata": {
"type": "flattened"
}
```
支持对内部字段的查询和聚合，但不支持全文搜索。适合标签、注解等结构不固定的场景。
### geo_point 与 geo_shape：地理信息处理
```json
"location": {
"type": "geo_point"
}
```
`geo_point` 支持距离查询、范围过滤和聚合：
```json
{
"query": {
"geo_distance": {
"distance": "5km",
"location": { "lat": 39.9, "lon": 116.4 }
}
}
}
```
`geo_shape` 用于复杂地理区域（多边形、线段），支持空间关系查询（相交、包含等）。
### dense_vector：语义搜索的基础
```json
"embedding": {
"type": "dense_vector",
"dims": 768,
"index": true,
"similarity": "cosine"
}
```
`dense_vector` 存储向量数据，配合 kNN 查询实现语义搜索。`index: true`（ES 8.0+）启用向量索引以加速近似最近邻检索。
### rank_feature：影响相关性但不参与过滤
```json
"page_rank": {
"type": "rank_feature"
},
"hot_score": {
"type": "rank_features"
}
```
`rank_feature` 存储单个正数，`rank_features` 存储 key-value 对。它们只能用于 `rank_feature` 查询中提升相关性评分，不能用于过滤或聚合。适合引入外部信号（如热度、权威度）影响排序。
### 其他实用类型
- **ip**：存储 IPv4/IPv6，支持 CIDR 范围查询
- **alias**：字段别名，指向另一个字段，查询时自动转发
- **constant_keyword**：所有文档该字段值相同，优化存储
- **wildcard**：优化 `wildcard` 和 `prefix` 查询的性能
- **search_as_you_type**：专为即输即搜优化，自动构建 ngram 子字段
- **completion**：用于 `suggester` API 的自动补全
### runtime fields：查询时动态计算
运行时字段不在索引时生成，而在查询时通过脚本计算，适合临时分析或验证逻辑：
```json
"runtime": {
"price_gte_100": {
"type": "boolean",
"script": {
"source": "emit(doc['price'].value >= 100)"
}
}
}
```
优点是无需 reindex 即可添加字段；缺点是每次查询都要计算，大量数据下性能损耗明显。生产环境中高频查询的字段应转为索引字段。
## 选型原则
**第一步：确认查询方式**
| 查询方式 | 推荐类型 |
|---------|---------|
| 全文搜索 | `text` |
| 精确匹配 / 过滤 / 聚合 | `keyword` |
| 范围查询 | 数值类型 / `date` |
| 地理距离 | `geo_point` |
| 语义搜索 | `dense_vector` |
| 嵌套关联查询 | `nested` |
**第二步：考虑存储与性能**
- `keyword` 比 `text` 索引开销小，高频过滤字段优先用 `keyword`
- `scaled_float` 在货币场景下比 `double` 更精确且更省空间
- `nested` 查询比 `object` 慢，只在需要字段关联时使用
- `flattened` 减少 mapping 膨胀，但牺牲全文搜索能力
**第三步：避免常见错误**
- 不要在 `text` 字段上执行 `term` 查询，用 `match` 或改用 `keyword`
- 标识符字段用 `keyword`，不要用数值类型
- 日期字段始终显式声明 `format`
- 需要字段关联的嵌套数组必须用 `nested`，不能用 `object`
- 运行时字段不要用于高频过滤或大规模聚合
## 完整 mapping 示例
```json
{
"mappings": {
"properties": {
"title": {
"type": "text",
"analyzer": "ik_max_word",
"fields": {
"keyword": { "type": "keyword" }
}
},
"status": {
"type": "keyword"
},
"price": {
"type": "scaled_float",
"scaling_factor": 100
},
"is_active": {
"type": "boolean"
},
"created_at": {
"type": "date",
"format": "yyyy-MM-dd'T'HH:mm:ss.SSSZ||epoch_millis"
},
"location": {
"type": "geo_point"
},
"ip_address": {
"type": "ip"
},
"users": {
"type": "nested",
"properties": {
"name": { "type": "keyword" },
"age": { "type": "integer" }
}
},
"metadata": {
"type": "flattened"
},
"embedding": {
"type": "dense_vector",
"dims": 768,
"index": true,
"similarity": "cosine"
},
"hot_score": {
"type": "rank_feature"
}
}
}
}
```
选对字段类型是 Elasticsearch 索引设计的根基。先明确查询方式，再权衡存储与性能，最后对照常见错误排查——三步走基本覆盖绝大多数场景。如果业务演进导致类型需要变更，通过 reindex + alias 切换的方式在线完成，无需停服。
服务端5月27日 23:53
Elasticsearch 更新和删除操作的底层原理是什么？Elasticsearch 底层基于 Lucene，而 Lucene 的段（segment）是不可变的。这意味着已写入段的文档无法原地修改或删除。Elasticsearch 的更新和删除操作都建立在这一约束之上，通过标记删除 + 重新索引的方式实现，再由段合并完成物理清理。
## 更新操作：标记删除 + 重新索引
Elasticsearch 的更新并不是原地修改文档。当你更新一个文档时，实际发生的是两步操作：
1. 旧文档在 `.del` 文件中被标记为 deleted
2. 新文档被索引到一个新的段中
也就是说，更新 = 删除旧版本 + 插入新版本。这是由倒排索引的不可变性决定的——段一旦写入就无法修改，只能追加。
```json
PUT /products/_doc/1
{
"name": "MacBook Pro",
"price": 14999,
"updated_at": "2025-01-15"
}
```
上述请求如果文档 ID=1 已存在，旧文档会被标记删除，新文档写入新段。如果不指定 ID，则直接作为新文档插入。
### 部分更新（Partial Update）
全量替换需要发送完整文档，网络开销大。部分更新通过 `_update` API 只修改指定字段，但底层仍然是标记删除 + 重新索引——只是服务端帮你完成了合并旧文档和新字段的步骤：
```json
POST /products/_update/1
{
"doc": {
"price": 12999
}
}
```
### 脚本更新
对于需要动态计算的场景，可以用脚本更新：
```json
POST /products/_update/1
{
"script": {
"source": "ctx._source.price += params.delta",
"params": {
"delta": 500
}
}
}
```
### upsert 操作
当不确定文档是否存在时，upsert 可以在文档不存在时插入、存在时更新：
```json
POST /products/_update/1
{
"doc": { "price": 12999 },
"upsert": { "name": "MacBook Pro", "price": 12999 }
}
```
## 删除操作：逻辑删除与段合并清理
删除文档时，Elasticsearch 不会立即从磁盘移除数据。而是在 `.del` 文件中标记该文档为 deleted 状态。被标记的文档仍然存在于段中，但查询时会被过滤掉。
```json
DELETE /products/_doc/1
```
### 物理删除何时发生？
物理删除发生在段合并（segment merge）过程中。Lucene 后台会定期将多个小段合并为大段，此时被标记为 deleted 的文档不会被写入新段，从而实现真正的磁盘空间回收。
你也可以手动触发合并清理：
```json
POST /products/_forcemerge?only_expunge_deletes=true
```
`only_expunge_deletes=true` 表示只合并含有删除文档的段，不影响无删除标记的段。
### 按条件批量删除
对于需要按查询条件删除的场景，使用 `delete_by_query`：
```json
POST /products/_delete_by_query
{
"query": {
"range": {
"price": { "lte": 100 }
}
}
}
```
注意：`delete_by_query` 是先扫描再逐个标记删除，大数量下耗时长，建议在低峰期执行并设置 `wait_for_completion=false` 异步执行。
## 版本控制与乐观并发
### _version 字段
每个文档都有一个 `_version` 字段，每次写操作（index、update、delete）都会使版本号递增。这用于防止旧版本覆盖新版本——如果一个更新请求基于的版本号已过期，操作会被拒绝。
### 乐观并发控制
Elasticsearch 使用 `if_seq_no` 和 `if_primary_term` 实现乐观并发控制（OCC）。在读取文档时获取当前的 seq_no 和 primary_term，更新时带上这两个值，如果文档已被其他操作修改（seq_no 已变），则返回 409 冲突：
```json
PUT /products/_doc/1?if_seq_no=5&if_primary_term=1
{
"name": "MacBook Pro",
"price": 13999
}
```
如果不做并发控制，两个请求同时更新同一文档，后到的请求会覆盖先到的结果——这在电商库存扣减等场景下是严重问题。
## 近实时搜索与 refresh 机制
文档写入后并不是立即可搜索。Elasticsearch 的写入流程是：
1. 文档先写入内存缓冲区（index buffer）
2. 同时写入 translog（事务日志，保证持久性）
3. 每隔 `refresh_interval`（默认 1s）执行一次 refresh，将内存缓冲区的数据写入新段，文档变为可搜索
这意味着更新和删除操作也有近一秒的延迟才对搜索可见。生产环境中，可以适当调大 `refresh_interval`（如 30s）来提升写入吞吐量，代价是搜索可见延迟增加。
## 性能优化要点
**更新场景：**
- 优先使用部分更新而非全量替换，减少网络传输和 _source 重写开销
- 高频更新使用 Bulk API 批量提交
- 避免在热索引上频繁单条更新，考虑异步队列聚合后批量写入
**删除场景：**
- 大批量删除用 `delete_by_query` 而非逐条 DELETE
- 删除后若段膨胀明显，执行 `force_merge` 回收空间（只对只读索引执行，否则可能产生超大段）
- 删除大量数据后关注磁盘水位，段合并需要额外磁盘空间
**通用建议：**
- 监控 `GET /_nodes/stats/indexing` 中的索引吞吐和删除计数
- 调整 `index.merge.policy` 控制段合并策略和频率
- 更新和删除都会产生 translog 和段碎片，定期评估索引是否需要 reindex
面试中回答这个问题，核心要讲清楚三点：段不可变导致更新是删除+插入、删除是逻辑标记物理清理靠段合并、并发控制靠 seq_no/primary_term 实现乐观锁。理解这三层，就能应对追问。服务端5月27日 23:52
Elasticsearch 如何实现高可用和容灾备份？Elasticsearch 在日志分析、全文检索、可观测性等场景中承担核心存储角色，一旦集群不可用，下游查询和写入全部中断。高可用保证单节点/单机房故障后服务继续运行，容灾备份保证数据在区域性灾难后可恢复。两者机制不同，缺一不可。
## 高可用：集群内故障自愈
### 分片与副本——数据冗余的基石
Elasticsearch 将每个索引拆分为多个主分片（primary shard），每个主分片可配置若干副本分片（replica shard）。主分片与副本分片分布在不同节点上：
- **主分片故障**：副本自动提升为新主分片，数据零丢失，查询不中断。
- **副本分片故障**：主分片仍在，集群自动在其他节点重建副本。
- **动态调整**：副本数可在索引运行时修改，主分片数创建后不可更改，需提前规划。
```json
PUT /my_index
{
"settings": {
"number_of_shards": 3,
"number_of_replicas": 1
}
}
```
生产环境建议 `number_of_replicas >= 1`，关键业务设为 2，可容忍单节点故障且仍有冗余。但副本越多写入吞吐越低（每个写操作需同步到所有副本），需在可用性与性能间取舍。
### 节点角色分离
生产集群至少 3 节点，建议按角色分离：
| 角色 | 配置 | 职责 | 最低数量 |
|------|------|------|----------|
| 专用主节点 | node.master: true, node.data: false | 集群管理、元数据维护 | 3 |
| 数据节点 | node.master: false, node.data: true | 存储分片数据、执行 CRUD | 按数据量扩容 |
| 协调节点 | node.master: false, node.data: false | 请求路由、结果聚合 | 2+ |
专用主节点不存数据、不处理查询，资源占用低但保障选主稳定。只有 2 个候选主节点时容易出现选不出 master 的问题，必须保证奇数个候选节点。
### 脑裂防护
网络分区可能导致两个子集群各自选主，产生"脑裂"，数据不一致。Elasticsearch 7.x+ 已废弃 `discovery.zen.minimum_master_nodes`，改为自动计算法定人数（quorum），但理解其原理仍然关键：
- **7.x 之前**：手动设置 `discovery.zen.minimum_master_nodes` 为 `(候选主节点数 / 2) + 1`，确保只有多数派能选主。
- **7.x+**：由集群自动管理，但前提是正确配置 `cluster.initial_master_nodes`，首次启动时指定初始主节点列表。
```yaml
# elasticsearch.yml — 首次启动配置
discovery.seed_hosts: ["es-node1", "es-node2", "es-node3"]
cluster.initial_master_nodes: ["es-node1", "es-node2", "es-node3"]
```
### 集群健康与故障恢复
集群状态直观反映可用性：
- **green**：所有主分片和副本分片正常。
- **yellow**：主分片正常，部分副本缺失（单节点故障时常见，服务仍可用）。
- **red**：部分主分片不可用，数据有丢失风险。
```bash
# 查看集群健康
curl -XGET "http://localhost:9200/_cluster/health?pretty"
# 查看分片分配情况
curl -XGET "http://localhost:9200/_cat/shards?v"
```
节点故障后，集群自动执行分片重平衡：提升副本为主分片 → 在存活节点重建副本 → 数据重新均衡。此过程对应用透明，但重平衡期间查询性能可能下降。
## 容灾备份：跨机房/跨区域数据保护
高可用解决的是集群内单点故障，但整个机房故障（断电、网络中断、自然灾害）需要容灾方案。Elasticsearch 提供两条路径：快照恢复（冷备份）和跨集群复制 CCR（热备份）。
### 快照与恢复（Snapshot & Restore）
快照将索引数据备份到外部存储（本地磁盘、S3、HDFS 等），支持增量备份和按时间点恢复。
**1. 注册快照仓库**
```json
PUT /_snapshot/my_backup
{
"type": "fs",
"settings": {
"location": "/var/backups/elasticsearch"
}
}
```
S3 仓库需要安装 repository-s3 插件：
```json
PUT /_snapshot/s3_backup
{
"type": "s3",
"settings": {
"bucket": "my-backup-bucket",
"region": "us-east-1",
"base_path": "es-snapshots"
}
}
```
**2. 创建快照**
```bash
curl -XPUT "http://localhost:9200/_snapshot/my_backup/snapshot-20260527" \
-H "Content-Type: application/json" -d '{
"indices": "*,-.monitoring*,-.security*",
"ignore_unavailable": true,
"include_global_state": false
}'
```
注意排除系统索引（`.monitoring*`、`.security*`、`.ds*` 等），避免恢复时覆盖集群安全配置。
**3. 自动定期备份**
通过 SLM（Snapshot Lifecycle Management，8.x 内置）自动执行：
```json
PUT /_slm/policy/daily-snapshots
{
"schedule": "0 30 2 * * ?",
"name": "<daily-snap-{now/d}>",
"repository": "my_backup",
"config": {
"indices": ["*", "-.monitoring*", "-.security*"],
"ignore_unavailable": true,
"include_global_state": false
},
"retention": {
"expire_after": "30d",
"min_count": 5,
"max_count": 50
}
}
```
**4. 从快照恢复**
```json
POST /_snapshot/my_backup/snapshot-20260527/_restore
{
"indices": "my_index",
"include_aliases": true
}
```
恢复时目标索引必须不存在（或使用 `rename_pattern` 重命名）。整个集群不可用时，需先重建集群再恢复快照。
### 跨集群复制 CCR（Cross-Cluster Replication）
CCR 是 Elasticsearch 白金版功能，实现主集群到从集群的近实时索引复制，适用于异地容灾和读写分离。
**工作流程**：
1. **配置远程集群**：在从集群中声明主集群的连接信息。
2. **创建 Follower 索引**：从集群以只读方式持续拉取主集群的变更（先全量复制 segment，再增量同步 translog）。
3. **灾难切换**：主集群不可用时，将 Follower 索引转为普通索引（`POST /follower_index/_ccr/unfollow`），接管读写流量。
```json
PUT /_cluster/settings
{
"persistent": {
"cluster": {
"remote": {
"leader-cluster": {
"seeds": ["10.0.1.10:9300"]
}
}
}
}
}
```
```json
PUT /follower_index/_ccr/follow
{
"remote_cluster": "leader-cluster",
"leader_index": "leader_index"
}
```
**关键限制**：
- 需要白金版许可证。
- 从集群版本必须 >= 主集群版本。
- Follower 索引只读，需 unfollow 后才可写入。
- `ccr.indices.recovery.max_bytes_per_sec` 控制复制带宽（默认 40MB/s）。
### 快照 vs CCR 对比
| 维度 | 快照恢复 | CCR |
|------|----------|-----|
| 数据延迟 | 分钟~小时级（取决于备份频率） | 秒级近实时 |
| 恢复速度 | 需重建索引，分钟~小时级 | 秒级切换 |
| 成本 | 低（对象存储） | 高（需独立集群 + 白金许可） |
| 适用场景 | 数据归档、时间点恢复、开发测试 | 异地热备、业务连续性要求高 |
| 许可证 | 基础版即可 | 白金版 |
生产环境建议两者结合：CCR 保障实时容灾，快照提供长期归档和时间点回溯能力。
## 生产环境关键配置清单
### 防止数据丢失
```yaml
# elasticsearch.yml
# 每个索引默认至少 1 个副本
index.number_of_replicas: 1
# 刷新间隔，写入密集场景可适当增大
index.refresh_interval: 1s
# Translog 持久化策略：每次写操作后 fsync
index.translog.durability: request
```
### 索引生命周期管理（ILM）
ILM 自动管理索引的分片数、副本数、迁移和删除，避免冷数据无限膨胀：
```json
PUT /_ilm/policy/hot-warm-delete
{
"policy": {
"phases": {
"hot": {
"min_age": "0ms",
"actions": {
"rollover": { "max_age": "7d", "max_primary_shard_size": "50gb" }
}
},
"warm": {
"min_age": "30d",
"actions": {
"shrink": { "number_of_shards": 1 },
"forcemerge": { "max_num_segments": 1 },
"allocate": { "require": { "data": "warm" } }
}
},
"delete": {
"min_age": "90d",
"actions": {
"delete": {}
}
}
}
}
}
```
热节点用 SSD 存储近期活跃数据，温节点用 SATA 存储历史数据，ILM 自动将索引从热节点迁移到温节点，90 天后自动删除。冷热分层可降低 40%~60% 存储成本。
### 容灾演练
容灾方案不演练等于没有。建议每季度执行：
1. **节点级**：关闭一个数据节点，观察副本提升和集群重平衡。
2. **索引级**：删除一个索引，从快照恢复，验证数据完整性（对比文档数 `_count`）。
3. **集群级**：主集群断网，将 CCR Follower unfollow 接管，验证读写正常。
```bash
# 验证恢复后文档数一致
curl -XGET "http://localhost:9200/my_index/_count"
```
## 面试追问方向
- **RPO 和 RTO 分别是什么？** RPO（Recovery Point Objective）是可接受的数据丢失量，RTO（Recovery Time Objective）是可接受的服务中断时长。快照方案的 RPO 取决于备份频率，CCR 的 RPO 为秒级。
- **副本数设为 2 写入性能下降多少？** 通常下降 30%~40%，因为每次写操作需同步到主分片 + 2 个副本。写密集场景可设为 1 个副本，读密集场景增加副本数提升吞吐。
- **主分片数为什么不能改？** 主分片数决定了文档的路由公式 `shard = hash(routing) % number_of_primary_shards`，修改后所有文档的路由全部失效。扩容只能通过创建新索引 + reindex 实现。
- **CCR 和 Snapshot 能否替代彼此？** 不能。CCR 是实时热备但无法回溯历史时间点，Snapshot 是冷备但支持时间点恢复和长期归档。两者互补。服务端5月27日 23:51
Elasticsearch scroll 滚动查询和搜索上下文有哪些核心特点？## scroll 滚动查询是什么？为什么需要它？
Elasticsearch 的标准分页（from + size）在深度分页时性能急剧下降——获取第100页时，每个分片都要检索前1000+条数据，协调节点再做全局排序。ES 默认限制 from + size 不超过 10000（`index.max_result_window`）。
**scroll 滚动查询**就是为解决这个问题设计的：它发起一次查询后，在服务端创建一个**搜索上下文快照**，后续通过 scroll_id 逐批拉取数据，无需重复排序。
**核心机制：**
- **快照语义**：scroll 返回的是发起查询时刻的索引快照，之后的文档增删改不会影响结果
- **两阶段搜索**：首次请求执行 Query（获取文档ID列表）+ Fetch（拉取文档内容），后续滚动请求只做 Fetch
- **有状态**：scroll_id 在服务端持久化，直到超时或显式清除
```json
// 1. 初始化 scroll 查询
GET /products/_search?scroll=5m
{
"size": 1000,
"query": { "match_all": {} }
}
// 2. 使用 scroll_id 继续拉取
GET /_search/scroll
{
"scroll": "5m",
"scroll_id": "FGluY2x1ZGVfY29udGV4dF91dWlk..."
}
// 3. 清除 scroll 上下文（重要！）
DELETE /_search/scroll
{
"scroll_id": "FGluY2x1ZGVfY29udGV4dF91dWlk..."
}
```
**适用场景：** 数据导出、reindex 重建索引、ETL 批量处理等离线任务。
**不适用场景：** 实时分页请求——scroll 上下文占用堆内存，长时间不清理会导致资源泄漏。
## 搜索上下文（search context）是什么？
每次 `_search` 请求都会创建搜索上下文，它维护了**查询生命周期内的状态**，包括：
- Query 阶段的匹配文档ID列表
- 排序、聚合、高亮等操作所需的中间状态
- 请求级别的缓存信息
**关键特征：**
- 普通搜索的上下文在请求结束后自动销毁
- scroll 查询的上下文会持续存活直到超时
- 上下文数量受 `search.max_open_scroll_context` 限制（默认500）
搜索上下文本身不是一种"查询方式"，而是 scroll、聚合、高亮等功能的底层支撑。面试中常把"搜索上下文"和"scroll 上下文"混谈，核心区别在于生命周期：前者随请求结束而销毁，后者由 scroll 参数控制存活时间。
## scroll、search_after、from+size 三种分页怎么选？
| 对比维度 | from + size | scroll | search_after |
|---|---|---|---|
| **原理** | 偏移量跳过 | 快照 + 游标批量拉取 | 排序值游标逐页前进 |
| **状态** | 无状态 | 有状态（服务端保存快照） | 无状态 |
| **深度分页性能** | 差（O(n)排序开销） | 好（一次排序分批取） | 好（基于排序值定位） |
| **实时性** | 实时 | 快照，不反映后续变更 | 实时 |
| **随机跳页** | 支持 | 不支持 | 不支持 |
| **资源消耗** | 深分页时高 | 占用堆内存直到超时 | 低 |
| **典型场景** | Top N 查询 | 批量导出/重建索引 | 实时深度分页 |
**选择建议：**
- 数据量小、页码浅：`from + size`，简单直接
- 批量离线处理：`scroll`
- 实时深度分页：`search_after`
- 需要一致性视图 + 实时分页：`search_after` + PIT（Point in Time）
## Sliced Scroll 如何提升并行处理效率？
单条 scroll 串行拉取大量数据时效率有限。ES 提供 **Sliced Scroll**，将一个 scroll 查询切分为多个切片，并行拉取：
```json
GET /products/_search?scroll=5m
{
"size": 1000,
"slice": {
"id": 0,
"max": 4
},
"query": { "match_all": {} }
}
```
`max` 为切片总数，`id` 为当前切片编号（0 到 max-1）。每个切片独立返回一部分数据，多个线程/进程可并行拉取不同切片，显著缩短总耗时。
**注意：** 切片数不宜超过分片数，否则部分切片无数据可返回。
## 面试高频追问
**Q1: scroll 的 scroll_id 会变吗？**
会。每次滚动请求返回新的 scroll_id，客户端应始终使用最新返回的值。
**Q2: 忘记清除 scroll 上下文会怎样？**
上下文会持续占用堆内存直到超时。大量未清除的上下文可能导致 OOM，生产环境务必在处理完成后调用 `DELETE /_search/scroll` 清理。
**Q3: PIT + search_after 和 scroll 有什么区别？**
PIT（Point in Time）也创建快照，但更轻量，与 search_after 配合可实现一致性视图的实时分页。scroll 适合一次性全量遍历，PIT + search_after 适合交互式逐页浏览。ES 7.10+ 推荐用 PIT 替代 scroll 做深度分页。
**Q4: scroll 查询期间索引发生变更怎么办？**
scroll 基于快照，索引变更不影响已发起的 scroll 结果。但新文档不会出现在结果中，已删除文档可能仍存在——这取决于快照创建时机。服务端5月27日 23:50
Elasticsearch 如何进行索引数据的迁移和重建？Elasticsearch 索引迁移和重建是运维中绕不开的操作——无论是改 mapping、调分片数、换分词器，还是跨集群搬迁数据，都需要把旧索引的数据完整搬到新索引里。做不好就是数据丢失或者服务中断。
## 三种核心方案怎么选
| 方案 | 适用场景 | 停机要求 | 数据完整性 |
|------|---------|---------|-----------|
| _reindex API | 同集群内迁移、mapping 变更、分词器更换 | 可零停机 | 依赖验证 |
| Snapshot & Restore | 跨集群迁移、大版本升级 | 需短暂切换 | 高 |
| _reindex + Pipeline | 迁移同时需要字段转换 | 可零停机 | 依赖验证 |
选型原则：同集群内改结构用 `_reindex`，跨集群或版本升级用快照，迁移过程中要改数据格式就加 Pipeline。
## _reindex API：同集群迁移的首选
### 基本用法
```json
POST /_reindex
{
"source": {
"index": "old_index"
},
"dest": {
"index": "new_index",
"op_type": "create"
},
"conflicts": "proceed"
}
```
关键参数说明：
- `op_type: "create"` —— 目标索引已存在相同 `_id` 的文档时跳过，而不是覆盖。原文档保留不动
- `conflicts: "proceed"` —— 遇到版本冲突时跳过继续执行，不中断整个任务
- `requests_per_second` —— 限流参数，防止 reindex 把集群压垮，生产环境建议设 10-50
### 加速：slices 并行
数据量大时，单线程 reindex 很慢。用 `slices` 参数按分片并行处理：
```json
POST /_reindex?slices=5&refresh
{
"source": {
"index": "old_index"
},
"dest": {
"index": "new_index"
}
}
```
slices 设多少？等于源索引的分片数时性能最好。设太多反而增加调度开销。
### 零停机切换：别名机制
生产环境不能停服务，零停机的核心是别名切换：
```json
// 第1步：创建新索引（新的 mapping）
PUT /new_index
{
"mappings": { ... }
}
// 第2步：reindex 数据
POST /_reindex
{
"source": { "index": "old_index" },
"dest": { "index": "new_index" }
}
// 第3步：原子切换别名
POST /_aliases
{
"actions": [
{ "remove": { "index": "old_index", "alias": "my_alias" } },
{ "add": { "index": "new_index", "alias": "my_alias" } }
]
}
```
别名切换是原子操作，应用层无感知。切换后别忘了处理 reindex 期间的增量数据——可以在切换前用 `refresh: "wait_for"` 确保数据写入完毕。
### 远程集群 reindex
跨集群迁移不需要快照，`_reindex` 支持直接从远程集群拉数据：
```json
POST /_reindex
{
"source": {
"remote": {
"host": "http://old-cluster:9200",
"username": "user",
"password": "pass"
},
"index": "old_index",
"query": {
"match_all": {}
}
},
"dest": {
"index": "new_index"
}
}
```
注意：远程 reindex 走 HTTP 拉数据，网络带宽是瓶颈。需要在 `elasticsearch.yml` 配置 `reindex.remote.whitelist` 允许远程主机。
## Snapshot & Restore：跨集群和版本升级
快照方式保留完整的索引设置和映射，适合整体搬迁或大版本升级。
### 创建仓库和快照
```json
// 注册快照仓库（S3 示例）
PUT /_snapshot/my_backup
{
"type": "s3",
"settings": {
"bucket": "my-es-backups",
"region": "us-east-1"
}
}
// 创建快照
PUT /_snapshot/my_backup/snapshot_1
{
"indices": "old_index",
"ignore_unavailable": true,
"include_global_state": false
}
```
`include_global_state: false` 很重要——不导出集群全局状态，避免覆盖目标集群的配置。
### 恢复到新索引
```json
POST /_snapshot/my_backup/snapshot_1/_restore
{
"indices": "old_index",
"rename_pattern": "(.+)",
"rename_replacement": "new_$1",
"include_aliases": false
}
```
`rename_pattern` + `rename_replacement` 把旧索引名映射成新的，避免名称冲突。
### 版本兼容性
快照向前兼容一个大版本：7.x 的快照可以恢复到 8.x，但不能恢复到 9.x。跨多个大版本升级需要逐步中转。
## _reindex + Pipeline：迁移同时改数据
需要迁移时顺便改字段结构，就用 Ingest Pipeline：
```json
// 定义 Pipeline：把 old_field 的值复制到 new_field
PUT /_ingest/pipeline/transform_pipeline
{
"description": "Transform fields during reindex",
"processors": [
{
"rename": {
"field": "old_field",
"target_field": "new_field"
}
},
{
"remove": {
"field": "deprecated_field"
}
}
]
}
// reindex 时指定 Pipeline
POST /_reindex
{
"source": { "index": "old_index" },
"dest": {
"index": "new_index",
"pipeline": "transform_pipeline"
}
}
```
Pipeline 支持 rename、remove、set、script 等处理器，能处理大部分字段转换需求。
## 迁移后的验证清单
迁移完不代表万事大吉，以下验证缺一不可：
**1. 文档数量校验**
```json
GET /new_index/_count
```
对比源索引和目标索引的文档数，必须一致。
**2. 数据抽样比对**
```json
GET /new_index/_search
{
"query": { "term": { "_id": "具体文档ID" } }
}
```
随机抽几条文档，逐字段对比 `_source` 内容。
**3. 映射验证**
```json
GET /new_index/_mapping
```
确认新索引的 mapping 符合预期，特别是字段类型和分词器。
**4. 性能验证**
用实际的查询在迁移前后的索引上跑一遍，对比响应时间。新的分片数和 mapping 可能影响查询性能。
## 常见踩坑点
- **磁盘空间不足**：reindex 期间新旧索引同时存在，磁盘占用翻倍。迁移前检查磁盘余量
- **refresh_policy 没关**：大索引 reindex 时，把 `refresh_policy` 设为 `none`，完成后再手动 refresh，否则频繁刷新拖慢速度
- **超时中断**：大索引 reindex 耗时很长，设置 `timeout` 和 `scroll` 参数（如 `"scroll": "5m"`），避免连接超时
- **mapping 不兼容**：reindex 到新索引前必须先创建好目标索引的 mapping，否则 ES 自动推断的类型可能不对
- **跨集群白名单**：远程 reindex 需要在目标集群配置 `reindex.remote.whitelist`，否则请求会被拒绝
迁移前在测试集群走一遍完整流程，记录每个步骤的耗时和资源消耗，再上生产。数据一致性是底线——跳过验证步骤的生产事故见得太多了。服务端5月27日 23:50
Elasticsearch 如何实现跨集群复制（CCR）？Elasticsearch 跨集群复制（Cross-Cluster Replication, CCR）是一种基于 Leader-Follower 模型的单向数据复制机制，允许一个集群中的索引数据持续同步到另一个集群。Leader 索引负责写入，Follower 索引只读并持续拉取更新。CCR 从 6.5 版本开始提供，属于白金版付费功能，广泛用于灾备恢复、数据本地化和集中报表场景。
## CCR 的前提条件
在配置 CCR 之前，必须满足以下条件：
- **许可要求**：CCR 是白金版（Platinum）付费功能，需要商业许可证，可申请 30 天试用体验
- **版本兼容**：Follower 集群的 Elasticsearch 版本必须等于或高于 Leader 集群的版本
- **软删除必须启用**：Leader 索引必须开启软删除（`index.soft_deletes.enabled: true`），7.0.0 及以上版本默认开启
- **远程集群已注册**：双方集群必须互相注册为远程集群
- **权限配置**：本地集群用户需要 `manage_ccr` 集群权限，Follower 索引需要 `monitor`、`read`、`write` 及 `manage_follow_index` 索引权限
## CCR 的工作原理
CCR 采用**主动-被动模型**，数据流严格从 Leader 流向 Follower：
1. **Leader 索引**：接收所有写入操作，生成 translog 和 segment
2. **Follower 索引**：只读状态，主动从 Leader 拉取数据变更
3. **复制分两阶段**：
- **阶段一（Remote Recovery）**：复制 Leader 的已有 segment 到 Follower，这是网络密集型操作
- **阶段二（操作记录同步）**：持续复制内存缓冲区和 translog 中的新增操作记录
Follower 通过**轮询 Leader 的 translog** 获取变更，使用序列号（Sequence Number）标记同步位点，确保数据顺序性和一致性。如果 Follower 落后过多，Leader 会保留历史操作记录直到 Follower 追上，这也正是软删除必须启用的重要原因。
## 实战：配置跨集群复制
### 步骤 1：注册远程集群
在 Follower 集群上注册 Leader 集群：
```bash
# 在 Follower 集群执行
PUT /_cluster/settings
{
"persistent": {
"cluster": {
"remote": {
"leader-cluster": {
"seeds": ["leader-node1:9300", "leader-node2:9300"]
}
}
}
}
}
```
验证远程集群连接：
```bash
GET /_remote/info
```
返回结果中应能看到 `leader-cluster` 的连接状态为已连接。
### 步骤 2：创建 Follower 索引
在 Follower 集群上创建跟随者索引，指定 Leader 集群和索引：
```bash
# 在 Follower 集群执行
PUT /my-follower-index/_ccr/follow
{
"remote_cluster": "leader-cluster",
"leader_index": "my-leader-index"
}
```
创建后，Follower 索引进入只读状态，自动开始从 Leader 拉取数据。首次同步会执行完整的 Remote Recovery，后续只同步增量变更。
### 步骤 3：验证复制状态
检查 Follower 索引的复制进度：
```bash
GET /my-follower-index/_ccr/stats
```
关键字段说明：
- `leader_global_checkpoint`：Leader 当前的全局检查点
- `follower_global_checkpoint`：Follower 已追到的检查点
- `operations_indexed`：已索引的操作数
- 两者差值即为复制延迟量
### 步骤 4：暂停与恢复复制
```bash
# 暂停复制
POST /my-follower-index/_ccr/pause_follow
# 恢复复制
POST /my-follower-index/_ccr/resume_follow
```
### 步骤 5：终止复制
如需将 Follower 索引转为可写入的普通索引：
```bash
# 先暂停复制
POST /my-follower-index/_ccr/pause_follow
# 关闭索引
POST /my-follower-index/_close
# 终止跟随关系
POST /my-follower-index/_ccr/unfollow
# 重新打开索引（现在可以写入了）
POST /my-follower-index/_open
```
终止后，该索引变为普通索引，不再与 Leader 保持同步。
## 性能调优参数
CCR 提供了多个调优参数控制复制行为：
| 参数 | 默认值 | 说明 |
|------|--------|------|
| `ccr.indices.recovery.max_bytes_per_sec` | 40mb | 每节点出入站远程流量上限 |
| `ccr.indices.recovery.max_concurrent_file_chunks` | 5 | 并行复制文件数，最大 10 |
| `ccr.indices.recovery.chunk_size` | 1mb | 单次请求的文件块大小 |
| `ccr.indices.recovery.recovery_activity_timeout` | 60s | Leader 等待 Follower 请求的超时 |
在跨地域部署中，建议根据网络带宽适当调低 `max_bytes_per_sec`，避免 CCR 流量挤占业务带宽。
## CCR 的典型应用场景
**灾备恢复**：生产集群作为 Leader，异地集群作为 Follower。主集群故障时，可将 Follower 索引转为普通索引接管业务。
**数据本地化**：将中心集群的数据复制到边缘集群，减少跨区域访问延迟。例如总部数据同步到各区域机房供本地查询。
**集中报表**：多个业务集群作为 Leader，将数据统一复制到中央报表集群，避免直接查询生产库。
**连锁复制**：A 集群复制到 B，B 再复制到 C，实现多级数据分发。但需注意每一级都会增加延迟。
## CCR 与 CCS 的区别
- **CCR（跨集群复制）**：数据物理复制，Follower 持有完整数据副本，可离线查询
- **CCS（跨集群搜索）**：不复制数据，实时转发搜索请求到远程集群并汇总结果，依赖网络可用性
两者常配合使用：CCR 保证数据本地可用，CCS 实现全局搜索覆盖。
## 常见问题与排查
**复制延迟过高**：检查网络带宽和 `max_bytes_per_sec` 配置，确认 Leader 集群写入压力是否过大。使用 `_ccr/stats` 监控 checkpoint 差值。
**Follower 无法连接 Leader**：确认 9300 端口开放，检查 `seeds` 地址是否正确，通过 `_remote/info` 验证连接状态。
**软删除未启用**：如果 Leader 索引创建时未启用软删除，CCR 将无法工作。需要重新创建索引并启用 `index.soft_deletes.enabled`。
**Follower 索引写入报错**：这是正常行为，Follower 索引为只读。需要写入时必须先终止跟随关系。
## 小结
CCR 通过 Leader-Follower 模型实现跨集群数据复制，核心流程是注册远程集群、创建 Follower 索引、监控同步状态。关键要点：CCR 是白金版功能，Follower 版本不能低于 Leader，软删除必须开启，Follower 索引只读。掌握这些前提和配置步骤，就能在生产环境中可靠地实现跨集群数据同步与灾备。服务端5月27日 23:49
Elasticsearch 的索引生命周期管理（ILM）如何配置？## Elasticsearch ILM 是什么？
ILM（Index Lifecycle Management）是 Elasticsearch 提供的索引生命周期自动化管理机制，它根据索引的年龄、大小等条件，自动将索引在不同存储层级之间迁移，最终删除过期数据，从而降低存储成本和运维负担。
没有 ILM 时，常见的问题是：索引无限增长导致分片过大（恢复慢）、热节点磁盘告警、过期数据占满存储。ILM 通过定义策略（policy），让索引自动经历 hot → warm → cold → frozen → delete 五个阶段，每阶段执行特定操作（rollover、shrink、force_merge、delete 等）。
## ILM 的五个阶段
| 阶段 | 触发条件 | 典型操作 | 节点角色 |
|------|---------|---------|---------|
| hot | 索引活跃写入 | rollover（按大小/时间滚动） | data_hot |
| warm | 不再写入，仍常查询 | shrink（缩减分片）、force_merge（合并段） | data_warm |
| cold | 偶尔查询 | searchable_snapshot（可搜索快照） | data_cold |
| frozen | 极少查询 | freeze（7.x）/ searchable_snapshot（8.x） | data_frozen |
| delete | 超过保留期 | delete（永久删除） | — |
注意：frozen 阶段从 7.12 版本正式引入，8.x 中推荐用 searchable snapshot 替代 freeze 操作。
## 如何创建 ILM 策略？
通过 `_ilm/policy` API 创建策略，指定每个阶段的 `min_age` 和 `actions`：
```json
PUT _ilm/policy/log_retention_policy
{
"policy": {
"phases": {
"hot": {
"min_age": "0ms",
"actions": {
"rollover": {
"max_size": "50gb",
"max_age": "7d",
"max_docs": 100000000
},
"set_priority": {
"priority": 100
}
}
},
"warm": {
"min_age": "30d",
"actions": {
"shrink": {
"number_of_shards": 1
},
"force_merge": {
"max_num_segments": 1
},
"set_priority": {
"priority": 50
}
}
},
"cold": {
"min_age": "90d",
"actions": {
"searchable_snapshot": {
"snapshot_repository": "my_backup"
},
"set_priority": {
"priority": 0
}
}
},
"delete": {
"min_age": "180d",
"actions": {
"delete": {}
}
}
}
}
}
```
关键参数说明：
- `min_age`：索引进入该阶段需等待的最短时间，从索引进入上一阶段算起（不是从索引创建时间算）
- `rollover`：在 hot 阶段滚动创建新索引，三个条件满足任一即触发
- `shrink`：在 warm 阶段将分片数缩减，降低资源占用
- `force_merge`：合并段文件，减少文件句柄和查询开销
- `searchable_snapshot`：将索引转为快照挂载，大幅降低存储成本
## 如何将 ILM 策略绑定到索引？
有两种方式：索引模板（Index Template）和 Data Stream。
### 方式一：索引模板绑定
```json
PUT _index_template/log_template
{
"index_patterns": ["app-log-*"],
"priority": 500,
"template": {
"settings": {
"index.lifecycle.name": "log_retention_policy",
"index.lifecycle.rollover_alias": "app-log",
"number_of_shards": 3,
"number_of_replicas": 1
}
}
}
```
创建初始索引时，需以 `000001` 结尾才能触发 rollover：
```json
PUT app-log-000001
{
"aliases": {
"app-log": {
"is_write_index": true
}
}
}
```
### 方式二：Data Stream 绑定（推荐 7.9+）
Data Stream 天然支持 ILM，创建时直接关联策略：
```json
PUT _data_stream/app-logs
{
"index_template": "log_template"
}
```
写入 Data Stream 时，自动在背后创建 backing index，ILM 自动管理这些 backing index 的生命周期。Data Stream 的优势在于写入时无需关心底层索引名称，滚动完全自动化。
## 如何监控和排查 ILM？
查看所有索引的 ILM 状态：
```json
GET _ilm/explain?pretty
```
查看特定索引的 ILM 阶段和下一步操作：
```json
GET _ilm/explain/my-index-000001?pretty
```
常见排查思路：
- **ILM 不生效**：检查 `indices.lifecycle.poll_interval`（默认 10 分钟），策略变更后需等待轮询周期
- **索引卡在某个阶段**：用 `_ilm/explain` 查看 `step_info` 中的错误原因，常见原因是目标节点角色未配置
- **rollover 未触发**：确认索引名以数字结尾（如 `000001`）且设置了 `is_write_index: true`
- **shrink 失败**：目标分片数必须是原分片数的因子，且索引必须先设为只读
手动推进 ILM 步骤（排查用）：
```json
POST _ilm/retry/my-index-000001
```
## ILM 配置有哪些常见坑？
1. **min_age 的理解偏差**：min_age 是从索引进入上一阶段开始计时，不是索引创建时间。比如 warm 阶段 `min_age: 30d` 指的是进入 hot 阶段 30 天后（若 hot 阶段无 min_age 限制），而非索引创建 30 天后
2. **allocate 语法变更**：7.x 中用 `allocate.include/require` 分配节点，8.x 已废弃，改用节点角色自动路由（配置 `data_hot`/`data_warm`/`data_cold` 角色，ILM 自动迁移）
3. **节点角色互斥**：`data_hot`/`data_warm`/`data_cold` 不能与旧版 `data` 角色同时配置，需搭配 `data_content` 使用
4. **shrink 前必须只读**：执行 shrink 前索引必须设为 `index.blocks.write: true`，否则会失败
5. **Data Stream 不可删除单条数据**：Data Stream 是追加模型，不支持按文档 ID 删除，只能通过 ILM 删除整个 backing index
## 追问：frozen 阶段和 cold 阶段有什么区别？
cold 阶段的数据仍以完整分片存储在节点磁盘上，查询性能较好但存储成本高。frozen 阶段使用 searchable snapshot，数据存储在快照仓库中，查询时按需从快照加载缓存，存储成本极低但查询延迟较高。简单说：cold 是"低频但随时可查"，frozen 是"几乎不查但保留可搜索"。服务端5月27日 23:48
Elasticsearch 的路由机制是如何工作的？## 路由机制的核心原理
Elasticsearch 是分布式搜索引擎，每个索引由多个分片（shard）组成，每个分片是一个独立的 Lucene 索引。当写入或查询一条文档时，系统必须确定这条文档属于哪个分片——这就是路由机制要解决的问题。
路由算法的公式：
```
shard_num = hash(routing_value) % number_of_primary_shards
```
默认情况下，`routing_value` 就是文档的 `_id`。Elasticsearch 使用的哈希函数是 **Murmur3Hash**（不是 SHA-256），它计算速度快且分布均匀。这意味着相同的 `_id` 永远路由到同一个分片，保证读写的确定性。
**为什么分片数创建后不能改？** 因为一旦 `number_of_primary_shards` 变化，已有文档的路由结果会改变，导致数据"丢失"（实际还在，但按新公式找不到）。所以分片数只能在创建索引时指定。
## 写请求的路由流程
1. 客户端向任意节点发送写入请求，该节点成为**协调节点（coordinating node）**
2. 协调节点根据 `hash(_id) % primary_shards` 计算目标分片
3. 请求被转发到目标主分片所在节点，写入 Memory Buffer，最终持久化
4. 主分片写入成功后，并行复制到所有副本分片
5. 协调节点收集所有副本的响应后，返回客户端成功
## 读请求的路由流程
读请求的路由比写请求多一步选择：
1. 协调节点同样根据哈希公式定位目标分片
2. 在主分片及其所有副本中，使用 **round-robin 轮询算法**随机选一个执行查询——这就是读请求的负载均衡
3. 选中的分片返回结果给协调节点，协调节点合并后返回客户端
这个机制意味着：**副本越多，读吞吐量越高**，因为读请求可以分散到多个副本上并行处理。
## 自定义路由（custom routing）
默认按 `_id` 路由在大多数场景下没问题，但某些业务需要更精细的控制。比如一个订单系统，希望同一用户的订单落在同一分片上，这样按用户查询时只需命中一个分片，避免 scatter-gather。
### 指定 routing 参数
```bash
# 写入时指定 routing
PUT /orders/_doc/1?routing=user_123
{
"user_id": "user_123",
"amount": 99.9
}
# 查询时必须带上相同的 routing
GET /orders/_search?routing=user_123
{
"query": {
"term": { "user_id": "user_123" }
}
}
```
```java
IndexRequest request = new IndexRequest("orders");
request.id("1");
request.routing("user_123");
request.source("user_id", "user_123", "amount", 99.9);
client.index(request, RequestOptions.DEFAULT);
```
### 自定义路由的三个坑
**坑一：查询忘带 routing，触发全分片扫描。** 写入时用了 routing，查询时没带，Elasticsearch 会在所有分片上执行搜索，性能急剧下降。
**坑二：routing 值不均匀导致数据倾斜。** 如果用 `city` 做 routing，北上广深的数据量远超其他城市，会造成某些分片过大。解决方案是对 routing 值再加一层哈希，或在 routing 后面拼序号（如 `user_123_0`、`user_123_1`），人为分散到多个分片。
**坑三：更新文档时 routing 必须一致。** 如果更新时用了不同的 routing 值，旧文档不会被覆盖，而是作为新文档写入另一个分片，造成数据冗余。
### required_routing 强制约束
从 Elasticsearch 7.x 开始，可以在 mapping 中配置 `routing` 为 `required`：
```json
PUT /orders
{
"mappings": {
"_routing": {
"required": true
}
}
}
```
设为 `required` 后，不带 routing 的写入和查询请求会被直接拒绝，从机制上避免坑一。
## 分片分配感知（Allocation Awareness）
除了文档级别的路由，Elasticsearch 还支持节点级别的分片分配策略，确保主分片和副本分布在不同物理机上：
```yaml
# elasticsearch.yml
node.attr.rack_id: rack_one
cluster.routing.allocation.awareness.attributes: rack_id
```
配置后，Elasticsearch 尽量将同一分片的主副本分布在不同 rack 上。如果某个 rack 宕机，数据仍然可用。
还可以配置 **forced awareness**，防止集群在只有一个 rack 时将主副本分配到同一 rack：
```yaml
cluster.routing.allocation.awareness.attributes: rack_id
cluster.routing.allocation.awareness.force.rack_id.values: rack_one,rack_two
```
## 面试追问
**Q：路由公式为什么用取模而不是一致性哈希？**
取模保证分片数不变时结果确定，实现简单且均匀。一致性哈希在节点增减时只需迁移少量数据，但 Elasticsearch 的分片数固定不变（创建后不可改），取模已经够用。这也是分片数不能改的根本原因。
**Q：如何监控路由是否均匀？**
`GET _cat/shards?v` 查看各分片的 docs 数和 store 大小。如果某分片明显偏大，说明 routing 值分布不均，需要调整 routing 策略或增加分片数。
**Q：_id 和 routing 的关系是什么？**
`_id` 是文档唯一标识，routing 是路由计算依据。默认 routing = `_id`，但自定义 routing 后两者独立。_id 保证文档唯一性，routing 决定文档存在哪个分片。服务端5月27日 23:48
Elasticsearch 的 bool 查询如何组合多个查询条件？Elasticsearch 的 bool 查询是日常开发中使用频率最高的复合查询，它通过四个子句——must、should、must_not、filter——实现 AND/OR/NOT 逻辑组合。面试中，能否讲清这四个子句的区别、各自对相关性评分的影响，以及 filter 上下文的性能优势，是考察重点。
## 四个子句各自做什么
bool 查询的四个子句分别对应不同的逻辑角色：
- **must**：文档必须匹配，等价于逻辑 AND，参与相关性评分
- **should**：文档匹配任意一个即可，等价于逻辑 OR，参与相关性评分
- **must_not**：文档必须不匹配，等价于逻辑 NOT，不参与评分（属于 filter 上下文）
- **filter**：文档必须匹配，但不参与评分，仅做过滤（属于 filter 上下文）
这里有一个容易混淆的点：must 和 filter 在逻辑上都是 AND 语义，区别在于 **must 参与评分，filter 不参与**。这意味着当你只关心"是否匹配"而不关心"匹配得好不好"时，应该用 filter。
## Query Context 与 Filter Context
理解 bool 查询的关键在于区分两种上下文：
- **Query Context**（查询上下文）：must 和 should 处于此上下文，会计算相关性评分（_score），回答"匹配得有多好"
- **Filter Context**（过滤上下文）：filter 和 must_not 处于此上下文，不计算评分，回答"是否匹配"，且结果会被缓存以提升后续查询性能
这也是为什么面试中常问"filter 和 must 有什么区别"——本质是评分 vs 不评分、缓存 vs 不缓存的区别。
## minimum_should_match 的行为
should 子句有一个关键参数 `minimum_should_match`，它决定了至少需要匹配几个 should 条件：
- **当 bool 中没有 must 或 filter 时**，默认值为 1，即至少匹配一个 should 条件
- **当 bool 中存在 must 或 filter 时**，默认值为 0，即 should 条件完全可选，仅用于提升评分
这个默认值的变化是面试高频考点。如果不知道这个规则，查询结果可能和预期不一致。
```json
{
"query": {
"bool": {
"must": [
{ "match": { "title": "手机" } }
],
"should": [
{ "term": { "brand": "华为" } },
{ "term": { "brand": "小米" } }
]
}
}
}
```
上面这个查询中，由于存在 must，should 默认不强制匹配。意味着"手机"关键词匹配即可，华为和小米只是加分项。如果要求必须匹配华为或小米之一，需要显式设置 `"minimum_should_match": 1`。
## 组合示例
### AND 逻辑：must
查询标题包含"手机"且价格低于 1000 的商品：
```json
{
"query": {
"bool": {
"must": [
{ "match": { "title": "手机" } },
{ "range": { "price": { "lt": 1000 } } }
]
}
}
}
```
### OR 逻辑：should
查询标题包含"手机"或类别为"电子产品"：
```json
{
"query": {
"bool": {
"should": [
{ "match": { "title": "手机" } },
{ "term": { "category": "电子产品" } }
],
"minimum_should_match": 1
}
}
}
```
### NOT 逻辑：must_not
查询标题包含"手机"但排除品牌为"Apple"：
```json
{
"query": {
"bool": {
"must": [
{ "match": { "title": "手机" } }
],
"must_not": [
{ "term": { "brand": "Apple" } }
]
}
}
}
```
### filter 优先的复合查询
实际开发中最常用的模式：全文检索用 must，精确过滤用 filter：
```json
{
"query": {
"bool": {
"must": [
{ "match": { "title": "手机" } }
],
"filter": [
{ "range": { "price": { "gte": 500, "lt": 1000 } } },
{ "term": { "status": "在售" } }
],
"must_not": [
{ "term": { "brand": "Apple" } }
],
"should": [
{ "term": { "brand": "华为" } }
],
"minimum_should_match": 0
}
}
}
```
这个查询的语义是：标题匹配"手机"，价格在 500-1000 之间，状态为"在售"，排除 Apple，华为品牌加分但不强制。
## 评分机制
bool 查询的评分遵循"匹配越多分数越高"的原则：
- must 子句的评分会相加
- should 子句的评分也会相加
- filter 和 must_not 不影响评分
- 最终 _score = must 评分之和 + should 评分之和
可以用 `boost` 参数调整单个查询的权重，比如让标题匹配的权重是内容匹配的 3 倍：
```json
{ "match": { "title": { "query": "手机", "boost": 3 } } }
```
## bool 嵌套
bool 查询可以嵌套使用，实现更复杂的逻辑。比如"查询标题包含手机或电脑，且价格低于 1000"：
```json
{
"query": {
"bool": {
"must": [
{ "bool": {
"should": [
{ "match": { "title": "手机" } },
{ "match": { "title": "电脑" } }
],
"minimum_should_match": 1
}
],
"filter": [
{ "range": { "price": { "lt": 1000 } } }
]
}
}
}
```
嵌套时内层 bool 的 minimum_should_match 规则同样适用：内层 bool 只有 should 没有 must/filter，所以默认 minimum_should_match 为 1。
## 面试常见追问
**Q: filter 和 must 都是 AND 语义，什么时候用 filter？**
A: 当条件不需要影响排序（即不关心相关性评分）时用 filter。filter 上下文不计算评分，且结果会被 Elasticsearch 自动缓存，查询性能显著优于 must。典型场景：状态过滤、价格范围、日期区间等精确值过滤。
**Q: should 在什么情况下是可选的？**
A: 当 bool 中同时存在 must 或 filter 子句时，should 默认不强制匹配（minimum_should_match 默认为 0），仅用于提升匹配文档的评分。如果需要强制匹配，显式设置 minimum_should_match。
**Q: bool 查询性能优化有哪些手段？**
A: 三点：一是精确匹配条件放 filter 而非 must，利用缓存；二是避免 should 中放过多子句，每个子句都会计算评分；三是对 filter 中使用的字段确保映射类型正确（如 price 用数值类型而非 keyword），避免类型转换开销。服务端5月27日 23:47
Elasticsearch 的 master 节点和 data 节点有什么区别？## 一句话回答
Master 节点管集群——负责元数据维护、索引创建删除、分片分配和主节点选举；Data 节点管数据——负责文档的存储、索引写入和查询执行。生产环境中两者必须分离部署，否则数据节点的高负载会拖垮集群管理，导致脑裂甚至集群不可用。
## 核心职责对比
| 维度 | Master 节点 | Data 节点 |
|------|------------|-----------|
| 核心任务 | 集群状态维护、元数据管理 | 文档存储、查询执行 |
| 是否存用户数据 | 否，仅存集群元信息（mapping、settings） | 是，以分片形式存储索引数据 |
| CPU 消耗 | 低（管理任务轻量） | 高（查询/索引密集） |
| 内存消耗 | 低（元数据体量小） | 高（依赖文件系统缓存） |
| 磁盘 I/O | 极低 | 高（读写分片数据） |
| 配置方式 | `node.roles: [master]` | `node.roles: [data]`（7.x 后可细分为 data_content/data_hot/data_cold/data_frozen） |
## Master 节点详解
Master 节点是集群的协调中心，具体职责：
- **集群状态管理**：维护全局 ClusterState，包括索引元数据、分片路由表、节点列表等。任何索引操作（创建/删除/映射变更）都由 master 节点发起状态变更，再广播给所有节点。
- **分片分配**：决定每个分片分配到哪个数据节点，平衡负载并在节点故障时触发分片迁移。
- **主节点选举**：集群启动或当前 master 失联时，候选 master 节点通过投票选出新 master。选举要求获得 N/2+1 票（N 为候选节点数），因此推荐部署 3 个专用 master 节点形成多数派。
生产配置示例：
```yaml
node.roles: [master]
cluster.initial_master_nodes: ['master-1', 'master-2', 'master-3']
```
`cluster.initial_master_nodes` 只在集群首次启动时使用，用于引导选举。集群形成后，新节点加入不需要再配置此参数。
## Data 节点详解
Data 节点承载实际的数据读写压力：
- **文档索引**：接收写入请求，将文档存入对应分片的 Lucene 段。
- **查询执行**：在本地分片上执行搜索、聚合操作，返回结果给协调节点。
- **副本同步**：维护主分片的副本分片，保证数据冗余和查询吞吐量。
ES 7.x 之后，Data 角色进一步细分为：
| 子角色 | 用途 |
|--------|------|
| `data_content` | 存储常访问的内容索引 |
| `data_hot` | 存储时序类热点数据，需 SSD |
| `data_warm` | 存储访问频率降低的时序数据 |
| `data_cold` | 存储很少访问的冷数据，可用 HDD |
| `data_frozen` | 存储极少访问的归档数据 |
这种分层存储架构是冷热分离策略的基础，可以大幅降低存储成本。
## 为什么生产环境必须分离
混合角色（`node.roles: [master, data]`）在小规模测试中可用，但在生产环境会带来严重问题：
- **性能干扰**：Data 节点处理重查询时 CPU 飙升，master 的集群协调任务被阻塞，导致心跳超时、选举延迟，甚至触发误判的故障转移。
- **脑裂风险**：如果 master 角色所在节点因数据负载过高而假死，其他节点可能发起重新选举。若网络分区导致旧 master 仍认为自己在任，就会出现双 master——即脑裂。ES 7.x 后已移除 `discovery.zen.minimum_master_nodes` 参数，改由集群自动管理多数派，但这依赖于 master 节点能够及时响应。
- **故障域重叠**：Data 节点磁盘满或 OOM 时，同时担任的 master 角色也会崩溃，集群失去管理能力，数据分片无法迁移，整个集群可能瘫痪。
验证节点角色是否正确分离：
```bash
curl -XGET 'http://localhost:9200/_cat/nodes?v&h=name,roles'
```
输出中每个节点应只显示单一角色（`m` 或 `d`），避免出现 `md` 混合。
## 协调节点补充
除了 master 和 data，还有一类容易忽略的角色——协调节点（Coordinating Node），配置为 `node.roles: []`（空角色）。它不存数据、不参与选举，只负责接收客户端请求、分发到相关 data 节点、合并结果后返回。在查询聚合场景下，专用协调节点可以避免 data 节点承担结果合并的内存开销。
## 追问：Master 选举过程是怎样的？
ES 7.x 使用基于 Raft 的选举协议。当集群中 master 失联时，候选节点进入选举流程：先按 nodeId 排序确定优先级，优先级最高的候选节点发起投票，其他节点收到投票请求后检查任期号和日志完整性，决定是否投票。获得多数票（N/2+1）的节点成为新 master。整个过程通常在秒级完成，期间集群处于只读状态。
选举触发条件包括：master 节点宕机、网络分区导致心跳超时（默认 30s）、master 主动卸任。生产环境中，3 个 master 节点可容忍 1 个故障，这是最低推荐配置。服务端5月27日 23:46
Elasticsearch 深度分页是怎么产生的？有哪些解决方案？Elasticsearch 使用 `from + size` 做分页时，翻到靠后的页面会越来越慢，甚至直接报错。这个现象叫深度分页问题，是 ES 面试的高频考点。
## 深度分页是怎么产生的
ES 的分页查询由协调节点协调：假设 `from=10000, size=10`，协调节点会向每个分片请求 `from + size = 10010` 条数据，在内存中合并排序后只取最后 10 条返回。分片越多，需要合并的数据量越大，内存占用和延迟随页码深度指数上升。
ES 默认通过 `index.max_result_window`（默认值 10000）限制 from + size 的上限，超过直接抛异常。这不是 bug，而是保护机制。
核心问题就一句话：**协调节点必须持有所有分片的前 N 条数据才能做全局排序，翻页越深，N 越大。**
## 解决方案一：search_after（推荐）
`search_after` 是官方推荐的实时深分页方案。原理是用上一页最后一条文档的排序值作为游标，下一页直接从该位置向后查，不需要跳过前面所有数据。
**首次请求：**
```json
GET /my_index/_search
{
"size": 10,
"sort": [
{ "timestamp": "desc" },
{ "_id": "asc" }
]
}
```
返回结果中每条文档都带有 `sort` 值，取最后一条：
```json
"sort": ["2025-06-15T10:30:00.000Z", "abc123"]
```
**后续请求：**
```json
GET /my_index/_search
{
"size": 10,
"search_after": ["2025-06-15T10:30:00.000Z", "abc123"],
"sort": [
{ "timestamp": "desc" },
{ "_id": "asc" }
]
}
```
**要点：**
- 排序字段必须全局唯一（推荐 `timestamp + _id` 组合），否则游标定位不准
- 只能向后翻页，不能跳页
- 实时性：每次查询都反映最新数据
- ES 7.10+ 引入 PIT（Point in Time）配合 search_after 使用，可保证翻页期间索引数据一致
**PIT 用法：**
```json
// 1. 先创建 PIT
POST /my_index/_pit?keep_alive=1m
// 返回 pit_id
// 2. 带 PIT 查询
GET /_search
{
"size": 10,
"pit": { "id": "pit_id值", "keep_alive": "1m" },
"sort": [{ "timestamp": "desc" }, { "_id": "asc" }]
}
// 3. 后续请求同时带 pit 和 search_after
GET /_search
{
"size": 10,
"pit": { "id": "pit_id值", "keep_alive": "1m" },
"search_after": ["2025-06-15T10:30:00.000Z", "abc123"],
"sort": [{ "timestamp": "desc" }, { "_id": "asc" }]
}
```
## 解决方案二：scroll
scroll 创建一个数据快照上下文，按批次遍历全部结果，适合数据导出、全量迁移等离线场景。
```json
// 初始化
GET /my_index/_search?scroll=1m
{
"size": 1000,
"query": { "match_all": {} }
}
// 后续请求
GET /_search/scroll
{
"scroll": "1m",
"scroll_id": "上一次返回的scroll_id"
}
// 用完务必清理
DELETE /_search/scroll
{
"scroll_id": "scroll_id值"
}
```
**要点：**
- `scroll` 参数控制上下文存活时间，建议设分钟级（如 `1m`），用完必须删除，否则占内存
- 快照语义：遍历期间看不到数据变更，不适合实时查询
- ES 7.10+ 官方建议新项目用 PIT + search_after 替代 scroll
## 三种方案对比
| 方案 | 能否跳页 | 实时性 | 性能 | 适用场景 |
|------|---------|--------|------|----------|
| from + size | 能 | 实时 | 深页差 | 前 10000 条内的随机翻页 |
| search_after | 不能 | 实时 | 恒定 | 在线深分页、无限滚动加载 |
| scroll | 不能 | 快照 | 恒定 | 数据导出、批量迁移 |
## 常见追问
**Q1: 为什么不直接调大 max_result_window？**
调大只是掩盖问题。from=50000 时协调节点仍要合并所有分片的前 50010 条数据，内存和 CPU 开销不会消失，只是从报错变成慢查询，最后还是会 OOM。
**Q2: search_after 在数据插入后游标会失效吗？**
不会失效，但可能重复或遗漏。新增文档如果排序值落在已翻过的范围内，不会出现；如果落在未翻过的范围内，会出现。配合 PIT 使用可以冻结索引视图，彻底解决一致性问题。
**Q3: 生产环境怎么选？**
- 前端分页跳转（第1页、第5页、第50页）：from + size，配合业务限制最大页码
- 无限滚动加载 / 加载更多：search_after
- 后台数据导出：scroll，或 PIT + search_after服务端5月27日 00:34
Elasticsearch 如何监控集群状态和性能指标？监控 ES 集群，最常用的三个入口：`_cluster/health` 看整体状态，`_cat/nodes` 看节点资源，Kibana Stack Monitoring 看可视化大盘。生产环境一般是 API + Prometheus + Grafana 的组合：API 做快速诊断，Prometheus 采 metrics，Grafana 出图 + 告警。
`_cluster/health` 返回 status（green/yellow/red），green 正常，yellow 有未分配副本，red 有主分片丢失。red 要立即查节点是不是挂了或者磁盘满了。
`_cat/nodes?v` 看每个节点的 heap.percent、cpu、disk.used。heap.percent 超 70% 就该告警，超 80% 可能 OOM。
Kibana 的 Stack Monitoring 不用额外部署，开箱即用。Overview 看集群状态，Nodes 看 CPU/内存/磁盘，Indices 看搜索延迟和索引速率。设好阈值就能自动告警。
生产环境一般加 Prometheus exporter 采 `_nodes/stats` 的 JVM 内存、查询延迟、磁盘 IO 等指标，Grafana 里建仪表板。比 Kibana 灵活，可以和其他服务的监控放一起看。
## 追问
### cluster health 返回 yellow 怎么排查？
yellow 表示主分片都正常但部分副本分片没分配。常见原因：节点数不够（比如索引设了 1 副本但只有一个节点）、磁盘满了、分片分配被手动关闭。用 `_cluster/allocation/explain` 看具体原因。
### ES 节点频繁 OOM 怎么定位？
先看 heap.percent 趋势，是不是持续上涨（内存泄漏）还是突发峰值（大查询）。用 `_nodes/hot_threads` 找慢线程，用 `_tasks` 看正在跑的耗时任务。大概率是聚合查询或深度分页导致的。
### 磁盘突然满了怎么办？
先看哪些索引占用大：`_cat/indices?v&s=store.size:desc`。紧急扩容或者删旧索引。长期方案：设 ILM（索引生命周期管理），按时间或大小自动 rollover 和删除。
### Kibana 监控和 Prometheus 监控怎么选？
Kibana 开箱即用，适合小团队快速上手。Prometheus + Grafana 灵活但需要维护 exporter，适合已经把其他服务也接 Prometheus 的团队。可以一起用，不冲突。服务端3月6日 21:12
ElasticSearch 与传统关系型数据库的主要区别是什么？在现代IT架构中，ElasticSearch（ES）作为分布式搜索与分析引擎，与传统关系型数据库（如MySQL、PostgreSQL）常被并置讨论。两者在数据存储、查询模型和应用场景上存在根本差异，理解这些区别对系统设计至关重要。本文深入剖析关键差异，结合技术细节与实践案例，帮助开发者在实际项目中做出明智选择。
## 1. 数据模型与存储机制
### 1.1 关系型数据库：表格化结构
传统关系型数据库基于表格模型，数据组织为行和列，严格遵循SQL标准。每个表定义固定模式，确保数据结构一致性。例如，用户表（users）包含id、name、email等字段，且所有记录必须符合模式。
**优势**：强一致性、事务完整性（ACID），适合金融交易等关键业务。
**局限性**：水平扩展困难，复杂查询效率低。例如，跨多表的JOIN操作在大数据量下性能显著下降。
### 1.2 ElasticSearch：文档存储与JSON格式
ElasticSearch采用文档存储模型，数据以JSON格式索引，每个文档可动态定义字段（schema-less）。数据存储在倒排索引中，支持全文搜索和复杂过滤。
**优势**：灵活扩展，无需预定义模式；支持高吞吐量写入。
**局限性**：不支持事务（无ACID保证），更适合日志分析等场景。
**代码示例对比**：
* **关系型数据库（SQL）**：
```sql
CREATE TABLE users (
id INT PRIMARY KEY,
name VARCHAR(50),
email VARCHAR(100)
);
INSERT INTO users (id, name, email) VALUES (1, 'John', 'john@example.com');
SELECT * FROM users WHERE name = 'John';
```
* **ElasticSearch（JSON文档）**：
```json
{
"index": "users",
"id": 1,
"source": {
"name": "John",
"email": "john@example.com"
}
}
```
查询示例：
```json
{
"query": {
"match": {
"name": "John"
}
}
}
```
## 2. 查询能力与性能特性
### 2.1 关系型数据库：SQL查询
基于SQL，查询语言结构化且强类型，支持复杂聚合（如GROUP BY）和事务。但全表扫描在大数据集下效率低下，且JOIN操作需优化索引。
**性能瓶颈**：在100万记录以上，JOIN查询可能慢于秒级。
### 2.2 ElasticSearch：全文搜索与实时分析
ES利用Lucene引擎提供全文搜索（如分词、模糊匹配），支持分布式查询。其倒排索引允许毫秒级响应，尤其适合高并发场景。
**性能优势**：在10亿级数据中，ES的搜索延迟通常低于100ms，而关系型数据库可能超过秒级。
**实践建议**：
* 使用ES处理日志分析或搜索应用：例如，ElasticSearch的Kibana仪表盘可实时监控系统日志。
* 关系型数据库用于事务处理：如订单系统需确保数据一致性。
## 3. 扩展性与部署模型
### 3.1 关系型数据库：垂直扩展
传统数据库依赖垂直扩展（升级硬件），如增加CPU/RAM。MySQL集群（如Galera）可实现读写分离，但写入瓶颈明显。
**局限性**：单节点扩展上限低，分布式模式复杂。
### 3.2 ElasticSearch：水平扩展与分布式架构
ES设计为分布式系统，数据自动分片（shards）并复制到多节点。通过Elasticsearch Cluster，可轻松扩展到数千节点，支持线性扩展。
**扩展示例**：
* 添加节点：`PUT /_cluster/settings { "transient": { "cluster.routing.allocation.enable": "all" } }`
* 查询分片：`GET /users/_shard_stores`
**实践建议**：
* 对于日志分析（如ELK栈），ES的水平扩展能力可处理PB级数据。
* 关系型数据库在单机或小集群下更高效，但需考虑分库分表（如ShardingSphere）。
## 4. 数据一致性与事务处理
### 4.1 关系型数据库：强一致性
遵循ACID原则，确保数据在事务中一致。例如，银行转账需原子性操作，任何失败都会回滚。
**技术保障**：通过MVCC（多版本并发控制）和锁机制。
### 4.2 ElasticSearch：最终一致性
ES优先保证可用性与分区容忍性（CAP定理），数据一致性为最终一致性。写入操作异步，可能导致短暂不一致。
**适用场景**：日志分析中可容忍短暂延迟，但关键业务需谨慎。
**对比总结**：
* 关系型数据库：强一致性，适合事务密集型应用。
* ElasticSearch：弱一致性，适合高吞吐量搜索。
## 5. 实际应用场景建议
### 5.1 何时选择ElasticSearch
* **日志分析**：如ELK栈处理系统日志，ES的全文搜索可快速定位错误。
* **全文搜索**：电商网站商品搜索，利用分词和同义词扩展。
* **实时分析**：监控指标（如Kibana仪表盘），支持实时可视化。
### 5.2 何时选择关系型数据库
* **事务处理**：如订单系统，需确保数据完整性和一致性。
* **结构化数据**：用户账户管理，固定模式可优化查询。
**实践案例**：
* 某电商平台结合两者：
* 用户会话存储在Redis（内存数据库），但核心交易在MySQL。
* 搜索功能使用ES，处理商品索引。
**关键建议**：
* **避免二选一**：在大型系统中，混合使用（如MySQL存结构化数据，ES存搜索数据）可发挥各自优势。
* **测试验证**：使用BenchmarkSQL（关系型）和ESSQL（ES）进行压力测试，确保符合需求。
## 结论
ElasticSearch与传统关系型数据库的核心区别在于：**ES以搜索和分析为中心，关系型数据库以事务和结构化为中心**。ES的分布式特性使其在大数据和实时搜索场景中脱颖而出，而关系型数据库在ACID事务中无可替代。开发者应根据业务需求权衡：若需高吞吐量搜索，ES是优选；若需严格事务，关系型数据库更可靠。通过合理组合（如使用ES处理日志，MySQL处理订单），可构建高效、可扩展的现代应用架构。记住：没有银弹，选择应基于具体场景而非技术偏好。
## 参考资料
* [Elasticsearch官方文档](https://www.elastic.co/guide/en/elasticsearch/reference/current/index.html)
* [MySQL性能优化指南](https://dev.mysql.com/doc/refman/8.0/en/optimization.html)
服务端3月6日 21:11
Elasticsearch 的冷热架构如何设计和实现？在现代大数据应用中，Elasticsearch 作为分布式搜索与分析引擎，其性能与成本优化至关重要。随着数据量激增，单一节点架构难以满足高吞吐、低延迟和低成本存储的需求。冷热架构（Hot-Cold Architecture）应运而生，通过将数据按访问频率划分为热数据（Hot Data）和冷数据（Cold Data），实现资源的精细化管理：热数据存储在高性能节点上以加速查询，冷数据则迁移至低成本节点以节省存储开销。本文将深入探讨冷热架构的设计原理、实现细节及最佳实践，帮助开发者构建高效、可扩展的 Elasticsearch 部署方案。
## 冷热架构概述
### 定义与背景
冷热架构的核心思想是基于数据生命周期动态分配资源。热数据指近期活跃、频繁查询的索引（如日志或实时交易数据），需高 I/O 和低延迟访问；冷数据指历史或低频访问的索引（如归档日志），可容忍高延迟但要求低成本存储。Elasticsearch 7.10+ 版本通过 **Index Lifecycle Management (ILM)** 和 **Data Streams** 技术原生支持此架构，避免了手动分片管理的复杂性。
**为什么需要冷热架构？**
* **成本优化**：冷数据存储成本可降低 60% 以上（基于 AWS S3 与 EBS 对比测试）。
* **性能提升**：热节点可减少 40% 的查询延迟（参考 Elastic Stack 性能报告）。
* **可扩展性**：支持动态数据增长，避免单集群过载。
### 关键组件
冷热架构依赖以下核心组件：
* **热节点 (Hot Nodes)**：配备 SSD 存储、高 CPU 和内存，用于索引和搜索。
* **冷节点 (Cold Nodes)**：使用 HDD 存储、低成本实例，专为只读查询设计。
* **索引生命周期管理 (ILM)**：自动化数据路由策略，基于时间或大小触发迁移。
* **数据流 (Data Streams)**：简化索引管理，自动创建按时间分区的索引。
## 设计原则
### 数据生命周期管理
设计冷热架构时，需定义明确的数据生命周期阶段：
* **热阶段 (Hot)**：数据创建后 7 天内，用于高频查询。
* **温阶段 (Warm)**：数据保留 30 天，仅用于读操作（可选）。
* **冷阶段 (Cold)**：数据超过 90 天，仅存储且不参与搜索。
**设计要点**：
* 依据业务场景设定阈值：例如，日志类应用通常设置 `max_age: 7d` 为热阶段。
* 避免过度复杂化：温阶段非必需，可直接跳转至冷阶段以简化架构。
### 分片策略
分片策略需与冷热节点匹配：
* **热数据分片**：分配到热节点，确保分片大小 \< 50GB（防止单节点过载）。
* **冷数据分片**：迁移至冷节点，允许分片大小 > 50GB 以节省资源。
**最佳实践**：
* 使用 `number_of_shards` 固定为 1，避免热冷数据混合分片。
* 热数据需启用 `index.codec: best_compression` 以减少存储占用。
## 实现步骤
### 配置 ILM 策略
ILM 是实现冷热架构的基石。通过 API 定义策略，指定数据迁移规则：
```json
{
"policy": {
"description": "Elasticsearch Hot-Cold Policy",
"index_patterns": ["logs-*"],
"data_streams": { "enabled": true },
"policy": {
"description": "Hot-Cold Automation",
"indices": {
"rollover": {
"max_size": "50gb",
"max_age": "7d"
},
"delete": {
"min_age": "90d"
}
},
"actions": {
"allocate": {
"require": {
"data": "hot"
}
},
"allocate": {
"require": {
"data": "cold"
}
}
}
}
}
}
```
**关键配置说明**：
* `rollover`：当索引大小达 50GB 或年龄 7 天时自动分片。
* `delete`：90 天后自动删除冷数据。
* `allocate.require`：强制数据路由至热/冷节点（需先配置节点角色）。
### 部署冷热节点
在 Elasticsearch 集群中，需明确节点角色：
1. **创建热节点**：
```bash
curl -XPUT "http://localhost:9200/_cluster/settings" -H 'Content-Type: application/json' -d '{
"persistent": {
"cluster.routing.allocation.require.data": "hot",
"cluster.routing.allocation.require.index": "hot"
}
}'
```
2. **创建冷节点**：
```bash
curl -XPUT "http://localhost:9200/_cluster/settings" -H 'Content-Type: application/json' -d '{
"persistent": {
"cluster.routing.allocation.require.data": "cold",
"cluster.routing.allocation.require.index": "cold"
}
}'
```
**节点配置建议**：
* 热节点：使用 `elasticsearch-node` 作为 `data` 属性（例如 `data: hot`）。
* 冷节点：使用 `elasticsearch-node` 作为 `data` 属性（例如 `data: cold`）。
* 确保冷节点无 `search` 角色，避免查询性能下降。
### 代码示例：自动迁移数据
以下 Python 脚本使用 Elasticsearch Python API 演示数据迁移：
```python
from elasticsearch import Elasticsearch
client = Elasticsearch()
# 创建数据流索引（自动管理热数据）
client.indices.create(
index='logs-2023-10',
body={
'settings': {
'index.lifecycle.rollover.condition': 'max_age:7d',
'index.lifecycle.rollover.max_age': '7d'
}
}
)
# 触发冷数据迁移（示例：90天后迁移）
client.indices.put_settings(
index='logs-2023-10',
body={
'index.lifecycle.rollover': {
'max_size': '50gb',
'max_age': '7d'
},
'index.lifecycle.delete': {
'min_age': '90d'
}
}
)
```
**注意事项**：
* 需先启用 ILM：`PUT /_ilm/policy` 配置策略。
* 冷数据迁移需在 `delete` 阶段触发，避免查询中断。
## 实践建议
### 监控与调优
* **关键指标**：监控 `cluster.stats` 中的 `indexing_total` 和 `search_total`，确保热节点负载 \< 70%。
* **工具推荐**：使用 Kibana Visualize 面板追踪数据迁移速率（例如，`ilm: data_stream` 索引）。
* **阈值设置**：当热数据分片大小 > 80GB 时，自动触发分片重组。
### 避免常见陷阱
* **数据碎片化**：热冷数据混合存储会导致查询性能下降，必须通过 `require` 策略隔离。
* **冷数据查询延迟**：冷节点仅支持只读查询，若需实时分析，应保留温阶段（可选）。
* **配置错误**：误设 `index.lifecycle.rollover` 会导致数据滞留，需定期验证 ILM 状态：`GET /_ilm/explain`。
### 性能优化技巧
* **存储压缩**：热数据启用 `index.codec: best_compression`，冷数据使用 `index.codec: best_compression` 以节省空间。
* **批量操作**：使用 `bulk API` 处理热数据写入，提升吞吐量。
* **自动扩展**：结合 Kubernetes 部署热节点，通过 HPA 基于 CPU 指标动态调整。
## 结论
Elasticsearch 的冷热架构通过数据生命周期管理，显著优化了存储成本与查询性能。设计时需以业务场景为基准，定义清晰的热冷阈值，并结合 ILM 和节点角色配置实现自动化。实践表明，合理配置可降低 30-60% 的云存储费用，同时提升查询响应速度。建议开发者优先部署 ILM 策略，并持续监控集群健康状态。未来趋势中，结合机器学习的动态资源分配（如通过 Elasticsearch 8.0 的 ML 功能）将进一步提升架构智能化水平。记住：冷热架构不是银弹，需根据数据特征迭代调整，以实现最佳平衡。
> **参考资料**：
>
>
***
## 附：关键配置速查表
| **组件** | **热数据** | **冷数据** |
| -------- | ------------------------------- | ------------------------------- |
| **存储类型** | SSD (EBS gp3) | HDD (S3) |
| **节点角色** | `data: hot` | `data: cold` |
| **索引设置** | `index.codec: best_compression` | `index.codec: best_compression` |
| **生命周期** | max\_age: 7d | min\_age: 90d |