Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
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.
Topik
- Alasan untuk bermigrasi ke DynamoDB
- Pertimbangan saat memigrasikan basis data relasional ke DynamoDB
- Memahami cara kerja migrasi ke DynamoDB
- Alat untuk membantu migrasi ke DynamoDB
- Memilih strategi yang tepat untuk migrasi ke DynamoDB
- Melakukan migrasi offline ke DynamoDB
- Melakukan migrasi hibrid ke DynamoDB
- Melakukan migrasi online ke DynamoDB dengan memigrasikan setiap tabel 1:1
- Lakukan migrasi online ke DynamoDB menggunakan tabel penahapan khusus
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.
-
Dikelola sepenuhnya: DynamoDB adalah layanan yang dikelola sepenuhnya yang disediakan oleh AWS. Ini berarti bahwa 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.
-
Tidak ada SQL fleksibilitas: Tidak seperti database relasional tradisional, DynamoDB mengikuti model No SQL data, 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 SLA ketersediaan hingga 99,999%.
-
Keamanan dan kepatuhan: DynamoDB terintegrasi dengan AWS Identity and Access Management untuk kontrol akses berbutir halus. Ini menyediakan enkripsi diam dan bergerak, sehingga memastikan keamanan data Anda. DynamoDB juga mematuhi berbagai standar kepatuhan, HIPAA termasuk,, GDPR dan PCIDSS, memungkinkan Anda memenuhi persyaratan peraturan.
-
Integrasi dengan AWS Ekosistem: Sebagai bagian dari AWS ekosistem, DynamoDB mulus terintegrasi dengan yang lain AWS layanan, seperti AWS Lambda, AWS CloudFormation, dan AWS AppSync. Integrasi ini memungkinkan Anda untuk membangun arsitektur tanpa server, memanfaatkan infrastruktur sebagai kode, dan membuat aplikasi berbasis data real-time.
Pertimbangan saat memigrasikan basis data relasional ke DynamoDB
Sistem database relasional dan Tidak ada SQL database yang memiliki kekuatan dan kelemahan yang berbeda. Perbedaan ini membuat desain basis data menjadi berbeda di antara kedua sistem.
| Jenis tugas | Basis data relasional | Tidak ada SQL database |
|---|---|---|
| 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 database relasional dapat menerapkan logika bisnis dalam prosedur tersimpan, SQL subquery, kueri pembaruan massal, dan kueri agregasi. | Dalam SQL database No seperti DynamoDB, data dapat ditanyakan secara efisien dalam sejumlah cara, di luar mana kueri bisa 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 atau EC2 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 Tidak ada SQL database memerlukan pola pikir yang berbeda dari merancang untuk sistem manajemen basis data relasional ()RDBMS. Untuk ituRDBMS, 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.
Tanpa SQL desain, Anda dapat mendesain skema Anda untuk DynamoDB ketika 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 item dan atribut besar di DynamoDB. 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.
Operasi tulis default dan paling umum adalah PutItemAPIoperasi 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 cukup WCU (unit kapasitas tulis) 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 panggilan terkait BatchWriteItem. BatchWriteItemmemungkinkan Anda untuk menggabungkan hingga 25 permintaan tulis menjadi satu API panggilan. Permintaan ini diterima oleh layanan dan diproses sebagai PutItem permintaan terpisah ke tabel. Saat ini, saat memilihBatchWriteItem, Anda tidak akan mendapatkan keuntungan dari percobaan ulang otomatis yang disertakan dengan AWS SDKsaat 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 S3PutItem, ini memerlukan proses hulu dan menulis data dalam format yang Anda pilih ke bucket Amazon S3.
Alat untuk membantu migrasi ke DynamoDB
Ada beberapa migrasi umum dan ETL alat yang dapat Anda gunakan untuk memigrasikan data ke DynamoDB.
Amazon menyediakan sejumlah alat data yang dapat digunakan dalam migrasi, termasuk AWS Database Migration Service (DMS), AWS Glue, Amazon EMR, dan Amazon Managed Streaming untuk Apache Kafka. Semua alat ini dapat digunakan untuk melakukan migrasi downtime, dan mereka dapat memanfaatkan database relasional Change Data Capture (CDC) fitur untuk mendukung migrasi online. Saat memilih alat, akan membantu untuk mempertimbangkan keahlian dan pengalaman yang dimiliki organisasi Anda dengan setiap alat bersama dengan fitur, kinerja, dan biaya masing-masing alat.
Banyak pelanggan memilih untuk menulis skrip migrasi dan tugas mereka sendiri untuk membangun transformasi data khusus untuk proses migrasi. Jika Anda berencana untuk mengoperasikan tabel DynamoDB volume tinggi dengan lalu lintas tulis yang padat atau pekerjaan beban massal besar biasa, Anda mungkin ingin menulis kode migrasi sendiri untuk lebih terbiasa 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.
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, berbagai faktor dapat mengarahkan Anda ke satu solusi atau 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 mentolerir beberapa waktu henti selama migrasi, itu akan menyederhanakan proses migrasi.
-
Migrasi hibrid: pendekatan ini memungkinkan uptime sebagian selama migrasi, seperti mengizinkan pembacaan tetapi tidak menulis, atau mengizinkan pembacaan dan penyisipan tetapi tidak memperbarui dan menghapus.
-
Migrasi online: aplikasi yang tidak memerlukan waktu henti selama migrasi tidak mudah dimigrasi, dan dapat memerlukan perencanaan dan pengembangan khusus yang signifikan. Salah satu keputusan utama adalah memperkirakan dan menimbang biaya membangun proses migrasi khusus versus biaya untuk bisnis yang memiliki jendela downtime selama pemotongan.
| Jika | Dan | Maka |
|---|---|---|
| Anda baik-baik saja untuk menghapus aplikasi selama beberapa waktu selama jendela pemeliharaan untuk melakukan migrasi data. Ini adalah migrasi offline. |
Gunakan AWS DMS dan melakukan migrasi offline menggunakan tugas pemuatan penuh. Pra-bentuk data sumber dengan SQL |
|
| Anda boleh menjalankan aplikasi dalam mode hanya-baca selama migrasi. Ini adalah migrasi hibrida. | Nonaktifkan penulisan di dalam aplikasi atau basis data sumber. Gunakan AWS DMS dan melakukan migrasi offline menggunakan tugas pemuatan penuh. | |
| Anda boleh menjalankan aplikasi dengan pembacaan dan sisipan catatan baru, tetapi tidak ada 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 | Gunakan 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. |
|
Gunakan AWS DMS untuk melakukan migrasi data online. Jalankan tugas pemuatan massal diikuti dengan tugas CDC sinkronisasi. |
| Anda memerlukan migrasi dengan waktu henti minimal. Ini adalah migrasi online. |
|
Buat tabel No SQL -ready dalam SQL database. Mengisi dan menyinkronkannya menggunakanJOINs,,UNIONs, pemicuVIEWs, prosedur tersimpan. |
| Anda memerlukan migrasi dengan waktu henti minimal. Ini adalah migrasi online. |
|
Pertimbangkan pendekatan migrasi hybrid atau offline. |
| Anda memerlukan migrasi dengan waktu henti minimal. Ini adalah migrasi online. | Anda boleh melewatkan migrasi data transaksi historis, atau dapat mengarsipkannya di Amazon S3 sebagai pengganti memigrasinya. Anda hanya perlu memigrasikan beberapa tabel statis kecil. | Tulis skrip atau gunakan ETL alat apa pun untuk memigrasikan tabel. Pra-bentuk data sumber 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 dapat secara otomatis diimpor ke tabel JSON DynamoDB baru menggunakan DynamoDB impor dari fitur S3.
Anda mungkin ingin menggabungkan tabel untuk memanfaatkan pola No SQL access yang unik (misalnya, mengubah empat tabel lama menjadi tabel DynamoDB tunggal). Permintaan dokumen nilai kunci tunggal atau kueri untuk koleksi item yang dikelompokkan sebelumnya biasanya kembali dengan latensi yang lebih baik daripada SQL database yang melakukan gabungan multi-tabel. Namun, ini membuat tugas migrasi lebih sulit. SQLTampilan dapat melakukan pekerjaan dalam database sumber untuk menyiapkan satu kumpulan data yang mewakili keempat tabel dalam satu set.
Tampilan ini dapat membuat JOIN tabel ke dalam bentuk denormalisasi, atau dapat menjaga entitas dinormalisasi dan menumpuk tabel menggunakan file. SQL UNION Keputusan penting seputar pembentukan kembali data relasional tercakup dalam video ini
Rencana
Lakukan migrasi offline menggunakan Amazon S3
Alat
-
ETLPekerjaan untuk mengekstrak dan mengubah SQL data dan menyimpannya dalam ember S3 seperti:
-
AWS Database Migration Service, layanan yang dapat memuat data historis secara massal dan juga dapat memproses catatan Change Data Capture (CDC) untuk menyinkronkan tabel sumber dan target.
-
AWS Glue
-
Amazon EMR
-
Kode khusus Anda sendiri
-
-
Fitur impor DynamoDB dari S3
Langkah-langkah migrasi offline:
-
Buat ETL pekerjaan yang dapat menanyakan SQL database, mengubah data tabel menjadi JSON DynamoDB CSV atau format, dan menyimpannya ke bucket S3.
-
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 mungkin tidak memerlukan pemrosesan penghapusan segera. Aplikasi ini dapat menunda penghapusan ke proses pembersihan massal pada 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
-
ETLPekerjaan untuk mengekstrak dan mengubah SQL data dan menyimpannya dalam ember S3 seperti:
-
AWS DMS
-
AWS Glue
-
Amazon EMR
-
Kode khusus Anda sendiri
-
Langkah-langkah migrasi hibrida:
-
Buat tabel DynamoDB target. Tabel ini akan menerima data massal historis dan data langsung baru
-
Buat versi aplikasi lama yang menghapus dan pembaruan dinonaktifkan saat melakukan semua sisipan sebagai penulisan ganda ke database dan DynamoDB SQL
-
Memulai ETL pekerjaan atau AWS DMS tugas untuk mengisi kembali data yang ada dan menyebarkan versi aplikasi baru secara bersamaan
-
Ketika pekerjaan pengurukan selesai, DynamoDB akan memiliki semua catatan yang ada dan baru dan siap untuk pemotongan aplikasi
catatan
Pekerjaan backfill menulis langsung dari SQL DynamoDB. Kami tidak dapat menggunakan fitur impor S3 seperti pada contoh migrasi offline, karena fitur itu membuat tabel baru yang tidak akan hidup sampai setelah DynamoDB memuat data.
Melakukan migrasi online ke DynamoDB dengan memigrasikan setiap tabel 1:1
Banyak database relasional memiliki fitur yang disebut Change Data Capture (CDC), di mana database memungkinkan pengguna untuk meminta daftar perubahan pada tabel yang terjadi sebelum atau setelah titik waktu tertentu. CDCmenggunakan log internal untuk mengaktifkan fitur ini dan tidak memerlukan tabel untuk memiliki kolom stempel waktu untuk berfungsi.
Saat memigrasikan skema SQL tabel ke SQL database No, 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-ke-1 ini tidak terlalu rumit karena Anda dapat memanfaatkan CDC fitur basis data sumber, menggunakan ETL alat 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 SQL tabel 1-ke-1 ke DynamoDB, dengan peringatan bahwa DynamoDB tidak mendukung gabungan sisi server. Anda harus menambahkan logika ke aplikasi Anda untuk menggabungkan data dari beberapa tabel.
Rencana
Lakukan migrasi online dari setiap tabel ke DynamoDB menggunakan AWS DMS
Alat
Langkah-langkah migrasi online:
-
Identifikasi tabel dalam skema sumber yang akan dimigrasikan
-
Buat jumlah tabel yang sama di DynamoDB dengan struktur kunci yang sama seperti di sumber
-
Buat server replikasi di AWS DMS dan konfigurasikan titik akhir sumber dan target
-
Tentukan setiap transformasi per baris yang diperlukan (seperti kolom gabungan atau konversi tanggal ke format string -8601) ISO
-
Buat tugas migrasi setiap tabel untuk Beban Penuh dan Change Data Capture
-
Pantau tugas-tugas ini sampai fase replikasi yang sedang berlangsung dimulai
-
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
Seperti dalam skenario migrasi offline di atas, Anda dapat memilih untuk menggabungkan tabel untuk memanfaatkan pola No SQL access yang unik (misalnya, mengubah empat tabel lama menjadi satu tabel DynamoDB tunggal). A SQL VIEW dapat melakukan pekerjaan dalam database sumber untuk menyiapkan satu kumpulan data yang mewakili keempat tabel dalam satu set.
Namun, untuk migrasi online dengan data langsung yang berubah, Anda tidak dapat memanfaatkan CDC fitur karena tidak didukung untuk VIEW s. Jika tabel Anda menyertakan kolom stempel waktu yang diperbarui terakhir, dan ini dimasukkan ke dalamVIEW, Anda kemudian dapat membuat ETL pekerjaan khusus yang menggunakan ini untuk mencapai beban massal dengan sinkronisasi.
Pendekatan baru untuk tantangan ini adalah dengan menggunakan SQL fitur standar seperti tampilan, prosedur tersimpan, dan pemicu untuk membuat SQL tabel baru yang ada dalam format SQL DynamoDB No yang diinginkan akhir.
Jika server database Anda memiliki kapasitas cadangan, Anda dapat membuat tabel pementasan tunggal ini sebelum migrasi dimulai. Anda akan melakukan ini dengan menulis prosedur tersimpan yang akan membaca dari tabel yang ada, mengubah data sesuai kebutuhan, dan menulis ke tabel pementasan baru. Anda dapat menambahkan satu set pemicu untuk mereplikasi perubahan dalam tabel ke dalam tabel pementasan secara real time. 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 untuk melawan tabel ini. Keuntungan dari pendekatan ini adalah menggunakan SQL keterampilan dan fitur terkenal yang tersedia di mesin database relasional.
Rencana
Lakukan migrasi online dengan tabel SQL pementasan menggunakan AWS DMS
Alat
-
Prosedur atau pemicu yang SQL disimpan khusus
Langkah-langkah migrasi online:
-
Dalam mesin basis data relasional sumber, pastikan ada beberapa kapasitas pemrosesan dan ruang disk tambahan.
-
Buat tabel pementasan baru dalam SQL database, dengan stempel waktu atau fitur diaktifkan CDC
-
Tulis dan jalankan prosedur tersimpan untuk menyalin data tabel relasional yang ada ke dalam tabel penahapan
-
Deploy pemicu atau ubah prosedur yang ada untuk penulisan ganda ke tabel penahapan baru saat melakukan penulisan normal ke tabel yang ada
-
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:
