Von der Abfrage zu strukturierten Ergebnissen: Aggregation und ORDER BY in Milvus 3.0

Betrachten wir einen vertrauten Produktsuchablauf. Ein Käufer lädt ein Foto eines Kleides hoch, und die Vektorsuche ruft eine relevante Kandidatenmenge aus einem Katalog mit mehreren zehn Millionen Produkten ab.

Die Seite benötigt jedoch mehr als eine Rangliste. Sie braucht Markenfacetten. Sie braucht eine Preissortierung. Das Merchandising-Team möchte wissen, welche Marken diese Ergebnismenge dominieren, welche Preisspanne innerhalb jeder Marke liegt und einige repräsentative Produkte aus jeder Gruppe.

Vor Milvus 3.0 übernahmen Anwendungen diesen zweiten Schritt häufig selbst: Zeilen aus Milvus abrufen, sie in pandas oder einer Service-Schicht gruppieren und sortieren und anschließend die Antwort zusammensetzen. Einige Teams pflegten eine separate Analytics-Pipeline nur, um Zählungen und Verteilungen über Daten zu berechnen, die sich bereits in der Vektordatenbank befanden.

Die Vektordatenbank fand die Kandidaten; die Anwendung musste daraus ein strukturiertes Ergebnis machen.

Milvus 3.0 verlagert mehr von dieser Arbeit in die Retrieval-Engine. Es fügt drei verwandte, aber unterschiedliche Funktionen hinzu:

• Query-Aggregation berechnet count, sum, avg, min und max über gefilterte, sichtbare Zeilen, mit optionalen GROUP BY-Feldern.
• Search Aggregation organisiert beibehaltene Approximate-Nearest-Neighbor-(ANN-)Kandidaten in Buckets, berechnet Metriken pro Bucket, erstellt verschachtelte Buckets und gibt repräsentative Treffer zurück.
• Serverseitiges **ORDER BY** sortiert Query-Ergebnisse oder ANN-Kandidaten nach einem oder mehreren Skalarfeldern, bevor die Anwendung sie erhält.

Der Unterschied zwischen Query und Search ist wichtig:

Funktion	Zusammengefasste oder geordnete Daten	Primäre Ergebnisform	Exaktheitsgrenze
Query-Aggregation	Alle sichtbaren Zeilen, die dem Filter entsprechen	Eine Zeile pro Gruppe, mit Aggregatwerten	Exakt über die sichtbare Zeilenmenge der Query
Search Aggregation	Kandidaten, die von der ANN-Suche und der Gruppierungsstufe beibehalten werden	Buckets, Metriken, repräsentative Treffer und optionale untergeordnete Buckets	Entwurfsbedingt approximativ
Query ORDER BY	Sichtbare Zeilen, die dem Filter entsprechen	Sortierte Zeilen	Exakt über das gefilterte Query-Ergebnis
Search ORDER BY	ANN-Kandidaten	Sortierte Suchtreffer oder Gruppen	Erweitert die ANN-Recall-Grenze nicht

Dieser Artikel erklärt, warum diese Operationen in die Datenbank gehören, wie verteilte Aggregation funktioniert, wie sich Search Aggregation von Grouping Search unterscheidet und wo die neue Semantik endet.

Warum anwendungsseitige Nachverarbeitung an Grenzen stößt

Aggregation und Sortierung in die Anwendung zu verlagern, kann wie eine kleine Implementierungsentscheidung wirken. Im großen Maßstab entstehen daraus drei größere Probleme.

Die Anwendung bewegt weit mehr Daten, als die Antwort enthält

Angenommen, ein Operations-Dashboard benötigt die Produktanzahl und den Durchschnittspreis für jede Kategorie unter zwei Millionen vorrätigen Zeilen. Selbst bei einer groben Nutzlast von nur 100 Byte pro Zeile für Kategorie, Preis, Primärschlüssel und Serialisierungs-Overhead muss die Anwendung etwa 200 MB Daten empfangen, bevor sie das Ergebnis berechnen kann.

Wenn der Katalog 200 Kategorien hat, besteht die Antwort nur aus einigen hundert Schlüsseln und Zahlen – in der Größenordnung von Kilobytes. Die Anwendung bewegt mehrere Größenordnungen mehr Daten, als sie zurückgibt, zahlt bei jeder Aktualisierung dieselben Kosten und benötigt genügend Client-Speicher, um die Zwischenzeilen zu halten oder zu streamen.

Eine In-Engine-Aggregation verändert die Einheit der Datenbewegung. Rohzeilen bleiben dort, wo sie sind. Was Knoten überquert und Milvus schließlich verlässt, ist die deutlich kleinere Menge partieller und finaler Gruppenzustände.

Seitenlokales Sortieren ist kein globales Sortieren

Sortieren nach der Paginierung ist ein Korrektheitsfehler, nicht nur eine ineffiziente Implementierung.

Wenn eine Anwendung die Zeilen 11 bis 20 abruft und nur diese Zeilen nach Preis sortiert, hat sie die Preisreihenfolge innerhalb dieser Seite erzeugt – nicht die Zeilen 11 bis 20 des global nach Preis sortierten Ergebnisses. Eine spätere Seite kann Produkte enthalten, die günstiger sind als jedes Produkt auf der ersten Seite.

Dieselbe Grenze ist bei der Vektorsuche wichtig. Das Abrufen einer kleinen Top-K-Menge und deren Sortierung in der Anwendung kann nur diese Kandidaten neu anordnen. Es kann keine relevanten Kandidaten wiederherstellen, die die ANN-Stufe nicht zurückgegeben hat, und führt häufig dazu, dass Anwendungen zu viel abrufen, nur um die clientseitige Sortierung nützlich zu machen.

Serverseitige Sortierung gibt Milvus die Kontrolle über die Reihenfolge und die Paginierungssequenz. Für Query-Workloads sortiert die Engine die gefilterte Zeilenmenge, bevor sie das Seitenfenster anwendet. Für Search-Workloads sortiert sie innerhalb der ANN-Kandidatengrenze und macht diese Einschränkung explizit.

Der Client kann die Datenbanksichtbarkeit nicht reproduzieren

Aggregation hängt auch davon ab, welche Zeilen zum Query-Zeitstempel sichtbar sind. Löschungen, abgelaufene Entitäten und gleichzeitige Schreibvorgänge werden durch Milvus’ Multiversion Concurrency Control (MVCC) und Konsistenzsemantik geregelt.

Sobald Rohzeilen die Datenbank verlassen, geht die Anwendung normalerweise davon aus, dass der empfangene Batch den korrekten Snapshot repräsentiert. Dieselben Sichtbarkeitsregeln in einem Client nachzubilden, ist unpraktikabel, insbesondere während die Collection Schreib- und Löschvorgänge erhält.

Der übliche Workaround – eine zweite Analytics-Engine, die per Export und ETL gespeist wird – fügt eine weitere Kopie der Daten, eine weitere Konsistenzgrenze und eine weitere zu betreibende Pipeline hinzu. Zählungen, Metriken und Sortierungen sollten dort ausgeführt werden, wo sowohl die Daten als auch ihre Sichtbarkeitsregeln bereits existieren.

Schauen wir uns nun an, was Milvus 3.0 bietet.

Query-Aggregation: exakte Statistiken über sichtbare Zeilen

Query-Aggregation beantwortet Fragen wie:

• Wie viele vorrätige Produkte gibt es in jeder Kategorie?
• Wie hoch ist der Durchschnittspreis pro Marke?
• Was sind die minimalen und maximalen Ereigniszeitstempel für jeden Host?
• Wie viele Datensätze bleiben übrig, nachdem ein Filter und TTL-Sichtbarkeit angewendet wurden?

Die API wirkt vertraut für alle, die SQL verwendet haben: Übergeben Sie ein oder mehrere Felder in group_by_fields und platzieren Sie anschließend Aggregationsausdrücke in output_fields.

res = client.query(
    collection_name="products",
    filter='status == "on_sale"',
    group_by_fields=["category"],
    output_fields=["category", "count(*)", "avg(price)"],
)
# [
#     {"category": "books", "count(*)": 18734, "avg(price)": 45.3},
#     …
# ]

Die Syntax ist der einfache Teil. Das Ausführungsmodell macht das Ergebnis in einer verteilten Vektordatenbank nützlich.

Segmentlokale Zustände ersetzen die Bewegung von Rohzeilen

