Cassandra-Benutzeroberfläche

Auf dieser Seite werden die Architekturen von Apache Cassandra und Spanner verglichen. Außerdem erfahren Sie mehr über die Funktionen und Einschränkungen der Spanner-Cassandra-Schnittstelle. Es wird davon ausgegangen, dass Sie mit Cassandra vertraut sind und vorhandene Anwendungen migrieren oder neue Anwendungen entwerfen möchten, während Sie Spanner als Datenbank verwenden.

Cassandra und Spanner sind beide verteilte Datenbanken im großen Maßstab, die für Anwendungen entwickelt wurden, die hohe Skalierbarkeit und niedrige Latenz erfordern. Beide Datenbanken können anspruchsvolle NoSQL-Arbeitslasten unterstützen. Spanner bietet jedoch erweiterte Funktionen für die Datenmodellierung, Abfrage und Transaktionsvorgänge. Weitere Informationen dazu, wie Spanner die Kriterien für NoSQL-Datenbanken erfüllt, finden Sie unter Spanner für nicht relationale Arbeitslasten.

Wichtige Konzepte

In diesem Abschnitt werden die wichtigsten Konzepte von Cassandra und Spanner verglichen.

Terminologie

Cassandra Spanner
Cluster Instanz

Ein Cassandra-Cluster entspricht einer Spanner-Instanz – einer Sammlung von Servern und Speicherressourcen. Da Spanner ein verwalteter Dienst ist, müssen Sie die zugrunde liegende Hardware oder Software nicht konfigurieren. Sie müssen nur die Anzahl der Knoten angeben, die Sie für Ihre Instanz reservieren möchten, oder Autoscaling verwenden, um die Instanz automatisch zu skalieren. Eine Instanz fungiert als Container für Ihre Datenbanken. Sie wählen die Datenreplikationstopologie (regional, biregional oder multiregional) auch auf Instanzebene aus.
Keyspace Datenbank

Ein Cassandra-Schlüsselbereich entspricht einer Spanner-Datenbank, die eine Sammlung von Tabellen und anderen Schemaelementen (z. B. Indexe und Rollen) ist. Im Gegensatz zu einem Keyspace müssen Sie den Replikationsort nicht konfigurieren. Spanner repliziert Ihre Daten automatisch in die Region, die in Ihrer Instanz angegeben ist.
Tabelle Tabelle

Sowohl in Cassandra als auch in Spanner sind Tabellen eine Sammlung von Zeilen, die durch einen im Tabellenschema angegebenen Primärschlüssel identifiziert werden.
Partition Aufteilen

Sowohl Cassandra als auch Spanner werden durch Sharding von Daten skaliert. In Cassandra wird jeder Shard als Partition bezeichnet, in Spanner als Split. Cassandra verwendet Hash-Partitionierung. Das bedeutet, dass jede Zeile unabhängig einem Speicherknoten zugewiesen wird, basierend auf einem Hash des Primärschlüssels. Spanner ist bereichsweise partitioniert. Das bedeutet, dass Zeilen, die im Primärschlüsselbereich zusammenhängen, auch im Speicher zusammenhängen (mit Ausnahme von Split-Grenzen). Spanner übernimmt das Aufteilen und Zusammenführen von Daten basierend auf Last und Speicher. Dies ist für die Anwendung transparent. Im Gegensatz zu Cassandra sind Bereichsscans über ein Präfix des Primärschlüssels in Spanner effizient.
Zeile Zeile

Sowohl in Cassandra als auch in Spanner ist eine Zeile eine Sammlung von Spalten, die eindeutig durch einen Primärschlüssel identifiziert werden. Wie Cassandra unterstützt auch Spanner zusammengesetzte Primärschlüssel. Im Gegensatz zu Cassandra wird in Spanner nicht zwischen dem Partitionsschlüssel und den Clustering-Spalten unterschieden, da Daten bereichsweise fragmentiert werden. In Spanner gibt es nur Clustering-Spalten. Die Partitionierung wird im Hintergrund verwaltet.
Spalte Spalte

Sowohl in Cassandra als auch in Spanner ist eine Spalte eine Gruppe von Datenwerten desselben Typs. Für jede Zeile einer Tabelle gibt es einen Wert. Weitere Informationen zum Vergleichen von Cassandra-Spaltentypen mit Spanner finden Sie unter Datentypen.

Architektur

