Migration von Cassandra zu Bigtable mit einem Dual-Write-Proxy

1. Einführung

Bigtable ist ein vollständig verwalteter, leistungsstarker NoSQL-Datenbankdienst, der für große analytische und operative Arbeitslasten entwickelt wurde. Die Migration von vorhandenen Datenbanken wie Apache Cassandra zu Bigtable erfordert oft eine sorgfältige Planung, um Ausfallzeiten und Auswirkungen auf Anwendungen zu minimieren.

In diesem Codelab wird eine Migrationsstrategie von Cassandra zu Bigtable mithilfe einer Kombination aus Proxy-Tools demonstriert:

  1. Cassandra-Bigtable-Proxy:Ermöglicht es Cassandra-Clients und -Tools (z. B. cqlsh oder Treiber), über das CQL-Protokoll (Cassandra Query Language) mit Bigtable zu interagieren, indem Abfragen übersetzt werden.
  2. Datastax Zero Downtime Migration (ZDM) Proxy:Ein Open-Source-Proxy, der sich zwischen Ihrer Anwendung und Ihren Datenbankdiensten (Cassandra als Quelle und Bigtable als Ziel über den Cassandra-Bigtable-Proxy) befindet. Sie orchestriert Dual Writes und verwaltet das Traffic-Routing, sodass die Migration mit minimalen Anwendungsänderungen und Ausfallzeiten möglich ist.
  3. Cassandra Data Migrator (CDM): Ein Open-Source-Tool, das für die Bulk-Migration von Verlaufsdaten aus dem Cassandra-Quellcluster in die Bigtable-Zielinstanz verwendet wird.

Lerninhalte

  • So richten Sie einen einfachen Cassandra-Cluster in Compute Engine ein.
  • So erstellen Sie eine Bigtable-Instanz.
  • So stellen Sie den Cassandra-Bigtable-Proxy bereit und konfigurieren ihn, um ein Cassandra-Schema Bigtable zuzuordnen.
  • So stellen Sie den Datastax ZDM-Proxy für Dual Writes bereit und konfigurieren ihn.
  • So verwenden Sie das Cassandra Data Migrator-Tool, um vorhandene Daten in großen Mengen zu migrieren.
  • Der allgemeine Workflow für eine Proxy-basierte Migration von Cassandra zu Bigtable.

Voraussetzungen

  • Google Cloud-Projekt mit aktivierter Abrechnungsfunktion. Neuen Nutzern steht ein kostenloser Testzeitraum zur Verfügung.
  • Grundlegende Kenntnisse von Google Cloud-Konzepten wie Projekten, Compute Engine, VPC-Netzwerken und Firewallregeln. Grundkenntnisse zu Linux-Befehlszeilentools.
  • Sie benötigen Zugriff auf einen Computer, auf dem die gcloud CLI installiert und konfiguriert ist, oder Sie verwenden die Google Cloud Shell.

In diesem Codelab verwenden wir hauptsächlich VMs in Compute Engine im selben VPC-Netzwerk und in derselben Region, um die Vernetzung zu vereinfachen. Die Verwendung interner IP-Adressen wird empfohlen.

2. Umgebung einrichten

1. Google Cloud-Projekt auswählen oder erstellen

Rufen Sie die Google Cloud Console auf und wählen Sie ein vorhandenes Projekt aus oder erstellen Sie ein neues. Notieren Sie sich Ihre Projekt-ID.

2. Region und Zone auswählen

Wählen Sie eine Region und eine Zone für Ihre Ressourcen aus. Wir verwenden us-central1 und us-central1-c als Beispiele. Definieren Sie diese der Einfachheit halber als Umgebungsvariablen:

export PROJECT_ID="<your-project-id>"
export REGION="us-central1"
export ZONE="us-central1-c"

gcloud config set project $PROJECT_ID
gcloud config set compute/region $REGION
gcloud config set compute/zone $ZONE

3. Erforderliche APIs aktivieren

Achten Sie darauf, dass die Compute Engine API und die Bigtable API für Ihr Projekt aktiviert sind.

gcloud services enable compute.googleapis.com bigtable.googleapis.com bigtableadmin.googleapis.com

4. Firewallregeln konfigurieren

