Ankündigung von Milvus 3.0: Lake-native Vektorsuche und eine leistungsstärkere Retrieval-Engine

Heute veröffentlichen wir Milvus 3.0, einen wichtigen architektonischen Meilenstein für das Projekt. Es verändert sowohl, wo Milvus Indizes erstellen und bereitstellen kann, als auch, wie viel Retrieval-Arbeit direkt innerhalb der Engine erledigt werden kann.

• Milvus 3.0 führt einen lake-nativen Pfad für die Indizierung von Vektordaten ein, die in Objektspeichern und offenen Tabellenformaten liegen, darunter Parquet, Lance, Iceberg und Vortex. Teams können im Lake gespeicherte Daten durchsuchbar machen, ohne eine weitere Kopie in einer Vektordatenbank zu pflegen.
• Diese Version erweitert Milvus außerdem über das initiale Abrufen von Kandidaten hinaus. Serverseitiges Sortieren, Aggregation, facettierte Suche, StructArray für verschachtelte Dokument-/Chunk-Strukturen und ColBERT-Vektoren sowie ein neu gestalteter Sparse-Index verlagern mehr Ranking, Gruppierung und Ergebnisverarbeitung aus dem Anwendungscode in die Retrieval-Engine.

Zusammen machen diese Fortschritte Milvus zur Open-Source-Grundlage für produktionsreifes KI-Retrieval und für Vector-Lakebase-Architekturen, die lake-nativen Speicher mit leistungsstarkem Vektor-Retrieval kombinieren.

Ein kurzer Überblick über den Funktionsumfang von Milvus 3.0

Bereich	Funktionen	Warum es wichtig ist
Lake-natives Retrieval	External Collections über Parquet, Lance, Iceberg und Vortex	Durchsuchen von im Lake gespeicherten Daten, ohne eine zweite Serving-Kopie zu pflegen
S3-basierter Speicher	Loon (Storage v3)	Reduzierung der Point-Read-Amplification für Serving-artige Zugriffe und Unterstützung von Schema-Evolution
Offline-/Batch-Workflows und Wiederherstellung	Snapshots, Spark DataSource V2 und Online-Schema-Evolution	Stabile Collection-Ansichten in Evaluierung, Deduplizierung, Clustering und Feature-Pipelines bringen
Retrieval-Engine	ORDER BY, Aggregation, Facets, StructArray und verbessertes Sparse Retrieval	Mehr Ergebnisverarbeitung und Multi-Vektor-Scoring in Milvus verlagern
Datenmodell & Betrieb	Nullable Vectors, TEXT LOB, TTL, MinHash, Woodpecker und ForceMerge	Umfangreichere Datenmodelle und produktionsreife Betriebsmuster unterstützen

Die lake-native Infrastruktur: Daten dort indizieren und bereitstellen, wo sie bereits liegen

Die größte architektonische Änderung in Milvus 3.0 betrifft den Ort, an dem das System Indizes erstellen und bereitstellen kann. Vektordaten können in offenen Formaten im Objektspeicher verbleiben, während Milvus produktionsreife Indizierung, Retrieval und APIs bereitstellt.

1. External Collections: direktes Indizieren von im Lake gespeicherten Daten

Viele Teams speichern Embeddings bereits in einem Data Lake — Lance-Tabellen, Iceberg-Tabellen, Parquet-Dateien oder anderen Datensätzen in offenen Formaten auf S3, GCS oder Azure Blob Storage. Vor Milvus 3.0 gab es in der Regel zwei Optionen, um diese Daten zu durchsuchen.

• Die Embeddings in eine Vektordatenbank kopieren. Das bietet Suche mit niedriger Latenz, erzeugt aber eine zweite Kopie und eine ETL-Pipeline, die synchron bleiben muss.
• Den Lake direkt abfragen. Das vermeidet Duplikation, aber ohne ANN-Indizes wird die Vektorsuche zu einem Brute-Force-Scan, der Produktionslatenzen nicht erfüllen kann.

