Buat rencana migrasi untuk migrasi dari Apache Cassandra ke Amazon Keyspaces - Amazon Keyspaces (untuk Apache Cassandra)

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Buat rencana migrasi untuk migrasi dari Apache Cassandra ke Amazon Keyspaces

Agar migrasi berhasil dari Apache Cassandra ke Amazon Keyspaces, kami merekomendasikan peninjauan konsep migrasi yang berlaku dan praktik terbaik serta perbandingan opsi yang tersedia.

Topik ini menguraikan cara kerja proses migrasi dengan memperkenalkan beberapa konsep kunci dan alat serta teknik yang tersedia untuk Anda. Anda dapat mengevaluasi berbagai strategi migrasi untuk memilih salah satu yang paling sesuai dengan kebutuhan Anda.

Kompatibilitas fungsional

Pertimbangkan perbedaan fungsional antara Apache Cassandra dan Amazon Keyspaces dengan hati-hati sebelum migrasi. Amazon Keyspaces mendukung semua operasi bidang data Cassandra yang umum digunakan, seperti membuat ruang kunci dan tabel, membaca data, dan menulis data.

Namun ada beberapa Cassandra yang tidak APIs didukung Amazon Keyspaces. Untuk informasi selengkapnya tentang dukunganAPIs, lihatAPI Cassandra yang didukung, operasi, fungsi, dan tipe data. Untuk gambaran umum tentang semua perbedaan fungsional antara Amazon Keyspaces dan Apache Cassandra, lihat. Perbedaan fungsional: Amazon Keyspaces vs Apache Cassandra

Untuk membandingkan Cassandra APIs dan skema yang Anda gunakan dengan fungsionalitas yang didukung di Amazon Keyspaces, Anda dapat menjalankan skrip kompatibilitas yang tersedia di toolkit Amazon Keyspaces. GitHub

Cara menggunakan skrip kompatibilitas
  1. Unduh skrip Python kompatibilitas dari GitHubdan pindahkan ke lokasi yang memiliki akses ke cluster Apache Cassandra Anda yang ada.

  2. Skrip kompatibilitas menggunakan parameter yang sama sepertiCQLSH. Untuk --host dan --port masukkan alamat IP dan port yang Anda gunakan untuk menghubungkan dan menjalankan kueri ke salah satu node Cassandra di cluster Anda.

    Jika cluster Cassandra Anda menggunakan otentikasi, Anda juga perlu menyediakan dan. -username -password Untuk menjalankan skrip kompatibilitas, Anda dapat menggunakan perintah berikut.

    python toolkit-compat-tool.py --host hostname or IP -u "username" -p "password" --port native transport port

Perkirakan harga Amazon Keyspaces

Bagian ini memberikan gambaran umum tentang informasi yang perlu Anda kumpulkan dari tabel Apache Cassandra Anda untuk menghitung perkiraan biaya Amazon Keyspaces. Setiap tabel Anda memerlukan tipe data yang berbeda, perlu mendukung CQL kueri yang berbeda, dan mempertahankan lalu lintas baca/tulis yang khas.

Memikirkan kebutuhan Anda berdasarkan tabel sejalan dengan isolasi sumber daya tingkat tabel Amazon Keyspaces dan mode kapasitas throughput baca/tulis. Dengan Amazon Keyspaces, Anda dapat menentukan kapasitas baca/tulis dan kebijakan penskalaan otomatis untuk tabel secara independen.

Memahami persyaratan tabel membantu Anda memprioritaskan tabel untuk migrasi berdasarkan fungsionalitas, biaya, dan upaya migrasi.

Kumpulkan metrik tabel Cassandra berikut sebelum migrasi. Informasi ini membantu memperkirakan biaya beban kerja Anda di Amazon Keyspaces.

  • Nama tabel - Nama ruang kunci dan nama tabel yang sepenuhnya memenuhi syarat.

  • Deskripsi — Deskripsi tabel, misalnya bagaimana itu digunakan, atau jenis data apa yang disimpan di dalamnya.

  • Pembacaan rata-rata per detik — Jumlah rata-rata pembacaan tingkat koordinat terhadap tabel selama interval waktu yang besar.

  • Rata-rata menulis per detik — Jumlah rata-rata tingkat koordinat menulis terhadap tabel selama interval waktu yang besar.

  • Ukuran baris rata-rata dalam byte - Ukuran baris rata-rata dalam byte.

  • Ukuran penyimpanan di GBs — Ukuran penyimpanan mentah untuk sebuah meja.

  • Rincian konsistensi baca — Persentase pembacaan yang menggunakan konsistensi akhirnya (LOCAL_ONEatauONE) vs. konsistensi kuat (LOCAL_QUORUM).

