十倍成本优化，Milvus 2.5到2.6升级官方手把手教程
不久前，Milvus 2.6 正式发布。
在该版本中，我们推出了多项备受期待的架构优化与新功能：
在架构层面，Milvus 2.6 大幅简化系统架构，整合多个核心组件 —— 例如将原有的 Coordinator 组件（含 RootCoord、QueryCoord、DataCoord）统一整合为 MixCoord，并将 IndexNode 与 DataNode 合并为单一组件。这些调整不仅降低了系统复杂度，更显著提升了系统的可维护性与横向扩展性。
此外，Milvus 2.6 新增多项实用功能，包括支持动态添加字段（Add Field）、地理空间（Geometry）与时间戳（TimestampTz）数据类型，以及 Structured List 等特性。这些新功能进一步拓宽了 Milvus 的应用边界，为开发者与数据科学家提供了更灵活的技术支撑。
伴随这些架构优化与新功能的落地，后台许多用户都私信我们，表示希望体验到 2.6 带来的提升。并希望得到官方指导的Milvus平滑版本升级。因此，本文将详细介绍如何顺利完成从 Milvus 2.5 到 2.6 的升级，并确保数据和服务的稳定性。
01 Milvus2.6能力概览
（1）降本提效
RaBitQ 量化技术：主索引 1bit 量化压缩至原内存 1/32，叠加 SQ8 精排后整体内存占比仅 28%，QPS 提升 4 倍，召回率保持 95% 左右，兼顾成本与精度。
Sparse-BM25 性能暴涨：比 ElasticSearch 检索速度快 3-4 倍（部分数据集达 7 倍），索引体积压缩至原数据 1/3，内存与存储占用大幅降低。
新增SON Path与JSON shredding Index：支持对动态 JSON 字段特定路径创建索引，先过滤再加速，过滤搜索延迟从平均 140ms（P99 480ms）降至 1.5ms（P99 10ms），适配复杂元数据查询。
新增 Int8 、Geometry 、 Struct Array 等多种类型数据的向量存储。其中，int8适配高性价比模型推理服务。 Geometry 类型支持存储和查询如 POINT、LINESTRING 或 POLYGON 等复杂的空间形状来进行地理信息检索，适用于地理围栏、路由导航和地图类应用。Struct Array 支持更自然地为多层嵌套和属性繁多的数据建模，简化 Schema 设计，提升元数据丰富的 AI 工作负载的查询能力。
新增部分Upsert能力， 无需重写整条记录即可刷新指定字段的值。
(2)搜索与功能增强
文本处理升级：新增 Lindera/ICU 分词器（支持日韩及多语言），Jieba 分词支持自定义词表，新增 Run Analyzer 语法可观测分词配置，并新增多语言 analyzer支持。
精准匹配能力：新增 Phrase Match 短语词序匹配，支持
slop参数调整词序宽容度，适配法律文档、智能问答等高精度场景。还支持了 NGRAM Index，加速对VARCHAR字段或JSON字段内特定 JSON 路径的LIKE查询。动态排序功能：引入 Decay Function 时间衰减重排，支持指数 / 线性 / 高斯衰减，提升搜索结果时效性。同时引入boost reranker，Milvus 会使用该功能中的可选过滤条件，在搜索结果候选项中查找匹配项，并结合权重给出得分，完成最终排序。
模型集成简化：支持 OpenAI、Hugging Face 等第三方模型集成，插入 / 查询时自动完成文本向量化，无需手动生成向量。
支持新增标量字段，支持不停机添加 Collection 字段，无须重建 Schema 和 Collection 即可即时在 Collection 中添加新字段
新增Minhash能力，帮助用户基于海量文档，高效识别近似重复内容
(3)架构优化：稳固扩展基石
冷热分层存储（Tiered Storage）：热数据存 SSD、冷数据下沉至对象存储，支持延迟加载 / 部分加载，资源使用减半，集合加载速度显著提升。
实时流处理（Streaming Service）：新增 Streaming Node，对接 Kafka/Pulsar 等消息队列，支持实时数据接入、即时索引与查询，写入吞吐超传统消息队列，故障恢复更快。
支持 100k Collection，满足海量租户与业务隔离需求；升级 Woodpecker 云原生日志系统（Zero-disk WAL）、Storage v2（优化 IOPS 与内存使用）、Coord Merge（提升集群稳定性）。
更多更新详情，可以参考https://milvus.io/docs/zh/release_notes.md
02 Milvus 2.5到2.6组件变化
首先通过2.5和2.6两个版本的架构图来为大家分析下功能组件的变化：
640-2.png
640.png
640-1.png
在2.5版本中，Worker Nodes流批处理耦合，Query Node既有增量又有历史数据的检索，Data Node既有增量数据的落盘(Flush)又有历史数据的的压缩(Compaction)，批处理能力池化难，分散在不同分布式角色中的两个流处理状态对齐有延迟。
2.6 版本将流式数据处理单独抽象出 StreamingNode 组件，专门负责流式数据的消费、写入和处理，而 DataNode 和 QueryNode 则专注于批式数据的处理。新增的2.6 Streaming Node取代了2.5 Data Node消费数据落盘到对象存储，2.5 Query Node做增量数据检索，和2.5 Proxy往流里写入数据的功能。
流批分离，合并分散角色。
新增Streaming Node，合并Coordinators为Mixcoord，Index Node和Data Node合并为Data Node。
03 2.5到2.6升级顺序
为了保障系统在升级过程中尽量保持可用状态，需要遵循以下升级顺序：
提前拉起Streaming Node，新的 Delegator（Querynode中处理流式数据的节点）要放到2.6 Streaming Node。
升级Mixcoord，Coordinator内部需要通过识别Worker Nodes版本来处理分布式跨版本不兼容的问题。
升级Query Node，因为QueryNode本身升级比较慢，2.5 Data Node/Index Node在此时可以帮助在升级期间负责Flush/Index等，降低QueryNode侧的查询压力。
升级Data Node。注意：2.5 DataNode下线后，Flush会没法完成，Growing Segments数据可能持续上涨，直到所有节点升级到2.6。
升级Proxy。注意：新2.6 Proxy节点上的写操作会不可用，直到所有节点升级到2.6。
下掉Index Node。
拉起Streaming Node -> 升级Mixcoord -> 升级Query Node -> 升级 Data Node -> 升级Proxy -> 下掉Index Node。
升级完DataNode，到升级完Proxy期间，Flush操作不可用。
第一个Proxy节点升级后，到升级完Proxy期间，部分写操作不可用。
如果从2.5.x直接升级到发布的2.6.6版本，由于DDL框架的修改，升级流程中DDL操作不可用。
04Milvus-Operator 升级控制
（1）Milvus-Operator 介绍
仓库：https://github.com/zilliztech/milvus-operator
提供了一种用于以可扩展和高可用的方式向目标 Kubernetes 集群部署和管理完整的 Milvus 服务栈。
Milvus服务栈包括 Milvus 组件及其相关依赖项(如 etcd、pulsar 和 minio)。
Milvus Operator 定义了一个 Milvus 自定义资源，并基于K8s Operator模式实现控制循环，持续监控实际状态与期望状态的差异，并自动进行协调。
（2）Milvus CR 例子
apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
name: my-milvus-mansion
namespace: dev
spec:
mode: cluster # cluster or standalone
# Milvus Components
components:
image: milvusdb/milvus:v2.6.5
imageUpdateMode: rollingUpgrade
proxy:
replicas: 1
mixCoord:
replicas: 1
dataNode:
replicas: 1
queryNode:
replicas: 2
resources:
requests:
cpu: "2"
memory: "8Gi"
# Dependencies, including etcd, storage and message stream
dependencies:
etcd:
inCluster:
values:
replicaCount: 3
storage:
type: MinIO
inCluster:
values:
mode: distributed
msgStreamType: pulsar
pulsar:
inCluster:
values:
bookkeeper:
replicas: 3
# Milvus configs
config:
dataCoord:
enableActiveStandby: true
（3）2.5滚动升级到2.6场景的处理
Milvus-Operator对Cluster模式组件升级做了如下适配：
根据Milvus镜像版本识别组件组成和依赖可用性：
通过判断
spec.components.image的tag，判断是否是2.6版本。或者通过填入
spec.components.version主动告知版本。
识别2.5到2.6升级场景：比对
status.currentImage/status.currentVersion，和spec.components.image/(status.currentVersion)判断是否为2.5到2.6的升级场景。对2.5到2.6升级场景，如果为滚动升级模式(
spec.components.imageUpdateMode: rollingUpgrade，也是默认模式)，会依次拉起Streaming Node -> 升级Mixcoord -> 升级Query Node -> 升级 Data Node -> 升级Proxy -> 下掉Index Node。合并Coords场景的处理：Milvus-Operator如果识别到有
spec.Components.MixCoord有配置，会在Mixcoord起来之后，把其他Coords都下掉。
（4）2.5到2.6升级步骤
升级Milvus-Operator到最新版本（下面以本文写作时最新的1.3.3为例）。
# Option 1: Using Helm helm upgrade --install milvus-operator \ -n milvus-operator --create-namespace \ https://github.com/zilliztech/milvus-operator/releases/download/v1.3.3/milvus-operator-1.3.3.tgz # Option 2: Using kubectl & raw manifests kubectl apply -f https://raw.githubusercontent.com/zilliztech/milvus-operator/v1.3.3/deploy/manifests/deployment.yaml合并Coords，跳过如果已是mixcoord部署了。
kubectl patch milvus my-release -n demo-operator --type=merge -p ' { "spec": { "components": { "mixCoord": { "replicas": 1 } } } }'确保升级到2.5.16 （或更高的2.5版本），跳过如果已是2.5.16以上版本。
kubectl patch milvus my-release -n demo-operator --type=merge -p ' { "spec": { "components": { "image": "milvusdb/milvus:v2.5.22" } } }' # wait till updated kubectl wait milvus my-release -n demo-operator --for=condition=milvusupdated --timeout=1h升级到2.6。
kubectl patch milvus my-release -n demo-operator --type=merge -p ' { "spec": { "components": { "image": "milvusdb/milvus:v2.6.5" } } }' # wait till updated kubectl wait milvus my-release -n demo-operator --for=condition=milvusupdated --timeout=1h
05Milvus-Helm升级控制
在Helm里，各Deployment均并发执行，没有顺序关系，无法进行严格的滚动升级，如果是在生产环境中部署Milvus，优先推荐使用 Operator。
2.5到2.6升级步骤
软件要求：Helm version >= 3.14.0，Kubernetes version >= 1.20.0
- 升级Helm Chart到最新版本（下面以本文写作时最新的5.0.7为例）。
helm repo add zilliztech https://zilliztech.github.io/milvus-helm
helm repo update
- 如果使用的是多个Coords，确保升级到2.5.16(或以上的2.5版本）并enable
mixCoordinator。
helm upgrade -i my-release zilliztech/milvus \
--namespace=helm-demo \
--set image.all.tag="v2.5.22" \
--set mixCoordinator.enabled=true \
--set rootCoordinator.enabled=false \
--set indexCoordinator.enabled=false \
--set queryCoordinator.enabled=false \
--set dataCoordinator.enabled=false \
--set streaming.enabled=false \
--set indexNode.enabled=true \
--reset-then-reuse-values \
--version=5.0.7 \
--wait --timeout 1h
- 升级到2.6。
helm upgrade my-release zilliztech/milvus \
--namespace=helm-demo \
--set image.all.tag="v2.6.5" \
--set streaming.enabled=true \
--set indexNode.enabled=false \
--reset-then-reuse-values \
--version=5.0.7 \
--wait --timeout 1h
06 常见问题
Q1：Milvus-Helm和Milvus-Operator的对比？
- 推荐在生产上用Milvus-Operator，对比请见https://github.com/zilliztech/milvus-operator?tab=readme-ov-file#milvus-operator-vs-helm
Q2：Message Queue的选择？
standalone：成本敏感用rocksmq。
cluster：pulsar支持更多租户，可以更大规模实例共用，水平扩缩能力强；Kafka部署维护更成熟，各大云都提供了SaaS方案。
2.6 新推出的Woodpecker: 没有额外Message Queue依赖，成本低，维护简单。目前支持部署的是woodpecker嵌入模式，较轻量。2.6 standalone推荐使用woodpecker；2.6 上生产的cluster模式建议使用待发布的woodpecker集群模式。
Q3: 升级过程中支持MQ的切换吗？
- 目前不支持切换MQ，后续版本会实现Pulsar，Kafka，Woodpecker和RocksMQ之间的切换的管理API以支持切换MQ。
Q4：2.6限流配置是否要更改？
- 不需要，原限流配置对StreamingNode也生效。
Q5：Mixcoord合并后，监控上的role有变更吗？配置项有变更吗？
- 监控role没有变更(rootcoord，querycoord, datacoord)；原有配置项不变，同时新增mixCoord.enableActiveStandby，会fallback到rootcoord.enableActiveStandby。
Q7：Streaming Node推荐的资源配置？
- 如果少量实时写入或边写边查询的需求，Streaming Node配置可以较小，比如2C 8G；反之和QueryNode同等配置较好。
Q8: Docker Compose 单机升级？
- 修改docker-compose.yaml中Milvus的镜像tag即可，详见：https://milvus.io/docs/upgrade_milvus_standalone-docker.md
07参考文档
https://milvus.io/docs/upgrade_milvus_cluster-operator.md
https://milvus.io/docs/upgrade_milvus_standalone-operator.md
https://milvus.io/docs/upgrade_milvus_cluster-helm.md
https://milvus.io/docs/upgrade_milvus_standalone-helm.md
忆卿
