如何把自建 Milvus 迁移到托管的 Zilliz Cloud，实现性能翻倍
最近几年，我陆续看到不少开发者和团队分享他们使用 Milvus 构建应用的经历。很多项目一开始只是内部原型，数据量不大、访问频率也不高，一台机器或一个简单的 Standalone 实例就足以支撑。
但随着项目走向生产，用户量和数据量一起飞涨，数据库中的向量数据可能从几百万条增长到几千万甚至更多；原来只需要支持内部测试，现在开始面对更高的并发和更严格的延迟要求；过去偶尔重启一次没有太大影响，进入生产环境后，几分钟的服务抖动都可能影响用户体验。
数据增长带来的也不只是扩容问题。内存开始不够用，会触发 frequent paging ；Pod 故障导致服务不稳定；备份、恢复和版本升级需要专门规划；etcd、对象存储或查询节点中的任何一个环节，都可能逐渐成为新的瓶颈。
到了这个阶段，很多团队都会遇到一个现实问题：是继续投入人力，自建并维护一套更完整的 Milvus 基础设施，还是把数据库交给托管服务？
前一种方式意味着需要有人负责容量规划、故障恢复、监控告警、扩缩容和升级；后一种方式则会增加云服务成本，但可以让团队把更多精力放回应用本身。两种选择背后，本质上是在权衡工程人力、基础设施成本和业务增长速度。
我自己的项目也经历了类似的过程。
之前，我构建了一个简单的 Wikipedia RAG 应用，使用 Cohere Embed v3 multilingual 模型，将完整的英文维基百科语料转换为约 5000 万条 1024 维向量，项目跑在我的个人笔记本上。
但由于容器运行稳定性太差，重启一次约需 20 分钟 ，导致每次重启大约需要 20 分钟。但我可能随时需要去做项目演示，在启动上浪费太多时间会显得不太专业。
另外，由于笔记本内存不足，我还用上了mmap，但这又会导致查询过程中出现frequent paging ，单次查询延迟一度达到约 3 秒。
下面的视频为当时应用的实际运行效果：
当然，我可以购买一台内存更大的电脑，或者继续投入时间优化本地部署。但这不能真正解决后续的备份、扩容、稳定性和运维问题。
也是因此，最终我决定将数据迁移到 Zilliz Cloud，也就是Milvus原厂Zilliz 打造的全托管向量数据库SaaS。Zilliz Cloud 作为 Milvus 官方商业化托管服务，两者核心架构同源，API 等 完全兼容，业务代码基本无需修改。此外，Zilliz Cloud 上专有的搜索引擎 Cardinal，也可以提供十倍于开源Milvus的查询效率。
（Zilliz Cloud 提供了多种迁移方式。为了尽量减少操作步骤，我选择了备份与恢复方案。）
下面是我实际采用的完整迁移步骤。
第一步：使用 milvus-backup 创建本地备份
Zilliz 提供了 milvus-backup 工具，用于备份和恢复 Milvus 数据。通过 Homebrew 安装非常简单：
brew install milvus-backup
安装完成后，需要创建一个配置文件。默认情况下，milvus-backup 会在当前工作目录中查找名为 backup.yaml 的文件。
下面是一个精简配置示例，用于备份在本地 Docker 环境中运行的 Milvus Standalone。完整的 YAML 配置选项可以参考 milvus-backup 项目的官方文档或者GitHub 上的项目文档。
milvus:
address: localhost
port: 19530
user: "root"
password: "Milvus"
tlsMode: 0
etcd:
endpoints: 127.0.0.1:2379
rootPath: "by-dev"
minio:
storageType: "local"
rootPath: "/../milvus_wikipedia/volumes/milvus/data"
backupStorageType: "local"
backupRootPath: "/../milvus-backup-test/backup"
配置完成后，先运行检查命令，确认 Milvus、对象存储和备份目录均可正常访问：
$ milvus-backup check
正常情况下，会看到类似下面的输出：
Milvus version: 2.6.2
Storage:
milvus-storage-type: local
milvus-bucket: a-bucket
milvus-rootpath: /../milvus_wikipedia/volumes/milvus/data
backup-storage-type: local
backup-bucket: a-bucket
backup-rootpath: /../milvus-backup-test/backup
Success!
检查通过后，即可创建备份。备份所需时间取决于数据规模、磁盘性能和存储配置。
$ milvus-backup create -n wiki_backup
第二步：在 Zilliz Cloud 上创建目标实例
首先，需要根据本地数据规模、向量维度、索引类型和查询负载估算，在 Zilliz Cloud 应该准备怎样规模的的目标实例。
对于我的数据集——5000 万条 1024 维向量，我计划使用 Tiered-Storage 集群。根据 Zilliz Cloud 资源计算器的估算，集群至少需要配置 2 个 Query CU：
（以上配置和图中展示的价格，更适合需要高频检索的项目，Zilliz Cloud支持空闲时暂停集群，在此期间，不产生计算资源费用，可以大幅降低非使用时段的成本。对于偶尔需求，也可以选择Serverless模式，进一步降低成本。）
随后，进入 Zilliz Cloud 控制台，单击 “+ Cluster”，并根据计算结果创建目标集群：
在集群创建期间，还需要准备迁移所需的 API Key。
同时，记录新集群的 Cluster ID：
第三步：将数据迁移到 Zilliz Cloud
准备好目标集群后，更新本地的 backup.yaml 文件，加入 Zilliz Cloud 的 API 地址和 API Key：
cloud:
address: https://api.cloud.zilliz.com
apikey: <your-api-key>
请将 <your-api-key> 替换为实际的 Zilliz Cloud API Key。
完成配置后，运行下面的命令启动迁移：
$ milvus-backup migrate -n wiki_backup -c <your-cluster-id>
其中：
-n wiki_backup指定需要迁移的备份名称。-c <your-cluster-id>指定目标 Zilliz Cloud 集群。
在我的迁移过程中，将约 120 GB 的备份文件上传至 Zilliz Cloud 的 Volume 大约花费了几个小时。上传完成后，从 Volume 创建目标集群又花费了约 1 小时。
实际耗时会受到本地上传带宽、数据规模和目标集群配置等因素影响。可以进入 Zilliz Cloud 控制台，在 Jobs 页面查看迁移任务的状态和进度：
迁移完成后，还需要在目标集群中加载集合（Collection）。只有完成加载后，集合才能正常处理查询：
第四步：验证迁移后的查询性能
数据迁移完成后，只需要修改应用中的数据库连接配置，将原来的本地 Milvus 地址和凭证替换为 Zilliz Cloud 集群的访问地址（Endpoint）和认证凭证。
在我的测试中，迁移前后，查询延迟从 3112 毫秒下降到了 25 毫秒，降幅超过 99%。
值得一提的是，这不是个严格控制变量的基准测试。性能提升一部分来自云端更充足的计算资源，另一部分来自 Zilliz Cloud 的索引和查询优化能力，其中包括专有搜索引擎 Cardinal。与开源版 Milvus 相比，Cardinal 的查询速度最高可提升至 10 倍。
而对我自己来说，除了查询性能提升，迁移到云端还解决了本地运行中的稳定性问题，再也不需要担心 Milvus 容器意外停止，也释放了笔记本电脑上约 20 GB 的内存。
选择 Zilliz Cloud 集群类型时还需要考虑什么
完成迁移只是第一步。为了进一步平衡成本、查询性能和资源利用率，还可以根据应用负载选择合适的集群类型和运行策略。
比如，我的项目是用于展示的，并非全天候运行，向量数据库也不需要保持 7×24 小时在线。Zilliz Cloud对于演示环境、开发环境或者只在固定时段使用的应用，支持在空闲时暂停集群。集群暂停后，不再产生计算资源费用，从而降低非使用时段的成本。所以我一开始测算出的成本，在实际中，可能要打个 1 折。
再比如，对于查询量较低（低于 10 QPS ）的应用，可以选择Tiered-Storage 兼顾容量和成本。
Tiered-Storage 之外，Zilliz Cloud 还提供其他集群类型，可以根据延迟、吞吐量和数据密度要求进行选择，具体如下：
- Tiered-Storage ： 适合低至中等查询负载、大规模数据集，可以在数据密度、查询性能和成本之间取得平衡
- On-Demand：仅在实际执行查询时使用计算资源。根据查询频率的不同，计算成本最多可能降低 99%，但相应地会带来更高的冷启动延迟。
- Capacity-Optimized：相比 Tiered-Storage，其数据密度更低，但吞吐量最高可提升 10 倍，查询速度可提升 2～5 倍。以我的示例为例，采用该类型后，计算成本大约会增加 60%。
- Performance-Optimized：可以提供更高的吞吐能力，单副本可支持超过 1000 QPS，查询性能可提升 10～100 倍，但代价是数据密度进一步降低。
以本文的数据集为例，选择 Capacity-Optimized 后，预计计算成本会比 Tiered-Storage 增加约 60%，但可以换取更高的查询吞吐量和更低的延迟。具体配置仍应根据实际数据规模、索引类型、查询参数和并发负载进行测试。
更多迁移方式推荐
存储方面，Zilliz Cloud 支持挂载来自 Google Cloud Storage、Amazon S3 和 Azure Blob Storage 等服务的外部 Volume。因此，在网络和权限条件允许的情况下，可以先将 Milvus 备份上传到云对象存储，再由 Zilliz Cloud 从对象存储中恢复数据。与从本地设备直接上传大型备份相比，这种方式通常更适合生产环境，也更容易实现自动化。
当由于部署环境或存储配置等原因无法创建备份，但现有 Milvus 服务可以通过公网访问时，也可以使用 Zilliz Cloud 提供的 Migrate from Milvus Endpoint 功能。该方式可以直接连接现有 Milvus Endpoint，并将数据迁移到 Zilliz Cloud。
本文中通过 Zilliz Cloud 控制台完成的所有操作，如果团队不希望依赖控制台点选操作，也可以通过 API 或 Terraform 管理集群、凭证和相关云资源，将迁移流程集成到现有的基础设施即代码和自动化运维体系中。
如果你的 Milvus 应用已经进入生产阶段，并且数据库运维开始影响团队开发效率，那么不妨将基础设施交给 Zilliz Cloud 这样的云托管服务，让团队把更多精力重新投入到应用和业务本身。
