Migration de Milvus autogéré vers Zilliz Cloud pour une réduction de la latence de >99 %
Publié à l’origine sur simonhearne.com et republié avec autorisation.
Vous avez donc créé une application utilisant Milvus comme base de données vectorielle, avec Standalone ou Distributed. Vous êtes arrivé à un point où l’application fonctionne, les clients l’utilisent et le volume de données augmente. À un moment donné, la gestion de la base de données vectorielle commence à consommer plus de temps, les défaillances de pods provoquent des à-coups de service, vous manquez de RAM sur le serveur, ou etcd devient un goulot d’étranglement pénible.
À ce stade, vous explorez probablement un service managé pour vous décharger du fardeau opérationnel. La bonne nouvelle, c’est que la migration de Milvus vers Zilliz Cloud est simple, et les différentes options sont bien documentées.
Dans mon cas, j’avais créé une application RAG Wikipédia simple : 50 M d’embeddings utilisant le modèle multilingue Embed v3 de Cohere en 1 024 dimensions (couvrant l’ensemble du corpus Wikipédia en anglais). Au départ, je l’hébergeais sur mon ordinateur portable avec Milvus Standalone, mais le conteneur était instable, et les redémarrages prenaient ~20 minutes — pas idéal quand on veut montrer une démo !
Les performances de requête en souffraient également en raison d’une pagination fréquente (je n’ai pas assez de mémoire sur mon ordinateur portable, j’ai donc activé mmap). Voici une courte vidéo montrant l’application en action :
Des temps de requête de trois secondes, ce n’est pas génial ; donc, sans budget pour un nouvel ordinateur portable, j’ai planifié ma migration vers Milvus managé sur Zilliz Cloud. Voici le processus étape par étape que j’ai suivi — plusieurs méthodes sont disponibles, mais j’ai choisi la sauvegarde/restauration pour sa simplicité.
1. Créer une sauvegarde
Zilliz fournit l’utilitaire milvus-backup, et l’installer est aussi simple que brew install milvus-backup
Vous devez ensuite créer un fichier de configuration (milvus-backup recherche backup.yaml dans le répertoire de travail courant par défaut). Voici un exemple minimal pour créer une sauvegarde à partir de Standalone exécuté localement dans Docker (consultez les options yaml complètes sur 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"
Puis lancez une vérification rapide :
$ 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!
Et enfin, créez la sauvegarde (cela prendra un peu de temps) :
$ milvus-backup create -n wiki_backup
2. Créer l’instance cible sur Zilliz Cloud
Tout d’abord, assurez-vous d’avoir un compte Zilliz Cloud — puis créez une instance qui correspond aux exigences minimales de votre déploiement local. Pour mes embeddings 50 M x 1 024-D sur Tiered-Storage, le calculateur public a estimé qu’il me fallait 2 Query CU :
J’ai donc accédé à la console cloud, cliqué sur « + Cluster », et utilisé ces paramètres :
Pendant sa création, vous pouvez récupérer/générer la clé API dont nous aurons besoin pour l’étape suivante :
Et notez l’ID de cluster de la nouvelle instance :
3. Migrer vers Zilliz
Mettez à jour votre backup.yaml pour inclure la clé cloud que vous venez de générer/récupérer :
cloud:
address: https://api.cloud.zilliz.com
apikey: <your-api-key>
Ensuite, il ne nous reste plus qu’à exécuter une commande de migration, avec le nom de la sauvegarde et l’ID du cluster cible passés en arguments :
$ milvus-backup migrate -n wiki_backup -c <your-cluster-id>
Dans mon cas, il a fallu quelques heures pour téléverser le fichier de sauvegarde d’environ 120 Go vers un Volume sur Zilliz Cloud, puis environ une heure pour créer le cluster cible à partir du Volume. Vous pouvez suivre l’état de la migration dans la console Zilliz Cloud sous Jobs :
Une fois la migration terminée, assurez-vous de charger la collection dans le cluster !
4. Validation
Vous pouvez maintenant simplement mettre à jour l’application pour utiliser le nouvel endpoint de cluster et les nouveaux identifiants.
Nous observons une amélioration des performances par rapport à Milvus Standalone — 25 ms contre 3 112 ms — soit une réduction de la latence de plus de 99 % !. Cela est en partie dû à l’augmentation des ressources de calcul allouées dans le service cloud, ainsi qu’au moteur d’indexation propriétaire de Zilliz Cloud — Cardinal — qui peut atteindre des requêtes 10x plus rapides que Milvus OSS.
Le gain de performance est énorme, mais mieux encore, je n’ai plus à m’inquiéter de l’arrêt du conteneur, et je peux libérer environ 20 Go de RAM sur mon ordinateur portable !
5. Autres considérations
- Si votre application ne fonctionne pas 24 h/24 et 7 j/7, votre base de données vectorielle n’en a pas besoin non plus. Suspendez les clusters inactifs afin de réduire le coût de calcul à zéro lorsqu’elle n’est pas utilisée.
- Tiered-Storage est un excellent type de cluster pour les besoins faibles (<10 QPS), mais il existe d’autres options et vous pouvez migrer les données entre elles :
- On-Demand — n’utilise le calcul que lorsque des requêtes sont en cours d’exécution. Cela pourrait réduire le coût de 99 %, selon la fréquence des requêtes, au prix d’une latence de démarrage à froid plus élevée.
- Capacity-Optimized — offre une densité de données réduite par rapport à Tiered-Storage, mais atteint un débit 10 fois supérieur et des requêtes 2 à 5 fois plus rapides. Cela augmenterait le coût de calcul de mon exemple d’environ 60 %.
- Performance-Optimized — offre un débit encore plus élevé (>1 000 QPS par réplica) et de meilleures performances (10 à 100 fois plus rapides) au prix d’une densité de données encore réduite.
- Zilliz Cloud prend en charge le montage de volumes externes depuis Google Cloud Storage, Amazon S3, Azure Blob Storage, etc. Une approche plus propre consisterait donc à téléverser la sauvegarde directement vers le stockage cloud et à la restaurer depuis celui-ci.
- Si la création/restauration d’une sauvegarde n’est pas possible pour une raison quelconque, et que le déploiement Milvus peut être rendu accessible publiquement, vous pouvez utiliser la fonctionnalité Migrate from Milvus Endpoint dans Zilliz Cloud.
- Tout ce que nous avons effectué dans Zilliz Cloud peut être géré via API et/ou Terraform si le click-ops n’est pas votre méthodologie préférée.
Continuer à lire
Introducing Customer-Managed Encryption Keys (CMEK) on Zilliz Cloud
We're announcing the general availability of Customer-Managed Encryption Keys (CMEK) on Zilliz Cloud.
Zilliz Cloud Now Available in AWS Europe (Ireland)
Zilliz Cloud launches in AWS eu-west-1 (Ireland) — bringing low-latency vector search, EU data residency, and full GDPR-ready infrastructure to European AI teams. Now live across 30 regions on five cloud providers.
Milvus 2.6.x Now Generally Available on Zilliz Cloud, Making Vector Search Faster, Smarter, and More Cost-Efficient for Production AI
Milvus 2.6.x is now GA on Zilliz Cloud, delivering faster vector search, smarter hybrid queries, and lower costs for production RAG and AI applications.