十倍成本优化，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两个版本的架构图来为大家分析下功能组件的变化：

在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升级顺序

为了保障系统在升级过程中尽量保持可用状态，需要遵循以下升级顺序：

1. 提前拉起Streaming Node，新的 Delegator（Querynode中处理流式数据的节点）要放到2.6 Streaming Node。
2. 升级Mixcoord，Coordinator内部需要通过识别Worker Nodes版本来处理分布式跨版本不兼容的问题。
3. 升级Query Node，因为QueryNode本身升级比较慢，2.5 Data Node/Index Node在此时可以帮助在升级期间负责Flush/Index等，降低QueryNode侧的查询压力。
4. 升级Data Node。注意：2.5 DataNode下线后，Flush会没法完成，Growing Segments数据可能持续上涨，直到所有节点升级到2.6。
5. 升级Proxy。注意：新2.6 Proxy节点上的写操作会不可用，直到所有节点升级到2.6。
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操作不可用。

04

Milvus-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: tru

（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升级步骤

a.升级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

（4）2.5到2.6升级步骤

a.升级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

b.合并Coords，跳过如果已是mixcoord部署了。

kubectl patch milvus my-release -n demo-operator --type=merge -p '
{
  "spec": {
    "components": {
      "mixCoord": {
        "replicas": 1
      }
    }
  }
}

c.确保升级到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
d.升级到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

05

Milvus-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

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

作者介绍

Zilliz DevOps Engineer 忆卿

文章来自于微信公众号 “Zilliz”，作者 “Zilliz”