Teilen über

Anleitung zur Anpassung an Azure Cosmos DB for Apache Cassandra, wenn Sie von Apache Cassandra kommen

  • Artikel

GILT FÜR: Cassandra

Azure Cosmos DB for Apache Cassandra bietet Wire Protocol-Kompatibilität mit vorhandenen SDKs und Tools für Cassandra. Sie können Anwendungen ausführen, die für die Verbindung mit Apache Cassandra entwickelt wurden, indem Sie die API für Cassandra mit minimalen Änderungen verwenden.

Bei Verwendung der API für Cassandra ist es wichtig, sich der Unterschiede zwischen Apache Cassandra und Azure Cosmos DB bewusst zu sein. Wenn Sie mit nativem Apache Cassandra vertraut sind, kann dieser Artikel Ihnen helfen, mit der Verwendung von Azure Cosmos DB for Apache Cassandra zu beginnen.

Featureunterstützung

Die API für Cassandra unterstützt eine große Anzahl von Apache Cassandra-Features. Einige Funktionen werden nicht unterstützt oder haben Einschränkungen. Stellen Sie vor der Migration sicher, dass die benötigten Azure Cosmos DB for Apache Cassandra-Features unterstützt werden.

Replikation

Bei der Planung der Replikation ist es wichtig, sowohl die Migration als auch die Konsistenz zu betrachten.

Auch wenn Sie über Version 4 des binären CQL Wire Protocol (Cassandra Query Language) mit der API für Cassandra kommunizieren können, implementiert Azure Cosmos DB ein eigenes internes Replikationsprotokoll. Sie können das Cassandra-Gossip-Protokoll nicht für die Livemigration oder Replikation verwenden. Weitere Informationen finden Sie unter Livemigration von Apache Cassandra zur API für Cassandra mithilfe von dualen Schreibvorgängen.

Informationen zur Offlinemigration finden Sie unter Migrieren von Daten aus Cassandra in ein Azure Cosmos DB for Apache Cassandra-Konto mithilfe von Azure Databricks.

Obwohl die Ansätze für Replikationskonsistenz in Apache Cassandra und Azure Cosmos DB ähnlich sind, ist es wichtig, die Unterschiede zu verstehen. In einem Zuordnungsdokument werden die Ansätze von Apache Cassandra und Azure Cosmos DB für Replikationskonsistenz miteinander verglichen. Es wird jedoch dringend empfohlen, die Konsistenzeinstellungen in Azure Cosmos DB genau anzusehen oder sich eine kurze Videoanleitung zum besseren Verständnis der Konsistenzeinstellungen der Azure Cosmos DB-Plattform anzuschauen.

Bei Verwendung der API für Cassandra müssen Sie keine grundlegenden Codeänderungen an vorhandenen Anwendungen vornehmen, die Apache Cassandra ausführen. Einige Ansätze und Konfigurationseinstellungen für die API für Cassandra in Azure Cosmos DB werden empfohlen. Ausführlichere Informationen finden Sie im Blogbeitrag Empfehlungen für die API für Cassandra für Java.

Codebeispiele

Die API für Cassandra ist für das Arbeiten mit Ihrem vorhandenen Anwendungscode konzipiert. Wenn jedoch Verbindungsfehler auftreten, verwenden Sie die Schnellstartbeispiele als Ausgangspunkt, um kleinere Setupänderungen zu ermitteln, die Sie möglicherweise im vorhandenen Code vornehmen müssen.

Außerdem gibt es detailliertere Beispiele für Java v3- und Java v4-Treiber. Mit diesen Codebeispielen werden benutzerdefinierte Erweiterungen implementiert, die ihrerseits empfohlene Clientkonfigurationen implementieren.

Sie können auch Beispiele für Java Spring Boot (v3-Treiber) und Java Spring Boot (v4-Treiber) verwenden.

Storage

Die API für Cassandra wird von Azure Cosmos DB, einer dokumentorientierten NoSQL-Datenbank-Engine, unterstützt. Azure Cosmos DB verwaltet Metadaten, wodurch sich möglicherweise die Menge des physischen Speichers ändert, der für eine bestimmte Workload erforderlich ist.

Der Unterschied bei den Speicheranforderungen zwischen nativem Apache Cassandra-System und Azure Cosmos DB macht sich besonders bei kleinen Zeilengrößen bemerkbar. In einigen Fällen kann der Unterschied ausgeglichen werden, da Azure Cosmos DB keine Komprimierung oder Tombstones implementiert. Dieser Faktor hängt erheblich von der Workload ab. Wenn Sie hinsichtlich der Speicheranforderungen unsicher sind, wird empfohlen, zunächst eine Machbarkeitsstudie (Proof of Concept) zu erstellen.

