Milvus Externe Kollektion: Lake-residente Daten indizieren und abrufen, ohne sie zu verschieben

In vielen KI-Pipelines werden Embeddings und Metadaten bereits erzeugt und in einem Data Lake gespeichert. Eine Produktpipeline könnte Produktattribute und multimodale Embeddings als Parquet-Dateien in S3 schreiben. Ein Retrieval- oder Trainingskorpus könnte in einer Iceberg- oder Lance-Tabelle leben. Der Lake ist bereits dort, wo diese Datensätze erzeugt, aktualisiert, versioniert und vom restlichen Daten-Stack verwendet werden.

Vektordatenbanken hingegen wurden traditionell um eine von der Datenbank verwaltete Serving-Kopie herum aufgebaut. Wenn Teams eine Vektorsuche mit geringer Latenz über Daten benötigten, die bereits in einem Lake lagen, hatten sie in der Regel zwei Optionen:

• Die Daten in eine Vektordatenbank kopieren. Dies bietet ANN-Indizes und einen produktiven Serving-Pfad, erzeugt aber eine zweite Kopie des Datensatzes und eine ETL-Pipeline, die mit der Quelle synchronisiert bleiben muss.
• Den Lake direkt abfragen. Dies vermeidet Duplikate, aber ohne eine ANN-Indizierungs- und Serving-Schicht fällt die Vektorsuche auf Scans zurück, die nicht für Produktionslatenzen ausgelegt sind.

Milvus 3.0 External Collection führt einen dritten Weg ein. Die Quelldaten bleiben in Parquet, Iceberg, Lance, Vortex oder einem anderen unterstützten externen Format, während Milvus darauf Indizes aufbaut und diese bereitstellt. Sie mappen die externen Felder in ein Milvus-Schema, definieren die benötigten Indizes, aktualisieren die Collection und verwenden die normalen Milvus-Such- und Abfrage-APIs – ohne die Quelldatenzeilen zuvor in eine von Milvus verwaltete Collection zu kopieren.

Die architektonische Änderung ist klar: Die Daten können im Lake verbleiben, während Milvus die Indizierungs- und Retrieval-Schicht hinzufügt.

Das macht External Collection auch zu einem wichtigen Schritt in Richtung Vector Lakebase, einer einheitlichen, lake-nativen Datenarchitektur für KI, die Serving auf dem Niveau einer Vektordatenbank mit offenem Lake-Speicher, wiederverwendbaren Indizes auf Lake-Ebene und einer gemeinsamen semantischen Schicht verbindet. Online-Retrieval muss nicht länger mit einer separaten Serving-Kopie beginnen, während Spark, Trainingspipelines, Evaluierungsaufträge und Governance-Tools mit einer anderen Version der Daten arbeiten. Sie können von derselben lake-residenten Datenbasis aus arbeiten.

Was eine External Collection ist und was sie verändert

Eine External Collection ist eine Art von Milvus-Collection, deren Quelldaten außerhalb des von Milvus verwalteten Speichers leben.

Ohne eine External Collection bedeutet es, diesen Katalog hinter einer produktiven Vektorsuche zu platzieren, normalerweise, eine weitere Kopie in Milvus zu erstellen:

Jedes Mal, wenn sich der Katalog ändert, sich das Embedding-Modell ändert oder ein Feld nachträglich befüllt wird, muss eine weitere Pipeline die aktualisierten Daten über diese Grenze bewegen.

Mit External Collection wird die Architektur zu:

Milvus macht keine eigene Quell-Datenkopie aus externen Dateien. Stattdessen enthält die External Collection die Informationen, die Milvus benötigt, um diese zu interpretieren und zu durchsuchen:

1. Eine external_source, die die externen Dateien oder die Tabelle identifiziert.
2. Eine external_spec, die das Quellformat und den Speicherzugriff beschreibt.
3. external_field-Zuordnungen, die Felder im Milvus-Schema mit Spalten im externen Datensatz verbinden.
4. Die Indizes, Manifeste und Serving-Zustände, die Milvus für das Retrieval erstellt.

Null-Kopie der Quelldaten bedeutet nicht null Zustand in Milvus. Milvus baut weiterhin Indizes auf. Es verwendet weiterhin Rechenressourcen. Es cached weiterhin Daten. Die Änderung besteht darin, dass die maßgeblichen Zeilen nicht mehr in Milvus kopiert werden müssen, nur weil Sie Milvus benötigen, um nach ihnen zu suchen.

Normale Milvus-Collection vs. External Collection

Aspekt	Von Milvus verwaltete Collection	External Collection
Quelldatensätze	Von Milvus gespeichert und verwaltet	Verbleiben in den externen Dateien oder der Tabelle
Wie Daten in Milvus gelangen	Insert, Upsert, Import oder Streaming-Write	Externe Quellzuordnung + Refresh
Online-Mutationen	Unterstützt	Von Milvus aus schreibgeschützt
Aktualität	Folgt dem Milvus-Schreibpfad und Konsistenzmodell	Folgt dem zuletzt erfolgreich veröffentlichten Refresh
Von Milvus verwalteter Zustand	Quelldaten, Metadaten, Indizes, Caches	Zuordnungen, Manifeste, Indizes, Caches
Abfragepfad	Milvus-Such- und Abfrage-APIs	Milvus-Such- und Abfrage-APIs
Bester Einsatzbereich	Kontinuierlich wechselnde Online-Daten	Große, in Batches erzeugte, leseintensive Lake-Daten

External Collection ergänzt daher normale Milvus-Collections, anstatt sie zu ersetzen.

Ein System kann schnell wechselnde Online-Zustände in normalen Milvus-Collections halten, während es External Collections für große Korpora, Kataloge, historische Datensätze, Modell-Features oder andere Daten verwendet, die bereits im Lake erzeugt und verwaltet werden.

Warum das Entfernen der zweiten Kopie wichtig ist

Es ist verlockend, External Collections als Speicheroptimierung zu beschreiben: Kopieren Sie nicht mehrere Terabyte an Daten in eine andere Datenbank, und Sie sparen Speicher. Das ist nützlich, aber es ist nicht das Hauptproblem der Architektur.

Die höheren Kosten entstehen dadurch, dass zwei Datensysteme abgeglichen werden müssen.

Betrachten wir erneut den Produktkatalog. Die Datenplattform erzeugt den maßgeblichen Parquet-Datensatz. Die Suche importiert ihn in eine Vektordatenbank. Ein Empfehlungsteam könnte dieselben Lake-Daten über Spark für Offline-Analysen lesen. Ein neues Embedding-Modell erzeugt dann eine Ersatz-Vektorspalte. Inventar und Metadaten ändern sich gleichzeitig kontinuierlich.

Sobald die Online-Serving-Kopie unabhängig vom Lake wird, muss jede Änderung diese Grenze überqueren:

• die Daten müssen kopiert werden;
• die Übertragung muss geplant und überwacht werden;
• fehlgeschlagene Aufträge benötigen Wiederholungen;
• Schemas und Berechtigungen müssen möglicherweise in mehreren Systemen abgebildet werden;
• die Aktualität hängt davon ab, wie schnell die Synchronisierungspipeline aufholt;
• Teams müssen wissen, welche Kopie die Version darstellt, die sie tatsächlich möchten.

Speicher ist nur eine Kostenposition.

Kosten	Separater Lake + Serving-Kopie	External Collection
Kopien der Quelldaten	Lake-Kopie plus eine separate Serving-Kopie	Quellzeilen verbleiben im Lake
Datenbewegung	Permanente ETL-/Import-Pipeline	Refresh über die externe Quelle
Aktualität	Hängt vom Export-/Import-Rhythmus ab	Gesteuert durch die Veröffentlichung eines neuen Refresh
Governance	Quell- und Serving-Kopien müssen abgeglichen bleiben	Quelleneigentum, Herkunft und Versionierung verbleiben bei der Lake-Plattform
Offline-Wiederverwendung	Andere Konsumenten erstellen möglicherweise eigene Kopien	Bestehende Lake-Tools können weiterhin dieselbe Quelle lesen
Serving-Ressourcen	Dimensioniert um die Datenbankkopie und das Abfrageaufkommen	Indizierung, Abfrage-Rechenleistung und Caches können getrennt vom Eigentum an den Quellzeilen verwaltet werden

Der Unterschied wird besonders wichtig, wenn sich KI-Daten häufiger ändern.

