Milvus elemzés: a legteljesebb vektordatbázis üzemeltetve

A Milvus nyílt forráskódú vektordatbázis beágyazások közötti hasonlóságkeresésre, Go és C++ nyelven írva, az LF AI & Data keretében fejlesztve, a Zilliz pedig a fő közreműködő. Ennek az elemzésnek az álláspontja: nagyobb léptékben a legképesebb motor, amit a nyílt forráskód kínál, és egyben a legköltségesebb üzemeltetni — a valódi kérdés az, hogy ki futtatja a klasztert, nem az, hogy melyik indexnyerő.

A rendszer a RAG- vagy keresőstack lekérési rétegét foglalja el: azt a tárolót, amely vektorokat, metaadatokat és 3.0 óta hosszú szövegeket tart, és top-k lekérdezéseket válaszol meg szűrőkkel. Párban versenyez a Qdranttal és a Weaviate-tel önállóan üzemeltethető alternatívaként, a Pinecone-nal mint tisztán felhőszolgáltatással, a pgvector-ral pedig azokkal a csapatokkal, amelyek nem akarnak még egy adatbázist üzemeltetni. A Zilliz Cloud, amelyet az a cég értékesít, amely a kód nagy részét adja, a Apache-licencű projekt felhős ikertestvére.

Mi ez

Három telepítési forma létezik, és nem egyenértékűek. A Milvus Lite a Python-kliens által megnyitott helyi fájl kísérletekhez; a standalone egy csomópont a függőségeivel; a terjesztett mód a valódi termék: Kubernetes-re telepített, tároló- és számítási rétegre bontott rendszer.

• Apache-2.0 licenc, LF AI & Data projekt, a Zilliz a fő közreműködő; Go és C++ írva, a keresőmagok FAISS, HNSW, DiskANN és SCANN építőkövekből.
• Aktuális verzió: 3.0.2, 2026. szeptember 20., párhuzamosan a 2.6 ág is karbantartva, 2.6.25-ig.
• Indexválaszték: HNSW, IVF, FLAT, SCANN, DiskANN, GPU-indexek, például NVIDIA CAGRA, plusz kvantizálás és mmap a memóriakötött adatokhoz.
• Sűrű vektorok, tanult ritka vektorok és szerveroldali BM25 egyetlen kollekcióban, hibrid kereséssel és rerankinggel egyetlen kérésben.
• Több-bérlős működés adatbázis-, kollekció-, partíció- vagy partition-key szinten, hitelesítés, TLS és RBAC mögött.
• A 3.0 external kollekciókat hoz Parquet, Lance, Iceberg és Vortex fölött, snapshotokat, valamint online sémaváltoztatást backfillel.
• A lekérési stack elvárt integrációi: LangChain, LlamaIndex, Attu az adminisztrációhoz, Prometheus és Grafana a monitorozáshoz, továbbá Spark- és Kafka-kapcsolók.

Hogyan működik

A Milvus négy rétegre bontja az adat- és a vezérlési síkot. Az állapotmentes proxyk fogadják és redukálják a kéréseket; egyszerre pontosan egy koárdinátor aktív, ő ütemezi a DDL-, útvonalazási-, lekérdezési- és kompaktálási feladatokat; a worker-csomópontok végrehajtanak, saját adat nélkül; a tároló megosztott. A dokumentáció a Woodpeckert nulla lemezes write-ahead logként írja le, amely közvetlenül az objektumtárolóba ír, így a helyi lemez kezelése kikerül a írási útból.

Egy írás először a WAL-be kerül, a streaming node-ban növevő adatként lekérdezhető, és ott is marad, amíg a kompaktálás le nem zárja; a data node ezután felépíti az indexeket, a query node pedig betölti őket. A keresés helyben a növevő adatokon és párhuzamosan a lezárt szegmenseken fut, az eredmények három szinten redukálódnak, mielőtt a proxy visszaadja őket. Minden lépés az a hely, ahol a konzisztencia-szint és a replica elhelyezése megváltoztatja a várt késleltetést.