External Collections führen einen dritten Weg ein. Sie definieren eine Milvus-Collection über Daten, die im Objektspeicher verbleiben, ordnen externe Felder einem Milvus-Schema zu und nutzen dieselben Such- und Abfrage-APIs wie bei einer nativen Collection. Die Quelldateien werden nicht verschoben; Milvus erstellt und stellt Vektor-, BM25-Inverted-, JSON- und skalare Indizes über den externen Daten bereit.

External Collections sind read-only und zero-copy, was sie nützlich macht, wenn Governance, Eigentumsgrenzen oder Betriebskosten erfordern, dass der Quelldatensatz im Lake verbleibt.

Wenn sich der externe Datensatz ändert, liest Milvus sein Speicher-Manifest und indiziert neu hinzugefügte Fragmente, anstatt die gesamte Collection neu aufzubauen.

import json
import os
import time
from pymilvus import DataType, MilvusClient
client = MilvusClient(uri=“”)
# Register an Iceberg table as a zero-copy collection.
schema = client.create_schema(
external_source=“s3://lake/docs/metadata/v1.metadata.json”,
external_spec=json.dumps(
{
“format”: “iceberg-table”,
“snapshot_id”: 123456789,
“extfs”: {
“cloud_provider”: “aws”,
“region”: “us-east-1”,
“access_key_id”: os.environ[“AWS_ACCESS_KEY_ID”],
“access_key_value”: os.environ[“AWS_SECRET_ACCESS_KEY”],
},
}
),
)
schema.add_field(field_name=“id”, datatype=DataType.INT64, external_field=“doc_id”)
schema.add_field(field_name=“emb”, datatype=DataType.FLOAT_VECTOR, dim=1024, external_field=“embedding”)
schema.add_field(field_name=“title”, datatype=DataType.VARCHAR, max_length=1024, external_field=“title”)
client.create_collection(collection_name=“docs”, schema=schema)
# Import the external table snapshot.
job_id = client.refresh_external_collection(collection_name=“docs”)
while True:
progress = client.get_refresh_external_collection_progress(job_id=job_id)
if progress.state == “RefreshCompleted”:
break
if progress.state == “RefreshFailed”:
raise RuntimeError(progress.reason)
time.sleep(1)
index_params = client.prepare_index_params()
index_params.add_index(field_name=“emb”, index_type=“HNSW”, metric_type=“COSINE”)
client.create_index(collection_name=“docs”, index_params=index_params)
client.load_collection(collection_name=“docs”)

In regulierten Umgebungen kann Retrieval dort ausgeführt werden, wo die Daten liegen dürfen. Für große KI-Systeme kann ein im Lake gespeicherter Datensatz mehrere Retrieval-Deployments unterstützen, ohne dass zwischen ihnen ein Migrationsjob erforderlich ist.

External Collections sind eine additive Fähigkeit. Native Milvus-Collections bleiben der primäre Weg für schreibintensives Serving mit niedriger Latenz, während External Collections für Datensätze konzipiert sind, deren führendes System außerhalb von Milvus bleibt.

Weitere Details finden Sie unter Eine External Collection erstellen.

2. Loon (Storage v3): effiziente Point Reads für lake-natives Retrieval

External Collections werfen eine offensichtliche Frage auf: Objektspeicher ist auf Skalierung und Dauerhaftigkeit ausgelegt, aber kann er die engen Point Reads unterstützen, die auf eine ANN-Suche folgen?

Die Herausforderung ist Read Amplification. Vektorsuche läuft üblicherweise in zwei Phasen ab: Ein ANN-Index liefert Kandidaten-IDs zurück, und das System ruft ausgewählte Felder für diese Kandidaten ab. Formate, die für analytische Scans optimiert sind, können einen engen logischen Lookup in einen deutlich größeren physischen Read verwandeln.

Milvus 3.0 begegnet diesem Problem mit Loon, auch bekannt als Storage v3, einer manifestbasierten spaltenorientierten Storage-Engine für S3-kompatiblen Objektspeicher. Loon organisiert Felder in ColumnGroups mit ausgerichteten Zeilen-IDs, sodass skalare Felder Filterung und Scans begünstigen können, während Vektoren und Point-Read-intensive Felder Layouts verwenden, die für engere Lookups ausgelegt sind.

