Migrazione da Milvus autogestito a Zilliz Cloud per una riduzione della latenza >99%
Pubblicato originariamente su simonhearne.com e ripubblicato con autorizzazione.
Quindi hai creato un'applicazione usando Milvus come database vettoriale, utilizzando Standalone o Distributed. Sei arrivato a un punto in cui l'applicazione funziona, i clienti la stanno usando e il volume dei dati sta crescendo. A un certo punto, gestire il database vettoriale inizia a richiedere più tempo, i guasti dei pod causano instabilità del servizio, stai esaurendo la RAM sul server, oppure etcd diventa un collo di bottiglia problematico.
A questo punto, probabilmente stai valutando un servizio gestito per eliminare il carico operativo. La buona notizia è che migrare da Milvus a Zilliz Cloud è semplice, e le varie opzioni sono ben documentate.
Nel mio caso, avevo creato una semplice applicazione RAG per Wikipedia: 50M embedding usando il modello multilingue Embed v3 di Cohere a 1.024 dimensioni (che copre l'intero corpus di Wikipedia in inglese). Inizialmente, l'ho ospitata sul mio laptop usando Milvus Standalone, ma il container era instabile e i riavvii richiedevano ~20 minuti — non l'ideale quando vuoi mostrare una demo!
Anche le prestazioni delle query ne risentivano a causa del paging frequente (non ho abbastanza memoria sul mio laptop, quindi ho abilitato mmap). Di seguito c'è un breve video che mostra l'applicazione in azione:
Tempi di query di tre secondi non sono il massimo, quindi, non avendo il budget per un nuovo laptop, ho pianificato la migrazione a Milvus gestito su Zilliz Cloud. Di seguito c'è il processo passo passo che ho seguito — sono disponibili diversi metodi, ma ho scelto backup/restore per semplicità.
1. Crea un backup
Zilliz fornisce l'utility milvus-backup, e installarla è semplice come brew install milvus-backup
Devi quindi creare un file di configurazione (milvus-backup cerca backup.yaml nella directory di lavoro corrente per impostazione predefinita). Questo è un esempio minimale per creare un backup da Standalone eseguito localmente in Docker (vedi le opzioni yaml complete su 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"
Poi esegui un rapido controllo:
$ 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!
E infine, crea il backup (ci vorrà un po' di tempo):
$ milvus-backup create -n wiki_backup
2. Crea l'istanza di destinazione su Zilliz Cloud
Per prima cosa, assicurati di avere un account Zilliz Cloud — poi crea un'istanza che soddisfi i requisiti minimi del tuo deployment locale. Per i miei embedding 50M x 1.024-D su Tiered-Storage, il calcolatore pubblico stimava che mi servissero 2 Query CU:
Quindi sono andato alla console cloud, ho cliccato su "+ Cluster" e ho usato queste impostazioni:
Mentre viene creata, puoi recuperare/generare la chiave API di cui avremo bisogno per il passaggio successivo:
E annota l'ID del cluster della nuova istanza:
3. Migrare a Zilliz
Aggiorna il tuo backup.yaml per includere la chiave cloud che hai appena generato/recuperato:
cloud:
address: https://api.cloud.zilliz.com
apikey: <your-api-key>
Poi, infine, dobbiamo solo eseguire un comando di migrazione, con il nome del backup e l'ID del cluster di destinazione passati come argomenti:
$ milvus-backup migrate -n wiki_backup -c <your-cluster-id>
Nel mio caso, ci sono volute alcune ore per caricare il file di backup da ~120GB su un Volume su Zilliz Cloud, poi circa un'ora per creare il cluster di destinazione dal Volume. Puoi monitorare lo stato della migrazione nella console di Zilliz Cloud sotto Jobs:
Una volta completata la migrazione, assicurati di caricare la collection nel cluster!
4. Validazione
Ora puoi semplicemente aggiornare l'applicazione per usare il nuovo endpoint del cluster e le nuove credenziali.
Osserviamo un miglioramento delle prestazioni rispetto a Milvus Standalone — 25ms rispetto a 3.112ms — ovvero una riduzione della latenza di oltre il 99%!. Questo è dovuto in parte alla maggiore capacità di calcolo allocata nel servizio cloud, così come al motore di indicizzazione proprietario in Zilliz Cloud — Cardinal — che può ottenere query 10 volte più veloci rispetto a Milvus OSS.
Il guadagno in termini di prestazioni è enorme, ma ancora meglio, non devo più preoccuparmi che il container si fermi, e posso liberare ~20GB di RAM sul mio laptop!
5. Altre considerazioni
- Se la tua applicazione non è in esecuzione 24x7, non è necessario che lo sia nemmeno il tuo database vettoriale. Sospendi i cluster inattivi per ridurre a zero il costo di calcolo quando non viene utilizzato.
- Tiered-Storage è un ottimo tipo di cluster per requisiti bassi (<10 QPS), ma ci sono altre opzioni e puoi migrare i dati tra di esse:
- On-Demand — utilizza il calcolo solo quando vengono eseguite query. Questo potrebbe ridurre il costo del 99%, a seconda della frequenza delle query, al prezzo di una maggiore latenza di avvio a freddo.
- Capacity-Optimized — offre una densità dei dati ridotta rispetto a Tiered-Storage, ma raggiunge un throughput 10 volte superiore e query 2-5 volte più veloci. Questo aumenterebbe il costo di calcolo del mio esempio di circa il 60%.
- Performance-Optimized — offre throughput ancora maggiore (>1.000 QPS per replica) e prestazioni (10-100 volte più veloci) al costo di una densità dei dati ulteriormente ridotta.
- Zilliz Cloud supporta il montaggio di volumi esterni da Google Cloud Storage, Amazon S3, Azure Blob Storage, ecc. Quindi un approccio più pulito sarebbe caricare il backup direttamente nello storage cloud e ripristinarlo da lì.
- Se la creazione/il ripristino di un backup non è possibile per qualsiasi motivo, e il deployment Milvus può essere reso accessibile pubblicamente, puoi usare la funzionalità Migrate from Milvus Endpoint in Zilliz Cloud.
- Tutto ciò che abbiamo eseguito in Zilliz Cloud può essere gestito tramite API e/o Terraform se il click-ops non è la tua metodologia preferita.
Continua a leggere
Introducing Loon: A New Storage Engine for Vector Data That Never Stops Changing
Loon is a new storage engine for Milvus 3.0 and Zilliz Vector Lakebase, built to manage evolving vector datasets with ColumnGroups, row ID alignment, and Manifests.
Introducing Zilliz MCP Server: Natural Language Access to Your Vector Database
Developers can easily manage and query vector databases with natural language via Zilliz MCP Server in AI-native environments.
DeepSeek-VL2: Mixture-of-Experts Vision-Language Models for Advanced Multimodal Understanding
Explore DeepSeek-VL2, the open-source MoE vision-language model. Discover its architecture, efficient training pipeline, and top-tier performance.