Când o organizație depășește câteva milioane de vectori (de exemplu în e-commerce cu cataloage vaste de produse sau bănci cu arhive uriașe de tranzacții), bazele de date vectoriale embedded sau pe un singur nod încep să sufere degradări severe de memorie și latență.
Milvus (și versiunea sa administrată în cloud, Zilliz) a fost proiectat de la zero ca un sistem distribuit masiv bazat pe o arhitectură decuplată pe 4 niveluri: Access Layer (coordonare stateless), Coordinator Service (management de metadate și sarcini), Worker Nodes (noduri de calcul specializate de interogare QueryNodes și indexare DataNodes) și Storage Layer (stocare persistentă pe MinIO/S3 și jurnale pe Apache Pulsar/Kafka).
Datorită acestei separări, scalarea capacității de interogare se face adăugând QueryNodes în timp real fără downtime, iar suportul pentru indici avansați precum HNSW, IVF_FLAT și DiskANN permite interogarea miliardelor de vectori cu latențe sub 10 milisecunde.
Sintaxă, opțiuni și concepte cheie
| Opțiune / Concept | Descriere practică |
|---|---|
Disaggregated Storage-Compute |
Arhitectura în care datele trăiesc pe S3/MinIO, iar memoria RAM a nodurilor conține doar segmentele fierbinți. |
QueryNode / DataNode |
Noduri elastice de Kubernetes dedicate exclusiv căutării în memorie sau construirii de indici vectoriali. |
DiskANN Indexing |
Algoritmul ce permite căutarea de înaltă fidelitate direct pe unități NVMe SSD, reducând costurile cu memoria RAM cu până la 80%. |
Partition & Sharding Key |
Mecanismul de partiționare fizică a colecțiilor mari pentru localizarea precisă a cererilor. |
Exemple practice și configurații
Exemplul 1: Crearea unei colecții distribuite și căutare HNSW în Python cu PyMilvus
Codul Python complet pentru definirea schemei și executarea unei interogări vectoriale.
from pymilvus import connections, FieldSchema, CollectionSchema, DataType, Collection
# 1. Conectare la clusterul distribuit Milvus
connections.connect("default", host="milvus-cluster.internal", port="19530")
# 2. Definim schema cu câmp vectorial de 1536 dimensiuni
campuri = [
FieldSchema(name="id", dtype=DataType.INT64, is_primary=True, auto_id=True),
FieldSchema(name="vector", dtype=DataType.FLOAT_VECTOR, dim=1536),
FieldSchema(name="categorie", dtype=DataType.VARCHAR, max_length=64)
]
schema = CollectionSchema(campuri, "Catalog produse la scară largă")
colectie = Collection("catalog_v1", schema)
# 3. Construim indexul HNSW pe GPU/CPU și căutăm primii 10 vecini
colectie.create_index("vector", {"index_type": "HNSW", "metric_type": "COSINE", "params": {"M": 16, "efConstruction": 200}})
colectie.load()
rezultate = colectie.search([vector_interogare], "vector", {"metric_type": "COSINE", "params": {"ef": 64}}, limit=10)Rezultat & Impact
Interogare executată în 4.2ms peste o colecție distribuită masivă.Greșeli frecvente și bune practici
- Ne-încărcarea colecției în memorie (`collection.load()`) înainte de căutare, ceea ce generează o eroare imediată de execuție.
- Configurarea unui `efConstruction` prea mare în HNSW fără resurse CPU/RAM adecvate, ducând la blocarea nodurilor de indexare.