Aufbau einer Vektordatenbank für skalierbare Ähnlichkeitssuche
Titelbild
Dieser Artikel wurde von Xiaofan Luan geschrieben und von Angela Ni und Claire Yu umgesetzt.
Statistiken zufolge sind etwa 80 bis 90 % der weltweit anfallenden Daten unstrukturiert. Aufgrund des rasanten Wachstums des Internets ist in den kommenden Jahren mit einer explosionsartigen Zunahme unstrukturierter Daten zu rechnen. Folglich benötigen Unternehmen dringend eine leistungsfähige Datenbank, die ihnen hilft, diese Art von Daten besser zu handhaben und zu verstehen. Die Entwicklung einer Datenbank ist jedoch immer leichter gesagt als getan. In diesem Artikel werden der Denkprozess und die Entwurfsprinzipien bei der Entwicklung von Milvus, einer quelloffenen, cloud-nativen Vektordatenbank für die skalierbare Ähnlichkeitssuche, vorgestellt. In diesem Artikel wird auch die Architektur von Milvus im Detail erläutert.
Springen Sie zu:
- Unstrukturierte Daten erfordern einen kompletten Basis-Software-Stack
- Die Gestaltungsprinzipien von Milvus 2.0
- Aufbau einer Vektordatenbank für skalierbare Ähnlichkeitssuche
Unstrukturierte Daten erfordern ein komplettes Basis-Softwarepaket
Mit dem Wachstum und der Entwicklung des Internets wurden unstrukturierte Daten immer häufiger, darunter E-Mails, Dokumente, IoT-Sensordaten, Facebook-Fotos, Proteinstrukturen und vieles mehr. Damit Computer unstrukturierte Daten verstehen und verarbeiten können, werden diese mithilfe von Einbettungstechniken in Vektoren umgewandelt.
Milvus speichert und indiziert diese Vektoren und analysiert die Korrelation zwischen zwei Vektoren, indem es ihren Ähnlichkeitsabstand berechnet. Wenn die beiden Einbettungsvektoren sehr ähnlich sind, bedeutet dies, dass auch die ursprünglichen Datenquellen ähnlich sind.
Der Arbeitsablauf bei der Verarbeitung unstrukturierter Daten.
Vektoren und Skalare
Ein Skalar ist eine Größe, die nur durch ein Maß - den Betrag - beschrieben wird. Ein Skalar kann als Zahl dargestellt werden. Zum Beispiel fährt ein Auto mit einer Geschwindigkeit von 80 km/h. In diesem Fall ist die Geschwindigkeit (80km/h) ein Skalar. Ein Vektor hingegen ist eine Größe, die durch mindestens zwei Größen - Betrag und Richtung - beschrieben wird. Wenn ein Auto mit einer Geschwindigkeit von 80 km/h in Richtung Westen fährt, ist die Geschwindigkeit (80 km/h West) ein Vektor. Das folgende Bild ist ein Beispiel für Skalare und Vektoren.
Skalare vs. Vektoren
Da die meisten wichtigen Daten mehr als ein Attribut haben, können wir diese Daten besser verstehen, wenn wir sie in Vektoren umwandeln. Eine gängige Methode zur Bearbeitung von Vektordaten ist die Berechnung des Abstands zwischen Vektoren mithilfe von Metriken wie Euklidischer Abstand, Inneres Produkt, Tanimoto-Abstand, Hamming-Abstand usw. Je geringer der Abstand ist, desto ähnlicher sind die Vektoren. Um einen umfangreichen Vektordatensatz effizient abzufragen, können wir Vektordaten organisieren, indem wir Indizes für sie erstellen. Nachdem der Datensatz indiziert ist, können Abfragen zu Clustern oder Teilmengen von Daten geleitet werden, die mit hoher Wahrscheinlichkeit Vektoren enthalten, die einer Eingabeabfrage ähnlich sind.
Weitere Informationen zu den Indizes finden Sie unter Vektorindex.
Von der Vektorsuchmaschine zur Vektordatenbank
Milvus 2.0 wurde von Anfang an so konzipiert, dass es nicht nur als Suchmaschine, sondern vor allem als leistungsstarke Vektordatenbank dient.
Eine Möglichkeit, den Unterschied zu verstehen, besteht darin, eine Analogie zwischen InnoDB und MySQL oder Lucene und Elasticsearch zu ziehen.
Genau wie MySQL und Elasticsearch baut auch Milvus auf Open-Source-Bibliotheken wie Faiss, HNSW und Annoy auf, die sich auf die Bereitstellung von Suchfunktionen und die Gewährleistung der Suchleistung konzentrieren. Es wäre jedoch unfair, Milvus lediglich zu einer Schicht über Faiss zu degradieren, da es Vektoren speichert, abruft, analysiert und wie jede andere Datenbank auch eine Standardschnittstelle für CRUD-Operationen bietet. Darüber hinaus verfügt Milvus über folgende Funktionen:
- Sharding und Partitionierung
- Replikation
- Wiederherstellung im Katastrophenfall
- Lastausgleich
- Abfrageparser oder -optimierer
Vektordatenbank
Für ein umfassenderes Verständnis dessen, was eine Vektordatenbank ist, lesen Sie den Blog hier.
Ein erster Cloud-nativer Ansatz
Könnte-nativer Ansatz
Von gemeinsamem Nichts zu gemeinsamem Speicher und dann zu gemeinsamem Etwas
Herkömmliche Datenbanken verwendeten eine "Shared Nothing"-Architektur, bei der die Knoten in den verteilten Systemen unabhängig, aber über ein Netzwerk verbunden sind. Die Knoten teilen sich weder Arbeitsspeicher noch Speicherplatz. Snowflake jedoch revolutionierte die Branche durch die Einführung einer "Shared-Storage"-Architektur, bei der die Rechenleistung (Abfrageverarbeitung) vom Speicher (Datenbankspeicher) getrennt ist. Mit einer Shared-Storage-Architektur können Datenbanken eine höhere Verfügbarkeit, Skalierbarkeit und eine Reduzierung der Datenduplikation erreichen. Inspiriert von Snowflake haben viele Unternehmen damit begonnen, eine Cloud-basierte Infrastruktur für die Datenpersistenz zu nutzen, während lokaler Speicher für das Caching verwendet wird. Diese Art von Datenbankarchitektur wird als "Shared Something" bezeichnet und ist heute in den meisten Anwendungen zur Standardarchitektur geworden.
Abgesehen von der "Shared Something"-Architektur unterstützt Milvus die flexible Skalierung der einzelnen Komponenten durch die Verwendung von Kubernetes zur Verwaltung der Ausführungs-Engine und die Trennung von Lese-, Schreib- und anderen Diensten durch Microservices.
Datenbank als Dienst (DBaaS)
Database as a Service ist ein heißer Trend, da sich viele Nutzer nicht nur um reguläre Datenbankfunktionalitäten kümmern, sondern sich auch nach vielfältigeren Diensten sehnen. Das bedeutet, dass unsere Datenbank neben den traditionellen CRUD-Operationen die Art der Dienste, die sie anbieten kann, erweitern muss, z. B. Datenbankmanagement, Datentransport, Abrechnung, Visualisierung usw.
Synergie mit dem breiteren Open-Source-Ökosystem
Ein weiterer Trend in der Datenbankentwicklung ist die Nutzung von Synergien zwischen der Datenbank und anderen Cloud-nativen Infrastrukturen. Im Fall von Milvus wird auf einige Open-Source-Systeme zurückgegriffen. So verwendet Milvus beispielsweise etcd für die Speicherung von Metadaten. Es verwendet auch Message Queue, eine Art asynchrone Service-to-Service-Kommunikation, die in der Microservices-Architektur verwendet wird und den Export inkrementeller Daten unterstützen kann.
Wir hoffen, Milvus in Zukunft auf KI-Infrastrukturen wie Spark oder Tensorflow aufbauen zu können und Milvus mit Streaming-Engines zu integrieren, damit wir die vereinheitlichte Stream- und Batch-Verarbeitung besser unterstützen können, um die verschiedenen Bedürfnisse der Milvus-Nutzer zu erfüllen.
Die Designprinzipien von Milvus 2.0
Milvus 2.0, unsere Cloud-native Vektordatenbank der nächsten Generation, basiert auf den folgenden drei Prinzipien.
Protokoll als Daten
Ein Protokoll in einer Datenbank zeichnet seriell alle an den Daten vorgenommenen Änderungen auf. Wie in der Abbildung unten dargestellt, sind von links nach rechts "alte Daten" und "neue Daten" zu sehen. Und die Protokolle sind in zeitlicher Reihenfolge. Milvus verfügt über einen globalen Timer-Mechanismus, der einen global eindeutigen und automatisch inkrementellen Zeitstempel zuweist.
Protokolle
In Milvus 2.0 dient der Log-Broker als Rückgrat des Systems: Alle Einfüge- und Aktualisierungsvorgänge von Daten müssen über den Log-Broker laufen, und die Arbeitsknoten führen CRUD-Operationen aus, indem sie Logs abonnieren und konsumieren.
Dualität von Tabelle und Protokoll
Sowohl die Tabelle als auch das Protokoll sind Daten, und sie sind nur zwei verschiedene Formen. Tabellen sind begrenzte Daten, während Protokolle unbegrenzt sind. Protokolle können in Tabellen umgewandelt werden. Im Fall von Milvus werden die Protokolle mit Hilfe eines Verarbeitungsfensters von TimeTick aggregiert. Auf der Grundlage der Log-Sequenz werden mehrere Logs in einer kleinen Datei zusammengefasst, die als Log-Snapshot bezeichnet wird. Anschließend werden diese Log-Snapshots zu einem Segment zusammengefasst, das individuell für den Lastausgleich genutzt werden kann.
Log-Persistenz
Die Beständigkeit von Protokollen ist eines der heiklen Probleme, mit denen viele Datenbanken konfrontiert sind. Die Speicherung von Protokollen in einem verteilten System hängt normalerweise von Replikationsalgorithmen ab.
Im Gegensatz zu Datenbanken wie Aurora, HBase, Cockroach DB und TiDB verfolgt Milvus einen bahnbrechenden Ansatz und führt ein Publish-Subscribe-System (pub/sub) für die Speicherung und Persistenz von Protokollen ein. Ein Pub/Sub-System ist vergleichbar mit der Nachrichtenwarteschlange in Kafka oder Pulsar. Alle Knoten innerhalb des Systems können die Protokolle abrufen. In Milvus wird diese Art von System als Log-Broker bezeichnet. Dank des Log-Brokers sind die Protokolle vom Server entkoppelt, wodurch Milvus selbst zustandslos ist und besser in der Lage ist, sich schnell von Systemausfällen zu erholen.
Log-Broker
Aufbau einer Vektordatenbank für skalierbare Ähnlichkeitssuche
Milvus basiert auf beliebten Vektorsuchbibliotheken wie Faiss, ANNOY, HNSW und anderen und wurde für die Ähnlichkeitssuche in dichten Vektordatensätzen mit Millionen, Milliarden oder sogar Billionen von Vektoren entwickelt.
Eigenständig und im Cluster
Milvus bietet zwei Einsatzmöglichkeiten - Standalone oder Cluster. Da bei Milvus Standalone alle Knoten gemeinsam eingesetzt werden, können wir Milvus als einen einzigen Prozess betrachten. Zurzeit stützt sich Milvus standalone auf MinIO und etcd für die Datenpersistenz und die Speicherung von Metadaten. Wir hoffen, dass wir diese beiden Abhängigkeiten von Drittanbietern in zukünftigen Versionen eliminieren können, um die Einfachheit des Milvus-Systems zu gewährleisten. Milvus-Cluster umfasst acht Microservice-Komponenten und drei Abhängigkeiten von Drittanbietern: MinIO, etcd und Pulsar. Pulsar dient als Log-Broker und bietet Log-Pub/Sub-Dienste.
Eigenständig und Cluster
Ein Grundgerüst der Milvus-Architektur
Milvus trennt den Datenfluss vom Kontrollfluss und ist in vier Schichten unterteilt, die in Bezug auf Skalierbarkeit und Notfallwiederherstellung unabhängig sind.
Milvus-Architektur
Zugriffsschicht
Die Zugriffsschicht fungiert als Gesicht des Systems und stellt den Endpunkt der Client-Verbindung nach außen hin dar. Sie ist verantwortlich für die Verarbeitung von Client-Verbindungen, die Durchführung statischer Überprüfungen, grundlegender dynamischer Überprüfungen von Benutzeranfragen, die Weiterleitung von Anfragen sowie das Sammeln und Zurücksenden von Ergebnissen an den Client. Der Proxy selbst ist zustandslos und stellt über Lastausgleichskomponenten (Nginx, Kubernetes Ingress, NodePort und LVS) einheitliche Zugangsadressen und Dienste für die Außenwelt bereit. Milvus verwendet eine MPP-Architektur (Massively Parallel Processing), bei der die Proxys die von den Arbeitsknoten gesammelten Ergebnisse nach globaler Aggregation und Nachbearbeitung zurückgeben.
Koordinator-Dienst
Der Koordinationsdienst ist das Gehirn des Systems und verantwortlich für die Verwaltung der Clustertopologie, den Lastausgleich, die Zeitstempelgenerierung, die Datendeklaration und die Datenverwaltung. Eine ausführliche Erläuterung der Funktionen der einzelnen Koordinatorendienste finden Sie in der technischen Dokumentation von Milvus.
Worker-Knoten
Der Worker- oder Ausführungsknoten fungiert als Gliedmaßen des Systems und führt die vom Koordinatordienst ausgegebenen Anweisungen und die vom Proxy initiierten DML-Befehle (Data Manipulation Language) aus. Ein Worker Node in Milvus ist vergleichbar mit einem Data Node in Hadoop oder einem Region Server in HBase. Jeder Typ von Worker Node entspricht einem Koordinationsdienst. Eine ausführliche Erläuterung der Funktionen der einzelnen Worker Nodes finden Sie in der technischen Dokumentation von Milvus.
Speicherung
Die Speicherung ist der Eckpfeiler von Milvus, der für die Persistenz der Daten verantwortlich ist. Die Speicherschicht ist in drei Teile unterteilt:
- Metaspeicher: Verantwortlich für die Speicherung von Schnappschüssen von Metadaten wie z.B. Sammelschema, Knotenstatus, Checkpoints für den Nachrichtenverbrauch, etc. Milvus verlässt sich für diese Funktionen auf Etcd, das auch die Verantwortung für die Registrierung von Diensten und die Gesundheitsprüfungen übernimmt.
- Log-Broker: Ein Pub/Sub-System, das die Wiedergabe unterstützt und für die Persistenz von Streaming-Daten, die zuverlässige asynchrone Ausführung von Abfragen, Ereignisbenachrichtigungen und die Rückgabe von Abfrageergebnissen zuständig ist. Bei der Wiederherstellung von Knoten während der Ausfallzeit stellt der Log-Broker die Integrität der inkrementellen Daten durch die Wiedergabe des Log-Brokers sicher. Der Milvus-Cluster verwendet Pulsar als Log-Broker, während im Standalone-Modus RocksDB zum Einsatz kommt. Streaming-Speicherdienste wie Kafka und Pravega können ebenfalls als Log-Broker verwendet werden.
- Objektspeicher: Speichert Snapshot-Dateien von Protokollen, Skalar-/Vektorindexdateien und Zwischenergebnisse der Abfrageverarbeitung. Milvus unterstützt AWS S3 und Azure Blob sowie MinIO, einen leichtgewichtigen Open-Source-Objektspeicherdienst. Aufgrund der hohen Zugriffslatenz und Abrechnung pro Abfrage von Objektspeicherdiensten wird Milvus in Kürze Speicher/SSD-basierte Cache-Pools und Hot/Cold-Datentrennung unterstützen, um die Leistung zu verbessern und die Kosten zu senken.
Datenmodell
Das Datenmodell organisiert die Daten in einer Datenbank. In Milvus werden alle Daten nach Sammlung, Scherbe, Partition, Segment und Entität organisiert.
Datenmodell 1
Sammlung
Eine Sammlung in Milvus kann mit einer Tabelle in einem relationalen Speichersystem verglichen werden. Die Sammlung ist die größte Dateneinheit in Milvus.
Scherbe
Um die parallele Rechenleistung von Clustern beim Schreiben von Daten voll auszunutzen, müssen Sammlungen in Milvus die Schreiboperationen auf verschiedene Knoten verteilen. Standardmäßig enthält eine einzelne Sammlung zwei Shards. Je nach Umfang Ihres Datensatzes können Sie mehr Shards in einer Sammlung haben. Milvus verwendet für das Sharding ein Master-Key-Hashing-Verfahren.
Partition
Es gibt auch mehrere Partitionen in einem Shard. Eine Partition in Milvus bezieht sich auf einen Satz von Daten, die mit dem gleichen Label in einer Sammlung markiert sind. Gängige Partitionierungsmethoden sind die Partitionierung nach Datum, Geschlecht, Alter des Benutzers und mehr. Die Erstellung von Partitionen kann für den Abfrageprozess von Vorteil sein, da riesige Daten nach Partitionskennzeichen gefiltert werden können.
Im Vergleich dazu geht es beim Sharding eher um Skalierungsmöglichkeiten beim Schreiben von Daten, während beim Partitionieren eher die Systemleistung beim Lesen von Daten gesteigert wird.
Datenmodell 2
Segmente
Innerhalb jeder Partition gibt es mehrere kleine Segmente. Ein Segment ist die kleinste Einheit für die Systemplanung in Milvus. Es gibt zwei Arten von Segmenten: wachsende und geschlossene Segmente. Wachsende Segmente werden von Abfrageknoten abonniert. Der Milvus-Benutzer schreibt ständig Daten in wachsende Segmente. Wenn die Größe eines wachsenden Segments eine Obergrenze erreicht (standardmäßig 512 MB), lässt das System das Schreiben weiterer Daten in dieses wachsende Segment nicht mehr zu und versiegelt dieses Segment. Indizes werden auf versiegelten Segmenten aufgebaut.
Um auf Daten in Echtzeit zuzugreifen, liest das System Daten sowohl in wachsenden Segmenten als auch in versiegelten Segmenten.
Entität
Jedes Segment enthält eine große Anzahl von Entitäten. Eine Entität in Milvus ist gleichbedeutend mit einer Zeile in einer herkömmlichen Datenbank. Jede Entität hat ein eindeutiges Primärschlüsselfeld, das auch automatisch generiert werden kann. Entitäten müssen auch einen Zeitstempel (ts) und ein Vektorfeld enthalten - das Herzstück von Milvus.
Über die Deep Dive-Reihe
Mit der offiziellen Ankündigung der allgemeinen Verfügbarkeit von Milvus 2.0 haben wir diese Milvus-Deep-Dive-Blogserie ins Leben gerufen, um eine eingehende Interpretation der Milvus-Architektur und des Quellcodes zu bieten. Die Themen dieser Blogserie umfassen:
- Unstrukturierte Daten erfordern ein komplettes Basis-Softwarepaket
- Die Designprinzipien von Milvus 2.0
- Über die Deep Dive-Reihe
On This Page
Try Managed Milvus for Free
Zilliz Cloud is hassle-free, powered by Milvus and 10x faster.
Get StartedLike the article? Spread the word