Eine Milvus-Collection kann sich über Hunderte oder Tausende von Segmenten erstrecken, die über mehrere Query Nodes verteilt sind, wobei kürzlich geschriebene Daten noch auf dem Streaming-Pfad liegen. Kein einzelner Ausführungsknoten beginnt mit jeder sichtbaren Zeile.

Milvus schiebt Aggregation daher bis zu den Segmenten hinunter:

1. Jedes Segment wendet den Filter und die MVCC-Sichtbarkeitsregeln lokal an.
2. Das Segment gibt einen partiellen Zustand pro Gruppe aus statt seiner passenden Zeilen.
3. Partielle Zustände werden innerhalb eines Query Nodes zusammengeführt.
4. Der Proxy führt die finale knotenübergreifende Zusammenführung durch und gibt die vollständigen Gruppen zurück.

Die Menge der Zwischendaten skaliert nun mit der Anzahl der Gruppen und Aggregatzustände, statt direkt mit der Anzahl der passenden Zeilen.

Die Merge-Operation hängt vom Aggregat ab:

Aggregat	Partieller Zustand	Merge-Regel
count	Partielle Zählung	Zählungen addieren
sum	Partielle Summe	Summen addieren
min	Partielles Minimum	Das Minimum nehmen
max	Partielles Maximum	Das Maximum nehmen
avg	Partielle Summe und Zählung	Beide Zustände addieren, dann erst in der finalen Stufe dividieren

avg ist der anschauliche Fall. Zwei partielle Durchschnitte zu mitteln ist falsch, wenn die Partitionen unterschiedliche Zeilenzahlen enthalten. Milvus führt sum und count unabhängig voneinander mit und berechnet den finalen Durchschnitt erst, nachdem beide global zusammengeführt wurden.

Dies ist ein Grund, warum Aggregation in die Datenbank gehört: Die Operation ist nicht einfach „dieselbe Funktion auf mehreren Batches ausführen“. Die Engine muss die Algebra jedes Aggregats über Segment- und Knotengrenzen hinweg bewahren.

Sichtbarkeit wird vor der Aggregation angewendet

Gelöschte und abgelaufene Zeilen werden gemäß der Sichtbarkeitsgrenze der Query auf Segmentebene aus den partiellen Zuständen entfernt. Sie wandern nicht nach oben, um dann in der Anwendung korrigiert zu werden.

Das Ergebnis beschreibt daher die Zeilen, die Milvus für diese Anfrage als sichtbar betrachtet, nicht eine beliebige Sammlung von Batches, die zu leicht unterschiedlichen Zeiten abgerufen wurden.

limit zählt jetzt Gruppen

In einer normalen Query steuert limit, wie viele Entitätszeilen zurückgegeben werden. In einer gruppierten Query steuert es, wie viele Gruppen zurückgegeben werden. Da die Ergebniskardinalität durch Gruppen statt durch passende Zeilen bestimmt wird, kann eine Query-Aggregation limit auch weglassen, wenn sie jede Gruppe benötigt.

Das klingt nach einem kleinen API-Detail, spiegelt aber ein anderes Ergebnismodell wider: Die Ausgabe ist nicht länger eine Seite von Entitäten. Sie ist eine Relation, deren Zeilen Gruppen repräsentieren.

Search Aggregation: eine Bucket-Ansicht von ANN-Kandidaten

Query-Aggregation beantwortet: „Wie sehen die sichtbaren Zeilen aus, die diesem Filter entsprechen?“ Search Aggregation stellt eine andere Frage: „Wie sieht die für diesen Vektor abgerufene Kandidatenmenge aus?“

Diese Operation hat kein exaktes SQL-Äquivalent. Die ANN-Suche legt zunächst eine ähnlichkeitsgetriebene Kandidatengrenze fest. Milvus organisiert die beibehaltenen Kandidaten dann nach Skalar-Schlüsseln und gibt einen Bucket-Baum statt einer gewöhnlichen flachen Trefferliste zurück.

Ein Bucket kann enthalten:

• einen Schlüssel wie brand oder einen zusammengesetzten Schlüssel wie (brand, color);
• eine Anzahl beibehaltener Kandidaten;
• Metriken einschließlich count, sum, avg, min und max;
• repräsentative Entitäten, ausgewählt mit top_hits; und
• eine verschachtelte sub_aggregation, die untergeordnete Buckets erstellt.