Wir müssen die Kommunikation zwischen unseren VMs im Standard-VPC-Netzwerk über mehrere Ports zulassen:

  • Cassandra-/Proxy-CQL-Port: 9042
  • ZDM-Proxy-Systemdiagnoseport: 14001
  • SSH: 22

Erstellen Sie eine Firewallregel, um internen Traffic auf diesen Ports zuzulassen. Wir verwenden das Tag cassandra-migration, um diese Regel einfach auf relevante VMs anzuwenden.

gcloud compute firewall-rules create allow-migration-internal \
--network=default \
--action=ALLOW \
--rules=tcp:22,tcp:9042,tcp:7000,tcp:14001 \
--source-ranges=10.0.0.0/8 \
--target-tags=cassandra-migration

3. Cassandra-Cluster bereitstellen (Ursprung)

In diesem Codelab richten wir einen einfachen Cassandra-Cluster mit einem Knoten in Compute Engine ein. In der Praxis würden Sie eine Verbindung zu Ihrem vorhandenen Cluster herstellen.

1. GCE-VM für Cassandra erstellen

gcloud compute instances create cassandra-origin \
--machine-type=e2-medium \
--image-family=ubuntu-2204-lts \
--image-project=ubuntu-os-cloud \
--tags=cassandra-migration \
--boot-disk-size=20GB \
--scopes=cloud-platform \
--zone="$ZONE"

SSH-Verbindung zur Cassandra-Instanz herstellen

gcloud compute ssh --zone="$ZONE" "cassandra-origin"

2. Cassandra installieren

# Install Java (Cassandra dependency)
sudo apt-get update
sudo apt-get install -y openjdk-11-jre-headless

# Add Cassandra repository
echo "deb https://debian.cassandra.apache.org 41x main" | sudo tee -a /etc/apt/sources.list.d/cassandra.sources.list
curl https://downloads.apache.org/cassandra/KEYS | sudo apt-key add -

# Install Cassandra
sudo apt update
sudo apt install -y cassandra

# (Optional) Verify Cassandra is running
sudo systemctl status cassandra

3. Cassandra konfigurieren

Wir müssen Cassandra so konfigurieren, dass sie im privaten Netzwerk zugänglich ist.

Rufen Sie die private IP-Adresse von „cassandra-origin“ mit folgendem Befehl ab:

hostname -I

Bearbeiten Sie die Cassandra-Konfiguration. Sie müssen keine neuen Konfigurationszeilen hinzufügen, sondern nur die vorhandenen aktualisieren:

sudo vim /etc/cassandra/cassandra.yaml
  1. Setzen Sie seed_provider.parameters.seeds auf "CASSANDRA_ORIGIN_PRIVATE_IP:7000".
  2. Setzen Sie rpc_address auf CASSANDRA_ORIGIN_PRIVATE_IP.
  3. Setzen Sie listen_address auf CASSANDRA_ORIGIN_PRIVATE_IP.

Speichern Sie die Datei.

Starten Sie Cassandra neu, um die Konfigurationsänderungen zu laden:

sudo systemctl restart cassandra

# (Optional) Verify Cassandra is running
sudo systemctl status cassandra

4. Keyspace und Tabelle erstellen

Wir verwenden ein Beispiel für eine Mitarbeitertabelle und erstellen einen Keyspace namens „zdmbigtable“.

Hinweis: Es kann eine Minute dauern, bis Cassandra Verbindungen akzeptiert.

# Start cqlsh
cqlsh $(hostname -I)

In cqlsh:

-- Create keyspace (adjust replication for production)
CREATE KEYSPACE zdmbigtable WITH replication = {'class':'SimpleStrategy', 'replication_factor':1};

-- Use the keyspace
USE zdmbigtable;

-- Create the employee table
CREATE TABLE employee (
    name text PRIMARY KEY,
    age bigint,
    code int,
    credited double,
    balance float,
    is_active boolean,
    birth_date timestamp
);

-- Exit cqlsh
EXIT;

Lassen Sie die SSH-Sitzung geöffnet oder notieren Sie sich die IP-Adresse dieser VM (hostname -I).

4. Bigtable (Ziel) einrichten

Dauer: 0:01

Bigtable-Instanz erstellen. Wir verwenden zdmbigtable als Instanz-ID.

gcloud bigtable instances create zdmbigtable \
--display-name="ZDM Bigtable Target" \
--cluster="bigtable-c1" \
--cluster-zone="$ZONE" \
--cluster-num-nodes=1 # Use 1 node for dev/testing; scale as needed

