Migrasi ke DynamoDB dari basis data relasional

Migrasi basis data relasional ke DynamoDB memerlukan perencanaan yang matang untuk memastikan hasil yang sukses. Panduan ini akan membantu Anda memahami cara kerja proses ini, alat yang Anda miliki, lalu cara mengevaluasi strategi migrasi potensial dan memilih salah satu yang sesuai dengan kebutuhan Anda.

Alasan untuk bermigrasi ke DynamoDB

Migrasi ke Amazon DynamoDB menghadirkan berbagai manfaat menarik bagi bisnis dan organisasi. Berikut adalah beberapa keuntungan utama yang menjadikan DynamoDB sebagai pilihan menarik untuk migrasi basis data:

• Skalabilitas: DynamoDB dirancang untuk menangani beban kerja yang besar dan menskalakan dengan mulus untuk mengakomodasi lalu lintas dan volume data yang terus bertambah. Dengan DynamoDB, Anda dapat dengan mudah meningkatkan atau menurunkan basis data berdasarkan permintaan sehingga memastikan aplikasi Anda dapat menangani lonjakan lalu lintas secara tiba-tiba tanpa mengorbankan performa.

• Performa: DynamoDB menawarkan akses data latensi rendah sehingga 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.

• Terkelola penuh: DynamoDB adalah layanan terkelola penuh 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 nirserver: DynamoDB mendukung model nirserver, yang dikenal sebagai DynamoDB sesuai permintaan, yaitu Anda hanya membayar untuk permintaan baca dan tulis aktual yang dibuat aplikasi Anda tanpa memerlukan penyediaan kapasitas di muka. pay-per-request Model 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: Tidak seperti basis data relasional tradisional, DynamoDB mengikuti model data NoSQL, sehingga memberikan fleksibilitas dalam desain skema. Dengan DynamoDB, Anda dapat menyimpan data terstruktur, semi-terstruktur, dan tidak terstruktur, sehingga cocok untuk menangani jenis data yang beragam dan berkembang. Fleksibilitas ini memungkinkan siklus pengembangan yang lebih cepat dan adaptasi yang lebih mudah terhadap perubahan kebutuhan bisnis.

• Ketersediaan dan daya tahan tinggi: DynamoDB mereplikasi data di beberapa zona ketersediaan dalam suatu Wilayah, sehingga memastikan ketersediaan tinggi dan daya tahan data. Replikasi, failover, dan pemulihan direplikasi secara otomatis, sehingga meminimalkan risiko kehilangan data atau gangguan layanan. DynamoDB menyediakan ketersediaan SLA hingga 99,999%.

• Keamanan dan kepatuhan: DynamoDB terintegrasi dengan AWS Identity and Access Management untuk kontrol akses terperinci. Ini menyediakan enkripsi diam dan bergerak, sehingga memastikan keamanan data Anda. DynamoDB juga mematuhi berbagai standar kepatuhan, termasuk HIPAA, PCI DSS, dan GDPR, sehingga memungkinkan Anda memenuhi persyaratan peraturan.

• Integrasi dengan AWS Ekosistem: Sebagai bagian dari AWS ekosistem, DynamoDB terintegrasi secara mulus dengan layanan AWS lain, seperti,, dan. AWS Lambda AWS CloudFormation AWS AppSync Integrasi ini memungkinkan Anda membangun arsitektur nirserver, memanfaatkan infrastruktur sebagai kode, dan membuat aplikasi berbasis data waktu nyata.

Pertimbangan saat memigrasikan basis data relasional ke DynamoDB

Sistem basis data relasional dan basis data NoSQL memiliki keunggulan dan kelemahan yang berbeda. Perbedaan ini membuat desain basis data menjadi berbeda di antara kedua sistem.

	Basis data relasional	Basis data NoSQL
