# Elasticsearch 索引架构实战：从分片到段，避开分片税

```text
旧方案：单索引多分片，盲目扩容
冲突：查询变慢，Heap 飙升，文件句柄耗尽
后果：集群不稳定，协调成本剧增
```

很多团队把 Elasticsearch 当黑盒，数据一多就加 Shard，结果查询反而更慢。

我是老李，过去半年在深圳一家电商公司负责搜索服务，亲眼见过一个索引从 5 个 Shard 扩到 40 个 Shard 后，P99 延迟从 200ms 涨到 1.8s。

为什么增加 Shard 有时不仅不会让查询更快，反而增加 Heap、文件句柄和协调成本？

是优先控制单 Shard 大小，还是优先增加 Shard 数量来分摊写入压力？

如果选错，会不会导致集群在高峰期频繁 Full GC，甚至节点失联？

# 01、故事

```text
凌晨 02:17→深圳南山机房→商品搜索索引扩容→分片数从 5 改到 40
```

那天凌晨两点十七分，我在南山机房的工位上，任务是给商品搜索索引做一次扩容，因为运营说大促前数据量要翻倍。

我打开 Kibana 的 Dev Tools，把索引模板里的 number_of_shards 从 5 改成 40，然后重建索引。

数据灌到一半，监控屏上三个数据节点的 Heap 使用率同时冲破 85%，查询线程池开始堆积。

我赶紧停掉写入，但已经晚了，几个慢查询把协调节点拖住，搜索接口开始超时。

> 凌晨两点改分片，
> 四十个分片压垮三节点。
> 堆内存冲上八十五，
> 搜索超时告警连成线。

# 02、问题

```text
需求变化：数据量翻倍→分片数从 5 扩到 40
冲突：查询变慢，Heap 飙升，文件句柄耗尽
后果：协调成本剧增，集群不稳定
```

表面看是数据量增长，实际是分片数从 5 变成 40，每个查询要协调的分片数翻了 8 倍。

每个 Shard 都是一个 Lucene Index 实例，占用独立 Heap、文件句柄和线程资源，40 个 Shard 意味着 40 份固定成本。

可验证的验收标准是：同样 100 并发查询，P99 延迟不超过 500ms，Heap 使用率低于 75%，文件句柄数低于节点上限的 60%。

> 数据翻倍本寻常，
> 分片八倍惹祸殃。
> 固定成本四十份，
> 协调开销把命伤。

# 03、原理

```text
Index → Primary Shard → Replica Shard → Segment → Lucene Index
```

一个 Index 在创建时被拆成多个 Primary Shard，每个 Primary Shard 决定数据分区，通过 Routing 把文档哈希到对应分片。

Replica Shard 是 Primary 的副本，提供查询能力和故障冗余，但不承担写入主路径。

每个 Shard 内部是一个 Lucene Index，由多个 Segment 组成，Segment 是不可变的倒排索引文件。

反直觉判断：Shard 数量越多，单次查询的并行度越高，但协调节点需要合并的结果集也越大，CPU 和内存开销非线性增长。

> 索引拆成主分片，
> 路由哈希定归属。
> 副本只读不主写，
> 段是不可变倒排。

# 04、架构

```text
输入：文档写入请求、查询请求
本模块：Coordinating Node → Primary/Replica Shards → Segments
输出：查询结果合并、写入确认
边界：单 Shard 建议 10-50GB，单节点 Shard 数受 Heap 限制
```

Coordinating Node 接收查询，广播到所有相关 Shard，每个 Shard 在本地 Lucene Index 上执行查询，返回 TopN 给协调节点做全局排序。

写入路径只走 Primary Shard，Primary 写完同步转发给 Replica，等副本确认后才返回成功。

收益是水平扩展读写能力，代价是每个 Shard 都有固定内存和文件句柄开销，适用条件是单 Shard 大小在 10 到 50GB 之间。

> 协调节点广播查询，
> 各分片本地取前 N。
> 全局归并再返回，
> 固定成本要算清。

# 05、第一版实战

```text
环境：Elasticsearch 8.11.3，3 数据节点，每节点 16GB Heap
配置：商品索引 5 Primary Shards，1 Replica
代码：索引创建、文档写入、查询验证
启动：docker compose 启动 3 节点集群
验证：_cat/shards 观察分片分布，查询延迟基线
V1：5 分片，P99 200ms，Heap 60%
```

环境是 Elasticsearch 8.11.3，三个数据节点，每个节点 16GB Heap，用 Docker Compose 启动。

先创建商品索引，5 个 Primary Shard，1 个 Replica，总共 10 个 Shard。

