Eine Einführung in die Milvus-Architektur
In einer Umfrage unter über 1200 Nutzern haben wir eine zentrale, wiederkehrende Herausforderung festgestellt: Skalierbarkeit. Wie können wir unsere Vektoroperationen skalieren? Diese Frage führte zur Entwicklung von Milvus als verteiltem System. Vektordatenbanken haben im Gegensatz zu traditionellen Datenbanken andere Nutzungsanforderungen. Drei Hauptunterschiede motivierten uns dazu, eine cloudnative Vektordatenbank von Grund auf neu zu entwickeln.
Erstens benötigen Vektordaten keine komplexen Transaktionen.
Zweitens erfordert die Vielfalt der Anwendungsfälle einen einstellbaren Kompromiss zwischen Leistung und Konsistenz.
Drittens sind einige Vektordatenoperationen rechenintensiv, was eine elastische Ressourcenzuweisung erforderlich macht.
Milvus erreicht horizontale Skalierung durch sein bewusstes Design als verteiltes System. Während Einzelinstanz-Datenbanken bis zu einem gewissen Punkt vertikal skaliert werden können, stoßen sie bald an Hardwaregrenzen. Die horizontale Skalierungsfähigkeit von Milvus überwindet dieses Problem und ermöglicht es der Datenbank, sich über mehrere Instanzen hinweg zu erweitern. Es gibt zwei Möglichkeiten, eine Datenbank horizontal zu skalieren: die Funktionalität direkt in die Datenbank zu integrieren oder Skalierungsprozesse manuell zu implementieren.
Bei Milvus ist die Skalierungsfunktionalität in das System integriert. Zwar können Sie die Skalierung selbst übernehmen, doch ist dies keine ideale Lösung, es sei denn, Ihre geschäftskritische Arbeit umfasst das Skalieren von Datenbanken. Sehen wir uns drei Architekturen und zwei Suchdesignentscheidungen an, die Milvus so skalierbar machen.
Cloudnative Systemarchitektur
Die meisten Softwareteams stellen heute nicht mehr auf den Servern im Serverraum bereit. Warum? Die verfügbaren Public Clouds (AWS, Azure, GCP usw.) ermöglichen es Softwareteams, schneller voranzukommen. Milvus wurde entwickelt, um die Flexibilität zu nutzen, die das Arbeiten in der Cloud bietet.
Milvus besteht aus vier Schichten: Zugriff, Koordination, Worker und Speicher. Zustandslose Zugriffsknoten ermöglichen den Zugriff auf das System. Die Worker und Koordinatoren sind nach einem serverlosen Muster gestaltet. Zustandsbehaftete Koordinatoren skalieren zustandslose Worker je nach Bedarf hoch und herunter. Die Speicherschicht speichert die Vektordaten und alle notwendigen Informationen, damit das System funktioniert.
Trennung der Verantwortlichkeiten
Bei der Arbeit mit einer Vektordatenbank gibt es drei primäre Verantwortungsbereiche: Abfragen, Datenaufnahme und Indexierung. Diese drei Funktionalitäten werden sich zu unterschiedlichen Zeiten immer in unterschiedlichem Umfang skalieren lassen müssen. Milvus stellt drei verschiedene Knotentypen bereit, die unabhängig voneinander skaliert werden können.
Abfrageknoten übernehmen die Abfragefunktionalität, was bedeutet, dass sie über genügend Speicher verfügen müssen, um die In-Memory-Indizes für mehrere Segmente zu halten. Segmente sind Datenblöcke einer vordefinierten Größe, die Milvus aus Gründen der Effizienz und Skalierbarkeit verwendet. Abfrageknoten helfen auch dabei, die Suche zu parallelisieren, indem sie einen Teil ihrer Rechenleistung und ihres Speichers nutzen, um Suchergebnisse aus mehreren Segmenten zu delegieren, zu aggregieren und zu verarbeiten, von denen viele auf anderen Knoten liegen können.
Wenn Daten eingehen, gelangen sie sowohl in die Abfrage- als auch in die Datenknoten. Diese Knoten halten Daten in wachsenden Segmenten vor, die ihre Größenbegrenzung noch nicht erreicht haben. Nachdem das Segment seine Kapazität erreicht hat, gibt der Abfrageknoten diese Daten frei und ersetzt sie durch den generierten Index.
Datenknoten übernehmen die Datenaufnahme. Nachdem ein Segment bei einem Datenknoten seine Größenbegrenzung erreicht hat, wird es „versiegelt“. Versiegelte Segmente werden anschließend aus den Daten- und Abfrageknoten in den dauerhaften Speicher geschrieben. Sobald die Daten in die Speicherschicht geschrieben wurden, benachrichtigen die Koordinatoren einen Indexknoten.
Indexknoten erstellen Indizes. Wenn ein Indexknoten benachrichtigt wird, liest er das Datensegment aus der Speicherschicht. Dieser Aufbau ermöglicht es uns auf natürliche Weise, beim Erstellen des Index mit weniger Daten zu arbeiten. Da der Indexknoten Daten aus dem Speicher liest, kann er nur die Attribute lesen, die er zur Entwicklung von Indizes benötigt.
Schreibkonsistenz im großen Maßstab
Ein natürlicher Teil der Skalierung ist das Auftreten von Konsistenzproblemen. Sobald Sie die zweite Replik oder Instanz von Milvus oder eines anderen Datenbanksystems starten, stoßen Sie sofort auf ein Datenkonsistenzproblem. Sie müssen eine systemweite Übereinkunft darüber sicherstellen, wie konsistent Daten sein sollten.
Milvus verfügt über viele Optionen, um Ihre Datenkonsistenz abzustimmen, die in das System integriert sind. Milvus ist ein Pub/Sub-System. Der Nachrichtenspeicherblock fungiert als Veröffentlichungssystem und versieht jedes eingehende Datenelement mit einem Zeitstempel. Die Abfrage- und Datenknoten lesen dieses Veröffentlichungsprotokoll dann als Abonnenten.
Das Skalieren von Schreibvorgängen umfasst die Skalierung der Anzahl von Shards, die als Writer fungieren. Wenn Daten eingehen, wird ihre ID gehasht, und der Hash bestimmt, welcher Shard dieses Datenelement schreibt.
Datensegmente für parallele Suche
Wie bereits erwähnt, erstellt Milvus einzelne Indizes auf vordefinierten Datenmengen, die als „Segmente“ bezeichnet werden. Standardmäßig erstellt Milvus Segmente auf 512 MB Daten, was Sie an Ihre Anforderungen anpassen können.
Warum erstellen wir Segmente und bauen Indizes auf diese Weise? Für mehr Flexibilität, Skalierbarkeit und einfache Änderbarkeit. Indizes sind Möglichkeiten, auf Daten zuzugreifen. Stellen Sie sich vor, Sie erstellen einen Index auf einem anfänglichen Datensatz. In einem realen Szenario ändern sich Ihre Daten im Laufe der Zeit, sodass Sie weiterhin Daten hinzufügen müssen. Da der anfängliche Index nur auf den anfänglichen Daten erstellt wurde, hilft er bei den neuen Daten nicht.
Die rationale Lösung für dieses Indexierungsproblem wäre, kontinuierlich neue Indizes in einem vordefinierten Intervall zu erstellen (etwa entsprechend der Menge der neu hinzugefügten Daten). Milvus implementiert diese Lösung über mehrere Instanzen und Replikate hinweg.
Diese Segmentkonfiguration bietet eine effiziente Lösung für ineffiziente Indexierung und macht Abfragen skalierbarer. Da Indizes, die auf separaten Datensegmenten erstellt wurden, nicht voneinander abhängen, können wir sie parallel durchsuchen, nur durch die Hardware begrenzt.
Die Entscheidung für eine größere Segmentgröße erhöht die Effizienz jeder Suchoperation; es ist jedoch wichtig zu beachten, dass diese Wahl auch zu erhöhten Kosten im Zusammenhang mit Kompaktierung und Index-Neuaufbau führt.
Vorfilterung der Metadatensuche
Metadatenfilterung ist für viele Menschen eine wichtige Funktion. Mit dieser Funktion können Sie nur nach Vektoren aus bestimmten Daten, von bestimmten Autoren oder mit bestimmten Attributwerten suchen. Beim Entwerfen einer Vektorsuchanwendung können Sie die Metadatenfilterung entweder vor oder nach der Vektorsuchfunktionalität platzieren.
Vor der Durchführung einer Vektorsuche erzeugt Milvus eine Bitmaske auf den Metadaten. Diese Vorfilterungsoperation ist zeitlinear. Milvus prüft die Daten einmal und überprüft, ob die Metadaten dem bereitgestellten Filterausdruck entsprechen oder nicht. Die Vorfilterung der Metadaten verringert das Datenvolumen, das der Vektorsuche unterzogen wird, wodurch die Vektorsuchoperation effizienter wird.
In der kommenden Version Milvus 2.4 werden wir den invertierten Index mit tantivy unterstützen, und die Vorfilterungsgeschwindigkeit wird drastisch erhöht.
Zusammenfassung
Milvus verwendet eine verteilte Systemarchitektur, die aus vier Schichten besteht: Zugriff, Koordination, Worker und Speicher. Angesichts der vielfältigen Anwendungsfälle von Vektordatenbanken ist eine anpassungsfähige und sich weiterentwickelnde Infrastruktur unerlässlich. Milvus modelliert seine Datenaufnahme-Komponente entsprechend dieser Anforderung als Pub/Sub-System (Publish-Subscribe).
Die Modellierung der Datenaufnahme als Pub/Sub-Dienst bietet uns Flexibilität, indem sie ein entkoppeltes Dienstparadigma ermöglicht, und hilft bei der Datenkonsistenz. Der „Veröffentlichungs“-Dienst versieht jedes Datenelement als Teil der Konsistenzfunktionalität mit einem Zeitstempel.
Wenn es um die drei Anliegen (Abfragen, Datenaufnahme und Indexierung) in einer Vektordatenbank geht, trennt Milvus sie alle. Jede der drei Operationen verfügt über einen eigenen Knoten. Sie können die Knoten unabhängig voneinander hoch- und herunterfahren, sodass Milvus mit der Datenmenge, die Sie haben, und dem Nutzungsmuster skaliert.
Die Gewährleistung der Datenkonsistenz ist eine der anspruchsvollsten Aufgaben, wenn die Datenmenge, über die Sie verfügen, skaliert. Milvus begegnet dieser Herausforderung durch den Einsatz von „Shards“. Eingehende Daten werden gehasht und dann basierend auf ihrem Hash einem Shard zugeteilt. Milvus verfügt über eine anpassbare Konsistenz mit vier Stufen zur Auswahl, um abzuwägen, wie schnell Ihre Suche reagiert und wie schnell Daten über die vielen Instanzen der Datenbank hinweg repliziert werden.
Das Schreiben von Daten in großem Maßstab verwendet mehrere Shards. Das Lesen von Daten in großem Maßstab verwendet Segmente. Indizes werden auf einzelnen Segmenten aufgebaut. Jedes Segment kann nun zur Abfragezeit parallel durchsucht werden, wodurch die Suchzeit für große Datenmengen massiv reduziert wird.
Bei der Suche nach Daten werden Sie diese wahrscheinlich auf irgendeine Weise filtern wollen. Milvus implementiert Metadatenfilterung als Vorfilterungsoperation. Anschließend wendet es während der Vektorsuche eine Bitmaske auf den Datensatz an und überspringt alle Vektoren, die nicht passen. Dieser Ansatz kann die Suchzeit erheblich reduzieren, wenn viele Vektoren herausgefiltert werden.
Die einzigartige Architektur von Milvus bietet viele Vorteile, insbesondere horizontale Skalierung. Es ist sorgfältig als cloudnative Vektordatenbank für schnelle horizontale Skalierung bei gleichzeitiger Aufrechterhaltung optimaler Leistung konzipiert. Das bewusst entkoppelte Architekturdesign erleichtert die Weiterentwicklung von Milvus im Laufe der Zeit und ermöglicht Flexibilität. Diese Anpassungsfähigkeit erweist sich als entscheidend angesichts der zunehmenden Bedeutung von Vektordatenbanken und der wachsenden Bandbreite an Anwendungsfällen, die sie bedienen.
Weiterlesen
Introducing Zilliz Cloud Global Cluster: Region-Level Resilience for Mission-Critical AI
Zilliz Cloud Global Cluster delivers multi-region resilience, automatic failover, and fast global AI search with built-in security and compliance.
The Real Bottlenecks in Autonomous Driving — And How AI Infrastructure Can Solve Them
Autonomous driving faces a data bottleneck. Learn how AI-native vector databases like Zilliz solve scale, cost, and insight challenges across AV pipelines.
Zilliz Cloud Delivers Better Performance and Lower Costs with Arm Neoverse-based AWS Graviton
Zilliz Cloud adopts Arm-based AWS Graviton3 CPUs to cut costs, speed up AI vector search, and power billion-scale RAG and semantic search workloads.