Konsistenzebenen von Azure Cosmos DB for Apache Cassandra und Azure Cosmos DB
GILT FÜR: 
Cassandra
Im Gegensatz zu Azure Cosmos DB bietet Apache Cassandra nativ keine genau definierten Konsistenzgarantien. Stattdessen bietet Apache Cassandra eine Schreib- und Lesekonsistenzebene, um in den Genuss von Vorteilen in Bezug auf Hochverfügbarkeit, Konsistenz und Latenz zu kommen. Bei Verwenden von Azure Cosmos DB for Cassandra:
- Die Schreibkonsistenzebene von Apache Cassandra wird der Standardkonsistenzebene zugeordnet, die in Ihrem Azure Cosmos DB-Konto konfiguriert ist. Die Konsistenz für einen Schreibvorgang (CL) kann nicht anforderungsweise geändert werden.
- Azure Cosmos DB ordnet die vom Cassandra-Clienttreiber angegebene Lesekonsistenzebene dynamisch zu. Die Konsistenzebene wird einer der Azure Cosmos DB-Konsistenzebenen zugeordnet, die bei einer Leseanforderung dynamisch konfiguriert wird.
Schreibvorgänge in mehreren Regionen und Schreibvorgänge in einer einzelnen Region
Die Apache Cassandra-Datenbank ist standardmäßig ein Multimaster-System und bietet keine Standardoption für Schreibvorgänge in einer einzelnen Region mit Replikation für Lesevorgänge in mehreren Regionen. Azure Cosmos DB bietet jedoch die sofort einsatzbereite Möglichkeit, Schreibkonfigurationen für eine einzelne Region oder mehrere Regionen zu haben. Einer der Vorteile bei der Möglichkeit zur Auswahl einer Schreibkonfiguration für eine einzelne Region in mehreren Regionen ist die Vermeidung regionsübergreifender Konfliktszenarien und die Option, eine starke Konsistenz in mehreren Regionen zu wahren.
Bei Schreibvorgängen in einer einzelnen Region können Sie eine starke Konsistenz wahren und gleichzeitig eine regionsübergreifende hohe Verfügbarkeit mit dienstseitig verwaltetem Failover weiterhin aufrechterhalten. In dieser Konfiguration können Sie die Datenlokalität weiterhin zur Verringerung der Leselatenz ausnutzen, indem Sie anforderungsweise auf letztliche Konsistenz herabstufen. Zusätzlich zu diesen Funktionen bietet die Azure Cosmos DB-Plattform auch die Möglichkeit der Zonenredundanz bei der Auswahl einer Region. Im Gegensatz zu nativem Apache Cassandra ermöglicht es Ihnen Azure Cosmos DB daher, im Kompromissspektrum des CAP-Theorems mit einer höheren Granularität zu navigieren.
Zuordnen von Konsistenzebenen
Die Azure Cosmos DB-Plattform stellt eine Gruppe von fünf klar definierten, an Anwendungsfällen für Unternehmen orientierten Konsistenzeinstellungen in Bezug auf die Replikation bereit. Die Nachteile dieser Konsistenzeinstellungen sind durch das CAP-Theorem und das PACLC-Theorem definiert. Da sich dieser Ansatz erheblich von Apache Cassandra unterscheidet, sollten Sie sich Zeit nehmen, sich über die Azure Cosmos DB-Konsistenz zu informieren und sie zu verstehen. Sie können sich auch dieses kurze Anleitungsvideo ansehen, um Konsistenzeinstellungen in der Azure Cosmos DB-Plattform zu verstehen. In der folgenden Tabelle werden die möglichen Zuordnungen zwischen Apache Cassandra- und Azure Cosmos DB-Konsistenzebenen bei Verwendung der API für Cassandra veranschaulicht. Diese Tabelle zeigt Konfigurationen für eine einzelne Region, Lesevorgänge in mehreren Regionen mit Schreibvorgängen in einer einzelnen Region und Schreibvorgänge in mehreren Regionen.
Zuordnungen
Hinweis
Dies sind keine exakten Zuordnungen. Stattdessen haben wir Apache Cassandra die naheliegendsten Äquivalente zur Verfügung gestellt und qualitative Unterschiede in der Spalte ganz rechts vermieden. Wie oben erwähnt, empfehlen wir, dass Sie sich über Konsistenzeinstellungen für Azure Cosmos DB informieren.
Schreibkonsistenz ALL, EACH_QUOROM, QUOROM, LOCAL_QUORUM oder THREE in Apache Cassandra
| Apache-Lesekonsistenz | Lesen aus | Azure Cosmos DB-Konsistenzebene, die den Lese-/Schreibeinstellungen von Apache Cassandra am nächsten kommt |
|---|---|---|
ALL |
Lokale Region | Strong |
EACH_QUOROM |
Lokale Region | Strong |
QUOROM |
Lokale Region | Strong |
LOCAL_QUORUM |
Lokale Region | Strong |
LOCAL_ONE |
Lokale Region | Eventual |
ONE |
Lokale Region | Eventual |
TWO |
Lokale Region | Strong |
THREE |
Lokale Region | Strong |
Im Gegensatz zu Apache und DSE Cassandra führt Azure Cosmos DB standardmäßig dauerhaft einen Commit für einen Quorum-Schreibvorgang durch. Mindestens drei von vier (3/4) Knoten führen einen Commit für den Schreibvorgang auf einen Datenträger aus und NICHT nur ein In-Memory-Commitprotokoll.
Schreibkonsistenz ONE, LOCAL_ONE oder ANY in Apache Cassandra
| Apache-Lesekonsistenz | Lesen aus | Azure Cosmos DB-Konsistenzebene, die den Lese-/Schreibeinstellungen von Apache Cassandra am nächsten kommt |
|---|---|---|
ALL |
Lokale Region | Strong |
EACH_QUOROM |
Lokale Region | Eventual |
QUOROM |
Lokale Region | Eventual |
LOCAL_QUORUM |
Lokale Region | Eventual |
LOCAL_ONE |
Lokale Region | Eventual |
ONE |
Lokale Region | Eventual |
TWO |
Lokale Region | Eventual |
THREE |
Lokale Region | Eventual |
Die Azure Cosmos DB-API für Cassandra führt standardmäßig dauerhaft einen Commit für einen Quorum-Schreibvorgang durch, sodass alle Lesekonsistenzen verwendet werden können.
Schreibkonsistenz TWO in Apache Cassandra
| Apache-Lesekonsistenz | Lesen aus | Azure Cosmos DB-Konsistenzebene, die den Lese-/Schreibeinstellungen von Apache Cassandra am nächsten kommt |
|---|---|---|
ALL |
Lokale Region | Strong |
EACH_QUOROM |
Lokale Region | Strong |
QUOROM |
Lokale Region | Strong |
LOCAL_QUORUM |
Lokale Region | Strong |
LOCAL_ONE |
Lokale Region | Eventual |
ONE |
Lokale Region | Eventual |
TWO |
Lokale Region | Eventual |
THREE |
Lokale Region | Strong |
Azure Cosmos DB verfügt über kein Konzept für Schreibkonsistenz auf nur zwei Knoten, sodass diese Konsistenz in den meisten Fällen ähnlich einem Quorum behandelt wird. Bei Lesekonsistenz TWO entspricht diese Konsistenz dem Schreiben mit QUOROM und Lesen aus ONE.
Schreibkonsistenz Serial oder Local_Serial in Apache Cassandra
| Apache-Lesekonsistenz | Lesen aus | Azure Cosmos DB-Konsistenzebene, die den Lese-/Schreibeinstellungen von Apache Cassandra am nächsten kommt |
|---|---|---|
ALL |
Lokale Region | Strong |
EACH_QUOROM |
Lokale Region | Strong |
QUOROM |
Lokale Region | Strong |
LOCAL_QUORUM |
Lokale Region | Strong |
LOCAL_ONE |
Lokale Region | Eventual |
ONE |
Lokale Region | Eventual |
TWO |
Lokale Region | Strong |
THREE |
Lokale Region | Strong |
„Serial“ gilt nur für einfache Transaktionen. Azure Cosmos DB folgt standardmäßig einem Algorithmus für dauerhaften Commit und daher ähnelt die Konsistenz Serial einem Quorum.
Andere Regionen für Schreibvorgänge in einer einzelnen Region
Azure Cosmos DB unterstützt fünf Konsistenzeinstellungen (einschließlich „Strong“) in mehreren Regionen, in denen Schreibvorgänge in einer einzelnen Region konfiguriert sind. Diese Möglichkeit besteht, solange die Regionen nicht weiter als 2.000 Meilen voneinander entfernt sind.
Azure Cosmos DB weist keine geeignete Zuordnung zu Apache Cassandra auf, da alle Knoten/Regionen Schreibvorgänge ausführen und keine Garantie für starke Konsistenz für alle Regionen gegeben werden kann.
Andere Regionen für Schreibvorgänge in mehreren Regionen
Azure Cosmos DB unterstützt nur vier Konsistenzeinstellungen (eventual, consistent prefix, sessionund bounded staleness) in mehreren Regionen, in denen Schreibvorgänge in mehreren Regionen konfiguriert sind.
Apache Cassandra würde unabhängig von den Einstellungen nur letztliche Konsistenz für Lesevorgänge in anderen Regionen bieten.
Unterstützte dynamische Überschreibungen
| Azure Cosmos DB-Kontoeinstellung | Überschreibungswert in Clientanforderung | Auswirkung der Überschreibung |
|---|---|---|
Strong |
All |
Keine Auswirkung (bleibt strong) |
Strong |
Quorum |
Keine Auswirkung (bleibt strong) |
Strong |
LocalQuorum |
Keine Auswirkung (bleibt strong) |
Strong |
Two |
Keine Auswirkung (bleibt strong) |
Strong |
Three |
Keine Auswirkung (bleibt strong) |
Strong |
Serial |
Keine Auswirkung (bleibt strong) |
Strong |
LocalSerial |
Keine Auswirkung (bleibt strong) |
Strong |
One |
Konsistenz ändert sich in Eventual |
Strong |
LocalOne |
Konsistenz ändert sich in Eventual |
Strong |
Any |
Nicht zulässig (Fehler) |
Strong |
EachQuorum |
Nicht zulässig (Fehler) |
Bounded staleness, sessionoder consistent prefix |
All |
Nicht zulässig (Fehler) |
Bounded staleness, sessionoder consistent prefix |
Quorum |
Nicht zulässig (Fehler) |
Bounded staleness, sessionoder consistent prefix |
LocalQuorum |
Nicht zulässig (Fehler) |
Bounded staleness, sessionoder consistent prefix |
Two |
Nicht zulässig (Fehler) |
Bounded staleness, sessionoder consistent prefix |
Three |
Nicht zulässig (Fehler) |
Bounded staleness, sessionoder consistent prefix |
Serial |
Nicht zulässig (Fehler) |
Bounded staleness, sessionoder consistent prefix |
LocalSerial |
Nicht zulässig (Fehler) |
Bounded staleness, sessionoder consistent prefix |
One |
Konsistenz ändert sich in Eventual |
Bounded staleness, sessionoder consistent prefix |
LocalOne |
Konsistenz ändert sich in Eventual |
Bounded staleness, sessionoder consistent prefix |
Any |
Nicht zulässig (Fehler) |
Bounded staleness, sessionoder consistent prefix |
EachQuorum |
Nicht zulässig (Fehler) |
Metriken
Wenn Ihr Azure Cosmos DB-Konto mit einer anderen Konsistenzebene als der starken Konsistenz konfiguriert ist, sehen Sie sich die PBS-Metrik (Probabilistically Bounded Staleness) an. Die Metrik erfasst die Wahrscheinlichkeit, dass Ihre Clients starke und konsistente Lesevorgänge für Ihre Workloads erzielen. Diese Metrik steht im Azure-Portal zur Verfügung. Weitere Informationen zur PBS-Metrik finden Sie unter Überwachen der PBS-Metrik (Probabilistically Bounded Staleness).
PBS (Probabilistically Bounded Staleness) zeigt, wie letztendlich Ihre letztliche Konsistenz ist. Diese Metrik gibt Aufschluss darüber, wie oft Sie eine stärkere Konsistenz erreichen können als die Konsistenzebene, die Sie aktuell in Ihrem Azure Cosmos DB-Konto konfiguriert haben. Das heißt, Sie sehen die Wahrscheinlichkeit (gemessen in Millisekunden), dass konsistente Lesevorgänge in Regionen mit Schreib- und Lesevorgängen auftreten.
Globale starke Konsistenz für Schreibanforderungen in Apache Cassandra
In Apache Cassandra bewirkt die Einstellung EACH_QUORUM oder QUORUM eine starke Konsistenz. Wenn eine Schreibanforderung an eine Region gesendet wird, werden mit EACH_QUORUM die Daten in einer Quorumanzahl von Knoten in jedem Rechenzentrum permanent gespeichert. Diese permanente Speicherung erfordert, dass jedes Rechenzentrum für einen erfolgreichen Schreibvorgang verfügbar ist. QUORUM ist etwas weniger restriktiv, da eine QUORUM-Anzahl von Knoten in allen Rechenzentren erforderlich ist, um die Daten permanent zu speichern, bevor der Schreibvorgang als erfolgreich bestätigt wird.
Die folgende Grafik veranschaulicht eine globale starke Konsistenzeinstellung in Apache Cassandra zwischen den zwei Regionen 1 und 2. Nachdem Daten in Region 1 geschrieben wurden, muss der Schreibvorgang in einer Quorumanzahl von Knoten sowohl in Region 1 als auch in Region 2 permanent gespeichert werden, bevor die Anwendung eine Bestätigung erhält.
Globale starke Konsistenz für Schreibanforderungen in Azure Cosmos DB for Apache Cassandra
In Azure Cosmos DB wird die Konsistenz wird auf Kontoebene festgelegt. Bei der Konsistenzeinstellung Strong in Azure Cosmos DB for Cassandra werden Daten synchron in die Leseregionen für das Konto repliziert. Je weiter die Regionen für das Azure Cosmos DB-Konto voneinander entfernt sind, desto höher ist die Latenz der konsistenten Schreibvorgänge.
Auswirkungen der Anzahl von Regionen auf die Lese- oder Schreibanforderung:
- Zwei Regionen: Mit starker Konsistenz, Quorum
(N/2 + 1) = 2. Wenn also die Leseregion ausfällt, kann das Konto keine Schreibvorgänge mehr mit starker Konsistenz akzeptieren, da keine Quorumanzahl von Regionen zur Verfügung steht, in denen der Schreibvorgang repliziert werden kann. - Drei oder mehr Regionen: Für
N = 3,quorum = 2. Wenn eine der Leseregionen ausfällt, kann die Schreibregion die Schreibvorgänge weiterhin in insgesamt zwei Regionen replizieren, die die Quorumanforderung erfüllen. Ähnlich ist es bei vier Regionen,quorum = 4/2 + 1 = 3. Selbst wenn eine Leseregion ausfällt, kann das Quorum erreicht werden.
Hinweis
Wenn eine global starke Konsistenz für alle Schreibvorgänge erforderlich ist, muss die Konsistenz für das Azure Cosmos DB for Cassandra-Konto auf „Strong“ festgelegt werden. Die Konsistenzebene für Schreibvorgänge kann in Azure Cosmos DB nicht pro Anforderung durch Überschreibung auf eine niedrigere Konsistenzebene festgelegt werden.
Schwächere Konsistenz für Schreibanforderungen in Apache Cassandra
Konsistenzebene ANY, ONE, TWO, THREE, LOCAL_QUORUM, Serial oder Local_Serial? Ziehen Sie eine Schreibanforderung mit LOCAL_QUORUM und einem RF-Wert von 4 in einem Rechenzentrum mit sechs Knoten in Betracht. Quorum = 4/2 + 1 = 3.
Schwächere Konsistenz für Schreibanforderungen in Azure Cosmos DB for Apache Cassandra
Wenn eine Schreibanforderung mit einer niedrigeren Konsistenzebene als Strong gesendet wird, wird eine Erfolgsantwort zurückgegeben, sobald die lokale Region den Schreibvorgang in mindestens drei von vier Replikaten permanent speichert.
Globale starke Konsistenz für Leseanforderungen in Apache Cassandra
Mit der Konsistenzeinstellung EACH_QUORUM kann ein konsistenter Lesevorgang in Apache Cassandra erzielt werden. Wenn bei einer Einrichtung mit mehreren Regionen für EACH_QUORUM die Quorumanzahl der Knoten nicht in jeder Region erreicht wird, ist der Lesevorgang nicht erfolgreich.
Globale starke Konsistenz für Leseanforderungen in Azure Cosmos DB for Apache Cassandra
Die Leseanforderung wird aus zwei Replikaten in der angegebenen Region bedient. Da der Schreibvorgang bereits für die permanente Speicherung in einer Quorumanzahl von Regionen (bzw. in allen Regionen, wenn jede Region verfügbar war) gesorgt hat, bietet das einfache Lesen aus zwei Replikaten in der angegebenen Region eine starke Konsistenz. Für diese starke Konsistenz muss EACH_QUORUM im Treiber angegeben werden, wenn der Lesevorgang für eine Region für das Cosmos DB-Konto zusammen mit „Starke Konsistenz“ als Standardkonsistenzebene für das Konto ausgegeben wird.
Lokale starke Konsistenz in Apache Cassandra
Eine Leseanforderung mit der Konsistenzebene TWO, THREE oder LOCAL_QUORUM führt zu einem Lesevorgang mit starker Konsistenz aus der lokalen Region. Bei der Konsistenzebene LOCAL_QUORUM benötigen Sie für einen erfolgreichen Lesevorgang eine Antwort von zwei Knoten im angegebenen Rechenzentrum.
Lokale starke Konsistenz in Azure Cosmos DB for Apache Cassandra
In Azure Cosmos DB for Cassandra bewirkt die Konsistenzebene TWO, THREE oder LOCAL_QUORUM eine lokale starke Konsistenz für eine Leseanforderung. Da der Schreibpfad die Replikation in mindestens drei von vier Replikaten garantiert, wird durch einen Lesevorgang aus zwei Replikaten in der angegebenen Region ein Quorum-Lesevorgang der Daten in dieser Region garantiert.
Letztliche Konsistenz in Apache Cassandra
Die Konsistenzebenen LOCAL_ONE, One und ANY with LOCAL_ONE führen zu letztlicher Konsistenz. Diese Konsistenz wird in Fällen verwendet, in denen der Schwerpunkt auf der Latenz liegt.
Letztliche Konsistenz in Azure Cosmos DB for Apache Cassandra?
Die Konsistenzebene LOCAL_ONE, ONE oder Any bietet Ihnen letztliche Konsistenz. Bei letztlicher Konsistenz wird ein Lesevorgang aus nur einem der Replikate in der angegebenen Region bedient.
Überschreiben der Konsistenzebene für Lesevorgänge in Azure Cosmos DB for Cassandra
Zuvor konnte die Konsistenzebene für Leseanforderungen nur mit einer niedrigeren Konsistenz als der für das Konto festgelegten Standardkonsistenz überschrieben werden. Bei der Standardkonsistenz „Strong“ konnten beispielsweise Leseanforderungen standardmäßig mit „Strong“ ausgegeben und (bei Bedarf) pro Anforderung mit einer niedrigeren Konsistenzebene als „Strong“ überschrieben werden. Leseanforderungen konnten jedoch nicht durch Überschreibung mit einer höheren Konsistenzebene als der Standardeinstellung des Kontos ausgegeben werden. Ein Konto mit letztlicher Konsistenz konnte keine Leseanforderungen mit einer höheren Konsistenzebene als „Eventual“ erhalten (was in den Apache Cassandra-Treibern in TWO, THREE, LOCAL_QUORUM oder QUORUM übersetzt wird).
Azure Cosmos DB for Cassandra ermöglicht jetzt das Überschreiben der Konsistenz bei Leseanforderungen auf einen höheren Wert als die Standardkonsistenz des Kontos. Wenn die Standardkonsistenz für das Cosmos DB-Konto z. B. auf „Eventual“ festgelegt ist (entspricht in Apache Cassandra One oder ANY), können Leseanforderungen pro Anforderung in LOCAL_QUORUM überschrieben werden. Durch diese Überschreibung wird sichergestellt, dass eine Quorumanzahl von Replikaten innerhalb der angegebenen Region vor der Rückgabe der Ergebnisse berücksichtigt wird, wie es von LOCAL_QUORUM gefordert wird.
Diese Option verhindert auch, dass eine Standardkonsistenz festgelegt werden muss, die höher ist als Eventual, wenn dies nur für Leseanforderungen erforderlich ist.