Első lépések

A legrövidebb út a Milvus Lite a Python-kliensen keresztül: egy pip install és egy fájlnév, szerver nélkül, etcd nélkül, objektumtároló nélkül. Ugyanaz a kliens aztán uri és token megváltoztatásával szerverre vagy Zilliz Cloud végpontra mutat, ezért a prototípusok általában újraírás nélkül továbbélnek.

# pip install -U pymilvus  — Milvus Lite stores everything in one local file
from pymilvus import MilvusClient

client = MilvusClient(uri="./milvus_demo.db")

client.create_collection(
    collection_name="papers",
    dimension=768,        # must match the embedding model
    auto_id=True,
    metric_type="COSINE",
)

client.insert(collection_name="papers", data=[
    {"vector": v, "title": t, "year": y} for v, t, y in rows
])

hits = client.search(
    collection_name="papers",
    data=[query_vector],
    limit=5,
    filter="year >= 2023",
    output_fields=["title", "year"],
)
print([(h["entity"]["title"], round(h["distance"], 3)) for h in hits[0]])

A leegyszerűsített kliens elrejti a sémát, az indexparamétereket és a dinamikus mezőket, és egy prototípusnál ez a megfelelő szint. Élesben ezeket a döntéseket explicit meg kell hozni: metrika típusa, indextípus, kvantizálás, mmap, partition key a többbérlőshöz, és kérésenkénti konzisztenciaszint.

Hibrid keresés és lépték

A Milvus sűrű vektorokat, tanult ritka vektorokat és a BM25 kimenetét ugyanabban a kollekcióban tartja, így egy kérés több vektorkeresést is lefuttathat és összemoshat. A reranking a 3.0-ban a szerverre költözött: a Function Chain API pontátalakítást, modellen alapuló rerankinget és jelöltvágást fűz egyetlen keresési hívásba, a súlyozott reciprocal-rank fúzió pedig 3.0.1-ben érkezett.

• A BM25 szerveroldalon készül a nyers szövegből, az alkalmazás nem küldi oda-vissza a tokeneket.
• A ritka keresés a 3.0-ban SINDI köré épült, Block-Max WAND és Block-Max MaxScore választható terhelés szerint.
• Az ANN útvonalon futó faceted search a legfelső facetértékeket COUNT és AVG mellett ugyanabban a kérésben adja vissza, nem kliensoldali túllekéréssel.
• A TEXT mezők 64 KB alatti értékeket soron belül tárolnak, a nagyobbakat partíciószintű LOB-fájlokban, így a forrásszöveg és a vektor egy tárolóból olvasható.

A 3.0.0-as release notes két belső számot közöl: a tömörített BM25-index összehasonlítható recall mellett nagyjából háromszor kisebb, mint a 2.6 ritka indexe, a SINDI pedig tanult ritka beágyazásokon akár mintegy tízszeres QPS-t ér el a MaxScore-hoz képest. Mindkettő a szállító saját mérése. A beszédesebb szám a 3.0.2-ben van: kivettek egy atomikus refcount-helyszűkést, amely a keresés leaf CPU-idejének körülbelül 48%-át tette ki. A szűrt keresés eddig fizette ezt az adót, a termelési vektormunkák pedig nagyrészt szűrt lekérdezések.

Üzemeltetés és költség

A Milvus önálló üzemeltetése azt jelenti, hogy a koárdinátor failoverje, a replica elhelyezése, a kompaktálás viselkedése és az indexépítési kapacitás a saját felelősség. A Zilliz Cloud ugyanezt a motort árulja ezek nélkül a döntések nélkül, az ároldalak pedig pontosan megmondják, miért fizet az ember.

• Ingyenes sáv: 5 GB tárhely, havonta 2.5 millió vCU és legfeljebb 5 kollekció, csak közösségi támogatással.
• A dedicated kiszolgálószámítás listaára $0.273 óránkénti CU-nként a performance- és capacity-optimalizált klasztereknél, $0.41 a tiered-storage klaszternél.
• A tárhely listaára dedicated klaszternél $0.025 GBenként havonta, óránként számlázva; a biztonsági mentés szintén $0.025 GBenként havonta.
• Az Enterprise $197 havonta indul, 99.95% uptime SLA-val, audit logokkal, SSO-val és VPC-peeringgel.
• A nagy léptékű lekérdezés- és indexfeladatokhoz való on-demand compute listaára $0.41 óránkénti CU-nként, percenkénti CU-ban számlázva.

Ahol megakad

Először a gyengeségek. A Milvus elosztott rendszer koárdinátorral, WAL-lel, objektumtárolóval és index-worker-ekkel, és ez a felület jóval hamarabb jelenik meg üzemeltetési munkaként, mint képességként. Sémaelemszerű változtatások, indexépítések újra és a kompaktálás hangolása hétköznapi feladatok hétköznapi hibamódokkal; önmagában a 3.0.2 hoz javításokat egy olyan replica-ra, amelynek minden csatornája egy query node-ra került és így használhatatlanná vált, valamint olyan WAL-fencingre, amely 45–60 másodpercre megfagyasztotta az írásokat.

• Telepítési költség: a terjesztett mód Kubernetes-telepítés operátorokkal, nem egy docker run.
• A kis terhelések megfizetik az architektúrát: tízmillió vektor alatt az egyetlen bináris tároló egyszerűbb és általában gyorsabb lekérdezni.
• A verziószétlátás drága: a 2.6 és a 3.0 párhuzamosan karbantartott, a Storage V3 alapból ki van kapcsolva, és bekapcsolva eltűnik a visszalépés a 2.6-ra.
• A nyilvános összehasonlító anyag zöme szállítói anyag; független számok rögzített recall-céllal alig léteznek.

Ezt a táblát figyelemköltség-ként olvasd, nem funkcióként. A Milvus akkor nyer, ha a terhelés nagy, szűrt és több bérlős, és mindenhol máshol veszít, mert a koárdinátor, a WAL és az index-worker-ek is szolgálatban lévő embert kívánnak.

Ítélet

A Milvus a megfelelő motor egy olyan csapatnak, amely már futtat elosztott rendszereket, és van olyan terhelése, amely igazolja őket. Rossz első választás egy olyan terméknél, amely még keresi a lekérési minőségét, ahol a gyorsabb iteráció többet ér, mint a far-késleltetés.

1. Válaszd, ha százmilliós nagyságrendű vektorok, szigorú bérlőelkülönítés, vagy sűrű és ritka lekérés egy tárolóban kell.
2. Csak akkor üzemeltessd magad, ha a csapatban valaki már kezel állomásos Kubernetes-szolgáltatásokat; különben Zilliz Cloud-on kezdd, és tartsd nyitva a migrációs utat.
3. Hagyd ki pár millió chunk alatti RAG-prototípusnál: Lite a kísérlethez, aztán egyetlen bináris tároló a termeléshez.
4. Hagyd ki, ha az adat amúgy is a Postgresben van, és a vektorkeresés csak mellékfunkció; a pgvector egy biztonsági mentést és egy hitelesítőkészletet jelent.
5. Bárhogy is döntesz, rögzítsd a verziót és olvasd el a release noteokat: a 3.0 tárolóformátum-alapértelmezéseket változtatott, az új indexek pedig alapból ki vannak kapcsolva.

A vektordatázis, amelyet nem tudsz üzemeltetni, nem olcsóbb adatbázis. Egy ki nem fizetett üzemeltetési szerződés egy hozzábiggyesztett indexszel.

Források

1. Milvus: architektúra-áttekintés
2. Milvus: release notes
3. Milvus-kiadások a GitHubon
4. Milvus README: funkciók és licenc
5. Zilliz Cloud árak
6. Zilliz Cloud: listaár