Häufig gestellte Fragen zu Azure Cosmos DB for Apache Cassandra

Wichtige Unterschiede zwischen der API für den Cassandra-Dienst und Apache Cassandra:

• Apache Cassandra empfiehlt für Partitionsschlüssel eine Größenbeschränkung von 100 MB. Die API für Cassandra für Azure Cosmos DB lässt bis zu 20 GB pro Partition zu.
• Apache Cassandra ermöglicht Ihnen das Deaktivieren von dauerhaften Commits. Sie können das Schreiben in das Commitprotokoll überspringen und direkt in die In-Memory-Datenstruktur wechseln. Dies kann zu Datenverlust führen, wenn der Knoten ausfällt, bevor die In-Memory-Datenstrukturen in SSTables auf dem Datenträger geleert werden. Azure Cosmos DB führt immer dauerhafte Commits aus, um Datenverluste zu verhindern.
• Bei Apache Cassandra kann es zu einer verringerten Leistung kommen, wenn die Workload viele Ersetzungen oder Löschungen umfasst. Der Grund dafür sind Tombstones, die von der Leseworkload übersprungen werden müssen, um die neuesten Daten abzurufen. Bei der API für Cassandra kommt es nicht zu einer verringerten Leseleistung, wenn die Workload viele Ersetzungen oder Löschungen umfasst.
• In Szenarien mit hohen Ersetzungsworkloads muss die Komprimierung ausgeführt werden, um SSTables auf dem Datenträger zusammenzuführen. (Die Zusammenführung ist erforderlich, weil Apache Cassandra-Schreibvorgänge nur angefügt werden. Mehrere Aktualisierungen werden als einzelne SSTable-Einträge gespeichert, die regelmäßig zusammengeführt werden müssen.) Diese Situation kann auch zu einer geringeren Leseleistung während der Komprimierung führen. Bei der API für Cassandra kommt es nicht zu dieser Leistungsbeeinträchtigung, weil die API keine Komprimierung implementiert.
• Das Festlegen eines Replikationsfaktors von „1“ ist mit Apache Cassandra möglich. Es führt jedoch zu geringer Verfügbarkeit, wenn der einzige Knoten mit den Daten ausfällt. Dies ist bei der API für Cassandra für Azure Cosmos DB kein Problem, weil immer der Replikationsfaktor „4“ (Quorum von „3“) verwendet wird.
• Das Hinzufügen oder Entfernen von Knoten in Apache Cassandra erfordert manuelle Eingriffe sowie eine hohe CPU-Auslastung auf dem neuen Knoten, während vorhandene Knoten einige ihrer Tokenbereiche auf den neuen Knoten verschieben. Das ist auch bei der Außerbetriebnahme eines vorhandenen Knotens der Fall. Die API für Cassandra kann jedoch aufskaliert werden, ohne dass Probleme beim Dienst oder bei der Anwendung auftreten.
• Sie müssen nicht wie in Apache Cassandra num_tokens für jeden Knoten in den Clustern festlegen. Knoten und Tokenbereiche werden von Azure Cosmos DB vollständig verwaltet.
• Die API für Cassandra ist vollständig verwaltet. Sie benötigen keine Befehle wie „Repair“ und „Decommission“, die in Apache Cassandra verwendet werden.

Die API für Cassandra für Azure Cosmos DB unterstützt die Cassandra Query Language (CQL), Version 3.x. Die CQL-Kompatibilität basiert auf dem öffentlichen Apache Cassandra-GitHub-Repository. Wenn Sie Feedback zur Unterstützung anderer Protokolle haben, senden Sie eine E-Mail an askcosmosdbcassandra@microsoft.com.

Azure Cosmos DB legt den Standarddurchsatz für Ihren Container abhängig davon fest, ob Sie die Tabelle im Azure-Portal oder über CQL erstellt haben.

Azure Cosmos DB bietet Garantien für Leistung und Wartezeit (mit Obergrenzen für Vorgänge). Diese Garantien sind möglich, wenn das Modul Governance für die Vorgänge des Mandanten erzwingen kann. Durch Festlegen des Durchsatzes wird sichergestellt, dass Sie den garantierten Durchsatz und die garantierte Wartezeit erhalten. Hierzu wird die entsprechende Kapazität von der Plattform reserviert, um den Erfolg des Vorgangs zu gewährleisten. Sie können den Durchsatz flexibel anpassen, um von Schwankungen bei der Nutzung Ihrer Anwendung zu profitieren und Kosten zu sparen.