Ein Cassandra-Cluster besteht aus einer Reihe von Servern und dem zugehörigen Speicher. Eine Hash-Funktion ordnet Zeilen aus einem Partitionsschlüsselbereich einem virtuellen Knoten (VNode) zu. Jedem Server wird dann nach dem Zufallsprinzip eine Reihe von VNodes zugewiesen, um einen Teil des Clusterschlüsselbereichs bereitzustellen. Der Speicher für die V-Knoten ist lokal an den Bereitstellungsknoten angehängt. Clienttreiber stellen eine direkte Verbindung zu den Serving-Knoten her und übernehmen den Lastenausgleich und das Abfragerouting.

Eine Spanner-Instanz besteht aus einer Reihe von Servern in einer Replikationstopologie. Spanner unterteilt jede Tabelle dynamisch in Zeilenbereiche basierend auf der CPU- und Festplattennutzung. Shards werden Rechenknoten zur Bereitstellung zugewiesen. Die Daten werden physisch in Colossus, dem verteilten Dateisystem von Google, getrennt von den Rechenknoten gespeichert. Clienttreiber stellen eine Verbindung zu den Frontend-Servern von Spanner her, die das Anforderungsrouting und das Load-Balancing ausführen. Weitere Informationen finden Sie im Whitepaper Lebensdauer von Lese- und Schreibvorgängen in Spanner.

Auf übergeordneter Ebene lassen sich beide Architekturen skalieren, wenn dem zugrunde liegenden Cluster Ressourcen hinzugefügt werden. Durch die Trennung von Compute und Speicher in Spanner kann die Last zwischen den Compute-Knoten schneller neu verteilt werden, wenn sich die Arbeitslast ändert. Im Gegensatz zu Cassandra sind bei Shard-Verschiebungen keine Datenübertragungen erforderlich, da die Daten auf Colossus verbleiben. Außerdem ist die bereichsbasierte Partitionierung von Spanner möglicherweise besser für Anwendungen geeignet, bei denen Daten nach dem Partitionierungsschlüssel sortiert werden. Die Kehrseite der bereichsbasierten Partitionierung ist, dass Arbeitslasten, die an ein Ende des Schlüsselbereichs schreiben (z. B. Tabellen, die nach dem aktuellen Zeitstempel indexiert werden), Hotspots aufweisen können, wenn keine zusätzlichen Schemadesigns berücksichtigt werden. Weitere Informationen zu Techniken zur Vermeidung von Hotspots finden Sie unter Best Practices für Schemadesign.

Konsistenz

Bei Cassandra müssen Sie für jeden Vorgang eine Konsistenzebene angeben. Wenn Sie die Konsistenzebene „Quorum“ verwenden, muss eine Mehrheit der Replikatknoten auf den Koordinatorknoten antworten, damit der Vorgang als erfolgreich betrachtet wird. Wenn Sie die Konsistenzebene „one“ verwenden, benötigt Cassandra einen einzelnen Replikatknoten, um zu antworten, damit der Vorgang als erfolgreich betrachtet wird.

Spanner bietet hohe Konsistenz. Die Spanner API stellt dem Client keine Replikate zur Verfügung. Spanner-Clients interagieren mit Spanner, als wäre es eine Datenbank auf einem einzelnen Computer. Ein Schreibvorgang wird immer in eine Mehrheit der Replikate geschrieben, bevor Spanner dem Nutzer den Erfolg meldet. Bei allen nachfolgenden Lesevorgängen werden die neu geschriebenen Daten berücksichtigt. Anwendungen können einen Snapshot der Datenbank zu einem bestimmten Zeitpunkt in der Vergangenheit lesen. Dies kann im Vergleich zu starken Lesevorgängen zu einer besseren Leistung führen. Weitere Informationen zu den Konsistenzeigenschaften von Spanner finden Sie unter Transaktionen.

Spanner wurde entwickelt, um die Konsistenz und Verfügbarkeit zu unterstützen, die in groß angelegten Anwendungen erforderlich sind. Spanner bietet strikte Konsistenz im großen Maßstab und mit hoher Leistung. Für Anwendungsfälle, in denen dies erforderlich ist, unterstützt Spanner Snapshot-Lesevorgänge (veraltet), bei denen die Anforderungen an die Aktualität gelockert werden.

Cassandra-Schnittstelle

Mit der Cassandra-Schnittstelle können Sie die vollständig verwaltete, skalierbare und hochverfügbare Infrastruktur von Spanner mit vertrauten Cassandra-Tools und ‑Syntax nutzen. Auf dieser Seite erfahren Sie mehr über die Funktionen und Einschränkungen der Cassandra-Schnittstelle.

