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.
Hochladen historischer Daten während einer Online-Migration
Nachdem duale Schreibvorgänge implementiert wurden, um sicherzustellen, dass neue Daten in Echtzeit in beide Datenspeicher geschrieben werden, besteht der nächste Schritt im Migrationsplan darin, zu evaluieren, wie viele historische Daten Sie kopieren oder massenweise von Cassandra auf Amazon Keyspaces hochladen müssen. Dadurch wird sichergestellt, dass sowohl neue als auch historische Daten in der neuen Amazon Keyspaces-Datenbank verfügbar sind, bevor Sie die Anwendung migrieren.
Abhängig von Ihren Anforderungen zur Datenspeicherung, z. B. davon, wie viele historische Daten Sie gemäß den Richtlinien Ihres Unternehmens aufbewahren müssen, können Sie eine der folgenden beiden Optionen in Betracht ziehen.
Massen-Upload historischer Daten — Die Migration historischer Daten von Ihrer bestehenden Cassandra-Bereitstellung zu Amazon Keyspaces kann durch verschiedene Techniken erreicht werden, z. B. mithilfe von AWS Glue oder 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
Wenn Sie den Massenupload historischer Daten planen, müssen Sie berücksichtigen, wie Sie Konflikte lösen können, die auftreten können, wenn neue Schreibvorgänge versuchen, dieselben Daten zu aktualisieren, die gerade hochgeladen werden. Es wird erwartet, dass der Massen-Upload letztendlich konsistent ist, was bedeutet, dass die Daten irgendwann alle Knoten erreichen werden.
Wenn dieselben Daten aufgrund eines erneuten Schreibvorgangs gleichzeitig aktualisiert werden, sollten Sie sicherstellen, dass diese Daten nicht durch den Upload der historischen 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 (LWT) verwenden, um Operationen zu vergleichen und festzulegen. Dazu können Sie Ihrem Datenmodell ein zusätzliches Feld hinzufügen, das den Zeitpunkt der Änderung oder den Status darstellt.
Darüber hinaus unterstützt Amazon Keyspaces die
WRITETIMECassandra-Zeitstempelfunktion. Sie können clientseitige Zeitstempel von Amazon Keyspaces verwenden, um die Zeitstempel der Quelldatenbank beizubehalten und die Last-Writer-Wins-Konfliktlösung zu implementieren. Weitere Informationen finden Sie unter Client-side Zeitstempel in Amazon Keyspaces.Verwenden von Time-to-Live (TTL) — Für Datenaufbewahrungszeiträume unter 30, 60 oder 90 Tagen können Sie während der Migration TTL in Cassandra und Amazon Keyspaces verwenden, um zu vermeiden, dass unnötige historische Daten in Amazon Keyspaces hochgeladen werden. TTL ermöglicht es Ihnen, einen Zeitraum festzulegen, nach dem die Daten automatisch aus der Datenbank entfernt werden.
Während der Migrationsphase können Sie, anstatt historische Daten in Amazon Keyspaces zu kopieren, die TTL-Einstellungen so konfigurieren, dass die historischen Daten im alten System (Cassandra) automatisch ablaufen, während die neuen Schreibvorgänge nur mithilfe der Dual-Write-Methode auf Amazon Keyspaces angewendet werden. Im Laufe der Zeit und da alte Daten im Cassandra-Cluster kontinuierlich ablaufen und neue Daten mit der Dual-Write-Methode geschrieben wurden, holt Amazon Keyspaces automatisch nach 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 Datenaufbewahrungsanforderungen zu tun haben. Weitere Informationen zu TTL finden Sie unter Daten mit Time to Live (TTL) für Amazon Keyspaces (für Apache Cassandra) ablaufen lassen.
Stellen Sie sich das folgende Beispiel für eine Migration von Cassandra zu Amazon Keyspaces mit TTL-Datenablauf vor. In diesem Beispiel setzen wir TTL für beide Datenbanken auf 60 Tage und zeigen, wie der Migrationsprozess über einen Zeitraum von 90 Tagen abläuft. Beide Datenbanken erhalten in diesem Zeitraum dieselben neu geschriebenen Daten unter Verwendung der Methode mit zwei Schreibvorgängen. 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.
Nach den ersten 30 Tagen haben der Cassandra-Cluster und Amazon Keyspaces neue Schreibvorgänge erhalten. Der Cassandra-Cluster enthält auch historische Daten, für die die Aufbewahrungsdauer von 60 Tagen noch nicht erreicht ist, was 50% der Daten im Cluster ausmacht.
Daten, die älter als 60 Tage sind, werden im Cassandra-Cluster mithilfe von TTL automatisch gelöscht. Zu diesem Zeitpunkt enthält Amazon Keyspaces 50% der im Cassandra-Cluster gespeicherten Daten, die sich aus den neuen Schreibvorgängen abzüglich der historischen Daten zusammensetzen.
Nach 60 Tagen enthalten sowohl der Cassandra-Cluster als auch Amazon Keyspaces dieselben Daten, die in den letzten 60 Tagen geschrieben wurden.
Innerhalb von 90 Tagen enthalten sowohl Cassandra als auch Amazon Keyspaces dieselben Daten und die Daten laufen mit derselben Geschwindigkeit ab.
Dieses Beispiel zeigt, wie Sie den Schritt des Hochladens historischer Daten vermeiden können, indem Sie TTL mit einem auf 60 Tage festgelegten Ablaufdatum verwenden.
