Migration von selbstverwaltetem Milvus zu Zilliz Cloud für >99 % Latenzreduzierung
Ursprünglich veröffentlicht auf simonhearne.com und mit Genehmigung erneut veröffentlicht.
Du hast also eine Anwendung mit Milvus als Vektordatenbank erstellt, unter Verwendung von Standalone oder Distributed. Du hast einen Punkt erreicht, an dem die Anwendung funktioniert, Kunden sie nutzen und das Datenvolumen wächst. Irgendwann beginnt die Verwaltung der Vektordatenbank mehr Zeit zu beanspruchen, Pod-Ausfälle verursachen Service-Jitter, dir geht der RAM auf dem Server aus, oder etcd wird zu einem schmerzhaften Engpass.
In dieser Phase erkundest du wahrscheinlich einen verwalteten Service, um die operative Last abzugeben. Die gute Nachricht ist, dass die Migration von Milvus zu Zilliz Cloud unkompliziert ist, und die verschiedenen Optionen sind gut dokumentiert.
In meinem Fall hatte ich eine einfache Wikipedia-RAG-Anwendung erstellt: 50 Mio. Embeddings mit Coheres mehrsprachigem Embed-v3-Modell mit 1.024 Dimensionen (das den gesamten englischen Wikipedia-Korpus abdeckt). Anfangs hostete ich dies auf meinem Laptop mit Milvus Standalone, aber der Container war instabil, und Neustarts dauerten ~20 Minuten — nicht ideal, wenn man eine Demo zeigen möchte!
Auch die Abfrageleistung litt unter häufigem Paging (ich habe nicht genug Arbeitsspeicher auf meinem Laptop, daher habe ich mmap aktiviert). Unten ist ein kurzes Video, das die Anwendung in Aktion zeigt:
Abfragezeiten von drei Sekunden sind nicht gerade großartig, also plante ich ohne Budget für einen neuen Laptop meine Migration zu verwaltetem Milvus auf Zilliz Cloud. Im Folgenden findest du den Schritt-für-Schritt-Prozess, den ich befolgt habe — es stehen mehrere Methoden zur Verfügung, aber ich habe mich der Einfachheit halber für Backup/Restore entschieden.
1. Ein Backup erstellen
Zilliz stellt das Dienstprogramm milvus-backup bereit, und die Installation ist so einfach wie brew install milvus-backup
Dann musst du eine Konfigurationsdatei erstellen (milvus-backup sucht standardmäßig im aktuellen Arbeitsverzeichnis nach backup.yaml). Dies ist ein minimales Beispiel, um ein Backup von Standalone zu erstellen, das lokal in Docker läuft (siehe die vollständigen yaml-Optionen auf 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"
Führe dann eine schnelle Prüfung aus:
$ 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!
Und erstelle schließlich das Backup (das wird etwas Zeit in Anspruch nehmen):
$ milvus-backup create -n wiki_backup
2. Die Zielinstanz auf Zilliz Cloud erstellen
Stelle zunächst sicher, dass du ein Zilliz Cloud-Konto hast — erstelle dann eine Instanz, die den Mindestanforderungen deiner lokalen Bereitstellung entspricht. Für meine 50 Mio. x 1.024-D-Embeddings auf Tiered-Storage schätzte der öffentliche Rechner, dass ich 2 Query CU benötigte:
Also navigierte ich zur Cloud-Konsole, klickte auf „+ Cluster“ und verwendete diese Einstellungen:
Während sie erstellt wird, kannst du den API-Schlüssel abrufen/generieren, den wir für den nächsten Schritt benötigen:
Und notiere dir die Cluster-ID der neuen Instanz:
3. Zu Zilliz migrieren
Aktualisiere deine backup.yaml, um den Cloud-Schlüssel einzuschließen, den du gerade generiert/abgerufen hast:
cloud:
address: https://api.cloud.zilliz.com
apikey: <your-api-key>
Dann müssen wir abschließend nur noch einen Migrationsbefehl ausführen, wobei der Backup-Name und die Ziel-Cluster-ID als Argumente übergeben werden:
$ milvus-backup migrate -n wiki_backup -c <your-cluster-id>
In meinem Fall dauerte es ein paar Stunden, die ~120GB große Backup-Datei auf ein Volume in Zilliz Cloud hochzuladen, und dann etwa eine Stunde, um den Ziel-Cluster aus dem Volume zu erstellen. Du kannst den Migrationsstatus in der Zilliz Cloud-Konsole unter Jobs überwachen:
Sobald die Migration abgeschlossen ist, stelle sicher, dass du die Collection in den Cluster lädst!
4. Validierung
Jetzt kannst du die Anwendung einfach aktualisieren, sodass sie den neuen Cluster-Endpunkt und die neuen Anmeldedaten verwendet.
Wir beobachten eine Leistungsverbesserung im Vergleich zu Milvus Standalone — 25ms im Vergleich zu 3,112ms — das entspricht einer Latenzreduzierung von über 99 %!. Dies ist teilweise auf die erhöhte Rechenleistung zurückzuführen, die im Cloud-Service zugewiesen ist, sowie auf die proprietäre Index-Engine in Zilliz Cloud — Cardinal — die im Vergleich zu Milvus OSS 10-mal schnellere Abfragen erreichen kann.
Der Leistungsgewinn ist enorm, aber noch besser: Ich muss mir keine Sorgen mehr machen, dass der Container stoppt, und ich kann ~20GB RAM auf meinem Laptop freigeben!
5. Weitere Überlegungen
- Wenn Ihre Anwendung nicht rund um die Uhr läuft, muss Ihre Vektordatenbank das auch nicht. Pausieren Sie inaktive Cluster, um die Rechenkosten auf null zu senken, wenn sie nicht genutzt werden.
- Tiered-Storage ist ein großartiger Cluster-Typ für niedrige Anforderungen (<10 QPS), aber es gibt andere Optionen, und Sie können Daten zwischen ihnen migrieren:
- On-Demand — nutzt Compute nur, wenn Abfragen ausgeführt werden. Dies könnte die Kosten je nach Häufigkeit der Abfragen um 99 % senken, auf Kosten einer höheren Cold-Start-Latenz.
- Capacity-Optimized — bietet im Vergleich zu Tiered-Storage eine geringere Datendichte, erreicht aber einen 10-fach höheren Durchsatz und 2- bis 5-mal schnellere Abfragen. Dies würde die Compute-Kosten meines Beispiels um etwa 60 % erhöhen.
- Performance-Optimized — bietet noch höheren Durchsatz (>1.000 QPS pro Replikat) und bessere Performance (10- bis 100-mal schneller), auf Kosten einer weiter reduzierten Datendichte.
- Zilliz Cloud unterstützt das Einbinden externer Volumes von Google Cloud Storage, Amazon S3, Azure Blob Storage usw. Ein saubererer Ansatz wäre daher, das Backup direkt in den Cloud-Speicher hochzuladen und es von dort wiederherzustellen.
- Wenn das Erstellen/Wiederherstellen eines Backups aus irgendeinem Grund nicht möglich ist und das Milvus-Deployment öffentlich zugänglich gemacht werden kann, können Sie die Funktion Migrate from Milvus Endpoint in Zilliz Cloud verwenden.
- Alles, was wir in Zilliz Cloud durchgeführt haben, kann über API und/oder Terraform verwaltet werden, wenn Click-Ops nicht Ihre bevorzugte Methode ist.
Weiterlesen
Vector Lakebase: End the AI Data Silo
Learn how Vector Lakebase unifies vector search, data lakes, and AI data operations so teams can serve RAG and agents without copy-and-sync pipelines.
Introducing Customer-Managed Encryption Keys (CMEK) on Zilliz Cloud
We're announcing the general availability of Customer-Managed Encryption Keys (CMEK) on Zilliz Cloud.
Build for the Boom: Why AI Agent Startups Should Build Scalable Infrastructure Early
Explore strategies for developing AI agents that can handle rapid growth. Don't let inadequate systems undermine your success during critical breakthrough moments.