翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # オンライン移行中の履歴データのアップロード デュアル書き込みを実装して新しいデータを両方のデータストアにリアルタイムで書き込むようにした後、移行計画の次のステップでは、Cassandra から Amazon Keyspaces にコピーまたは一括アップロードする必要がある履歴データの量を評価します。これにより、アプリケーションの移行前に、新しいデータと履歴データの両方を新しい Amazon Keyspaces データベースに用意できます。 データ保持の要件 (組織のポリシーに基づいて保管しておく必要がある履歴データの量など) に応じて、次の 2 つの選択肢のいずれかを検討できます。 + **履歴データの一括アップロード** – 既存の Cassandra デプロイから Amazon Keyspaces への履歴データの移行は、データの抽出、変換、ロード (ETL) に AWS Glueやカスタムスクリプトを使用するなど、さまざまな手法を通じて実現できます。AWS Glue を使用して履歴データをアップロードする方法については、「[オフライン移行プロセス: Apache Cassandra から Amazon Keyspaces への移行](migrating-offline.md)」を参照してください。 履歴データの一括アップロードを計画する場合は、まさにアップロード中のデータを新しい書き込みが更新しようとした場合に生じる競合を、どのように解決するのか考えておく必要があります。一括アップロードは、最終的な一貫性が担保されます。つまり、データは最終的にすべてのノードに行き届きます。 同じデータの更新作業が新しい書き込みによって同時に行われた場合、アップロードされた履歴データの方で上書きされないようにする必要があります。一括インポート中でもデータに最新の更新を確実に反映するには、一括アップロードのスクリプトかデュアル書き込みのアプリケーションロジックのいずれかに競合解決を織り込む必要があります。 例えば、[軽量トランザクション](functional-differences.md#functional-differences.light-transactions) (LWT) を使用してオペレーションを比較し、設定できます。そのためには、変更時間または状態を表すフィールドをデータモデルに追加します。 さらに、Amazon Keyspaces は Cassandra の `WRITETIME` タイムスタンプ関数をサポートしています。Amazon Keyspaces のクライアント側タイムスタンプを使用して、ソースデータベースのタイムスタンプを維持し、Last-Writer-Wins (最後の書き込みを優先) による競合解決を実装できます。詳細については、「[Amazon Keyspaces でのクライアント側のタイムスタンプ](client-side-timestamps.md)」を参照してください。 + **Time-to-Live (TTL) の使用** – データ保持期間が 30、60、または 90 日未満の場合、移行中に Cassandra および Amazon Keyspaces で TTL を使用して、不要な履歴データを Amazon Keyspaces にアップロードしないようにすることができます。TTL に指定した期間が経過したら、データが自動的にデータベースから削除されます。 移行フェーズでは、履歴データを Amazon Keyspaces にコピーする代わりに、TTL を設定して履歴データを古いシステム (Cassandra) で自動的に期限切れにし、デュアル書き込み手法を用いて新しい書き込みのみを Amazon Keyspaces に適用することができます。時間が経つにつれて、Cassandra クラスターで古いデータが順次期限切れになり、デュアル書き込み手法で新しいデータが書き込まれていき、自ずと Amazon Keyspaces が追いつき、Cassandra と同じデータが揃います。 このアプローチなら、移行対象のデータ量を大幅に削減して、より効率的、合理的に移行プロセスを進めることができます。データ保持の要件がさまざまに異なる大規模なデータセットを処理する場合は、このアプローチを検討できます。TTL の詳細については、「[Amazon Keyspaces (Apache Cassandra 向け) で有効期限 (TTL) を使用してデータを期限切れにする](TTL.md)」を参照してください。 TTL によるデータの有効期限を利用して、Cassandra から Amazon Keyspaces に移行する次の例を検討してみましょう。この例では、両方のデータベースの TTL を 60 日間に設定し、90 日の期間にわたって移行プロセスがどのように進行するかを見ていきます。両方のデータベースにはこの期間中、デュアル書き込み手法で新しいデータが書き込まれます。移行を 30 日間ずつの各フェーズに分けて検討します。 各フェーズで移行がどのように進むかを次の図にまとめています。 ![\[Apache Cassandra から Amazon Keyspaces への移行時に TTL を使用して履歴データを期限切れにします。\]](http://docs.aws.amazon.com/ja_jp/keyspaces/latest/devguide/images/migration/online-migration-TTL.png) 1. 最初の 30 日が過ぎた時点で、Cassandra クラスターと Amazon Keyspaces は新しい書き込みを受信しています。Cassandra クラスターには、60 日間の保持期間がまだ過ぎていない履歴データも含まれていて、これがクラスター内のデータの 50% を占めています。 60 日以上経ったデータは、TTL を使用して Cassandra クラスターから自動的に削除されます。この時点で、Amazon Keyspaces には Cassandra クラスターに保存されているデータの 50% が含まれており、これは新しい書き込みから履歴データを除いた分です。 1. 60 日後、Cassandra クラスターと Amazon Keyspaces の両方に、過去 60 日間に書き込まれた同じデータが揃います。 1. 90 日経過するまでの間に、Cassandra と Amazon Keyspaces の両方に同じデータが揃い、同じ速さでデータが期限切れになります。 この例で、TTL を使用して有効期限を 60 日に設定し、履歴データのアップロードを回避する方法がわかりました。