Mengkueri basis data	Di basis data relasional, data dapat dikueri secara fleksibel, tetapi kueri relatif mahal dan tidak dapat diskalakan dengan baik dalam situasi lalu lintas tinggi (lihat Langkah pertama untuk memodelkan data relasional di DynamoDB). Aplikasi basis data relasional dapat menerapkan logika bisnis dalam prosedur tersimpan, subkueri SQL, kueri pembaruan massal, dan kueri agregasi.	Dalam basis data NoSQL seperti DynamoDB, data dapat dikueri secara efisien dalam sejumlah cara terbatas, di luar itu kueri bisa jadi mahal dan lambat. Penulisan ke DynamoDB merupakan singleton. Logika bisnis aplikasi yang sebelumnya dijalankan dalam prosedur tersimpan harus difaktorkan ulang untuk berjalan di luar DynamoDB dalam kode khusus yang berjalan pada host seperti Amazon Amazon EC2 atau. AWS Lambda
Merancang basis data	Anda merancang untuk fleksibilitas tanpa perlu mengkhawatirkan detail penerapan atau performa. Optimasi kueri umumnya tidak memengaruhi desain skema, tetapi normalisasi itu penting.	Anda merancang skema secara spesifik untuk membuat kueri yang paling umum dan penting seefisien dan seterjangkau mungkin. Struktur data Anda disesuaikan dengan kebutuhan spesifik kasus penggunaan bisnis Anda.

Merancang untuk basis data NoSQL membutuhkan pola pikir yang berbeda dari merancang untuk sistem manajemen basis data relasional (RDBMS). Untuk RDBMS, Anda dapat membuat model data yang dinormalisasi tanpa memikirkan pola akses. Anda kemudian dapat memperluasnya nanti ketika ada pertanyaan dan persyaratan kueri baru. Anda dapat mengatur setiap jenis data ke dalam tabelnya sendiri.

Dengan desain NoSQL, Anda tidak boleh mulai merancang skema untuk DynamoDB sampai Anda mengetahui pertanyaan yang perlu dijawab. Memahami masalah bisnis dan pola baca dan tulis aplikasi sangatlah penting. Anda juga harus berusaha mempertahankan tabel sesedikit mungkin dalam aplikasi DynamoDB. Memiliki lebih sedikit tabel membuat segala sesuatunya lebih terukur, memerlukan lebih sedikit manajemen izin, dan mengurangi overhead untuk aplikasi DynamoDB Anda. Hal ini juga dapat membantu menjaga biaya pencadangan tetap rendah secara keseluruhan.

Tugas memodelkan data relasional untuk DynamoDB dan membangun versi baru aplikasi front-end merupakan topik terpisah. Panduan ini mengasumsikan Anda memiliki versi baru aplikasi yang dibuat untuk menggunakan DynamoDB, tetapi Anda masih perlu menentukan cara terbaik untuk memigrasikan dan menyinkronkan data historis selama cutover.

Pertimbangan Ukuran

Ukuran maksimum setiap item (baris) yang Anda simpan dalam tabel DynamoDB adalah 400KB. Untuk informasi selengkapnya, lihat Layanan, akun, dan tabel kuota di Amazon DynamoDB. Ukuran item ditentukan oleh ukuran total semua nama atribut dan nilai atribut dalam item. Untuk informasi selengkapnya, lihat Ukuran dan format item DynamoDB.

Jika aplikasi Anda perlu menyimpan lebih banyak data dalam item daripada batas ukuran DynamoDB yang diizinkan, pisahkan item menjadi koleksi item, kompres data item, atau simpan item sebagai objek di Amazon Simple Storage Service (Amazon S3) Simple Storage Service (Amazon S3) sambil menyimpan pengidentifikasi objek Amazon S3 di item DynamoDB Anda. Lihat Praktik terbaik untuk menyimpan atribut dan item besar. Biaya untuk memperbarui item didasarkan pada ukuran penuh item. Untuk beban kerja yang memerlukan pembaruan yang sering ke item yang ada, memiliki item kecil satu atau dua KB akan lebih murah untuk memperbarui daripada item yang lebih besar. Lihat Koleksi item - cara memodelkan one-to-many hubungan di DynamoDB untuk informasi lebih lanjut tentang koleksi item.

Saat memilih partisi dan mengurutkan atribut kunci, pengaturan tabel lainnya, ukuran dan struktur item, dan apakah akan membuat indeks sekunder, pastikan untuk meninjau dokumentasi Pemodelan DynamoDB serta panduan untuk. Mengoptimalkan biaya pada tabel DynamoDB Pastikan untuk menguji rencana migrasi Anda sehingga solusi DynamoDB Anda hemat biaya dan sesuai dengan fitur dan batasan DynamoDB.