```bash
curl -X PUT "localhost:9200/products_v1" -H 'Content-Type: application/json' -d'
{
  "settings": {
    "number_of_shards": 5,
    "number_of_replicas": 1
  },
  "mappings": {
    "properties": {
      "title": { "type": "text" },
      "price": { "type": "double" },
      "category": { "type": "keyword" },
      "created_at": { "type": "date" }
    }
  }
}'
```

写入 500 万条商品文档，用 bulk API 分批灌入。

```bash
curl -X POST "localhost:9200/_bulk" -H 'Content-Type: application/x-ndjson' --data-binary @products_bulk.json
```

查看分片分布，确认 10 个 Shard 均匀分布在 3 个节点上。

```bash
curl -s "localhost:9200/_cat/shards/products_v1?v&h=index,shard,prirep,state,node,store"
```

```text
示例输出：
index        shard prirep state   node     store
products_v1  0     p      STARTED node-1   8.2gb
products_v1  0     r      STARTED node-2   8.2gb
products_v1  1     p      STARTED node-2   8.1gb
products_v1  1     r      STARTED node-3   8.1gb
products_v1  2     p      STARTED node-3   8.3gb
products_v1  2     r      STARTED node-1   8.3gb
products_v1  3     p      STARTED node-1   8.0gb
products_v1  3     r      STARTED node-2   8.0gb
products_v1  4     p      STARTED node-3   8.2gb
products_v1  4     r      STARTED node-1   8.2gb
```

执行查询验证，按分类过滤并按价格排序，取前 20 条。

```bash
curl -s "localhost:9200/products_v1/_search" -H 'Content-Type: application/json' -d'
{
  "query": { "term": { "category": "electronics" } },
  "sort": [ { "price": "desc" } ],
  "size": 20
}'
```

```text
示例输出：
{
  "took": 187,
  "hits": { "total": { "value": 12430 }, "max_score": null },
  "_shards": { "total": 5, "successful": 5, "skipped": 0, "failed": 0 }
}
```

成功标准：查询 took 低于 200ms，_shards.total 等于 5，所有分片 successful。

> 五主五副十份片，
> 三节点上均匀摊。
> 查询两百毫秒内，
> 基线稳定心不慌。

# 06、排查

```text
诊断树：
查询变慢
├── 怀疑：分片数过多
│   ├── 检查：_cat/shards 统计分片总数
│   ├── 证据：40 个 Shard 分布在 3 节点，每节点 13+ Shard
│   └── 根因：协调节点合并 40 个分片结果，CPU 和内存开销过大
├── 怀疑：Heap 压力
│   ├── 检查：_cat/nodes?v&h=name,heap.percent,ram.percent
│   ├── 证据：heap.percent 85%+，频繁 Young GC
│   └── 根因：每个 Shard 的 Segment 缓存和查询缓存叠加
└── 怀疑：文件句柄耗尽
    ├── 检查：节点上 lsof -p <pid> | wc -l
    ├── 证据：单节点文件句柄数超过 60000
    └── 根因：每个 Segment 打开多个文件，Shard 越多句柄越多
```

第一个问题是查询变慢，我怀疑是分片数过多，用 _cat/shards 统计发现 40 个 Shard 分布在 3 个节点上，每节点超过 13 个 Shard。

协调节点每次查询要广播到 40 个 Shard，合并结果时 CPU 和内存开销远超 5 个 Shard 的场景。

第二个问题是 Heap 压力，用 _cat/nodes 查看节点状态。

```bash
curl -s "localhost:9200/_cat/nodes?v&h=name,heap.percent,ram.percent,cpu"
```

```text
示例输出：
name    heap.percent ram.percent cpu
node-1  87          92          78
node-2  85          90          75
node-3  88          93          80
```

每个 Shard 的 Segment 缓存和查询缓存叠加，导致 Heap 使用率冲到 85% 以上，频繁 Young GC。

第三个问题是文件句柄，登录节点执行 lsof 统计。

```bash
lsof -p $(pgrep -f elasticsearch) | wc -l
```

```text
示例输出：
62341
```

每个 Segment 打开多个文件，Shard 越多句柄越多，单节点文件句柄数超过 60000，接近系统上限。

**错误尝试：** 我一开始以为是查询语句没优化，加了 constant_keyword 和 filter 缓存，结果延迟只降了 50ms，Heap 依然高企。

> 四十片查一次，
> 协调节点累成痴。
> 堆高句柄都耗尽，
> 优化查询也难支。

# 07、优化

```text
V1：5 分片，P99 200ms，Heap 60%
证据：40 分片，P99 1.8s，Heap 87%，句柄 62000+
V2：回到 5 分片，单分片 40GB，P99 210ms，Heap 62%
```

核心改动是把分片数从 40 降回 5，让单 Shard 大小控制在 40GB 左右，而不是追求分片多。

重建索引，设置 5 个 Primary Shard，1 个 Replica，用 reindex 从旧索引迁移数据。