Die Bigtable-Tabelle selbst wird später vom Einrichtungs-Script für den Cassandra-Bigtable-Proxy erstellt.

5. Cassandra-Bigtable-Proxy einrichten

1. Compute Engine-VM für Cassandra-Bigtable-Proxy erstellen

gcloud iam service-accounts create bigtable-proxy-sa \
    --description="Service account for Bigtable Proxy access" \
    --display-name="Bigtable Proxy Access SA"

export BIGTABLE_PROXY_SA_EMAIL=$(gcloud iam service-accounts list --filter="displayName='Bigtable Proxy Access SA'" --format="value(email)")

gcloud bigtable instances add-iam-policy-binding zdmbigtable \
  --member="serviceAccount:$BIGTABLE_PROXY_SA_EMAIL" \
  --role="roles/bigtable.admin"

gcloud compute instances create bigtable-proxy-vm \
--machine-type=e2-medium \
--image-family=ubuntu-2204-lts \
--image-project=ubuntu-os-cloud \
--tags=cassandra-migration \
--boot-disk-size=20GB \
--zone=$ZONE \
--scopes=cloud-platform \
--service-account="$BIGTABLE_PROXY_SA_EMAIL"

Stellen Sie eine SSH-Verbindung zur bigtable-proxy-vm her:

gcloud compute ssh --zone="$ZONE" "bigtable-proxy-vm"

Führen Sie auf der bigtable-proxy-vm Folgendes aus:

# Install Git and Go
sudo apt-get update
sudo apt-get install -y git

wget https://go.dev/dl/go1.23.6.linux-amd64.tar.gz
sudo rm -rf /usr/local/go
sudo tar -C /usr/local -xzf go1.23.6.linux-amd64.tar.gz

echo 'export GOPATH=$HOME/go' >> ~/.profile
echo 'export PATH=$PATH:/usr/local/go/bin:$GOPATH/bin' >> ~/.profile
source ~/.profile

# Clone the proxy repository
git clone https://github.com/GoogleCloudPlatform/cloud-bigtable-ecosystem.git
cd cloud-bigtable-ecosystem/cassandra-bigtable-migration-tools/cassandra-bigtable-proxy/

2. Cassandra-Bigtable-Proxy starten

Starten Sie den Proxyserver.

# At the root of the cassandra-to-bigtable-proxy directory
go run proxy.go --project-id="$(gcloud config get-value project)" --instance-id=zdmbigtable --keyspace-id=zdmbigtable --rpc-address=$(hostname -I)

Der Proxy wird gestartet und überwacht Port 9042 auf eingehende CQL-Verbindungen. Lassen Sie diese Terminalsitzung geöffnet. Notieren Sie sich die IP-Adresse dieser VM (Hostname -I).

3. Tabelle über CQL erstellen

Stellen Sie mit CQLSH eine Verbindung zur IP-Adresse der Cassandra-Bigtable-Proxy-VM her. Sie können die IP-Adresse ermitteln, indem Sie den folgenden Befehl lokal ausführen:

gcloud compute instances describe bigtable-proxy-vm --format='get(networkInterfaces[0].networkIP)'

Stellen Sie in einem separaten Fenster über SSH eine Verbindung zu Ihrer cassandra-origin-VM her und verwenden Sie cqlsh für den bigtable-proxy. Wir haben ein längeres als das Standard-Zeitlimit für Anfragen festgelegt, damit Bigtable genügend Zeit hat, die zugrunde liegende Tabelle zu erstellen. Sie sollten „Connected to cassandra-bigtable-proxy-v0.2.3“ oder Ähnliches sehen. Das bedeutet, dass Sie eine Verbindung zum Bigtable-Proxy und nicht zum lokalen Cassandra-Server hergestellt haben.

# Replace <your-bigtable-proxy-vm-ip> with the ip from the above command
export BIGTABLE_PROXY_IP=<your-bigtable-proxy-vm-ip>
cqlsh --request-timeout=60 $BIGTABLE_PROXY_IP

-- Create the employee table
CREATE TABLE zdmbigtable.employee (
    name text PRIMARY KEY,
    age bigint,
    code int,
    credited double,
    balance float,
    is_active boolean,
    birth_date timestamp
);