Loon hält Vektor- und Inverted-Indizes vom Dateiformat getrennt, anstatt sie darin einzubetten. Jede Datensatzversion wird durch ein unveränderliches Manifest beschrieben, das ihre ColumnGroups erfasst, sodass dieselbe Indizierungs-Engine über Lance, Parquet, Iceberg und Vortex hinweg arbeiten kann.

Das Manifest-Design macht Schema-Evolution ebenfalls weniger disruptiv. Das Hinzufügen oder Entfernen eines Felds kann Metadaten aktualisieren, ohne bestehende Spalten neu zu schreiben. Das Befüllen eines neuen Felds schreibt eine neue ColumnGroup, während bestehende ColumnGroups unverändert bleiben.

Vortex ist das Standardformat für diesen Pfad. Es ist ein offenes, Arrow-kompatibles spaltenorientiertes Format mit flexiblen Layouts und verschachtelten Kodierungen, die besser zu Point-Query-intensiven KI-Daten passen. In einem internen Benchmark mit 3 Millionen Zeilen, 128-dimensionalen Vektoren, S3 und 256 parallelen Lesern sank der gemessene I/O pro Point Read von etwa 9,4 MB für die Parquet-Baseline auf 0,07 MB für Vortex mit Loon, also ungefähr 135-mal weniger.

Milvus 3.0 lässt Objektspeicher nicht wie lokalen Speicher agieren. Es reduziert die Read Amplification, die Objektspeicher sonst für Serving-artige Point Lookups unpraktisch macht. Predicate Pushdown in das Format und eine lokale Vortex-Variante stehen als Nächstes auf der Roadmap.

Weitere Details finden Sie in unserem Blog: Warum wir Loon entwickelt haben und im Vortex-Projekt.

3. Snapshots: Point-in-Time-Ansicht ohne Datenkopie

Offline-Jobs benötigen eine konsistente Sicht auf Daten, auch während Produktions-Collections weiterhin Schreibvorgänge erhalten. Ein Milvus-Snapshot ist eine zeitpunktbezogene, schreibgeschützte Ansicht, die Verweise auf bestehende Daten-, Index- und Metadatendateien aufzeichnet, anstatt den vollständigen Datensatz zu kopieren.

Dadurch sind Snapshots kostengünstig genug, um sie vor riskanten Vorgängen wie einem Modellwechsel, einem Re-Embedding-Job oder einer Schema-Migration zu erstellen. Die Wiederherstellung eines Snapshots kann bestehende Daten- und Indexdateien durch serverseitiges Kopieren im Objektspeicher wiederverwenden, anstatt jede Zeile erneut zu importieren und jeden Index neu aufzubauen. Diese Funktion ist besonders nützlich für schnelllebige Workloads wie KI-Agenten, bei denen sich Daten ständig ändern und man häufige, günstige Wiederherstellungspunkte statt gelegentlicher schwergewichtiger Backups wünscht.

Dieselbe eingefrorene Ansicht kann Evaluierung, Deduplizierung, Backfill-Validierung und isolierte Tests unterstützen, während die Live-Collection weiterhin Schreibvorgänge akzeptiert. Der Snapshot stabilisiert die logische Eingabe, auch wenn die Workloads weiterhin Infrastruktur wie Objektspeicher und Netzwerkbandbreite gemeinsam nutzen können.

Snapshots ersetzen keine Backups. Ein Snapshot referenziert Dateien, die der Live-Collection gehören, und eignet sich am besten für logische Wiederherstellung, Klonen und kurzlebige stabile Ansichten. Ein Backup erstellt eine unabhängige Kopie für langfristige Aufbewahrung und Disaster Recovery.

Weitere Informationen finden Sie unter Snapshots, Snapshots verwalten und Snapshot-Anwendungsfälle.

4. Spark-Connector: Milvus mit Batch-Workflows verbinden

Ein stabiler Snapshot ist nur dann nützlich, wenn Batch-Engines ihn lesen können. Milvus 3.0 stellt Milvus als Spark DataSource V2 bereit, sodass Spark-, Databricks- und EMR-Jobs im Rahmen standardmäßiger Batch-Pipelines aus Milvus lesen und nach Milvus schreiben können.

