Konsistenzmodelle für Vektordatenbanken verstehen
Verteilte Systeme für Ihre Vektorsuchanwendungen werden unverzichtbar – von Skalierbarkeit und Fehlertoleranz bis hin zu verbesserter Leistung und globaler Zugänglichkeit. Die grundlegenden Prinzipien, die verteilte Systeme zum Rückgrat widerstandsfähiger, leistungsstarker Anwendungen machen, erfordern, dass wir Konsistenz-, Verfügbarkeits- und Latenz-Trade-offs berücksichtigen.
Zum Beispiel ist Konsistenz für bestimmte Vektorsuch-Anwendungsfälle in Ihrer verteilten Anwendung entscheidend. Wäre es nicht ärgerlich, wenn Sie Daten abfragen, von denen Sie erwarten, dass sie vorhanden sind, die aber nicht da sind? Das würde passieren, wenn Ihre Daten nicht über alle Replikate hinweg konsistent wären, die Sie in Ihren verteilten Systemen haben. Oberflächlich betrachtet klingt es einfach. Natürlich sollten meine Daten da sein, nachdem ich sie dort abgelegt und über mehrere Knoten repliziert habe. Aber wann sollten sie da sein? Wie stellen Sie das sicher?
Als Antwort auf das Konsistenzproblem bietet die vollständig verteilte Milvus-Vektordatenbank Tunable Consistency. Milvus verfügt über eine einzigartige Architektur, die es Ihnen ermöglicht, die Art und Weise, wie Sie Ihre Daten schreiben, horizontal zu skalieren und Konsistenz sicherzustellen, ohne zusätzliche Tools verwenden zu müssen. Durch die Nutzung einer verteilten Infrastruktur ist Milvus ein lose gekoppeltes Pub-Sub-System, was bedeutet, dass Konsistenz einfach über Zeitstempel verwaltet und abgestimmt werden kann.
In diesem Artikel betrachten wir:
Was ist Konsistenz?
- Konsistenzanforderungen von Vektordatenbanken
Konsistenz, Verfügbarkeit und Partitionen
Welche Konsistenzstufen bietet Milvus?
Eventual Consistency
Session Consistency
Bounded Consistency
Strong Consistency
Zusammenfassung zum Verständnis von Konsistenz für Vektordatenbanken
Was ist Konsistenz?
Eine der Definitionen von Konsistenz ist „das Erreichen eines Leistungsniveaus, das im Laufe der Zeit qualitativ nicht stark variiert.“ In Bezug auf Konsistenz für Ihre verteilte Datenbank bedeutet dies, dass Sie die genauesten und aktuellsten Daten erhalten, nach denen Sie fragen. Deshalb bietet Milvus die Möglichkeit, Ihre Konsistenz darauf abzustimmen, wie aktuell die Daten sein müssen, auf die Sie zugreifen möchten.
Verschiedene Arten von Datenbanken haben zusätzliche Konsistenzanforderungen. Nicht-relationale Datenbanken haben beispielsweise oft „eventual“ oder gelockerte ACID-Anforderungen (Atomicity, Consistency, Isolation und Durability). Bei der Arbeit mit NoSQL-Datenbanken erhalten Sie möglicherweise teilweise aktualisierte Daten.
Andererseits haben ACID-konforme SQL-Datenbanken wie Postgres andere Konsistenzanforderungen. Diese Datenbanken stellen sicher, dass Sie keine teilweise aktualisierten Daten zurückerhalten, indem sie Konsistenz auf Änderungsebene durchsetzen. Wenn Sie also eine Abfrage ausführen, müssen Sie warten, bis Ihre gesamte Änderung abgeschlossen ist, um die Daten aus dieser Änderung zurückzuerhalten.
Konsistenzanforderungen von Vektordatenbanken
Gleichzeitig haben Vektordatenbanken andere Konsistenzanforderungen als relationale oder nicht-relationale Datenbanken. Sie können gültige Daten haben, noch bevor eine Batch-Änderung vollständig abgeschlossen ist. Allerdings dürfen Sie keine teilweise aktualisierten Daten haben. Vektordatenbanken arbeiten nach dem PACELC-Theorem. Genau das macht Milvus durch sein Pub-Sub-Setup. Jede Zeile wird durch die Schreib-Pipeline „veröffentlicht“ und von den erforderlichen Knoten „abonniert“. Dieses Setup ermöglicht es Ihnen, Milvus zu durchsuchen oder abzufragen und Ergebnisse basierend auf den Unterschieden in den Zeitstempeln zu erhalten.
Konsistenz, Verfügbarkeit und Partitionen (CAP)
Das CAP-Theorem ist ein Informatikkonzept, das besagt, dass es einen Trade-off zwischen Konsistenz, Verfügbarkeit und Partitionstoleranz gibt. Sie können nur zwei der drei wählen. Wenn eine Netzwerkpartition vorliegt, müssen Sie zwischen Verfügbarkeit und Konsistenz wählen. Ein System, das eine hohe Datenverfügbarkeit verlangt, benötigt Replikate, was Konsistenz schwieriger macht.
Das PACELC-Theorem ist eine Erweiterung des CAP-Theorems. Es ist das CAP-Theorem + else + Latenz + Konsistenz. Es besagt, dass du dir in einem System ohne Netzwerkpartitionen keine Gedanken über Kompromisse zwischen Verfügbarkeit und Konsistenz machen musst. Du musst dich jedoch weiterhin zwischen Latenz und Konsistenz entscheiden, da du warten musst, bis Daten synchronisiert sind.
Welche Konsistenzstufen bietet Milvus an?
Milvus bietet vier verschiedene Konsistenzstufen an. In der Reihenfolge von der geringsten bis zur höchsten Konsistenz sind dies: Eventual, Session, Bounded und Strong. Eventual Consistency bedeutet, dass du bereit bist zu warten, bis es „... irgendwann“ passiert. Strong Consistency bedeutet, dass du alle Daten in dem Moment einbeziehen möchtest, in dem du die Abfrage sendest. Session und Bounded liegen dazwischen. Schauen wir uns das genauer an.
Kannst du erraten, welche Emojis welche Stufen darstellen?
Eventual Consistency
Eventual (oder „Eventually“) Consistency bedeutet, dass die Daten schließlich über alle Replikate hinweg konsistent sein werden. Wir verwenden Eventual Consistency, wenn uns die Geschwindigkeit einer Anwendung wichtiger ist als die aktuellsten Daten oder wiederholbare Abfragen. Für Milvus bedeutet diese Art von Konsistenz, dass wir die Konsistenzanforderung umsetzen, indem wir die Zeitstempelprüfung beim Lesen überspringen.
Ein Beispielanwendungsfall für diese Art von Konsistenzstufe könnte das Abrufen von Produktbewertungen sein. Die meisten Nutzer werden nicht alle Bewertungen zu einem Produkt lesen, daher ist es nicht von großer Bedeutung, die aktuellsten Bewertungen zu erhalten. Wenn du eine Collection mit dieser Konsistenzstufe erstellen möchtest, zeigt der folgende Code, wie du in Milvus eine Collection mit Konsistenz auf „Eventually“-Niveau erstellst. Es ist wichtig zu beachten, dass consistency_level nach dem Schlüsselwort „Eventually“ sucht.
Session Consistency
Session Consistency bedeutet, dass jede Session mindestens auf dem Stand ihrer eigenen Schreibvorgänge ist. Eine Session kann mehrere Replikate haben, daher ist das der erste Kompromiss zwischen Latenz und Konsistenz. Wir verwenden Session Consistency, wenn wir unseren Zustand nur einmal pro Session speichern müssen. Milvus implementiert diese Art von Konsistenz, indem der erforderliche Zeitstempel auf die Zeit des letzten Schreibvorgangs gesetzt wird.
In der Praxis kannst du Session Consistency verwenden, wenn jede Client-Server-Instanz Datenkonsistenz haben muss. Ein Beispiel dafür ist ein Videospielserver. Du willst nicht zulassen, dass Spieler Infinity-Glitches ausnutzen, daher musst du Konsistenz innerhalb jeder Instanz oder Session sicherstellen. Der folgende Code zeigt, wie eine Vektorsuche mit der Konsistenzstufe „Session“ durchgeführt wird.
Bounded Consistency
Bounded Consistency (oder begrenzte Veraltetheit) ist einen Schritt „konsistenter“ als Session Consistency. Bei Konsistenz auf „Session“-Niveau werden die anderen Instanzen oder Sessions als eventual consistent behandelt. Begrenzte Veraltetheit zwingt jede Instanz und jedes Replikat, sich innerhalb eines bestimmten Zeitraums zu synchronisieren.
Ein Beispiel für begrenzte Veraltetheit könnte eine Video-Empfehlungsmaschine sein. Nutzer benötigen die neuesten Videos nicht sofort, sollten sie aber bald sehen. Änderungen eines Nutzers sollten sich außerdem zeitnah außerhalb seiner Session verbreiten. Der folgende Code zeigt, wie du Milvus mit einer Anforderung an Bounded Consistency durchsuchst.
Strong Consistency
Strong Consistency macht Daten in dem Moment verfügbar, in dem du sie einfügst. Natürlich bringt diese Konsistenz einen Kompromiss bei der Latenz mit sich – wir müssen warten, bis sich das System ändert. In der Praxis implementiert Milvus diese Konsistenz, indem der erforderliche Lesezeitstempel auf die neueste Aktualisierung im System gesetzt wird. Dadurch steigt unsere Suchlatenz auf mindestens 200 ms.
Ein Beispiel für starke Konsistenz könnte Betrugserkennung sein. Wenn jemand Ihr Bankkonto für Betrug verwendet, müssen Sie dies sofort wissen und stoppen. Anwendungen, die eine Read-after-Write-Konfiguration benötigen, benötigen starke Konsistenz. Der folgende Code zeigt, wie eine Collection (gefilterte Suche ohne Vektoren) mit einer Anforderung an starke Konsistenz abgefragt wird.
Zusammenfassung zum Verständnis von Konsistenz für Vektordatenbanken
Datenkonsistenz ist eines der wichtigsten Dinge, die beim Aufbau Ihrer verteilten Anwendung berücksichtigt werden müssen. Jede Anwendung benötigt Daten, und alle Daten benötigen bestimmte Konsistenzanforderungen. Bei Vektordaten müssen wir die Datenkonsistenz im Hinblick auf zeilenbasierte Konsistenzanforderungen bewerten.
In Übereinstimmung mit diesen Anforderungen bietet Milvus vier Konsistenzstufen, die auf der Zeitstempelung der Daten basieren. Beachten Sie, dass dies nur für zeilenbasierte Konsistenz möglich ist und nicht in SQL- oder NoSQL-Datenbanken implementiert ist. Die vier Konsistenzstufen, von der höchsten bis zur niedrigsten Konsistenz, sind strong, bound, session und eventually.
Starke Konsistenz stellt sicher, dass uns systemweit (fast) sofort alle aktuellsten Daten zur Verfügung stehen. Diese Konsistenzstufe wird erreicht, indem der Zeitstempel auf den neuesten Einfügezeitstempel aktualisiert wird, wodurch sichergestellt wird, dass wir alle bis zum Zeitpunkt der Anfrage eingefügten Daten abfragen können.
Begrenzte Konsistenz stellt sicher, dass uns systemweit innerhalb eines festen Zeitraums alle aktuellsten Daten zur Verfügung stehen. Begrenzte Konsistenz setzt den Zeitstempel so, dass innerhalb eines bestimmten Zeitraums ab der Anfrage geprüft wird. Auf diese Weise haben wir alle Daten innerhalb eines begrenzten Zeitraums. Begrenzte Konsistenz ist die Standardeinstellung in Milvus.
Sitzungskonsistenz stellt sicher, dass uns in der aktuellen Sitzung, in der wir arbeiten, alle aktuellsten Daten zur Verfügung stehen. Milvus erreicht diese Konsistenzstufe, indem der Zeitstempel für jede Instanz auf den letzten Zeitpunkt gesetzt wird, zu dem diese Instanz Daten eingefügt hat. Auf diese Weise haben wir alle Daten, die (mindestens) in der von uns verwendeten Instanz eingefügt wurden.
Schließlich stellt eventuelle Konsistenz (Schlüsselwort „Eventually“) sicher, dass die Daten im gesamten System letztendlich alle konsistent sein werden. Daten können sich verbreiten und werden mit einer Geschwindigkeit, die sinnvoll ist, mit Replikaten synchronisiert. Obwohl wir einen Teil der Datenkonsistenz opfern, erhalten wir im Gegenzug eine bessere Verfügbarkeit und Leistung. In der Praxis dauert diese Konsistenzstufe nicht lange. Milvus implementiert eventuelle Konsistenz, indem die Zeitstempelprüfung übersprungen und Suchen oder Abfragen sofort ausgeführt werden.
Weiterlesen
Build Multimodal Search for 3D Assets with Tripo and Zilliz Cloud
Generate 3D assets with Tripo, then search them by text, image, and metadata with multimodal embeddings and Zilliz Cloud.
How to Install and Run OpenClaw (Previously Clawdbot/Moltbot) on Mac
Turn your Mac into an AI gateway for WhatsApp, Telegram, Discord, iMessage, and more — in under 5 minutes.
Why AI Databases Don't Need SQL
Whether you like it or not, here's the truth: SQL is destined for decline in the era of AI.