Prüfen Sie in CQLSH, ob die Tabelle erstellt wurde, indem Sie Folgendes ausführen:

DESC TABLE zdmbigtable.employee;

6. ZDM-Proxy einrichten

In diesem Lab erstellen wir eine einzelne Instanz des ZDM-Proxys. Für eine Produktionsmigration benötigen Sie jedoch eine Einrichtung mit mehreren Knoten.

1. ZDM-Proxy-VM erstellen

gcloud compute instances create zdm-proxy-vm \
--machine-type=e2-medium \
--image-family=ubuntu-2204-lts \
--image-project=ubuntu-os-cloud \
--tags=cassandra-migration \
--boot-disk-size=20GB \
--scopes=cloud-platform \
--zone=$ZONE

Notieren Sie sich die IP-Adressen beider VMs.

2. ZDM-Proxy vorbereiten

gcloud compute ssh --zone="$ZONE" zdm-proxy-vm

export ZDM_VERSION="2.3.4"
wget "https://github.com/datastax/zdm-proxy/releases/download/v$ZDM_VERSION/zdm-proxy-linux-amd64-v$ZDM_VERSION.tgz"
tar -xvzf "zdm-proxy-linux-amd64-v$ZDM_VERSION.tgz"

# replace YOUR_ZONE
gcloud config set compute/zone "YOUR_ZONE"
export ZDM_ORIGIN_CONTACT_POINTS=$(gcloud compute instances describe cassandra-origin --format='get(networkInterfaces[0].networkIP)') 
export ZDM_TARGET_CONTACT_POINTS=$(gcloud compute instances describe bigtable-proxy-vm --format='get(networkInterfaces[0].networkIP)')
export ZDM_ORIGIN_USERNAME=""
export ZDM_ORIGIN_PASSWORD=""
export ZDM_TARGET_USERNAME=""
export ZDM_TARGET_PASSWORD=""
export ZDM_PROXY_LISTEN_ADDRESS=0.0.0.0
export ZDM_PROXY_LISTEN_PORT=9042
./zdm-proxy-v${ZDM_VERSION}

7. Anwendung konfigurieren und Dual-Writes starten

Dauer: 0:05

In dieser Phase einer echten Migration würden Sie Ihre Anwendung(en) so konfigurieren, dass sie auf die IP-Adresse der ZDM-Proxy-VM verweisen (z.B. :9042) anstatt eine direkte Verbindung zu Cassandra herzustellen.

Sobald die Anwendung eine Verbindung zum ZDM-Proxy herstellt, werden Lesevorgänge standardmäßig vom Ursprung (Cassandra) bereitgestellt. Schreibvorgänge werden sowohl an die Quelle (Cassandra) als auch an das Ziel (Bigtable über den Cassandra-Bigtable-Proxy) gesendet. So kann Ihre Anwendung weiterhin normal funktionieren und gleichzeitig werden neue Daten in beide Datenbanken geschrieben. Sie können die Verbindung mit cqlsh testen, das auf den ZDM-Proxy verweist:

cqlsh $(gcloud compute instances describe zdm-proxy-vm --format='get(networkInterfaces[0].networkIP)')

Versuchen Sie, Daten einzufügen:

INSERT INTO zdmbigtable.employee (name, age, is_active) VALUES ('Alice', 30, true); 
INSERT INTO zdmbigtable.employee (name, age, is_active) VALUES ('Anna', 45, true); 
INSERT INTO zdmbigtable.employee (name, age, is_active) VALUES ('Albert', 50, false); 
SELECT * FROM zdmbigtable.employee;

Diese Daten sollten sowohl in Cassandra als auch in Bigtable geschrieben werden. Sie können dies in Bigtable bestätigen, indem Sie in der Google Cloud Console den Bigtable-Abfrageeditor für Ihre Instanz öffnen. Führen Sie die Abfrage „SELECT * FROM employee“ aus. Die gerade eingefügten Daten sollten sichtbar sein.

8. Verlaufsdaten mit Cassandra Data Migrator migrieren

Nachdem Dual Writes für neue Daten aktiviert sind, kopieren Sie die vorhandenen Verlaufsdaten mit dem Cassandra Data Migrator-Tool (CDM) von Cassandra nach Bigtable.

1. Compute Engine-VM für CDM erstellen

Diese VM benötigt ausreichend Arbeitsspeicher für Spark.