```bash
curl -X PUT "localhost:9200/products_v2" -H 'Content-Type: application/json' -d'
{
  "settings": {
    "number_of_shards": 5,
    "number_of_replicas": 1,
    "refresh_interval": "5s"
  },
  "mappings": {
    "properties": {
      "title": { "type": "text" },
      "price": { "type": "double" },
      "category": { "type": "keyword" },
      "created_at": { "type": "date" }
    }
  }
}'
```

```bash
curl -X POST "localhost:9200/_reindex" -H 'Content-Type: application/json' -d'
{
  "source": { "index": "products_v1" },
  "dest": { "index": "products_v2" }
}'
```

同时把 refresh_interval 从默认 1s 调到 5s，减少 Segment 生成频率，降低 Merge 压力。

> 四十片回五片，
> 单分片四十吉。
> 刷新间隔调五秒，
> 堆和句柄都松气。

# 08、演进

```text
V2：5 分片，单分片 40GB，P99 210ms，Heap 62%
能力：查询延迟稳定，Heap 余量充足，句柄数下降 60%
遗留：单分片 40GB 接近上限，未来数据增长需滚动索引
```

用 V1 同一组查询请求验证，P99 从 1.8s 降到 210ms，Heap 从 87% 降到 62%，句柄数从 62000 降到 25000 左右。

收益是协调成本大幅下降，每个查询只广播 5 个 Shard，合并结果集小，CPU 和内存开销可控。

代价是单分片 40GB 接近建议上限，如果数据继续增长，需要引入滚动索引或 ILM 来拆分。

遗留问题是当前方案没有处理 Hot Shard，如果某个分类数据量特别大，可能导致单个 Shard 过热。

> 五片查询二百一，
> 堆余充足句柄低。
> 单片四十近上限，
> 滚动索引待补齐。

# 09、洞见

```text
从现象到判断：分片数增加反而变慢，说明固定成本主导了性能
```

## 分片是扩展单位，同时也是固定成本单位
```text
每增加一个 Shard，就多一份 Lucene Index 的 Heap、句柄和线程开销
```

很多人把 Shard 当成免费的并行度，实际上每个 Shard 都有独立的 Lucene Index 实例，占用固定内存和文件句柄。

当分片数从 5 增加到 40，固定成本翻了 8 倍，而查询并行度的收益被协调合并的开销抵消。

## 反直觉判断：分片越多，查询不一定越快
```text
协调节点合并 N 个分片结果的开销是 O(N log N)，N 越大越不划算
```

查询延迟由最慢的分片决定，分片越多，出现慢分片的概率越高，协调节点还要做全局排序。

在 3 节点集群里，40 个 Shard 意味着每个节点要处理 13 个 Shard 的查询，CPU 争抢严重。

## 反直觉判断：单分片大小比分片数量更重要
```text
10-50GB 的单分片大小是经验值，超出后 Merge 和 Recovery 成本剧增
```

单分片太小，固定成本占比高；单分片太大，Segment Merge 和故障恢复时间长。

规划索引时先估算数据总量，再反推分片数，而不是先定分片数再看数据量。

## 搜索集群规划首先要避免分片税
```text
分片税 = 分片数 × 单分片固定成本，规划时先算这笔账
```

分片税是每个查询都要支付的固定开销，包括广播、上下文切换、结果合并。

规划集群时先确定单分片目标大小，再根据数据总量计算分片数，最后验证节点 Heap 和句柄余量。

> 分片本是双刃剑，
> 扩展成本两相兼。
> 固定开销算清楚，
> 莫让查询交税钱。

# 10、系统落地

```text
入口：搜索 API 网关
服务：商品搜索服务
本模块：Elasticsearch 索引架构（5 分片 + 1 副本 + 5s Refresh）
存储：3 数据节点，每节点 16GB Heap
未实现：ILM 滚动索引、Hot Shard 自动拆分
```

原来系统只有一个 products 索引，分片数随意设置，没有容量规划。

本篇增加了基于数据量反推分片数的方法，把索引控制在 5 个 Primary Shard，单分片 40GB。

现在能做什么：查询 P99 稳定在 210ms，Heap 余量充足，句柄数在安全范围内。

下一篇缺什么：ILM 滚动索引和 Hot Shard 检测，应对数据持续增长和热点分片。

官方文档可参考 Elasticsearch 官网的 Size your shards 指南：https://www.elastic.co/guide/en/elasticsearch/referenc

e/current/size-your-shards.html

> 入口网关到搜索，
> 五片索引稳如钟。
> 滚动索引还未建，
> 热点分片待追踪。

# 11、小结

```text
三问三答：
为什么增加 Shard 反而变慢？→ 固定成本叠加，协调合并开销非线性增长
优先控制单 Shard 大小还是增加 Shard 数量？→ 先控制单 Shard 大小在 10-50GB，再反推分片数
选错后果？→ Heap 飙升、句柄耗尽、节点失联，集群不可用
```