Memahami cara kerja migrasi ke DynamoDB

Sebelum meninjau alat migrasi yang tersedia bagi kami, pertimbangkan cara penulisan diproses oleh DynamoDB.

catatan

DynamoDB otomatis memecah dan mendistribusikan data Anda ke beberapa server bersama dan lokasi penyimpanan sehingga tidak ada cara langsung untuk mengimpor set data besar secara langsung ke server produksi.

Operasi tulis default dan paling umum adalah operasi API PutItem tunggal. Anda dapat melakukan operasi PutItem dalam satu putaran untuk memproses kumpulan data. DynamoDB mendukung koneksi bersamaan yang hampir tidak terbatas, jadi dengan asumsi Anda dapat mengonfigurasi dan menjalankan rutinitas pemuatan multi-utas besar-besaran MapReduce seperti atau Spark, kecepatan penulisan hanya dibatasi oleh kapasitas tabel target (yang juga umumnya tidak terbatas).

Saat memuat data ke DynamoDB, penting untuk memahami kecepatan tulis loader Anda. Jika item (baris) yang Anda muat berukuran 1KB atau kurang, kecepatan ini hanyalah jumlah item per detik. Tabel target kemudian dapat disediakan dengan WCU (unit kapasitas tulis) yang memadai untuk menangani tingkat ini. Jika loader Anda melebihi kapasitas yang disediakan dalam detik tertentu, permintaan tambahan dapat mengalami throttling atau ditolak sama sekali. Anda dapat memeriksa throttle di CloudWatch bagan yang ditemukan di tab pemantauan konsol DynamoDB.

Operasi kedua yang dapat dilakukan adalah dengan API terkait yang disebut BatchWriteItem. BatchWriteItem memungkinkan Anda untuk menggabungkan hingga 25 permintaan tulis ke dalam satu panggilan API. Permintaan ini diterima oleh layanan dan diproses sebagai PutItem permintaan terpisah ke tabel. Saat memilihBatchWriteItem, Anda tidak akan mendapatkan keuntungan dari percobaan ulang otomatis yang disertakan dengan AWS SDK saat melakukan panggilan tunggal dengan. PutItem Jadi, jika ada kesalahan (seperti pengecualian throttling), Anda harus mencari daftar penulisan yang gagal pada panggilan respons ke BatchWriteItem. Untuk informasi selengkapnya tentang penanganan peringatan pelambatan jika ini terdeteksi di bagan CloudWatch pelambatan, lihat. Masalah pelambatan untuk DynamoDB

Jenis impor data ketiga dimungkinkan dengan fitur impor DynamoDB dari S3. Fitur ini memungkinkan Anda untuk menampilkan set data besar di Amazon S3 dan meminta DynamoDB untuk mengimpor data secara otomatis ke tabel baru. Impor ini tidak instan dan memerlukan waktu yang sebanding dengan ukuran set data. Namun, menghadirkan kemudahan karena tidak memerlukan platform ETL atau kode DynamoDB khusus untuk ditulis. Fitur impor ini memiliki batasan yang membuatnya cocok untuk migrasi saat waktu henti dapat diterima. Data dari S3 dimuat ke dalam tabel baru yang dibuat oleh impor, dan tidak tersedia untuk memuat data ke tabel yang ada. Tidak ada transformasi data, sehingga memerlukan proses hulu untuk menyiapkan dan menyimpan data dalam format akhir ke bucket S3.

Alat untuk membantu migrasi ke DynamoDB

Ada beberapa alat migrasi dan ETL umum yang dapat Anda gunakan untuk memigrasikan data ke DynamoDB.

Banyak pelanggan memilih untuk menulis skrip migrasi dan tugas mereka sendiri untuk membangun transformasi data khusus untuk proses migrasi. Jika berencana mengoperasikan tabel DynamoDB bervolume tinggi dengan lalu lintas tulis yang padat atau tugas pemuatan massal yang besar secara reguler, Anda dapat membuat alat migrasi sendiri untuk menghindari kekhawatiran dengan perilaku DynamoDB di bawah lalu lintas tulis yang padat. Skenario seperti penanganan throttle dan penyediaan tabel yang efisien dapat dialami di awal proyek saat melakukan migrasi praktik.