gcloud compute instances create cdm-migrator-vm \
--machine-type=e2-medium \
--image-family=ubuntu-2204-lts \
--image-project=ubuntu-os-cloud \
--tags=cassandra-migration \
--boot-disk-size=40GB \
--scopes=cloud-platform \
--zone=$ZONE

2. Voraussetzungen installieren (Java 11, Spark)

Stellen Sie eine SSH-Verbindung zur cdm-migrator-vm her:

gcloud compute ssh cdm-migrator-vm

In der VM:

# Install Java 11 
sudo apt-get update 
sudo apt-get install -y openjdk-11-jdk
 
# Verify Java installation 
java -version 

# Download and Extract Spark (Using version 3.5.3 as requested) 
# Check the Apache Spark archives for the correct URL if needed

wget  https://archive.apache.org/dist/spark/spark-3.5.3/spark-3.5.3-bin-hadoop3-scala2.13.tgz
tar -xvzf spark-3.5.3-bin-hadoop3-scala2.13.tgz

echo 'export SPARK_HOME=$PWD/spark-3.5.3-bin-hadoop3-scala2.13' >> ~/.profile
echo 'export PATH=$PATH:$SPARK_HOME/bin' >> ~/.profile
source ~/.profile

3. Cassandra Data Migrator herunterladen

Öffnen Sie in Ihrem Browser die Seite CDM Packages (CDM-Pakete) und kopieren Sie den .jar-Link aus dem Bereich „Assets“. Wenn 5.4.0 nicht verfügbar ist, wählen Sie die nächstbeste Version aus. Fügen Sie den Link in den folgenden Befehl ein und führen Sie ihn auf Ihrer cdm-migrator-vm-Instanz aus. Achten Sie darauf, dass die einfachen Anführungszeichen um die URL erhalten bleiben.

wget 'JAR_URL_GOES_HERE' -O cassandra-data-migrator.jar

Prüfen Sie, ob die JAR-Datei korrekt heruntergeladen wurde, indem Sie sie mit dem Tool jar scannen. Sie sollten eine lange Liste von „.class“-Dateien sehen.

jar tf cassandra-data-migrator.jar

4. Daten hinzufügen

Wir müssen einige Daten hinzufügen, die migriert werden sollen. Dazu schreiben wir direkt in cassandra-origin (nicht in die zdm-proxy-VM).

INSERT INTO zdmbigtable.employee (name, age, is_active) VALUES ('Alfred', 67, true); 
INSERT INTO zdmbigtable.employee (name, age, is_active) VALUES ('Bobby', 12, false); 
INSERT INTO zdmbigtable.employee (name, age, is_active) VALUES ('Carol', 29, true);

5. Migrationsjob ausführen

Führen Sie die Migration mit „spark-submit“ aus. Mit diesem Befehl wird Spark angewiesen, das CDM-JAR auszuführen. Dabei werden Ihre Attributdatei verwendet und der zu migrierende Keyspace und die zu migrierende Tabelle angegeben. Passen Sie die Speichereinstellungen (–driver-memory, –executor-memory) an die Größe Ihrer VM und das Datenvolumen an.

Sie müssen sich in dem Verzeichnis befinden, das die CDM-JAR-Datei und die Eigenschaftendatei enthält.

Tipp: Sie können die interne IP-Adresse Ihrer Cassandra- und Proxy-VMs abrufen, indem Sie die folgenden Befehle auf Ihrem lokalen Computer ausführen:

gcloud compute instances describe cassandra-origin --format='get(networkInterfaces[0].networkIP)'
gcloud compute instances describe bigtable-proxy-vm --format='get(networkInterfaces[0].networkIP)'

export ORIGIN_HOST="<your-cassandra-origin-ip>"
export TARGET_HOST="<your-bigtable-proxy-vm-ip>"
export KEYSPACE_TABLE="zdmbigtable.employee"
spark-submit --verbose --master "local[*]" \
--driver-memory 3G --executor-memory 3G \
--conf spark.cdm.schema.origin.keyspaceTable="$KEYSPACE_TABLE" \
--conf spark.cdm.connect.origin.host="$ORIGIN_HOST" \
--conf spark.cdm.connect.origin.port=9042 \
--conf spark.cdm.connect.target.host="$TARGET_HOST" \
--conf spark.cdm.connect.target.port=9042 \
--conf spark.cdm.feature.origin.ttl.automatic=false \
--conf spark.cdm.feature.origin.writetime.automatic=false \
--conf spark.cdm.feature.target.ttl.automatic=false \
--conf spark.cdm.feature.target.writetime.automatic=false \
--conf spark.cdm.schema.origin.column.ttl.automatic=false \
--conf spark.cdm.schema.ttlwritetime.calc.useCollections=false \
--class com.datastax.cdm.job.Migrate cassandra-data-migrator.jar