Vorteile der Cassandra-Schnittstelle

  • Portabilität: Die Cassandra-Schnittstelle bietet Zugriff auf die gesamte Bandbreite der Spanner-Funktionen mit Schemas, Abfragen und Clients, die mit Cassandra kompatibel sind. Dadurch wird die Migration einer auf Spanner basierenden Anwendung in eine andere Cassandra-Umgebung oder umgekehrt vereinfacht. Diese Portabilität bietet Flexibilität bei der Bereitstellung und unterstützt Szenarien zur Notfallwiederherstellung, z. B. einen Stressed Exit.
  • Vertrautheit: Wenn Sie bereits Cassandra verwenden, können Sie schnell mit Spanner loslegen, da viele der CQL-Anweisungen und -Typen identisch sind.
  • Kompromisslos Spanner: Da die Cassandra-Schnittstelle auf der vorhandenen Grundlage von Spanner basiert, bietet sie alle Vorteile von Spanner in Bezug auf Verfügbarkeit, Konsistenz und Preis-Leistungs-Verhältnis, ohne dass Sie auf die Funktionen des ergänzenden GoogleSQL-Ökosystems verzichten müssen.

CQL-Kompatibilität

  • Unterstützung für CQL-Dialekt: Spanner bietet eine Teilmenge des CQL-Dialekts, einschließlich Data Query Language (DQL), Data Manipulation Language (DML), Lightweight Transactions (LWT) sowie Aggregat- und Datums-/Uhrzeitfunktionen.

  • Unterstützte Cassandra-Funktionen: Die Cassandra-Schnittstelle unterstützt viele der am häufigsten verwendeten Funktionen von Cassandra. Dazu gehören die wichtigsten Teile des Schemas und des Typsystems, viele gängige Abfrageformen, eine Vielzahl von Funktionen und Operatoren sowie die wichtigsten Aspekte des Systemkatalogs von Cassandra. Anwendungen können viele Cassandra-Clients oder -Treiber verwenden, indem sie über die Spanner-Implementierung des Cassandra-Wire-Protokolls eine Verbindung herstellen.

  • Unterstützung für Client- und Wire-Protokolle: Spanner unterstützt die wichtigsten Abfragefunktionen des Cassandra-Wire-Protokolls v4 mit dem Cassandra-Adapter, einem einfachen Client, der parallel zu Ihrer Anwendung ausgeführt wird. So können viele Cassandra-Clients unverändert mit einer Spanner-Datenbank mit Cassandra-Schnittstelle verwendet werden, während der globale Endpunkt und die Verbindungsverwaltung von Spanner sowie die IAM-Authentifizierung genutzt werden.

Unterstützte Cassandra-Datentypen

In der folgenden Tabelle sind die unterstützten Cassandra-Datentypen aufgeführt und jeder Datentyp wird dem entsprechenden Spanner GoogleSQL-Datentyp zugeordnet.

Unterstützte Cassandra-Datentypen Spanner-GoogleSQL-Datentyp
Numerische Typen tinyint (vorzeichenbehaftete 8-Bit-Ganzzahl) INT64 (vorzeichenbehaftete 64-Bit-Ganzzahl)

Spanner unterstützt einen einzelnen 64‑Bit-Datentyp für signierte Ganzzahlen.
smallint (vorzeichenbehaftete 16-Bit-Ganzzahl)
int (vorzeichenbehaftete 32-Bit-Ganzzahl)
bigint (vorzeichenbehaftete 64-Bit-Ganzzahl)
float (32-Bit-IEEE-754-Gleitkommazahl) FLOAT32 (32-Bit-IEEE-754-Gleitkommazahl)
double (64-Bit-IEEE-754-Gleitkommazahl) FLOAT64 (64-Bit-IEEE-754-Gleitkommazahl)
decimal Verwenden Sie für Dezimalzahlen mit fester Genauigkeit den Datentyp NUMERIC (Genauigkeit 38, Skalierung 9).
varint (Ganzzahl mit variabler Genauigkeit)
Stringtypen text STRING(MAX)

Sowohl text als auch varchar speichern und validieren UTF-8-Strings. In Spanner muss für STRING-Spalten die maximale Länge angegeben werden. Dies hat keine Auswirkungen auf den Speicherplatz. Es dient nur zu Validierungszwecken.
varchar
ascii STRING(MAX)
uuid STRING(MAX)
inet STRING(MAX)
blob BYTES(MAX)