Amazon menyediakan sejumlah alat data yang dapat dimanfaatkan, termasuk AWS Database Migration Service (DMS), AWS Glue, Amazon EMR, dan Amazon Managed Streaming for Apache Kafka. Semua alat ini dapat digunakan untuk melakukan migrasi waktu henti, dan alat tertentu yang dapat memanfaatkan fitur Change Data Capture (CDC) basis data relasional juga dapat mendukung migrasi online. Saat memilih alat terbaik, ada baiknya mempertimbangkan keahlian dan pengalaman yang dimiliki organisasi Anda dengan setiap alat beserta fitur, performa, dan biaya masing-masing alat.

Memilih strategi yang tepat untuk migrasi ke DynamoDB

Sebuah aplikasi basis data relasional besar dapat menjangkau seratus atau lebih tabel dan mendukung beberapa fungsi aplikasi yang berbeda. Saat melakukan migrasi besar, pertimbangkan untuk memecah aplikasi Anda menjadi komponen yang lebih kecil atau layanan mikro, dan memigrasikan sekumpulan tabel kecil dalam satu waktu. Anda kemudian dapat memigrasikan komponen lainnya ke DynamoDB secara bertahap.

Saat memilih strategi migrasi, parameter tertentu dapat mengarahkan Anda ke satu solusi atau solusi lainnya. Kami dapat menyajikan opsi-opsi ini dalam pohon keputusan untuk menyederhanakan opsi yang tersedia bagi kami berdasarkan kebutuhan dan sumber daya yang tersedia. Konsep-konsep tersebut disebutkan secara singkat di sini (tetapi akan dibahas lebih mendalam nanti dalam panduan ini):

• Migrasi offline: jika aplikasi Anda dapat menoleransi beberapa waktu henti selama migrasi, hal ini akan sangat menyederhanakan proses migrasi.

• Migrasi hibrida: pendekatan ini akan memungkinkan waktu aktif parsial selama migrasi, seperti mengizinkan membaca tetapi tidak menulis, atau mengizinkan membaca dan menyisipkan tetapi tidak memperbarui dan menghapus.

• Migrasi online: aplikasi yang mengharuskan tidak adanya waktu henti selama migrasi tidak mudah dimigrasi, dan mungkin memerlukan perencanaan dan pengembangan khusus yang signifikan. Salah satu keputusan utama adalah memperkirakan dan menimbang biaya membuat proses migrasi khusus versus biaya untuk bisnis yang memiliki periode waktu henti selama cutover.

Jika	Dan				Maka
Anda boleh menghapus aplikasi selama beberapa waktu selama periode pemeliharaan untuk melakukan migrasi data. Ini adalah migrasi offline					Menggunakan AWS DMS dan melakukan migrasi offline menggunakan tugas pemuatan penuh. Bentuk data sumber terlebih dahulu dengan SQL VIEW jika diinginkan.
Anda boleh menjalankan aplikasi dalam mode hanya-baca selama migrasi. Ini adalah migrasi hibrida					Nonaktifkan penulisan di dalam aplikasi atau basis data sumber. Menggunakan AWS DMS dan melakukan migrasi offline menggunakan tugas pemuatan penuh.
Anda boleh menjalankan aplikasi dengan pembacaan dan sisipan catatan baru, tetapi tidak boleh menjalankan pembaruan atau penghapusan, selama migrasi. Ini adalah migrasi hibrida	Anda memiliki keterampilan pengembangan aplikasi dan dapat memperbarui aplikasi relasional yang ada untuk melakukan penulisan ganda termasuk ke DynamoDB, untuk semua catatan baru				Menggunakan AWS DMS dan melakukan migrasi offline menggunakan tugas pemuatan penuh. Secara bersamaan, deploy versi aplikasi yang ada yang memungkinkan pembacaan dan melakukan penulisan ganda.
Anda memerlukan migrasi dengan waktu henti minimal. Ini adalah migrasi online	Anda memigrasikan tabel sumber 1 per 1 ke DynamoDB tanpa perubahan skema besar				Gunakan AWS DMS untuk melakukan migrasi data online. Menjalankan tugas beban massal diikuti dengan tugas sinkronisasi CDC
	Anda menggabungkan tabel sumber menjadi lebih sedikit tabel DynamoDB dengan mengikuti filosofi tabel tunggal			Anda memiliki keterampilan pengembangan basis data backend dan kapasitas cadangan pada host SQL	Buat tabel siap NoSQL dalam basis data SQL. Mengisi dan menyinkronkannya menggunakan JOIN, UNION, VIEW, pemicu, prosedur tersimpan
				Anda tidak memiliki keterampilan pengembangan basis data backend dan kapasitas cadangan pada host SQL	Pertimbangkan pendekatan migrasi hibrida atau offline
	Anda boleh melewatkan migrasi data transaksi historis, atau dapat mengarsipkannya di Amazon S3 sebagai pengganti migrasi. Anda hanya perlu memigrasikan beberapa tabel statis kecil				Tulis skrip atau gunakan alat ETL apa pun untuk memigrasikan tabel. Bentuk data sumber terlebih dahulu dengan SQL VIEW jika diinginkan.