6. Datenmigration prüfen

Wenn der CDM-Job erfolgreich abgeschlossen wurde, prüfen Sie, ob die Verlaufsdaten in Bigtable vorhanden sind.

cqlsh <bigtable-proxy-vm-ip>

In cqlsh:

SELECT COUNT(*) FROM zdmbigtable.employee; -- Check row count matches origin 
SELECT * FROM zdmbigtable.employee LIMIT 10; -- Check some sample data

9. Umstellung (konzeptionell)

Nachdem Sie die Datenkonsistenz zwischen Cassandra und Bigtable gründlich geprüft haben, können Sie mit der endgültigen Umstellung fortfahren.

Beim ZDM-Proxy muss er für die Umstellung so neu konfiguriert werden, dass er hauptsächlich aus dem Ziel (Bigtable) anstelle des Ursprungs (Cassandra) liest. Dies erfolgt in der Regel über die Konfiguration des ZDM-Proxys, wodurch der Lesetraffic Ihrer Anwendung effektiv zu Bigtable verschoben wird.

Wenn Sie sicher sind, dass Bigtable den gesamten Traffic korrekt verarbeitet, können Sie Folgendes tun:

  • Beenden Sie die Dual-Writes, indem Sie den ZDM-Proxy neu konfigurieren.
  • Nehmen Sie den ursprünglichen Cassandra-Cluster außer Betrieb.
  • Entfernen Sie den ZDM-Proxy und lassen Sie die Anwendung direkt eine Verbindung zum Cassandra-Bigtable-Proxy herstellen oder verwenden Sie den nativen Bigtable-CQL-Client für Java.

Die Einzelheiten der ZDM-Proxy-Neukonfiguration für die Umstellung gehen über dieses einfache Codelab hinaus, werden aber in der Datastax-ZDM-Dokumentation beschrieben.

10. Bereinigen

Löschen Sie die in diesem Codelab erstellten Ressourcen, um Gebühren zu vermeiden.

1. Compute Engine-VMs löschen

gcloud compute instances delete cassandra-origin zdm-proxy-vm bigtable-proxy-vm cdm-migrator-vm --zone=$ZONE --quiet

2. Bigtable-Instanz löschen

gcloud bigtable instances delete zdmbigtable

3. Firewallregeln löschen

gcloud compute firewall-rules delete allow-migration-internal

4. Cassandra-Datenbank löschen (falls lokal installiert oder persistent)

Wenn Sie Cassandra außerhalb einer hier erstellten Compute Engine-VM installiert haben, folgen Sie den entsprechenden Schritten, um die Daten zu entfernen oder Cassandra zu deinstallieren.

11. Glückwunsch!

Sie haben den Prozess zum Einrichten eines proxybasierten Migrationspfads von Apache Cassandra zu Bigtable erfolgreich durchlaufen.

Sie haben Folgendes gelernt:

Cassandra und Bigtable bereitstellen

  • Cassandra-Bigtable-Proxy für CQL-Kompatibilität konfigurieren
  • Stellen Sie den Datastax ZDM-Proxy bereit, um Dual-Writes und Traffic zu verwalten.
  • Verwenden Sie den Cassandra Data Migrator, um Verlaufsdaten zu migrieren.

Dieser Ansatz ermöglicht Migrationen mit minimalen Ausfallzeiten und ohne Codeänderungen, da die Proxyschicht genutzt wird.

Nächste Schritte

  • Bigtable-Dokumentation ansehen
  • Informationen zu erweiterten Konfigurationen und Umstellungsverfahren finden Sie in der Datastax ZDM Proxy-Dokumentation.
  • Weitere Informationen finden Sie im Cassandra-Bigtable-Proxy-Repository.
  • Weitere Informationen zur erweiterten Verwendung finden Sie im Cassandra Data Migrator-Repository.
  • Weitere Google Cloud-Codelabs ausprobieren