Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Bermigrasi ke Amazon Keyspaces (untuk Apache Cassandra)
Migrasi ke Amazon Keyspaces (untuk Apache Cassandra) menghadirkan berbagai manfaat menarik bagi bisnis dan organisasi. Berikut adalah beberapa keuntungan utama yang menjadikan Amazon Keyspaces pilihan yang menarik untuk migrasi.
+ **Skalabilitas** — Amazon Keyspaces dirancang untuk menangani beban kerja yang besar dan menskalakan dengan mulus untuk mengakomodasi volume dan lalu lintas data yang terus bertambah. Dengan Cassandra tradisional, penskalaan tidak dilakukan sesuai permintaan dan membutuhkan perencanaan untuk puncak masa depan. Dengan Amazon Keyspaces, Anda dapat dengan mudah meningkatkan atau menurunkan tabel berdasarkan permintaan, memastikan bahwa aplikasi Anda dapat menangani lonjakan lalu lintas yang tiba-tiba tanpa mengorbankan kinerja.
+ **Kinerja** - Amazon Keyspaces menawarkan akses data latensi rendah, memungkinkan aplikasi untuk mengambil dan memproses data dengan kecepatan luar biasa. Arsitektur terdistribusinya memastikan operasi baca dan tulis didistribusikan di beberapa simpul sehingga memberikan waktu respons milidetik satu digit yang konsisten bahkan pada tingkat permintaan tinggi.
+ **Dikelola sepenuhnya** - Amazon Keyspaces adalah layanan yang dikelola sepenuhnya yang disediakan oleh. AWS Ini berarti AWS menangani aspek operasional manajemen basis data, termasuk penyediaan, konfigurasi, penambalan, pencadangan, dan penskalaan. Ini memungkinkan Anda untuk lebih fokus pada pengembangan aplikasi dan tidak terlalu fokus pada tugas administrasi basis data.
+ **Arsitektur tanpa server** - Amazon Keyspaces tanpa server. Anda hanya membayar untuk kapasitas yang dikonsumsi tanpa memerlukan penyediaan kapasitas di muka. Anda tidak memiliki server untuk dikelola atau instance untuk dipilih. pay-per-requestModel ini menawarkan efisiensi biaya dan overhead operasional minimal, karena Anda hanya membayar sumber daya yang Anda konsumsi tanpa perlu menyediakan dan memantau kapasitas.
+ **Fleksibilitas NoSQL dengan skema -** Amazon Keyspaces mengikuti model data NoSQL, memberikan fleksibilitas dalam desain skema. Dengan Amazon Keyspaces, Anda dapat menyimpan data terstruktur, semi-terstruktur, dan tidak terstruktur, sehingga cocok untuk menangani beragam tipe data yang berkembang. Selain itu, Amazon Keyspaces melakukan validasi skema pada penulisan yang memungkinkan evolusi terpusat dari model data. Fleksibilitas ini memungkinkan siklus pengembangan yang lebih cepat dan adaptasi yang lebih mudah terhadap perubahan kebutuhan bisnis.
+ **Ketersediaan dan daya tahan tinggi** — Amazon Keyspaces mereplikasi data di beberapa [Availability Zone](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/) dalam satu Wilayah AWS, memastikan ketersediaan tinggi dan daya tahan data. Replikasi, failover, dan pemulihan direplikasi secara otomatis, sehingga meminimalkan risiko kehilangan data atau gangguan layanan. Amazon Keyspaces menyediakan ketersediaan SLA hingga 99,999%. [Untuk ketahanan yang lebih tinggi dan pembacaan lokal latensi rendah, Amazon Keyspaces menawarkan replikasi Multi-wilayah.](multiRegion-replication.md)
+ **Keamanan dan kepatuhan** — Amazon Keyspaces terintegrasi dengan AWS Identity and Access Management kontrol akses berbutir halus. Ini menyediakan enkripsi saat istirahat dan dalam perjalanan, membantu meningkatkan keamanan data Anda. Amazon Keyspaces telah dinilai oleh auditor pihak ketiga untuk keamanan dan kepatuhan terhadap program tertentu, termasuk HIPAA, PCI DSS, dan SOC, yang memungkinkan Anda memenuhi persyaratan peraturan. Untuk informasi selengkapnya, lihat [Validasi kepatuhan untuk Amazon Keyspaces (untuk Apache Cassandra)](Keyspaces-compliance.md).
+ **Integrasi dengan AWS Ekosistem** — Sebagai bagian dari AWS ekosistem, Amazon Keyspaces terintegrasi dengan mulus dengan yang lain Layanan AWS, misalnya, AWS CloudFormation Amazon, dan. CloudWatch AWS CloudTrail Integrasi ini memungkinkan Anda membangun arsitektur nirserver, memanfaatkan infrastruktur sebagai kode, dan membuat aplikasi berbasis data waktu nyata. Lihat informasi yang lebih lengkap di [Memantau Amazon Keyspaces (untuk Apache Cassandra)](monitoring-overview.md).
**Topics**
+ [Buat rencana migrasi untuk migrasi dari Apache Cassandra ke Amazon Keyspaces](migrating-cassandra.md)
+ [Cara memilih alat yang tepat untuk mengunggah massal atau memigrasi data ke Amazon Keyspaces](migrating-tools.md)
# 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.
**Topics**
+ [Kompatibilitas fungsional](#migrating-cassandra-compatibility)
+ [Perkirakan harga Amazon Keyspaces](#migrating-cassandra-sizing)
+ [Pilih strategi migrasi](#migrating-cassandra-strategy)
+ [Migrasi online ke Amazon Keyspaces: strategi dan praktik terbaik](migrating-online.md)
+ [Proses migrasi offline: Apache Cassandra ke Amazon Keyspaces](migrating-offline.md)
+ [Menggunakan solusi migrasi hibrida: Apache Cassandra ke Amazon Keyspaces](migrating-hybrid.md)
## 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 dukungan APIs, lihat[Cassandra APIs, operasi, fungsi, dan tipe data yang didukung](cassandra-apis.md). Untuk gambaran umum tentang semua perbedaan fungsional antara Amazon Keyspaces dan Apache Cassandra, lihat. [Perbedaan fungsional: Amazon Keyspaces vs Apache Cassandra](functional-differences.md)
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](https://github.com/aws-samples/amazon-keyspaces-toolkit/blob/master/bin/toolkit-compat-tool.py)
**Cara menggunakan skrip kompatibilitas**
1. Unduh skrip Python kompatibilitas dari [GitHub](https://github.com/aws-samples/amazon-keyspaces-toolkit/blob/master/bin/toolkit-compat-tool.py)dan pindahkan ke lokasi yang memiliki akses ke cluster Apache Cassandra Anda yang ada.
1. Skrip kompatibilitas menggunakan parameter yang sama seperti`CQLSH`. 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 kueri CQL yang berbeda, dan mempertahankan lalu lintas yang berbeda. read/write
Memikirkan kebutuhan Anda berdasarkan tabel sejalan dengan isolasi sumber daya tingkat tabel Amazon Keyspaces [dan](ReadWriteCapacityMode.md) mode kapasitas throughput baca/tulis. Dengan Amazon Keyspaces, Anda dapat menentukan kapasitas baca/tulis dan kebijakan [penskalaan otomatis](autoscaling.md) 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_ONE`atau`ONE`) 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 read/write permintaan 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\]](http://docs.aws.amazon.com/id_id/keyspaces/latest/devguide/images/migration/migration-data-distribution.png)
Anda dapat menggunakan skrip sampler ukuran baris yang tersedia [GitHub](https://github.com/aws-samples/amazon-keyspaces-toolkit/blob/master/bin/row-size-sampler.sh)untuk 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 ke`cqlsh`, sehingga parameter yang sama dapat digunakan untuk menghubungkan dan membaca dari cluster Cassandra Anda.
Pernyataan berikut adalah contoh dari ini.
```
./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](calculating-row-size.md)
1. 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 metrik`BillableTableSizeInBytes`, yang ditampilkan untuk setiap tabel di. Konsol Manajemen AWS
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.
`Nodetool`adalah 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 harus digunakan adalah`nodetool tablestats`. Tablestats mengembalikan ukuran tabel dan rasio kompresi. Ukuran tabel disimpan sebagai `tablelivespace` untuk tabel dan Anda dapat membaginya dengan`compression 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
```
1. 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 read/write throughput di Amazon Keyspaces didasarkan pada jumlah dan ukuran permintaan.
Ada dua mode kapasitas di Amazon Keyspaces:
+ [On-demand](ReadWriteCapacityMode.OnDemand.md) — 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](ReadWriteCapacityMode.Provisioned.md) — 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 mempertahankan prediktabilitas.
Mode yang disediakan menawarkan [penskalaan otomatis](autoscaling.md) 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)](serverless_resource_management.md)
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 RPS rata-rata selama periode 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.\]](http://docs.aws.amazon.com/id_id/keyspaces/latest/devguide/images/migration/migration-rps.png)
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.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/keyspaces/latest/devguide/migrating-cassandra.html)
+ Gunakan `nodetool`
Gunakan `nodetool tablestats` dan `nodetool info` untuk menangkap rata-rata operasi baca dan tulis dari tabel. `tablestats`mengembalikan total jumlah baca dan tulis dari waktu node telah dimulai. `nodetool info`menyediakan 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 info`mengembalikan 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
```
1. 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` baca, atau dua permintaan `LOCAL_ONE` baca, untuk satu baris hingga 4 KB. Jika Anda perlu membaca baris yang lebih besar dari 4 KB, operasi baca menggunakan tambahan RCUs. 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 tambahan WCUs. 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 dan WCUs.
+ **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
```
1. Hitung estimasi harga bulanan untuk Amazon Keyspaces
Untuk memperkirakan penagihan bulanan untuk tabel berdasarkan throughput read/write kapasitas, Anda dapat menghitung harga untuk on-demand dan untuk mode yang disediakan menggunakan rumus yang berbeda dan membandingkan opsi untuk tabel Anda.
**Mode yang disediakan** - Konsumsi kapasitas baca dan tulis ditagih dengan 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, lihat[Migrasi online ke Amazon Keyspaces: strategi dan praktik terbaik](migrating-online.md).
+ **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, lihat[Proses migrasi offline: Apache Cassandra ke Amazon Keyspaces](migrating-offline.md).
+ **Hybrid** — Teknik migrasi ini memungkinkan perubahan direplikasi ke Amazon Keyspaces dalam waktu dekat, tetapi tanpa konsistensi baca demi tulis.
Untuk informasi selengkapnya tentang cara merencanakan migrasi hibrida, lihat[Menggunakan solusi migrasi hibrida: Apache Cassandra ke Amazon Keyspaces](migrating-hybrid.md).
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.
# Migrasi online ke Amazon Keyspaces: strategi dan praktik terbaik
Jika Anda perlu menjaga ketersediaan aplikasi selama migrasi dari Apache Cassandra ke Amazon Keyspaces, Anda dapat menyiapkan strategi migrasi online khusus dengan menerapkan komponen utama yang dibahas dalam topik ini. Dengan mengikuti praktik terbaik untuk migrasi online ini, Anda dapat memastikan bahwa ketersediaan dan read-after-write konsistensi aplikasi dipertahankan selama seluruh proses migrasi, meminimalkan dampak pada pengguna Anda.
Saat merancang strategi migrasi online dari Apache Cassandra ke Amazon Keyspaces, Anda perlu mempertimbangkan langkah-langkah kunci berikut.
1. **Menulis data baru**
+ **ZDM Dual Write Proxy untuk Migrasi Keyspaces Amazon — Gunakan ZDM Dual Write Proxy yang tersedia di [Github](https://github.com/aws-samples/amazon-keyspaces-examples/blob/main/migration/online/zdm-proxy/README.md) untuk melakukan migrasi** zero-downtime dari Apache Cassandra ke Amazon Keyspaces. Proxy ZDM melakukan penulisan ganda tanpa perlu memfaktorkan ulang aplikasi yang ada dan melakukan pembacaan ganda untuk validasi kueri.
+ Application dual-write: Anda dapat menerapkan penulisan ganda dalam aplikasi Anda menggunakan pustaka dan driver klien Cassandra yang ada. Tentukan satu database sebagai pemimpin dan yang lainnya sebagai pengikut. Kegagalan menulis ke database pengikut dicatat dalam [antrian huruf mati (DLQ](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html)) untuk analisis.
+ Tulis ganda tingkat pesan: Atau, Anda dapat mengonfigurasi platform perpesanan yang ada untuk mengirim tulisan ke Cassandra dan Amazon Keyspaces menggunakan konsumen tambahan. Ini pada akhirnya menciptakan tampilan yang konsisten di kedua database.
1. **Migrasi data historis**
+ Salin data historis: Anda dapat memigrasikan data historis dari Cassandra ke Amazon Keyspaces menggunakan AWS Glue atau kustom ekstrak, transformasi, dan muat (ETL) skrip. Menangani resolusi konflik antara penulisan ganda dan beban massal menggunakan teknik seperti transaksi ringan atau stempel waktu.
+ Gunakan Time-To-Live (TTL): Untuk periode retensi data yang lebih pendek, Anda dapat menggunakan TTL di Cassandra dan Amazon Keyspaces untuk menghindari mengunggah data historis yang tidak perlu. Karena data lama kedaluwarsa di Cassandra dan data baru ditulis melalui penulisan ganda, Amazon Keyspaces akhirnya menyusul.
1. **Memvalidasi data**
+ Pembacaan ganda: Menerapkan pembacaan ganda dari database Cassandra (primer) dan Amazon Keyspaces (sekunder), membandingkan hasil secara asinkron. Perbedaan dicatat atau dikirim ke DLQ.
+ Sampel dibaca: Gunakan fungsi Λ untuk mengambil sampel dan membandingkan data secara berkala di kedua sistem, mencatat perbedaan apa pun ke DLQ.
1. **Migrasi aplikasi**
+ Strategi biru-hijau: Alihkan aplikasi Anda untuk memperlakukan Amazon Keyspaces sebagai primer dan Cassandra sebagai penyimpanan data sekunder dalam satu langkah. Pantau kinerja dan putar kembali jika masalah muncul.
+ Penerapan Canary: Secara bertahap meluncurkan migrasi ke subset pengguna terlebih dahulu, secara bertahap meningkatkan lalu lintas ke Amazon Keyspaces sebagai primer hingga sepenuhnya dimigrasikan.
1. **Penonaktifan Cassandra**
Setelah aplikasi Anda sepenuhnya dimigrasikan ke Amazon Keyspaces dan konsistensi data divalidasi, Anda dapat merencanakan untuk menonaktifkan klaster Cassandra Anda berdasarkan kebijakan penyimpanan data.
Dengan merencanakan strategi migrasi online dengan komponen-komponen ini, Anda dapat bertransisi dengan lancar ke layanan Amazon Keyspaces yang dikelola sepenuhnya dengan waktu henti atau gangguan minimal. Bagian berikut masuk ke setiap komponen secara lebih rinci.
**Topics**
+ [Menulis data baru selama migrasi online](migration-online-dw.md)
+ [Mengunggah data historis selama migrasi online](migration-online-historical.md)
+ [Memvalidasi konsistensi data selama migrasi online](migration-online-validation.md)
+ [Migrasi aplikasi selama migrasi online](migration-online-app-migration.md)
+ [Menonaktifkan Cassandra setelah migrasi online](migration-online-decommission.md)
# Menulis data baru selama migrasi online
Langkah pertama dalam rencana migrasi online adalah memastikan bahwa setiap data baru yang ditulis oleh aplikasi disimpan di kedua database, cluster Cassandra yang ada, dan Amazon Keyspaces. Tujuannya adalah untuk memberikan pandangan yang konsisten di kedua penyimpanan data. Anda dapat melakukan ini dengan menerapkan semua penulisan baru ke kedua database. Untuk menerapkan penulisan ganda, pertimbangkan salah satu dari tiga opsi berikut.
+ **ZDM Dual Write Proxy untuk Migrasi Keyspaces Amazon** — Menggunakan Proxy ZDM untuk Amazon Keyspaces yang tersedia [di](https://github.com/aws-samples/amazon-keyspaces-examples/blob/main/migration/online/zdm-proxy/README.md) Github, Anda dapat memigrasikan beban kerja Apache Cassandra ke Amazon Keyspaces tanpa downtime aplikasi. Solusi yang disempurnakan ini menerapkan praktik AWS terbaik dan memperluas kemampuan Proxy ZDM resmi.
+ Lakukan migrasi online antara Apache Cassandra dan Amazon Keyspaces.
+ Tulis data ke tabel sumber dan target secara bersamaan tanpa aplikasi refactoring.
+ Validasi kueri melalui operasi dual-read.
Solusinya menawarkan penyempurnaan berikut untuk bekerja dengan dan AWS Amazon Keyspaces.
+ **Penyebaran kontainer** — Gunakan image Docker yang telah dikonfigurasi sebelumnya dari Amazon Elastic Container Registry (Amazon ECR) Registry (Amazon ECR) untuk penerapan yang dapat diakses VPC.
+ **Infrastruktur sebagai kode** - Terapkan menggunakan AWS CloudFormation templat untuk penyiapan otomatis aktif. AWS Fargate
+ **Kompatibilitas Amazon Keyspaces** — Akses tabel sistem dengan adaptasi khusus untuk Amazon Keyspaces.
Solusinya berjalan di Amazon ECS dengan Fargate, menyediakan skalabilitas tanpa server berdasarkan tuntutan beban kerja Anda. Penyeimbang beban jaringan mendistribusikan lalu lintas aplikasi yang masuk di beberapa tugas Amazon ECS untuk ketersediaan tinggi.
![\[Menerapkan proxy penulisan ganda ZDM untuk memigrasikan data dari Apache Cassandra ke Amazon Keyspaces.\]](http://docs.aws.amazon.com/id_id/keyspaces/latest/devguide/images/migration/online-migration-zdm.png)
+ **Application dual write** — Anda dapat menerapkan penulisan ganda dengan perubahan minimal pada kode aplikasi Anda dengan memanfaatkan pustaka dan driver klien Cassandra yang ada. Anda dapat menerapkan penulisan ganda dalam aplikasi yang ada, atau membuat layer baru dalam arsitektur untuk menangani penulisan ganda. Untuk informasi lebih lanjut dan studi kasus pelanggan yang menunjukkan bagaimana penulisan ganda diimplementasikan dalam aplikasi yang ada, lihat Studi [kasus migrasi Cassandra](https://aws.amazon.com/solutions/case-studies/intuit-apache-migration-case-study/).
Saat menerapkan penulisan ganda, Anda dapat menunjuk satu database sebagai pemimpin dan database lainnya sebagai pengikut. Ini memungkinkan Anda untuk terus menulis ke sumber asli Anda, atau database pemimpin tanpa membiarkan kegagalan menulis ke pengikut, atau database tujuan mengganggu jalur kritis aplikasi Anda.
Alih-alih mencoba menulis ulang gagal ke pengikut, Anda dapat menggunakan Amazon Simple Queue Service untuk merekam penulisan gagal dalam [antrian surat mati](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) (DLQ). DLQ memungkinkan Anda menganalisis penulisan yang gagal ke pengikut dan menentukan mengapa pemrosesan tidak berhasil dalam database tujuan.
Untuk implementasi penulisan ganda yang lebih canggih, Anda dapat mengikuti praktik AWS terbaik untuk merancang urutan transaksi lokal menggunakan [pola saga](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/saga.html). Pola saga memastikan bahwa jika transaksi gagal, saga menjalankan transaksi kompensasi untuk mengembalikan perubahan database yang dibuat oleh transaksi sebelumnya.
Saat menggunakan dual-write untuk migrasi online, Anda dapat mengonfigurasi penulisan ganda mengikuti pola saga sehingga setiap penulisan adalah transaksi lokal untuk memastikan operasi atom di seluruh database heterogen. Untuk informasi selengkapnya tentang merancang aplikasi terdistribusi menggunakan pola desain yang direkomendasikanAWS Cloud, lihat [Pola, arsitektur, dan implementasi desain Cloud](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/introduction).
![\[Menerapkan penulisan ganda di lapisan aplikasi saat bermigrasi dari Apache Cassandra ke Amazon Keyspaces.\]](http://docs.aws.amazon.com/id_id/keyspaces/latest/devguide/images/migration/online-migration-dual-writes.png)
+ **Messaging tier dual write** — Alih-alih menerapkan penulisan ganda di lapisan aplikasi, Anda dapat menggunakan tingkat perpesanan yang ada untuk melakukan penulisan ganda ke Cassandra dan Amazon Keyspaces.
Untuk melakukan ini, Anda dapat mengonfigurasi konsumen tambahan ke platform perpesanan Anda untuk mengirim tulisan ke kedua penyimpanan data. Pendekatan ini menyediakan strategi kode rendah sederhana menggunakan tingkat pesan untuk membuat dua tampilan di kedua database yang pada akhirnya konsisten.
# 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, lihat[Proses migrasi offline: Apache Cassandra ke Amazon Keyspaces](migrating-offline.md).
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](functional-differences.md#functional-differences.light-transactions) (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](client-side-timestamps.md).
+ **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, lihat[Data kedaluwarsa dengan Time to Live (TTL) untuk Amazon Keyspaces (untuk Apache Cassandra)](TTL.md).
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.
![\[Menggunakan TTL untuk kedaluwarsa data historis saat bermigrasi dari Apache Cassandra ke Amazon Keyspaces.\]](http://docs.aws.amazon.com/id_id/keyspaces/latest/devguide/images/migration/online-migration-TTL.png)
1. 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.
1. Setelah 60 hari, cluster Cassandra dan Amazon Keyspaces berisi data yang sama yang ditulis dalam 60 hari terakhir.
1. 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.
# Memvalidasi konsistensi data selama migrasi online
Langkah selanjutnya dalam proses migrasi online adalah validasi data. Penulisan ganda menambahkan data baru ke database Amazon Keyspaces Anda dan Anda telah menyelesaikan migrasi data historis baik menggunakan unggahan massal atau kedaluwarsa data dengan TTL.
Sekarang Anda dapat menggunakan fase validasi untuk mengonfirmasi bahwa kedua penyimpanan data sebenarnya berisi data yang sama dan mengembalikan hasil baca yang sama. Anda dapat memilih dari salah satu dari dua opsi berikut untuk memvalidasi bahwa kedua database Anda berisi data yang identik.
+ **Bacaan ganda** — Untuk memvalidasi bahwa keduanya, sumber dan database tujuan berisi kumpulan data yang baru ditulis dan historis yang sama, Anda dapat menerapkan pembacaan ganda. Untuk melakukannya, Anda membaca dari Cassandra utama dan database Amazon Keyspaces sekunder Anda mirip dengan metode penulisan ganda dan membandingkan hasilnya secara asinkron.
Hasil dari database utama dikembalikan ke klien, dan hasil dari database sekunder digunakan untuk memvalidasi terhadap kumpulan hasil utama. Perbedaan yang ditemukan dapat dicatat atau dikirim ke [antrian surat mati (DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) untuk rekonsiliasi nanti.
Dalam diagram berikut, aplikasi melakukan pembacaan sinkron dari Cassandra, yang merupakan penyimpanan data utama) dan pembacaan asinkron dari Amazon Keyspaces, yang merupakan penyimpanan data sekunder.
![\[Menggunakan pembacaan ganda untuk memvalidasi konsistensi data selama migrasi online dari Apache Cassandra ke Amazon Keyspaces.\]](http://docs.aws.amazon.com/id_id/keyspaces/latest/devguide/images/migration/online-migration-dual-reads.png)
+ **Pembacaan sampel** — Solusi alternatif yang tidak memerlukan perubahan kode aplikasi adalah dengan menggunakan AWS Lambda fungsi untuk mengambil sampel data secara berkala dan acak dari cluster Cassandra sumber dan database Amazon Keyspaces tujuan.
Fungsi Lambda ini dapat dikonfigurasi untuk berjalan secara berkala. Fungsi Lambda mengambil subset data acak dari sistem sumber dan tujuan, dan kemudian melakukan perbandingan data sampel. Setiap perbedaan atau ketidakcocokan antara dua kumpulan data dapat direkam dan dikirim ke [antrian surat mati khusus (](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html)DLQ) untuk rekonsiliasi nanti.
Proses ini diilustrasikan dalam diagram berikut.
![\[Menggunakan pembacaan sampel untuk memvalidasi konsistensi data selama dan migrasi online dari Apache Cassandra ke Amazon Keyspaces.\]](http://docs.aws.amazon.com/id_id/keyspaces/latest/devguide/images/migration/online-migration-sample-reads.png)
# Migrasi aplikasi selama migrasi online
Pada fase keempat migrasi online, Anda memigrasikan aplikasi dan beralih ke Amazon Keyspaces sebagai penyimpanan data utama. Ini berarti Anda mengalihkan aplikasi Anda untuk membaca dan menulis langsung dari dan ke Amazon Keyspaces. Untuk memastikan gangguan minimal pada pengguna Anda, ini harus menjadi proses yang terencana dan terkoordinasi dengan baik.
Tersedia dua solusi berbeda yang direkomendasikan untuk migrasi aplikasi, strategi pemotongan hijau biru dan strategi pemotongan kenari. Bagian berikut menguraikan strategi ini secara lebih rinci.
+ **Strategi hijau biru** — Dengan menggunakan pendekatan ini, Anda mengalihkan aplikasi Anda untuk memperlakukan Amazon Keyspaces sebagai penyimpanan data utama dan Cassandra sebagai penyimpanan data sekunder dalam satu langkah. Anda dapat melakukan ini menggunakan flag AWS AppConfig fitur untuk mengontrol pemilihan penyimpanan data primer dan sekunder di seluruh instance aplikasi. Untuk informasi selengkapnya tentang flag fitur, lihat [Membuat profil konfigurasi flag fitur di AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-creating-configuration-and-profile-feature-flags.html).
Setelah menjadikan Amazon Keyspaces sebagai penyimpanan data utama, Anda memantau perilaku dan kinerja aplikasi, memastikan bahwa Amazon Keyspaces memenuhi persyaratan Anda dan migrasi berhasil.
Misalnya, jika Anda menerapkan pembacaan ganda untuk aplikasi Anda, selama fase migrasi aplikasi Anda mentransisikan pembacaan utama dari Cassandra ke Amazon Keyspaces dan pembacaan sekunder dari Amazon Keyspaces ke Cassandra. Setelah transisi, Anda terus memantau dan membandingkan hasil seperti yang dijelaskan di bagian [validasi data](migration-online-validation.md) untuk memastikan konsistensi di kedua database sebelum menonaktifkan Cassandra.
Jika Anda mendeteksi masalah apa pun, Anda dapat dengan cepat memutar kembali ke keadaan sebelumnya dengan kembali ke Cassandra sebagai penyimpanan data utama. Anda hanya melanjutkan ke fase penonaktifan migrasi jika Amazon Keyspaces memenuhi semua kebutuhan Anda sebagai penyimpanan data utama.
![\[Menggunakan strategi hijau biru untuk memigrasikan aplikasi dari Apache Cassandra ke Amazon Keyspaces.\]](http://docs.aws.amazon.com/id_id/keyspaces/latest/devguide/images/migration/online-migration-switch.png)
+ **Strategi kenari** — Dalam pendekatan ini, Anda secara bertahap meluncurkan migrasi ke subset pengguna atau lalu lintas Anda. Awalnya, sebagian kecil dari lalu lintas aplikasi Anda, misalnya 5% dari semua lalu lintas dirutekan ke versi menggunakan Amazon Keyspaces sebagai penyimpanan data utama, sementara sisa lalu lintas terus menggunakan Cassandra sebagai penyimpanan data utama.
Ini memungkinkan Anda untuk menguji versi migrasi secara menyeluruh dengan lalu lintas dunia nyata dan memantau kinerja, stabilitas, dan menyelidiki potensi masalah. Jika Anda tidak mendeteksi masalah apa pun, Anda dapat secara bertahap meningkatkan persentase lalu lintas yang dirutekan ke Amazon Keyspaces hingga menjadi penyimpanan data utama untuk semua pengguna dan lalu lintas.
Peluncuran bertahap ini meminimalkan risiko gangguan layanan yang meluas dan memungkinkan proses migrasi yang lebih terkontrol. Jika ada masalah kritis yang muncul selama penyebaran kenari, Anda dapat dengan cepat memutar kembali ke versi sebelumnya menggunakan Cassandra sebagai penyimpanan data utama untuk segmen lalu lintas yang terpengaruh. Anda hanya melanjutkan ke fase penonaktifan migrasi setelah Anda memvalidasi bahwa Amazon Keyspaces memproses 100% pengguna dan lalu lintas Anda seperti yang diharapkan.
Diagram berikut menggambarkan langkah-langkah individu dari strategi kenari.
![\[Menggunakan strategi kenari untuk memigrasikan aplikasi dari Apache Cassandra ke Amazon Keyspaces.\]](http://docs.aws.amazon.com/id_id/keyspaces/latest/devguide/images/migration/online-migration-canary.png)
# Menonaktifkan Cassandra setelah migrasi online
Setelah migrasi aplikasi selesai dengan aplikasi Anda sepenuhnya berjalan di Amazon Keyspaces dan Anda telah memvalidasi konsistensi data selama periode waktu tertentu, Anda dapat merencanakan untuk menonaktifkan cluster Cassandra Anda. Selama fase ini, Anda dapat mengevaluasi apakah data yang tersisa di cluster Cassandra Anda perlu diarsipkan atau dapat dihapus. Ini tergantung pada kebijakan organisasi Anda untuk penanganan dan penyimpanan data.
Dengan mengikuti strategi ini dan mempertimbangkan praktik terbaik yang direkomendasikan yang dijelaskan dalam topik ini saat merencanakan migrasi online Anda dari Cassandra ke Amazon Keyspaces, Anda dapat memastikan transisi yang mulus ke Amazon Keyspaces sambil read-after-write mempertahankan konsistensi dan ketersediaan aplikasi Anda.
Bermigrasi dari Apache Cassandra ke Amazon Keyspaces dapat memberikan banyak manfaat, termasuk pengurangan overhead operasional, penskalaan otomatis, keamanan yang ditingkatkan, dan kerangka kerja yang membantu Anda mencapai tujuan kepatuhan Anda. Dengan merencanakan strategi migrasi online dengan penulisan ganda, pengunggahan data historis, validasi data, dan peluncuran bertahap, Anda dapat memastikan transisi yang mulus dengan gangguan minimal pada aplikasi Anda dan penggunanya.
Menerapkan strategi migrasi online yang dibahas dalam topik ini memungkinkan Anda memvalidasi hasil migrasi, mengidentifikasi dan mengatasi masalah apa pun, dan pada akhirnya menonaktifkan penerapan Cassandra yang ada demi layanan Amazon Keyspaces yang dikelola sepenuhnya.
# Proses migrasi offline: Apache Cassandra ke Amazon Keyspaces
Migrasi offline cocok bila Anda mampu melakukan downtime untuk melakukan migrasi. Sudah umum di antara perusahaan untuk memiliki jendela pemeliharaan untuk patching, rilis besar, atau downtime untuk peningkatan perangkat keras atau peningkatan besar. Migrasi offline dapat menggunakan jendela ini untuk menyalin data dan mengalihkan lalu lintas aplikasi dari Apache Cassandra ke Amazon Keyspaces.
Migrasi offline mengurangi modifikasi pada aplikasi karena tidak memerlukan komunikasi ke Cassandra dan Amazon Keyspaces secara bersamaan. Selain itu, dengan aliran data dijeda, status yang tepat dapat disalin tanpa mempertahankan mutasi.
Dalam contoh ini, kami menggunakan Amazon Simple Storage Service (Amazon S3) sebagai area pementasan data selama migrasi offline untuk meminimalkan waktu henti. Anda dapat secara otomatis mengimpor data yang Anda simpan dalam format Parket di Amazon S3 ke dalam tabel Amazon Keyspaces menggunakan konektor Spark Cassandra dan. AWS Glue Bagian berikut akan menunjukkan ikhtisar tingkat tinggi dari proses tersebut. Anda dapat menemukan contoh kode untuk proses ini di [Github](https://github.com/aws-samples/amazon-keyspaces-examples/tree/main/scala/datastax-v4/aws-glue).
Proses migrasi offline dari Apache Cassandra ke Amazon Keyspaces menggunakan Amazon S3 dan memerlukan pekerjaan berikut. AWS Glue AWS Glue
1. Pekerjaan ETL yang mengekstrak dan mengubah data CQL dan menyimpannya di bucket Amazon S3.
1. Pekerjaan kedua yang mengimpor data dari bucket ke Amazon Keyspaces.
1. Pekerjaan ketiga untuk mengimpor data tambahan.
**Cara melakukan migrasi offline ke Amazon Keyspaces dari Cassandra yang berjalan di Amazon EC2 di Amazon Virtual Private Cloud**
1. Pertama Anda gunakan AWS Glue untuk mengekspor data tabel dari Cassandra dalam format Parket dan menyimpannya ke ember Amazon S3. Anda perlu menjalankan AWS Glue pekerjaan menggunakan AWS Glue konektor ke VPC tempat EC2 instans Amazon yang menjalankan Cassandra berada. Kemudian, menggunakan titik akhir pribadi Amazon S3, Anda dapat menyimpan data ke bucket Amazon S3.
Diagram berikut menggambarkan langkah-langkah ini.
![\[Memigrasi data Apache Cassandra dari Amazon yang berjalan EC2 di VPC ke bucket Amazon S3 menggunakan. AWS Glue\]](http://docs.aws.amazon.com/id_id/keyspaces/latest/devguide/images/migration/migration-export.png)
1. Kocokkan data di bucket Amazon S3 untuk meningkatkan pengacakan data. Data yang diimpor secara merata memungkinkan lalu lintas yang lebih terdistribusi di tabel target.
Langkah ini diperlukan saat mengekspor data dari Cassandra dengan partisi besar (partisi dengan lebih dari 1000 baris) untuk menghindari pola tombol pintas saat memasukkan data ke Amazon Keyspaces. Masalah kunci panas terjadi `WriteThrottleEvents` di Amazon Keyspaces dan mengakibatkan peningkatan waktu muat.
![\[AWS GluePekerjaan mengacak data dari bucket Amazon S3 dan mengembalikannya ke bucket Amazon S3 lainnya.\]](http://docs.aws.amazon.com/id_id/keyspaces/latest/devguide/images/migration/migration-shuffle.png)
1. Gunakan AWS Glue pekerjaan lain untuk mengimpor data dari bucket Amazon S3 ke Amazon Keyspaces. Data yang diacak di bucket Amazon S3 disimpan dalam format Parket.
![\[Pekerjaan AWS Glue impor mengambil data acak dari bucket Amazon S3 dan memindahkannya ke tabel Amazon Keyspaces.\]](http://docs.aws.amazon.com/id_id/keyspaces/latest/devguide/images/migration/migration-import.png)
Untuk informasi selengkapnya tentang proses migrasi offline, lihat lokakarya [Amazon Keyspaces with AWS Glue](https://catalog.workshops.aws/unlocking-amazonkeyspaces/en-US/keyspaces-with-glue)
# Menggunakan solusi migrasi hibrida: Apache Cassandra ke Amazon Keyspaces
Solusi migrasi berikut dapat dianggap sebagai hibrida antara migrasi online dan offline. Dengan pendekatan hybrid ini, data ditulis ke database tujuan dalam waktu dekat tanpa memberikan konsistensi baca demi tulis. Ini berarti bahwa data yang baru ditulis tidak akan segera tersedia dan penundaan diharapkan terjadi. Jika Anda perlu membaca setelah menulis konsistensi, lihat[Migrasi online ke Amazon Keyspaces: strategi dan praktik terbaik](migrating-online.md).
Untuk migrasi waktu nyata dari Apache Cassandra ke Amazon Keyspaces, Anda dapat memilih di antara dua metode yang tersedia.
+ **CQLReplicator**— (Disarankan) CQLReplicator adalah utilitas open source yang tersedia di [Github](https://github.com/aws-samples/cql-replicator) yang membantu Anda memigrasikan data dari Apache Cassandra ke Amazon Keyspaces dalam waktu dekat.
Untuk menentukan penulisan dan pembaruan untuk disebarkan ke database tujuan, CQLReplicator memindai rentang token Apache Cassandra dan menggunakan AWS Glue pekerjaan untuk menghapus peristiwa duplikat dan menerapkan penulisan dan pembaruan langsung ke Amazon Keyspaces.
+ **Ubah pengambilan data (CDC)** - Jika Anda terbiasa dengan Cassandra CDC, fitur CDC bawaan Apache Cassandra yang memungkinkan pengambilan perubahan dengan menyalin log komit ke direktori CDC terpisah adalah opsi lain untuk menerapkan migrasi hibrida.
Anda dapat melakukannya dengan mereplikasi perubahan data ke Amazon Keyspaces, menjadikan CDC sebagai opsi alternatif untuk skenario migrasi data.
Jika Anda tidak memerlukan konsistensi baca setelah menulis, Anda dapat menggunakan pipeline CQLReplicator atau CDC untuk memigrasikan data dari Apache Cassandra ke Amazon Keyspaces berdasarkan preferensi dan keakraban Anda dengan alat dan digunakan di setiap solusi. Layanan AWS Menggunakan metode ini untuk memigrasikan data dalam waktu dekat dapat dianggap sebagai pendekatan hibrida untuk migrasi yang menawarkan alternatif untuk migrasi online.
Strategi ini dianggap sebagai pendekatan hibrida, karena selain opsi yang diuraikan dalam topik ini, Anda harus menerapkan beberapa langkah kemajuan migrasi online, misalnya salinan data historis dan strategi migrasi aplikasi yang dibahas dalam topik [migrasi online](migrating-online.md).
Bagian berikut membahas opsi migrasi hibrida secara lebih rinci.
**Topics**
+ [Migrasi data menggunakan CQLReplicator](migration-hybrid-cql-rep.md)
+ [Migrasi data menggunakan change data capture (CDC)](migration-hybrid-cdc.md)
# Migrasi data menggunakan CQLReplicator
Dengan [CQLReplicator](https://github.com/aws-samples/cql-replicator), Anda dapat membaca data dari Apache Cassandra dalam waktu dekat dengan memindai cincin token Cassandra secara cerdas menggunakan kueri CQL. CQLReplicator tidak menggunakan Cassandra CDC dan sebagai gantinya menerapkan strategi caching untuk mengurangi penalti kinerja pemindaian penuh.
Untuk mengurangi jumlah penulisan ke tujuan, CQLReplicator secara otomatis menghapus duplikat peristiwa replikasi. Dengan CQLReplicator, Anda dapat menyetel replikasi perubahan dari database sumber ke database tujuan, memungkinkan migrasi data secara real time dari Apache Cassandra ke Amazon Keyspaces.
Diagram berikut menunjukkan arsitektur khas CQLReplicator pekerjaan menggunakanAWS Glue.
1. **Untuk memungkinkan akses ke Apache Cassandra berjalan di VPC pribadi, konfigurasikan AWS Glue koneksi dengan jenis koneksi Jaringan.**
1. Untuk menghapus duplikat dan mengaktifkan caching kunci dengan CQLReplicator pekerjaan, konfigurasikan Amazon Simple Storage Service (Amazon S3).
1. Database sumber terverifikasi streaming CQLReplicator pekerjaan berubah langsung ke Amazon Keyspaces.
![\[Menggunakan CQLReplicator untuk memigrasikan data dari Apache Cassandra ke Amazon Keyspaces.\]](http://docs.aws.amazon.com/id_id/keyspaces/latest/devguide/images/migration/hybrid-migration-CQLRep.png)
Untuk informasi selengkapnya tentang proses migrasi yang digunakan CQLReplicator, lihat postingan berikut di blog AWS Database [Migrasikan beban kerja Cassandra ke Amazon Keyspaces CQLReplicator menggunakan dan panduan preskriptif [Memigrasikan beban kerja Apache](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migrate-apache-cassandra-workloads-to-amazon-keyspaces-using-aws-glue.html) Cassandra AWS ke Amazon Keyspaces](https://aws.amazon.com/blogs/database/migrate-cassandra-workloads-to-amazon-keyspaces-using-cqlreplicator/) menggunakan. AWS Glue
# Migrasi data menggunakan change data capture (CDC)
Jika sudah terbiasa mengonfigurasi pipeline change data capture (CDC) dengan [Debezium](https://debezium.io/), Anda dapat menggunakan opsi ini untuk memigrasikan data ke Amazon Keyspaces sebagai alternatif penggunaan. CQLReplicator Debezium adalah platform terdistribusi open-source untuk CDC, yang dirancang untuk memantau database dan menangkap perubahan tingkat baris dengan andal.
[Konektor Debezium untuk Apache Cassandra mengunggah](https://debezium.io/documentation/reference/stable/connectors/cassandra.html) perubahan ke Amazon Managed Streaming for Apache Kafka (Amazon MSK) sehingga dapat dikonsumsi dan diproses oleh konsumen hilir yang pada gilirannya menulis data ke Amazon Keyspaces. Untuk informasi selengkapnya, lihat [Panduan migrasi data berkelanjutan dari Apache Cassandra ke Amazon](https://aws.amazon.com/solutions/guidance/continuous-data-migration-from-apache-cassandra-to-amazon-keyspaces/) Keyspaces.
Untuk mengatasi masalah konsistensi data potensial, Anda dapat menerapkan proses dengan Amazon MSK di mana konsumen membandingkan kunci atau partisi di Cassandra dengan yang ada di Amazon Keyspaces.
Untuk mengimplementasikan solusi ini dengan sukses, kami sarankan untuk mempertimbangkan hal berikut.
+ Cara mengurai log komit CDC, misalnya cara menghapus peristiwa duplikat.
+ Cara memelihara direktori CDC, misalnya cara menghapus log lama.
+ Cara menangani kegagalan sebagian di Apache Cassandra, misalnya jika penulisan hanya berhasil dalam satu dari tiga replika.
+ Cara menangani alokasi sumber daya, misalnya meningkatkan ukuran instance untuk memperhitungkan persyaratan CPU, memori, DISK, dan IO tambahan untuk proses CDC yang terjadi pada node.
Pola ini memperlakukan perubahan dari Cassandra sebagai “petunjuk” bahwa kunci mungkin telah berubah dari keadaan sebelumnya. Untuk menentukan apakah ada perubahan untuk disebarkan ke database tujuan, Anda harus terlebih dahulu membaca dari cluster Cassandra sumber menggunakan `LOCAL_QUORUM` operasi untuk menerima catatan terbaru dan kemudian menuliskannya ke Amazon Keyspaces.
Dalam kasus penghapusan rentang atau pembaruan rentang, Anda mungkin perlu melakukan perbandingan terhadap seluruh partisi untuk menentukan peristiwa penulisan atau pembaruan mana yang perlu ditulis ke database tujuan Anda.
Dalam kasus di mana penulisan tidak idempoten, Anda juga perlu membandingkan tulisan Anda dengan apa yang sudah ada di database tujuan sebelum menulis ke Amazon Keyspaces.
Diagram berikut menunjukkan arsitektur khas pipa CDC menggunakan Debezium dan Amazon MSK.
![\[Menggunakan pipeline pengambilan data perubahan untuk memigrasikan data dari Apache Cassandra ke Amazon Keyspaces.\]](http://docs.aws.amazon.com/id_id/keyspaces/latest/devguide/images/migration/hybrid-migration-CDC.png)
# Cara memilih alat yang tepat untuk mengunggah massal atau memigrasi data ke Amazon Keyspaces
Di bagian ini, Anda dapat meninjau berbagai alat yang dapat Anda gunakan untuk mengunggah atau memigrasi data secara massal ke Amazon Keyspaces, dan mempelajari cara memilih alat yang benar berdasarkan kebutuhan Anda. Selain itu, bagian ini memberikan ikhtisar dan kasus penggunaan untuk step-by-step tutorial yang tersedia yang menunjukkan cara mengimpor data ke Amazon Keyspaces.
Untuk meninjau strategi yang tersedia untuk memigrasikan beban kerja dari Apache Cassandra ke Amazon Keyspaces, lihat. [Buat rencana migrasi untuk migrasi dari Apache Cassandra ke Amazon Keyspaces](migrating-cassandra.md)
+ **Alat migrasi**
+ Dengan [kalkulator harga untuk Amazon Keyspaces (untuk Apache Cassandra)](https://aws-samples.github.io/sample-pricing-calculator-for-keyspaces/#cassandra) yang tersedia di Github, Anda dapat memperkirakan biaya bulanan Anda untuk Amazon Keyspaces berdasarkan beban kerja Apache Cassandra yang ada. Masukkan metrik dari keluaran status nodetool Cassandra Anda dan konfigurasi tanpa server yang dimaksudkan untuk Amazon Keyspaces untuk membandingkan biaya langsung antara kedua solusi. Perhatikan bahwa kalkulator ini hanya berfokus pada biaya operasional Amazon Keyspaces dibandingkan dengan penerapan Cassandra yang ada. Ini tidak termasuk faktor biaya kepemilikan total (TCO) seperti pemeliharaan infrastruktur, overhead operasional, atau biaya dukungan untuk Cassandra.
+ **ZDM Dual Write Proxy untuk Migrasi Keyspaces Amazon - ZDM Dual Write Proxy tersedia di Github mendukung migrasi** [zero-downtime dari Apache Cassandra](https://github.com/aws-samples/amazon-keyspaces-examples/blob/main/migration/online/zdm-proxy/README.md) ke Amazon Keyspaces.
+ **CQLReplicator**— CQLReplicator adalah utilitas open source yang tersedia di [Github](https://github.com/aws-samples/cql-replicator) yang membantu Anda memigrasikan data dari Apache Cassandra ke Amazon Keyspaces dalam waktu dekat.
Untuk informasi selengkapnya, lihat [Migrasi data menggunakan CQLReplicator](migration-hybrid-cql-rep.md).
+ Untuk mempelajari selengkapnya tentang cara menggunakan Amazon Managed Streaming for Apache Kafka guna menerapkan proses migrasi [online](migrating-online.md) dengan penulisan ganda, [lihat Panduan migrasi data berkelanjutan dari Apache Cassandra](https://aws.amazon.com/solutions/guidance/continuous-data-migration-from-apache-cassandra-to-amazon-keyspaces/) ke Amazon Keyspaces.
+ Untuk migrasi besar, pertimbangkan untuk menggunakan alat ekstrak, transformasi, dan muat (ETL). Anda dapat menggunakannya AWS Glue untuk melakukan migrasi transformasi data dengan cepat dan efektif. Untuk informasi selengkapnya, lihat [Proses migrasi offline: Apache Cassandra ke Amazon Keyspaces](migrating-offline.md).
+ Untuk mempelajari cara menggunakan konektor Apache Cassandra Spark untuk menulis data ke Amazon Keyspaces, lihat. [Tutorial: Integrasikan dengan Apache Spark untuk mengimpor atau mengekspor data](spark-integrating.md)
+ Mulailah dengan cepat dengan memuat data ke Amazon Keyspaces dengan menggunakan `COPY FROM` perintah cqlsh. cqlsh disertakan dengan Apache Cassandra dan paling cocok untuk memuat kumpulan data kecil atau data uji. Untuk step-by-step instruksi, lihat[Tutorial: Memuat data ke Amazon Keyspaces menggunakan cqlsh](bulk-upload.md).
+ Anda juga dapat menggunakan DataStax Bulk Loader untuk Apache Cassandra untuk memuat data ke Amazon Keyspaces menggunakan perintah. `dsbulk` DSBulk[menyediakan kemampuan impor yang lebih kuat daripada cqlsh dan tersedia dari repositori. GitHub ](https://github.com/datastax/dsbulk) Untuk step-by-step instruksi, lihat[Tutorial: Memuat data ke Amazon Keyspaces menggunakan DSBulk](dsbulk-upload.md).
Pertimbangan umum untuk upload data ke Amazon Keyspaces
+ **Pecah unggahan data menjadi komponen yang lebih kecil.**
Pertimbangkan unit migrasi berikut dan jejak potensialnya dalam hal ukuran data mentah. Mengunggah data dalam jumlah yang lebih kecil dalam satu atau beberapa fase dapat membantu menyederhanakan migrasi Anda.
+ **Berdasarkan cluster** — Migrasikan semua data Cassandra Anda sekaligus. Pendekatan ini mungkin baik-baik saja untuk kelompok yang lebih kecil.
+ **Berdasarkan ruang kunci atau tabel** — Pecah migrasi Anda ke dalam grup ruang kunci atau tabel. Pendekatan ini dapat membantu Anda memigrasikan data secara bertahap berdasarkan kebutuhan Anda untuk setiap beban kerja.
+ **Berdasarkan data** — Pertimbangkan untuk memigrasikan data untuk grup pengguna atau produk tertentu, untuk menurunkan ukuran data.
+ **Prioritaskan data apa yang akan diunggah terlebih dahulu berdasarkan kesederhanaan.**
Pertimbangkan jika Anda memiliki data yang dapat dimigrasikan terlebih dahulu dengan lebih mudah—misalnya, data yang tidak berubah selama waktu tertentu, data dari pekerjaan batch malam hari, data yang tidak digunakan selama jam offline, atau data dari aplikasi internal.
**Topics**
+ [Tutorial: Memuat data ke Amazon Keyspaces menggunakan cqlsh](bulk-upload.md)
+ [Tutorial: Memuat data ke Amazon Keyspaces menggunakan DSBulk](dsbulk-upload.md)
# Tutorial: Memuat data ke Amazon Keyspaces menggunakan cqlsh
Tutorial ini memandu Anda melalui proses migrasi data dari Apache Cassandra ke Amazon Keyspaces menggunakan perintah. `cqlsh COPY FROM` `cqlsh COPY FROM`Perintah ini berguna untuk mengunggah kumpulan data kecil dengan cepat dan mudah ke Amazon Keyspaces untuk tujuan akademis atau pengujian. Untuk informasi selengkapnya tentang cara memigrasikan beban kerja produksi, lihat. [Proses migrasi offline: Apache Cassandra ke Amazon Keyspaces](migrating-offline.md) Dalam tutorial ini, Anda akan menyelesaikan langkah-langkah berikut:
Prasyarat - Siapkan AWS akun dengan kredensyal, buat file penyimpanan kepercayaan JKS untuk sertifikat, dan konfigurasikan untuk terhubung ke Amazon Keyspaces. `cqlsh`
1. **Buat CSV sumber dan tabel target** — Siapkan file CSV sebagai data sumber dan buat ruang kunci dan tabel target di Amazon Keyspaces.
1. **Siapkan data** — Acak data dalam file CSV dan analisis untuk menentukan ukuran baris rata-rata dan maksimum.
1. **Mengatur kapasitas throughput** — Hitung unit kapasitas tulis yang diperlukan (WCUs) berdasarkan ukuran data dan waktu muat yang diinginkan, dan konfigurasikan kapasitas yang disediakan tabel.
1. **Konfigurasikan parameter cqlsh** — Tentukan nilai optimal untuk `cqlsh COPY FROM` parameter seperti`INGESTRATE`,, `NUMPROCESSES``MAXBATCHSIZE`, dan `CHUNKSIZE` untuk mendistribusikan beban kerja secara merata.
1. **Jalankan `cqlsh COPY FROM` perintah** — Jalankan `cqlsh COPY FROM` perintah untuk mengunggah data dari file CSV ke tabel Amazon Keyspaces, dan pantau progres.
Pemecahan masalah — Mengatasi masalah umum seperti permintaan tidak valid, kesalahan parser, kesalahan kapasitas, dan kesalahan cqlsh selama proses pengunggahan data.
**Topics**
+ [Prasyarat: Langkah-langkah yang harus diselesaikan sebelum Anda dapat mengunggah data menggunakan `cqlsh COPY FROM`](bulk-upload-prequs.md)
+ [Langkah 1: Buat file CSV sumber dan tabel target untuk unggahan data](bulk-upload-source.md)
+ [Langkah 2: Siapkan data sumber untuk mengunggah data yang berhasil](bulk-upload-prepare-data.md)
+ [Langkah 3: Atur kapasitas throughput untuk tabel](bulk-upload-capacity.md)
+ [Langkah 4: Konfigurasikan `cqlsh COPY FROM` pengaturan](bulk-upload-config.md)
+ [Langkah 5: Jalankan `cqlsh COPY FROM` perintah untuk mengunggah data dari file CSV ke tabel target](bulk-upload-run.md)
+ [Pemecahan masalah](bulk-upload-troubleshooting.md)
# Prasyarat: Langkah-langkah yang harus diselesaikan sebelum Anda dapat mengunggah data menggunakan `cqlsh COPY FROM`
Anda harus menyelesaikan tugas-tugas berikut sebelum Anda dapat memulai tutorial ini.
1. Jika Anda belum melakukannya, daftar Akun AWS dengan mengikuti langkah-langkah di[Menyiapkan AWS Identity and Access Management](accessing.md#SettingUp.IAM).
1. Buat kredensil khusus layanan dengan mengikuti langkah-langkah di. [Buat kredensil khusus layanan untuk akses terprogram ke Amazon Keyspaces](programmatic.credentials.ssc.md)
1. Siapkan koneksi shell Cassandra Query Language (cqlsh) dan konfirmasikan bahwa Anda dapat terhubung ke Amazon Keyspaces dengan mengikuti langkah-langkah di. [Menggunakan `cqlsh` untuk terhubung ke Amazon Keyspaces](programmatic.cqlsh.md)
# Langkah 1: Buat file CSV sumber dan tabel target untuk unggahan data
Untuk tutorial ini, kita menggunakan file nilai dipisahkan koma (CSV) dengan nama `keyspaces_sample_table.csv` sebagai file sumber untuk migrasi data. File sampel yang disediakan berisi beberapa baris data untuk tabel dengan nama`book_awards`.
1. Buat file sumber. Anda dapat memilih salah satu opsi berikut:
+ Download contoh file CSV (`keyspaces_sample_table.csv`) yang terkandung dalam file arsip berikut [samplemigration.zip](samples/samplemigration.zip). Buka zip arsip dan catat jalur ke`keyspaces_sample_table.csv`.
+ Untuk mengisi file CSV dengan data Anda sendiri yang disimpan dalam database Apache Cassandra, Anda dapat mengisi file CSV sumber dengan menggunakan `cqlsh` `COPY TO` pernyataan seperti yang ditunjukkan pada contoh berikut.
```
cqlsh localhost 9042 -u "username" -p "password" --execute "COPY mykeyspace.mytable TO 'keyspaces_sample_table.csv' WITH HEADER=true";
```
Pastikan file CSV yang Anda buat memenuhi persyaratan berikut:
+ Baris pertama berisi nama kolom.
+ Nama kolom dalam file CSV sumber cocok dengan nama kolom di tabel target.
+ Data dibatasi dengan koma.
+ Semua nilai data adalah tipe data Amazon Keyspaces yang valid. Lihat [Jenis Data](cql.elements.md#cql.data-types).
1. Buat keyspace target dan tabel di Amazon Keyspaces.
1. Connect ke Amazon Keyspaces menggunakan`cqlsh`, mengganti endpoint layanan, nama pengguna, dan kata sandi dalam contoh berikut dengan nilai Anda sendiri.
```
cqlsh cassandra.us-east-1.amazonaws.com 9142 -u "111122223333" -p "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" --ssl
```
1. Buat keyspace baru dengan nama `catalog` seperti yang ditunjukkan pada contoh berikut.
```
CREATE KEYSPACE catalog WITH REPLICATION = {'class': 'SingleRegionStrategy'};
```
1. Ketika keyspace baru tersedia, gunakan kode berikut untuk membuat tabel `book_awards` target.
```
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)
);
```
Jika Apache Cassandra adalah sumber data asli Anda, cara sederhana untuk membuat tabel target Amazon Keyspaces dengan header yang cocok adalah dengan menghasilkan `CREATE TABLE` pernyataan dari tabel sumber, seperti yang ditunjukkan dalam pernyataan berikut.
```
cqlsh localhost 9042 -u "username" -p "password" --execute "DESCRIBE TABLE mykeyspace.mytable;"
```
Kemudian buat tabel target di Amazon Keyspaces dengan nama kolom dan tipe data yang cocok dengan deskripsi dari tabel sumber Cassandra.
# Langkah 2: Siapkan data sumber untuk mengunggah data yang berhasil
Mempersiapkan data sumber untuk transfer yang efisien adalah proses dua langkah. Pertama, Anda mengacak data. Pada langkah kedua, Anda menganalisis data untuk menentukan nilai `cqlsh` parameter yang sesuai dan pengaturan tabel yang diperlukan untuk memastikan bahwa unggahan data berhasil.
**Acak data**
`cqlsh COPY FROM`Perintah membaca dan menulis data dalam urutan yang sama seperti yang muncul di file CSV. Jika Anda menggunakan `cqlsh COPY TO` perintah untuk membuat file sumber, data ditulis dalam urutan kunci yang diurutkan di CSV. Secara internal, Amazon Keyspaces mempartisi data menggunakan tombol partisi. Meskipun Amazon Keyspaces memiliki logika bawaan untuk membantu memuat permintaan keseimbangan untuk kunci partisi yang sama, memuat data lebih cepat dan lebih efisien jika Anda mengacak urutan. Ini karena Anda dapat memanfaatkan penyeimbangan beban bawaan yang terjadi saat Amazon Keyspaces menulis ke partisi yang berbeda.
Untuk menyebarkan tulisan di seluruh partisi secara merata, Anda harus mengacak data dalam file sumber. Anda dapat menulis aplikasi untuk melakukan ini atau menggunakan alat sumber terbuka, seperti [Shuf](https://en.wikipedia.org/wiki/Shuf). Shuf tersedia secara bebas di distribusi Linux, di macOS (dengan menginstal coreutils di [homebrew](https://brew.sh)), dan di Windows (dengan menggunakan Windows Subsystem for Linux (WSL)). Satu langkah tambahan diperlukan untuk mencegah baris header dengan nama kolom diacak pada langkah ini.
Untuk mengacak file sumber sambil mempertahankan header, masukkan kode berikut.
```
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 menulis ulang data ke file CSV baru yang disebut. `keyspace.table.csv` Anda sekarang dapat menghapus `keyspaces_sample_table.csv` file — Anda tidak lagi membutuhkannya.
**Menganalisis data**
Tentukan ukuran baris rata-rata dan maksimum dengan menganalisis data.
Anda melakukan ini karena alasan berikut:
+ Ukuran baris rata-rata membantu memperkirakan jumlah total data yang akan ditransfer.
+ Anda memerlukan ukuran baris rata-rata untuk menyediakan kapasitas tulis yang diperlukan untuk unggahan data.
+ Anda dapat memastikan bahwa setiap baris berukuran kurang dari 1 MB, yang merupakan ukuran baris maksimum di Amazon Keyspaces.
**catatan**
Kuota ini mengacu pada ukuran baris, bukan ukuran partisi. Tidak seperti partisi Apache Cassandra, partisi Amazon Keyspaces hampir tidak terikat ukurannya. Kunci partisi dan kolom pengelompokan memerlukan penyimpanan tambahan untuk metadata, yang harus Anda tambahkan ke ukuran baris mentah. Untuk informasi selengkapnya, lihat [Perkirakan ukuran baris di Amazon Keyspaces](calculating-row-size.md).
Kode berikut menggunakan [AWK](https://en.wikipedia.org/wiki/AWK) untuk menganalisis file CSV dan mencetak ukuran baris rata-rata dan maksimum.
```
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
```
Menjalankan kode ini menghasilkan output berikut.
```
using 10,000 samples:
{lines: 10000, avg: 123 bytes, max: 225 bytes}
```
Anda menggunakan ukuran baris rata-rata pada langkah berikutnya dari tutorial ini untuk menyediakan kapasitas tulis untuk tabel.
# Langkah 3: Atur kapasitas throughput untuk tabel
Tutorial ini menunjukkan cara menyetel cqlsh untuk memuat data dalam rentang waktu yang ditetapkan. Karena Anda tahu berapa banyak membaca dan menulis yang Anda lakukan sebelumnya, gunakan mode kapasitas yang disediakan. Setelah Anda menyelesaikan transfer data, Anda harus mengatur mode kapasitas tabel agar sesuai dengan pola lalu lintas aplikasi Anda. Untuk mempelajari lebih lanjut tentang manajemen kapasitas, lihat[Mengelola sumber daya tanpa server di Amazon Keyspaces (untuk Apache Cassandra)](serverless_resource_management.md).
Dengan mode kapasitas yang disediakan, Anda menentukan berapa banyak kapasitas baca dan tulis yang ingin Anda berikan ke tabel Anda sebelumnya. Kapasitas tulis ditagih per jam dan diukur dalam satuan kapasitas tulis (). WCUs Setiap WCU memiliki kapasitas tulis yang cukup untuk mendukung penulisan 1 KB data per detik. Saat Anda memuat data, laju penulisan harus berada di bawah maks WCUs (parameter:`write_capacity_units`) yang ditetapkan pada tabel target.
Secara default, Anda dapat menyediakan hingga 40.000 WCUs ke tabel dan 80.000 WCUs di semua tabel di akun Anda. Jika Anda membutuhkan kapasitas tambahan, Anda dapat meminta peningkatan kuota di konsol [Service](https://console.aws.amazon.com/servicequotas/home#!/services/cassandra/quotas) Quotas. Untuk informasi lebih lanjut tentang kuota, lihat[Kuota untuk Amazon Keyspaces (untuk Apache Cassandra)](quotas.md).
**Hitung jumlah rata-rata yang WCUs diperlukan untuk sisipan**
Memasukkan 1 KB data per detik membutuhkan 1 WCU. Jika file CSV Anda memiliki 360.000 baris dan Anda ingin memuat semua data dalam 1 jam, Anda harus menulis 100 baris per detik (360.000 baris/ 60 menit/60 detik = 100 baris per detik). Jika setiap baris memiliki data hingga 1 KB, untuk memasukkan 100 baris per detik, Anda harus menyediakan 100 WCUs ke tabel Anda. Jika setiap baris memiliki 1,5 KB data, Anda perlu dua WCUs untuk memasukkan satu baris per detik. Oleh karena itu, untuk memasukkan 100 baris per detik, Anda harus menyediakan 200 WCUs.
Untuk menentukan berapa banyak yang WCUs Anda butuhkan untuk memasukkan satu baris per detik, bagi ukuran baris rata-rata dalam byte dengan 1024 dan bulatkan ke seluruh nomor terdekat.
Misalnya, jika ukuran baris rata-rata adalah 3000 byte, Anda perlu tiga WCUs untuk memasukkan satu baris per detik.
```
ROUNDUP(3000 / 1024) = ROUNDUP(2.93) = 3 WCUs
```
**Hitung waktu dan kapasitas pemuatan data**
Sekarang setelah Anda mengetahui ukuran rata-rata dan jumlah baris dalam file CSV Anda, Anda dapat menghitung berapa banyak yang WCUs Anda butuhkan untuk memuat data dalam jumlah waktu tertentu, dan perkiraan waktu yang diperlukan untuk memuat semua data dalam file CSV Anda menggunakan pengaturan WCU yang berbeda.
Misalnya, jika setiap baris dalam file Anda adalah 1 KB dan Anda memiliki 1.000.000 baris dalam file CSV Anda, untuk memuat data dalam 1 jam, Anda harus menyediakan setidaknya 278 WCUs ke tabel Anda selama jam itu.
```
1,000,000 rows * 1 KBs = 1,000,000 KBs
1,000,000 KBs / 3600 seconds =277.8 KBs / second = 278 WCUs
```
**Konfigurasikan pengaturan kapasitas yang disediakan**
Anda dapat mengatur pengaturan kapasitas tulis tabel saat Anda membuat tabel atau dengan menggunakan perintah `ALTER TABLE` CQL. Berikut ini adalah sintaks untuk mengubah pengaturan kapasitas disediakan tabel dengan pernyataan CQL. `ALTER TABLE`
```
ALTER TABLE mykeyspace.mytable WITH custom_properties={'capacity_mode':{'throughput_mode': 'PROVISIONED', 'read_capacity_units': 100, 'write_capacity_units': 278}} ;
```
Untuk referensi bahasa selengkapnya, lihat[ALTER TABLE](cql.ddl.table.md#cql.ddl.table.alter).
# Langkah 4: Konfigurasikan `cqlsh COPY FROM` pengaturan
Bagian ini menguraikan cara menentukan nilai parameter untuk`cqlsh COPY FROM`. `cqlsh COPY FROM`Perintah membaca file CSV yang Anda siapkan sebelumnya dan menyisipkan data ke Amazon Keyspaces menggunakan CQL. Perintah membagi baris dan mendistribusikan `INSERT` operasi di antara satu set pekerja. Setiap pekerja membuat koneksi dengan Amazon Keyspaces dan `INSERT` mengirimkan permintaan di sepanjang saluran ini.
`cqlsh COPY`Perintah tidak memiliki logika internal untuk mendistribusikan pekerjaan secara merata di antara para pekerjanya. Namun, Anda dapat mengonfigurasinya secara manual untuk memastikan bahwa pekerjaan didistribusikan secara merata. Mulailah dengan meninjau parameter cqlsh kunci ini:
+ **DELIMITER** — Jika Anda menggunakan pembatas selain koma, Anda dapat mengatur parameter ini, yang defaultnya koma.
+ **INGESTRATE** — Jumlah target baris yang `cqlsh COPY FROM` mencoba memproses per detik. Jika tidak disetel, defaultnya menjadi 100.000.
+ **NUMPROCESSS** — Jumlah proses pekerja anak yang dibuat cqlsh untuk tugas. `COPY FROM` Maksimum untuk pengaturan ini adalah 16, defaultnya adalah`num_cores - 1`, di mana `num_cores` jumlah inti pemrosesan pada host yang menjalankan cqlsh.
+ **MAXBATCHSIZE — Ukuran** batch menentukan jumlah maksimal baris yang dimasukkan ke dalam tabel tujuan dalam satu batch. Jika tidak disetel, cqlsh menggunakan batch 20 baris yang disisipkan.
+ **CHUNKSIZE** — Ukuran unit kerja yang diteruskan ke pekerja anak. Secara default, ini diatur ke 5.000.
+ **MAKSIMAL** — Jumlah maksimum kali untuk mencoba kembali potongan pekerja yang gagal. Setelah upaya maksimum tercapai, catatan yang gagal ditulis ke file CSV baru yang dapat Anda jalankan lagi nanti setelah menyelidiki kegagalan.
Tetapkan `INGESTRATE` berdasarkan jumlah WCUs yang Anda berikan ke tabel tujuan target. `INGESTRATE``cqlsh COPY FROM`Perintah bukanlah batas—ini adalah rata-rata target. Ini berarti dapat (dan sering) meledak di atas angka yang Anda tetapkan. Untuk memungkinkan ledakan dan memastikan bahwa kapasitas yang cukup tersedia untuk menangani permintaan pemuatan data, atur `INGESTRATE` ke 90% dari kapasitas tulis tabel.
```
INGESTRATE = WCUs * .90
```
Selanjutnya, atur `NUMPROCESSES` parameter menjadi sama dengan satu kurang dari jumlah core pada sistem Anda. Untuk mengetahui berapa jumlah core sistem Anda, Anda dapat menjalankan kode berikut.
```
python -c "import multiprocessing; print(multiprocessing.cpu_count())"
```
Untuk tutorial ini, kami menggunakan nilai berikut.
```
NUMPROCESSES = 4
```
Setiap proses membuat pekerja, dan setiap pekerja membuat koneksi ke Amazon Keyspaces. Amazon Keyspaces dapat mendukung hingga 3.000 permintaan CQL per detik pada setiap koneksi. Ini berarti Anda harus memastikan bahwa setiap pekerja memproses kurang dari 3.000 permintaan per detik.
Seperti halnya`INGESTRATE`, pekerja sering meledak di atas angka yang Anda tetapkan dan tidak dibatasi oleh detik jam. Oleh karena itu, untuk memperhitungkan semburan, atur parameter cqlsh Anda untuk menargetkan setiap pekerja untuk memproses 2.500 permintaan per detik. Untuk menghitung jumlah pekerjaan yang didistribusikan kepada pekerja, gunakan pedoman berikut.
+ Bagilah `INGESTRATE` dengan`NUMPROCESSES`.
+ Jika`INGESTRATE`/`NUMPROCESSES`> 2.500, turunkan `INGESTRATE` untuk membuat rumus ini benar.
```
INGESTRATE / NUMPROCESSES <= 2,500
```
Sebelum Anda mengonfigurasi pengaturan untuk mengoptimalkan unggahan data sampel kami, mari tinjau pengaturan `cqlsh` default dan lihat bagaimana penggunaannya memengaruhi proses pengunggahan data. Karena `cqlsh COPY FROM` menggunakan `CHUNKSIZE` untuk membuat potongan pekerjaan (`INSERT`pernyataan) untuk didistribusikan kepada pekerja, pekerjaan tidak secara otomatis didistribusikan secara merata. Beberapa pekerja mungkin duduk diam, tergantung pada `INGESTRATE` pengaturannya.
Untuk mendistribusikan pekerjaan secara merata di antara para pekerja dan menjaga setiap pekerja pada tingkat optimal 2.500 permintaan per detik, Anda harus mengatur `CHUNKSIZE``MAXBATCHSIZE`,, dan `INGESTRATE` dengan mengubah parameter input. Untuk mengoptimalkan pemanfaatan lalu lintas jaringan selama pemuatan data, pilih nilai `MAXBATCHSIZE` yang mendekati nilai maksimum 30. Dengan mengubah `CHUNKSIZE` ke 100 dan `MAXBATCHSIZE` ke 25, 10.000 baris tersebar merata di antara empat pekerja (10.000/2500 = 4).
Contoh kode berikut menggambarkan hal ini.
```
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
```
Untuk meringkas, gunakan rumus berikut saat mengatur `cqlsh COPY FROM` parameter:
+ **INGESTRATE** = write\$1capacity\$1units \$1 .90
+ **NUMPROCESSS** = num\$1cores -1 (default)
+ **INGESTRATE/NUMPROCESSS** = 2,500 (Ini harus menjadi pernyataan yang benar.)
+ **MAXBATCHSIZE** = 30 (Default ke 20. Amazon Keyspaces menerima batch hingga 30.)
+ **CHUNKSIZE** = (MENELAN/NUMPROCESSS)/MAXBATCHSIZE
Sekarang Anda telah menghitung`NUMPROCESSES`,,`INGESTRATE`, dan`CHUNKSIZE`, Anda siap untuk memuat data Anda.
# Langkah 5: Jalankan `cqlsh COPY FROM` perintah untuk mengunggah data dari file CSV ke tabel target
Untuk menjalankan `cqlsh COPY FROM` perintah, selesaikan langkah-langkah berikut.
1. Connect ke Amazon Keyspaces menggunakan cqlsh.
1. Pilih ruang kunci Anda dengan kode berikut.
```
USE catalog;
```
1. Tetapkan konsistensi tulis ke`LOCAL_QUORUM`. Untuk memastikan daya tahan data, Amazon Keyspaces tidak mengizinkan pengaturan konsistensi tulis lainnya. Lihat kode berikut.
```
CONSISTENCY LOCAL_QUORUM;
```
1. Siapkan `cqlsh COPY FROM` sintaks Anda menggunakan contoh kode berikut.
```
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. Jalankan pernyataan yang disiapkan pada langkah sebelumnya. cqlsh menggemakan kembali semua pengaturan yang telah Anda konfigurasi.
1. Pastikan pengaturan sesuai dengan input Anda. Lihat contoh berikut ini.
```
Reading options from the command line: {'chunksize': '120', 'header': 'true', 'ingestrate': '36000', 'numprocesses': '15', 'maxbatchsize': '20'}
Using 15 child processes
```
1. Tinjau jumlah baris yang ditransfer dan tingkat rata-rata saat ini, seperti yang ditunjukkan pada contoh berikut.
```
Processed: 57834 rows; Rate: 6561 rows/s; Avg. rate: 31751 rows/s
```
1. Ketika cqlsh selesai mengunggah data, tinjau ringkasan statistik pemuatan data (jumlah file yang dibaca, runtime, dan baris yang dilewati) seperti yang ditunjukkan pada contoh berikut.
```
15556824 rows imported from 1 files in 8 minutes and 8.321 seconds (0 skipped).
```
Pada langkah terakhir tutorial ini, Anda telah mengunggah data ke Amazon Keyspaces.
**penting**
Sekarang setelah Anda mentransfer data Anda, sesuaikan pengaturan mode kapasitas tabel target Anda agar sesuai dengan pola lalu lintas reguler aplikasi Anda. Anda dikenakan biaya pada tarif per jam untuk kapasitas yang Anda berikan sampai Anda mengubahnya.
# Pemecahan masalah
Setelah pengunggahan data selesai, periksa untuk melihat apakah baris dilewati. Untuk melakukannya, navigasikan ke direktori sumber file CSV sumber dan cari file dengan nama berikut.
```
import_yourcsvfilename.err.timestamp.csv
```
cqlsh menulis setiap baris data yang dilewati ke dalam file dengan nama itu. Jika file ada di direktori sumber Anda dan memiliki data di dalamnya, baris ini tidak diunggah ke Amazon Keyspaces. Untuk mencoba lagi baris ini, pertama-tama periksa kesalahan yang ditemui selama pengunggahan dan sesuaikan data yang sesuai. Untuk mencoba lagi baris ini, Anda dapat menjalankan kembali prosesnya.
**Kesalahan umum**
Alasan paling umum mengapa baris tidak dimuat adalah kesalahan kapasitas dan kesalahan penguraian.
**Kesalahan permintaan tidak valid saat mengunggah data ke Amazon Keyspaces**
Dalam contoh berikut, tabel sumber berisi kolom penghitung, yang menghasilkan panggilan batch yang dicatat dari perintah cqlsh`COPY`. Panggilan batch yang dicatat tidak didukung oleh Amazon Keyspaces.
```
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
```
Untuk mengatasi kesalahan ini, gunakan DSBulk untuk memigrasikan data. Untuk informasi selengkapnya, lihat [Tutorial: Memuat data ke Amazon Keyspaces menggunakan DSBulk](dsbulk-upload.md).
**Kesalahan parser saat mengunggah data ke Amazon Keyspaces**
Contoh berikut menunjukkan baris yang dilewati karena a`ParseError`.
```
Failed to import 1 rows: ParseError - Invalid ... –
```
Untuk mengatasi kesalahan ini, Anda perlu memastikan bahwa data yang akan diimpor cocok dengan skema tabel di Amazon Keyspaces. Tinjau file impor untuk kesalahan penguraian. Anda dapat mencoba menggunakan satu baris data menggunakan `INSERT` pernyataan untuk mengisolasi kesalahan.
**Kesalahan kapasitas saat mengunggah data ke 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 menggunakan `WriteTimeout` pengecualian `ReadTimeout` dan untuk menunjukkan kapan permintaan tulis gagal karena kapasitas throughput yang tidak mencukupi. Untuk membantu mendiagnosis pengecualian kapasitas yang tidak mencukupi, Amazon Keyspaces `WriteThrottleEvents` menerbitkan dan `ReadThrottledEvents` metrik di Amazon. CloudWatch Untuk informasi selengkapnya, lihat [Memantau Amazon Keyspaces dengan Amazon CloudWatch](monitoring-cloudwatch.md).
**kesalahan cqlsh saat mengunggah data ke Amazon Keyspaces**
Untuk membantu memecahkan masalah kesalahan cqlsh, jalankan kembali perintah yang gagal dengan bendera. `--debug`
Saat menggunakan versi cqlsh yang tidak kompatibel, Anda melihat kesalahan berikut.
```
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
```
Konfirmasikan bahwa versi cqlsh yang benar diinstal dengan menjalankan perintah berikut.
```
cqlsh --version
```
Anda akan melihat sesuatu seperti berikut untuk output.
```
cqlsh 5.0.1
```
Jika Anda menggunakan Windows, ganti semua instance `cqlsh` dengan`cqlsh.bat`. Misalnya, untuk memeriksa versi cqlsh di Windows, jalankan perintah berikut.
```
cqlsh.bat --version
```
Koneksi ke Amazon Keyspaces gagal setelah klien cqlsh menerima tiga kesalahan berturut-turut dari jenis apa pun dari server. Klien cqlsh gagal dengan pesan berikut.
```
Failed to import 1 rows: NoHostAvailable - , will retry later, attempt 3 of 100
```
Untuk mengatasi kesalahan ini, Anda perlu memastikan bahwa data yang akan diimpor cocok dengan skema tabel di Amazon Keyspaces. Tinjau file impor untuk kesalahan penguraian. Anda dapat mencoba menggunakan satu baris data dengan menggunakan pernyataan INSERT untuk mengisolasi kesalahan.
Klien secara otomatis mencoba membangun kembali koneksi.
# Tutorial: Memuat data ke Amazon Keyspaces menggunakan DSBulk
step-by-stepTutorial ini memandu Anda melalui migrasi data dari Apache Cassandra ke Amazon Keyspaces menggunakan Bulk Loader () DataStax yang tersedia di. DSBulk [GitHub](https://github.com/datastax/dsbulk.git) Penggunaan DSBulk berguna untuk mengunggah kumpulan data ke Amazon Keyspaces untuk tujuan akademis atau pengujian. Untuk informasi selengkapnya tentang cara memigrasikan beban kerja produksi, lihat. [Proses migrasi offline: Apache Cassandra ke Amazon Keyspaces](migrating-offline.md) Dalam tutorial ini, Anda menyelesaikan langkah-langkah berikut.
Prasyarat - Siapkan AWS akun dengan kredensyal, buat file penyimpanan kepercayaan JKS untuk sertifikat, konfigurasikan, unduh dan instal, dan konfigurasikan `cqlsh` file. DSBulk `application.conf`
1. **Buat CSV sumber dan tabel target** — Siapkan file CSV sebagai data sumber dan buat ruang kunci dan tabel target di Amazon Keyspaces.
1. **Siapkan data** — Acak data dalam file CSV dan analisis untuk menentukan ukuran baris rata-rata dan maksimum.
1. **Mengatur kapasitas throughput** — Hitung unit kapasitas tulis yang diperlukan (WCUs) berdasarkan ukuran data dan waktu muat yang diinginkan, dan konfigurasikan kapasitas yang disediakan tabel.
1. **Konfigurasi DSBulk pengaturan** — Buat file DSBulk konfigurasi dengan pengaturan seperti otentikasi, SSL/TLS, tingkat konsistensi, dan ukuran kumpulan koneksi.
1. **Jalankan perintah DSBulk load** - Jalankan perintah DSBulk load untuk mengunggah data dari file CSV ke tabel Amazon Keyspaces, dan pantau progres.
**Topics**
+ [Prasyarat: Langkah-langkah yang harus Anda selesaikan sebelum dapat mengunggah data DSBulk](dsbulk-upload-prequs.md)
+ [Langkah 1: Buat file CSV sumber dan tabel target untuk upload data menggunakan DSBulk](dsbulk-upload-source.md)
+ [Langkah 2: Siapkan data untuk diunggah menggunakan DSBulk](dsbulk-upload-prepare-data.md)
+ [Langkah 3: Atur kapasitas throughput untuk tabel target](dsbulk-upload-capacity.md)
+ [Langkah 4: Konfigurasikan `DSBulk` pengaturan untuk mengunggah data dari file CSV ke tabel target](dsbulk-upload-config.md)
+ [Langkah 5: Jalankan DSBulk `load` perintah untuk mengunggah data dari file CSV ke tabel target](dsbulk-upload-run.md)
# Prasyarat: Langkah-langkah yang harus Anda selesaikan sebelum dapat mengunggah data DSBulk
Anda harus menyelesaikan tugas-tugas berikut sebelum Anda dapat memulai tutorial ini.
1. Jika Anda belum melakukannya, daftar AWS akun dengan mengikuti langkah-langkah di[Menyiapkan AWS Identity and Access Management](accessing.md#SettingUp.IAM).
1. Buat kredensi dengan mengikuti langkah-langkah di. [Membuat dan mengonfigurasi AWS kredensional untuk Amazon Keyspaces](access.credentials.md)
1. Buat file penyimpanan kepercayaan JKS.
1. Unduh sertifikat digital berikut dan simpan file secara lokal atau di direktori home Anda.
1. AmazonRootCA1
1. AmazonRootCA2
1. AmazonRootCA3
1. AmazonRootCA4
1. Starfield Class 2 Root (opsional - untuk kompatibilitas mundur)
Untuk mengunduh sertifikat, Anda dapat menggunakan perintah berikut.
```
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
```
**catatan**
Amazon Keyspaces sebelumnya menggunakan sertifikat TLS yang ditambatkan ke Starfield Class 2 CA. AWS memigrasikan semua Wilayah AWS ke sertifikat yang dikeluarkan di bawah Amazon Trust Services (Amazon Root CAs 1-4). Selama transisi ini, konfigurasikan klien untuk mempercayai Amazon Root CAs 1-4 dan root Starfield untuk memastikan kompatibilitas di semua Wilayah.
1. Ubah sertifikat digital menjadi file TrustStore dan tambahkan ke keystore.
```
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
```
Pada langkah terakhir, Anda perlu membuat kata sandi untuk keystore dan mempercayai setiap sertifikat. Perintah interaktif terlihat seperti ini.
```
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. Siapkan koneksi shell Cassandra Query Language (cqlsh) dan konfirmasikan bahwa Anda dapat terhubung ke Amazon Keyspaces dengan mengikuti langkah-langkah di. [Menggunakan `cqlsh` untuk terhubung ke Amazon Keyspaces](programmatic.cqlsh.md)
1. Unduh dan instal DSBulk.
**catatan**
Versi yang ditampilkan dalam tutorial ini mungkin bukan versi terbaru yang tersedia. Sebelum Anda mengunduh DSBulk, periksa [halaman unduhan DataStax Bulk Loader](https://downloads.datastax.com/#bulk-loader) untuk versi terbaru, dan perbarui nomor versi dalam perintah berikut.
1. Untuk mengunduh DSBulk, Anda dapat menggunakan kode berikut.
```
curl -OL https://downloads.datastax.com/dsbulk/dsbulk-1.8.0.tar.gz
```
1. Kemudian buka paket file tar dan tambahkan DSBulk ke Anda `PATH` seperti yang ditunjukkan pada contoh berikut.
```
tar -zxvf dsbulk-1.8.0.tar.gz
# add the DSBulk directory to the path
export PATH=$PATH:./dsbulk-1.8.0/bin
```
1. Buat `application.conf` file untuk menyimpan pengaturan yang akan digunakan oleh DSBulk. Anda dapat menyimpan contoh berikut sebagai`./dsbulk_keyspaces.conf`. Ganti `localhost` dengan titik kontak cluster Cassandra lokal Anda jika Anda tidak berada di node lokal, misalnya nama DNS atau alamat IP. Perhatikan nama file dan jalur, karena Anda akan perlu menentukan ini nanti dalam `dsbulk load` perintah.
```
datastax-java-driver {
basic.contact-points = [ "localhost"]
advanced.auth-provider {
class = software.aws.mcs.auth.SigV4AuthProvider
aws-region = us-east-1
}
}
```
1. Untuk mengaktifkan dukungan SiGv4, unduh `jar` file yang diarsir dari [GitHub](https://github.com/aws/aws-sigv4-auth-cassandra-java-driver-plugin/releases/)dan letakkan di DSBulk `lib` folder seperti yang ditunjukkan pada contoh berikut.
```
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
```
# Langkah 1: Buat file CSV sumber dan tabel target untuk upload data menggunakan DSBulk
Untuk tutorial ini, kita menggunakan file nilai dipisahkan koma (CSV) dengan nama `keyspaces_sample_table.csv` sebagai file sumber untuk migrasi data. File sampel yang disediakan berisi beberapa baris data untuk tabel dengan nama`book_awards`.
1. Buat file sumber. Anda dapat memilih salah satu opsi berikut:
+ Download contoh file CSV (`keyspaces_sample_table.csv`) yang terkandung dalam file arsip berikut [samplemigration.zip](samples/samplemigration.zip). Buka zip arsip dan catat jalur ke`keyspaces_sample_table.csv`.
+ Untuk mengisi file CSV dengan data Anda sendiri yang disimpan dalam database Apache Cassandra, Anda dapat mengisi file CSV sumber dengan menggunakan `dsbulk unload` seperti yang ditunjukkan pada contoh berikut.
```
dsbulk unload -k mykeyspace -t mytable -f ./my_application.conf > keyspaces_sample_table.csv
```
Pastikan file CSV yang Anda buat memenuhi persyaratan berikut:
+ Baris pertama berisi nama kolom.
+ Nama kolom dalam file CSV sumber cocok dengan nama kolom di tabel target.
+ Data dibatasi dengan koma.
+ Semua nilai data adalah tipe data Amazon Keyspaces yang valid. Lihat [Jenis Data](cql.elements.md#cql.data-types).
1. Buat keyspace target dan tabel di Amazon Keyspaces.
1. Connect ke Amazon Keyspaces menggunakan`cqlsh`, mengganti endpoint layanan, nama pengguna, dan kata sandi dalam contoh berikut dengan nilai Anda sendiri.
```
cqlsh cassandra.us-east-1.amazonaws.com 9142 -u "111122223333" -p "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" --ssl
```
1. Buat keyspace baru dengan nama `catalog` seperti yang ditunjukkan pada contoh berikut.
```
CREATE KEYSPACE catalog WITH REPLICATION = {'class': 'SingleRegionStrategy'};
```
1. Setelah keyspace baru memiliki status yang tersedia, gunakan kode berikut untuk membuat tabel `book_awards` target. Untuk mempelajari lebih lanjut tentang pembuatan sumber daya asinkron dan cara memeriksa apakah sumber daya tersedia, lihat. [Periksa status pembuatan keyspace di 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)
);
```
Jika Apache Cassandra adalah sumber data asli Anda, cara sederhana untuk membuat tabel target Amazon Keyspaces dengan header yang cocok adalah dengan menghasilkan `CREATE TABLE` pernyataan dari tabel sumber seperti yang ditunjukkan dalam pernyataan berikut.
```
cqlsh localhost 9042 -u "username" -p "password" --execute "DESCRIBE TABLE mykeyspace.mytable;"
```
Kemudian buat tabel target di Amazon Keyspaces dengan nama kolom dan tipe data yang cocok dengan deskripsi dari tabel sumber Cassandra.
# Langkah 2: Siapkan data untuk diunggah menggunakan DSBulk
Mempersiapkan data sumber untuk transfer yang efisien adalah proses dua langkah. Pertama, Anda mengacak data. Pada langkah kedua, Anda menganalisis data untuk menentukan nilai `dsbulk` parameter yang sesuai dan pengaturan tabel yang diperlukan.
**Mengacak data**
`dsbulk`Perintah membaca dan menulis data dalam urutan yang sama seperti yang muncul di file CSV. Jika Anda menggunakan `dsbulk` perintah untuk membuat file sumber, data ditulis dalam urutan kunci yang diurutkan di CSV. Secara internal, Amazon Keyspaces mempartisi data menggunakan tombol partisi. Meskipun Amazon Keyspaces memiliki logika bawaan untuk membantu memuat permintaan keseimbangan untuk kunci partisi yang sama, memuat data lebih cepat dan lebih efisien jika Anda mengacak urutan. Ini karena Anda dapat memanfaatkan penyeimbangan beban bawaan yang terjadi saat Amazon Keyspaces menulis ke partisi yang berbeda.
Untuk menyebarkan tulisan di seluruh partisi secara merata, Anda harus mengacak data dalam file sumber. Anda dapat menulis aplikasi untuk melakukan ini atau menggunakan alat sumber terbuka, seperti [Shuf](https://en.wikipedia.org/wiki/Shuf). Shuf tersedia secara bebas di distribusi Linux, di macOS (dengan menginstal coreutils di [homebrew](https://brew.sh)), dan di Windows (dengan menggunakan Windows Subsystem for Linux (WSL)). Satu langkah tambahan diperlukan untuk mencegah baris header dengan nama kolom diacak pada langkah ini.
Untuk mengacak file sumber sambil mempertahankan header, masukkan kode berikut.
```
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 menulis ulang data ke file CSV baru bernama. `keyspace.table.csv` Anda sekarang dapat menghapus `keyspaces_sample_table.csv` file — Anda tidak lagi membutuhkannya.
**Menganalisis data**
Tentukan ukuran baris rata-rata dan maksimum dengan menganalisis data.
Anda melakukan ini karena alasan berikut:
+ Ukuran baris rata-rata membantu memperkirakan jumlah total data yang akan ditransfer.
+ Anda memerlukan ukuran baris rata-rata untuk menyediakan kapasitas tulis yang diperlukan untuk unggahan data.
+ Anda dapat memastikan bahwa setiap baris berukuran kurang dari 1 MB, yang merupakan ukuran baris maksimum di Amazon Keyspaces.
**catatan**
Kuota ini mengacu pada ukuran baris, bukan ukuran partisi. Tidak seperti partisi Apache Cassandra, partisi Amazon Keyspaces hampir tidak terikat ukurannya. Kunci partisi dan kolom pengelompokan memerlukan penyimpanan tambahan untuk metadata, yang harus Anda tambahkan ke ukuran baris mentah. Untuk informasi selengkapnya, lihat [Perkirakan ukuran baris di Amazon Keyspaces](calculating-row-size.md).
Kode berikut menggunakan [AWK](https://en.wikipedia.org/wiki/AWK) untuk menganalisis file CSV dan mencetak ukuran baris rata-rata dan maksimum.
```
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
```
Menjalankan kode ini menghasilkan output berikut.
```
using 10,000 samples:
{lines: 10000, avg: 123 bytes, max: 225 bytes}
```
Pastikan ukuran baris maksimum Anda tidak melebihi 1 MB. Jika ya, Anda harus memecah baris atau mengompres data untuk membawa ukuran baris di bawah 1 MB. Pada langkah berikutnya dari tutorial ini, Anda menggunakan ukuran baris rata-rata untuk menyediakan kapasitas tulis untuk tabel.
# Langkah 3: Atur kapasitas throughput untuk tabel target
Tutorial ini menunjukkan cara menyetel DSBulk untuk memuat data dalam rentang waktu yang ditetapkan. Karena Anda tahu berapa banyak membaca dan menulis yang Anda lakukan sebelumnya, gunakan mode kapasitas yang disediakan. Setelah Anda menyelesaikan transfer data, Anda harus mengatur mode kapasitas tabel agar sesuai dengan pola lalu lintas aplikasi Anda. Untuk mempelajari lebih lanjut tentang manajemen kapasitas, lihat[Mengelola sumber daya tanpa server di Amazon Keyspaces (untuk Apache Cassandra)](serverless_resource_management.md).
Dengan mode kapasitas yang disediakan, Anda menentukan berapa banyak kapasitas baca dan tulis yang ingin Anda berikan ke tabel Anda sebelumnya. Kapasitas tulis ditagih per jam dan diukur dalam satuan kapasitas tulis (). WCUs Setiap WCU memiliki kapasitas tulis yang cukup untuk mendukung penulisan 1 KB data per detik. Saat Anda memuat data, laju penulisan harus berada di bawah maks WCUs (parameter:`write_capacity_units`) yang ditetapkan pada tabel target.
Secara default, Anda dapat menyediakan hingga 40.000 WCUs ke tabel dan 80.000 WCUs di semua tabel di akun Anda. Jika Anda membutuhkan kapasitas tambahan, Anda dapat meminta peningkatan kuota di konsol [Service](https://console.aws.amazon.com/servicequotas/home#!/services/cassandra/quotas) Quotas. Untuk informasi lebih lanjut tentang kuota, lihat[Kuota untuk Amazon Keyspaces (untuk Apache Cassandra)](quotas.md).
**Hitung jumlah rata-rata yang WCUs diperlukan untuk sisipan**
Memasukkan 1 KB data per detik membutuhkan 1 WCU. Jika file CSV Anda memiliki 360.000 baris dan Anda ingin memuat semua data dalam 1 jam, Anda harus menulis 100 baris per detik (360.000 baris/ 60 menit/60 detik = 100 baris per detik). Jika setiap baris memiliki data hingga 1 KB, untuk menyisipkan 100 baris per detik, Anda harus menyediakan 100 WCUs ke tabel Anda. Jika setiap baris memiliki 1,5 KB data, Anda perlu dua WCUs untuk memasukkan satu baris per detik. Oleh karena itu, untuk memasukkan 100 baris per detik, Anda harus menyediakan 200 WCUs.
Untuk menentukan berapa banyak yang WCUs Anda butuhkan untuk memasukkan satu baris per detik, bagi ukuran baris rata-rata dalam byte dengan 1024 dan bulatkan ke seluruh nomor terdekat.
Misalnya, jika ukuran baris rata-rata adalah 3000 byte, Anda perlu tiga WCUs untuk memasukkan satu baris per detik.
```
ROUNDUP(3000 / 1024) = ROUNDUP(2.93) = 3 WCUs
```
**Hitung waktu dan kapasitas muat data**
Sekarang setelah Anda mengetahui ukuran rata-rata dan jumlah baris dalam file CSV Anda, Anda dapat menghitung berapa banyak yang WCUs Anda butuhkan untuk memuat data dalam jumlah waktu tertentu, dan perkiraan waktu yang diperlukan untuk memuat semua data dalam file CSV Anda menggunakan pengaturan WCU yang berbeda.
Misalnya, jika setiap baris dalam file Anda adalah 1 KB dan Anda memiliki 1.000.000 baris dalam file CSV Anda, untuk memuat data dalam 1 jam, Anda harus menyediakan setidaknya 278 WCUs ke tabel Anda selama jam itu.
```
1,000,000 rows * 1 KBs = 1,000,000 KBs
1,000,000 KBs / 3600 seconds =277.8 KBs / second = 278 WCUs
```
**Konfigurasikan pengaturan kapasitas yang disediakan**
Anda dapat mengatur pengaturan kapasitas tulis tabel saat Anda membuat tabel atau dengan menggunakan `ALTER TABLE` perintah. Berikut ini adalah sintaks untuk mengubah pengaturan kapasitas disediakan tabel dengan perintah. `ALTER TABLE`
```
ALTER TABLE catalog.book_awards WITH custom_properties={'capacity_mode':{'throughput_mode': 'PROVISIONED', 'read_capacity_units': 100, 'write_capacity_units': 278}} ;
```
Untuk referensi bahasa lengkap, lihat [CREATE TABLE](cql.ddl.table.md#cql.ddl.table.create) dan[ALTER TABLE](cql.ddl.table.md#cql.ddl.table.alter).
# Langkah 4: Konfigurasikan `DSBulk` pengaturan untuk mengunggah data dari file CSV ke tabel target
Bagian ini menguraikan langkah-langkah yang diperlukan DSBulk untuk mengonfigurasi pengunggahan data ke Amazon Keyspaces. Anda mengkonfigurasi DSBulk dengan menggunakan file konfigurasi. Anda menentukan file konfigurasi langsung dari baris perintah.
1. Buat file DSBulk konfigurasi untuk migrasi ke Amazon Keyspaces, dalam contoh ini kita menggunakan nama file. `dsbulk_keyspaces.conf` Tentukan pengaturan berikut dalam file DSBulk konfigurasi.
1. *`PlainTextAuthProvider`*— Buat penyedia otentikasi dengan `PlainTextAuthProvider` kelas. `ServiceUserName`dan `ServicePassword` harus cocok dengan nama pengguna dan kata sandi yang Anda peroleh saat Anda membuat kredensyal khusus layanan dengan mengikuti langkah-langkah di. [Buat kredensi untuk akses terprogram ke Amazon Keyspaces](programmatic.credentials.md)
1. *`local-datacenter`*— Tetapkan nilai `local-datacenter` untuk Wilayah AWS yang Anda sambungkan. Misalnya, jika aplikasi terhubung ke`cassandra.us-east-1.amazonaws.com`, maka atur pusat data lokal ke`us-east-1`. Untuk semua yang tersedia Wilayah AWS, lihat[Titik akhir layanan untuk Amazon Keyspaces](programmatic.endpoints.md). Untuk menghindari replika, atur `slow-replica-avoidance` ke`false`.
1. *`SSLEngineFactory`*— Untuk mengkonfigurasi SSL/TLS, inisialisasi `SSLEngineFactory` dengan menambahkan bagian dalam file konfigurasi dengan satu baris yang menentukan kelas dengan. `class = DefaultSslEngineFactory` Berikan jalur ke `cassandra_truststore.jks` dan kata sandi yang Anda buat sebelumnya.
1. *`consistency`*— Tetapkan tingkat konsistensi ke`LOCAL QUORUM`. Tingkat konsistensi penulisan lainnya tidak didukung, untuk informasi lebih lanjut lihat[Mendukung Apache Cassandra membaca dan menulis tingkat konsistensi dan biaya terkait](consistency.md).
1. Jumlah koneksi per pool dapat dikonfigurasi di driver Java. Untuk contoh ini, atur `advanced.connection.pool.local.size` ke 3.
Berikut ini adalah file konfigurasi sampel lengkap.
```
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. Tinjau parameter untuk DSBulk `load` perintah.
1. *`executor.maxPerSecond`*— Jumlah maksimum baris yang coba diproses oleh perintah load secara bersamaan per detik. Jika tidak disetel, pengaturan ini dinonaktifkan dengan -1.
Tetapkan `executor.maxPerSecond` berdasarkan jumlah WCUs yang Anda berikan ke tabel tujuan target. `executor.maxPerSecond``load`Perintah bukanlah batas — ini adalah rata-rata target. Ini berarti dapat (dan sering) meledak di atas angka yang Anda tetapkan. Untuk memungkinkan ledakan dan memastikan bahwa kapasitas yang cukup tersedia untuk menangani permintaan pemuatan data, atur `executor.maxPerSecond` ke 90% dari kapasitas tulis tabel.
```
executor.maxPerSecond = WCUs * .90
```
Dalam tutorial ini, kita mengatur `executor.maxPerSecond` ke 5.
**catatan**
Jika Anda menggunakan DSBulk 1.6.0 atau lebih tinggi, Anda dapat menggunakannya `dsbulk.engine.maxConcurrentQueries` sebagai gantinya.
1. Konfigurasikan parameter tambahan ini untuk DSBulk `load` perintah.
+ *`batch-mode`*— Parameter ini memberitahu sistem untuk mengelompokkan operasi dengan kunci partisi. Kami merekomendasikan untuk menonaktifkan mode batch, karena dapat menghasilkan skenario dan penyebab hot key`WriteThrottleEvents`.
+ *`driver.advanced.retry-policy-max-retries`*— Ini menentukan berapa kali untuk mencoba lagi kueri yang gagal. Jika tidak disetel, defaultnya adalah 10. Anda dapat menyesuaikan nilai ini sesuai kebutuhan.
+ *`driver.basic.request.timeout`*— Waktu dalam hitungan menit sistem menunggu kueri kembali. Jika tidak disetel, defaultnya adalah “5 menit”. Anda dapat menyesuaikan nilai ini sesuai kebutuhan.
# Langkah 5: Jalankan DSBulk `load` perintah untuk mengunggah data dari file CSV ke tabel target
Pada langkah terakhir tutorial ini, Anda mengunggah data ke Amazon Keyspaces.
Untuk menjalankan DSBulk `load` perintah, selesaikan langkah-langkah berikut.
1. Jalankan kode berikut untuk mengunggah data dari file csv Anda ke tabel Amazon Keyspaces Anda. Pastikan untuk memperbarui jalur ke file konfigurasi aplikasi yang Anda buat sebelumnya.
```
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. Outputnya mencakup lokasi file log yang merinci operasi yang berhasil dan tidak berhasil. File disimpan di direktori berikut.
```
Operation directory: /home/user_name/logs/UNLOAD_20210308-202317-801911
```
1. Entri file log akan menyertakan metrik, seperti pada contoh berikut. Periksa untuk memastikan bahwa jumlah baris konsisten dengan jumlah baris dalam file csv Anda.
```
total | failed | rows/s | p50ms | p99ms | p999ms
200 | 0 | 200 | 21.63 | 21.89 | 21.89
```
**penting**
Sekarang setelah Anda mentransfer data Anda, sesuaikan pengaturan mode kapasitas tabel target Anda agar sesuai dengan pola lalu lintas reguler aplikasi Anda. Anda dikenakan biaya pada tarif per jam untuk kapasitas yang Anda berikan sampai Anda mengubahnya. Lihat informasi yang lebih lengkap di [Konfigurasikan mode read/write kapasitas di Amazon Keyspaces](ReadWriteCapacityMode.md).