Melakukan migrasi offline ke DynamoDB

Migrasi offline cocok ketika Anda dapat mengizinkan periode waktu henti untuk melakukan migrasi. Basis data relasional biasanya membutuhkan setidaknya beberapa waktu henti setiap bulan untuk pemeliharaan dan patching, atau mungkin membutuhkan waktu henti lebih lama untuk peningkatan perangkat keras atau peningkatan rilis utama.

Amazon S3 dapat digunakan sebagai area penahapan selama migrasi. Data yang disimpan dalam CSV (nilai dipisahkan koma) atau format DynamoDB JSON dapat diimpor ke tabel DynamoDB baru secara otomatis menggunakan fitur impor DynamoDB dari S3.

Rencana

Melakukan migrasi offline menggunakan Amazon Amazon S3

Alat

• Tugas ETL untuk mengekstrak dan mengubah data SQL serta menyimpannya dalam bucket S3 seperti:

  • AWS Glue

  • Amazon EMR

  • Kode khusus Anda sendiri

• Fitur impor DynamoDB dari S3

Langkah-langkah migrasi offline:

1. Buat tugas ETL yang dapat menanyakan basis data SQL, mengubah data tabel menjadi DynamoDB JSON atau format CSV, dan menyimpannya ke bucket S3.

   

2. Fitur Impor DynamoDB dari S3 dipanggil untuk membuat tabel baru dan memuat data secara otomatis dari bucket S3 Anda.

Migrasi offline sangat sederhana dan mudah, tetapi mungkin tidak populer di kalangan pemilik aplikasi dan pengguna. Pengguna akan mendapatkan keuntungan jika aplikasi dapat memberikan tingkat layanan yang lebih rendah selama migrasi, daripada tidak memberikan layanan sama sekali.

Anda dapat menambahkan fungsionalitas untuk menonaktifkan penulisan selama migrasi offline, sambil mengizinkan pembacaan berlanjut seperti biasa. Pengguna aplikasi masih dapat menelusuri dan menanyakan data yang ada dengan aman saat data relasional sedang dimigrasikan. Jika ini yang Anda cari, lanjutkan membaca untuk mempelajari tentang migrasi hibrida.

Melakukan migrasi hibrid ke DynamoDB

Meskipun semua aplikasi basis data melakukan operasi baca dan tulis, jenis operasi tulis yang dilakukan harus dipertimbangkan saat merencanakan migrasi hibrida atau online. Penulisan basis data dapat diklasifikasikan ke dalam tiga bucket: sisipan, pembaruan, dan penghapusan. Beberapa aplikasi tidak melakukan pembaruan apa pun pada catatan yang ada. Aplikasi lain mungkin tidak mengharuskan penghapusan untuk segera diproses, dan dapat menunda penghapusan ke proses pembersihan massal di akhir bulan, misalnya. Jenis aplikasi ini bisa jadi lebih mudah untuk dimigrasi sambil memungkinkan waktu aktif parsial.

Rencana

Lakukan migrasi online/offline hibrida dengan penulisan ganda aplikasi

Alat

