Миграция самоуправляемого Milvus в Zilliz Cloud для снижения задержки более чем на 99%
Изначально опубликовано на simonhearne.com и перепубликовано с разрешения.
Итак, вы создали приложение, использующее Milvus в качестве векторной базы данных, с помощью Standalone или Distributed. Вы достигли момента, когда приложение работает, клиенты им пользуются, а объем данных растет. В какой-то момент управление векторной базой данных начинает отнимать всё больше времени, сбои pod вызывают нестабильность сервиса, на сервере заканчивается RAM, или etcd становится болезненным узким местом.
На этом этапе вы, вероятно, рассматриваете управляемый сервис, чтобы снять с себя операционную нагрузку. Хорошая новость в том, что миграция с Milvus на Zilliz Cloud проста, а различные варианты хорошо задокументированы.
В моем случае я создал простое Wikipedia RAG-приложение: 50 млн эмбеддингов с использованием многоязычной модели Cohere Embed v3 размерностью 1 024 (охватывающее весь англоязычный корпус Wikipedia). Сначала я разместил его на своем ноутбуке с использованием Milvus Standalone, но контейнер был нестабилен, а перезапуски занимали ~20 минут — не идеально, когда хочется показать демо!
Производительность запросов также страдала из-за частого paging (на моем ноутбуке недостаточно памяти, поэтому я включил mmap). Ниже — короткое видео, демонстрирующее приложение в действии:
Время выполнения запросов в три секунды — не лучший результат, поэтому, не имея бюджета на новый ноутбук, я запланировал миграцию на управляемый Milvus в Zilliz Cloud. Ниже приведен пошаговый процесс, которому я следовал — доступно несколько методов, но я выбрал backup/restore ради простоты.
1. Создайте резервную копию
Zilliz предоставляет утилиту milvus-backup, и установить ее так же просто, как выполнить brew install milvus-backup
Затем нужно создать файл конфигурации (milvus-backup по умолчанию ищет backup.yaml в текущем рабочем каталоге). Это минимальный пример для создания резервной копии из Standalone, запущенного локально в Docker (полные yaml options см. на 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-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
2. Создайте целевой экземпляр в Zilliz Cloud
Сначала убедитесь, что у вас есть учетная запись Zilliz Cloud — затем создайте экземпляр, соответствующий минимальным требованиям вашего локального развертывания. Для моих эмбеддингов 50 млн x 1 024-D на Tiered-Storage публичный калькулятор оценил, что мне требуется 2 Query CU:
Поэтому я перешел в cloud console, нажал "+ Cluster" и использовал следующие настройки:
Пока он создается, вы можете получить/сгенерировать API-ключ, который понадобится нам на следующем шаге:
И запишите ID кластера нового экземпляра:
3. Миграция в Zilliz
Обновите ваш backup.yaml, добавив только что сгенерированный/полученный облачный ключ:
cloud:
address: https://api.cloud.zilliz.com
apikey: <your-api-key>
Затем, наконец, нам нужно просто выполнить одну команду миграции, передав имя резервной копии и ID целевого кластера в качестве аргументов:
$ milvus-backup migrate -n wiki_backup -c <your-cluster-id>
В моем случае загрузка файла резервной копии размером ~120 ГБ в Volume на Zilliz Cloud заняла несколько часов, а затем создание целевого кластера из Volume заняло около часа. Вы можете отслеживать статус миграции в консоли Zilliz Cloud в разделе Jobs:
После завершения миграции обязательно загрузите коллекцию в кластер!
4. Проверка
Теперь вы можете просто обновить приложение, чтобы использовать новый endpoint кластера и учетные данные.
Мы наблюдаем улучшение производительности по сравнению с Milvus Standalone — 25 мс против 3 112 мс — это более чем 99%-ное снижение задержки!. Это частично связано с увеличенными вычислительными ресурсами, выделенными в облачном сервисе, а также с проприетарным индексным движком в Zilliz Cloud — Cardinal, — который позволяет выполнять запросы в 10 раз быстрее по сравнению с Milvus OSS.
Выигрыш в производительности огромен, но, что еще лучше, мне больше не нужно беспокоиться об остановке контейнера, и я могу освободить ~20 ГБ ОЗУ на своем ноутбуке!
5. Другие соображения
- Если ваше приложение не работает 24x7, ваша векторная база данных тоже не обязана. Приостанавливайте неактивные кластеры, чтобы снизить стоимость вычислений до нуля, когда они не используются.
- Tiered-Storage — отличный тип кластера для низких требований (<10 QPS), но есть и другие варианты, и вы можете переносить данные между ними:
- On-Demand — использует вычислительные ресурсы только при выполнении запросов. Это может снизить стоимость на 99%, в зависимости от частоты запросов, ценой более высокой задержки холодного старта.
- Capacity-Optimized — обеспечивает меньшую плотность данных по сравнению с Tiered-Storage, но достигает в 10 раз большей пропускной способности и в 2–5 раз более быстрых запросов. Это увеличило бы стоимость вычислений в моем примере примерно на 60%.
- Performance-Optimized — обеспечивает еще большую пропускную способность (>1 000 QPS на реплику) и производительность (в 10–100 раз быстрее) ценой дальнейшего снижения плотности данных.
- Zilliz Cloud поддерживает подключение внешних томов из Google Cloud Storage, Amazon S3, Azure Blob Storage и т. д. Поэтому более чистым подходом было бы загрузить резервную копию напрямую в облачное хранилище и восстановить ее оттуда.
- Если создание/восстановление резервной копии по какой-либо причине невозможно, а развертывание Milvus можно сделать публично доступным, вы можете использовать функцию Migrate from Milvus Endpoint в Zilliz Cloud.
- Все, что мы выполняли в Zilliz Cloud, можно управлять через API и/или Terraform, если click-ops не является вашей предпочтительной методологией.
Читать далее
Zilliz Skills Breakdown: How AI Agents Master Vector Databases
Zilliz's Milvus Skill (pymilvus, 7 files) and Zilliz Cloud Skill (zilliz-cli, 14 modules) bring vector-DB dev and ops into one Claude Code session.
How to Choose the Best Embedding Model for RAG in 2026: 10 Models Benchmarked
We benchmarked 10 embedding models on cross-modal, cross-lingual, long-document, and dimension compression tasks. See which one fits your RAG pipeline.
Our Journey to 35K+ GitHub Stars: The Real Story of Building Milvus from Scratch
Join us in celebrating Milvus, the vector database that hit 35.5K stars on GitHub. Discover our story and how we’re making AI solutions easier for developers.