Das Durchsatzkonzept wird im Artikel Anforderungseinheiten in Azure Cosmos DB erläutert. Der Durchsatz für eine Tabelle wird gleichmäßig auf die zugrunde liegenden physischen Partitionen verteilt.

Azure Cosmos DB verwendet als Einheit für den Durchsatz Anforderungseinheiten pro Sekunde (Request Units per Second, RU/s). Für über CQL erstellte Tabellen lautet der Standardwert 400 RUs. Sie können die Anforderungseinheiten im Azure-Portal ändern.

CQL

CREATE TABLE keyspaceName.tablename (user_id int PRIMARY KEY, lastname text) WITH cosmosdb_provisioned_throughput=1200

.NET

int provisionedThroughput = 400;
var simpleStatement = new SimpleStatement($"CREATE TABLE {keyspaceName}.{tableName} (user_id int PRIMARY KEY, lastname text)");
var outgoingPayload = new Dictionary<string, byte[]>();
outgoingPayload["cosmosdb_provisioned_throughput"] = Encoding.UTF8.GetBytes(provisionedThroughput.ToString());
simpleStatement.SetOutgoingPayload(outgoingPayload);

Azure Cosmos DB bietet Garantien für Leistung und Wartezeit (mit Obergrenzen für Vorgänge). Diese Garantien sind möglich, wenn das Modul Governance für die Vorgänge des Mandanten erzwingen kann. Durch Festlegen des Durchsatzes wird sichergestellt, dass Sie den garantierten Durchsatz und die garantierte Wartezeit erhalten. Hierzu wird die entsprechende Kapazität von der Plattform reserviert, um den Erfolg des Vorgangs zu gewährleisten.

Wenn diese Kapazität überschritten wird, erhalten Sie die folgende Fehlermeldung, aus der hervorgeht, dass die Kapazität aufgebraucht wurde:

0x1001 Überladen: Die Anforderung kann nicht verarbeitet werden – „Anforderungsrate ist groß“.

Es ist wichtig, dass Sie überprüfen, welche Vorgänge (mit welchem Umfang) dieses Problem verursachen. Informationen über die verbrauchte Kapazität oberhalb der bereitgestellten Kapazität bieten die Metriken im Azure-Portal. Sie müssen dann sicherstellen, dass die Kapazität von allen zugrunde liegenden Partitionen nahezu gleichmäßig verbraucht wird. Wenn Sie feststellen, dass der größte Teil des Durchsatzes von einer Partition verbraucht wird, führt dies zu einer ungleichmäßigen Arbeitsauslastung.

Es sind Metriken verfügbar, die Ihnen zeigen, wie der Durchsatz von einzelnen Partitionen oder in aggregierter Form über Stunden, über Tage und pro Woche (sieben Tage) verwendet wird. Weitere Informationen finden Sie unter Überwachen und Debuggen mit Metriken in Azure Cosmos DB.

Diagnoseprotokolle werden im Artikel Diagnoseprotokollierung für Azure Cosmos DB erläutert.

Ja. Der Partitionsschlüssel wird verwendet, um die Entität am richtigen Speicherort zu platzieren. In Azure Cosmos DB wird er zum Suchen der richtigen logischen Partition auf einer physischen Partition verwendet. Das Konzept der Partitionierung wird im Artikel Partitionieren und Skalieren in Azure Cosmos DB sehr gut erläutert. Die wesentliche Lektion ist hierbei, dass eine logische Partition die 20-GB-Grenze nicht überschreiten sollte.

Azure Cosmos DB ist ein auf einer Vereinbarung zum Servicelevel (Service-Level Agreement, SLA) basierendes System, das unbegrenzte Skalierbarkeit mit Garantien für Wartezeit, Durchsatz, Verfügbarkeit und Konsistenz bietet. Dieser unbegrenzte Speicher basiert auf einer horizontalen Skalierung der Daten mit der Partitionierung als grundlegendem Konzept. Das Konzept der Partitionierung wird im Artikel Partitionieren und Skalieren in Azure Cosmos DB sehr gut erläutert.