Diese Funktion ist wichtig, weil KI-Daten-Workflows iterativ sind: Deduplizierung speist Re-Embedding, Clustering speist Evaluierung, und Evaluierung erzeugt kuratierte Trainings- oder Serving-Sets. Ein stabiler Snapshot liefert diesen Jobs konsistente Eingaben, während die Live-Collection weiter bereitstellt. Mit dem Spark-Connector wird die Senke eines Jobs zur Quelle des nächsten, ohne jedes Mal eine vollständige Collection aus Milvus zu exportieren.

Milvus 3.0 führt außerdem vektornative Batch-Operatoren für Aufgaben wie Deduplizierung, Anomalieerkennung und Clustering ein, sodass rechenintensive Arbeit außerhalb des Online-Abfragepfads bleibt und direkt auf Vektordaten operiert.

5. Online-Schemaänderungen und Backfill

Ein Schema bleibt in der Produktion selten statisch — Teams fügen im Laufe der Zeit neue Embedding-Modelle, Sparse-Vektoren, Labels, Metadatenfelder und Aufbewahrungsrichtlinien hinzu. Milvus 3.0 ermöglicht es ihnen, Spalten hinzuzufügen, zu befüllen und zu entfernen, während das Serving weiterläuft, anstatt der disruptiven Neuaufbauten, die dafür früher erforderlich waren.

Das Hinzufügen oder Entfernen einer Spalte erfordert kein Neuschreiben bestehender Daten. client.add_collection_field(...) legt eine neue nullable Spalte an, ohne die Collection offline zu nehmen, und client.drop_collection_field(...) entfernt ein veraltetes oder experimentelles Feld zur Laufzeit. Keines davon schreibt die bestehenden Daten neu — beides ist eine Änderung am Manifest der Collection statt an den Datendateien, weshalb kein Neuaufbau erforderlich ist.

Milvus 3.0 unterstützt zwei Backfill-Pfade:

• Inner Backfill (in 3.0) ist für Werte gedacht, die aus bestehenden Feldern abgeleitet werden. Milvus kann innerhalb des Kernels einen BM25-Sparse-Vektor aus einer Textspalte erzeugen und damit beim Aufbau von Dense-plus-Sparse-Hybrid-Retrieval den Bedarf an einem clientseitigen Encoder eliminieren.
• External Backfill(auf der Roadmap) wird für Werte gedacht sein, die außerhalb von Milvus berechnet werden: einen Snapshot erstellen, Spark gegen die konsistente Ansicht ausführen, eine neue Spalte berechnen, die Werte zurückschreiben und Milvus den Index inkrementell aktualisieren lassen. Dies ist der vorgesehene Weg für große Re-Embedding-Jobs — zum Beispiel das Hinzufügen einer neuen Embedding-Spalte über Hunderte Millionen Zeilen hinweg, während Schreibvorgänge weiterlaufen.

Zusammen erleichtern Online-Schemaänderungen und Backfill die Weiterentwicklung von Retrieval-Pipelines, ohne jedes Mal eine gesamte Collection neu aufzubauen, wenn sich das Datenmodell ändert.

Eine leistungsstärkere Engine für End-to-End-Retrieval

Milvus unterstützt seit Langem mehr als Dense-ANN-Suche, einschließlich BM25-basiertem Sparse Retrieval und Hybrid Search. Milvus 3.0 erweitert die Engine entlang einer anderen Achse: Es bringt mehr der mehrstufigen Retrieval-Pipeline in Milvus selbst und reduziert Over-Fetching, duplizierte Anwendungslogik und die Abhängigkeit von separaten Post-Processing-Diensten.

1. Serverseitiges ORDER BY: Sortieren innerhalb der Engine, pro Segment

Das Sortieren erforderte bisher, dass Anwendungen Kandidaten im Übermaß abrufen, sie zum Client übertragen und dort sortieren. Das verbrauchte Bandbreite und machte das Endergebnis davon abhängig, wo die clientseitige Kürzung stattfand.

Milvus 3.0 fügt serverseitiges ORDER BY hinzu, wodurch Query-Workloads gefilterte Zeilen nach skalaren Feldern wie Bewertung, Preis, Aktualität, Lagerbestand oder Zeitstempel sortieren können.

• Auf dem Query-Pfad sortiert jedes Segment seine gefilterte Ergebnismenge, Query-Nodes führen diese Streams zusammen, und der Proxy gibt den angeforderten Ausschnitt zurück.
• Auf dem Search-Pfad sortiert ORDER BY die ANN-Kandidatenmenge innerhalb von Milvus und reduziert so clientseitiges Over-Fetching und doppelte Nachverarbeitung. Es verändert nicht die Recall-Grenze, die durch die ANN-Kandidaten festgelegt wird.

client.query(
    collection_name="products",
    filter="category == 'shoes'",
    output_fields=["price", "rating"],
    limit=10,
    order_by=["rating:desc", "price:asc"],
)

Dies ist besonders nützlich für Suchen, die Relevanz mit geschäftlichen oder benutzerorientierten Einschränkungen wie Bewertung, Preis, Aktualität, Lagerbestand oder Zeitstempel kombinieren.

Weitere Informationen finden Sie unter Suchergebnisse nach skalaren Feldern sortieren und Abfrageergebnisse sortieren.

2. Aggregation und facettierte Suche

Milvus 3.0 fügt query-seitige Aggregation mit Operationen wie Count, Summe, Durchschnitt, Minimum und Maximum hinzu, gruppiert nach einem oder mehreren skalaren Feldern. Dadurch entfällt ein häufiges Muster, bei dem Teams gefilterte Zeilen nur deshalb in Client-Code ziehen, um zu zählen, zu gruppieren oder einfache Statistiken zu berechnen.

client.query(
    collection_name="orders",
    filter="in_stock == true",
    group_by_fields=["category"],
    output_fields=["category", "count(*)", "avg(price)", "max(rating)"],
)

Milvus 3.0 fügt außerdem Search Aggregation für facettierte Suche hinzu. Nach einer ANN-Suche gruppiert Milvus die abgerufenen Treffer nach einem Feld und gibt Bucket-Zählungen, aggregierte Statistiken und Top-N-Beispieltreffer pro Bucket zurück — das Muster hinter Gruppierungen nach Marke, Preisspanne, Farbe, Mandant oder Dokumenttyp. Eine Einschränkung: Search Aggregation arbeitet über der durch ANN abgerufenen Ergebnismenge, nicht über der gesamten Collection, daher sind Facet-Zählungen näherungsweise. Wenn exakte Zählungen benötigt werden, verwenden Sie query-seitige Aggregation.

Weitere Informationen finden Sie unter Abfrageergebnisse aggregieren.

3. StructArray für verschachtelte Vektoren und Late-Interaction-Modelle

Viele Entitäten werden natürlich durch mehrere Vektoren repräsentiert. Ein langes Dokument ist eine Reihe von Chunks; ein Video ist eine Sequenz von Frames, die man lieber in einer Zeile zusammenhält, als sie über viele zu verteilen; ein Produkt hat mehrere Bilder oder Perspektiven. Late-Interaction-Modelle treiben dies noch weiter — ColBERT erzeugt einen Vektor pro Token, ColPali einen pro visuellem Patch. In jedem Fall ist die Einheit, die Sie tatsächlich speichern und durchsuchen möchten, die gesamte Entität, nicht jedes Fragment für sich.

StructArray ermöglicht es einer Milvus-Zeile, ein Array variabler Länge aus strukturierten Elementen einschließlich mehrerer Vektoren zu enthalten, während eine einzelne Entitäts-ID und ein einziger Satz Metadaten beibehalten werden. Dadurch wird vermieden, ein Dokument in mehrere Zeilen aufzuteilen und Labels, Berechtigungen oder andere Felder über Fragmente hinweg zu duplizieren.

Milvus unterstützt zwei Suchgranularitäten.

• Element-Level-Suche gleicht einen Query-Vektor mit jedem Element in der Liste ab und gibt das spezifische passende Element mit seinem Offset zurück. Das ist nützlich, wenn man wissen möchte, welcher Chunk, welches Token, welcher Patch oder welches Bild getroffen hat. Eine Zeile kann mehr als einmal erscheinen, wenn mehrere Elemente passen.
• Entity-Level-Suche vergleicht die vollständige Vektorliste einer Query mit der Vektorliste der Zeile mithilfe von MAX_SIM und der Metrik MAX_SIM_COSINE. Jedes Query-Token nimmt seinen besten Treffer im Dokument, und diese besten Scores werden summiert. Dadurch erhält Milvus native Unterstützung für Late-Interaction-Retrieval-Muster wie ColBERT und ColPali, während eine Zeile pro Dokument beibehalten wird.