Verwenden Sie den Datentyp BYTES, um Binärdaten zu speichern.
Datums- und Uhrzeittypen date DATE
time INT64

Spanner unterstützt keinen dedizierten Zeitdatentyp. Verwenden Sie INT64, um die Dauer in Nanosekunden zu speichern.
timestamp TIMESTAMP
timeuuid STRING(MAX)
Containertypen set ARRAY

Spanner unterstützt keinen dedizierten Datentyp set. Verwenden Sie ARRAY-Spalten, um eine set darzustellen.
list ARRAY

Verwenden Sie ARRAY, um eine Liste von typisierten Objekten zu speichern.
map JSON

Spanner unterstützt keinen dedizierten Kartentyp. Verwenden Sie JSON-Spalten, um Karten darzustellen.
Andere Typen boolean BOOL
counter INT64

Datentyp-Annotationen

Mit der Spaltenoption cassandra_type können Sie Zuordnungen zwischen den Cassandra- und Spanner-Datentypen definieren. Wenn Sie in Spanner eine Tabelle erstellen, mit der Sie über Cassandra-kompatible Abfragen interagieren möchten, können Sie mit der Option cassandra_type den entsprechenden Cassandra-Datentyp für jede Spalte angeben. Diese Zuordnung wird dann von Spanner verwendet, um Daten bei der Übertragung zwischen den beiden Datenbanksystemen richtig zu interpretieren und zu konvertieren.

Angenommen, es gibt eine Tabelle in Cassandra mit dem folgenden Schema:

CREATE TABLE Albums (
  albumId uuid,
  title varchar,
  artists set<varchar>,
  tags  map<varchar, varchar>,
  numberOfSongs tinyint,
  releaseDate date,
  copiesSold bigint,
  score frozen<set<int>>
  ....
  PRIMARY KEY(albumId)
)

In Spanner verwenden Sie Typanmerkungen, um Cassandra-Datentypen zuzuordnen, wie im Folgenden dargestellt:

CREATE TABLE Albums (
  albumId       STRING(MAX) OPTIONS (cassandra_type = 'uuid'),
  title         STRING(MAX) OPTIONS (cassandra_type = 'varchar'),
  artists       ARRAY<STRING(max)> OPTIONS (cassandra_type = 'set<varchar>'),
  tags          JSON OPTIONS (cassandra_type = 'map<varchar, varchar>'),
  numberOfSongs INT64 OPTIONS (cassandra_type = 'tinyint'),
  releaseDate   DATE OPTIONS (cassandra_type = 'date'),
  copiesSold    INT64 OPTIONS (cassandra_type = 'bigint'),
  score         ARRAY<INT64> OPTIONS (cassandra_type = 'frozen<set<int>>')
  ...
) PRIMARY KEY (albumId);

Im vorherigen Beispiel wird mit der OPTIONS-Anweisung der Spanner-Datentyp der Spalte dem entsprechenden Cassandra-Datentyp zugeordnet.

  • albumId (Spanner STRING(MAX)) wird in Cassandra uuid zugeordnet.
  • title (Spanner STRING(MAX)) wird in Cassandra varchar zugeordnet.
  • artists (Spanner ARRAY<STRING(MAX)>) wird in Cassandra set<varchar> zugeordnet.
  • tags (Spanner JSON) wird in Cassandra map<varchar,varchar> zugeordnet.
  • numberOfSongs (Spanner INT64) wird in Cassandra tinyint zugeordnet.
  • releaseDate (Spanner DATE) wird in Cassandra date zugeordnet.
  • copiesSold (Spanner INT64) wird in Cassandra bigint zugeordnet.
  • score (Spanner ARRAY<INT64>) wird in Cassandra frozen<set<int>> zugeordnet.
Option cassandra_type ändern

Mit der ALTER TABLE-Anweisung können Sie die Option cassandra_type für vorhandene Spalten hinzufügen oder ändern.

Verwenden Sie die folgende Anweisung, um einer Spalte, die noch keine cassandra_type-Option hat, eine hinzuzufügen:

ALTER TABLE Albums ALTER COLUMN uuid SET OPTIONS (cassandra_type='uuid');

In diesem Beispiel wird die Spalte uuid in der Tabelle „Albums“ aktualisiert. Die Option cassandra_type ist auf uuid festgelegt.

