Auswählen der richtigen Konsistenzebene
Jedes der Konsistenzmodelle kann für bestimmte reale Szenarien verwendet werden. Jedes Modell ist in Bezug auf Verfügbarkeit und Leistung speziell abgestimmt und basiert auf umfassenden SLAs. Die folgenden einfachen Überlegungen helfen Ihnen, in vielen gängigen Szenarien die richtige Wahl zu treffen.
Konfigurieren der Standardkonsistenzebene
Sie können die Standardkonsistenzebene für Ihr Azure Cosmos DB-Konto jederzeit konfigurieren. Die für Ihr Konto konfigurierte Standardkonsistenzebene gilt für alle Azure Cosmos DB-Datenbanken und -Container in diesem Konto. Bei allen in einem Container oder einer Datenbank ausgeführten Lesevorgängen und Abfragen wird standardmäßig die angegebene Konsistenzebene verwendet.
Die Lesekonsistenz gilt für einen einzelnen Lesevorgang innerhalb einer logischen Partition. Ein Lesevorgang kann durch einen Remoteclient oder eine gespeicherte Prozedur ausgelöst werden.
Garantien in Zusammenhang mit Konsistenzebenen
Azure Cosmos DB garantiert, dass 100 Prozent aller Leseanforderungen die Konsistenzgarantie für jede ausgewählte Konsistenzebene erfüllen. Die genauen Definitionen der fünf Konsistenzebenen in Azure Cosmos DB – unter Verwendung der TLA+-Spezifikationssprache – finden Sie im GitHub-Repository azure-cosmos-tla.
Starke Konsistenz
Starke Konsistenz bietet garantierte Linearisierbarkeit. Linearisierbarkeit bedeutet die gleichzeitige Verarbeitung von Anforderungen. Die Lesevorgänge geben garantiert die neueste Version eines Elements zurück, für die ein Commit ausgeführt wurde. Einem Client wird nie ein partieller Schreibvorgang bzw. ein Schreibvorgang, für den kein Commit ausgeführt wurde, angezeigt. Benutzer haben immer die Garantie, dass sie den neuesten Schreibvorgang lesen, für den ein Commit ausgeführt wurde.
Konsistenzebene „Begrenzte Veraltung“
Bei der Konsistenz der begrenzten Veraltung liegt die Verzögerung von Daten zwischen zwei beliebigen Regionen immer unter einem angegebenen Wert. Der Betrag kann K- Versionen (d. h. Updates) eines Elements oder durch T Zeitintervalle sein, je nachdem, was zuerst erreicht wird. Wenn Sie also die begrenzte Veraltung auswählen, kann die maximale Veraltung der Daten in jeder Region auf zwei Arten konfiguriert werden:
- Anhand der Anzahl von Versionen (K) des Elements
- Das Zeitintervall (T) kann hinter den Schreibvorgängen liegen.
Begrenzte Veraltung ist in erster Linie für Konten mit Schreibzugriff auf eine einzelne Region mit zwei oder mehr Regionen von Vorteil. Wenn die Datenverzögerung in einer Region (ermittelt pro physischer Partition) den konfigurierten Veraltungswert übersteigt, werden Schreibvorgänge für diese Partition gedrosselt, bis die Veraltung wieder innerhalb der konfigurierten Obergrenze liegt.
Für ein Konto mit einer einzelnen Region bietet die begrenzte Veraltung die gleichen Schreibkonsistenzgarantien wie Sitzungskonsistenz und letztliche Konsistenz. Bei der begrenzten Veraltung werden Daten in einer lokalen Mehrheit (drei von vier Replikaten) innerhalb der einzelnen Region repliziert.
Sitzungskonsistenz
Bei der Sitzungskonsistenz berücksichtigen Lesevorgänge innerhalb einer einzelnen Clientsitzung immer die folgenden Garantien: Lesen der eigenen Schreibvorgänge und Schreibvorgänge folgen Lesevorgängen. Diese Garantie setzt voraus, dass entweder eine einzelne „Writer“-Sitzung durchgeführt oder das Sitzungstoken für mehrere Autoren geteilt wird.
Wie alle Konsistenzebenen, die schwächer als „Strong“ sind, werden Schreibvorgänge in mindestens drei Replikaten (in einer Gruppe von vier Replikaten) in der lokalen Region repliziert, wobei die asynchrone Replikation in alle anderen Regionen erfolgt.
Präfixkonsistenz
Bei einem konsistenten Präfix sind die Aktualisierungen, die als einzelne Dokumentschreibvorgänge durchgeführt werden, letztendlich konsistent. Als Batch innerhalb einer Transaktion vorgenommene Aktualisierungen werden konsistent zu der Transaktion zurückgegeben, in der sie committet wurden. Schreibvorgänge innerhalb einer Transaktion mehrerer Dokumente sind immer zusammen sichtbar.
Angenommen, es werden zwei Schreibvorgänge auf die Dokumente Doc 1 und Doc 2 innerhalb der Transaktionen T1 und T2 durchgeführt. Wenn der Client ein Lesevorgang in einem Replikat ausführt, sieht der Benutzer entweder "Doc 1 v1 und Doc 2 v1" oder "Doc 1 v2 und Doc 2 v2", " aber nie "Doc 1 v1 und Doc 2 v2" oder "Doc 1 v2 und Doc 2 v1" für denselben Lese- oder Abfragevorgang.
Letztliche Konsistenz
Bei letztlicher Konsistenz gibt es keine Reihenfolgegarantie für Lesevorgänge. Wenn keine weiteren Schreibvorgänge vorhanden sind, konvergieren die Replikate schließlich.
Die letztliche Konsistenz ist die schwächste Form der Konsistenz, da ein Client unter Umständen Werte liest, die älter als die zuvor gelesenen Werte sind. Letztliche Konsistenz ist ideal, wenn die Anwendung keine die Reihenfolge betreffenden Garantien erfordert. Ein Beispiel wäre etwa das Zählen von Retweets, Likes oder Kommentaren ohne Thread.