Jeden Token-Vektor zu indizieren kann teuer sein; deshalb fügt Milvus 3.0 mehrere Beschleunigungspfade hinzu, darunter TokenANN, Muvera und Lemur, die Indexgröße, Trainingskosten und Recall gegeneinander abwägen.

Strategie	Stage-One-Repräsentation	Kostenprofil	Am besten geeignet für
TokenANN	Jeder Token-Vektor wird indiziert.	Am höchsten, exakt	Modelle mit hoher Diskriminationsfähigkeit und kurze Dokumente
Muvera	Ein Vektor pro Dokument mit Random-Projection FDE.	Mittel, kein Training	Lange Dokumente
Lemur	Ein Vektor pro Dokument mit gelernter MLP-Kompression	Am niedrigsten, erfordert Training	Modelle mit geringer Diskriminationsfähigkeit und visuelle oder Patch-Vektoren

In unseren Benchmarks erreicht oder übertrifft Lemur den TokenANN-Recall auf den meisten Datensätzen, während jedes Dokument auf einen einzigen Vektor komprimiert wird; die Ausnahme sind Korpora mit hoher Längenvarianz, bei denen TokenANN oder eine andere Strategie sicherer ist.

Für Korpora, die größer als der Arbeitsspeicher sind, unterstützt Milvus außerdem einen DISKANN-Index, der Embedding-Listen auf der Festplatte hält, um den RAM-Druck zu reduzieren.

Element-Level-Suche ist bereits in Milvus 2.6 angekommen. Filtering für Muvera, Lemur und StructList ist neu in 3.0.

4. BM25-Indexkomprimierung und SINDI

Milvus hat Sparse-Vektorsuche bereits in früheren Versionen unterstützt. Milvus 3.0 reduziert den Platzbedarf des Sparse-Index durch blockkomprimierte Postings (VByte-verwandte Algorithmen plus SIMD-Dekodierung) und Quantisierung (fp16 für innere Produkte, u16 für BM25).

In einer Reihe interner BM25-Benchmarks war die neue Implementierung bei vergleichbarem Recall ungefähr 3-mal kleiner als der Sparse-Index von Milvus 2.6. Ein kleinerer Index reduziert Speicher- und Bandbreitendruck und kann die Geschwindigkeit in Workloads verbessern, die durch Datenbewegung begrenzt sind.

Milvus 3.0 führt außerdem SINDI ein, einen neuen Sparse-Retrieval-Algorithmus, der für gelernte Sparse Embeddings wie SPLADE optimiert ist. Da diese Embeddings dichtere Posting-Listen erzeugen als BM25, können pruning-intensive Suchalgorithmen erhebliche CPU-Zeit damit verbringen, zu entscheiden, was übersprungen werden soll. SINDI organisiert Postings stattdessen in kompakten Fenstern und verwendet SIMD-freundliche Score-Akkumulation, um sie effizient zu verarbeiten, während die Retrieval-Genauigkeit durch verlustfreies Pruning erhalten bleibt.

Wir haben SINDI außerdem über sein ursprüngliches Design hinaus erweitert und native BM25-Unterstützung hinzugefügt, sodass Milvus denselben optimierten Sparse-Retrieval-Pfad sowohl für gelernte Sparse Embeddings als auch für traditionelle Volltextsuche verwenden kann.

In unseren Benchmarks über 4 SPLADE-Sparse-Vektordatensätze hinweg erreicht SINDI auf Learned-Sparse-Vektoren bis zu etwa das 10-Fache der QPS von MaxScore, mit einem Worst Case von etwa dem 5-Fachen.

SINDI ist in Milvus 3.0 der Standard für Sparse-Inner-Product-Suche.

Weitere Verbesserungen

