分片与副本怎么起作用
分布式向量库用分片（shard）分摊数据与检索负载，用副本（replica）提供并发与容灾：分片键选择影响过滤效率，副本数影响成本与一致性体验。扩容不是简单加机器——分片数变化会带来数据再平衡与查询扇出增加，检索延迟可能先升后降，需要在扩容前后都做压测对比。
基本信息
| 分片作用 | 把数据与检索负载分散到多个节点 |
|---|---|
| 副本作用 | 提高并发承载与容灾能力，同时增加存储成本 |
| 扩容方式 | 增加节点后触发再平衡，把部分分片迁到新节点 |
| 关键副作用 | 查询扇出随分片数上升，单个请求要等更多分片返回 |
典型使用场景
- 容量不足：单节点内存装不下时按分片拆分数据
- 并发瓶颈：查询并发高时增加查询侧副本分摊压力
- 写入吞吐不足：写入量大时先扩容数据节点与消息通道
- 库表隔离：给大客户单独分配分片，避免互相影响
- 容灾演练：验证副本故障时服务是否仍可用
Milvus 指定分片数
Milvus 指定分片数
client.create_collection(
collection_name="kb_big",
schema=schema,
num_shards=4, # 按数据量与并发规划，过多会增加扇出
consistency_level="Bounded",
)
# 分片数在建集合时确定，事后调整通常要重建集合
扩容思路
扩容思路
查询并发高 → 增加查询侧副本与节点
写入吞吐高 → 关注数据节点与消息队列扩容
容量不足 → 增加分片并触发再平衡，按官方文档操作
# 每次扩容后都要重跑压测与检索评测，确认延迟与召回都达标
维度与手段
| 瓶颈表现 | 优先手段 | 代价 |
|---|---|---|
| 内存不足 | 增加分片或节点 | 扇出增加，协调开销上升 |
| 查询延迟高 | 增加查询副本 | 成本上升，缓存可能重复 |
| 写入延迟高 | 扩容数据节点与队列 | 运维复杂度提高 |
| 单点故障风险 | 配置副本与故障转移 | 存储成本成倍增加 |
分片过多会增加检索扇出与协调开销；先做好容量与延迟规划再定分片数，比事后反复调整省事。
扩容属于高风险操作：再平衡期间可能出现查询变慢或部分数据暂不可读，安排在低峰期并准备好回滚方案，扩容后核对各分片数据量是否均衡。