Tabel ini menunjukkan contoh informasi tentang tabel yang perlu Anda kumpulkan saat merencanakan migrasi.

Nama tabel Deskripsi Rata-rata membaca per detik Rata-rata menulis per detik Ukuran baris rata-rata dalam byte Ukuran penyimpanan di GBs Baca rincian konsistensi

mykeyspace.mytable

Digunakan untuk menyimpan sejarah keranjang belanja

10.000

5.000

2.200

2.000

100% LOCAL_ONE

mykeyspace.mytable2

Digunakan untuk menyimpan informasi profil terbaru

20.000

1.000

850

1.000

25% LOCAL_QUORUM 75% LOCAL_ONE

Cara mengumpulkan metrik tabel

Bagian ini memberikan petunjuk langkah demi langkah tentang cara mengumpulkan metrik tabel yang diperlukan dari cluster Cassandra Anda yang ada. Metrik ini mencakup ukuran baris, ukuran tabel, dan permintaan baca/tulis per detik (). RPS Mereka memungkinkan Anda menilai persyaratan kapasitas throughput untuk tabel Amazon Keyspaces dan memperkirakan harga.

Cara mengumpulkan metrik tabel di tabel sumber Cassandra
  1. Tentukan ukuran baris

    Ukuran baris penting untuk menentukan kapasitas baca dan pemanfaatan kapasitas tulis di Amazon Keyspaces. Diagram berikut menunjukkan distribusi data tipikal pada rentang token Cassandra.

    Diagram yang menunjukkan distribusi data tipikal pada rentang token Cassandra menggunakan partisi. murmur3

    Anda dapat menggunakan skrip sampler ukuran baris yang tersedia GitHubuntuk mengumpulkan metrik ukuran baris untuk setiap tabel di cluster Cassandra Anda.

    Skrip mengekspor data tabel dari Apache Cassandra dengan menggunakan cqlsh dan awk menghitung min, maks, rata-rata, dan standar deviasi ukuran baris atas kumpulan sampel data tabel yang dapat dikonfigurasi. Sampler ukuran baris meneruskan argumen kecqlsh, sehingga parameter yang sama dapat digunakan untuk menghubungkan dan membaca dari cluster Cassandra Anda.

    Pernyataan berikut adalah contohnya.

    ./row-size-sampler.sh 10.22.33.44 9142 \\ -u "username" -p "password" --ssl

    Untuk informasi selengkapnya tentang cara menghitung ukuran baris di Amazon Keyspaces, lihat. Perkirakan ukuran baris di Amazon Keyspaces

  2. Tentukan ukuran tabel

    Dengan Amazon Keyspaces, Anda tidak perlu menyediakan penyimpanan terlebih dahulu. Amazon Keyspaces memantau ukuran tabel yang dapat ditagih secara terus menerus untuk menentukan biaya penyimpanan Anda. Penyimpanan ditagih per GB-bulan. Ukuran tabel Amazon Keyspaces didasarkan pada ukuran mentah (tidak terkompresi) dari satu replika.

    Untuk memantau ukuran tabel di Amazon Keyspaces, Anda dapat menggunakan metrikBillableTableSizeInBytes, yang ditampilkan untuk setiap tabel di AWS Management Console.

    Untuk memperkirakan ukuran tabel Amazon Keyspaces yang dapat ditagih, Anda dapat menggunakan salah satu dari dua metode ini:

    • Gunakan ukuran baris rata-rata dan kalikan dengan angka atau baris.

      Anda dapat memperkirakan ukuran tabel Amazon Keyspaces dengan mengalikan ukuran baris rata-rata dengan jumlah baris dari tabel sumber Cassandra Anda. Gunakan skrip sampel ukuran baris dari bagian sebelumnya untuk menangkap ukuran baris rata-rata. Untuk menangkap jumlah baris, Anda dapat menggunakan alat seperti dsbulk count untuk menentukan jumlah total baris di tabel sumber Anda.

    • Gunakan metadata tabel nodetool untuk mengumpulkan.

      Nodetooladalah alat administrasi yang disediakan dalam distribusi Apache Cassandra yang memberikan wawasan tentang keadaan proses Cassandra dan mengembalikan metadata tabel. Anda dapat menggunakan nodetool metadata sampel tentang ukuran tabel dan dengan itu mengekstrapolasi ukuran tabel di Amazon Keyspaces.

      Perintah yang digunakan adalahnodetool tablestats. Tablestats mengembalikan ukuran tabel dan rasio kompresi. Ukuran tabel disimpan sebagai tablelivespace untuk tabel dan Anda dapat membaginya dengancompression ratio. Kemudian gandakan nilai ukuran ini dengan jumlah node. Akhirnya bagi dengan faktor replikasi (biasanya tiga).

      Ini adalah rumus lengkap untuk perhitungan yang dapat Anda gunakan untuk menilai ukuran tabel.

      ((tablelivespace / compression ratio) * (total number of nodes))/ (replication factor)

      Mari kita asumsikan bahwa cluster Cassandra Anda memiliki 12 node. Menjalankan nodetool tablestats perintah mengembalikan 200 GB dan compression ratio 0,5. tablelivespace Ruang kunci memiliki faktor replikasi tiga.

      Seperti inilah perhitungan untuk contoh ini.

      (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
  3. Menangkap jumlah membaca dan menulis

    Untuk menentukan persyaratan kapasitas dan penskalaan untuk tabel Amazon Keyspaces Anda, tangkap tingkat permintaan baca dan tulis tabel Cassandra Anda sebelum migrasi.

    Amazon Keyspaces tanpa server dan Anda hanya membayar untuk apa yang Anda gunakan. Secara umum, harga throughput baca/tulis di Amazon Keyspaces didasarkan pada jumlah dan ukuran permintaan.

    Ada dua mode kapasitas di Amazon Keyspaces:

    • On-demand — Ini adalah opsi penagihan fleksibel yang mampu melayani ribuan permintaan per detik tanpa perlu perencanaan kapasitas. Ini menawarkan pay-per-request harga untuk permintaan baca dan tulis sehingga Anda hanya membayar untuk apa yang Anda gunakan.

    • Disediakan — Jika Anda memilih mode kapasitas throughput yang disediakan, Anda menentukan jumlah pembacaan dan penulisan per detik yang diperlukan untuk aplikasi Anda. Ini membantu Anda mengelola penggunaan Amazon Keyspaces agar tetap pada atau di bawah tingkat permintaan yang ditentukan untuk mengoptimalkan harga dan mempertahankan prediktabilitas.

      Mode yang disediakan menawarkan penskalaan otomatis untuk secara otomatis menyesuaikan tarif yang disediakan untuk meningkatkan atau menurunkan skala guna meningkatkan efisiensi operasional. Untuk informasi selengkapnya tentang manajemen sumber daya tanpa server, lihat. Mengelola sumber daya tanpa server di Amazon Keyspaces (untuk Apache Cassandra)

    Karena Anda menyediakan kapasitas throughput baca dan tulis di Amazon Keyspaces secara terpisah, Anda perlu mengukur tingkat permintaan untuk membaca dan menulis di tabel yang ada secara independen.

    Untuk mengumpulkan metrik pemanfaatan paling akurat dari cluster Cassandra yang ada, tangkap permintaan rata-rata per detik (RPS) untuk operasi baca dan tulis tingkat koordinator selama periode waktu yang lama untuk tabel yang dikumpulkan di semua node dalam satu pusat data.

    Menangkap rata-rata RPS selama setidaknya beberapa minggu menangkap puncak dan lembah dalam pola lalu lintas Anda, seperti yang ditunjukkan pada diagram berikut.

    Diagram yang menunjukkan tingkat rata-rata permintaan per detik per hari selama dua minggu.

    Anda memiliki dua opsi untuk menentukan tingkat permintaan baca dan tulis dari tabel Cassandra Anda.

    • Gunakan pemantauan Cassandra yang ada

      Anda dapat menggunakan metrik yang ditampilkan dalam tabel berikut untuk mengamati permintaan baca dan tulis. Perhatikan bahwa nama metrik dapat berubah berdasarkan alat pemantauan yang Anda gunakan.

      Dimensi Metrik Cassandra JMX

      Menulis

      org.apache.cassandra.metrics:type=ClientRequest, scope=Write,name=Latency#Count

      Membaca

      org.apache.cassandra.metrics:type=ClientRequest, scope=Read,name=Latency#Count

    • Gunakan nodetool

      Gunakan nodetool tablestats dan nodetool info untuk menangkap rata-rata operasi baca dan tulis dari tabel. tablestatsmengembalikan total jumlah baca dan tulis dari waktu node telah dimulai. nodetool infomenyediakan up-time untuk node dalam hitungan detik.

      Untuk menerima rata-rata per detik membaca dan menulis, bagilah jumlah baca dan tulis dengan waktu aktif node dalam hitungan detik. Kemudian, untuk pembacaan Anda membagi dengan iklan tingkat konsistensi untuk penulisan yang Anda bagi dengan faktor replikasi. Perhitungan ini dinyatakan dalam rumus berikut.

      Rumus untuk pembacaan rata-rata per detik:

      ((number of reads * number of nodes in cluster) / read consistency quorum (2)) / uptime

      Rumus untuk penulisan rata-rata per detik:

      ((number of writes * number of nodes in cluster) / replication factor of 3) / uptime

      Mari kita asumsikan kita memiliki 12 node cluster yang telah naik selama 4 minggu. nodetool infomengembalikan 2.419.200 detik up-time dan nodetool tablestats mengembalikan 1 miliar penulisan dan 2 miliar pembacaan. Contoh ini akan menghasilkan perhitungan berikut.

      ((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
  4. Tentukan pemanfaatan kapasitas tabel

    Untuk memperkirakan pemanfaatan kapasitas rata-rata, mulailah dengan tingkat permintaan rata-rata dan ukuran baris rata-rata tabel sumber Cassandra Anda.

    Amazon Keyspaces menggunakan read capacity units (RCUs) dan write capacity units (WCUs) untuk mengukur kapasitas throughput yang disediakan untuk membaca dan menulis untuk tabel. Untuk perkiraan ini, kami menggunakan unit ini untuk menghitung kebutuhan kapasitas baca dan tulis dari tabel Amazon Keyspaces baru setelah migrasi.

    Nanti dalam topik ini kita akan membahas bagaimana pilihan antara mode kapasitas yang disediakan dan sesuai permintaan memengaruhi penagihan. Tetapi untuk perkiraan pemanfaatan kapasitas dalam contoh ini, kami berasumsi bahwa tabel dalam mode yang disediakan.

    • Membaca — Satu RCU mewakili satu permintaan LOCAL_QUORUM LOCAL_ONE baca, atau dua permintaan baca, untuk satu baris hingga 4 KB. Jika Anda perlu membaca baris yang lebih besar dari 4 KB, operasi baca menggunakan tambahanRCUs. Jumlah total yang RCUs dibutuhkan tergantung pada ukuran baris, dan apakah Anda ingin menggunakan LOCAL_QUORUM atau LOCAL_ONE membaca konsistensi.

      Misalnya, membaca baris 8 KB membutuhkan 2 RCUs menggunakan konsistensi LOCAL_QUORUM baca, dan 1 RCU jika Anda memilih konsistensi LOCAL_ONE baca.

    • Menulis — Satu WCU mewakili satu tulis untuk satu baris dengan ukuran hingga 1 KB. Semua penulisan menggunakan LOCAL_QUORUM konsistensi, dan tidak ada biaya tambahan untuk menggunakan transaksi ringan (LWTs).

      Jumlah total yang WCUs dibutuhkan tergantung pada ukuran baris. Jika Anda perlu menulis baris yang lebih besar dari 1 KB, operasi tulis menggunakan tambahanWCUs. Misalnya, jika ukuran baris Anda adalah 2 KB, Anda memerlukan 2 WCUs untuk melakukan satu permintaan tulis.

    Rumus berikut dapat digunakan untuk memperkirakan yang dibutuhkan RCUs danWCUs.

    • Kapasitas baca RCUs dapat ditentukan dengan mengalikan pembacaan per detik dengan jumlah baris yang dibaca per bacaan dikalikan dengan ukuran baris rata-rata dibagi 4KB dan dibulatkan ke atas ke bilangan bulat terdekat.

    • Kapasitas tulis dalam WCUs dapat ditentukan dengan mengalikan jumlah permintaan dengan ukuran baris rata-rata dibagi dengan 1KB dan dibulatkan ke bilangan bulat terdekat.

    Ini dinyatakan dalam rumus berikut.

    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

    Misalnya, jika Anda melakukan 4.960 permintaan baca dengan ukuran baris 2,5KB di tabel Cassandra Anda, Anda memerlukan 4.960 di Amazon Keyspaces. RCUs Jika saat ini Anda melakukan 1.653 permintaan tulis per detik dengan ukuran baris 2,5KB di tabel Cassandra Anda, Anda memerlukan 4.959 per detik di Amazon Keyspaces. WCUs

    Contoh ini dinyatakan dalam rumus berikut.

    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

    Menggunakan eventual consistency memungkinkan Anda menghemat hingga setengah dari kapasitas throughput pada setiap permintaan baca. Setiap pembacaan yang konsisten pada akhirnya dapat mengkonsumsi hingga 8KB. Anda dapat menghitung pembacaan konsisten akhirnya dengan mengalikan perhitungan sebelumnya dengan 0,5 seperti yang ditunjukkan pada rumus berikut.

    4,960 read requests per second * ROUNDUP( 2.5KB /4KB per unit) * .5 = 2,480 read request per second * 1 RCU = 2,480 RCUs
  5. Hitung estimasi harga bulanan untuk Amazon Keyspaces

    Untuk memperkirakan penagihan bulanan untuk tabel berdasarkan throughput kapasitas baca/tulis, Anda dapat menghitung harga untuk mode sesuai permintaan dan untuk penyediaan menggunakan rumus yang berbeda dan membandingkan opsi untuk tabel Anda.

    Mode yang disediakan - Konsumsi kapasitas baca dan tulis ditagih pada tarif per jam berdasarkan unit kapasitas per detik. Pertama, bagi tingkat itu dengan 0,7 untuk mewakili pemanfaatan target autoscaling default sebesar 70%. Kemudian beberapa kali dengan 30 hari kalender, 24 jam per hari, dan harga tarif regional.

    Perhitungan ini dirangkum dalam rumus berikut.

    (read capacity per second / .7) * 24 hours * 30 days * regional rate (write capacity per second / .7) * 24 hours * 30 days * regional rate

    Mode sesuai permintaan - Kapasitas baca dan tulis ditagih berdasarkan tarif per permintaan. Pertama, kalikan tingkat permintaan dengan 30 hari kalender, dan 24 jam per hari. Kemudian bagi dengan satu juta unit permintaan. Akhirnya, kalikan dengan tarif regional.

    Perhitungan ini dirangkum dalam rumus berikut.

    ((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

Pilih strategi migrasi

Anda dapat memilih di antara strategi migrasi berikut saat bermigrasi dari Apache Cassandra ke Amazon Keyspaces:

  • Online — Ini adalah migrasi langsung menggunakan penulisan ganda untuk mulai menulis data baru ke Amazon Keyspaces dan cluster Cassandra secara bersamaan. Jenis migrasi ini direkomendasikan untuk aplikasi yang tidak memerlukan waktu henti selama migrasi dan konsistensi baca setelah penulisan.

    Untuk informasi selengkapnya tentang cara merencanakan dan menerapkan strategi migrasi online, lihatMigrasi online ke Amazon Keyspaces: strategi dan praktik terbaik.

  • Offline — Teknik migrasi ini melibatkan penyalinan kumpulan data dari Cassandra ke Amazon Keyspaces selama jendela downtime. Migrasi offline dapat menyederhanakan proses migrasi, karena tidak memerlukan perubahan pada aplikasi Anda atau resolusi konflik antara data historis dan penulisan baru.

    Untuk informasi selengkapnya tentang cara merencanakan migrasi offline, lihatProses migrasi offline: Apache Cassandra ke Amazon Keyspaces.

  • Hybrid — Teknik migrasi ini memungkinkan perubahan direplikasi ke Amazon Keyspaces dalam waktu dekat, tetapi tanpa konsistensi baca demi tulis.

Setelah meninjau teknik migrasi dan praktik terbaik yang dibahas dalam topik ini, Anda dapat menempatkan opsi yang tersedia di pohon keputusan untuk merancang strategi migrasi berdasarkan kebutuhan dan sumber daya yang tersedia.