• Tugas ETL untuk mengekstrak dan mengubah data SQL serta menyimpannya dalam bucket S3 seperti:

  • AWS Glue

  • Amazon EMR

  • Kode khusus Anda sendiri

Langkah-langkah migrasi hibrida:

1. Buat tabel DynamoDB target. Tabel ini akan menerima data massal historis dan data langsung baru

2. Membuat versi aplikasi lama yang penghapusan dan pembaruannya dinonaktifkan saat melakukan semua penyisipan sebagai penulisan ganda ke basis data SQL dan DynamoDB

3. Memulai tugas ETL untuk memigrasikan data yang ada dan men-deploy versi aplikasi baru secara bersamaan

4. Setelah tugas ETL selesai, DynamoDB akan memiliki semua catatan yang ada dan baru, dan siap untuk cutover aplikasi

catatan

Tugas ETL menulis langsung dari SQL ke DynamoDB. Kami tidak dapat menggunakan fitur impor S3 seperti pada contoh migrasi offline, karena tabel target tidak bersifat publik dan tersedia untuk penulisan lain hingga seluruh impor selesai.

Melakukan migrasi online ke DynamoDB dengan memigrasikan setiap tabel 1:1

Banyak basis data relasional memiliki fitur yang disebut Change Data Capture (CDC), yaitu basis data memungkinkan pengguna untuk meminta daftar perubahan pada tabel yang terjadi sebelum atau setelah titik waktu tertentu. CDC menggunakan log internal untuk mengaktifkan fitur ini dan tidak mengharuskan tabel untuk memiliki kolom stempel waktu agar dapat berfungsi.

Saat memigrasikan skema tabel SQL ke basis data NoSQL, Anda mungkin ingin menggabungkan dan membentuk kembali data Anda menjadi tabel yang lebih sedikit. Melakukannya akan memungkinkan Anda mengumpulkan data di satu tempat dan menghindari keharusan untuk menggabungkan data terkait secara manual dalam operasi baca multi-langkah. Namun, pembentukan data tabel tunggal tidak selalu diperlukan dan terkadang Anda akan memigrasikan tabel 1 per 1 ke DynamoDB. Migrasi tabel 1 per 1 ini tidak terlalu rumit karena Anda dapat memanfaatkan fitur CDC basis data sumber, menggunakan alat ETL umum yang mendukung jenis migrasi ini. Data untuk setiap baris masih dapat diubah ke dalam format baru, tetapi cakupan setiap tabel tetap sama.

Pertimbangkan untuk memigrasikan tabel SQL 1 per 1 ke DynamoDB, dengan peringatan bahwa tidak ada gabungan sisi server.

Rencana

Lakukan migrasi online dari setiap tabel ke DynamoDB menggunakan AWS DMS

Alat

• AWS Database Migration Service (DMS), alat ETL yang dapat memuat data historis secara massal dan juga memanfaatkan CDC untuk menyinkronkan tabel sumber dan target

Langkah-langkah migrasi online:

1. Identifikasi tabel dalam skema sumber yang akan dimigrasikan

2. Buat jumlah tabel yang sama di DynamoDB dengan struktur kunci yang serupa

3. Buat server replikasi AWS DMS dan konfigurasikan titik akhir sumber dan target

4. Tentukan transformasi per baris yang diperlukan (seperti kolom gabungan atau konversi tanggal ke format string ISO-8601)

5. Buat tugas migrasi setiap tabel untuk Beban Penuh dan Change Data Capture

6. Pantau tugas-tugas ini sampai fase replikasi yang sedang berlangsung dimulai

7. Pada titik ini Anda dapat melakukan audit validasi, lalu mengalihkan pengguna ke aplikasi yang membaca dan menulis ke DynamoDB

Lakukan migrasi online ke DynamoDB menggunakan tabel penahapan khusus

Anda sebaiknya menggabungkan tabel untuk memanfaatkan pola akses NoSQL yang unik (misalnya, mengubah empat tabel lama menjadi satu tabel DynamoDB tunggal). Permintaan dokumen nilai kunci tunggal, atau kueri untuk kumpulan item yang dikelompokkan sebelumnya biasanya akan menghasilkan latensi yang lebih baik daripada basis data SQL yang melakukan gabungan multi-tabel. Namun, hal ini membuat tugas migrasi menjadi lebih sulit. SQL VIEW dapat melakukan pekerjaan dalam basis data sumber untuk menyiapkan satu set data yang mewakili keempat tabel dalam satu set.

Tampilan ini mungkin JOIN tabel menjadi bentuk yang didenormalisasi, atau sebaliknya, menjaga entitas tetap normal dan menumpuk tabel menggunakan SQL UNION. Keputusan penting seputar pembentukan kembali data relasional tercakup dalam video ini. Untuk migrasi offline, menggunakan tampilan untuk menggabungkan tabel adalah cara terbaik untuk membentuk data untuk skema tabel tunggal DynamoDB.

Namun, untuk migrasi online dengan data langsung dan berubah, Anda tidak dapat memanfaatkan fitur CDC karena fitur tersebut hanya didukung untuk kueri tabel tunggal, bukan dari dalam VIEW. Jika tabel Anda menyertakan kolom stempel waktu terakhir diperbarui, dan tabel tersebut digabungkan ke dalam VIEW, Anda kemudian dapat membuat tugas ETL khusus yang menggunakan tabel tersebut untuk mencapai beban massal dengan sinkronisasi.

Pendekatan baru untuk tantangan ini adalah menggunakan fitur SQL standar seperti tampilan, prosedur tersimpan, dan pemicu untuk membuat tabel SQL baru dalam format akhir DynamoDB NoSQL yang diinginkan.

Jika server basis data Anda dapat mengalokasikan sejumlah ruang penyimpanan tambahan, tabel penahapan tunggal ini dapat dibuat sebelum migrasi dimulai. Hal ini dapat dicapai dengan menulis prosedur tersimpan yang akan membaca dari tabel yang ada, mengubah data sesuai kebutuhan, dan menulis ke tabel penahapan baru. Serangkaian pemicu dapat ditambahkan untuk mereplikasi perubahan dalam tabel ke dalam tabel penahapan secara waktu nyata. Jika pemicu tidak diperbolehkan karena kebijakan perusahaan, perubahan pada prosedur tersimpan dapat mencapai hasil yang sama. Anda akan menambahkan beberapa baris kode ke prosedur apa pun yang menulis data, untuk menambahkan perubahan yang sama ke dalam tabel penahapan.

Memiliki tabel penahapan ini yang sepenuhnya disinkronkan dengan tabel aplikasi lama akan memberi Anda titik awal yang bagus untuk migrasi langsung. Alat yang menggunakan database CDC untuk menyelesaikan migrasi langsung, seperti AWS DMS, sekarang dapat digunakan terhadap tabel ini. Keuntungan dari pendekatan ini adalah penggunaan keterampilan dan fitur SQL terkenal yang tersedia di mesin basis data relasional.

Rencana

Lakukan migrasi online dengan tabel pementasan SQL menggunakan AWS DMS

Alat

• Prosedur atau pemicu tersimpan SQL khusus

• AWS Database Migration Service (DMS), alat ETL yang dapat memigrasikan tabel penahapan langsung ke DynamoDB

Langkah-langkah migrasi online:

1. Dalam mesin basis data relasional sumber, pastikan ada beberapa kapasitas pemrosesan dan ruang disk tambahan.

2. Buat tabel penahapan baru di basis data SQL, dengan stempel waktu atau fitur CDC diaktifkan

3. Tulis dan jalankan prosedur tersimpan untuk menyalin data tabel relasional yang ada ke dalam tabel penahapan

4. Deploy pemicu atau ubah prosedur yang ada untuk penulisan ganda ke tabel penahapan baru saat melakukan penulisan normal ke tabel yang ada

5. Jalankan AWS DMS untuk memigrasi dan menyinkronkan tabel sumber ini ke tabel DynamoDB target

Panduan ini menyajikan beberapa pertimbangan dan pendekatan untuk memigrasikan data basis data relasional ke DynamoDB, dengan fokus pada meminimalkan waktu henti dan menggunakan alat dan teknik basis data umum. Untuk informasi selengkapnya, lihat berikut ini:

• AWS DMS Panduan Pengguna

• AWS Glue Panduan Pengguna

• Praktik Terbaik untuk Bermigrasi dari RDBMS ke DynamoDB