Bereitstellungen in mehreren Regionen

Das native Apache Cassandra-System ist standardmäßig ein Multimastersystem. Apache Cassandra bietet keine Option für Einzelmaster mit Replikation in mehreren Regionen nur für Lesevorgänge. Das Konzept des Failovers auf Anwendungsebene in eine andere Region für Schreibvorgänge ist in Apache Cassandra redundant. Alle Knoten sind unabhängig, und es gibt keine einzelne Fehlerquelle (Single Point of Failure). Azure Cosmos DB bietet jedoch die Möglichkeit, direkt Einzel- oder Multimasterregionen für Schreibvorgänge zu konfigurieren.

Der Vorteil einer Einzelmasterregion für Schreibvorgänge besteht in der Vermeidung von Szenarien mit regionsübergreifenden Konflikten. Dies bietet Ihnen die Möglichkeit, sowohl eine starke Konsistenz über mehrere Regionen hinweg als auch Hochverfügbarkeit aufrecht zu erhalten.

Hinweis

Eine starke regionsübergreifende Konsistenz und ein Wiederherstellungspunktziel (Recovery Point Objective, RPO) von Null ist beim nativen Apache Cassandra-System nicht möglich, da alle Knoten Schreibvorgänge verarbeiten können. Sie können Azure Cosmos DB für eine starke regionsübergreifende Konsistenz mit einer einzelnen Schreibregion konfigurieren. Wie beim nativen Apache Cassandra-System können Sie jedoch kein Azure Cosmos DB-Konto konfigurieren, das für starke Konsistenz mit mehreren Schreibregionen konfiguriert ist. Ein verteiltes System kann kein RPO von Null und eine Wiederherstellungszeitvorgabe (Recovery Time Objective, RTO) von Null bieten.

Weitere Informationen finden Sie in der Richtlinie zum Lastenausgleich in unseren Blog mit Empfehlungen für die API für Cassandra für Java. Siehe auch Failoverszenarien in unserem offiziellen Codebeispiel für den Cassandra Java v4-Treiber.

Anforderungseinheiten

Ein wichtiger Unterschied zwischen der Ausführung eines nativen Apache Cassandra-Clusters und der Bereitstellung eines Azure Cosmos DB-Kontos ist die Bereitstellung der Datenbankkapazität. Bei herkömmlichen Datenbanken wird die Kapazität in Form von CPU-Kernen, RAM und IOPS ausgedrückt. Azure Cosmos DB ist eine PaaS-Datenbank (Platform-as-a-Service) mit mehreren Mandanten. Die Kapazität wird mithilfe einer einzelnen normalisierten Maßeinheit ausgedrückt, den sogenannten Anforderungseinheiten (Request Units, RUs). Jede an die Datenbank gesendete Anforderung hat Kosten pro Anforderungseinheit (RU-Kosten). Jede Anforderung kann profiliert werden, um die Kosten zu ermitteln.

Der Vorteil der Verwendung von Anforderungseinheiten als Maßeinheit ist, dass Datenbankkapazität für in hohem Maß vorhersehbare Leistung und Effizienz deterministisch bereitgestellt werden kann. Nachdem Sie ein Profil der Kosten für jede Anforderung erstellt haben, können Sie mithilfe von Anforderungseinheiten die Anzahl der an die Datenbank gesendeten Anforderungen direkt der Kapazität zuordnen, die Sie bereitstellen müssen. Die Herausforderung bei dieser Art der Kapazitätsbereitstellung besteht darin, dass Sie die Durchsatzmerkmale Ihrer Workload gut kennen müssen.

Es wird dringend empfohlen, Ihre Anforderungen zu profilieren. Anhand dieser Informationen können Sie die Anzahl der Anforderungseinheiten schätzen, die Sie bereitstellen müssen. Hier sind einige Artikel aufgeführt, die Ihnen bei der Schätzung helfen können:

Kapazitätsbereitstellungsmodelle