Für die Produktsuchseite kann eine Anfrage Marken-Buckets, den Durchschnittspreis innerhalb jedes Buckets und drei repräsentative Produkte pro Marke zurückgeben:

from pymilvus import SearchAggregation, TopHits
aggregation = SearchAggregation(
fields=[“brand”],
size=10,                                    # Return up to 10 brand buckets
metrics={“avg_price”: {“avg”: “price”}},
order=[{“_count”: “desc”}],               # Order by retained-candidate count
top_hits=TopHits(
size=3,
sort=[{“_score”: “desc”}],            # Use “asc” for L2 distance
),
)
res = client.search(
collection_name=“products”,
data=[query_vector],
anns_field=“embedding”,
search_aggregation=aggregation,
output_fields=[“title”, “brand”, “price”],
)
buckets = res.agg_buckets[0]

Wenn search_aggregation gesetzt ist, ist die gewöhnliche Trefferliste leer. Die Anwendung liest die Bucket-Antwort aus result.agg_buckets.

Die Aggregationsspezifikation setzt zwei unterschiedliche Grenzen

Search Aggregation führt kein GROUP BY über jede Entität in der Collection aus, und sie nimmt auch nicht einfach eine gewöhnliche Top-K-Antwort und aggregiert diese flache Liste.

Ihre Ausführung hat drei Stufen:

1. Milvus führt eine ANN-Suche aus, um Kandidaten in der Nähe des Query-Vektors abzurufen.
2. Die Gruppierungsstufe behält eine begrenzte Anzahl von Kandidaten für jeden vollständigen Bucket-Schlüssel bei.
3. Milvus erstellt Buckets, berechnet Metriken über die beibehaltenen Kandidaten, ordnet die Buckets und hängt repräsentative Treffer oder untergeordnete Buckets an.

Zwei Parameter steuern unterschiedliche Teile des Ergebnisses:

• SearchAggregation.size begrenzt, wie viele Buckets auf dieser Aggregationsebene zurückgegeben werden.
• Die größte TopHits.size irgendwo im Aggregationsbaum legt das Budget beibehaltener Kandidaten für jeden vollständigen zusammengesetzten Schlüssel fest. Wenn die Anfrage kein top_hits enthält, ist das Standardbudget pro Schlüssel eins.

Das limit der Top-Level-Suche steuert diesen Modus nicht und wird ignoriert, wenn search_aggregation vorhanden ist.

Diese Unterscheidung ist wesentlich, wenn man count oder Metriken eines Buckets liest. Mit TopHits(size=3) kann ein Marken-Bucket höchstens drei beibehaltene Kandidaten für seinen vollständigen Schlüssel zusammenfassen, selbst wenn die Collection Tausende relevanter Produkte dieser Marke enthält. Eine Erhöhung von TopHits.size erweitert das Metrikfenster pro Schlüssel, verwandelt die ANN-Suche aber nicht in einen exakten Scan.

Wenn die Anwendung exakte Statistiken über jede sichtbare Zeile benötigt, die einem Filter entspricht, sollte sie Query-Aggregation verwenden. Search Aggregation dient dazu, die von der Ähnlichkeitsabfrage erzeugten Kandidaten zu beschreiben und zu vergleichen.

Search Aggregation und Grouping Search lösen unterschiedliche Probleme

Milvus unterstützt Grouping Search (group_by)seit Milvus 2.4. Es ist leicht, das Wort „Grouping“ in beiden Funktionen zu sehen und anzunehmen, sie seien zwei Schnittstellen für dieselbe Operation. Ihre Ausgabeverträge sind unterschiedlich.

Grouping Search ändert, welche Entitäten in einer gerankten Ergebnisliste erscheinen. Ein gängiges RAG-Muster speichert Chunks als einzelne Entitäten, gruppiert sie nach doc_id und gibt einen oder wenige Chunks aus jedem Dokument zurück. Die primäre Ausgabe bleiben gewöhnliche Suchtreffer, jedoch mit weniger wiederholten Werten aus dem Gruppierungsfeld.

