Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Mengunggah data historis selama migrasi online
Setelah menerapkan penulisan ganda untuk memastikan bahwa data baru ditulis ke kedua penyimpanan data secara real time, langkah selanjutnya dalam rencana migrasi adalah mengevaluasi berapa banyak data historis yang perlu Anda salin atau unggah massal dari Cassandra ke Amazon Keyspaces. Ini memastikan bahwa data baru dan data historis akan tersedia di database Amazon Keyspaces baru sebelum Anda memigrasikan aplikasi.
Bergantung pada persyaratan penyimpanan data Anda, misalnya berapa banyak data historis yang perlu Anda pertahankan berdasarkan kebijakan organisasi Anda, Anda dapat mempertimbangkan salah satu dari dua opsi berikut.
Pengunggahan massal data historis — Migrasi data historis dari penyebaran Cassandra Anda yang ada ke Amazon Keyspaces dapat dicapai melalui berbagai teknik, misalnya menggunakan AWS Glue atau skrip khusus untuk mengekstrak, mengubah, dan memuat (ETL) data. Untuk informasi selengkapnya tentang penggunaan AWS Glue untuk mengunggah data historis, lihatProses migrasi offline: Apache Cassandra ke Amazon Keyspaces.
Saat merencanakan unggahan massal data historis, Anda perlu mempertimbangkan cara menyelesaikan konflik yang dapat terjadi ketika penulisan baru mencoba memperbarui data yang sama yang sedang dalam proses diunggah. Upload massal diharapkan pada akhirnya konsisten, yang berarti data akan mencapai semua node pada akhirnya.
Jika pembaruan data yang sama terjadi pada saat yang sama karena penulisan baru, Anda ingin memastikan bahwa itu tidak akan ditimpa oleh unggahan data historis. Untuk memastikan bahwa Anda mempertahankan pembaruan terbaru pada data Anda bahkan selama impor massal, Anda harus menambahkan resolusi konflik baik ke dalam skrip unggahan massal atau ke dalam logika aplikasi untuk penulisan ganda.
Misalnya, Anda dapat menggunakan Transaksi ringan (LWT) untuk membandingkan dan mengatur operasi. Untuk melakukan ini, Anda dapat menambahkan bidang tambahan ke model data Anda yang mewakili waktu modifikasi atau status.
Selain itu, Amazon Keyspaces mendukung fungsi stempel waktu Cassandra
WRITETIME. Anda dapat menggunakan stempel waktu sisi klien Amazon Keyspaces untuk mempertahankan stempel waktu database sumber dan menerapkan resolusi konflik. last-writer-wins Untuk informasi selengkapnya, lihat Stempel waktu sisi klien di Amazon Keyspaces.Menggunakan Time-to-Live (TTL) — Untuk periode retensi data yang lebih pendek dari 30, 60, atau 90 hari, Anda dapat menggunakan TTL di Cassandra dan Amazon Keyspaces selama migrasi untuk menghindari mengunggah data historis yang tidak perlu ke Amazon Keyspaces. TTL memungkinkan Anda untuk mengatur periode waktu setelah data dihapus secara otomatis dari database.
Selama fase migrasi, alih-alih menyalin data historis ke Amazon Keyspaces, Anda dapat mengonfigurasi pengaturan TTL agar data historis kedaluwarsa secara otomatis di sistem lama (Cassandra) sambil hanya menerapkan penulisan baru ke Amazon Keyspaces menggunakan metode penulisan ganda. Seiring waktu dan dengan data lama yang terus kedaluwarsa di cluster Cassandra dan data baru yang ditulis menggunakan metode dual-write, Amazon Keyspaces secara otomatis menangkap data yang sama dengan Cassandra.
Pendekatan ini dapat secara signifikan mengurangi jumlah data yang akan dimigrasi, menghasilkan proses migrasi yang lebih efisien dan efisien. Anda dapat mempertimbangkan pendekatan ini ketika berhadapan dengan kumpulan data besar dengan berbagai persyaratan retensi data. Untuk informasi lebih lanjut tentang TTL, lihatData kedaluwarsa dengan Time to Live (TTL) untuk Amazon Keyspaces (untuk Apache Cassandra).
Pertimbangkan contoh migrasi dari Cassandra ke Amazon Keyspaces berikut menggunakan kedaluwarsa data TTL. Dalam contoh ini kami menetapkan TTL untuk kedua database ke 60 hari dan menunjukkan bagaimana proses migrasi berlangsung selama periode 90 hari. Kedua database menerima data yang baru ditulis yang sama selama periode ini menggunakan metode penulisan ganda. Kita akan melihat tiga fase migrasi yang berbeda, setiap fase adalah 30 hari.
Cara kerja proses migrasi untuk setiap fase ditunjukkan pada gambar berikut.
Setelah 30 hari pertama, cluster Cassandra dan Amazon Keyspaces telah menerima penulisan baru. Cluster Cassandra juga berisi data historis yang belum mencapai retensi 60 hari, yang merupakan 50% dari data dalam cluster.
Data yang lebih tua dari 60 hari secara otomatis dihapus di cluster Cassandra menggunakan TTL. Pada titik ini Amazon Keyspaces berisi 50% data yang disimpan di cluster Cassandra, yang terdiri dari penulisan baru dikurangi data historis.
Setelah 60 hari, cluster Cassandra dan Amazon Keyspaces berisi data yang sama yang ditulis dalam 60 hari terakhir.
Dalam 90 hari, Cassandra dan Amazon Keyspaces berisi data yang sama dan data kedaluwarsa dengan kecepatan yang sama.
Contoh ini menggambarkan cara menghindari langkah mengunggah data historis dengan menggunakan TTL dengan tanggal kedaluwarsa yang ditetapkan ke 60 hari.