Teams deduplizieren Korpora. Sie clustern Daten für Analysen. Sie erzeugen neue Embeddings, wenn sich ein Modell ändert. Sie fügen Labels, Zusammenfassungen, extrahierte Entitäten, Qualitätswerte oder Feedback-Signale hinzu. Sie führen Evaluierungsaufträge und Datenbereinigungspipelines über denselben Korpus aus, aus dem Produktionsanwendungen abrufen.

Wenn jedes System seine eigene Kopie besitzt, wird jede Verbesserung zu einem weiteren Synchronisierungsauftrag.

External Collection verändert diese Grenze: Offline-Systeme können weiterhin am Lake-Datensatz arbeiten, während Milvus Retrieval auf derselben Grundlage bereitstellt.

Welche Datenquellen External Collection unterstützt

External Collection ist für offene, extern verwaltete Daten konzipiert und nicht für ein Milvus-spezifisches Quellformat. Es unterstützt mehrere externe Quellformate über Storage V3:

Externes Format	format-Wert	Was Milvus liest
Apache Parquet	parquet	Ein Verzeichnis oder Objektspeicher-Präfix, das Parquet-Dateien und Zeilengruppen enthält
Vortex	vortex	Vortex-Dateien und ihre Layout-Metadaten
Lance	lance-table	Einen Lance-Datensatz und seine Fragment-Metadaten
Apache Iceberg	iceberg-table	Iceberg-Metadaten plus einen ausgewählten Snapshot
Milvus-Snapshot	milvus-table	Einen unterstützten Milvus-Snapshot, der als externe Quelle bereitgestellt wird

Die Zuordnung zwischen Quelle und Milvus ist explizit.

Eine Quellspalte namens product_id kann zum Milvus-Feld id werden; image_vec kann zu embedding werden; und eine breite Quelltabelle muss nicht jede Spalte für die Collection bereitstellen. Das bedeutet, dass die Datenplattform ihre Quelle nicht umbenennen oder umschreiben muss, nur um die Serving-Datenbank zufriedenzustellen.

Versionierte Formate fügen eine weitere nützliche Eigenschaft hinzu. Mit einer Quelle wie Iceberg kann die Collection auf einen bestimmten Snapshot zeigen, anstatt auf das, was zum Zeitpunkt der Abfrage gerade aktuell ist. Eine feste Quellversion ist nützlich für reproduzierbare Evaluierung, Regressionstests, historische Analysen und Audit-Arbeitslasten.

Die zugrunde liegenden Dateien bleiben auch für den Rest des Daten-Stacks nutzbar. Spark, Trainings-Frameworks, Governance-Systeme und andere lake-kompatible Tools können weiterhin dieselben offenen Daten lesen.

External Collection fügt einen weiteren Konsumenten dieser Daten hinzu; es macht Milvus nicht zu deren alleinigem Eigentümer.

Sicherer Zugriff auf externen Speicher

Milvus benötigt außerdem die Berechtigung, den externen Speicher zu lesen.

Abhängig vom Speicheranbieter können Bereitstellungen Mechanismen wie Workload- oder Instanzidentität, AWS-STS-Rollenannahme, Dienstkonten-Impersonation, SAS-basierten Zugriff oder anbieterspezifische Rollensysteme verwenden, anstatt langlebige Anmeldeinformationen in der Anwendungskonfiguration zu hinterlegen.

Diese Speicheridentität steuert, wie Milvus die Quelle erreicht. Die Autorisierung innerhalb von Milvus bleibt eine separate Sicherheitsgrenze.

So erstellen, indizieren, aktualisieren und durchsuchen Sie eine External Collection

Der Lebenszyklus einer External Collection hat vier Hauptschritte:

1. Definieren Sie die externe Quelle und mappen Sie ihre Spalten in ein Milvus-Schema.
2. Definieren Sie die Indizes, die die Arbeitslast benötigt.
3. Führen Sie Refresh aus, damit Milvus die Quelldaten erkennt und eine abfragbare Version vorbereitet.
4. Laden Sie die Collection und verwenden Sie die normalen Milvus-Such- und Abfrage-APIs.

Hier ist derselbe Produktkatalog als External Collection dargestellt:

import json
import time
from pymilvus import DataType, MilvusClient
client = MilvusClient(
uri=“http://localhost:19530”,
token=“root:Milvus”,
)
schema = client.create_schema(
external_source=“s3://my-lake/datasets/products/”,
external_spec=json.dumps(
{
“format”: “parquet”,
“extfs”: {
“cloud_provider”: “aws”,
“region”: “us-east-1”,
“use_iam”: “true”,
“iam_endpoint”: “https://sts.us-east-1.amazonaws.com”,
},
}
),
)
schema.add_field(
field_name=“id”,
datatype=DataType.INT64,
external_field=“product_id”,
)
schema.add_field(
field_name=“embedding”,
datatype=DataType.FLOAT_VECTOR,
dim=768,
external_field=“image_vec”,
)
schema.add_field(
field_name=“title”,
datatype=DataType.VARCHAR,
max_length=256,
external_field=“product_name”,
)
schema.add_field(
field_name=“stock”,
datatype=DataType.INT64,
external_field=“stock”,
)
schema.add_field(
field_name=“rating”,
datatype=DataType.FLOAT,
external_field=“rating”,
)
client.create_collection(
collection_name=“products_ext”,
schema=schema,
)

Indizes verwenden die normale Milvus-Schnittstelle:

index_params = client.prepare_index_params()
index_params.add_index(
    field_name="embedding",
    index_type="HNSW",
    metric_type="COSINE",
)
index_params.add_index(field_name="stock", index_type="AUTOINDEX")
index_params.add_index(field_name="rating", index_type="AUTOINDEX")
client.create_index(
collection_name=“products_ext”,
index_params=index_params,
)

Danach die externe Quelle aktualisieren:

job_id = client.refresh_external_collection(
    collection_name="products_ext",
)
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(2)

Sobald die aktualisierte Version bereit ist, laden und durchsuchen Sie sie wie eine normale Milvus-Collection:

client.load_collection("products_ext")
results = client.search(
collection_name=“products_ext”,
data=[query_vec],
anns_field=“embedding”,
filter=“stock > 0 and rating >= 4.0”,
limit=10,
output_fields=[“id”, “title”, “stock”, “rating”],
)

Der wichtige Unterschied liegt nicht im Suchaufruf. Er liegt darin, wo der Lebenszyklus beginnt. Eine von Milvus verwaltete Collection beginnt damit, dass Daten in Milvus geschrieben oder importiert werden. Eine External Collection beginnt mit einem Verweis auf Daten, die bereits anderswo existieren.

Wie Refresh Änderungen in externen Daten erkennt

External Collection ist von der Milvus-Seite aus schreibgeschützt, aber der zugrunde liegende Lake-Datensatz muss nicht für immer eingefroren bleiben.

Angenommen, die Produktpipeline fügt einen weiteren Batch hinzu, aktualisiert Metadaten oder schreibt Embeddings aus einem neuen Modell. Milvus verfolgt nicht kontinuierlich jedes Objekt, das im Quellpfad erscheint. Diese Änderungen werden über Refresh sichtbar.

Refresh liest die externen Metadaten, löst die Quellfragmente auf, aktualisiert die Manifeste, die sie mit der Milvus-Collection verbinden, und bereitet den entsprechenden Indexzustand vor.

Der Schlüssel ist, dass diese Arbeit inkrementell sein kann.

Milvus identifiziert Quellfragmente, die sich nicht geändert haben, und kann deren vorhandene Segment- und Indexarbeit wiederverwenden. Neue oder geänderte Fragmente sind die Teile, die neue Verarbeitung erfordern.

Eine kleine Änderung an einem Multi-Terabyte-Datensatz muss daher keinen weiteren vollständigen Import und vollständigen Index-Neuaufbau auslösen.

Refresh gibt dem Serving-System auch eine klare Versionsgrenze. Während eine neue Version vorbereitet wird, verwenden Abfragen weiterhin den zuvor veröffentlichten Zustand. Sobald Refresh abgeschlossen ist, wird der neue Zustand als vollständige Version verfügbar, anstatt eine Mischung aus alten und teilweise vorbereiteten Daten bereitzustellen.

Dieses Modell passt natürlich zu stündlichen Katalog-Builds, nächtlichen Wissensdatenbank-Updates, periodischen Embedding-Aktualisierungen, modellgenerierten Feature-Pipelines und ähnlichen batch-orientierten Arbeitslasten.

Es ersetzt keinen Streaming-Schreibpfad. Wenn jeder Insert oder Delete sofort über Milvus durchsuchbar sein muss, bleibt eine verwaltete Collection das bessere Modell.

Wie Lazy Loading den Speicherbedarf für breite Datensätze reduziert

Quellzeilen im Objektspeicher zu belassen, hilft nur, wenn die Serving-Schicht nicht jedes Byte lokal laden muss, bevor sie Abfragen beantworten kann. Mit aktiviertem Milvus Tiered Storage ist das nicht der Fall.

Beim Laden der Collection können QueryNodes zunächst nur leichtgewichtige Metadaten wie Schema-Informationen, Indexdefinitionen, Chunk-Maps und Verweise auf entfernte Objekte behalten. Felddaten werden auf Chunk-Ebene abgerufen, wenn eine Abfrage sie benötigt; Indizes können bis zur ersten Verwendung entfernt bleiben und dann lokal gecacht werden. Häufig verwendete Daten bleiben heiß, während weniger häufig aufgerufene Daten aus dem Cache entfernt werden können.

Dies ist besonders nützlich für breite KI-Datensätze.

Eine Produktzeile könnte mehrere Embeddings, eine lange Beschreibung, rohes JSON, Bildmetadaten, generierte Zusammenfassungen, Inventar, Preise, Bewertungen und viele andere Attribute enthalten. Eine typische Ähnlichkeitssuche berührt möglicherweise nur einen Vektor plus Inventar, Preis und Bewertung. Es gibt keinen Grund, warum jedes andere Feld dauerhaft Serving-Speicher belegen muss, nur weil es zum selben Datensatz gehört.

External Collection kann den Serving-Fußabdruck auf zwei Ebenen verkleinern:

• Erstens, Schema-Projektion. Über external_field kann die External Collection nur die Quellspalten bereitstellen, die die Anwendung benötigt. Andere Spalten verbleiben im Lake-Datensatz und sind nicht in diesem Serving-Schema enthalten.
• Zweitens, Laufzeit-Projektion. Im tiered Serving-Modell rufen QueryNodes die Felder und Indizes ab und cachen sie, die die Arbeitslast tatsächlich benötigt, anstatt den gesamten gemappten Datensatz im Voraus zu laden.

Mit anderen Worten: Der Datensatz kann im Lake breit bleiben, ohne dass der Serving-Fußabdruck ebenso breit sein muss.

Es gibt einen offensichtlichen Kompromiss. Eine Abfrage, die auf ein kaltes Feld oder einen kalten Index trifft, kann beim ersten Zugriff mit einem Remote-Read verbunden sein. Aufwärmrichtlinien können latenzkritische Felder oder Indizes vorabladen, während Cache- und Eviction-Richtlinien verhindern, dass weniger häufig verwendete Zustände lokale Ressourcen dauerhaft belegen.

Der Punkt ist nicht, dass sich Objektspeicher wie RAM verhält. Es geht darum, dass Speicher und lokaler Speicher dem Arbeitsset der Retrieval-Arbeitslast folgen können, anstatt der Gesamtgröße und -breite des Quelldatensatzes.

Das Quellformat spielt hier ebenfalls eine Rolle. Formate, die für breite analytische Scans entwickelt wurden, und Formate, die für schmalere oder zufällige Lesezugriffe optimiert sind, können beim On-Demand-Zugriff unterschiedliches I/O-Verhalten erzeugen. External Collection löscht diese Speicher-Kompromisse nicht; es lässt Milvus eine Retrieval-Schicht darauf aufbauen.

Welche Such- und Indizierungsfunktionen External Collection unterstützt

External Collection zeigt Milvus nicht einfach auf ein Verzeichnis mit Embeddings und scannt die Dateien durch. Milvus baut Retrieval-Strukturen auf externen Daten auf und führt Abfragen über seine standardmäßige Retrieval-Engine aus.

Milvus-Indizes, die über externen Daten aufgebaut werden

Je nach Feldern und Arbeitslast kann Milvus Folgendes aufbauen:

• Vektorindizes für die ANN-Suche;
• Skalarindizes für Metadaten-Filterung;
• JSON-Indizes für semistrukturierte Attribute;
• BM25- und Volltextindizes für lexikalisches Retrieval.
• Funktionsgenerierte Felder, die vom Milvus-Datenmodell unterstützt werden.

Die ANN-Suche verwendet diese Indizes, um den Kandidatensatz einzugrenzen, anstatt jeden Quellvektor zu lesen.

Diese Unterscheidung ist wichtig, denn ein Embedding in einem Lake zu speichern ist nicht dasselbe wie eine Vektordatenbank darüber zu betreiben. Persistenz gibt Ihnen Bytes. Produktives Retrieval benötigt auch Indizes, Abfrageplanung, Filterung, Ranking, Caching und einen Serving-Pfad mit geringer Latenz.

Über Vektor-Top-K hinaus

Ein weiterer häufiger Fehler ist, „External Collection" als „Vektorsuche über Parquet" zu lesen. Das verkauft das, was produktives Retrieval tatsächlich erfordert, unter Wert.

Ein Produktionssuchergebnis hängt selten allein von der Vektorähnlichkeit ab. Es kann auch von exakten Begriffen, Zugriffsrichtlinien, Inventar, Zeitstempel, Kategorie, Preis, Quellqualität oder geschäftlichen Ranking-Signalen abhängen.

Betrachten wir eine Abfrage wie:

rotes Blumenkleid für den Sommer, auf Lager, höchste Bewertung zuerst

Ein produktiver Retrieval-Pfad benötigt möglicherweise mehrere Signale:

• Vektorähnlichkeit für die semantische Bedeutung von „sommerliches Blumenkleid".
• Lexikalische oder Volltextsuche für einen exakten Begriff wie „rot".
• Skalarfilter, um Produkte zu entfernen, die nicht auf Lager sind oder unter einer Bewertungsschwelle liegen.
• Hybrides Retrieval und Ranking, um mehrere Retrieval-Signale zu kombinieren.

Milvus 3.0 erweitert die Abfrage-Engine außerdem über die initiale Nachbarschaftssuche hinaus um Funktionen wie serverseitige Sortierung, Aggregation und Facettierung.

Der übergreifende Punkt ist, dass External Collection lake-residenten Daten einen Datenbank-Retrieval-Pfad gibt – nicht nur eine Möglichkeit, Vektoren aus Dateien zu lesen.

Wie dieselben Lake-Daten Online-Serving und Offline-Verarbeitung unterstützen

Der stärkste architektonische Grund, die Quelle in einem offenen Lake-Format zu belassen, ist nicht einfach, dass eine zweite Kopie Geld kostet. Es ist, dass derselbe Datensatz für die Systeme verfügbar bleiben kann, die ihn kontinuierlich verbessern.

Gehen wir zurück zum Produktkatalog.

Tagsüber kann Milvus eine External Collection für Produktsuche, Empfehlungen oder Agenten-Retrieval bereitstellen.

Gleichzeitig können andere Systeme direkt am Lake-Datensatz arbeiten:

• Spark kann doppelte Produkte identifizieren.
• Eine Trainingspipeline kann Embeddings aus einem neuen Modell erzeugen.
• Ein Datenqualitätsauftrag kann fehlerhafte oder anomale Datensätze erkennen.
• Eine Evaluierungspipeline kann die Retrieval-Qualität zwischen Modellversionen vergleichen.
• Ein Batch-Prozess kann Zusammenfassungen, Labels oder zusätzliche Metadaten erzeugen.

External Collection führt diese Aufträge nicht selbst aus. Spark bleibt Spark; Training bleibt Training. Seine Rolle besteht darin, die zusätzliche Serving-Datengrenze zwischen ihnen zu entfernen.

Offline-Arbeit kann verbesserte Daten oder neue Felder zurück in den Lake schreiben. Ein anschließender Refresh macht die aktualisierte Quelle für den Milvus-Retrieval-Pfad verfügbar.

Es gibt keine separate Export-Import-Schleife, deren einziger Zweck darin besteht, eine weitere maßgebliche Kopie für das Serving zu rekonstruieren.