Sie sollten das Limit von 20 GB für die Anzahl von Entitäten oder Elementen pro logischer Partition einhalten. Um sicherzustellen, dass Ihre Anwendung gut skaliert werden kann, sollten Sie keine Hot Partition erstellen, indem Sie alle Informationen in einer Partition speichern und abfragen. Dieser Fehler kann nur bei einer Datenscherung auftreten, also wenn Sie über viele Daten für einen Partitionsschlüssel (mehr als 20 GB) verfügen. Sie können die Verteilung der Daten mithilfe des Storage-Portals ermitteln. Um diesen Fehler zu beheben, müssen Sie die Tabelle neu erstellen und einen präzisen Primärschlüssel (Partitionsschlüssel) auswählen, der eine bessere Verteilung der Daten ermöglicht.

Azure Cosmos DB kann eine beliebige Datenmenge speichern, indem der Speicher horizontal hochskaliert wird. Diese Speicherung ist unabhängig vom Durchsatz. Ja. Grundsätzlich können Sie die API für Cassandra nur zum Speichern und Abrufen von Schlüsseln und Werten verwenden, indem Sie den richtigen Primär-/Partitionsschlüssel angeben. Diese einzelnen Schlüssel erhalten jeweils ihre eigene logische Partition und befinden sich auf einer physischen Partition.

Ja, mit der API für Cassandra können mehrere Tabellen erstellt werden. Jede dieser Tabellen wird bei Durchsatz und Speicherung als Einheit behandelt.

Azure Cosmos DB ist ein ressourcengesteuertes System für Aktivitäten auf Daten- und Steuerungsebene. Container (wie z. B. Sammlungen und Tabellen) sind Laufzeitentitäten, die für eine bestimmte Durchsatzkapazität bereitgestellt werden. Die Erstellung dieser Container in schneller Folge ist eine unerwartete Aktivität und wird möglicherweise gedrosselt. Wenn Sie Tests durchführen, bei denen Tabellen sofort abgelegt oder erstellt werden, sollten Sie diese Vorgänge voneinander trennen.

Es besteht keine physische Beschränkung für die Anzahl von Tabellen. Wenn Sie sehr viele Tabellen (mit einer konstanten Gesamtgröße von mehr als 10 TB an Daten) erstellen müssen, also nicht nur die übliche Anzahl von Dutzenden oder Hunderten, senden Sie eine E-Mail an askcosmosdbcassandra@microsoft.com.

Es besteht keine physische Beschränkung für die Anzahl von Keyspaces, weil es sich dabei um Metadatencontainer handelt. Wenn Sie über eine große Anzahl von Keyspaces verfügen, senden Sie eine E-Mail an askcosmosdbcassandra@microsoft.com.

Ja. Unter der Voraussetzung, dass die Partitionen gleichmäßig verteilt sind, wird die Speicherkapazität automatisch verwaltet und erhöht, wenn Sie weitere Daten hinzufügen. Daher können Sie problemlos beliebig viele Daten importieren, ohne Knoten verwalten und bereitstellen zu müssen. Wenn Sie jedoch ein hohes sofortiges Datenwachstum erwarten, ist es sinnvoller, den erwarteten Durchsatz direkt bereitzustellen, statt mit einer kleineren Menge zu beginnen und diese sofort zu erhöhen.

Die API für Cassandra für Azure Cosmos DB bietet zum Ausführen von Vorgängen Kompatibilität auf Protokollebene. Er vereinfacht die Verwaltung, Überwachung und Konfiguration. Als Entwickler/Benutzer müssen Sie sich keine Gedanken über Verfügbarkeit, Tombstones, Schlüsselcache, Zeilencache, Bloomfilter und zahlreiche andere Einstellungen machen. Bei der API für Cassandra steht die Bereitstellung der benötigten Lese- und Schreibleistung ohne Mehraufwand durch Konfiguration und Verwaltung im Mittelpunkt.

Die API für Cassandra vereinfacht die Kapazitätsplanung und die Reaktion auf Elastizitätsanforderungen für Durchsatz und Speicher. Mit Azure Cosmos DB stellen Sie den benötigten Durchsatz bereit. Sie können diesen dann beliebig oft zentral hoch- und herunterskalieren, ohne sich Gedanken über das Hinzufügen, Löschen oder Verwalten von Knoten machen zu müssen. Sie müssen keine Tools für die Knoten- und Clusterverwaltung verwenden.

Azure Cosmos DB bietet aus Gründen der Verfügbarkeit und der geringen Wartezeit bereits eine vorkonfigurierte globale Verteilung. Sie müssen keine Replikate oder andere Elemente einrichten. Schreibvorgänge werden in jeder Region, in der Sie Daten schreiben, immer dauerhaft im Quorum committet, wobei Leistungsgarantien geboten werden.