Wenn Sie eine vorhandene cassandra_type-Option ändern möchten, verwenden Sie die ALTER TABLE-Anweisung mit dem neuen cassandra_type-Wert. Wenn Sie beispielsweise die cassandra_type der Spalte numberOfSongs in der Tabelle „Albums“ von tinyint in bigint ändern möchten, verwenden Sie die folgende Anweisung:

ALTER TABLE Albums ALTER COLUMN numberOfSongs SET OPTIONS (cassandra_type='bigint');

Sie dürfen nur die folgenden Typen ändern:

Von An
tinyint smallint, int, bigint
smallint int, bigint
int bigint
float double
Text varchar
ascii varchar, text
Direkte und differenzierte Zuordnungen

In vielen Fällen ist die Zuordnung zwischen Spanner- und Cassandra-Datentypen unkompliziert. Beispiel: Ein Spanner-STRING(MAX) wird einem Cassandra-varchar zugeordnet und ein Spanner-INT64 einem Cassandra-bigint.

Es gibt jedoch Situationen, in denen die Zuordnung mehr Überlegung und Anpassung erfordert. Sie müssen beispielsweise eine Cassandra-smallint einer Spanner-INT64 zuordnen.

Unterstützte Cassandra-Funktionen

In diesem Abschnitt werden die in Spanner unterstützten Cassandra-Funktionen aufgeführt.

In der folgenden Liste sehen Sie, welche Cassandra-Funktionen von Spanner unterstützt werden.

Time to Live (TTL)

Wenn Sie von Cassandra migrieren, fügen Sie Ihrer Spanner-Tabelle eine Richtlinie zum Löschen von Zeilen hinzu, damit Sie die Option USING TTL in den Anweisungen INSERT oder UPDATE oder die Spanner-TTL verwenden können.

Die Spanner-TTL-Logik wird auf Zeilenebene ausgeführt, im Gegensatz zu Cassandra, wo die TTL-Logik auf Zellebene angewendet werden kann. Wenn Sie die Spanner-TTL verwenden möchten, müssen Sie eine Zeitstempelspalte und ein Zeitintervall in die Richtlinie zum Löschen von Zeilen einfügen. Spanner löscht die Zeile, nachdem sie die angegebene Dauer relativ zum Zeitstempel überschritten hat.

Das Löschen von Daten mit Spanner TTL erfolgt nicht sofort. Ein asynchroner Hintergrundprozess löscht abgelaufene Zeilen. Das kann bis zu 72 Stunden dauern.

Weitere Informationen finden Sie unter TTL für Cassandra-Daten aktivieren.

Nicht unterstützte Cassandra-Funktionen in Spanner

Die Cassandra-Schnittstelle bietet die Funktionen von Spanner über Schemas, Typen, Abfragen und Clients, die mit Cassandra kompatibel sind. Nicht alle Funktionen von Cassandra werden unterstützt. Die Migration einer vorhandenen Cassandra-Anwendung zu Spanner, selbst wenn die Cassandra-Schnittstelle verwendet wird, erfordert wahrscheinlich einige Überarbeitungen, um nicht unterstützte Cassandra-Funktionen oder Verhaltensunterschiede wie die Abfrageoptimierung oder das Design des Primärschlüssels zu berücksichtigen. Nach der Migration können Ihre Arbeitslasten jedoch die Zuverlässigkeit und die einzigartigen Multi-Modell-Funktionen von Spanner nutzen.

Die folgende Liste enthält weitere Informationen zu nicht unterstützten Cassandra-Funktionen:

  • Einige CQL-Sprachfunktionen werden nicht unterstützt: benutzerdefinierte Typen und Funktionen, Write-Timestamp.
  • Spanner- und Google Cloud Steuerungsebene: Datenbanken mit Cassandra-Schnittstellen verwenden Spanner- und Google Cloud-Tools, um Instanzen bereitzustellen, zu schützen, zu überwachen und zu optimieren. Spanner unterstützt keine Tools wie nodetool für administrative Aktivitäten.

DDL-Unterstützung

CQL-DDL-Anweisungen werden über die Cassandra-Schnittstelle nicht direkt unterstützt. Für DDL-Änderungen müssen Sie die Spanner Google Cloud Console, einen gcloud-Befehl oder Clientbibliotheken verwenden.

Verbindung

  • Cassandra-Clientunterstützung

    Mit Spanner können Sie von einer Vielzahl von Clients aus eine Verbindung zu Datenbanken herstellen:

Zugriffssteuerung mit Identity and Access Management