Auch die Governance bleibt klar getrennt. Quellversionen, Herkunft und Quelleneigentum verbleiben bei der Lake-Plattform. Milvus pflegt seine eigene Autorisierung auf Collection-Ebene und die Anmeldeinformationen, die zum Lesen der Quelle erforderlich sind. Eine gemeinsame Datenbasis zu teilen bedeutet nicht, jede Sicherheitsdomäne in ein einziges System zu kollabieren.

Dies ist die Verbindung zu Vector Lakebase: Der Lake bleibt die gemeinsame Datenbasis, während Milvus eine Retrieval-Schicht mit geringer Latenz darüber bereitstellt. External Collection ist ein Teil dieser Architektur, neben Storage V3, Snapshots, Spark-Integration, Schema-Evolution und Backfill.

Wo External Collection passt – und wo nicht

External Collection ist eine gute Wahl, wenn:

• Ihre maßgeblichen Daten bereits in Parquet, Vortex, Lance, Iceberg oder einer anderen unterstützten externen Quelle vorliegen.
• Der Datensatz hauptsächlich in Batches erzeugt wird und nicht durch hochfrequente transaktionale Schreibvorgänge.
• Das Pflegen einer zweiten Serving-Kopie erheblichen ETL-, Aktualitäts- oder Governance-Aufwand erzeugt.
• Mehrere Systeme mit demselben offenen Datensatz arbeiten müssen.
• Eine explizite Refresh-Grenze für die Serving-Aktualität akzeptabel ist.
• Sie produktives Milvus-Retrieval wünschen, ohne dass Milvus der Eigentümer der Quellzeilen wird.

Eine normale Milvus-Collection ist weiterhin die bessere Wahl, wenn:

• die Anwendung kontinuierlich Datensätze einfügt oder aktualisiert;
• Löschungen über den Online-Schreibpfad sichtbar werden müssen;
• die Arbeitslast von Collection-Funktionen abhängt, die für externe Schemas nicht verfügbar sind;
• das Serving-Design absichtlich alle erforderlichen Daten im Speicher hält, um Remote-Cache-Misses zu vermeiden.

Mehrere Grenzen sollten Sie im Hinterkopf behalten.

• External Collections sind schreibgeschützt. Quelländerungen finden außerhalb von Milvus statt.
• Null-Kopie gilt für Quellzeilen. Indizes, Manifeste, Caches und Rechenleistung kosten weiterhin Ressourcen.
• Refresh ist explizit. Es ist kein Streaming-Synchronisierungsmechanismus.
• Die Quelle muss erreichbar bleiben. Such-, Index- und Refresh-Verhalten hängen weiterhin von Speicherzugriff und Anmeldeinformationen ab.
• Storage V3 ist erforderlich. In Open-Source-Milvus 3.0 muss es vor der Verwendung von External Collection aktiviert sein.
• External Collection ersetzt keine vorgelagerte Verarbeitung. Embedding-Erzeugung, Clustering, Deduplizierung und Datenbereinigung finden weiterhin in den geeigneten vorgelagerten Systemen statt.

Die Wahl ist daher komplementär und nicht binär. Ein System kann normale Milvus-Collections für sich schnell ändernde Online-Zustände verwenden und External Collections für große, in Batches erzeugte Datensätze, deren natürlicher Ort der Lake ist.

Testen Sie External Collection in Milvus 3.0

External Collection ist in Milvus 3.0 verfügbar. Beginnen Sie mit einem repräsentativen Lake-Datensatz und bewerten Sie die Aspekte, die für Ihre Arbeitslast wichtig sind: initialer und inkrementeller Refresh, Indexaufbaukosten, Verhalten bei warmen und kalten Abfragen sowie das Aktualitätsintervall, das Ihre Anwendung benötigt.

Implementierungsdetails finden Sie unter:

• Eine External Collection erstellen
• Milvus-3.0-Versionshinweise
• Milvus-3.0-Start-Blog

Wenn Sie einen verwalteten Weg bevorzugen, ist External Collection auch als Teil von Zilliz Vector Lakebase in Zilliz Cloud verfügbar. Siehe:

• External Collection in Zilliz Cloud
• Von der Vektordatenbank zu Vector Lakebase
• Warum wir Vector Lakebase gebaut haben: Unstrukturierte Datenarchitektur für KI neu denken

Sie können Implementierungsfragen oder Feedback auch an das Milvus-GitHub-Repository oder die Milvus-Discord-Community richten.