Azure Cosmos DB bietet Leistungsgarantien für Lese- und Schreibvorgänge sowie für den Durchsatz. Sie müssen sich also keine Sorgen machen, dass Sie die Konfigurationseinstellungen bearbeiten und versehentlich ändern. Diese Einstellungen umfassen den Bloomfilter, die Zwischenspeicherung, Lesereparaturänderungen, „gc_grace“ und „compression memtable_flush_period“.

Ja. TTL wird unterstützt.

Azure Cosmos DB ist ein Plattformdienst, mit dem Sie Ihre Produktivität steigern können, ohne sich Gedanken über die Verwaltung und Überwachung der Infrastruktur zu machen. Sie müssen beispielsweise nicht erst den Knotenstatus, Replikatstatus, GC und Betriebssystemparameter mit verschiedenen Tools überwachen. Sie müssen nur auf den Durchsatz achten, der in den Metriken im Portal angegeben ist, um zu erkennen, ob Ihr Durchsatz gedrosselt wird, und dann können Sie diesen Durchsatz erhöhen oder verringern. Ihre Möglichkeiten:

• Überwachen von SLAs
• Verwenden von Metriken
• Verwenden von Diagnoseprotokollen

Für Clientprogramme wurden die Clienttreiber des Apache Cassandra SDK verwendet, die CQLv3 verwenden. Wenn Sie andere Treiber verwenden oder bei Ihnen Probleme auftreten, senden Sie eine E-Mail an askcosmosdbcassandra@microsoft.com.

Ja. Sie können unter Verwendung der regulären Syntax zusammengesetzte Partitionsschlüssel erstellen.

Nein, sstableloader wird nicht unterstützt.

Derzeit ist Azure Cosmos DB für Cloudumgebungen optimiert und kann ohne zusätzlichen Aufwand betrieben werden. Wenn Sie Kopplung benötigen, senden Sie eine E-Mail mit einer Beschreibung Ihres Szenarios an askcosmosdbcassandra@microsoft.com. Wir arbeiten an einem Angebot, um die Kopplung des lokalen oder cloudbasierten Cassandra-Clusters mit der API für Cassandra für Azure Cosmos DB zu unterstützen.

Azure Cosmos DB bietet zwei kostenlose vollständige Sicherungen, die in Vier-Stunden-Intervallen für alle APIs erstellt werden. Sie müssen also keinen Sicherungszeitplan einrichten.

Sie können die Aufbewahrung und Häufigkeit der Sicherungen selbst verwalten.

Wenn Sie ein Backup wiederherstellen möchten, senden Sie eine E-Mail an askcosmosdbcassandra@microsoft.com oder öffnen Sie einen Supportfall. Informationen zu Sicherungsfunktion finden Sie im Artikel Automatische Onlinesicherung und -wiederherstellung mit Azure Cosmos DB.

Die API für Cassandra nutzt Teile der global verteilten Plattform von Azure Cosmos DB. Aktivieren Sie im Azure-Portal mindestens eine weitere Region für das Konto, um sicherzustellen, dass Ihre Anwendung Ausfallzeiten von Rechenzentren tolerieren kann. Weitere Informationen finden Sie unter Hochverfügbarkeit mit Azure Cosmos DB.

Sie können für das Konto beliebig viele Regionen hinzufügen und steuern, wohin das Failover erfolgen kann, indem Sie eine Failoverpriorität festlegen. Für die Verwendung der Datenbank müssen Sie dafür eine Anwendung bereitstellen. Wenn Sie so vorgehen, treten für Ihre Kunden keine Ausfallzeiten auf.

Nein. Die API für Cassandra unterstützt sekundäre Indizes, die sich ähnlich wie in Apache Cassandra verhalten. Die API indiziert nicht standardmäßig jedes Attribut.

Ja, diese Möglichkeit wird unterstützt. Ausführliche Informationen zum Aktivieren dieser Option finden Sie im Artikel Verwenden des Azure Cosmos DB-Emulators für lokale Entwicklungs- und Testvorgänge.

Informationen zu den Migrationsoptionen finden Sie im Tutorial Migrieren Ihrer Daten zu einem API für Cassandra-Konto in Azure Cosmos DB.

Zugehöriger Inhalt

• Erste Schritte für die elastische Skalierung eines Kontos in Azure Cosmos DB for Apache Cassandra

Nächster Schritt