Sie benötigen die Berechtigungen spanner.databases.adapt, spanner.databases.select und spanner.databases.write, um Lese- und Schreibvorgänge für den Cassandra-Endpunkt auszuführen. Weitere Informationen finden Sie in der IAM-Übersicht.

Weitere Informationen zum Zuweisen von Spanner-IAM-Berechtigungen finden Sie unter IAM-Rollen anwenden.

Monitoring

Spanner bietet die folgenden Messwerte, mit denen Sie den Cassandra-Adapter überwachen können:

  • spanner.googleapis.com/api/adapter_request_count: Erfasst und gibt die Anzahl der Adapteranfragen an, die Spanner pro Sekunde ausführt, oder die Anzahl der Fehler, die auf dem Spanner-Server pro Sekunde auftreten.
  • spanner.googleapis.com/api/adapter_request_latencies: Erfasst und gibt die Zeit an, die Spanner für die Verarbeitung von Adapteranfragen benötigt.

Sie können ein benutzerdefiniertes Cloud Monitoring-Dashboard erstellen, um Messwerte für den Cassandra-Adapter anzuzeigen und zu überwachen. Das benutzerdefinierte Dashboard enthält die folgenden Diagramme:

  • P99-Anfragelatenzen: Die Verteilung des 99. Perzentils der Serveranfragelatenzen pro message_type für Ihre Datenbank.

  • P50-Anfragelatenzen: Die Verteilung der Serveranfragelatenzen des 50. Perzentils pro message_type für Ihre Datenbank.

  • Anzahl der API-Anfragen nach Nachrichtentyp: Die Anzahl der API-Anfragen pro message_type für Ihre Datenbank.

  • Anzahl der API-Anfragen nach Vorgangstyp: Die Anzahl der API-Anfragen pro op_type für Ihre Datenbank.

  • Fehlerraten: Die API-Fehlerraten für Ihre Datenbank.

Google Cloud Console

  1. Laden Sie die Datei cassandra-adapter-dashboard.json herunter. Diese Datei enthält die Informationen, die zum Erstellen eines benutzerdefinierten Dashboards in Monitoring erforderlich sind.

  2. Öffnen Sie in der Google Cloud Console die Seite Dashboards :

    Dashboards aufrufen

    Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Monitoring ist.

  3. Klicken Sie auf der Seite Dashboard-Übersicht auf Benutzerdefiniertes Dashboard erstellen.
  4. Klicken Sie in der Dashboard-Symbolleiste auf das Symbol Dashboard-Einstellungen. Wählen Sie dann JSON und anschließend JSON-Editor aus.
  5. Kopieren Sie im Bereich JSON-Editor den Inhalt der heruntergeladenen Datei cassandra-adapter-dashboard.json und fügen Sie ihn in den Editor ein.
  6. Klicken Sie auf Änderungen übernehmen, um die Änderungen auf das Dashboard anzuwenden. Wenn Sie dieses Dashboard nicht verwenden möchten, kehren Sie zur Seite „Dashboards – Übersicht“ zurück.
  7. Klicken Sie nach dem Erstellen des Dashboards auf Filter hinzufügen. Wählen Sie dann entweder project_id oder instance_id aus, um den Cassandra-Adapter zu überwachen.

gcloud-CLI

  1. Laden Sie die Datei cassandra-adapter-dashboard.json herunter. Diese Datei enthält die Informationen, die zum Erstellen eines benutzerdefinierten Dashboards in Monitoring erforderlich sind.

  2. Verwenden Sie den Befehl gcloud monitoring dashboards create, um ein Dashboard in einem Projekt zu erstellen:

    gcloud monitoring dashboards create --config-from-file=cassandra-adapter-dashboard.json

    Weitere Informationen finden Sie in der Referenz zu gcloud monitoring dashboards create.

Außerdem sind die folgenden Spanner-Messwerte hilfreich für die Überwachung des Cassandra-Adapters:

Eine vollständige Liste der System-Insights finden Sie unter Instanzen mit System-Insights überwachen. Weitere Informationen zum Monitoring Ihrer Spanner-Ressourcen finden Sie unter Instanzen mit Cloud Monitoring überwachen.

Preise

Für die Verwendung des Cassandra-Endpunkts fallen keine zusätzlichen Gebühren an. Ihnen werden die Standardpreise für Spanner für die von Ihrer Instanz verwendete Rechenkapazität und den von Ihrer Datenbank verwendeten Speicherplatz berechnet.

Weitere Informationen finden Sie unter Spanner-Preise.

Nächste Schritte