增加 Shard 反而变慢，是因为每个 Shard 都有固定 Heap、句柄和线程开销，协调节点合并结果的成本随分片数非线性增长。

应该优先控制单 Shard 大小在 10 到 50GB，根据数据总量反推分片数，而不是盲目增加分片。

选错的后果是 Heap 使用率冲高、文件句柄耗尽、节点失联，最终整个集群不可用。

当前状态：商品索引稳定在 5 分片，P99 210ms，Heap 62%，句柄数安全。

> 三问三答理清楚，
> 分片固定成本高。
> 先定单片再反推，
> 集群稳定不告饶。

# 12、作业

```text
理解→实战→排障→架构判断
```

## 理解题：为什么说 Shard 是扩展单位同时也是固定成本单位？

每个 Shard 内部是一个独立的 Lucene Index 实例，占用独立的 Heap 内存、文件句柄和线程资源。

增加 Shard 可以分摊写入压力、提升查询并行度，但每个 Shard 的固定成本不会消失，反而会叠加。

当分片数过多时，固定成本超过并行收益，查询反而变慢。

## 实战题：创建一个 3 分片 1 副本的索引，写入 100 万条文档，观察 _cat/shards 分布和查询延迟

```bash
curl -X PUT "localhost:9200/homework_idx" -H 'Content-Type: application/json' -d'
{
  "settings": { "number_of_shards": 3, "number_of_replicas": 1 },
  "mappings": { "properties": { "content": { "type": "text" } } }
}'
```

写入 100 万条文档后，用 _cat/shards 确认 6 个 Shard 均匀分布，执行 match_all 查询记录 took 值。

对比 10 分片 1 副本的索引，观察查询延迟和节点 Heap 变化。

## 排障题：查询突然变慢，_cat/nodes 显示 Heap 90%，_cat/shards 显示 60 个 Shard，如何定位和修复？

先确认分片数是否过多，60 个 Shard 在 3 节点上每节点 20 个，固定成本过高。

检查 _cat/shards 看是否有分片分布不均，检查 _cat/nodes 看 Heap 和句柄使用率。

修复方案是重建索引，把分片数降到合理范围，单分片大小控制在 10-50GB，同时调大 refresh_interval。

## 架构判断题：一个日志索引每天写入 200GB，保留 7 天，应该用多少分片？

总数据量 1.4TB，按单分片 40GB 计算，需要 35 个 Primary Shard。

但 35 个分片在 3 节点集群上每节点约 12 个，固定成本偏高。

更好的方案是用 ILM 按天滚动索引，每天一个索引 5 个分片，单分片 40GB，7 天共 35 个分片但分散在不同索引，查询只命中相关索引。

> 理解实战排障题，
> 架构判断要仔细。
> 分片规划先算账，
> 滚动索引解难题。

# 13、升华

```text
工程结论：分片规划是搜索集群稳定的第一道防线
```

有依据的结论是：分片数不是越多越好，单分片大小控制在 10-50GB，根据数据总量反推分片数，才能避免分片税。

本次实战从 40 分片回退到 5 分片，P99 从 1.8s 降到 210ms，Heap 从 87% 降到 62%，证明固定成本主导了小集群的查询性能。

下一篇可以深入 ILM 滚动索引和 Hot Shard 检测，解决数据持续增长和热点分片问题。

> 分片规划第一关，
> 固定成本要算全。
> 单片大小控十到五十，
> 集群稳定保平安。

**系列项目：** 电商搜索服务

**已完成：** 索引架构与分片规划

**本篇：** 从分片到段的层级理解与分片税规避

**下一篇：** ILM 滚动索引与 Hot Shard 治理

很多团队把 Elasticsearch 当黑盒，数据一多就加 Shard，结果查询反而更慢。

《Spring ES实战》第12招 Shard不是越多越好

深入 Elasticsearch 索引架构，从 Shard 到 Segment 逐层拆解，实战观察查询分发与分片成本，避免盲目扩容带来的性能陷阱。

架构师

数据库

开发工具

后端

Elasticsearch分片规划实战：电商搜索索引从5扩至40分片后P99延迟飙升至1.8s，回退至5分片单分片40GB后降至210ms。深入解析分片税机制，论证单分片大小10-50GB优于盲目增加分片数，避免Heap飙升、文件句柄耗尽及节点失联风险，提供可验证的分片优化方案。

2026上云采购 | AI焕新·智启新局

cngw

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

《Spring ES实战》第12招 Shard不是越多越好-腾讯云开发者社区-腾讯云

《Spring ES实战》第12招 Shard不是越多越好

《Spring ES实战》第12招 Shard不是越多越好

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