Search Aggregation gibt eine statistische Ansicht zurück. Die primäre Ausgabe ist ein Bucket-Baum mit Schlüsseln, Zählungen, Metriken, repräsentativen Treffern und optionalen untergeordneten Buckets.

Anwendungsbedarf	Bevorzugt	Konsumieren
Eine gerankte Entitätenliste mit größerer Vielfalt über ein Feld hinweg	Grouping Search	Gewöhnliche Suchtreffer
Facettenzählungen, Metriken pro Gruppe, repräsentative Treffer oder verschachtelte Verteilungen	Search Aggregation	AggregationBucket-Objekte in result.agg_buckets

Eine praktische Regel ist, von der UI- oder API-Antwortform auszugehen. Wenn die Anwendung eine Liste rendert, ist Grouping Search normalerweise das richtige Primitiv. Wenn sie Facetten, Verteilungskarten oder eine Gruppenhierarchie rendert, verwenden Sie Search Aggregation.

Die beiden Modi schließen sich in einer Anfrage gegenseitig aus, da sie unterschiedliche primäre Ergebnisformen definieren.

ORDER BY: Sortierung vor die Anwendungsgrenze verlagern

Sortierung ist die am wenigsten exotische Funktion in diesem Release und eine der am leichtesten falsch außerhalb der Engine zu implementierenden.

Milvus 3.0 stellt Sortierung sowohl für Query als auch für Search bereit, aber die beiden Pfade verwenden unterschiedliche SDK-Parameter und arbeiten über unterschiedliche Eingabemengen.

Query-Sortierung ordnet die gefilterte Zeilenmenge

PyMilvus Query verwendet order_by, ausgedrückt als Liste von "field:direction"-Strings. Die Engine wendet den Filter an, ordnet die sichtbaren Zeilen und wendet anschließend limit und offset an.

res = client.query(
    collection_name="products",
    filter='category == "books"',
    output_fields=["title", "price"],
    order_by=["price:desc", "title:asc"],
    limit=10,
    offset=10,  # Rows 11-20 in the filtered, price-sorted result
)

Das macht Query nützlich für geschäftlich sortiertes Browsing: neueste ingestierte Datensätze, höchstpreisige Produkte innerhalb eines Filters, niedrigster Bestand oder Extremwerte zur Dateninspektion. Ohne serverseitige Sortierung mussten Anwendungen zuerst Zeilen abrufen und konnten keine verlässliche Geschäftsreihenfolge über Seiten hinweg definieren.

Bei nullable Query-Feldern platziert aufsteigende Sortierung Nullwerte zuletzt und absteigende Sortierung zuerst. Ein Sortierfeld muss nicht in output_fields erscheinen; nehmen Sie es nur auf, wenn die Anwendung den Wert in der Antwort benötigt.

Search-Sortierung ordnet die ANN-Kandidatenmenge neu

PyMilvus Search verwendet order_by_fields, wobei jeder Eintrag ein Skalarfeld und eine Richtung benennt:

res = client.search(
    collection_name="products",
    data=[query_vector],
    anns_field="embedding",
    limit=50,
    output_fields=["title", "price"],
    order_by_fields=[
        {"field": "price", "order": "asc"},
    ],
)

ANN bestimmt weiterhin, welche Entitäten zu Kandidaten werden. order_by_fields ändert, wie diese Kandidaten zurückgegeben werden; es bewirkt nicht, dass die Suche die Collection global nach den günstigsten Produkten scannt.

Diese Grenze gibt den beiden APIs unterschiedliche Aufgaben:

• Verwenden Sie Query plus order_by, wenn die Skalarreihenfolge selbst das Ergebnis definiert, etwa die zehn günstigsten vorrätigen Produkte.
• Verwenden Sie Search plus order_by_fields, wenn semantische oder Vektorrelevanz die Kandidatenmenge definiert und ein Skalarfeld bestimmt, wie diese Kandidaten präsentiert werden sollen.

Mehrfeldsortierung wendet Schlüssel in Listenreihenfolge an. Wenn Suchkandidaten für jeden angegebenen Skalar-Schlüssel dieselben Werte haben, behält Milvus ihre ursprüngliche Ähnlichkeits-Score-Reihenfolge bei.

