Konsistenz
In diesem Thema werden die vier Konsistenzstufen in Milvus und die dafür am besten geeigneten Szenarien vorgestellt. Der Mechanismus zur Gewährleistung der Konsistenz in Milvus wird ebenfalls in diesem Thema behandelt.
Überblick
Konsistenz in einer verteilten Datenbank bezieht sich speziell auf die Eigenschaft, die sicherstellt, dass jeder Knoten oder jede Replik dieselbe Sicht auf die Daten hat, wenn sie zu einem bestimmten Zeitpunkt Daten schreiben oder lesen.
Milvus unterstützt vier Konsistenzstufen: strong, bounded staleness, session und eventually. Die Standardkonsistenzstufe in Milvus ist "bounded staleness". Sie können die Konsistenzstufe bei der Durchführung einer Einzelvektorsuche, einer hybriden Suche oder einer Abfrage leicht anpassen, um sie optimal auf Ihre Anwendung abzustimmen.
Konsistenzstufen
Wie im PACELC-Theorem definiert, muss eine verteilte Datenbank einen Kompromiss zwischen Konsistenz, Verfügbarkeit und Latenzzeit eingehen. Eine hohe Konsistenz bedeutet eine hohe Genauigkeit, aber auch eine hohe Suchlatenz, während eine niedrige Konsistenz zu einer schnellen Suchgeschwindigkeit, aber einem gewissen Verlust an Datentransparenz führt. Daher eignen sich verschiedene Konsistenzniveaus für verschiedene Szenarien.
Im Folgenden werden die Unterschiede zwischen den vier von Milvus unterstützten Konsistenzstufen und den jeweiligen Szenarien erläutert.
Stark
Strong ist die höchste und strengste Konsistenzstufe. Sie stellt sicher, dass die Benutzer die neueste Version der Daten lesen können.
Starke Konsistenz
Das PACELC-Theorem besagt, dass sich die Latenzzeit erhöht, wenn die Konsistenzstufe auf Strong eingestellt wird. Daher empfehlen wir, bei Funktionstests starke Konsistenz zu wählen, um die Genauigkeit der Testergebnisse zu gewährleisten. Starke Konsistenz eignet sich auch am besten für Anwendungen, die strenge Anforderungen an die Datenkonsistenz auf Kosten der Suchgeschwindigkeit stellen. Ein Beispiel hierfür ist ein Online-Finanzsystem, das sich mit der Bezahlung von Bestellungen und der Rechnungsstellung befasst.
Begrenzte Unbeständigkeit
Bounded Staleness lässt, wie der Name schon sagt, Dateninkonsistenz während eines bestimmten Zeitraums zu. In der Regel sind die Daten jedoch außerhalb dieses Zeitraums immer global konsistent.
Konsistenz von Bounded Staleness
Bounded Staleness eignet sich für Szenarien, in denen die Suchlatenz kontrolliert werden muss und sporadische Unsichtbarkeit der Daten akzeptiert werden kann. In Empfehlungssystemen wie Videoempfehlungsmaschinen hat die Unsichtbarkeit von Daten manchmal nur geringe Auswirkungen auf die Gesamtauffindungsrate, kann aber die Leistung des Empfehlungssystems erheblich steigern.
Sitzung
Session stellt sicher, dass alle Daten, die geschrieben werden, sofort in der gleichen Sitzung gelesen werden können. Mit anderen Worten: Wenn Sie Daten über einen Client schreiben, werden die neu eingefügten Daten sofort durchsuchbar.
Session-Konsistenz
Wir empfehlen die Wahl von Session als Konsistenzebene für Szenarien, in denen die Anforderung an die Datenkonsistenz in derselben Session hoch ist. Ein Beispiel ist das Löschen der Daten eines Bucheintrags aus dem Bibliothekssystem. Nach der Bestätigung der Löschung und dem Auffrischen der Seite (einer anderen Sitzung) sollte das Buch nicht mehr in den Suchergebnissen erscheinen.
Eventuell
Es gibt keine garantierte Reihenfolge der Lese- und Schreibvorgänge, und die Replikate konvergieren schließlich zum gleichen Zustand, wenn keine weiteren Schreibvorgänge durchgeführt werden. Bei der Konsistenzstufe "eventually" beginnen die Replikate bei Leseanforderungen mit den zuletzt aktualisierten Werten zu arbeiten. Eventuell konsistent ist die schwächste der vier Stufen.
Eventuelle Konsistenz
Nach dem PACELC-Theorem kann die Suchlatenz jedoch enorm verkürzt werden, wenn die Konsistenz geopfert wird. Daher eignet sich die Stufe "Eventuell konsistent" am besten für Szenarien, die keine hohen Anforderungen an die Datenkonsistenz stellen, aber eine blitzschnelle Suchleistung erfordern. Ein Beispiel hierfür ist das Abrufen von Rezensionen und Bewertungen von Amazon-Produkten mit der Stufe "eventually consistent".
Garantierter Zeitstempel
Milvus realisiert verschiedene Konsistenzstufen durch die Einführung des Guarantee Timestamp (GuaranteeTs).
Ein GuaranteeTs dient dazu, den Abfrageknoten mitzuteilen, dass eine Such- oder Abfrageanfrage erst dann durchgeführt wird, wenn alle Daten vor dem GuaranteeTs von den Abfrageknoten gesehen werden können. Wenn Sie die Konsistenzstufe angeben, wird die Konsistenzstufe auf einen bestimmten GuaranteeTs-Wert abgebildet. Verschiedene GuaranteeTs-Werte entsprechen verschiedenen Konsistenzstufen:
Stark: GuaranteeTs wird als identisch mit dem neuesten Systemzeitstempel festgelegt, und Abfrageknoten warten, bis alle Daten vor dem neuesten Systemzeitstempel zu sehen sind, bevor sie die Such- oder Abfrageanfrage bearbeiten.
Begrenzte Staleness: GuaranteeTs wird relativ kleiner als der neueste Systemzeitstempel gesetzt, und Abfrageknoten suchen auf einer tolerierbaren, weniger aktuellen Datenansicht.
Sitzung: Der Client verwendet den Zeitstempel des letzten Schreibvorgangs als GuaranteeTs, so dass jeder Client zumindest die vom selben Client eingefügten Daten abrufen kann.
Eventuell: GuaranteeTs wird auf einen sehr kleinen Wert gesetzt, um die Konsistenzprüfung zu überspringen. Abfrageknoten suchen sofort in der vorhandenen Datenansicht.
Unter Funktionsweise von GuaranteeTs finden Sie weitere Informationen über den Mechanismus zur Gewährleistung verschiedener Konsistenzstufen in Milvus.
Was kommt als nächstes
- Erfahren Sie, wie Sie die Konsistenzstufe einstellen können, wenn:
