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.
# Migration zu Amazon Keyspaces (für Apache Cassandra)
Die Migration zu Amazon Keyspaces (für Apache Cassandra) bietet eine Reihe überzeugender Vorteile für Unternehmen und Organisationen. Hier sind einige wichtige Vorteile, die Amazon Keyspaces zu einer attraktiven Wahl für die Migration machen.
+ **Skalierbarkeit** — Amazon Keyspaces ist darauf ausgelegt, enorme Workloads zu bewältigen und nahtlos zu skalieren, um wachsenden Datenmengen und Datenströmen gerecht zu werden. Bei herkömmlichem Cassandra erfolgt die Skalierung nicht bei Bedarf und erfordert die Planung zukünftiger Spitzenwerte. Mit Amazon Keyspaces können Sie Ihre Tabellen je nach Bedarf einfach nach oben oder unten skalieren und so sicherstellen, dass Ihre Anwendungen plötzliche Datenverkehrsspitzen ohne Leistungseinbußen bewältigen können.
+ **Leistung** — Amazon Keyspaces bietet Datenzugriff mit niedriger Latenz, sodass Anwendungen Daten mit außergewöhnlicher Geschwindigkeit abrufen und verarbeiten können. Die verteilte Architektur stellt sicher, dass Lese- und Schreibvorgänge auf mehrere Knoten verteilt werden, sodass selbst bei hohen Anforderungsraten konsistente Antwortzeiten im einstelligen Millisekundenbereich erzielt werden.
+ **Vollständig verwaltet** — Amazon Keyspaces ist ein vollständig verwalteter Service von AWS. Das bedeutet, dass er sich um die betrieblichen Aspekte der Datenbankverwaltung AWS kümmert, einschließlich Bereitstellung, Konfiguration, Patching, Backups und Skalierung. Auf diese Weise können Sie sich mehr auf die Entwicklung Ihrer Anwendungen und weniger auf Datenbankverwaltungsaufgaben konzentrieren.
+ **Serverlose Architektur** — Amazon Keyspaces ist serverlos. Sie zahlen nur für die verbrauchte Kapazität, ohne dass vorab Kapazitäten bereitgestellt werden müssen. Sie müssen weder Server verwalten noch Instanzen auswählen. Dieses pay-per-request Modell bietet Kosteneffizienz und minimalen Betriebsaufwand, da Sie nur für die Ressourcen zahlen, die Sie verbrauchen, ohne dass Kapazitäten bereitgestellt und überwacht werden müssen.
+ **NoSQL-Flexibilität mit Schema** — Amazon Keyspaces folgt einem NoSQL-Datenmodell, das Flexibilität beim Schemadesign bietet. Mit Amazon Keyspaces können Sie strukturierte, halbstrukturierte und unstrukturierte Daten speichern, sodass sie sich gut für den Umgang mit unterschiedlichen und sich weiterentwickelnden Datentypen eignen. Darüber hinaus führt Amazon Keyspaces beim Schreiben eine Schemavalidierung durch, was eine zentralisierte Weiterentwicklung des Datenmodells ermöglicht. Diese Flexibilität ermöglicht schnellere Entwicklungszyklen und eine einfachere Anpassung an sich ändernde Geschäftsanforderungen.
+ **Hohe Verfügbarkeit und Beständigkeit** — Amazon Keyspaces repliziert Daten über mehrere [Availability Zones](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/) innerhalb einer und gewährleistet so eine AWS-Region hohe Verfügbarkeit und Datenbeständigkeit. Es übernimmt automatisch Replikation, Failover und Wiederherstellung und minimiert so das Risiko von Datenverlusten oder Serviceunterbrechungen. Amazon Keyspaces bietet eine Verfügbarkeits-SLA von bis zu 99,999% [Für noch mehr Stabilität und lokale Lesevorgänge mit geringer Latenz bietet Amazon Keyspaces Replikation in mehreren Regionen.](multiRegion-replication.md)
+ **Sicherheit und Compliance** — Amazon Keyspaces lässt sich AWS Identity and Access Management für eine differenzierte Zugriffskontrolle integrieren. Es bietet Verschlüsselung im Ruhezustand und bei der Übertragung und trägt so zur Verbesserung der Sicherheit Ihrer Daten bei. Amazon Keyspaces wurde von externen Prüfern auf Sicherheit und Einhaltung bestimmter Programme wie HIPAA, PCI DSS und SOC geprüft, sodass Sie die gesetzlichen Anforderungen erfüllen können. Weitere Informationen finden Sie unter [Konformitätsprüfung für Amazon Keyspaces (für Apache Cassandra)](Keyspaces-compliance.md).
+ **Integration mit dem AWS Ökosystem** — Als Teil des AWS Ökosystems lässt sich Amazon Keyspaces nahtlos in andere AWS-Services Systeme integrieren AWS CloudFormation, beispielsweise Amazon CloudWatch und AWS CloudTrail. Diese Integration ermöglicht es Ihnen, serverlose Architekturen zu erstellen, Infrastruktur als Code zu nutzen und datengesteuerte Echtzeitanwendungen zu erstellen. Weitere Informationen finden Sie unter [Überwachung von Amazon Keyspaces (für Apache Cassandra)](monitoring-overview.md).
**Topics**
+ [Erstellen Sie einen Migrationsplan für die Migration von Apache Cassandra zu Amazon Keyspaces](migrating-cassandra.md)
+ [So wählen Sie das richtige Tool für den Massen-Upload oder die Migration von Daten zu Amazon Keyspaces](migrating-tools.md)
# 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)
# So wählen Sie das richtige Tool für den Massen-Upload oder die Migration von Daten zu Amazon Keyspaces
In diesem Abschnitt können Sie sich mit den verschiedenen Tools vertraut machen, mit denen Sie Daten massenweise auf Amazon Keyspaces hochladen oder migrieren können, und erfahren, wie Sie das richtige Tool für Ihre Bedürfnisse auswählen können. Darüber hinaus bietet dieser Abschnitt einen Überblick und Anwendungsfälle für die verfügbaren step-by-step Tutorials, die zeigen, wie Daten in Amazon Keyspaces importiert werden.
Informationen zu den verfügbaren Strategien für die Migration von Workloads von Apache Cassandra zu Amazon Keyspaces finden Sie unter. [Erstellen Sie einen Migrationsplan für die Migration von Apache Cassandra zu Amazon Keyspaces](migrating-cassandra.md)
+ **Tools für die Migration**
+ Mit dem [Preisrechner für Amazon Keyspaces (für Apache Cassandra)](https://aws-samples.github.io/sample-pricing-calculator-for-keyspaces/#cassandra), der auf Github verfügbar ist, können Sie Ihre monatlichen Kosten für Amazon Keyspaces auf der Grundlage Ihrer vorhandenen Apache Cassandra-Arbeitslast schätzen. Geben Sie Metriken aus Ihrer Cassandra-Nodetool-Statusausgabe und der geplanten serverlosen Konfiguration für Amazon Keyspaces ein, um die direkten Kosten zwischen den beiden Lösungen zu vergleichen. Beachten Sie, dass sich dieser Rechner nur auf die Betriebskosten von Amazon Keyspaces im Vergleich zu Ihrer bestehenden Cassandra-Bereitstellung konzentriert. Dabei sind die Gesamtbetriebskosten (TCO) wie Infrastrukturwartung, Betriebskosten oder Supportkosten für Cassandra nicht berücksichtigt.
+ **ZDM Dual Write Proxy für die Amazon Keyspaces-Migration** — Der auf [Github](https://github.com/aws-samples/amazon-keyspaces-examples/blob/main/migration/online/zdm-proxy/README.md) verfügbare ZDM Dual Write Proxy unterstützt die Migration ohne Ausfallzeiten von Apache Cassandra zu Amazon Keyspaces.
+ **CQLReplicator**— 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.
Weitere Informationen finden Sie unter [Migrieren Sie Daten mit CQLReplicator](migration-hybrid-cql-rep.md).
+ Weitere Informationen zur Verwendung von Amazon Managed Streaming for Apache Kafka zur Implementierung eines [Online-Migrationsprozesses](migrating-online.md) mit Dual-Writes finden Sie unter [Anleitung für die kontinuierliche Datenmigration von Apache Cassandra zu](https://aws.amazon.com/solutions/guidance/continuous-data-migration-from-apache-cassandra-to-amazon-keyspaces/) Amazon Keyspaces.
+ Für umfangreiche Migrationen sollten Sie die Verwendung eines ETL-Tool (Extract, Transform and Load) in Betracht ziehen. Sie können es verwenden AWS Glue , um Datentransformationsmigrationen schnell und effektiv durchzuführen. Weitere Informationen finden Sie unter [Offline-Migrationsprozess: Apache Cassandra zu Amazon Keyspaces](migrating-offline.md).
+ Informationen zur Verwendung des Apache Cassandra Spark-Connectors zum Schreiben von Daten in Amazon Keyspaces finden Sie unter. [Tutorial: Integrieren Sie Apache Spark, um Daten zu importieren oder zu exportieren](spark-integrating.md)
+ Beginnen Sie schnell mit dem Laden von Daten in Amazon Keyspaces mithilfe des `COPY FROM` Befehls cqlsh. cqlsh ist in Apache Cassandra enthalten und eignet sich am besten zum Laden kleiner Datensätze oder Testdaten. [Tutorial: Daten mit cqlsh in Amazon Keyspaces laden](bulk-upload.md)Eine Anleitung finden Sie step-by-step unter.
+ Sie können auch den DataStax Bulk Loader für Apache Cassandra verwenden, um Daten mit dem Befehl in Amazon Keyspaces zu laden. `dsbulk` DSBulk[bietet robustere Importfunktionen als cqlsh und ist im Repository verfügbar. GitHub ](https://github.com/datastax/dsbulk) step-by-stepEine Anleitung dazu finden Sie unter. [Tutorial: Daten in Amazon Keyspaces laden mit DSBulk](dsbulk-upload.md)
Allgemeine Überlegungen zu Datenuploads auf Amazon Keyspaces
+ **Teilen Sie den Datenupload in kleinere Komponenten auf.**
Betrachten Sie die folgenden Migrationseinheiten und ihren potenziellen Platzbedarf in Bezug auf die Rohdatengröße. Das Hochladen kleinerer Datenmengen in einer oder mehreren Phasen kann dazu beitragen, Ihre Migration zu vereinfachen.
+ **Nach Clustern** — Migrieren Sie alle Ihre Cassandra-Daten auf einmal. Dieser Ansatz kann für kleinere Cluster in Ordnung sein.
+ **Nach Schlüsselraum oder Tabelle** — Teilen Sie Ihre Migration in Gruppen von Schlüsselräumen oder Tabellen auf. Dieser Ansatz kann Ihnen dabei helfen, Daten in Phasen zu migrieren, die Ihren Anforderungen für jeden Workload entsprechen.
+ **Nach Daten** — Erwägen Sie die Migration von Daten für eine bestimmte Gruppe von Benutzern oder Produkten, um die Datenmenge noch weiter zu reduzieren.
+ **Priorisieren Sie anhand der Einfachheit, welche Daten zuerst hochgeladen werden sollen.**
Überlegen Sie, ob Sie Daten haben, die zunächst einfacher migriert werden könnten, z. B. Daten, die sich zu bestimmten Zeiten nicht ändern, Daten aus nächtlichen Batch-Jobs, Daten, die während der Offline-Zeiten nicht verwendet werden, oder Daten aus internen Apps.
**Topics**
+ [Tutorial: Daten mit cqlsh in Amazon Keyspaces laden](bulk-upload.md)
+ [Tutorial: Daten in Amazon Keyspaces laden mit DSBulk](dsbulk-upload.md)
# Tutorial: Daten mit cqlsh in Amazon Keyspaces laden
Dieses Tutorial führt Sie durch den Prozess der Migration von Daten von Apache Cassandra zu Amazon Keyspaces mithilfe des Befehls. `cqlsh COPY FROM` Der `cqlsh COPY FROM` Befehl ist nützlich, um schnell und einfach kleine Datensätze für akademische Zwecke oder Testzwecke auf Amazon Keyspaces hochzuladen. Weitere Informationen zur Migration von Produktionsworkloads finden Sie unter. [Offline-Migrationsprozess: Apache Cassandra zu Amazon Keyspaces](migrating-offline.md) In diesem Tutorial führen Sie die folgenden Schritte durch:
Voraussetzungen — Richten Sie ein AWS Konto mit Anmeldeinformationen ein, erstellen Sie eine JKS-Trust-Store-Datei für das Zertifikat und konfigurieren Sie die Verbindung `cqlsh` zu Amazon Keyspaces.
1. **Quell-CSV und Zieltabelle erstellen** — Bereiten Sie eine CSV-Datei als Quelldaten vor und erstellen Sie den Zielschlüsselraum und die Zieltabelle in Amazon Keyspaces.
1. **Daten vorbereiten** — Randomisieren Sie die Daten in der CSV-Datei und analysieren Sie sie, um die durchschnittliche und maximale Zeilengröße zu ermitteln.
1. **Durchsatzkapazität festlegen** — Berechnen Sie die erforderlichen Schreibkapazitätseinheiten (WCUs) auf der Grundlage der Datengröße und der gewünschten Ladezeit und konfigurieren Sie die bereitgestellte Kapazität der Tabelle.
1. **Cqlsh-Parameter konfigurieren** — Ermitteln Sie optimale Werte für `cqlsh COPY FROM` Parameter wie`INGESTRATE`,, und `NUMPROCESSES``MAXBATCHSIZE`, um die Arbeitslast gleichmäßig `CHUNKSIZE` zu verteilen.
1. **`cqlsh COPY FROM`Befehl ausführen** — Führen Sie den `cqlsh COPY FROM` Befehl aus, um die Daten aus der CSV-Datei in die Amazon Keyspaces-Tabelle hochzuladen, und überwachen Sie den Fortschritt.
Fehlerbehebung — Beheben Sie häufig auftretende Probleme wie ungültige Anfragen, Parserfehler, Kapazitätsfehler und Cqlsh-Fehler beim Hochladen von Daten.
**Topics**
+ [Voraussetzungen: Schritte, die Sie ausführen müssen, bevor Sie Daten hochladen können mit `cqlsh COPY FROM`](bulk-upload-prequs.md)
+ [Schritt 1: Erstellen Sie die CSV-Quelldatei und eine Zieltabelle für den Datenupload](bulk-upload-source.md)
+ [Schritt 2: Bereiten Sie die Quelldaten für einen erfolgreichen Datenupload vor](bulk-upload-prepare-data.md)
+ [Schritt 3: Stellen Sie die Durchsatzkapazität für die Tabelle ein](bulk-upload-capacity.md)
+ [Schritt 4: `cqlsh COPY FROM` Einstellungen konfigurieren](bulk-upload-config.md)
+ [Schritt 5: Führen Sie den `cqlsh COPY FROM` Befehl aus, um Daten aus der CSV-Datei in die Zieltabelle hochzuladen](bulk-upload-run.md)
+ [Fehlerbehebung](bulk-upload-troubleshooting.md)
# Voraussetzungen: Schritte, die Sie ausführen müssen, bevor Sie Daten hochladen können mit `cqlsh COPY FROM`
Sie müssen die folgenden Aufgaben erledigen, bevor Sie mit diesem Tutorial beginnen können.
1. Falls Sie dies noch nicht getan haben, melden Sie sich für eine an, AWS-Konto indem Sie den Schritten unter folgen[Einrichten AWS Identity and Access Management](accessing.md#SettingUp.IAM).
1. Erstellen Sie dienstspezifische Anmeldeinformationen, indem Sie die Schritte unter [Dienstspezifische Anmeldeinformationen für den programmatischen Zugriff auf Amazon Keyspaces erstellen](programmatic.credentials.ssc.md) befolgen.
1. Richten Sie die Cassandra Query Language Shell (cqlsh) -Verbindung ein und bestätigen Sie, dass Sie eine Verbindung zu Amazon Keyspaces herstellen können, indem Sie die Schritte unter befolgen. [Verwenden`cqlsh`, um eine Verbindung zu Amazon Keyspaces herzustellen](programmatic.cqlsh.md)
# Schritt 1: Erstellen Sie die CSV-Quelldatei und eine Zieltabelle für den Datenupload
Für dieses Tutorial verwenden wir eine Datei mit kommagetrennten Werten (CSV) mit dem Namen `keyspaces_sample_table.csv` als Quelldatei für die Datenmigration. Die mitgelieferte Beispieldatei enthält einige Datenzeilen für eine Tabelle mit dem Namen. `book_awards`
1. Erstellen Sie die Quelldatei. Sie können eine der folgenden Optionen wählen:
+ Laden Sie die CSV-Beispieldatei (`keyspaces_sample_table.csv`) herunter, die in der folgenden Archivdatei [samplemigration.zip](samples/samplemigration.zip) enthalten ist. Entpacken Sie das Archiv und notieren Sie sich den Pfad zu`keyspaces_sample_table.csv`.
+ Um eine CSV-Datei mit Ihren eigenen Daten zu füllen, die in einer Apache Cassandra-Datenbank gespeichert sind, können Sie die CSV-Quelldatei mit der `cqlsh` `COPY TO` Anweisung füllen, wie im folgenden Beispiel gezeigt.
```
cqlsh localhost 9042 -u "username" -p "password" --execute "COPY mykeyspace.mytable TO 'keyspaces_sample_table.csv' WITH HEADER=true";
```
Stellen Sie sicher, dass die von Ihnen erstellte CSV-Datei die folgenden Anforderungen erfüllt:
+ Die erste Zeile enthält die Spaltennamen.
+ Die Spaltennamen in der CSV-Quelldatei stimmen mit den Spaltennamen in der Zieltabelle überein.
+ Die Daten sind durch ein Komma getrennt.
+ Alle Datenwerte sind gültige Amazon Keyspaces-Datentypen. Siehe [Datentypen](cql.elements.md#cql.data-types).
1. Erstellen Sie den Zielschlüsselraum und die Zieltabelle in Amazon Keyspaces.
1. Connect zu Amazon Keyspaces her`cqlsh`, indem Sie den Service-Endpunkt, den Benutzernamen und das Passwort im folgenden Beispiel durch Ihre eigenen Werte ersetzen.
```
cqlsh cassandra.us-east-1.amazonaws.com 9142 -u "111122223333" -p "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" --ssl
```
1. Erstellen Sie einen neuen Schlüsselraum mit dem Namen, `catalog` wie im folgenden Beispiel gezeigt.
```
CREATE KEYSPACE catalog WITH REPLICATION = {'class': 'SingleRegionStrategy'};
```
1. Wenn der neue Schlüsselraum verfügbar ist, verwenden Sie den folgenden Code, um die Zieltabelle zu erstellen. `book_awards`
```
CREATE TABLE "catalog.book_awards" (
year int,
award text,
rank int,
category text,
book_title text,
author text,
publisher text,
PRIMARY KEY ((year, award), category, rank)
);
```
Wenn Apache Cassandra Ihre ursprüngliche Datenquelle ist, besteht eine einfache Möglichkeit, die Amazon Keyspaces-Zieltabelle mit passenden Headern zu erstellen, darin, die `CREATE TABLE` Anweisung aus der Quelltabelle zu generieren, wie in der folgenden Anweisung gezeigt.
```
cqlsh localhost 9042 -u "username" -p "password" --execute "DESCRIBE TABLE mykeyspace.mytable;"
```
Erstellen Sie dann die Zieltabelle in Amazon Keyspaces mit den Spaltennamen und Datentypen, die der Beschreibung aus der Cassandra-Quelltabelle entsprechen.
# Schritt 2: Bereiten Sie die Quelldaten für einen erfolgreichen Datenupload vor
Die Vorbereitung der Quelldaten für eine effiziente Übertragung erfolgt in zwei Schritten. Zunächst randomisieren Sie die Daten. Im zweiten Schritt analysieren Sie die Daten, um die geeigneten `cqlsh` Parameterwerte und erforderlichen Tabelleneinstellungen zu ermitteln, um sicherzustellen, dass der Datenupload erfolgreich ist.
**Randomisieren Sie die Daten**
`cqlsh COPY FROM`Mit dem Befehl werden Daten in derselben Reihenfolge gelesen und geschrieben, in der sie in der CSV-Datei erscheinen. Wenn Sie den `cqlsh COPY TO` Befehl verwenden, um die Quelldatei zu erstellen, werden die Daten in schlüsselsortierter Reihenfolge in die CSV-Datei geschrieben. Intern partitioniert Amazon Keyspaces Daten mithilfe von Partitionsschlüsseln. Amazon Keyspaces verfügt zwar über eine integrierte Logik, die beim Lastenausgleich von Anfragen für denselben Partitionsschlüssel hilft, das Laden der Daten ist jedoch schneller und effizienter, wenn Sie die Reihenfolge nach dem Zufallsprinzip festlegen. Dies liegt daran, dass Sie den integrierten Lastenausgleich nutzen können, der auftritt, wenn Amazon Keyspaces auf verschiedene Partitionen schreibt.
Um die Schreibvorgänge gleichmäßig auf die Partitionen zu verteilen, müssen Sie die Daten in der Quelldatei randomisieren. [Sie können dafür eine Anwendung schreiben oder ein Open-Source-Tool wie Shuf verwenden.](https://en.wikipedia.org/wiki/Shuf) Shuf ist auf Linux-Distributionen, auf macOS (durch Installation von Coreutils in [Homebrew](https://brew.sh)) und unter Windows (mithilfe des Windows Subsystems for Linux (WSL)) kostenlos verfügbar. Ein zusätzlicher Schritt ist erforderlich, um zu verhindern, dass die Kopfzeile mit den Spaltennamen in diesem Schritt gemischt wird.
Um die Quelldatei nach dem Zufallsprinzip zu sortieren und gleichzeitig die Kopfzeile beizubehalten, geben Sie den folgenden Code ein.
```
tail -n +2 keyspaces_sample_table.csv | shuf -o keyspace.table.csv && (head -1 keyspaces_sample_table.csv && cat keyspace.table.csv ) > keyspace.table.csv1 && mv keyspace.table.csv1 keyspace.table.csv
```
Shuf schreibt die Daten in eine neue CSV-Datei mit dem Namen um. `keyspace.table.csv` Sie können die `keyspaces_sample_table.csv` Datei jetzt löschen — Sie benötigen sie nicht mehr.
**Analysieren Sie die Daten**
Ermitteln Sie die durchschnittliche und maximale Zeilengröße, indem Sie die Daten analysieren.
Sie tun dies aus den folgenden Gründen:
+ Die durchschnittliche Zeilengröße hilft bei der Schätzung der Gesamtmenge der zu übertragenden Daten.
+ Sie benötigen die durchschnittliche Zeilengröße, um die für den Datenupload benötigte Schreibkapazität bereitzustellen.
+ Sie können sicherstellen, dass jede Zeile weniger als 1 MB groß ist. Dies ist die maximale Zeilengröße in Amazon Keyspaces.
**Anmerkung**
Dieses Kontingent bezieht sich auf die Zeilengröße, nicht auf die Partitionsgröße. Im Gegensatz zu Apache Cassandra-Partitionen können Amazon Keyspaces-Partitionen praktisch unbegrenzt groß sein. Partitionsschlüssel und Clusterspalten benötigen zusätzlichen Speicherplatz für Metadaten, den Sie zur Rohgröße der Zeilen hinzufügen müssen. Weitere Informationen finden Sie unter [Schätzen Sie die Zeilengröße in Amazon Keyspaces](calculating-row-size.md).
Der folgende Code verwendet [AWK](https://en.wikipedia.org/wiki/AWK), um eine CSV-Datei zu analysieren und die durchschnittliche und maximale Zeilengröße zu drucken.
```
awk -F, 'BEGIN {samp=10000;max=-1;}{if(NR>1){len=length($0);t+=len;avg=t/NR;max=(len>max ? len : max)}}NR==samp{exit}END{printf("{lines: %d, average: %d bytes, max: %d bytes}\n",NR,avg,max);}' keyspace.table.csv
```
Die Ausführung dieses Codes führt zu der folgenden Ausgabe.
```
using 10,000 samples:
{lines: 10000, avg: 123 bytes, max: 225 bytes}
```
Im nächsten Schritt dieses Tutorials verwenden Sie die durchschnittliche Zeilengröße, um die Schreibkapazität für die Tabelle bereitzustellen.
# Schritt 3: Stellen Sie die Durchsatzkapazität für die Tabelle ein
Dieses Tutorial zeigt Ihnen, wie Sie cqlsh so einstellen, dass Daten innerhalb eines festgelegten Zeitbereichs geladen werden. Da Sie im Voraus wissen, wie viele Lese- und Schreibvorgänge Sie durchführen, sollten Sie den Modus für bereitgestellte Kapazität verwenden. Nachdem Sie die Datenübertragung abgeschlossen haben, sollten Sie den Kapazitätsmodus der Tabelle so einstellen, dass er den Datenverkehrsmustern Ihrer Anwendung entspricht. Weitere Informationen zur Kapazitätsverwaltung finden Sie unter[Verwaltung serverloser Ressourcen in Amazon Keyspaces (für Apache Cassandra)](serverless_resource_management.md).
Im Modus „Bereitgestellte Kapazität“ geben Sie im Voraus an, wie viel Lese- und Schreibkapazität Sie für Ihre Tabelle bereitstellen möchten. Die Schreibkapazität wird stündlich abgerechnet und in Schreibkapazitätseinheiten () gemessen. WCUs Jede WCU verfügt über ausreichend Schreibkapazität, um das Schreiben von 1 KB Daten pro Sekunde zu unterstützen. Wenn Sie die Daten laden, muss die Schreibrate unter dem in der Zieltabelle festgelegten Höchstwert WCUs (Parameter:`write_capacity_units`) liegen.
Standardmäßig können Sie bis WCUs zu 40.000 für eine Tabelle und 80.000 für alle WCUs Tabellen in Ihrem Konto bereitstellen. Wenn Sie zusätzliche Kapazität benötigen, können Sie in der [Service Quotas-Konsole eine Erhöhung des Kontingents](https://console.aws.amazon.com/servicequotas/home#!/services/cassandra/quotas) beantragen. Weitere Informationen zu Kontingenten finden Sie unter [Kontingente für Amazon Keyspaces (für Apache Cassandra)](quotas.md).
**Berechnen Sie die durchschnittliche Anzahl der für eine Einfügung WCUs erforderlichen**
Für das Einfügen von 1 KB Daten pro Sekunde ist 1 WCU erforderlich. Wenn Ihre CSV-Datei 360.000 Zeilen hat und Sie alle Daten in einer Stunde laden möchten, müssen Sie 100 Zeilen pro Sekunde schreiben (360.000 Zeilen/60 Minuten/ 60 Sekunden = 100 Zeilen pro Sekunde). Wenn jede Zeile bis zu 1 KB Daten enthält, müssen Sie 100 Zeilen pro Sekunde für Ihre Tabelle bereitstellen, WCUs um 100 Zeilen pro Sekunde einzufügen. Wenn jede Zeile 1,5 KB Daten enthält, benötigen Sie zwei, WCUs um eine Zeile pro Sekunde einzufügen. Um 100 Zeilen pro Sekunde einzufügen, müssen Sie daher 200 bereitstellen WCUs.
Um zu ermitteln, wie viele Zeilen WCUs Sie pro Sekunde einfügen müssen, teilen Sie die durchschnittliche Zeilengröße in Byte durch 1024 und runden Sie auf die nächste ganze Zahl auf.
Wenn die durchschnittliche Zeilengröße beispielsweise 3000 Byte beträgt, benötigen Sie drei, WCUs um eine Zeile pro Sekunde einzufügen.
```
ROUNDUP(3000 / 1024) = ROUNDUP(2.93) = 3 WCUs
```
**Berechnen Sie die Ladezeit und Kapazität der Daten**
Da Sie nun die durchschnittliche Größe und Anzahl der Zeilen in Ihrer CSV-Datei kennen, können Sie berechnen, wie viele WCUs Sie benötigen, um die Daten in einem bestimmten Zeitraum zu laden, und die ungefähre Zeit, die zum Laden aller Daten in Ihrer CSV-Datei benötigt wird, mithilfe verschiedener WCU-Einstellungen berechnen.
Wenn beispielsweise jede Zeile in Ihrer Datei 1 KB groß ist und Sie 1.000.000 Zeilen in Ihrer CSV-Datei haben, müssen Sie für diese Stunde mindestens 278 Zeilen für Ihre Tabelle bereitstellen, WCUs um die Daten in einer Stunde zu laden.
```
1,000,000 rows * 1 KBs = 1,000,000 KBs
1,000,000 KBs / 3600 seconds =277.8 KBs / second = 278 WCUs
```
**Konfigurieren Sie die Einstellungen für die bereitgestellte Kapazität**
Sie können die Schreibkapazitätseinstellungen einer Tabelle festlegen, wenn Sie die Tabelle erstellen oder den `ALTER TABLE` CQL-Befehl verwenden. Im Folgenden finden Sie die Syntax für die Änderung der bereitgestellten Kapazitätseinstellungen einer Tabelle mit der `ALTER TABLE` CQL-Anweisung.
```
ALTER TABLE mykeyspace.mytable WITH custom_properties={'capacity_mode':{'throughput_mode': 'PROVISIONED', 'read_capacity_units': 100, 'write_capacity_units': 278}} ;
```
Die vollständige Sprachreferenz finden Sie unter. [ALTER TABLE](cql.ddl.table.md#cql.ddl.table.alter)
# Schritt 4: `cqlsh COPY FROM` Einstellungen konfigurieren
In diesem Abschnitt wird beschrieben, wie Sie die Parameterwerte für ermitteln`cqlsh COPY FROM`. Der `cqlsh COPY FROM` Befehl liest die CSV-Datei, die Sie zuvor vorbereitet haben, und fügt die Daten mithilfe von CQL in Amazon Keyspaces ein. Der Befehl teilt die Zeilen auf und verteilt die `INSERT` Operationen auf eine Gruppe von Arbeitern. Jeder Mitarbeiter stellt eine Verbindung zu Amazon Keyspaces her und sendet `INSERT` Anfragen über diesen Kanal.
Der `cqlsh COPY` Befehl hat keine interne Logik, um die Arbeit gleichmäßig auf die Mitarbeiter zu verteilen. Sie können ihn jedoch manuell konfigurieren, um sicherzustellen, dass die Arbeit gleichmäßig verteilt wird. Überprüfen Sie zunächst die folgenden wichtigen Cqlsh-Parameter:
+ **DELIMITER** — Wenn Sie ein anderes Trennzeichen als ein Komma verwendet haben, können Sie diesen Parameter festlegen, der standardmäßig auf Komma gesetzt ist.
+ **INGESTRATE** — Die Zielanzahl von Zeilen, die pro Sekunde verarbeitet werden sollen. `cqlsh COPY FROM` Wenn sie nicht gesetzt ist, ist sie standardmäßig auf 100.000 eingestellt.
+ **NUMPROCESSES** — Die Anzahl der untergeordneten Worker-Prozesse, die cqlsh für Aufgaben erstellt. `COPY FROM` Das Maximum für diese Einstellung ist 16, die Standardeinstellung ist dabei die Anzahl der Prozessorkerne auf dem Host`num_cores - 1`, auf dem cqlsh ausgeführt `num_cores` wird.
+ **MAXBATCHSIZE** — Die Batchgröße bestimmt die maximale Anzahl von Zeilen, die in einem einzigen Batch in die Zieltabelle eingefügt werden. Falls nicht gesetzt, verwendet cqlsh Stapel von 20 eingefügten Zeilen.
+ **CHUNKSIZE — Die Größe** der Arbeitseinheit, die an den untergeordneten Arbeiter weitergegeben wird. Standardmäßig ist sie auf 5.000 festgelegt.
+ **MAXATTEMPTS** — Die maximale Anzahl von Wiederholungen für einen fehlgeschlagenen Worker-Chunk. Wenn der maximale Versuch erreicht ist, werden die fehlgeschlagenen Datensätze in eine neue CSV-Datei geschrieben, die Sie später erneut ausführen können, nachdem Sie den Fehler untersucht haben.
Dieser Wert `INGESTRATE` basiert auf der Anzahl der WCUs Dateien, die Sie in der Zieltabelle bereitgestellt haben. Der `INGESTRATE` Wert des `cqlsh COPY FROM` Befehls ist kein Limit, sondern ein Zieldurchschnitt. Das bedeutet, dass er die von Ihnen festgelegte Zahl überschreiten kann (und tut dies häufig auch). Um Bursts zu berücksichtigen und sicherzustellen, dass genügend Kapazität zur Bearbeitung der Datenladeanforderungen vorhanden ist, sollten Sie einen Wert von 90% der Schreibkapazität der Tabelle festlegen`INGESTRATE`.
```
INGESTRATE = WCUs * .90
```
Stellen Sie als Nächstes den `NUMPROCESSES` Parameter so ein, dass er um eins kleiner ist als die Anzahl der Kerne in Ihrem System. Um herauszufinden, wie viele Kerne Ihr System hat, können Sie den folgenden Code ausführen.
```
python -c "import multiprocessing; print(multiprocessing.cpu_count())"
```
Für dieses Tutorial verwenden wir den folgenden Wert.
```
NUMPROCESSES = 4
```
Jeder Prozess erstellt einen Worker, und jeder Worker stellt eine Verbindung zu Amazon Keyspaces her. Amazon Keyspaces kann bei jeder Verbindung bis zu 3.000 CQL-Anfragen pro Sekunde unterstützen. Das bedeutet, dass Sie sicherstellen müssen, dass jeder Mitarbeiter weniger als 3.000 Anfragen pro Sekunde verarbeitet.
Wie bei der `INGESTRATE` anderen Methode überschreiten die Mitarbeiter häufig die von Ihnen festgelegte Anzahl und sind nicht durch Taktsekunden begrenzt. Um Bursts zu berücksichtigen, sollten Sie Ihre cqlsh-Parameter daher so einstellen, dass jeder Worker 2.500 Anfragen pro Sekunde verarbeitet. Verwenden Sie die folgende Richtlinie, um den Arbeitsaufwand zu berechnen, der auf eine Arbeitskraft verteilt wird.
+ Dividiere `INGESTRATE` durch`NUMPROCESSES`.
+ Wenn`INGESTRATE`/`NUMPROCESSES`> 2.500, verringern Sie den Wert, `INGESTRATE` damit diese Formel wahr wird.
```
INGESTRATE / NUMPROCESSES <= 2,500
```
Bevor Sie die Einstellungen zur Optimierung des Uploads unserer Beispieldaten konfigurieren, sollten wir uns zunächst die `cqlsh` Standardeinstellungen ansehen und herausfinden, wie sich ihre Verwendung auf den Daten-Upload-Prozess auswirkt. Da der `cqlsh COPY FROM` verwendet wird`CHUNKSIZE`, um Arbeitsblöcke (`INSERT`Kontoauszüge) zu erstellen, um sie an die Mitarbeiter zu verteilen, wird die Arbeit nicht automatisch gleichmäßig verteilt. Je nach Einstellung können einige Mitarbeiter untätig sitzen. `INGESTRATE`
Um die Arbeit gleichmäßig auf die Mitarbeiter zu verteilen und dafür zu sorgen, dass für jeden Mitarbeiter die optimale Rate von 2.500 Anfragen pro Sekunde erreicht wird`CHUNKSIZE`, müssen Sie`MAXBATCHSIZE`, und `INGESTRATE` durch Ändern der Eingabeparameter festlegen. Um die Auslastung des Netzwerkverkehrs während des Datenladens zu optimieren, wählen Sie einen Wert`MAXBATCHSIZE`, der dem Höchstwert von 30 nahe kommt. Wenn `CHUNKSIZE` Sie den Wert auf 100 und `MAXBATCHSIZE` auf 25 ändern, werden die 10.000 Zeilen gleichmäßig auf die vier Mitarbeiter verteilt (10.000/2500 = 4).
Das folgende Codebeispiel veranschaulicht dies.
```
INGESTRATE = 10,000
NUMPROCESSES = 4
CHUNKSIZE = 100
MAXBATCHSIZE. = 25
Work Distribution:
Connection 1 / Worker 1 : 2,500 Requests per second
Connection 2 / Worker 2 : 2,500 Requests per second
Connection 3 / Worker 3 : 2,500 Requests per second
Connection 4 / Worker 4 : 2,500 Requests per second
```
Zusammenfassend lässt sich sagen, dass Sie beim Einstellen von `cqlsh COPY FROM` Parametern die folgenden Formeln verwenden:
+ **INGESTRATE** = write\$1capacity\$1units \$1 .90
+ **NUMPROCESSES** = num\$1cores -1 (Standard)
+ **INGESTRATE//NUMPROCESSES = 2.500** (Dies muss eine wahre Aussage sein.)
+ **MAXBATCHSIZE** = 30 (Der Standardwert ist 20. Amazon Keyspaces akzeptiert Batches von bis zu 30.)
+ **CHUNKSIZE = (INGESTRATE**//NUMPROCESSES)/MAXBATCHSIZE
Nachdem Sie, und `CHUNKSIZE` berechnet haben, sind Sie `NUMPROCESSES` bereit`INGESTRATE`, Ihre Daten zu laden.
# Schritt 5: Führen Sie den `cqlsh COPY FROM` Befehl aus, um Daten aus der CSV-Datei in die Zieltabelle hochzuladen
Führen Sie die folgenden Schritte `cqlsh COPY FROM` aus, um den Befehl auszuführen.
1. Stellen Sie mithilfe von cqlsh eine Connect zu Amazon Keyspaces her.
1. Wählen Sie Ihren Keyspace mit dem folgenden Code aus.
```
USE catalog;
```
1. Stellen Sie die Schreibkonsistenz auf ein. `LOCAL_QUORUM` Um die Datenbeständigkeit zu gewährleisten, erlaubt Amazon Keyspaces keine anderen Einstellungen für die Schreibkonsistenz. Sehen Sie sich den folgenden Code an.
```
CONSISTENCY LOCAL_QUORUM;
```
1. Bereiten Sie Ihre `cqlsh COPY FROM` Syntax anhand des folgenden Codebeispiels vor.
```
COPY book_awards FROM './keyspace.table.csv' WITH HEADER=true
AND INGESTRATE=calculated ingestrate
AND NUMPROCESSES=calculated numprocess
AND MAXBATCHSIZE=20
AND CHUNKSIZE=calculated chunksize;
```
1. Führen Sie die im vorherigen Schritt vorbereitete Anweisung aus. cqlsh gibt alle Einstellungen zurück, die Sie konfiguriert haben.
1. Stellen Sie sicher, dass die Einstellungen mit Ihrer Eingabe übereinstimmen. Sehen Sie sich das folgende Beispiel an.
```
Reading options from the command line: {'chunksize': '120', 'header': 'true', 'ingestrate': '36000', 'numprocesses': '15', 'maxbatchsize': '20'}
Using 15 child processes
```
1. Überprüfen Sie die Anzahl der übertragenen Zeilen und die aktuelle Durchschnittsrate, wie im folgenden Beispiel gezeigt.
```
Processed: 57834 rows; Rate: 6561 rows/s; Avg. rate: 31751 rows/s
```
1. Wenn cqlsh das Hochladen der Daten abgeschlossen hat, überprüfen Sie die Zusammenfassung der Datenladestatistiken (Anzahl der gelesenen Dateien, Laufzeit und übersprungene Zeilen), wie im folgenden Beispiel gezeigt.
```
15556824 rows imported from 1 files in 8 minutes and 8.321 seconds (0 skipped).
```
In diesem letzten Schritt des Tutorials haben Sie die Daten auf Amazon Keyspaces hochgeladen.
**Wichtig**
Nachdem Sie Ihre Daten übertragen haben, passen Sie die Einstellungen für den Kapazitätsmodus Ihrer Zieltabelle an die regulären Datenverkehrsmuster Ihrer Anwendung an. Es fallen Gebühren zum Stundensatz für Ihre bereitgestellte Kapazität an, bis Sie diese ändern.
# Fehlerbehebung
Überprüfen Sie nach Abschluss des Datenuploads, ob Zeilen übersprungen wurden. Navigieren Sie dazu zum Quellverzeichnis der CSV-Quelldatei und suchen Sie nach einer Datei mit dem folgenden Namen.
```
import_yourcsvfilename.err.timestamp.csv
```
cqlsh schreibt alle übersprungenen Datenzeilen in eine Datei mit diesem Namen. Wenn die Datei in Ihrem Quellverzeichnis vorhanden ist und Daten enthält, wurden diese Zeilen nicht in Amazon Keyspaces hochgeladen. Um diese Zeilen erneut zu versuchen, überprüfen Sie zunächst, ob beim Upload Fehler aufgetreten sind, und passen Sie die Daten entsprechend an. Um diese Zeilen erneut zu versuchen, können Sie den Vorgang erneut ausführen.
**Häufige Fehler**
Die häufigsten Gründe, warum Zeilen nicht geladen werden, sind Kapazitätsfehler und Analysefehler.
**Ungültige Anforderungsfehler beim Hochladen von Daten zu Amazon Keyspaces**
Im folgenden Beispiel enthält die Quelltabelle eine Zählerspalte, die zu protokollierten Batch-Aufrufen des Befehls `COPY` cqlsh führt. Protokollierte Batch-Aufrufe werden von Amazon Keyspaces nicht unterstützt.
```
Failed to import 10 rows: InvalidRequest - Error from server: code=2200 [Invalid query] message=“Only UNLOGGED Batches are supported at this time.“, will retry later, attempt 22 of 25
```
Um diesen Fehler zu beheben, verwenden Sie, DSBulk um die Daten zu migrieren. Weitere Informationen finden Sie unter [Tutorial: Daten in Amazon Keyspaces laden mit DSBulk](dsbulk-upload.md).
**Parser-Fehler beim Hochladen von Daten zu Amazon Keyspaces**
Das folgende Beispiel zeigt eine übersprungene Zeile aufgrund von a. `ParseError`
```
Failed to import 1 rows: ParseError - Invalid ... –
```
Um diesen Fehler zu beheben, müssen Sie sicherstellen, dass die zu importierenden Daten dem Tabellenschema in Amazon Keyspaces entsprechen. Überprüfen Sie die Importdatei auf Analysefehler. Sie können versuchen, mithilfe einer `INSERT` Anweisung eine einzelne Datenzeile zu verwenden, um den Fehler zu isolieren.
**Kapazitätsfehler beim Hochladen von Daten auf Amazon Keyspaces**
```
Failed to import 1 rows: WriteTimeout - Error from server: code=1100 [Coordinator node timed out waiting for replica nodes' responses]
message="Operation timed out - received only 0 responses." info={'received_responses': 0, 'required_responses': 2, 'write_type': 'SIMPLE', 'consistency':
'LOCAL_QUORUM'}, will retry later, attempt 1 of 100
```
Amazon Keyspaces verwendet die `WriteTimeout` Ausnahmen `ReadTimeout` und, um anzuzeigen, wenn eine Schreibanforderung aufgrund unzureichender Durchsatzkapazität fehlschlägt. Um bei der Diagnose von Ausnahmen bei unzureichender Kapazität zu helfen, veröffentlicht `WriteThrottleEvents` Amazon Keyspaces `ReadThrottledEvents` Statistiken in Amazon CloudWatch. Weitere Informationen finden Sie unter [Überwachung von Amazon Keyspaces mit Amazon CloudWatch](monitoring-cloudwatch.md).
**cqlsh-Fehler beim Hochladen von Daten zu Amazon Keyspaces**
Um Cqlsh-Fehler zu beheben, führen Sie den fehlgeschlagenen Befehl erneut mit der Markierung aus. `--debug`
Wenn Sie eine inkompatible Version von cqlsh verwenden, wird der folgende Fehler angezeigt.
```
AttributeError: 'NoneType' object has no attribute 'is_up'
Failed to import 3 rows: AttributeError - 'NoneType' object has no attribute 'is_up', given up after 1 attempts
```
Vergewissern Sie sich, dass die richtige Version von cqlsh installiert ist, indem Sie den folgenden Befehl ausführen.
```
cqlsh --version
```
Sie sollten etwa das Folgende als Ausgabe sehen.
```
cqlsh 5.0.1
```
Wenn Sie Windows verwenden, ersetzen Sie alle Instanzen von `cqlsh` durch`cqlsh.bat`. Um beispielsweise die Version von cqlsh in Windows zu überprüfen, führen Sie den folgenden Befehl aus.
```
cqlsh.bat --version
```
Die Verbindung zu Amazon Keyspaces schlägt fehl, nachdem der cqlsh-Client drei aufeinanderfolgende Fehler beliebiger Art vom Server empfangen hat. Der Cqlsh-Client schlägt mit der folgenden Meldung fehl.
```
Failed to import 1 rows: NoHostAvailable - , will retry later, attempt 3 of 100
```
Um diesen Fehler zu beheben, müssen Sie sicherstellen, dass die zu importierenden Daten dem Tabellenschema in Amazon Keyspaces entsprechen. Überprüfen Sie die Importdatei auf Analysefehler. Sie können versuchen, eine einzelne Datenzeile zu verwenden, indem Sie eine INSERT-Anweisung verwenden, um den Fehler zu isolieren.
Der Client versucht automatisch, die Verbindung wiederherzustellen.
# Tutorial: Daten in Amazon Keyspaces laden mit DSBulk
Dieses step-by-step Tutorial führt Sie durch die Migration von Daten von Apache Cassandra zu Amazon Keyspaces mithilfe des DataStax Bulk Loaders (DSBulk), der auf verfügbar ist. [GitHub](https://github.com/datastax/dsbulk.git) DSBulk Die Verwendung ist nützlich, um Datensätze für akademische Zwecke oder Testzwecke auf Amazon Keyspaces hochzuladen. Weitere Informationen zur Migration von Produktionsworkloads finden Sie unter. [Offline-Migrationsprozess: Apache Cassandra zu Amazon Keyspaces](migrating-offline.md) In diesem Tutorial führen Sie die folgenden Schritte aus.
Voraussetzungen — Richten Sie ein AWS Konto mit Anmeldeinformationen ein, erstellen Sie eine JKS-Trust-Store-Datei für das Zertifikat, konfigurieren Sie `cqlsh` es, laden Sie es herunter und installieren Sie DSBulk es und konfigurieren Sie eine `application.conf` Datei.
1. **Quell-CSV und Zieltabelle erstellen** — Bereiten Sie eine CSV-Datei als Quelldaten vor und erstellen Sie den Zielschlüsselraum und die Zieltabelle in Amazon Keyspaces.
1. **Daten vorbereiten** — Randomisieren Sie die Daten in der CSV-Datei und analysieren Sie sie, um die durchschnittliche und maximale Zeilengröße zu ermitteln.
1. **Durchsatzkapazität festlegen** — Berechnen Sie die erforderlichen Schreibkapazitätseinheiten (WCUs) auf der Grundlage der Datengröße und der gewünschten Ladezeit und konfigurieren Sie die bereitgestellte Kapazität der Tabelle.
1. ** DSBulk Einstellungen konfigurieren** — Erstellen Sie eine DSBulk Konfigurationsdatei mit Einstellungen wie Authentifizierung, SSL/TLS, Konsistenzstufe und Größe des Verbindungspools.
1. **Den DSBulk Ladebefehl ausführen** — Führen Sie den Befehl DSBulk load aus, um die Daten aus der CSV-Datei in die Amazon Keyspaces-Tabelle hochzuladen und den Fortschritt zu überwachen.
**Topics**
+ [Voraussetzungen: Schritte, die Sie ausführen müssen, bevor Sie Daten hochladen können mit DSBulk](dsbulk-upload-prequs.md)
+ [Schritt 1: Erstellen Sie die Quell-CSV-Datei und eine Zieltabelle für den Datenupload mit DSBulk](dsbulk-upload-source.md)
+ [Schritt 2: Bereiten Sie die Daten für den Upload vor mit DSBulk](dsbulk-upload-prepare-data.md)
+ [Schritt 3: Stellen Sie die Durchsatzkapazität für die Zieltabelle ein](dsbulk-upload-capacity.md)
+ [Schritt 4: Konfigurieren Sie die `DSBulk` Einstellungen, um Daten aus der CSV-Datei in die Zieltabelle hochzuladen](dsbulk-upload-config.md)
+ [Schritt 5: Führen Sie den DSBulk `load` Befehl aus, um Daten aus der CSV-Datei in die Zieltabelle hochzuladen](dsbulk-upload-run.md)
# Voraussetzungen: Schritte, die Sie ausführen müssen, bevor Sie Daten hochladen können mit DSBulk
Sie müssen die folgenden Aufgaben erledigen, bevor Sie mit diesem Tutorial beginnen können.
1. Falls Sie dies noch nicht getan haben, registrieren Sie sich für ein AWS Konto, indem Sie den Schritten unter folgen[Einrichten AWS Identity and Access Management](accessing.md#SettingUp.IAM).
1. Erstellen Sie Anmeldeinformationen, indem Sie den Schritten unter folgen[AWS Anmeldeinformationen für Amazon Keyspaces erstellen und konfigurieren](access.credentials.md).
1. Erstellen Sie eine JKS-Trust-Store-Datei.
1. Laden Sie die folgenden digitalen Zertifikate herunter und speichern Sie die Dateien lokal oder in Ihrem Home-Verzeichnis.
1. AmazonRootCA1
1. AmazonRootCA2
1. AmazonRootCA3
1. AmazonRootCA4
1. Starfield Class 2 Root (optional — aus Gründen der Abwärtskompatibilität)
Um die Zertifikate herunterzuladen, können Sie die folgenden Befehle verwenden.
```
curl -O https://www.amazontrust.com/repository/AmazonRootCA1.pem
curl -O https://www.amazontrust.com/repository/AmazonRootCA2.pem
curl -O https://www.amazontrust.com/repository/AmazonRootCA3.pem
curl -O https://www.amazontrust.com/repository/AmazonRootCA4.pem
curl -O https://certs.secureserver.net/repository/sf-class2-root.crt
```
**Anmerkung**
Amazon Keyspaces verwendete zuvor TLS-Zertifikate, die in der Starfield Class 2 CA verankert waren. AWS migriert alle AWS-Regionen auf Zertifikate, die unter Amazon Trust Services (Amazon Root CAs 1—4) ausgestellt wurden. Während dieser Umstellung sollten Sie die Clients so konfigurieren, dass sie sowohl Amazon Root CAs 1—4 als auch Starfield Root vertrauen, um die Kompatibilität in allen Regionen sicherzustellen.
1. Konvertieren Sie die digitalen Zertifikate in TrustStore-Dateien und fügen Sie sie dem Keystore hinzu.
```
openssl x509 -outform der -in AmazonRootCA1.pem -out temp_file.der
keytool -import -alias amazon-root-ca-1 -keystore cassandra_truststore.jks -file temp_file.der
openssl x509 -outform der -in AmazonRootCA2.pem -out temp_file.der
keytool -import -alias amazon-root-ca-2 -keystore cassandra_truststore.jks -file temp_file.der
openssl x509 -outform der -in AmazonRootCA3.pem -out temp_file.der
keytool -import -alias amazon-root-ca-3 -keystore cassandra_truststore.jks -file temp_file.der
openssl x509 -outform der -in AmazonRootCA4.pem -out temp_file.der
keytool -import -alias amazon-root-ca-4 -keystore cassandra_truststore.jks -file temp_file.der
openssl x509 -outform der -in sf-class2-root.crt -out temp_file.der
keytool -import -alias cassandra -keystore cassandra_truststore.jks -file temp_file.der
```
Im letzten Schritt müssen Sie ein Passwort für den Keystore erstellen und jedem Zertifikat vertrauen. Der interaktive Befehl sieht so aus.
```
Enter keystore password:
Re-enter new password:
Owner: CN=Amazon Root CA 1, O=Amazon, C=US
Issuer: CN=Amazon Root CA 1, O=Amazon, C=US
Serial number: 66c9fcf99bf8c0a39e2f0788a43e696365bca
Valid from: Tue May 26 00:00:00 UTC 2015 until: Sun Jan 17 00:00:00 UTC 2038
Certificate fingerprints:
SHA1: 8D:A7:F9:65:EC:5E:FC:37:91:0F:1C:6E:59:FD:C1:CC:6A:6E:DE:16
SHA256: 8E:CD:E6:88:4F:3D:87:B1:12:5B:A3:1A:C3:FC:B1:3D:70:16:DE:7F:57:CC:90:4F:E1:CB:97:C6:AE:98:19:6E
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 2048-bit RSA key
Version: 3
Extensions:
#1: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:true
PathLen:2147483647
]
#2: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
DigitalSignature
Key_CertSign
Crl_Sign
]
#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 84 18 CC 85 34 EC BC 0C 94 94 2E 08 59 9C C7 B2 ....4.......Y...
0010: 10 4E 0A 08 .N..
]
]
Trust this certificate? [no]: yes
Certificate was added to keystore
Enter keystore password:
Owner: CN=Amazon Root CA 2, O=Amazon, C=US
Issuer: CN=Amazon Root CA 2, O=Amazon, C=US
Serial number: 66c9fd29635869f0a0fe58678f85b26bb8a37
Valid from: Tue May 26 00:00:00 UTC 2015 until: Sat May 26 00:00:00 UTC 2040
Certificate fingerprints:
SHA1: 5A:8C:EF:45:D7:A6:98:59:76:7A:8C:8B:44:96:B5:78:CF:47:4B:1A
SHA256: 1B:A5:B2:AA:8C:65:40:1A:82:96:01:18:F8:0B:EC:4F:62:30:4D:83:CE:C4:71:3A:19:C3:9C:01:1E:A4:6D:B4
Signature algorithm name: SHA384withRSA
Subject Public Key Algorithm: 4096-bit RSA key
Version: 3
Extensions:
#1: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:true
PathLen:2147483647
]
#2: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
DigitalSignature
Key_CertSign
Crl_Sign
]
#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: B0 0C F0 4C 30 F4 05 58 02 48 FD 33 E5 52 AF 4B ...L0..X.H.3.R.K
0010: 84 E3 66 52 ..fR
]
]
Trust this certificate? [no]: yes
Certificate was added to keystore
Enter keystore password:
Owner: CN=Amazon Root CA 3, O=Amazon, C=US
Issuer: CN=Amazon Root CA 3, O=Amazon, C=US
Serial number: 66c9fd5749736663f3b0b9ad9e89e7603f24a
Valid from: Tue May 26 00:00:00 UTC 2015 until: Sat May 26 00:00:00 UTC 2040
Certificate fingerprints:
SHA1: 0D:44:DD:8C:3C:8C:1A:1A:58:75:64:81:E9:0F:2E:2A:FF:B3:D2:6E
SHA256: 18:CE:6C:FE:7B:F1:4E:60:B2:E3:47:B8:DF:E8:68:CB:31:D0:2E:BB:3A:DA:27:15:69:F5:03:43:B4:6D:B3:A4
Signature algorithm name: SHA256withECDSA
Subject Public Key Algorithm: 256-bit EC (secp256r1) key
Version: 3
Extensions:
#1: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:true
PathLen:2147483647
]
#2: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
DigitalSignature
Key_CertSign
Crl_Sign
]
#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: AB B6 DB D7 06 9E 37 AC 30 86 07 91 70 C7 9C C4 ......7.0...p...
0010: 19 B1 78 C0 ..x.
]
]
Trust this certificate? [no]: yes
Certificate was added to keystore
Enter keystore password:
Owner: CN=Amazon Root CA 4, O=Amazon, C=US
Issuer: CN=Amazon Root CA 4, O=Amazon, C=US
Serial number: 66c9fd7c1bb104c2943e5717b7b2cc81ac10e
Valid from: Tue May 26 00:00:00 UTC 2015 until: Sat May 26 00:00:00 UTC 2040
Certificate fingerprints:
SHA1: F6:10:84:07:D6:F8:BB:67:98:0C:C2:E2:44:C2:EB:AE:1C:EF:63:BE
SHA256: E3:5D:28:41:9E:D0:20:25:CF:A6:90:38:CD:62:39:62:45:8D:A5:C6:95:FB:DE:A3:C2:2B:0B:FB:25:89:70:92
Signature algorithm name: SHA384withECDSA
Subject Public Key Algorithm: 384-bit EC (secp384r1) key
Version: 3
Extensions:
#1: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:true
PathLen:2147483647
]
#2: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
DigitalSignature
Key_CertSign
Crl_Sign
]
#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: D3 EC C7 3A 65 6E CC E1 DA 76 9A 56 FB 9C F3 86 ...:en...v.V....
0010: 6D 57 E5 81 mW..
]
]
Trust this certificate? [no]: yes
Certificate was added to keystore
Enter keystore password:
Owner: OU=Starfield Class 2 Certification Authority, O="Starfield Technologies, Inc.", C=US
Issuer: OU=Starfield Class 2 Certification Authority, O="Starfield Technologies, Inc.", C=US
Serial number: 0
Valid from: Tue Jun 29 17:39:16 UTC 2004 until: Thu Jun 29 17:39:16 UTC 2034
Certificate fingerprints:
SHA1: AD:7E:1C:28:B0:64:EF:8F:60:03:40:20:14:C3:D0:E3:37:0E:B5:8A
SHA256: 14:65:FA:20:53:97:B8:76:FA:A6:F0:A9:95:8E:55:90:E4:0F:CC:7F:AA:4F:B7:C2:C8:67:75:21:FB:5F:B6:58
Signature algorithm name: SHA1withRSA (weak)
Subject Public Key Algorithm: 2048-bit RSA key
Version: 3
Extensions:
#1: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: BF 5F B7 D1 CE DD 1F 86 F4 5B 55 AC DC D7 10 C2 ._.......[U.....
0010: 0E A9 88 E7 ....
]
[OU=Starfield Class 2 Certification Authority, O="Starfield Technologies, Inc.", C=US]
SerialNumber: [ 00]
]
#2: ObjectId: 2.5.29.19 Criticality=false
BasicConstraints:[
CA:true
PathLen:2147483647
]
#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: BF 5F B7 D1 CE DD 1F 86 F4 5B 55 AC DC D7 10 C2 ._.......[U.....
0010: 0E A9 88 E7 ....
]
]
Warning:
The input uses the SHA1withRSA signature algorithm which is considered a security risk. This algorithm will be disabled in a future update.
Trust this certificate? [no]: yes
Certificate was added to keystore
```
1. Richten Sie die Cassandra Query Language Shell (cqlsh) -Verbindung ein und bestätigen Sie, dass Sie eine Verbindung zu Amazon Keyspaces herstellen können, indem Sie die Schritte unter befolgen. [Verwenden`cqlsh`, um eine Verbindung zu Amazon Keyspaces herzustellen](programmatic.cqlsh.md)
1. Downloaden und installieren. DSBulk
**Anmerkung**
Die in diesem Tutorial gezeigte Version ist möglicherweise nicht die neueste verfügbare Version. Suchen Sie vor dem Herunterladen DSBulk auf der [DataStax Bulk Loader-Downloadseite](https://downloads.datastax.com/#bulk-loader) nach der neuesten Version und aktualisieren Sie die Versionsnummer in den folgenden Befehlen entsprechend.
1. Zum Herunterladen DSBulk können Sie den folgenden Code verwenden.
```
curl -OL https://downloads.datastax.com/dsbulk/dsbulk-1.8.0.tar.gz
```
1. Entpacken Sie dann die TAR-Datei und fügen Sie DSBulk sie zu Ihrer hinzu, `PATH` wie im folgenden Beispiel gezeigt.
```
tar -zxvf dsbulk-1.8.0.tar.gz
# add the DSBulk directory to the path
export PATH=$PATH:./dsbulk-1.8.0/bin
```
1. Erstellen Sie eine `application.conf` Datei, um die Einstellungen zu speichern, von denen verwendet werden soll DSBulk. Sie können das folgende Beispiel unter speichern`./dsbulk_keyspaces.conf`. `localhost`Ersetzen Sie es durch den Kontaktpunkt Ihres lokalen Cassandra-Clusters, wenn Sie sich nicht auf dem lokalen Knoten befinden, z. B. den DNS-Namen oder die IP-Adresse. Notieren Sie sich den Dateinamen und den Pfad, da Sie dies später im `dsbulk load` Befehl angeben müssen.
```
datastax-java-driver {
basic.contact-points = [ "localhost"]
advanced.auth-provider {
class = software.aws.mcs.auth.SigV4AuthProvider
aws-region = us-east-1
}
}
```
1. Um die SigV4-Unterstützung zu aktivieren, laden Sie die schattierte `jar` Datei von herunter [GitHub](https://github.com/aws/aws-sigv4-auth-cassandra-java-driver-plugin/releases/)und platzieren Sie sie in dem DSBulk `lib` Ordner, wie im folgenden Beispiel gezeigt.
```
curl -O -L https://github.com/aws/aws-sigv4-auth-cassandra-java-driver-plugin/releases/download/4.0.6-shaded-v2/aws-sigv4-auth-cassandra-java-driver-plugin-4.0.6-shaded.jar
```
# Schritt 1: Erstellen Sie die Quell-CSV-Datei und eine Zieltabelle für den Datenupload mit DSBulk
Für dieses Tutorial verwenden wir eine Datei mit kommagetrennten Werten (CSV) mit dem Namen `keyspaces_sample_table.csv` als Quelldatei für die Datenmigration. Die mitgelieferte Beispieldatei enthält einige Datenzeilen für eine Tabelle mit dem Namen. `book_awards`
1. Erstellen Sie die Quelldatei. Sie können eine der folgenden Optionen wählen:
+ Laden Sie die CSV-Beispieldatei (`keyspaces_sample_table.csv`) herunter, die in der folgenden Archivdatei [samplemigration.zip](samples/samplemigration.zip) enthalten ist. Entpacken Sie das Archiv und notieren Sie sich den Pfad zu`keyspaces_sample_table.csv`.
+ Um eine CSV-Datei mit Ihren eigenen Daten zu füllen, die in einer Apache Cassandra-Datenbank gespeichert sind, können Sie die CSV-Quelldatei `dsbulk unload` wie im folgenden Beispiel gezeigt auffüllen.
```
dsbulk unload -k mykeyspace -t mytable -f ./my_application.conf > keyspaces_sample_table.csv
```
Stellen Sie sicher, dass die von Ihnen erstellte CSV-Datei die folgenden Anforderungen erfüllt:
+ Die erste Zeile enthält die Spaltennamen.
+ Die Spaltennamen in der CSV-Quelldatei stimmen mit den Spaltennamen in der Zieltabelle überein.
+ Die Daten sind durch ein Komma getrennt.
+ Alle Datenwerte sind gültige Amazon Keyspaces-Datentypen. Siehe [Datentypen](cql.elements.md#cql.data-types).
1. Erstellen Sie den Zielschlüsselraum und die Zieltabelle in Amazon Keyspaces.
1. Connect zu Amazon Keyspaces her`cqlsh`, indem Sie den Service-Endpunkt, den Benutzernamen und das Passwort im folgenden Beispiel durch Ihre eigenen Werte ersetzen.
```
cqlsh cassandra.us-east-1.amazonaws.com 9142 -u "111122223333" -p "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" --ssl
```
1. Erstellen Sie einen neuen Schlüsselraum mit dem Namen, `catalog` wie im folgenden Beispiel gezeigt.
```
CREATE KEYSPACE catalog WITH REPLICATION = {'class': 'SingleRegionStrategy'};
```
1. Wenn der neue Schlüsselraum den Status verfügbar hat, verwenden Sie den folgenden Code, um die Zieltabelle zu erstellen. `book_awards` Weitere Informationen zur asynchronen Ressourcenerstellung und zur Überprüfung, ob eine Ressource verfügbar ist, finden Sie unter. [Überprüfen Sie den Status der Schlüsselraumerstellung in Amazon Keyspaces](keyspaces-create.md)
```
CREATE TABLE catalog.book_awards (
year int,
award text,
rank int,
category text,
book_title text,
author text,
publisher text,
PRIMARY KEY ((year, award), category, rank)
);
```
Wenn Apache Cassandra Ihre ursprüngliche Datenquelle ist, besteht eine einfache Möglichkeit, die Amazon Keyspaces-Zieltabelle mit passenden Headern zu erstellen, darin, die `CREATE TABLE` Anweisung aus der Quelltabelle zu generieren, wie in der folgenden Anweisung gezeigt.
```
cqlsh localhost 9042 -u "username" -p "password" --execute "DESCRIBE TABLE mykeyspace.mytable;"
```
Erstellen Sie dann die Zieltabelle in Amazon Keyspaces mit den Spaltennamen und Datentypen, die der Beschreibung aus der Cassandra-Quelltabelle entsprechen.
# Schritt 2: Bereiten Sie die Daten für den Upload vor mit DSBulk
Die Vorbereitung der Quelldaten für eine effiziente Übertragung erfolgt in zwei Schritten. Zunächst randomisieren Sie die Daten. Im zweiten Schritt analysieren Sie die Daten, um die geeigneten `dsbulk` Parameterwerte und erforderlichen Tabelleneinstellungen zu ermitteln.
**Randomisieren Sie die Daten**
Der `dsbulk` Befehl liest und schreibt Daten in derselben Reihenfolge, in der sie in der CSV-Datei erscheinen. Wenn Sie den `dsbulk` Befehl verwenden, um die Quelldatei zu erstellen, werden die Daten in schlüsselsortierter Reihenfolge in die CSV-Datei geschrieben. Intern partitioniert Amazon Keyspaces Daten mithilfe von Partitionsschlüsseln. Amazon Keyspaces verfügt zwar über eine integrierte Logik, die beim Lastenausgleich von Anfragen für denselben Partitionsschlüssel hilft, das Laden der Daten ist jedoch schneller und effizienter, wenn Sie die Reihenfolge nach dem Zufallsprinzip festlegen. Dies liegt daran, dass Sie den integrierten Lastenausgleich nutzen können, der auftritt, wenn Amazon Keyspaces auf verschiedene Partitionen schreibt.
Um die Schreibvorgänge gleichmäßig auf die Partitionen zu verteilen, müssen Sie die Daten in der Quelldatei randomisieren. [Sie können dafür eine Anwendung schreiben oder ein Open-Source-Tool wie Shuf verwenden.](https://en.wikipedia.org/wiki/Shuf) Shuf ist auf Linux-Distributionen, auf macOS (durch Installation von Coreutils in [Homebrew](https://brew.sh)) und unter Windows (mithilfe des Windows Subsystems for Linux (WSL)) kostenlos verfügbar. Ein zusätzlicher Schritt ist erforderlich, um zu verhindern, dass die Kopfzeile mit den Spaltennamen in diesem Schritt gemischt wird.
Um die Quelldatei nach dem Zufallsprinzip zu sortieren und gleichzeitig die Kopfzeile beizubehalten, geben Sie den folgenden Code ein.
```
tail -n +2 keyspaces_sample_table.csv | shuf -o keyspace.table.csv && (head -1 keyspaces_sample_table.csv && cat keyspace.table.csv ) > keyspace.table.csv1 && mv keyspace.table.csv1 keyspace.table.csv
```
Shuf schreibt die Daten in eine neue CSV-Datei mit dem Namen um. `keyspace.table.csv` Sie können die `keyspaces_sample_table.csv` Datei jetzt löschen — Sie benötigen sie nicht mehr.
**Analysieren Sie die Daten**
Ermitteln Sie die durchschnittliche und maximale Zeilengröße, indem Sie die Daten analysieren.
Sie tun dies aus den folgenden Gründen:
+ Die durchschnittliche Zeilengröße hilft bei der Schätzung der Gesamtmenge der zu übertragenden Daten.
+ Sie benötigen die durchschnittliche Zeilengröße, um die für den Datenupload benötigte Schreibkapazität bereitzustellen.
+ Sie können sicherstellen, dass jede Zeile weniger als 1 MB groß ist. Dies ist die maximale Zeilengröße in Amazon Keyspaces.
**Anmerkung**
Dieses Kontingent bezieht sich auf die Zeilengröße, nicht auf die Partitionsgröße. Im Gegensatz zu Apache Cassandra-Partitionen können Amazon Keyspaces-Partitionen praktisch unbegrenzt groß sein. Partitionsschlüssel und Clusterspalten benötigen zusätzlichen Speicherplatz für Metadaten, den Sie zur Rohgröße der Zeilen hinzufügen müssen. Weitere Informationen finden Sie unter [Schätzen Sie die Zeilengröße in Amazon Keyspaces](calculating-row-size.md).
Der folgende Code verwendet [AWK](https://en.wikipedia.org/wiki/AWK), um eine CSV-Datei zu analysieren und die durchschnittliche und maximale Zeilengröße zu drucken.
```
awk -F, 'BEGIN {samp=10000;max=-1;}{if(NR>1){len=length($0);t+=len;avg=t/NR;max=(len>max ? len : max)}}NR==samp{exit}END{printf("{lines: %d, average: %d bytes, max: %d bytes}\n",NR,avg,max);}' keyspace.table.csv
```
Die Ausführung dieses Codes führt zu der folgenden Ausgabe.
```
using 10,000 samples:
{lines: 10000, avg: 123 bytes, max: 225 bytes}
```
Stellen Sie sicher, dass Ihre maximale Zeilengröße 1 MB nicht überschreitet. Ist dies der Fall, müssen Sie die Zeile aufteilen oder die Daten komprimieren, um die Zeilengröße unter 1 MB zu bringen. Im nächsten Schritt dieses Tutorials verwenden Sie die durchschnittliche Zeilengröße, um die Schreibkapazität für die Tabelle bereitzustellen.
# Schritt 3: Stellen Sie die Durchsatzkapazität für die Zieltabelle ein
Dieses Tutorial zeigt Ihnen, wie Sie das Laden von Daten innerhalb eines bestimmten Zeitbereichs einstellen können. DSBulk Da Sie im Voraus wissen, wie viele Lese- und Schreibvorgänge Sie durchführen, sollten Sie den Modus für bereitgestellte Kapazität verwenden. Nachdem Sie die Datenübertragung abgeschlossen haben, sollten Sie den Kapazitätsmodus der Tabelle so einstellen, dass er den Datenverkehrsmustern Ihrer Anwendung entspricht. Weitere Informationen zur Kapazitätsverwaltung finden Sie unter[Verwaltung serverloser Ressourcen in Amazon Keyspaces (für Apache Cassandra)](serverless_resource_management.md).
Im Modus „Bereitgestellte Kapazität“ geben Sie im Voraus an, wie viel Lese- und Schreibkapazität Sie für Ihre Tabelle bereitstellen möchten. Die Schreibkapazität wird stündlich abgerechnet und in Schreibkapazitätseinheiten () gemessen. WCUs Jede WCU bietet ausreichend Schreibkapazität, um das Schreiben von 1 KB Daten pro Sekunde zu unterstützen. Wenn Sie die Daten laden, muss die Schreibrate unter dem in der Zieltabelle festgelegten Höchstwert WCUs (Parameter:`write_capacity_units`) liegen.
Standardmäßig können Sie bis WCUs zu 40.000 für eine Tabelle und 80.000 für alle WCUs Tabellen in Ihrem Konto bereitstellen. Wenn Sie zusätzliche Kapazität benötigen, können Sie in der [Service Quotas-Konsole eine Erhöhung des Kontingents](https://console.aws.amazon.com/servicequotas/home#!/services/cassandra/quotas) beantragen. Weitere Informationen zu Kontingenten finden Sie unter [Kontingente für Amazon Keyspaces (für Apache Cassandra)](quotas.md).
**Berechnen Sie die durchschnittliche Anzahl der für eine Einfügung WCUs erforderlichen**
Für das Einfügen von 1 KB Daten pro Sekunde ist 1 WCU erforderlich. Wenn Ihre CSV-Datei 360.000 Zeilen hat und Sie alle Daten in einer Stunde laden möchten, müssen Sie 100 Zeilen pro Sekunde schreiben (360.000 Zeilen/60 Minuten/ 60 Sekunden = 100 Zeilen pro Sekunde). Wenn jede Zeile bis zu 1 KB Daten enthält, müssen Sie 100 Zeilen pro Sekunde für Ihre Tabelle bereitstellen, WCUs um 100 Zeilen pro Sekunde einzufügen. Wenn jede Zeile 1,5 KB Daten enthält, benötigen Sie zwei, WCUs um eine Zeile pro Sekunde einzufügen. Um 100 Zeilen pro Sekunde einzufügen, müssen Sie daher 200 bereitstellen WCUs.
Um zu ermitteln, wie viele Zeilen WCUs Sie pro Sekunde einfügen müssen, teilen Sie die durchschnittliche Zeilengröße in Byte durch 1024 und runden Sie auf die nächste ganze Zahl auf.
Wenn die durchschnittliche Zeilengröße beispielsweise 3000 Byte beträgt, benötigen Sie drei, WCUs um eine Zeile pro Sekunde einzufügen.
```
ROUNDUP(3000 / 1024) = ROUNDUP(2.93) = 3 WCUs
```
**Berechnen Sie die Ladezeit und Kapazität der Daten**
Da Sie nun die durchschnittliche Größe und Anzahl der Zeilen in Ihrer CSV-Datei kennen, können Sie berechnen, wie viele WCUs Sie benötigen, um die Daten in einem bestimmten Zeitraum zu laden, und die ungefähre Zeit, die zum Laden aller Daten in Ihrer CSV-Datei benötigt wird, mithilfe verschiedener WCU-Einstellungen berechnen.
Wenn beispielsweise jede Zeile in Ihrer Datei 1 KB groß ist und Sie 1.000.000 Zeilen in Ihrer CSV-Datei haben, müssen Sie für diese Stunde mindestens 278 Zeilen für Ihre Tabelle bereitstellen, WCUs um die Daten in einer Stunde zu laden.
```
1,000,000 rows * 1 KBs = 1,000,000 KBs
1,000,000 KBs / 3600 seconds =277.8 KBs / second = 278 WCUs
```
**Konfigurieren Sie die Einstellungen für die bereitgestellte Kapazität**
Sie können die Schreibkapazitätseinstellungen einer Tabelle festlegen, wenn Sie die Tabelle erstellen oder den `ALTER TABLE` Befehl verwenden. Im Folgenden finden Sie die Syntax für das Ändern der bereitgestellten Kapazitätseinstellungen einer Tabelle mit dem `ALTER TABLE` Befehl.
```
ALTER TABLE catalog.book_awards WITH custom_properties={'capacity_mode':{'throughput_mode': 'PROVISIONED', 'read_capacity_units': 100, 'write_capacity_units': 278}} ;
```
Die vollständige Sprachreferenz finden Sie unter [CREATE TABLE](cql.ddl.table.md#cql.ddl.table.create) und. [ALTER TABLE](cql.ddl.table.md#cql.ddl.table.alter)
# Schritt 4: Konfigurieren Sie die `DSBulk` Einstellungen, um Daten aus der CSV-Datei in die Zieltabelle hochzuladen
In diesem Abschnitt werden die Schritte beschrieben, die DSBulk zur Konfiguration des Daten-Uploads auf Amazon Keyspaces erforderlich sind. Sie konfigurieren DSBulk mithilfe einer Konfigurationsdatei. Sie geben die Konfigurationsdatei direkt von der Befehlszeile aus an.
1. Erstellen Sie eine DSBulk Konfigurationsdatei für die Migration zu Amazon Keyspaces. In diesem Beispiel verwenden wir den Dateinamen`dsbulk_keyspaces.conf`. Geben Sie die folgenden Einstellungen in der DSBulk Konfigurationsdatei an.
1. *`PlainTextAuthProvider`*— Erstellen Sie den Authentifizierungsanbieter mit der `PlainTextAuthProvider` Klasse. `ServiceUserName`und `ServicePassword` sollte mit dem Benutzernamen und dem Passwort übereinstimmen, die Sie bei der Generierung der dienstspezifischen Anmeldeinformationen erhalten haben, indem Sie die Schritte unter [Anmeldeinformationen für den programmatischen Zugriff auf Amazon Keyspaces erstellen](programmatic.credentials.md) ausführen.
1. *`local-datacenter`*— Setzen Sie den Wert für `local-datacenter` auf den AWS-Region , zu dem Sie eine Verbindung herstellen. Wenn die Anwendung beispielsweise eine Verbindung herstellt`cassandra.us-east-1.amazonaws.com`, stellen Sie das lokale Rechenzentrum auf ein`us-east-1`. Alle verfügbaren AWS-Regionen Informationen finden Sie unter[Service-Endpunkte für Amazon Keyspaces](programmatic.endpoints.md). Um Replikate zu vermeiden, legen Sie den Wert `slow-replica-avoidance` auf `false` fest.
1. *`SSLEngineFactory`*— Um SSL/TLS zu konfigurieren, initialisieren Sie das, `SSLEngineFactory` indem Sie der Konfigurationsdatei einen Abschnitt mit einer einzigen Zeile hinzufügen, in der die Klasse mit angegeben wird. `class = DefaultSslEngineFactory` Geben Sie den Pfad `cassandra_truststore.jks` und das Passwort an, die Sie zuvor erstellt haben.
1. *`consistency`*— Stellen Sie die Konsistenzstufe auf ein`LOCAL QUORUM`. Andere Schreibkonsistenzstufen werden nicht unterstützt. Weitere Informationen finden Sie unter[Unterstützte Lese- und Schreibkonsistenzstufen von Apache Cassandra und damit verbundene Kosten](consistency.md).
1. Die Anzahl der Verbindungen pro Pool ist im Java-Treiber konfigurierbar. Stellen Sie in diesem Beispiel `advanced.connection.pool.local.size` den Wert 3 ein.
Im Folgenden finden Sie die vollständige Beispielkonfigurationsdatei.
```
datastax-java-driver {
basic.contact-points = [ "cassandra.us-east-1.amazonaws.com:9142"]
advanced.auth-provider {
class = PlainTextAuthProvider
username = "ServiceUserName"
password = "ServicePassword"
}
basic.load-balancing-policy {
local-datacenter = "us-east-1"
slow-replica-avoidance = false
}
basic.request {
consistency = LOCAL_QUORUM
default-idempotence = true
}
advanced.ssl-engine-factory {
class = DefaultSslEngineFactory
truststore-path = "./cassandra_truststore.jks"
truststore-password = "my_password"
hostname-validation = false
}
advanced.connection.pool.local.size = 3
}
```
1. Überprüfen Sie die Parameter für den DSBulk `load` Befehl.
1. *`executor.maxPerSecond`*— Die maximale Anzahl von Zeilen, die der Ladebefehl pro Sekunde gleichzeitig zu verarbeiten versucht. Wenn sie nicht gesetzt ist, ist diese Einstellung mit -1 deaktiviert.
Wird auf der `executor.maxPerSecond` Grundlage der Anzahl festgelegt WCUs , die Sie für die Zieltabelle bereitgestellt haben. Der `executor.maxPerSecond` Wert des `load` Befehls ist kein Limit, sondern ein Zieldurchschnitt. Das bedeutet, dass er die von Ihnen festgelegte Zahl überschreiten kann (und tut dies häufig auch). Um Bursts zu berücksichtigen und sicherzustellen, dass genügend Kapazität zur Bearbeitung der Datenladeanforderungen vorhanden ist, sollten Sie einen Wert von 90% der Schreibkapazität der Tabelle festlegen`executor.maxPerSecond`.
```
executor.maxPerSecond = WCUs * .90
```
In diesem Tutorial haben wir den Wert 5 `executor.maxPerSecond` eingestellt.
**Anmerkung**
Wenn Sie DSBulk 1.6.0 oder höher verwenden, können Sie `dsbulk.engine.maxConcurrentQueries` stattdessen verwenden.
1. Konfigurieren Sie diese zusätzlichen Parameter für den DSBulk `load` Befehl.
+ *`batch-mode`*— Dieser Parameter weist das System an, Operationen nach Partitionsschlüsseln zu gruppieren. Wir empfehlen, den Batch-Modus zu deaktivieren, da dies zu Hotkey-Szenarien und Ursachen führen kann`WriteThrottleEvents`.
+ *`driver.advanced.retry-policy-max-retries`*— Dies bestimmt, wie oft eine fehlgeschlagene Abfrage wiederholt werden muss. Wenn diese Option nicht gesetzt ist, ist die Standardeinstellung 10. Sie können diesen Wert nach Bedarf anpassen.
+ *`driver.basic.request.timeout`*— Die Zeit in Minuten, in der das System auf die Rückgabe einer Abfrage wartet. Wenn diese Option nicht gesetzt ist, ist die Standardeinstellung „5 Minuten“. Sie können diesen Wert nach Bedarf anpassen.
# Schritt 5: Führen Sie den DSBulk `load` Befehl aus, um Daten aus der CSV-Datei in die Zieltabelle hochzuladen
Im letzten Schritt dieses Tutorials laden Sie die Daten in Amazon Keyspaces hoch.
Führen Sie die folgenden Schritte DSBulk `load` aus, um den Befehl auszuführen.
1. Führen Sie den folgenden Code aus, um die Daten aus Ihrer CSV-Datei in Ihre Amazon Keyspaces-Tabelle hochzuladen. Achten Sie darauf, den Pfad zur Anwendungskonfigurationsdatei zu aktualisieren, die Sie zuvor erstellt haben.
```
dsbulk load -f ./dsbulk_keyspaces.conf --connector.csv.url keyspace.table.csv -header true --batch.mode DISABLED --executor.maxPerSecond 5 --driver.basic.request.timeout "5 minutes" --driver.advanced.retry-policy.max-retries 10 -k catalog -t book_awards
```
1. Die Ausgabe enthält den Speicherort einer Protokolldatei, in der erfolgreiche und erfolglose Vorgänge aufgeführt sind. Die Datei wird im folgenden Verzeichnis gespeichert.
```
Operation directory: /home/user_name/logs/UNLOAD_20210308-202317-801911
```
1. Die Einträge in der Protokolldatei werden Metriken enthalten, wie im folgenden Beispiel. Stellen Sie sicher, dass die Anzahl der Zeilen mit der Anzahl der Zeilen in Ihrer CSV-Datei übereinstimmt.
```
total | failed | rows/s | p50ms | p99ms | p999ms
200 | 0 | 200 | 21.63 | 21.89 | 21.89
```
**Wichtig**
Nachdem Sie Ihre Daten übertragen haben, passen Sie die Einstellungen für den Kapazitätsmodus Ihrer Zieltabelle an die regulären Datenverkehrsmuster Ihrer Anwendung an. Es fallen Gebühren zum Stundensatz für Ihre bereitgestellte Kapazität an, bis Sie diese ändern. Weitere Informationen finden Sie unter [read/write Kapazitätsmodi in Amazon Keyspaces konfigurieren](ReadWriteCapacityMode.md).