Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Erstellen Sie einen Migrationsplan für die Migration von Apache Cassandra zu Amazon Keyspaces
Für eine erfolgreiche Migration von Apache Cassandra zu Amazon Keyspaces empfehlen wir eine Überprüfung der geltenden Migrationskonzepte und Best Practices sowie einen Vergleich der verfügbaren Optionen.
In diesem Thema wird beschrieben, wie der Migrationsprozess funktioniert, und es werden verschiedene Schlüsselkonzepte sowie die Tools und Techniken vorgestellt, die Ihnen zur Verfügung stehen. Sie können die verschiedenen Migrationsstrategien bewerten, um diejenige auszuwählen, die Ihren Anforderungen am besten entspricht.
**Topics**
+ [Funktionale Kompatibilität](#migrating-cassandra-compatibility)
+ [Schätzung der Amazon Keyspaces-Preise](#migrating-cassandra-sizing)
+ [Wählen Sie eine Migrationsstrategie](#migrating-cassandra-strategy)
+ [Online-Migration zu Amazon Keyspaces: Strategien und bewährte Methoden](migrating-online.md)
+ [Offline-Migrationsprozess: Apache Cassandra zu Amazon Keyspaces](migrating-offline.md)
+ [Verwendung einer hybriden Migrationslösung: Apache Cassandra zu Amazon Keyspaces](migrating-hybrid.md)
## Funktionale Kompatibilität
Überlegen Sie sich vor der Migration sorgfältig die funktionalen Unterschiede zwischen Apache Cassandra und Amazon Keyspaces. Amazon Keyspaces unterstützt alle häufig verwendeten Cassandra-Datenebenenoperationen, z. B. das Erstellen von Schlüsselräumen und Tabellen, das Lesen von Daten und das Schreiben von Daten.
Es gibt jedoch einige Cassandra APIs , die Amazon Keyspaces nicht unterstützt. Weitere Informationen zu den unterstützten Programmen finden Sie APIs unter. [Unterstützte Cassandra APIs, Operationen, Funktionen und Datentypen](cassandra-apis.md) Einen Überblick über alle funktionalen Unterschiede zwischen Amazon Keyspaces und Apache Cassandra finden Sie unter. [Funktionale Unterschiede: Amazon Keyspaces im Vergleich zu Apache Cassandra](functional-differences.md)
Um die Cassandra APIs und das von Ihnen verwendete Schema mit den unterstützten Funktionen in Amazon Keyspaces zu vergleichen, können Sie ein Kompatibilitätsskript ausführen, das im Amazon Keyspaces-Toolkit verfügbar ist. [GitHub](https://github.com/aws-samples/amazon-keyspaces-toolkit/blob/master/bin/toolkit-compat-tool.py)
**Wie benutzt man das Kompatibilitätsskript**
1. Laden Sie das Kompatibilitäts-Python-Skript von herunter [GitHub](https://github.com/aws-samples/amazon-keyspaces-toolkit/blob/master/bin/toolkit-compat-tool.py)und verschieben Sie es an einen Speicherort, der Zugriff auf Ihren vorhandenen Apache Cassandra-Cluster hat.
1. Das Kompatibilitätsskript verwendet ähnliche Parameter wie`CQLSH`. `--port`Geben Sie für `--host` und geben Sie die IP-Adresse und den Port ein, den Sie verwenden, um eine Verbindung herzustellen und Abfragen an einen der Cassandra-Knoten in Ihrem Cluster auszuführen.
Wenn Ihr Cassandra-Cluster Authentifizierung verwendet, müssen Sie auch und angeben`-username`. `-password` Um das Kompatibilitätsskript auszuführen, können Sie den folgenden Befehl verwenden.
```
python toolkit-compat-tool.py --host hostname or IP -u "username" -p "password" --port native transport port
```
## Schätzung der Amazon Keyspaces-Preise
Dieser Abschnitt bietet einen Überblick über die Informationen, die Sie aus Ihren Apache Cassandra-Tabellen sammeln müssen, um die geschätzten Kosten für Amazon Keyspaces zu berechnen. Jede Ihrer Tabellen benötigt unterschiedliche Datentypen, muss unterschiedliche CQL-Abfragen unterstützen und sorgt für einen unterschiedlichen Datenverkehr. read/write
Wenn Sie Ihre Anforderungen auf der Grundlage von Tabellen berücksichtigen, entspricht dies den Amazon Keyspaces-Modi für die Ressourcenisolierung auf Tabellenebene und die Kapazitätsmodi für den [Lese-/Schreibdurchsatz](ReadWriteCapacityMode.md). Mit Amazon Keyspaces können Sie Lese-/Schreibkapazitäten und [automatische Skalierungsrichtlinien](autoscaling.md) für Tabellen unabhängig voneinander definieren.
Wenn Sie die Tabellenanforderungen verstehen, können Sie Tabellen für die Migration auf der Grundlage von Funktionalität, Kosten und Migrationsaufwand priorisieren.
Erfassen Sie vor einer Migration die folgenden Cassandra-Tabellenmetriken. Diese Informationen helfen Ihnen dabei, die Kosten Ihres Workloads auf Amazon Keyspaces abzuschätzen.
+ **Tabellenname** — Der Name des vollqualifizierten Schlüsselraums und der Tabellenname.
+ **Beschreibung** — Eine Beschreibung der Tabelle, z. B. wie sie verwendet wird oder welche Art von Daten darin gespeichert sind.
+ **Durchschnittliche Lesevorgänge pro Sekunde** — Die durchschnittliche Anzahl von Lesevorgängen in der Tabelle auf Koordinatenebene über ein großes Zeitintervall.
+ **Durchschnittliche Schreibvorgänge pro Sekunde** — Die durchschnittliche Anzahl von Schreibvorgängen in der Tabelle auf Koordinatenebene über einen großen Zeitraum.
+ **Durchschnittliche Zeilengröße in Byte** — Die durchschnittliche Zeilengröße in Byte.
+ **Speichergröße in GBs** — Die ungefähre Speichergröße für eine Tabelle.
+ **Aufschlüsselung der Lesekonsistenz** — Der Prozentsatz der Lesevorgänge, bei denen letztendlich Konsistenz (`LOCAL_ONE`oder`ONE`) erreicht wurde, im Vergleich zu starker Konsistenz (`LOCAL_QUORUM`).
Diese Tabelle zeigt ein Beispiel für die Informationen zu Ihren Tabellen, die Sie bei der Planung einer Migration zusammenstellen müssen.
****
| Name der Tabelle | Description | Durchschnittliche Lesevorgänge pro Sekunde | Durchschnittliche Schreibvorgänge pro Sekunde | Durchschnittliche Zeilengröße in Byte | Speichergröße in GBs | Lesen Sie die Aufschlüsselung zur |
| --- | --- | --- | --- | --- | --- | --- |
| mykeyspace.mytable | Wird zum Speichern des Warenkorbverlaufs verwendet | 10.000 | 5,000 | 2.200 | 2.000 | 100% `LOCAL_ONE` |
| mein Schlüsselraum. Meine Tabelle 2 | Wird verwendet, um die neuesten Profilinformationen zu speichern | 20 000 | 1.000 | 850 | 1.000 | 25% `LOCAL_QUORUM` 75% `LOCAL_ONE` |
### Wie erfasst man Tabellenmetriken
Dieser Abschnitt enthält schrittweise Anweisungen zum Sammeln der erforderlichen Tabellenmetriken aus Ihrem vorhandenen Cassandra-Cluster. Zu diesen Metriken gehören Zeilengröße, Tabellengröße und read/write Anfragen pro Sekunde (RPS). Sie ermöglichen es Ihnen, die Durchsatzkapazitätsanforderungen für eine Amazon Keyspaces-Tabelle zu bewerten und die Preise zu schätzen.
**Wie erfasst man Tabellenmetriken in der Cassandra-Quelltabelle**
1. Ermitteln Sie die Zeilengröße
Die Zeilengröße ist wichtig für die Bestimmung der Lese- und Schreibkapazitätsauslastung in Amazon Keyspaces. Das folgende Diagramm zeigt die typische Datenverteilung über einen Cassandra-Token-Bereich.
![\[Ein Diagramm, das die typische Datenverteilung über einen Cassandra-Token-Bereich mithilfe des murmur3 Partitionierers zeigt.\]](http://docs.aws.amazon.com/de_de/keyspaces/latest/devguide/images/migration/migration-data-distribution.png)
Sie können ein auf verfügbares Sampler-Skript zur Zeilengröße verwenden, um Metriken zur Zeilengröße für jede Tabelle in Ihrem Cassandra-Cluster [GitHub](https://github.com/aws-samples/amazon-keyspaces-toolkit/blob/master/bin/row-size-sampler.sh)zu sammeln.
Das Skript exportiert Tabellendaten aus Apache Cassandra, indem es die Mindest `cqlsh` -`awk`, Höchst-, Durchschnitts- und Standardabweichung der Zeilengröße anhand eines konfigurierbaren Stichprobensatzes von Tabellendaten verwendet und berechnet. Der Zeilengrößen-Sampler übergibt die Argumente an`cqlsh`, sodass dieselben Parameter verwendet werden können, um eine Verbindung herzustellen und aus Ihrem Cassandra-Cluster zu lesen.
Die folgende Aussage ist ein Beispiel dafür.
```
./row-size-sampler.sh 10.22.33.44 9142 \\
-u "username" -p "password" --ssl
```
Weitere Informationen zur Berechnung der Zeilengröße in Amazon Keyspaces finden Sie unter[Schätzen Sie die Zeilengröße in Amazon Keyspaces](calculating-row-size.md).
1. Ermitteln Sie die Tabellengröße
Mit Amazon Keyspaces müssen Sie Speicher nicht im Voraus bereitstellen. Amazon Keyspaces überwacht kontinuierlich die fakturierbare Größe Ihrer Tabellen, um Ihre Speichergebühren zu ermitteln. Speicherplatz wird pro GB-Monat abgerechnet. Die Tabellengröße von Amazon Keyspaces basiert auf der Rohgröße (unkomprimiert) eines einzelnen Replikats.
Um die Tabellengröße in Amazon Keyspaces zu überwachen, können Sie die Metrik verwenden`BillableTableSizeInBytes`, die für jede Tabelle in der AWS-Managementkonsole angezeigt wird.
Um die abrechnungsfähige Größe Ihrer Amazon Keyspaces-Tabelle zu schätzen, können Sie eine der beiden folgenden Methoden verwenden:
+ Verwenden Sie die durchschnittliche Zeilengröße und multiplizieren Sie sie mit der Anzahl oder den Zeilen.
Sie können die Größe der Amazon Keyspaces-Tabelle schätzen, indem Sie die durchschnittliche Zeilengröße mit der Anzahl der Zeilen aus Ihrer Cassandra-Quelltabelle multiplizieren. Verwenden Sie das Beispielskript für die Zeilengröße aus dem vorherigen Abschnitt, um die durchschnittliche Zeilengröße zu ermitteln. Um die Zeilenanzahl zu erfassen, können Sie Tools wie `dsbulk count` die Bestimmung der Gesamtzahl der Zeilen in Ihrer Quelltabelle verwenden.
+ Verwenden Sie die`nodetool`, um Tabellenmetadaten zu sammeln.
`Nodetool`ist ein in der Apache Cassandra-Distribution enthaltenes Verwaltungstool, das Einblick in den Status des Cassandra-Prozesses bietet und Tabellenmetadaten zurückgibt. Sie können `nodetool` es verwenden, um Metadaten zur Tabellengröße als Stichprobe zu verwenden und damit die Tabellengröße in Amazon Keyspaces zu extrapolieren.
Der zu verwendende Befehl lautet. `nodetool tablestats` Tablestats gibt die Größe und das Komprimierungsverhältnis der Tabelle zurück. Die Größe der Tabelle wird wie `tablelivespace` für die Tabelle gespeichert und Sie können sie durch die `compression ratio` teilen. Dann multiplizieren Sie diesen Größenwert mit der Anzahl der Knoten. Schließlich dividieren Sie durch den Replikationsfaktor (normalerweise drei).
Dies ist die vollständige Formel für die Berechnung, anhand derer Sie die Tabellengröße beurteilen können.
```
((tablelivespace / compression ratio) * (total number of nodes))/ (replication factor)
```
Nehmen wir an, dass Ihr Cassandra-Cluster 12 Knoten hat. Die Ausführung des `nodetool tablestats` Befehls gibt a `tablelivespace` von 200 GB und a `compression ratio` von 0,5 zurück. Der Schlüsselraum hat einen Replikationsfaktor von drei.
So sieht die Berechnung für dieses Beispiel aus.
```
(200 GB / 0.5) * (12 nodes)/ (replication factor of 3)
= 4,800 GB / 3
= 1,600 GB is the table size estimate for Amazon Keyspaces
```
1. Erfassen Sie die Anzahl der Lese- und Schreibvorgänge
Um die Kapazitäts- und Skalierungsanforderungen für Ihre Amazon Keyspaces-Tabellen zu ermitteln, erfassen Sie vor der Migration die Lese- und Schreibanforderungsrate Ihrer Cassandra-Tabellen.
Amazon Keyspaces ist serverlos und Sie zahlen nur für das, was Sie nutzen. Im Allgemeinen basiert der Preis für den read/write Durchsatz in Amazon Keyspaces auf der Anzahl und Größe der Anfragen.
In Amazon Keyspaces gibt es zwei Kapazitätsmodi:
+ Auf [Abruf](ReadWriteCapacityMode.OnDemand.md) — Dies ist eine flexible Abrechnungsoption, mit der Tausende von Anfragen pro Sekunde bearbeitet werden können, ohne dass eine Kapazitätsplanung erforderlich ist. Es bietet pay-per-request Preise für Lese- und Schreibanfragen, sodass Sie nur für das bezahlen, was Sie tatsächlich nutzen.
+ [Bereitgestellt](ReadWriteCapacityMode.Provisioned.md) — Wenn Sie den Modus Bereitgestellte Durchsatzkapazität wählen, geben Sie die Anzahl der Lese- und Schreibvorgänge pro Sekunde an, die für Ihre Anwendung erforderlich sind. Auf diese Weise können Sie Ihre Amazon Keyspaces-Nutzung so verwalten, dass sie bei oder unter einer definierten Anforderungsrate bleibt, um die Vorhersehbarkeit zu gewährleisten.
Der Bereitstellungsmodus bietet [auto Skalierung](autoscaling.md), um Ihre bereitgestellte Rate automatisch an die Skalierung nach oben oder unten anzupassen, um die betriebliche Effizienz zu verbessern. Weitere Informationen zur serverlosen Ressourcenverwaltung finden Sie unter. [Verwaltung serverloser Ressourcen in Amazon Keyspaces (für Apache Cassandra)](serverless_resource_management.md)
Da Sie Lese- und Schreibdurchsatzkapazität in Amazon Keyspaces separat bereitstellen, müssen Sie die Anforderungsrate für Lese- und Schreibvorgänge in Ihren vorhandenen Tabellen unabhängig voneinander messen.
Um die genauesten Nutzungsmetriken aus Ihrem bestehenden Cassandra-Cluster zu sammeln, erfassen Sie die durchschnittlichen Anfragen pro Sekunde (RPS) für Lese- und Schreibvorgänge auf Koordinatorebene über einen längeren Zeitraum für eine Tabelle, die über alle Knoten in einem einzigen Rechenzentrum aggregiert wird.
Durch die Erfassung des durchschnittlichen RPS über einen Zeitraum von mindestens mehreren Wochen werden Spitzen und Täler in Ihren Datenverkehrsmustern erfasst, wie in der folgenden Abbildung dargestellt.
![\[Ein Diagramm, das die durchschnittliche Rate von Anfragen pro Sekunde und Tag über einen Zeitraum von zwei Wochen zeigt.\]](http://docs.aws.amazon.com/de_de/keyspaces/latest/devguide/images/migration/migration-rps.png)
Sie haben zwei Möglichkeiten, die Lese- und Schreibanforderungsrate Ihrer Cassandra-Tabelle zu bestimmen.
+ Verwenden Sie das bestehende Cassandra-Monitoring
Sie können die in der folgenden Tabelle aufgeführten Metriken verwenden, um Lese- und Schreibanforderungen zu beobachten. Beachten Sie, dass sich die Namen der Metriken je nach dem von Ihnen verwendeten Überwachungstool ändern können.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/keyspaces/latest/devguide/migrating-cassandra.html)
+ Verwenden der `nodetool`
Verwenden Sie `nodetool tablestats` und`nodetool info`, um durchschnittliche Lese- und Schreibvorgänge aus der Tabelle zu erfassen. `tablestats`gibt die Gesamtzahl der Lese- und Schreibvorgänge ab dem Zeitpunkt zurück, zu dem der Knoten initiiert wurde. `nodetool info`gibt die Betriebszeit eines Knotens in Sekunden an.
Um den Durchschnitt der Lese- und Schreibvorgänge pro Sekunde zu ermitteln, dividieren Sie die Anzahl der Lese- und Schreibvorgänge durch die Betriebszeit des Knotens in Sekunden. Dann dividieren Sie für Lesevorgänge durch den Konsistenzgrad und für Schreibvorgänge dividieren Sie durch den Replikationsfaktor. Diese Berechnungen werden in den folgenden Formeln ausgedrückt.
Formel für durchschnittliche Lesevorgänge pro Sekunde:
```
((number of reads * number of nodes in cluster) / read consistency quorum (2)) / uptime
```
Formel für durchschnittliche Schreibvorgänge pro Sekunde:
```
((number of writes * number of nodes in cluster) / replication factor of 3) / uptime
```
Nehmen wir an, wir haben einen 12-Knoten-Cluster, der seit 4 Wochen aktiv ist. `nodetool info`gibt 2.419.200 Sekunden Betriebszeit zurück und `nodetool tablestats` gibt 1 Milliarde Schreibvorgänge und 2 Milliarden Lesevorgänge zurück. Dieses Beispiel würde zu der folgenden Berechnung führen.
```
((2 billion reads * 12 in cluster) / read consistency quorum (2)) / 2,419,200 seconds
= 12 billion reads / 2,419,200 seconds
= 4,960 read request per second
((1 billion writes * 12 in cluster) / replication factor of 3) / 2,419,200 seconds
= 4 billion writes / 2,419,200 seconds
= 1,653 write request per second
```
1. Ermitteln Sie die Kapazitätsauslastung der Tabelle
Um die durchschnittliche Kapazitätsauslastung zu schätzen, beginnen Sie mit den durchschnittlichen Anforderungsraten und der durchschnittlichen Zeilengröße Ihrer Cassandra-Quelltabelle.
Amazon Keyspaces verwendet *Lesekapazitätseinheiten* (RCUs) und *Schreibkapazitätseinheiten* (WCUs), um die bereitgestellte Durchsatzkapazität für Lese- und Schreibvorgänge für Tabellen zu messen. Für diese Schätzung verwenden wir diese Einheiten, um den Lese- und Schreibkapazitätsbedarf der neuen Amazon Keyspaces-Tabelle nach der Migration zu berechnen.
Später in diesem Thema werden wir erörtern, wie sich die Wahl zwischen Bereitstellungs- und On-Demand-Kapazitätsmodus auf die Abrechnung auswirkt. Für die Schätzung der Kapazitätsauslastung in diesem Beispiel gehen wir jedoch davon aus, dass sich die Tabelle im Bereitstellungsmodus befindet.
+ **Lesevorgänge** — Eine RCU steht für eine `LOCAL_QUORUM` oder zwei `LOCAL_ONE` Leseanforderungen für eine Zeile mit einer Größe von bis zu 4 KB. Wenn Sie eine Zeile lesen müssen, die größer als 4 KB ist, verwendet der Lesevorgang zusätzliche RCUs Daten. Die Gesamtzahl der RCUs erforderlichen Daten hängt von der Zeilengröße ab und davon, ob Sie Konsistenzen verwenden `LOCAL_QUORUM` oder `LOCAL_ONE` lesen möchten.
Zum Lesen einer 8-KB-Zeile sind beispielsweise 2 RCUs unter Verwendung von `LOCAL_QUORUM` Lesekonsistenz und 1 RCU erforderlich, wenn Sie `LOCAL_ONE` Lesekonsistenz wählen.
+ **Schreibvorgänge** — Eine WCU entspricht einem Schreibvorgang für eine Zeile mit einer Größe von bis zu 1 KB. Bei allen Schreibvorgängen wird `LOCAL_QUORUM` Konsistenz verwendet, und es fallen keine zusätzlichen Gebühren für die Verwendung von Lightweight Transactions (LWTs) an.
Die Gesamtzahl der WCUs benötigten Dateien hängt von der Zeilengröße ab. Wenn Sie eine Zeile schreiben müssen, die größer als 1 KB ist, verwendet der Schreibvorgang zusätzliche Daten WCUs. Wenn Ihre Zeilengröße beispielsweise 2 KB beträgt, benötigen Sie 2, WCUs um eine Schreibanforderung auszuführen.
Die folgende Formel kann verwendet werden, um den erforderlichen Wert RCUs und abzuschätzen WCUs.
+ Die **Lesekapazität in RCUs** kann bestimmt werden, indem die Lesevorgänge pro Sekunde mit der Anzahl der pro Lesevorgang gelesenen Zeilen multipliziert und mit der durchschnittlichen Zeilengröße geteilt durch 4 KB und aufgerundet auf die nächste ganze Zahl berechnet werden.
+ Die **Schreibkapazität in WCUs** kann bestimmt werden, indem die Anzahl der Anfragen mit der durchschnittlichen Zeilengröße geteilt durch 1 KB multipliziert und auf die nächste ganze Zahl aufgerundet wird.
Dies wird in den folgenden Formeln ausgedrückt.
```
Read requests per second * ROUNDUP((Average Row Size)/4096 per unit) = RCUs per second
Write requests per second * ROUNDUP(Average Row Size/1024 per unit) = WCUs per second
```
Wenn Sie beispielsweise 4.960 Leseanfragen mit einer Zeilengröße von 2,5 KB in Ihrer Cassandra-Tabelle ausführen, benötigen Sie 4.960 RCUs in Amazon Keyspaces. Wenn Sie derzeit 1.653 Schreibanforderungen pro Sekunde mit einer Zeilengröße von 2,5 KB in Ihrer Cassandra-Tabelle ausführen, benötigen Sie in Amazon Keyspaces 4.959 WCUs pro Sekunde.
Dieses Beispiel wird in den folgenden Formeln ausgedrückt.
```
4,960 read requests per second * ROUNDUP( 2.5KB /4KB bytes per unit)
= 4,960 read requests per second * 1 RCU
= 4,960 RCUs
1,653 write requests per second * ROUNDUP(2.5KB/1KB per unit)
= 1,653 requests per second * 3 WCUs
= 4,959 WCUs
```
`eventual consistency`Durch die Verwendung können Sie bei jeder Leseanforderung bis zur Hälfte der Durchsatzkapazität sparen. Jeder eventuell konsistente Lesevorgang kann bis zu 8 KB verbrauchen. Sie können letztendlich konsistente Lesevorgänge berechnen, indem Sie die vorherige Berechnung mit 0,5 multiplizieren, wie in der folgenden Formel dargestellt.
```
4,960 read requests per second * ROUNDUP( 2.5KB /4KB per unit) * .5
= 2,480 read request per second * 1 RCU
= 2,480 RCUs
```
1. Berechnen Sie die monatliche Preisschätzung für Amazon Keyspaces
Um die monatliche Abrechnung für die Tabelle auf der Grundlage des read/write Kapazitätsdurchsatzes abzuschätzen, können Sie die Preise für den On-Demand-Modus und den Bereitstellungsmodus anhand verschiedener Formeln berechnen und die Optionen für Ihre Tabelle vergleichen.
**Bereitgestellter Modus — Der** Kapazitätsverbrauch für Lese- und Schreibvorgänge wird nach einem Stundensatz abgerechnet, der auf den Kapazitätseinheiten pro Sekunde basiert. Teilen Sie diese Rate zunächst durch 0,7, um die standardmäßige automatische Skalierungszielauslastung von 70% darzustellen. Dann multiplizieren Sie es mit 30 Kalendertagen, 24 Stunden pro Tag und den Preisen nach regionalen Tarifen.
Diese Berechnung ist in den folgenden Formeln zusammengefasst.
```
(read capacity per second / .7) * 24 hours * 30 days * regional rate
(write capacity per second / .7) * 24 hours * 30 days * regional rate
```
**On-Demand-Modus** — Lese- und Schreibkapazität werden pro Anforderung abgerechnet. Multiplizieren Sie zunächst die Anforderungsrate mit 30 Kalendertagen und 24 Stunden pro Tag. Teilen Sie dann durch eine Million Anforderungseinheiten. Schließlich multiplizieren Sie mit dem Regionalsatz.
Diese Berechnung ist in den folgenden Formeln zusammengefasst.
```
((read capacity per second * 30 * 24 * 60 * 60) / 1 Million read request units) * regional rate
((write capacity per second * 30 * 24 * 60 * 60) / 1 Million write request units) * regional rate
```
## Wählen Sie eine Migrationsstrategie
Bei der Migration von Apache Cassandra zu Amazon Keyspaces können Sie zwischen den folgenden Migrationsstrategien wählen:
+ **Online** — Dies ist eine Live-Migration, bei der duale Schreibvorgänge verwendet werden, um mit dem gleichzeitigen Schreiben neuer Daten in Amazon Keyspaces und den Cassandra-Cluster zu beginnen. Dieser Migrationstyp wird für Anwendungen empfohlen, bei denen während der Migration keine Ausfallzeiten anfallen und die Konsistenz auch beim Lesen nach dem Schreiben gewährleistet ist.
Weitere Informationen zur Planung und Implementierung einer Online-Migrationsstrategie finden Sie unter[Online-Migration zu Amazon Keyspaces: Strategien und bewährte Methoden](migrating-online.md).
+ **Offline** — Bei dieser Migrationstechnik wird während eines Ausfallzeitfensters ein Datensatz von Cassandra nach Amazon Keyspaces kopiert. Die Offline-Migration kann den Migrationsprozess vereinfachen, da sie keine Änderungen an Ihrer Anwendung oder eine Konfliktlösung zwischen historischen Daten und neuen Schreibvorgängen erfordert.
Weitere Informationen zur Planung einer Offline-Migration finden Sie unter[Offline-Migrationsprozess: Apache Cassandra zu Amazon Keyspaces](migrating-offline.md).
+ **Hybrid** — Mit dieser Migrationstechnik können Änderungen nahezu in Echtzeit auf Amazon Keyspaces repliziert werden, jedoch ohne Konsistenz beim Lesen nach dem Schreiben.
Weitere Informationen zur Planung einer Hybridmigration finden Sie unter. [Verwendung einer hybriden Migrationslösung: Apache Cassandra zu Amazon Keyspaces](migrating-hybrid.md)
Nachdem Sie sich mit den in diesem Thema erörterten Migrationstechniken und bewährten Methoden befasst haben, können Sie die verfügbaren Optionen in einer Entscheidungsstruktur zusammenfassen, um eine Migrationsstrategie auf der Grundlage Ihrer Anforderungen und verfügbaren Ressourcen zu entwerfen.
# Online-Migration zu Amazon Keyspaces: Strategien und bewährte Methoden
Wenn Sie die Anwendungsverfügbarkeit während einer Migration von Apache Cassandra zu Amazon Keyspaces aufrechterhalten müssen, können Sie eine benutzerdefinierte Online-Migrationsstrategie vorbereiten, indem Sie die in diesem Thema beschriebenen Schlüsselkomponenten implementieren. Wenn Sie diese bewährten Methoden für Online-Migrationen befolgen, können Sie sicherstellen, dass die Verfügbarkeit und read-after-write Konsistenz der Anwendungen während des gesamten Migrationsprozesses erhalten bleibt, wodurch die Auswirkungen auf Ihre Benutzer minimiert werden.
Bei der Entwicklung einer Online-Migrationsstrategie von Apache Cassandra zu Amazon Keyspaces müssen Sie die folgenden wichtigen Schritte berücksichtigen.
1. **Neue Daten schreiben**
+ **ZDM Dual Write Proxy für Amazon Keyspaces-Migration** — Verwenden Sie den auf [Github](https://github.com/aws-samples/amazon-keyspaces-examples/blob/main/migration/online/zdm-proxy/README.md) verfügbaren ZDM Dual Write Proxy, um eine Migration ohne Ausfallzeiten von Apache Cassandra zu Amazon Keyspaces durchzuführen. Der ZDM Proxy führt duale Schreibvorgänge durch, ohne dass bestehende Anwendungen umgestaltet werden müssen, und führt duale Lesevorgänge zur Abfragevalidierung durch.
+ Doppelte Schreibvorgänge für Anwendungen: Sie können duale Schreibvorgänge in Ihrer Anwendung mithilfe vorhandener Cassandra-Clientbibliotheken und -Treiber implementieren. Benennen Sie eine Datenbank als Leader und die andere als Nachfolger. Schreibfehler in die Follower-Datenbank werden zur Analyse in einer [Warteschlange (Dead Letter Queue, DLQ](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html)) aufgezeichnet.
+ Dual-Writes auf Messaging-Ebene: Alternativ können Sie Ihre bestehende Messaging-Plattform so konfigurieren, dass Schreibvorgänge über einen zusätzlichen Verbraucher sowohl an Cassandra als auch an Amazon Keyspaces gesendet werden. Dadurch entstehen letztlich konsistente Ansichten in beiden Datenbanken.
1. **Migration historischer Daten**
+ Historische Daten kopieren: Sie können historische Daten mithilfe AWS Glue von benutzerdefinierten ETL-Skripts (Extrahieren, Transformieren und Laden) von Cassandra zu Amazon Keyspaces migrieren. Bewältigen Sie die Konfliktlösung zwischen dualen Schreibvorgängen und Massenladevorgängen mithilfe von Techniken wie einfachen Transaktionen oder Zeitstempeln.
+ Verwendung Time-To-Live (TTL): Für kürzere Aufbewahrungsfristen können Sie TTL sowohl in Cassandra als auch in Amazon Keyspaces verwenden, um zu vermeiden, dass unnötige historische Daten hochgeladen werden. Da alte Daten in Cassandra ablaufen und neue Daten per Dual-Write-Verfahren geschrieben werden, holt Amazon Keyspaces irgendwann auf.
1. **Daten werden validiert**
+ Duale Lesevorgänge: Implementieren Sie duale Lesevorgänge aus den Datenbanken Cassandra (primär) und Amazon Keyspaces (sekundär) und vergleichen Sie die Ergebnisse asynchron. Unterschiede werden protokolliert oder an eine DLQ gesendet.
+ Lesevorgänge an Stichproben: Verwenden Sie Λ -Funktionen, um in regelmäßigen Abständen Daten aus beiden Systemen abzutasten und zu vergleichen, wobei alle Abweichungen in einem DLQ protokolliert werden.
1. **Die Anwendung wird migriert**
+ Blau-grüne Strategie: Stellen Sie Ihre Anwendung so um, dass sie Amazon Keyspaces als primären und Cassandra als sekundären Datenspeicher in einem einzigen Schritt behandelt. Überwachen Sie die Leistung und führen Sie bei Problemen einen Rollback durch.
+ Bereitstellung auf Kanaren: Führen Sie die Migration schrittweise zunächst für eine Untergruppe von Benutzern durch und erhöhen Sie schrittweise den Traffic zu Amazon Keyspaces als primärem Benutzer, bis die Migration vollständig abgeschlossen ist.
1. **Außerbetriebnahme von Cassandra**
Sobald Ihre Anwendung vollständig zu Amazon Keyspaces migriert und die Datenkonsistenz validiert ist, können Sie die Außerbetriebnahme Ihres Cassandra-Clusters auf der Grundlage von Datenaufbewahrungsrichtlinien planen.
Durch die Planung einer Online-Migrationsstrategie mit diesen Komponenten können Sie reibungslos und mit minimalen Ausfallzeiten oder Unterbrechungen auf den vollständig verwalteten Amazon Keyspaces-Service umsteigen. In den folgenden Abschnitten werden die einzelnen Komponenten ausführlicher behandelt.
**Topics**
+ [Schreiben neuer Daten während einer Online-Migration](migration-online-dw.md)
+ [Upload historischer Daten während einer Online-Migration](migration-online-historical.md)
+ [Überprüfung der Datenkonsistenz während einer Online-Migration](migration-online-validation.md)
+ [Migration der Anwendung während einer Online-Migration](migration-online-app-migration.md)
+ [Außerbetriebnahme von Cassandra nach einer Online-Migration](migration-online-decommission.md)
# Schreiben neuer Daten während einer Online-Migration
Der erste Schritt in einem Online-Migrationsplan besteht darin, sicherzustellen, dass alle neuen Daten, die von der Anwendung geschrieben werden, in beiden Datenbanken, Ihrem vorhandenen Cassandra-Cluster und Amazon Keyspaces, gespeichert werden. Ziel ist es, einen konsistenten Überblick über die beiden Datenspeicher zu bieten. Sie können dies tun, indem Sie alle neuen Schreibvorgänge auf beide Datenbanken anwenden. Um duale Schreibvorgänge zu implementieren, sollten Sie eine der folgenden drei Optionen in Betracht ziehen.
+ **ZDM Dual Write Proxy für Amazon Keyspaces-Migration** — Mit dem auf [Github](https://github.com/aws-samples/amazon-keyspaces-examples/blob/main/migration/online/zdm-proxy/README.md) verfügbaren ZDM-Proxy für Amazon Keyspaces können Sie Ihre Apache Cassandra-Workloads ohne Anwendungsausfälle zu Amazon Keyspaces migrieren. Diese erweiterte Lösung implementiert AWS bewährte Verfahren und erweitert die offiziellen ZDM-Proxy-Funktionen.
+ Führen Sie Online-Migrationen zwischen Apache Cassandra und Amazon Keyspaces durch.
+ Schreiben Sie Daten gleichzeitig in Quell- und Zieltabellen, ohne Anwendungen umzugestalten.
+ Überprüfen Sie Abfragen mithilfe von Dual-Read-Vorgängen.
Die Lösung bietet die folgenden Verbesserungen für die Arbeit mit AWS Amazon Keyspaces.
+ **Container-Bereitstellung** — Verwenden Sie ein vorkonfiguriertes Docker-Image aus Amazon Elastic Container Registry (Amazon ECR) für VPC-zugängliche Bereitstellungen.
+ **Infrastruktur als Code** — Implementieren Sie mithilfe AWS CloudFormation von Vorlagen für die automatische Einrichtung auf. AWS Fargate
+ **Amazon Keyspaces-Kompatibilität — Greifen** Sie auf Systemtabellen mit benutzerdefinierten Anpassungen für Amazon Keyspaces zu.
Die Lösung läuft auf Amazon ECS mit Fargate und bietet serverlose Skalierbarkeit auf der Grundlage Ihrer Workload-Anforderungen. Ein Network Load Balancer verteilt den eingehenden Anwendungsdatenverkehr auf mehrere Amazon ECS-Aufgaben, um eine hohe Verfügbarkeit zu gewährleisten.
![\[Implementierung des ZDM-Dual-Write-Proxys für die Migration von Daten von Apache Cassandra zu Amazon Keyspaces.\]](http://docs.aws.amazon.com/de_de/keyspaces/latest/devguide/images/migration/online-migration-zdm.png)
+ **Doppelte Schreibvorgänge für Anwendungen** — Sie können duale Schreibvorgänge mit minimalen Änderungen an Ihrem Anwendungscode implementieren, indem Sie die vorhandenen Cassandra-Clientbibliotheken und -Treiber nutzen. Sie können entweder duale Schreibvorgänge in Ihrer vorhandenen Anwendung implementieren oder eine neue Ebene in der Architektur für duale Schreibvorgänge erstellen. Weitere Informationen und eine Kundenfallstudie, die zeigt, wie duale Schreibvorgänge in einer bestehenden Anwendung implementiert wurden, finden Sie in der [Fallstudie zur Cassandra-Migration](https://aws.amazon.com/solutions/case-studies/intuit-apache-migration-case-study/).
Bei der Implementierung von dualen Schreibvorgängen können Sie eine Datenbank als Leader und die andere Datenbank als Follower-Datenbank festlegen. Auf diese Weise können Sie weiterhin in Ihre ursprüngliche Quell- oder Leader-Datenbank schreiben, ohne dass Schreibfehler in die Follower- oder Zieldatenbank den kritischen Pfad Ihrer Anwendung stören.
Anstatt fehlgeschlagene Schreibvorgänge an den Follower erneut zu versuchen, können Sie Amazon Simple Queue Service verwenden, um fehlgeschlagene Schreibvorgänge in einer [Warteschlange für tote Briefe (DLQ](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html)) aufzuzeichnen. Mit dem DLQ können Sie die fehlgeschlagenen Schreibvorgänge an den Follower analysieren und feststellen, warum die Verarbeitung in der Zieldatenbank nicht erfolgreich war.
Für eine anspruchsvollere Dual-Write-Implementierung können Sie sich an AWS bewährte Methoden für den Entwurf einer Sequenz lokaler Transaktionen unter Verwendung des [Saga-Musters](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/saga.html) halten. Ein Saga-Muster stellt sicher, dass, falls eine Transaktion fehlschlägt, die Saga Ausgleichstransaktionen ausführt, um die durch die vorherigen Transaktionen vorgenommenen Datenbankänderungen rückgängig zu machen.
Wenn Sie Dual-Writes für eine Online-Migration verwenden, können Sie die Dual-Writes nach dem Saga-Muster konfigurieren, sodass jeder Schreibvorgang eine lokale Transaktion ist, um atomare Operationen in heterogenen Datenbanken sicherzustellen. Weitere Informationen zum Entwerfen verteilter Anwendungen mithilfe der empfohlenen Entwurfsmuster für die AWS Cloud finden Sie unter [Cloud-Entwurfsmuster, Architekturen](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/introduction) und Implementierungen.
![\[Implementierung von dualen Schreibvorgängen auf Anwendungsebene bei der Migration von Apache Cassandra zu Amazon Keyspaces.\]](http://docs.aws.amazon.com/de_de/keyspaces/latest/devguide/images/migration/online-migration-dual-writes.png)
+ **Doppelte Schreibvorgänge auf Messaging-Tier** — Anstatt duale Schreibvorgänge auf Anwendungsebene zu implementieren, können Sie Ihre bestehende Messaging-Stufe verwenden, um duale Schreibvorgänge auf Cassandra und Amazon Keyspaces durchzuführen.
Zu diesem Zweck können Sie für Ihre Messaging-Plattform einen zusätzlichen Verbraucher konfigurieren, der Schreibvorgänge an beide Datenspeicher sendet. Dieser Ansatz bietet eine einfache Low-Code-Strategie, bei der mithilfe der Messaging-Ebene zwei Ansichten für beide Datenbanken erstellt werden, die letztendlich konsistent sind.
# Upload historischer Daten während einer Online-Migration
Nach der Implementierung von Dual Writes, um sicherzustellen, dass neue Daten in Echtzeit in beide Datenspeicher geschrieben werden, besteht der nächste Schritt im Migrationsplan darin, zu bewerten, wie viele historische Daten Sie kopieren oder massenweise von Cassandra nach Amazon Keyspaces hochladen müssen. Dadurch wird sichergestellt, dass sowohl neue Daten als auch historische Daten in der neuen Amazon Keyspaces-Datenbank verfügbar sind, bevor Sie die Anwendung migrieren.
Abhängig von Ihren Anforderungen an die Datenspeicherung, z. B. davon, wie viele historische Daten Sie gemäß den Richtlinien Ihrer Organisation aufbewahren müssen, können Sie eine der folgenden beiden Optionen in Betracht ziehen.
+ **Massen-Upload historischer Daten** — Die Migration historischer Daten aus Ihrer bestehenden Cassandra-Bereitstellung zu Amazon Keyspaces kann durch verschiedene Techniken erreicht werden, z. B. durch die Verwendung von AWS Glue benutzerdefinierten Skripten zum Extrahieren, Transformieren und Laden (ETL) der Daten. Weitere Informationen zur Verwendung AWS Glue zum Hochladen historischer Daten finden Sie unter. [Offline-Migrationsprozess: Apache Cassandra zu Amazon Keyspaces](migrating-offline.md)
Wenn Sie den Massenupload historischer Daten planen, müssen Sie berücksichtigen, wie Konflikte gelöst werden können, die auftreten können, wenn neue Schreibvorgänge versuchen, dieselben Daten zu aktualisieren, die gerade hochgeladen werden. Es wird davon ausgegangen, dass der Bulk-Upload irgendwann konsistent sein wird, was bedeutet, dass die Daten irgendwann alle Knoten erreichen werden.
Wenn dieselben Daten aufgrund eines neuen Schreibvorgangs gleichzeitig aktualisiert werden, sollten Sie sicherstellen, dass sie nicht durch den Upload historischer Daten überschrieben werden. Um sicherzustellen, dass Sie die neuesten Aktualisierungen Ihrer Daten auch während des Massenimports beibehalten, müssen Sie die Konfliktlösung entweder in die Bulk-Upload-Skripts oder in die Anwendungslogik für duale Schreibvorgänge integrieren.
Beispielsweise können Sie [Einfache Transaktionen](functional-differences.md#functional-differences.light-transactions) (LWT) verwenden, um Operationen zu vergleichen und festzulegen. Zu diesem Zweck können Sie Ihrem Datenmodell ein zusätzliches Feld hinzufügen, das den Zeitpunkt der Änderung oder den Status angibt.
Darüber hinaus unterstützt Amazon Keyspaces die `WRITETIME` Cassandra-Timestamp-Funktion. Sie können clientseitige Zeitstempel von Amazon Keyspace verwenden, um Zeitstempel der Quelldatenbank beizubehalten und Konfliktlösung zu implementieren. last-writer-wins Weitere Informationen finden Sie unter [Clientseitige Zeitstempel in Amazon Keyspaces](client-side-timestamps.md).
+ **Verwenden von Time-to-Live (TTL)** — Für Datenaufbewahrungszeiträume von weniger als 30, 60 oder 90 Tagen können Sie TTL in Cassandra und Amazon Keyspaces während der Migration verwenden, um zu vermeiden, dass unnötige historische Daten zu Amazon Keyspaces hochgeladen werden. TTL ermöglicht es Ihnen, einen Zeitraum festzulegen, nach dem die Daten automatisch aus der Datenbank entfernt werden.
Anstatt historische Daten in Amazon Keyspaces zu kopieren, können Sie während der Migrationsphase die TTL-Einstellungen so konfigurieren, dass die historischen Daten im alten System (Cassandra) automatisch ablaufen, während die neuen Schreibvorgänge nur mit der Dual-Write-Methode auf Amazon Keyspaces angewendet werden. Im Laufe der Zeit und da alte Daten im Cassandra-Cluster ständig ablaufen und neue Daten mit der Dual-Write-Methode geschrieben wurden, holt Amazon Keyspaces automatisch auf und enthält dieselben Daten wie Cassandra.
Dieser Ansatz kann die Menge der zu migrierenden Daten erheblich reduzieren, was zu einem effizienteren und optimierten Migrationsprozess führt. Sie können diesen Ansatz in Betracht ziehen, wenn Sie mit großen Datensätzen mit unterschiedlichen Anforderungen an die Datenspeicherung arbeiten. Weitere Informationen zu TTL finden Sie unter [Daten mit Time to Live (TTL) für Amazon Keyspaces (für Apache Cassandra) ablaufen lassen](TTL.md).
Betrachten Sie das folgende Beispiel für eine Migration von Cassandra zu Amazon Keyspaces mit TTL-Datenablaufzeit. In diesem Beispiel setzen wir TTL für beide Datenbanken auf 60 Tage und zeigen, wie der Migrationsprozess über einen Zeitraum von 90 Tagen voranschreitet. Beide Datenbanken empfangen in diesem Zeitraum dieselben neu geschriebenen Daten mithilfe der Dual-Write-Methode. Wir werden uns drei verschiedene Phasen der Migration ansehen, jede Phase dauert 30 Tage.
Wie der Migrationsprozess für jede Phase funktioniert, wird in den folgenden Bildern gezeigt.
![\[Verwendung von TTL zum Ablaufen historischer Daten bei der Migration von Apache Cassandra zu Amazon Keyspaces.\]](http://docs.aws.amazon.com/de_de/keyspaces/latest/devguide/images/migration/online-migration-TTL.png)
1. Nach den ersten 30 Tagen haben der Cassandra-Cluster und Amazon Keyspaces neue Schreibvorgänge erhalten. Der Cassandra-Cluster enthält auch historische Daten, deren Aufbewahrungsfrist von 60 Tagen noch nicht erreicht wurde, was 50% der Daten im Cluster ausmacht.
Daten, die älter als 60 Tage sind, werden im Cassandra-Cluster automatisch mithilfe von TTL gelöscht. Derzeit enthält Amazon Keyspaces 50% der im Cassandra-Cluster gespeicherten Daten, die sich aus den neuen Schreibvorgängen abzüglich der historischen Daten zusammensetzen.
1. Nach 60 Tagen enthalten sowohl der Cassandra-Cluster als auch Amazon Keyspaces dieselben Daten, die in den letzten 60 Tagen geschrieben wurden.
1. Innerhalb von 90 Tagen enthalten Cassandra und Amazon Keyspaces dieselben Daten und laufen mit derselben Geschwindigkeit ab.
Dieses Beispiel zeigt, wie der Schritt des Hochladens historischer Daten vermieden werden kann, indem TTL mit einem Ablaufdatum von 60 Tagen verwendet wird.
# Überprüfung der Datenkonsistenz während einer Online-Migration
Der nächste Schritt im Online-Migrationsprozess ist die Datenvalidierung. Durch duale Schreibvorgänge werden Ihrer Amazon Keyspaces-Datenbank neue Daten hinzugefügt, und Sie haben die Migration historischer Daten entweder per Bulk-Upload oder Datenablauf mit TTL abgeschlossen.
Jetzt können Sie die Überprüfungsphase nutzen, um zu bestätigen, dass beide Datenspeicher tatsächlich dieselben Daten enthalten, und dieselben Leseergebnisse zurückgeben. Sie können eine der folgenden beiden Optionen wählen, um zu überprüfen, ob Ihre beiden Datenbanken identische Daten enthalten.
+ **Doppelte Lesevorgänge** — Um zu überprüfen, ob sowohl die Quell- als auch die Zieldatenbank denselben Satz neu geschriebener und historischer Daten enthalten, können Sie duale Lesevorgänge implementieren. Dazu lesen Sie ähnlich wie bei der dualen Schreibmethode sowohl aus Ihrer primären Cassandra- als auch aus Ihrer sekundären Amazon Keyspaces-Datenbank und vergleichen die Ergebnisse asynchron.
Die Ergebnisse aus der Primärdatenbank werden an den Client zurückgegeben, und die Ergebnisse aus der sekundären Datenbank werden zur Validierung anhand der primären Ergebnismenge verwendet. Die gefundenen Unterschiede können protokolliert oder zur späteren Abstimmung an eine [Warteschlange für unzustellbare Briefe (DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) gesendet werden.
In der folgenden Abbildung führt die Anwendung einen synchronen Lesevorgang aus Cassandra (dem primären Datenspeicher) und einen asynchronen Lesevorgang aus Amazon Keyspaces, dem sekundären Datenspeicher, durch.
![\[Verwendung von dualen Lesevorgängen zur Überprüfung der Datenkonsistenz während einer Online-Migration von Apache Cassandra zu Amazon Keyspaces.\]](http://docs.aws.amazon.com/de_de/keyspaces/latest/devguide/images/migration/online-migration-dual-reads.png)
+ **Lesevorgänge an Stichproben** — Eine alternative Lösung, die keine Änderungen am Anwendungscode erfordert, besteht darin, AWS Lambda Funktionen zu verwenden, um regelmäßig und nach dem Zufallsprinzip Daten sowohl aus dem Cassandra-Quellcluster als auch aus der Amazon Keyspaces-Zieldatenbank auszuwählen.
Diese Lambda-Funktionen können so konfiguriert werden, dass sie in regelmäßigen Abständen ausgeführt werden. Die Lambda-Funktion ruft eine zufällige Teilmenge von Daten sowohl vom Quell- als auch vom Zielsystem ab und führt dann einen Vergleich der Stichprobendaten durch. Alle Diskrepanzen oder Nichtübereinstimmungen zwischen den beiden Datensätzen können aufgezeichnet und zur späteren Abstimmung an eine spezielle Warteschlange ([Dead Letter](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) Queue, DLQ) gesendet werden.
Dieser Prozess wird im folgenden Diagramm veranschaulicht.
![\[Verwendung von Probenlesevorgängen zur Überprüfung der Datenkonsistenz während und Online-Migration von Apache Cassandra zu Amazon Keyspaces.\]](http://docs.aws.amazon.com/de_de/keyspaces/latest/devguide/images/migration/online-migration-sample-reads.png)
# Migration der Anwendung während einer Online-Migration
In der vierten Phase einer Online-Migration migrieren Sie Ihre Anwendung und wechseln zu Amazon Keyspaces als primärem Datenspeicher. Das bedeutet, dass Sie Ihre Anwendung so umstellen, dass sie direkt von und zu Amazon Keyspaces liest und schreibt. Um sicherzustellen, dass Ihre Benutzer möglichst wenig gestört werden, sollte dies ein gut geplantes und koordiniertes Verfahren sein.
Es gibt zwei verschiedene empfohlene Lösungen für die Anwendungsmigration: die blaugrüne Cut-Over-Strategie und die Canary-Cutover-Strategie. In den folgenden Abschnitten werden diese Strategien ausführlicher beschrieben.
+ **Blau-grüne Strategie** — Mit diesem Ansatz stellen Sie Ihre Anwendung so um, dass sie Amazon Keyspaces als primären Datenspeicher und Cassandra als sekundären Datenspeicher in einem einzigen Schritt behandelt. Dazu können Sie ein AWS AppConfig Feature-Flag verwenden, um die Auswahl von primären und sekundären Datenspeichern in der gesamten Anwendungsinstanz zu steuern. Weitere Informationen zu Feature-Flags finden Sie unter [Erstellen eines Feature-Flag-Konfigurationsprofils in AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-creating-configuration-and-profile-feature-flags.html).
Nachdem Sie Amazon Keyspaces zum primären Datenspeicher gemacht haben, überwachen Sie das Verhalten und die Leistung der Anwendung und stellen so sicher, dass Amazon Keyspaces Ihre Anforderungen erfüllt und die Migration erfolgreich ist.
Wenn Sie beispielsweise Dual-Reads für Ihre Anwendung implementiert haben, stellen Sie während der Anwendungsmigrationsphase die primären Lesevorgänge von Cassandra auf Amazon Keyspaces und die sekundären Lesevorgänge von Amazon Keyspaces auf Cassandra um. Nach der Umstellung überwachen und vergleichen Sie die Ergebnisse weiter, wie im Abschnitt zur [Datenvalidierung](migration-online-validation.md) beschrieben, um die Konsistenz zwischen beiden Datenbanken sicherzustellen, bevor Sie Cassandra außer Betrieb nehmen.
Wenn Sie Probleme feststellen, können Sie schnell zum vorherigen Status zurückkehren, indem Sie zu Cassandra als primärem Datenspeicher zurückkehren. Sie fahren nur dann mit der Außerbetriebnahmephase der Migration fort, wenn Amazon Keyspaces alle Ihre Anforderungen als primärer Datenspeicher erfüllt.
![\[Verwendung der blaugrünen Strategie für die Migration einer Anwendung von Apache Cassandra zu Amazon Keyspaces.\]](http://docs.aws.amazon.com/de_de/keyspaces/latest/devguide/images/migration/online-migration-switch.png)
+ **Kanarische Strategie** — Bei diesem Ansatz führen Sie die Migration schrittweise auf eine Teilmenge Ihrer Benutzer oder Ihres Datenverkehrs aus. Anfänglich wird ein kleiner Teil des Datenverkehrs Ihrer Anwendung, z. B. 5% des gesamten Datenverkehrs, an die Version weitergeleitet, die Amazon Keyspaces als primären Datenspeicher verwendet, während der Rest des Datenverkehrs weiterhin Cassandra als primären Datenspeicher verwendet.
Auf diese Weise können Sie die migrierte Version gründlich mit realem Datenverkehr testen, deren Leistung und Stabilität überwachen und mögliche Probleme untersuchen. Wenn Sie keine Probleme feststellen, können Sie den Prozentsatz des Datenverkehrs, der an Amazon Keyspaces weitergeleitet wird, schrittweise erhöhen, bis dieser zum primären Datenspeicher für alle Benutzer und den gesamten Datenverkehr wird.
Diese schrittweise Einführung minimiert das Risiko weit verbreiteter Serviceunterbrechungen und ermöglicht einen kontrollierteren Migrationsprozess. Wenn während der Bereitstellung auf Canary kritische Probleme auftreten, können Sie schnell zur vorherigen Version zurückkehren, indem Sie Cassandra als primären Datenspeicher für das betroffene Verkehrssegment verwenden. Sie fahren erst mit der Außerbetriebnahmephase der Migration fort, nachdem Sie bestätigt haben, dass Amazon Keyspaces 100% Ihrer Benutzer und Ihres Datenverkehrs erwartungsgemäß verarbeitet.
Das folgende Diagramm veranschaulicht die einzelnen Schritte der Canary-Strategie.
![\[Verwendung der kanarischen Strategie für die Migration einer Anwendung von Apache Cassandra zu Amazon Keyspaces.\]](http://docs.aws.amazon.com/de_de/keyspaces/latest/devguide/images/migration/online-migration-canary.png)
# Außerbetriebnahme von Cassandra nach einer Online-Migration
Nachdem die Anwendungsmigration abgeschlossen ist und Ihre Anwendung vollständig auf Amazon Keyspaces läuft und Sie die Datenkonsistenz über einen bestimmten Zeitraum überprüft haben, können Sie die Außerbetriebnahme Ihres Cassandra-Clusters planen. Während dieser Phase können Sie beurteilen, ob die in Ihrem Cassandra-Cluster verbleibenden Daten archiviert werden müssen oder gelöscht werden können. Dies hängt von den Richtlinien Ihres Unternehmens für den Umgang und die Aufbewahrung von Daten ab.
Wenn Sie bei der Planung Ihrer Online-Migration von Cassandra zu Amazon Keyspaces diese Strategie befolgen und die in diesem Thema beschriebenen empfohlenen Best Practices berücksichtigen, können Sie einen reibungslosen Übergang zu Amazon Keyspaces sicherstellen und gleichzeitig die read-after-write Konsistenz und Verfügbarkeit Ihrer Anwendung wahren.
Die Migration von Apache Cassandra zu Amazon Keyspaces kann zahlreiche Vorteile bieten, darunter einen geringeren Betriebsaufwand, automatische Skalierung, verbesserte Sicherheit und ein Framework, das Ihnen hilft, Ihre Compliance-Ziele zu erreichen. Durch die Planung einer Online-Migrationsstrategie mit dualem Schreibvorgang, Upload historischer Daten, Datenvalidierung und schrittweiser Einführung können Sie einen reibungslosen Übergang mit minimalen Unterbrechungen für Ihre Anwendung und deren Benutzer sicherstellen.
Die Implementierung der in diesem Thema erörterten Online-Migrationsstrategie ermöglicht es Ihnen, die Migrationsergebnisse zu überprüfen, Probleme zu identifizieren und zu beheben und letztendlich Ihre bestehende Cassandra-Bereitstellung zugunsten des vollständig verwalteten Amazon Keyspaces-Service außer Betrieb zu nehmen.
# Offline-Migrationsprozess: Apache Cassandra zu Amazon Keyspaces
Offline-Migrationen eignen sich, wenn Sie sich Ausfallzeiten für die Durchführung der Migration leisten können. In Unternehmen ist es üblich, Wartungsfenster für Patches, große Releases oder Ausfallzeiten für Hardware-Upgrades oder größere Upgrades vorzusehen. Die Offline-Migration kann dieses Fenster verwenden, um Daten zu kopieren und den Anwendungsdatenverkehr von Apache Cassandra zu Amazon Keyspaces umzuschalten.
Die Offline-Migration reduziert die Anzahl der Änderungen an der Anwendung, da sie nicht gleichzeitig mit Cassandra und Amazon Keyspaces kommunizieren muss. Außerdem kann bei unterbrochenem Datenfluss der exakte Status kopiert werden, ohne dass Mutationen beibehalten werden.
In diesem Beispiel verwenden wir Amazon Simple Storage Service (Amazon S3) als Staging-Bereich für Daten während der Offline-Migration, um Ausfallzeiten zu minimieren. Sie können die Daten, die Sie im Parquet-Format in Amazon S3 gespeichert haben, mithilfe des Spark-Cassandra-Connectors und automatisch in eine Amazon Keyspaces-Tabelle importieren. AWS Glue Der folgende Abschnitt gibt einen allgemeinen Überblick über den Prozess. Codebeispiele für diesen Prozess finden Sie auf [Github](https://github.com/aws-samples/amazon-keyspaces-examples/tree/main/scala/datastax-v4/aws-glue).
Der Offline-Migrationsprozess von Apache Cassandra zu Amazon Keyspaces mithilfe von Amazon S3 AWS Glue erfordert die folgenden AWS Glue Jobs.
1. Ein ETL-Job, der CQL-Daten extrahiert, transformiert und in einem Amazon S3 S3-Bucket speichert.
1. Ein zweiter Job, der die Daten aus dem Bucket in Amazon Keyspaces importiert.
1. Ein dritter Job zum Importieren inkrementeller Daten.
**So führen Sie eine Offline-Migration von Cassandra, die auf Amazon EC2 in einer Amazon Virtual Private Cloud läuft, zu Amazon Keyspaces durch**
1. Zuerst exportieren Sie AWS Glue Tabellendaten aus Cassandra im Parquet-Format und speichern sie in einem Amazon S3 S3-Bucket. Sie müssen einen AWS Glue Job mithilfe eines AWS Glue Connectors zu einer VPC ausführen, auf der sich die EC2 Amazon-Instance befindet, auf der Cassandra ausgeführt wird. Anschließend können Sie mit dem privaten Amazon S3 S3-Endpunkt Daten im Amazon S3 S3-Bucket speichern.
Das folgende Diagramm veranschaulicht diese Schritte.
![\[Migration von Apache Cassandra-Daten von Amazon, die in einer VPC EC2 ausgeführt werden, zu einem Amazon S3 S3-Bucket mit. AWS Glue\]](http://docs.aws.amazon.com/de_de/keyspaces/latest/devguide/images/migration/migration-export.png)
1. Mischen Sie die Daten im Amazon S3 S3-Bucket, um die Datenrandomisierung zu verbessern. Gleichmäßig importierte Daten ermöglichen einen stärker verteilten Datenverkehr in der Zieltabelle.
Dieser Schritt ist erforderlich, wenn Daten aus Cassandra mit großen Partitionen (Partitionen mit mehr als 1000 Zeilen) exportiert werden, um Tastenkombinationen beim Einfügen der Daten in Amazon Keyspaces zu vermeiden. Hotkey-Probleme treten `WriteThrottleEvents` in Amazon Keyspaces auf und führen zu einer längeren Ladezeit.
![\[Ein AWS Glue Job mischt Daten aus einem Amazon S3 S3-Bucket und gibt sie in einen anderen Amazon S3 S3-Bucket zurück.\]](http://docs.aws.amazon.com/de_de/keyspaces/latest/devguide/images/migration/migration-shuffle.png)
1. Verwenden Sie einen anderen AWS Glue Job, um Daten aus dem Amazon S3 S3-Bucket in Amazon Keyspaces zu importieren. Die gemischten Daten im Amazon S3 S3-Bucket werden im Parquet-Format gespeichert.
![\[Der AWS Glue Importjob nimmt gemischte Daten aus dem Amazon S3 S3-Bucket und verschiebt sie in eine Amazon Keyspaces-Tabelle.\]](http://docs.aws.amazon.com/de_de/keyspaces/latest/devguide/images/migration/migration-import.png)
Weitere Informationen zum Offline-Migrationsprozess finden Sie im Workshop [Amazon Keyspaces](https://catalog.workshops.aws/unlocking-amazonkeyspaces/en-US/keyspaces-with-glue) mit AWS Glue
# Verwendung einer hybriden Migrationslösung: Apache Cassandra zu Amazon Keyspaces
Die folgende Migrationslösung kann als Hybrid zwischen Online- und Offline-Migration betrachtet werden. Bei diesem hybriden Ansatz werden Daten nahezu in Echtzeit in die Zieldatenbank geschrieben, ohne dass eine Konsistenz beim Lesen nach dem Schreiben gewährleistet ist. Das bedeutet, dass neu geschriebene Daten nicht sofort verfügbar sind und Verzögerungen zu erwarten sind. Wenn Sie Konsistenz beim Lesen nach dem Schreiben benötigen, finden Sie weitere Informationen unter[Online-Migration zu Amazon Keyspaces: Strategien und bewährte Methoden](migrating-online.md).
Für eine Migration von Apache Cassandra zu Amazon Keyspaces nahezu in Echtzeit können Sie zwischen zwei verfügbaren Methoden wählen.
+ **CQLReplicator**— (Empfohlen) CQLReplicator ist ein auf [Github](https://github.com/aws-samples/cql-replicator) verfügbares Open-Source-Hilfsprogramm, mit dem Sie Daten nahezu in Echtzeit von Apache Cassandra zu Amazon Keyspaces migrieren können.
Um zu ermitteln, welche Schreibvorgänge und Aktualisierungen an die Zieldatenbank weitergegeben werden sollen, CQLReplicator scannt es den Apache Cassandra-Tokenbereich und verwendet einen AWS Glue Job, um doppelte Ereignisse zu entfernen und Schreibvorgänge und Aktualisierungen direkt auf Amazon Keyspaces anzuwenden.
+ **Change Data Capture (CDC)** — Wenn Sie mit Cassandra CDC vertraut sind, ist die in Apache Cassandra integrierte CDC-Funktion, mit der Änderungen erfasst werden können, indem das Commit-Protokoll in ein separates CDC-Verzeichnis kopiert wird, eine weitere Option für die Implementierung einer Hybridmigration.
Sie können dies tun, indem Sie die Datenänderungen auf Amazon Keyspaces replizieren, wodurch CDC zu einer alternativen Option für Datenmigrationsszenarien wird.
Wenn Sie keine Konsistenz beim Lesen nach dem Schreiben benötigen, können Sie entweder die CQLReplicator oder eine CDC-Pipeline verwenden, um Daten von Apache Cassandra zu Amazon Keyspaces zu migrieren, je nach Ihren Präferenzen und Ihrer Vertrautheit mit den Tools, die in den einzelnen Lösungen AWS-Services verwendet werden. Die Verwendung dieser Methoden zur Migration von Daten nahezu in Echtzeit kann als hybrider Migrationsansatz betrachtet werden, der eine Alternative zur Online-Migration bietet.
Diese Strategie wird als hybrider Ansatz betrachtet, da Sie zusätzlich zu den in diesem Thema beschriebenen Optionen einige Schritte der Online-Migration implementieren müssen, z. B. das Kopieren historischer Daten und die im Thema [Online-Migration erörterten Strategien zur Anwendungsmigration](migrating-online.md).
In den folgenden Abschnitten werden die Optionen für die Hybridmigration ausführlicher behandelt.
**Topics**
+ [Migrieren Sie Daten mit CQLReplicator](migration-hybrid-cql-rep.md)
+ [Migrieren Sie Daten mithilfe von Change Data Capture (CDC)](migration-hybrid-cdc.md)
# Migrieren Sie Daten mit CQLReplicator
Mit [CQLReplicator](https://github.com/aws-samples/cql-replicator)können Sie Daten aus Apache Cassandra nahezu in Echtzeit lesen, indem Sie den Cassandra-Tokenring mithilfe von CQL-Abfragen intelligent scannen. CQLReplicator verwendet Cassandra CDC nicht und implementiert stattdessen eine Caching-Strategie, um die Leistungseinbußen bei vollständigen Scans zu reduzieren.
Um die Anzahl der Schreibvorgänge auf das Ziel zu reduzieren, CQLReplicator werden doppelte Replikationsereignisse automatisch entfernt. Mit CQLReplicator können Sie die Replikation von Änderungen von der Quelldatenbank zur Zieldatenbank optimieren und so eine Migration von Daten von Apache Cassandra zu Amazon Keyspaces nahezu in Echtzeit ermöglichen.
Das folgende Diagramm zeigt die typische Architektur eines CQLReplicator Jobs mit. AWS Glue
1. **Um den Zugriff auf Apache Cassandra zu ermöglichen, das in einer privaten VPC ausgeführt wird, konfigurieren Sie eine AWS Glue Verbindung mit dem Verbindungstyp Netzwerk.**
1. Um Duplikate zu entfernen und das Schlüssel-Caching für den CQLReplicator Job zu aktivieren, konfigurieren Sie Amazon Simple Storage Service (Amazon S3).
1. Der CQLReplicator Job streamt verifizierte Quelldatenbankänderungen direkt an Amazon Keyspaces.
![\[Wird verwendet CQLReplicator , um Daten von Apache Cassandra zu Amazon Keyspaces zu migrieren.\]](http://docs.aws.amazon.com/de_de/keyspaces/latest/devguide/images/migration/hybrid-migration-CQLRep.png)
Weitere Informationen zum Migrationsprozess finden Sie im folgenden Beitrag im AWS Datenbank-Blog [Migrieren von Cassandra-Workloads zu Amazon Keyspaces using CQLReplicator](https://aws.amazon.com/blogs/database/migrate-cassandra-workloads-to-amazon-keyspaces-using-cqlreplicator/) und in der AWS präskriptiven Anleitung [Migrieren Sie Apache Cassandra-Workloads](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migrate-apache-cassandra-workloads-to-amazon-keyspaces-using-aws-glue.html) zu Amazon Keyspaces mithilfe von. CQLReplicator AWS Glue
# Migrieren Sie Daten mithilfe von Change Data Capture (CDC)
Wenn Sie bereits mit der Konfiguration einer Change Data Capture (CDC) -Pipeline mit [Debezium](https://debezium.io/) vertraut sind, können Sie diese Option als Alternative zur Verwendung verwenden, um Daten zu Amazon Keyspaces zu migrieren. CQLReplicator Debezium ist eine verteilte Open-Source-Plattform für CDC, die entwickelt wurde, um eine Datenbank zu überwachen und Änderungen auf Zeilenebene zuverlässig zu erfassen.
Der [Debezium-Konnektor für Apache Cassandra](https://debezium.io/documentation/reference/stable/connectors/cassandra.html) lädt Änderungen in Amazon Managed Streaming for Apache Kafka (Amazon MSK) hoch, sodass sie von nachgeschalteten Verbrauchern genutzt und verarbeitet werden können, die wiederum die Daten in Amazon Keyspaces schreiben. Weitere Informationen finden Sie unter [Anleitung für die kontinuierliche Datenmigration von Apache Cassandra zu Amazon Keyspaces](https://aws.amazon.com/solutions/guidance/continuous-data-migration-from-apache-cassandra-to-amazon-keyspaces/).
Um mögliche Probleme mit der Datenkonsistenz zu beheben, können Sie mit Amazon MSK einen Prozess implementieren, bei dem ein Verbraucher die Schlüssel oder Partitionen in Cassandra mit denen in Amazon Keyspaces vergleicht.
Um diese Lösung erfolgreich zu implementieren, empfehlen wir, Folgendes zu berücksichtigen.
+ Wie man das CDC-Commit-Protokoll analysiert, zum Beispiel wie man doppelte Ereignisse entfernt.
+ Wie man das CDC-Verzeichnis verwaltet, zum Beispiel wie man alte Logs löscht.
+ Wie man mit Teilausfällen in Apache Cassandra umgeht, zum Beispiel wenn ein Schreibvorgang nur in einem von drei Replikaten erfolgreich ist.
+ Wie geht man mit der Ressourcenzuweisung um, indem man beispielsweise die Größe der Instanz erhöht, um zusätzliche CPU-, Arbeitsspeicher-, FESTPLATTEN- und I/O-Anforderungen für den CDC-Prozess zu berücksichtigen, der auf einem Knoten stattfindet.
Dieses Muster behandelt Änderungen von Cassandra als „Hinweis“, dass sich ein Schlüssel möglicherweise gegenüber seinem vorherigen Zustand geändert hat. Um festzustellen, ob es Änderungen gibt, die an die Zieldatenbank weitergegeben werden müssen, müssen Sie zuerst aus dem Cassandra-Quellcluster lesen, indem Sie eine `LOCAL_QUORUM` Operation verwenden, um die neuesten Datensätze zu empfangen, und sie dann in Amazon Keyspaces schreiben.
Bei Bereichslöschungen oder Bereichsupdates müssen Sie möglicherweise einen Vergleich mit der gesamten Partition durchführen, um festzustellen, welche Schreib- oder Aktualisierungsereignisse in Ihre Zieldatenbank geschrieben werden müssen.
In Fällen, in denen Schreibvorgänge nicht idempotent sind, müssen Sie Ihre Schreibvorgänge auch mit dem vergleichen, was sich bereits in der Zieldatenbank befindet, bevor Sie in Amazon Keyspaces schreiben.
Das folgende Diagramm zeigt die typische Architektur einer CDC-Pipeline mit Debezium und Amazon MSK.
![\[Verwendung einer Change Data Capture-Pipeline zur Migration von Daten von Apache Cassandra zu Amazon Keyspaces.\]](http://docs.aws.amazon.com/de_de/keyspaces/latest/devguide/images/migration/hybrid-migration-CDC.png)