Bei der herkömmlichen Datenbankbereitstellung wird vorab eine feste Kapazität für den erwarteten Durchsatz bereitgestellt. Azure Cosmos DB bietet ein kapazitätsbasiertes Modell, das bereitgestellter Durchsatz genannt wird. Als mehrinstanzenfähiger Dienst bietet Azure Cosmos DB auch nutzungsbasierte Modelle im Autoskalierungsmodus und serverlosen Modus. In welchem Umfang eine Workload von einem dieser nutzungsbasierten Bereitstellungsmodelle profitieren kann, hängt von der Vorhersagbarkeit des Durchsatzes für die Workload ab.

Im Allgemeinen profitieren gleichbleibende Workloads mit vorhersehbarem Durchsatz am meisten von dem Modell mit bereitgestelltem Durchsatz. Workloads mit ausgedehnten Ruhezeiten profitieren vom serverlosen Modell. Workloads mit einem kontinuierlichen Mindestdurchsatz, aber mit unvorhersehbaren Spitzen, profitieren am meisten vom Modell mit Autoskalierungsmodus. Es wird empfohlen, die folgenden Artikel zu lesen, um ein klares Verständnis des besten Kapazitätsmodells für Ihre Durchsatzanforderungen zu erhalten:

Partitionierung

Die Partitionierung in Azure Cosmos DB ähnelt der Partitionierung in Apache Cassandra. Einer der Hauptunterschiede ist, dass Azure Cosmos DB mehr für die horizontale Skalierung optimiert ist. In Azure Cosmos DB bestehen Beschränkungen bei der Menge der vertikalen Durchsatzkapazität, die auf einer physischen Partition verfügbar ist. Der Effekt dieser Optimierung ist besonders dann zu bemerken, wenn ein vorhandenes Datenmodell erhebliche Unregelmäßigkeiten beim Durchsatz aufweist.

Sorgen Sie dafür, dass Ihr Partitionsschlüsselentwurf zu einer relativ einheitlichen Verteilung von Anforderungen führt. Weitere Informationen zur Funktionsweise der logischen und physischen Partitionierung und den Grenzen der Durchsatzkapazität pro Partition finden Sie unter Partitionierung in Azure Cosmos DB for Apache Cassandra.

Skalierung

Beim nativen Apache Cassandra-System setzt das Erhöhen der Kapazität und eine Skalierung das Hinzufügen neuer Knoten zu einem Cluster voraus. Dabei muss ebenfalls sichergestellt sein, dass die Knoten ordnungsgemäß dem Cassandra-Ring hinzugefügt werden. In Azure Cosmos DB erfolgt das Hinzufügen von Knoten transparent und automatisch. Die Skalierung ist eine Funktion, die davon abhängt, wie viele Anforderungseinheiten für den Keyspace oder die Tabelle bereitgestellt werden. Die Skalierung auf physischen Computern erfolgt, wenn entweder der physische Speicher oder der erforderliche Durchsatz die für eine logische oder physische Partition zulässigen Grenzwerte erreicht. Weitere Informationen finden Sie unter Partitionierung in Azure Cosmos DB for Apache Cassandra.

Ratenbegrenzung

Eine Herausforderung bei der Bereitstellung von Anforderungseinheiten ist die Ratenbegrenzung, insbesondere bei Verwendung des bereitgestellten Durchsatzes. Azure Cosmos DB gibt Fehler zur Ratenbegrenzung zurück, wenn Clients mehr Ressourcen verbrauchen als die von Ihnen bereitgestellte Menge. Diese Ausnahmen werden von der API für Cassandra in Azure Cosmos DB in Überladungsfehler im nativen Cassandra-Protokoll übersetzt. Informationen zum Vermeiden einer Ratenbegrenzung in Ihrer Anwendung finden Sie unter Verhindern von Ratenbegrenzungsfehlern bei Azure Cosmos DB for Apache Cassandra-Vorgängen.

Apache Spark-Connector

Viele Apache Cassandra-Benutzer verwenden den Apache Spark Cassandra-Connector, um Daten für Analyse- und Datenverschiebungsbedarf abzufragen. Sie können eine Verbindung mit der API für Cassandra auf gleiche Weise und mit demselben Connector herstellen. Bevor Sie eine Verbindung mit der API für Cassandra herstellen, sollten Sie den Artikel Herstellen einer Verbindung mit Azure Cosmos DB for Apache Cassandra in Spark lesen. Sehen Sie sich insbesondere den Abschnitt Optimieren der Durchsatzkonfiguration für den Spark-Connector an.

Häufig auftretende Probleme und Problembehandlung

Lösungen für häufige Probleme finden Sie unter Behandeln häufiger Probleme in Azure Cosmos DB for Apache Cassandra.

Nächste Schritte