Sortierung lässt sich auch mit Grouping Search kombinieren. Milvus ordnet Gruppen nach dem konfigurierten Skalarwert aus der Top-Entität jeder Gruppe, während die gruppierte Ergebnisform erhalten bleibt. Das ist nützlich, wenn die Anwendung sowohl Vielfalt über ein Feld hinweg als auch eine geschäftlich relevante Gruppenreihenfolge möchte.

Was diese Funktionen ermöglichen

Die APIs sind allgemeine Datenbankprimitive, aber mehrere Retrieval-Workloads profitieren unmittelbar.

RAG und Agents: Retrieval-Konzentration prüfen

Ein RAG- oder agentisches System kann abgerufene Chunks nach Quelldokument, Produktlinie, Tenant oder Inhaltstyp in Buckets einteilen. Ein Ergebnis, das sich auf zwei Dokumente konzentriert, trägt ein anderes Abdeckungssignal als eines, das über Dutzende von Quellen verteilt ist.

Diese Verteilung ist keine Garantie für Antwortqualität. Sie ist jedoch eine nützliche Retrieval-Diagnose, die eine Anwendung oder ein Agent mit Scores, Zitaten und anderen Prüfungen kombinieren kann, wenn entschieden wird, ob die Query erweitert, erneut abgerufen oder um Klärung gebeten werden soll.

Grouping Search bleibt die richtige Wahl, wenn das Ziel lediglich darin besteht, die zurückgegebenen Chunks zu diversifizieren. Search Aggregation ist nützlich, wenn das System die Verteilung selbst benötigt.

E-Commerce und Content-Empfehlung: Facetten mit der Suche zurückgeben

Die eingangs beschriebene Produktsuchseite kann Marken-Buckets, Preismetriken, repräsentative Artikel und eine skalar sortierte Kandidatenliste von Milvus erhalten. Die Anwendung steuert weiterhin Darstellung und Geschäftslogik, muss aber grundlegende Bucket-Semantik nicht mehr aus exportierten Treffern rekonstruieren.

Logs und Sicherheit: Ähnlichkeit mit Incident-Verteilung kombinieren

Ähnlichkeitssuche kann Ereignisse finden, die mit einer verdächtigen Log-Zeile zusammenhängen. Search Aggregation kann dann zeigen, welche Hosts diese Kandidaten dominieren, welche minimalen und maximalen Zeitstempel in jedem Host-Bucket liegen oder wie sich die Kandidaten über Schweregrad und Service verteilen.

Das Ergebnis bleibt eine Ansicht abgerufener Kandidaten statt einer exakten globalen Incident-Zählung. Wenn die Untersuchung exakte Zählungen über jedes Ereignis benötigt, das einem Filter entspricht, bietet Query-Aggregation diesen zweiten Pfad.

Operations und Datenerkundung: berechnen statt exportieren

Dashboards und Verwaltungstools können exakte Zählungen und Durchschnitte über gefilterte Zeilen ausführen und anschließend die zugrunde liegenden Entitäten in einer definierten Skalarreihenfolge durchsuchen. Das entfernt viele einmalige „exportieren, berechnen und sortieren“-Utilities, ohne vorzugeben, Milvus sei zu einer vollständigen analytischen Datenbank geworden.

Grenzen: was Aggregation und ORDER BY nicht ersetzen

Diese Funktionen erweitern die Retrieval-Engine; sie verwandeln Milvus nicht in ein Online Analytical Processing-(OLAP-)System.

