Versionshinweise
Erfahren Sie, was es Neues bei Milvus gibt! Auf dieser Seite finden Sie eine Übersicht über neue Funktionen, Verbesserungen, bekannte Probleme und Fehlerbehebungen in jeder Version. Wir empfehlen Ihnen, diese Seite regelmäßig zu besuchen, um sich über Updates zu informieren.
v3.0-beta
Veröffentlichungsdatum: 9. Mai 2026
| Milvus-Version | Python-SDK-Version | Node.js-SDK-Version |
|---|---|---|
| 3.0-beta | 3.0.0 | 3.0.0 |
Milvus 3.0-beta erweitert die Milvus-Vektordatenbank um eine neue Integration in das Open-Lake-Ökosystem: Mit „External Collection“ kann Milvus externe Lake-Tabellen ohne Kopieren abfragen, und Spark kann Milvus-Sammlungen direkt über Snapshot lesen. Die Version bietet außerdem umfangreichere Abfragefunktionen, ein ausdrucksstärkeres Schema, tiefgreifendere Anpassungsmöglichkeiten für die Textsuche, feinere Steuerungsmöglichkeiten für den Daten- und Modelllebenszyklus sowie mehr Steuerungsmöglichkeiten auf der Operatorseite. Milvus 3.0 ist der Kern von Zilliz Lakebase und unterstützt dessen einheitliche Bereitstellung, Erkennung und Batch-Verarbeitung.
Sehen Sie sich das folgende Video an, um mehr über Milvus 3.0 und das AMA mit den Hauptentwicklern zu erfahren:
Wichtigste Funktionen
Externe Sammlung
In typischen KI-Datenpipelines befinden sich bereits Terabytes an Embeddings und Metadaten als Parquet-, Lance- oder Iceberg-Tabellen im Objektspeicher. Das Kopieren dieser Daten in Milvus verdoppelt die Speicherkosten, erfordert eine ETL-Pipeline, die synchronisiert werden muss, und entzieht dem Kunden die Kontrolle über die Datenverwaltung.
Die externe Sammlung macht das Kopieren überflüssig. Eine Milvus-Sammlung kann auf Dateien verweisen, wo diese bereits gespeichert sind, und Milvus verwaltet nur das Schema, die Indizes und die Abfrageausführung. Eine inkrementelle Aktualisierung sorgt dafür, dass die Sammlung mit den zugrunde liegenden Dateien synchron bleibt. Kunden, deren Daten den Lake nicht verlassen dürfen, wie beispielsweise Teams aus den Bereichen Finanzen und Gesundheitswesen, können Vektorabfragen für diese Daten direkt an ihrem Speicherort durchführen. Ein einzelner, im Lake befindlicher Datensatz kann auch von mehreren Milvus-Instanzen gleichzeitig bereitgestellt werden.
Weitere Informationen finden Sie unter „Externe Sammlung erstellen“.
Snapshot
Für die Bereitstellung und die Batch-Erkennung wird oft dieselbe Collection gleichzeitig benötigt. A/B-Modellbewertung, groß angelegte Deduplizierung, Backfill-Validierung und Versions-Rollback erfordern alle eine stabile Ansicht der Collection, während weiterhin Schreibvorgänge stattfinden.
Snapshot erstellt eine zeitpunktbezogene, schreibgeschützte Ansicht einer Collection, indem es auf vorhandene Segmente verweist, anstatt Daten zu kopieren, sodass die marginalen Speicherkosten nahezu null sind. Batch-Jobs können unter MVCC-ähnlicher Isolation aus dem Snapshot lesen, während die Live-Collection weiterhin Schreibvorgänge akzeptiert.
Weitere Informationen finden Sie unter „Snapshots“, „Snapshots verwalten“ und „Anwendungsfälle für Snapshots“.
Abfrage / Suche nach Reihenfolge
Suche und Abfrage unterstützen nun die Sortierung nach mehreren Feldern, wobei die Sortierung in den Milvus-Kernel verlagert wird und „ ASC “ sowie „ DESC “ pro Feld einstellbar sind. Dies schließt eine häufige Lücke in der Produktion: „Top-K“ allein nach Entfernung entspricht oft nicht den geschäftlichen Anforderungen, wenn das ähnlichste Element nicht das günstigste, das neueste oder das beliebteste ist.
Anwendungen müssen nun nicht mehr übermäßig viele Ergebnisse abrufen und auf dem Client neu sortieren, um ein zusammengesetztes Ranking darzustellen.
Weitere Informationen finden Sie unter „Sortieren von Suchergebnissen nach skalaren Feldern “ und „Sortieren von Abfrageergebnissen“.
Abfrageaggregation
Um Statistiken zur Mandantenverteilung, Zählungen zur Feldvollständigkeit oder den Fortschritt bei der Versionsbereitstellung aus einer Milvus-Sammlung zu erstellen, mussten bisher passende Entitäten zurück auf den Client geladen und dort aggregiert werden. Milvus 3.0 integriert die skalare Aggregation im SQL-Stil in den Kernel. Ein Abfrageaufruf akzeptiert „ group_by_fields “ und Aggregationsausdrücke in „ output_fields “, einschließlich „ count(*) “, „ count(<field>) “, „ sum(<field>) “, „ avg(<field>) “, „ min(<field>) “ und „ max(<field>) “. Die Aggregation wird nach dem Filtern serverseitig ausgewertet.
Weitere Informationen finden Sie unter Aggregieren von Abfrageergebnissen.
Null-Vektor
Einbettungen werden oft asynchron erzeugt, sodass eine Entität vor ihrem Vektor eintreffen kann. Auch multimodale Daten weisen natürliche Lücken auf, wie beispielsweise ein Video ohne Untertitel oder ein Produkt ohne Bild. Frühere Versionen hatten keine gute Lösung: Anwendungen verzögerten entweder das Schreiben, bis der Vektor bereit war, oder füllten einen Platzhaltervektor ein, wobei beide Optionen die Abfragequalität beeinträchtigten.
Milvus 3.0 unterstützt NULL in Vektorfeldern für alle sechs Vektortypen. Die Suche überspringt NULL-Vektoren automatisch, die Abfragequalität bleibt unbeeinträchtigt, und NULL-Vektoren beanspruchen praktisch keinen Speicherplatz. Die „ AddField “ erstreckt sich im Rahmen dieser Änderung auch auf Vektorfelder: Mit „ nullable=True “ kann eine bestehende Sammlung online neue Vektorfelder hinzufügen, ohne neu aufgebaut werden zu müssen.
Weitere Informationen finden Sie unter „Nullable Fields“.
Benutzerdefiniertes Wörterbuch & Synonymwörterbuch
Standard-Tokenizer erfüllen nicht immer die Anforderungen an die Suchqualität in der Produktion. Chinesisch, vertikale Domänen wie Medizin, Recht und Chemie sowie mehrsprachige Korpora können erheblich von benutzerdefinierten Wörterbüchern und Synonymtabellen profitieren. Bislang wurden diese Ressourcen meist als anwendungsseitige Abfrageumschreibungen bereitgestellt.
Milvus 3.0 führt einen FileResource-Mechanismus ein, um benutzerdefinierte Tokenizer-Wörterbücher, Synonymlisten, Stoppwortlisten und Regeln zur Zerlegung von zusammengesetzten Wörtern zu registrieren. Nach der Registrierung kann eine Ressource von jedem Tokenizer oder Filter aus referenziert werden und wirkt sich auf BM25, Analysatoren und Text Match aus. Wörterbücher und Synonyme können nun zentral verwaltet und versioniert werden, anstatt über den Anwendungscode verstreut zu sein.
Weitere Informationen finden Sie unter „Dateiressourcen verwalten“.
Entity-TTL
TTL auf Collection- und Partitionsebene sind für viele Lebenszyklus- und Compliance-Szenarien zu grob. Verschiedene Mandanten innerhalb derselben Collection haben oft unterschiedliche Aufbewahrungsregeln, und einzelne Entitäten müssen möglicherweise nach einem Zeitplan ablaufen, der nicht mit dem Rest der Collection übereinstimmt.
Milvus 3.0 unterstützt TTL auf Entitätsebene. Deklarieren Sie ein Feld „ TIMESTAMPTZ “ im Schema, kennzeichnen Sie es über eine Collection-Eigenschaft als TTL-Feld, und Milvus entfernt abgelaufene Entitäten automatisch. Dies deckt Anträge auf das Recht auf Vergessenwerden, das Ablaufen von Sitzungsdaten und begrenzte Konversationshistorien ab, ohne dass eine Bereinigung auf Anwendungsseite erforderlich ist.
Weitere Informationen finden Sie unter „TTL auf Entitätsebene festlegen“.
MinHash DIDO (Doc-in, Doc-out)
Milvus 2.6 führte den „ MINHASH_LSH “-Index für die setbasierte Erkennung von Beinahe-Duplikaten ein, doch Anwendungen mussten weiterhin MinHash-Signaturen berechnen, bevor Daten in Milvus geschrieben wurden.
Milvus 3.0 führt eine serverseitige MinHash-Funktion ein. Deklarieren Sie im Schema ein Eingabefeld „ VARCHAR “ und ein Ausgabefeld „ BINARY_VECTOR “, fügen Sie eine Funktion „ FunctionType.MINHASH “ hinzu, und Milvus berechnet die Signaturen während des Einfügens, des Masseneinfügens und der Suche. Zusammen mit „ MINHASH_LSH “ unterstützt dies Deduplizierungs-Workflows für große Datensätze, Fingerprinting und Plagiatserkennung innerhalb von Milvus.
Weitere Informationen finden Sie unter MinHash-Funktion.
EmbList + DISKANN
Die Annahme „eine Entität = ein Vektor“ passt nicht mehr zur modernen Suche. Lange Dokumente werden in viele Teile aufgeteilt, Modelle mit später Interaktion wie ColBERT geben einen Vektor pro Token aus, und multimodale Entitäten können mehrere Ansichten enthalten.
EmbList speichert eine Vektorliste variabler Länge pro Entität, wobei „ DISKANN “ als On-Disk-Index dient. Der Speicherpfad hält den RAM-Verbrauch unter Kontrolle, wenn der Korpus die Speichergrenzen überschreitet. EmbList + „ DISKANN “ ist die erste Variante der umfassenderen StructList-Familie in diesem RC. Der Rest der Familie, einschließlich StructList-Filterung und Muvera-/Lemur-Multivektor-Beschleunigung, ist für die offizielle Version 3.0 vorgesehen.
Weitere Informationen finden Sie unter „Suche mit Embedding-Listen“.
Force Merge
In Produktionsumgebungen kommt es im Laufe der Zeit zu einer zunehmenden Segmentfragmentierung, was zu Schwankungen bei der Abfragelatenz und einem erhöhten Speicherbedarf führt.
Milvus 3.0 bietet die Möglichkeit, die Segmentkomprimierung während Zeiten mit geringer Auslastung explizit auszulösen, sowohl im synchronen als auch im asynchronen Modus.
Weitere Informationen finden Sie unter „Force Merge Compaction“.
Storage V3
Milvus 3.0 führt Storage V3 ein, eine manifestbasierte spaltenorientierte Speicher-Engine, bei der Daten und Metadaten auf S3-kompatiblem Objektspeicher liegen. Jede Datensatzversion wird als unveränderlicher Manifest-Snapshot erfasst, eine Avro-kodierte Datei, die festhält, aus welchen Spaltengruppen, Delta-Logs und Statistiken der Datensatz besteht.
Manifeste sind kompakte Avro-Dateien, und Delta-Logs zeichnen Löschungen auf Entitätsebene auf, ohne Datendateien neu zu schreiben. Dadurch bleibt der Metadaten-Overhead gering, auch wenn Datensätze wachsen. Das Manifest entkoppelt zudem die Metadatenverfolgung vom Abfragepfad, sodass eine Collection mehr Segmente verwalten kann, ohne die Abfrageleistung zu beeinträchtigen.
Da Zustände im Objektspeicher abgelegt werden, ist der Datensatz selbstbeschreibend: Jeder Leser mit Zugriff auf den Speicherpfad kann ihn ohne zentralen Katalog erkennen und interpretieren. Diese Eigenschaft bildet die Grundlage für die Integration von External Collection, Snapshot und zukünftigen Lake-Integrationen.