• TEXT LOB: Speichert langen Quelltext neben Vektoren. Text unter 64 KB bleibt inline; größere Werte verwenden eine Vortex-LOB-Referenz.
• Erweiterte Unterstützung für Dense-Indizes: Fügt innerhalb der Faiss-Familie weitere Indexoptionen hinzu, darunter SVS, Panorama, PQ, IVFPQ und ScaNN, für unterschiedliche Anforderungen an Skalierung, Speicher und Recall.
• MinHash und Suche nach nahezu Duplikaten: Erzeugt MinHash-Signaturen serverseitig und ruft nahezu doppelte Kandidaten mithilfe von MINHASH_LSH ab.
• Nullable Vectors und neue Typen: Ermöglicht, dass Vektorfelder NULL sind, und fügt TIMESTAMPTZ für zeitbewusste Filterung und Aufbewahrungsrichtlinien hinzu.
• Benutzerdefinierte Volltext-Wörterbücher: Registriert Wörterbücher, Synonyme und Stoppwort-Ressourcen im Cluster für mehrsprachige und domänenspezifische Tokenisierung.
• Standalone Woodpecker: Führt das Milvus Write-Ahead Log als unabhängig skalierbaren und beobachtbaren Dienst aus.
• Entity TTL****: Lässt einzelne Datensätze über ein TIMESTAMPTZ-Feld ablaufen, mit MVCC-Filterung, gefolgt von Garbage Collection während der Kompaktierung.
• ForceMerge: Kompaktiert kleine Segmente auf eine Zielgröße und baut Indizes neu auf, um Read Amplification vor dauerhaft leseintensivem Serving zu reduzieren.
• Und mehr

Erste Schritte mit Milvus 3.0

Milvus 3.0 ist ab heute unter der Apache-2.0-Lizenz verfügbar und bleibt ein LF AI & Data-Projekt. So legen Sie los:

• Lesen Sie die Release Notes und den Quickstart, und beziehen Sie den Quellcode unter github.com/milvus-io/milvus.
• Treten Sie der Milvus-Discord-Community bei oder buchen Sie eine Milvus Office Hours-Session, um Ihren Anwendungsfall mit den Maintainers zu besprechen.

Milvus 3.0 und Zilliz Vector Lakebase

Milvus 3.0 legt die Open-Source-Grundlage für produktionsreifes KI-Retrieval und die entstehende Vector-Lakebase-Architektur, die lake-nativen Speicher mit leistungsstarkem Vektor-Retrieval auf einer einzigen Source of Truth kombiniert, jeweils zu den passenden Kosten.

Zilliz Cloud ist eine vollständig verwaltete Vector Lakebase, entwickelt vom Team hinter Milvus. Sie teilt dieselbe verteilte, lake-native Architektur wie Milvus und ist vollständig mit der Milvus-API kompatibel. Angetrieben von ihrer proprietären Cardinal-Indizierungs-Engine liefert Zilliz Cloud eine bis zu 10× bessere Preis-Leistung als standardmäßige Open-Source-Indizierungsansätze und eliminiert zugleich die operative Komplexität des Infrastrukturmanagements. Enterprise-Funktionen umfassen Scale-to-Zero-Compute, regionsübergreifende Disaster Recovery, BYOC-Deployment, Sicherheit und Compliance auf Enterprise-Niveau (SOC 2, HIPAA, ISO 27001 und GDPR) sowie eine SLA von bis zu 99,99 %.

Entwickler können Milvus als Open-Source-Vektordatenbank bereitstellen oder Zilliz Cloud als verwaltete Plattform für mehrere Workloads über den gesamten KI-Datenlebenszyklus hinweg nutzen.

Was als Nächstes kommt

Die Milvus-Roadmap baut auf der 3.0-Architektur auf, mit Predicate Pushdown für External Collections, External Backfill, zusätzlichen Spark-Operatoren und Unterstützung für weitere Tabellenformate, darunter Delta Lake und Apache Paimon.

Die größere Richtung ist klar: KI-Datensysteme brauchen eine engere Schleife zwischen Online-Retrieval und Offline-Datenverbesserung. Vektordaten sollten nicht jedes Mal in separate Systeme kopiert werden müssen, wenn Teams sie durchsuchen, analysieren, verbessern oder bereitstellen möchten.