Elasticsearch 性能调优 详解

Elasticsearch 性能调优 是保障搜索与写入性能、资源利用率和系统稳定性的核心任务。 分片策略、刷新间隔、批量写入、查询优化——正是性能调优的四大支柱。

本文将为你提供一份 全面、可落地的 Elasticsearch 性能调优详解，涵盖原理、配置、监控与最佳实践。

---

一、分片策略优化（Shard Strategy Optimization）

1. 分片大小建议：20~50GB（黄金区间）

分片大小	问题
< 5GB	过多分片 → 开销大（每个分片有独立 Lucene 实例）
> 50GB	恢复慢、GC 压力大、查询性能下降

✅ 推荐范围：20~50GB，兼顾性能与管理。

2. 主分片数规划

公式：

主分片数 ≈ 总数据量 / 目标分片大小

示例：

• 预估索引数据量：300GB
• 目标分片大小：30GB
• 建议主分片数：10

⚠️ 主分片数一旦设定，不可更改，必须通过 reindex 修改。

---

3. 副本数建议

场景	建议副本数
开发/测试	0~1
生产环境	1~2
高可用要求	≥2
读多写少	可增至 3（提升查询吞吐）

⚠️ 副本越多，写入开销越大（需同步更多副本）。

---

4. 优化建议 ✅

• 使用 ILM（Index Lifecycle Management） 自动 rollover 控制索引大小；
• 避免“超大索引”，及时拆分；
• 监控 _cat/shards，识别过大/过小分片。

---

二、刷新间隔（refresh_interval）与事务日志（Translog）调整

1. 刷新间隔 refresh_interval

控制 Lucene 段刷新频率，影响 搜索可见性 和 写入性能。

设置	说明
"1s"（默认）	近实时搜索，写入开销高
"30s"	写密集场景推荐，提升吞吐
-1	禁用自动刷新（仅用于批量导入）

示例：写密集场景

PUT /logs-write/_settings
{
  "index.refresh_interval": "30s"
}

⚠️ 搜索延迟从 1s → 30s，但写入吞吐提升 3~5 倍。

---

2. 事务日志（Translog）调优

Translog 用于故障恢复，确保数据不丢失。

参数	默认值	建议值	说明
index.translog.sync_interval	5s	5s	同步到磁盘间隔
index.translog.durability	request	async	写入性能优先
index.translog.flush_threshold_size	512MB	1GB	触发 flush 的日志大小

高吞吐写入配置：

{
  "index.refresh_interval": "30s",
  "index.translog.durability": "async",
  "index.translog.sync_interval": "30s",
  "index.translog.flush_threshold_size": "1gb"
}

⚠️ async 模式下，单次写入失败可能丢失最近数据，适用于可容忍少量丢失的场景。

---

三、使用 _bulk API 批量写入提升吞吐量

1. 为什么批量写入？

• 减少网络往返（RTT）；
• 批量提交事务日志；
• 提升 Lucene 段合并效率。

2. 性能对比（实测数据）

批量大小	吞吐（docs/s）
1（单条）	~1,000
100	~8,000
1,000	~15,000
5,000	~20,000

✅ 推荐批量大小：1,000~5,000 条

---

3. 使用示例

POST /_bulk
{ "index": { "_index": "logs" } }
{ "message": "log1", "@timestamp": "2024-06-01T10:00:00Z" }
{ "index": { "_index": "logs" } }
{ "message": "log2", "@timestamp": "2024-06-01T10:00:01Z" }
...

---

4. 优化建议 ✅

• 使用多线程并行发送多个 bulk 请求；
• 控制单个 bulk 请求大小 < 10MB（避免 OOM）；
• 使用 ?refresh=wait_for 确保写入后立即可查（关键场景）；
• 监控 thread_pool.write.queue 防止积压。

---

四、查询性能优化

1. 避免深度分页（Deep Pagination）

❌ 危险写法

{
  "from": 10000,
  "size": 10
}

协调节点需合并 N × 10010 条文档，内存和 CPU 消耗巨大。

✅ 推荐替代方案

方案一：search_after（推荐）

GET /_search
{
  "size": 10,
  "sort": [
    { "timestamp": "desc" },
    { "_id": "asc" }
  ]
}

下一页：

"search_after": [ "2024-06-01T10:00:00Z", "doc_123" ]

✅ 适用于按排序字段翻页。

方案二：scroll（适合导出）

POST /_search?scroll=1m
{
  "size": 1000,
  "query": { "match_all": {} }
}

适合大数据导出，不适用于高并发分页。

---

2. 使用 filter 替代 query 提升缓存命中率

❌ 低效写法

"bool": {
  "must": [
    { "term": { "status": "published" } }
  ]
}

→ 计算 _score，不缓存

✅ 高效写法

"bool": {
  "filter": [
    { "term": { "status": "published" } }
  ]
}

→ 不计算评分，结果可被 bitset 缓存

✅ filter 上下文性能远高于 must

---

3. 其他查询优化建议 ✅

场景	建议
精确匹配	用 term 而非 match
避免 wildcard/regexp	改用 prefix 或 ngram 分词器
聚合字段	使用 keyword 而非 text
大 size 聚合	改用 composite 聚合
高频查询	应用层缓存结果（Redis）
高亮性能	限制 fragment_size 和 number_of_fragments

---

五、综合性能调优 checklist ✅

项目	是否完成	说明
分片大小	✅	控制在 20~50GB
主分片数	✅	根据未来数据量预估
refresh_interval	✅	写密集设为 30s
translog.durability	✅	高吞吐设为 async
批量写入	✅	使用 bulk，批量 1000~5000
查询分页	✅	避免 from > 10000，用 search_after
filter 替代 must	✅	提升缓存命中率
监控	✅	分片大小、刷新延迟、bulk 拒绝数

---

六、监控与告警建议

关键指标（Prometheus + Grafana）

# 刷新延迟
elasticsearch_indices_refresh_time_seconds

# bulk 写入拒绝
rate(elasticsearch_thread_pool_write_rejected[5m])

# 查询延迟
histogram_quantile(0.95, sum(rate(elasticsearch_indices_search_query_time_millis_bucket[5m])) by (le))

# 分片大小
elasticsearch_indices_store_size_bytes

告警规则

• bulk rejected > 0
• refresh_interval > 1s 且写入延迟高
• 分片大小 > 50GB