• Query-Aggregation unterstützt Gruppierung plus count, sum, avg, min und max. Sie fügt keine Joins, Window Functions oder komplexen Subqueries hinzu. Große Offline-Analytics-Jobs gehören weiterhin in Systeme wie Spark, die mit Milvus-3.0-Snapshots und gemeinsamen Speicherpfaden arbeiten können.
• Query-Gruppenschlüssel unterstützen Integer-, VARCHAR- und TIMESTAMPTZ-Felder. Search-Aggregation-Bucket-Schlüssel unterstützen zusätzlich Boolean-Felder. Gleitkomma-, Vektor-, JSON- und Array-Werte sind keine Bucket-Schlüssel.
• Für Search Aggregation akzeptiert count "*" oder eine Nicht-JSON-, nicht dynamische Quelle; sum und avg erfordern numerische Quellen; und min und max unterstützen auch String- und TIMESTAMPTZ-Quellen. Query-Aggregation folgt denselben arithmetischen Typgrenzen. Konsultieren Sie den API-Leitfaden, bevor Sie ein Aggregat auf einen komplexen Feldtyp anwenden.
• Query-Aggregation kann gruppierte Ausgabe nach Gruppenschlüsseln ordnen, während die Ordnung nach einem berechneten Aggregat wie count(*) eine aktuelle Grenze bleibt. Ohne explizite Ordnung ist die Gruppenreihenfolge nicht garantiert.
• Search Aggregation kann derzeit nicht mit Hybrid Search, Grouping Search, Search Iterators, einem Offset ungleich null oder Highlighting in derselben Anfrage kombiniert werden.
• Zählungen und Metriken von Search Aggregation beschreiben beibehaltene ANN-Kandidaten, nicht die vollständige Collection und nicht jede Entität, die semantisch relevant sein könnte.
• Search ORDER BY ändert die Kandidatenpräsentation. Es repariert keine verfehlten ANN-Kandidaten und wandelt Ähnlichkeits-Retrieval nicht in eine exakte skalare Top-N-Query um.

Der sauberste Weg, zwischen den neuen Primitiven zu wählen, ist, mit der Frage zu beginnen:

• Für exakte Statistiken über gefilterte sichtbare Zeilen verwenden Sie Query-Aggregation.
• Für eine Verteilung über Ähnlichkeits-Retrieval-Kandidaten verwenden Sie Search Aggregation.
• Für eine vielfältige Rangliste verwenden Sie Grouping Search.
• Für eine definierte Skalarreihenfolge verwenden Sie Query oder Search ORDER BY, je nachdem, welcher Pfad die Ergebnismenge festgelegt hat.

Von Kandidatenlisten zu strukturierten Ergebnissen

Vektordatenbanken haben traditionell eine Frage optimiert: Welche K Entitäten liegen diesem Vektor am nächsten?

Produktions-Retrieval-Systeme stellen unmittelbar Anschlussfragen. Welche Gruppen dominieren das Ergebnis? Wie lauten ihre Zählungen und Bereiche? Welche Beispiele repräsentieren jede Gruppe? In welcher Geschäftsreihenfolge sollte die Anwendung die Zeilen oder Kandidaten präsentieren?

Milvus 3.0 bringt diese Operationen in dieselbe Engine, der die Daten, die ANN-Kandidatengrenze und die Sichtbarkeitssemantik gehören. Query-Aggregation führt exakte verteilte Reduktion über sichtbare Zeilen aus. Search Aggregation erstellt eine Bucket-Ansicht über beibehaltene ANN-Kandidaten. ORDER BY gibt Query- und Search-Pfaden eine serverseitige Skalarreihenfolge, ohne die Anwendung aufzufordern, sie Seite für Seite zu rekonstruieren.

Das Ergebnis ist keine OLAP-Engine, die in einer Vektordatenbank versteckt ist. Es ist eine Retrieval-Engine, die mehr von der Struktur zurückgeben kann, die Anwendungen tatsächlich benötigen.

Aggregation und ORDER BY in Milvus 3.0 ausprobieren

Milvus 3.0 ist jetzt verfügbar. Nutzen Sie den Query-Leitfaden für exakte Aggregation und Query-Sortierung, den Search-Aggregation-Leitfaden für Bucket-Semantik und Limits, den Basic-Vector-Search-Leitfaden für Search-Sortierung und den Grouping-Search-Leitfaden, wenn Ihr primäres Ziel Ergebnisvielfalt ist.

Für das umfassendere Release lesen Sie den Milvus-3.0-Launch-Blog, die Milvus-3.0-Release Notes und das milvus-io/milvus-Repository.

Wenn Sie dieselben APIs evaluieren möchten, ohne den Cluster selbst zu betreiben, probieren Sie sie auf Zilliz Cloud aus. Die aktuelle Zilliz-Cloud-Query-Referenz und Search-Referenz beschreiben Verfügbarkeit und Parameter für verwaltete Clustertypen.

Um einen Workload oder einen Edge Case mit dem Team zu besprechen, treten Sie der Milvus-Discord-Community bei oder buchen Sie eine Milvus-Office-Hours-Sitzung.