Langkah-langkah pramigrasi untuk migrasi data dari MongoDB ke Azure Cosmos DB untuk MongoDB

BERLAKU UNTUK: MongoDB

Penting

Harap baca seluruh panduan ini sebelum melakukan langkah pramigrasi.

Panduan pramigrasi MongoDB ini merupakan bagian dari rangkaian migrasi MongoDB. Langkah-langkah migrasi MongoDB penting adalah pra-migrasi, migrasi, dan pascamigrasi, seperti yang ditunjukkan dalam panduan ini.

Diagram of the migration steps from pre to post migration.

Ringkasan pramigrasi

Sangat penting untuk melakukan perencanaan dan pengambilan keputusan di awal terkait migrasi Anda sebelum benar-benar memindahkan data apa pun. Proses pengambilan keputusan awal ini adalah "pra-migrasi".

Tujuan Anda dalam pra-migrasi adalah untuk:

  1. Memastikan Anda menyiapkan Azure Cosmos DB untuk memenuhi persyaratan aplikasi Anda, dan
  2. Rencanakan cara Anda menjalankan migrasi.

Ikuti langkah berikut untuk melakukan pramigrasi menyeluruh

  1. Temukan sumber daya MongoDB yang ada dan Nilai kesiapan sumber daya MongoDB yang ada untuk migrasi data
  2. Petakan sumber daya MongoDB yang ada ke sumber daya Azure Cosmos DB yang baru
  3. Rencanakan logistik proses migrasi secara end-to-end, sebelum Anda memulai migrasi data skala penuh

Kemudian, jalankan migrasi Anda sesuai dengan rencana pramigrasi.

Terakhir, lakukan langkah penting pascamigrasi cut-over dan optimasi.

Semua langkah di atas sangat penting untuk memastikan migrasi yang sukses.

Saat Anda merencanakan migrasi, kami menyarankan agar melakukannya di tingkat per sumber daya jika memungkinkan.

Penilaian pramigrasi

Langkah pra-migrasi pertama adalah menemukan sumber daya MongoDB yang ada dan menilai kesiapan sumber daya Anda untuk migrasi.

Penemuan melibatkan pembuatan daftar komprehensif sumber daya yang ada (database atau koleksi) di data estate MongoDB Anda.

Penilaian melibatkan mencari tahu apakah Anda menggunakan fitur dan sintaks yang didukung. Ini juga termasuk memastikan Anda mematuhi batas dan kuota. Tujuan dari tahap ini adalah untuk membuat daftar ketidaksesuaian dan peringatan, jika ada. Setelah Anda memiliki hasil penilaian, Anda dapat mencoba mengatasi temuan selama sisa perencanaan migrasi lainnya.

Ada 3 cara untuk menyelesaikan penilaian pra-migrasi, kami sarankan Anda menggunakan ekstensi Azure Cosmos DB Migration for MongoDB.

Ekstensi Azure Cosmos DB Migration for MongoDB

Ekstensi Azure Cosmos DB Migration for MongoDB di Azure Data Studio membantu Anda menilai beban kerja MongoDB untuk bermigrasi ke Azure Cosmos DB untuk MongoDB. Anda dapat menggunakan ekstensi ini untuk menjalankan penilaian end-to-end pada beban kerja Anda dan mengetahui tindakan yang mungkin perlu Anda ambil untuk memigrasikan beban kerja Anda dengan lancar di Azure Cosmos DB. Selama penilaian titik akhir MongoDB, ekstensi melaporkan semua sumber daya yang ditemukan.

Catatan

Kami menyarankan Anda untuk melalui fitur dan sintaks yang didukung, batas dan kuota Azure Cosmos DB secara rinci, serta melakukan bukti konsep sebelum migrasi aktual.

Penemuan manual (warisan)

Atau, Anda dapat membuat spreadsheet migrasi data estate. Tujuan spreadsheet ini adalah untuk meningkatkan produktivitas Anda dan membantu Anda merencanakan migrasi dari ujung ke ujung dan menggunakannya sebagai dokumen pelacakan sepanjang proses migrasi.

  • Lembar ini berisi daftar komprehensif sumber daya yang ada (database atau koleksi) di data estate MongoDB Anda.
  • Spreadsheet harus dibuat sebagai rekaman sumber daya data estate Anda, dalam bentuk daftar.
  • Setiap baris terkait dengan sumber daya (database atau koleksi).
  • Setiap kolom sesuai dengan properti sumber daya; mulai dengan setidaknya nama dan ukuran data (GB) sebagai kolom.
  • Saat Anda maju melalui panduan ini, Anda membuat spreadsheet ini ke dalam dokumen pelacakan untuk perencanaan migrasi menyeluruh Anda, menambahkan kolom sesuai kebutuhan.

Berikut adalah beberapa alat yang dapat digunakan untuk menemukan sumber daya:

Buka spreadsheet dan verifikasi setiap koleksi terhadap fitur dan sintaks yang didukung, serta batas dan kuota Azure Cosmos DB secara terperinci.

Utilitas Asisten Migrasi Database (warisan)

Catatan

Asisten Migrasi Database adalah utilitas warisan yang dimaksudkan untuk membantu Anda dengan langkah-langkah pra-migrasi. Kami menyarankan Anda untuk menggunakan ekstensi Azure Cosmos DB Migration for MongoDB untuk semua langkah pra-migrasi.

Anda dapat menggunakan utilitas Asisten Migrasi Database (DMA) untuk membantu Anda dengan langkah-langkah pra-migrasi.

Pemetaan pramigrasi

Dengan langkah-langkah penemuan dan penilaian selesai, Anda selesai dengan sisi MongoDB dari persamaan. Sekarang saatnya untuk merencanakan sisi Azure Cosmos DB dari persamaan. Bagaimana Anda berencana untuk menyiapkan dan mengonfigurasi sumber daya Azure Cosmos DB produksi Anda? Lakukan perencanaan pada tingkat per sumber daya - yang berarti Anda harus menambahkan kolom berikut ke spreadsheet perencanaan Anda:

  • Pemetaan Azure Cosmos DB
  • Kunci pecahan
  • Model data
  • Throughput khusus vs bersama

Detail selengkapnya tersedia di bagian berikutnya.

Perencanaan kapasitas

Mencoba melakukan perencanaan kapasitas untuk migrasi ke Azure Cosmos DB?

Pertimbangan saat menggunakan API Azure Cosmos DB untuk MongoDB

Sebelum merencanakan data estate Azure Cosmos DB Anda, pastikan untuk memahami konsep Azure Cosmos DB berikut:

  • Model kapasitas: Kapasitas database pada Azure Cosmos DB didasarkan pada model berbasis throughput. Model ini didasarkan pada Unit Permintaan per detik, yang merupakan unit yang menunjukkan jumlah operasi database yang dapat dieksekusi terhadap koleksi dengan basis per detik. Kapasitas ini dapat dialokasikan pada database atau tingkat koleksi, dan dapat disediakan pada model alokasi, atau menggunakan throughput yang disediakan skala otomatis.
  • Unit Permintaan: Setiap operasi database memiliki biaya Unit Permintaan (RU) terkait di Azure Cosmos DB. Saat dijalankan, unit permintaan dikurangi dari tingkat unit permintaan yang tersedia pada detik tertentu. Jika permintaan memerlukan lebih banyak RU daripada RU yang dialokasikan saat ini ada dua opsi untuk menyelesaikan masalah - tingkatkan jumlah RU, atau tunggu hingga detik berikutnya dimulai, lalu coba lagi operasi.
  • Kapasitas elastis: Kapasitas untuk koleksi atau database tertentu dapat berubah kapan saja. Fleksibilitas ini memungkinkan database beradaptasi secara elastis dengan persyaratan throughput beban kerja Anda.
  • Sharding otomatis: Azure Cosmos DB menyediakan sistem partisi otomatis yang hanya memerlukan pecahan (atau kunci partisi). Mekanisme partisi otomatis digunakan bersama di semua API Azure Cosmos DB dan memungkinkan data tanpa hambatan dan penskalaan throughput melalui distribusi horizontal.

Merencanakan data estate Azure Cosmos DB

Cari tahu sumber daya Azure Cosmos DB apa yang Anda buat. Proses ini memerlukan langkah melalui spreadsheet migrasi data estate Anda dan memetakan setiap sumber daya MongoDB yang ada ke sumber daya Azure Cosmos DB baru.

  • Antisipasi bahwa setiap database MongoDB menjadi database Azure Cosmos DB.
  • Antisipasi bahwa setiap koleksi MongoDB menjadi koleksi Azure Cosmos DB.
  • Pilih konvensi penamaan untuk sumber daya Azure Cosmos DB Anda. Menyimpan nama sumber daya yang sama biasanya merupakan pilihan yang baik, kecuali ada perubahan dalam struktur database dan koleksi.
  • Tentukan apakah Anda menggunakan koleksi yang dipecah atau tidak dicuci di Azure Cosmos DB. Batas koleksi yang tidak dipecah adalah 20 GB. Sharding, di sisi lain, membantu mencapai skala horizontal yang sangat penting bagi performa berbagai beban kerja.
  • Jika menggunakan koleksi pecahan, jangan asumsikan bahwa kunci shard koleksi MongoDB Anda menjadi kunci partisi kontainer Azure Cosmos DB Anda. Jangan berasumsi bahwa struktur dokumen model data MongoDB yang ada harus menjadi model yang sama dengan yang Anda gunakan di Azure Cosmos DB.
    • Kunci Shard adalah satu-satunya pengaturan terpenting untuk mengoptimalkan skalabilitas dan kinerja Azure Cosmos DB, dan pemodelan data adalah yang terpenting setelahnya. Kedua pengaturan ini tidak dapat diubah dan tidak dapat diubah setelah diatur; oleh karena itu sangat penting untuk mengoptimalkannya dalam fase perencanaan. Ikuti panduan di bagian Keputusan yang tidak dapat diubah untuk informasi selengkapnya.
  • Azure Cosmos DB tidak mengenali jenis koleksi MongoDB tertentu seperti koleksi yang dibatasi. Untuk sumber daya seperti ini, cukup buat koleksi Azure Cosmos DB biasa.
  • Azure Cosmos DB memiliki dua jenis koleksinya sendiri – throughput bersama dan khusus. Throughput bersama vs khusus adalah keputusan penting lainnya yang tidak dapat diubah, yang sangat penting untuk dibuat dalam fase perencanaan. Ikuti panduan di bagian Keputusan yang tidak dapat diubah untuk informasi selengkapnya.

Keputusan yang tidak dapat diubah

Pilihan konfigurasi Azure Cosmos DB berikut tidak dapat dimodifikasi atau dibatalkan setelah Anda membuat sumber daya Azure Cosmos DB; oleh karena itu penting untuk mendapatkan pilihan konfigurasi ini tepat selama perencanaan pra-migrasi, sebelum Anda memulai migrasi apa pun:

Biaya kepemilikan

Memperkirakan throughput

  • Di Azure Cosmos DB, throughput disediakan terlebih dahulu dan diukur dalam Request Units (RU) per detik. Tidak seperti VM atau server lokal, RU mudah untuk ditingkatkan dan diturunkan skalanya kapan saja. Anda dapat mengubah jumlah RU yang disediakan secara instan. Untuk informasi selengkapnya, lihat Unit permintaan di Azure Cosmos DB.

  • Anda dapat menggunakan kalkulator kapasitas Azure Cosmos DB untuk menentukan jumlah Unit Permintaan yang harus Anda gunakan. Jumlah ini didasarkan pada konfigurasi akun database Anda, jumlah data, ukuran dokumen, dan baca dan tulis yang diperlukan per detik.

  • Berikut ini adalah faktor kunci yang mempengaruhi jumlah RU yang diperlukan:

    • Ukuran dokumen: Seiring bertambahnya ukuran item/dokumen, jumlah RU yang digunakan untuk membaca atau menulis item/dokumen juga meningkat.

    • Jumlah properti dokumen: Jumlah RU yang digunakan untuk membuat atau memperbarui dokumen terkait dengan jumlah, kompleksitas, dan panjang propertinya. Anda dapat mengurangi konsumsi unit permintaan untuk operasi tulis dengan membatasi jumlah properti yang diindeks.

    • Pola kueri: Kompleksitas kueri memengaruhi berapa banyak unit permintaan yang digunakan kueri.

  • Cara terbaik untuk memahami biaya kueri adalah dengan menggunakan data sampel di Azure Cosmos DB, dan menjalankan kueri sampel dari MongoDB Shell menggunakan getLastRequestStastistics perintah untuk mendapatkan biaya permintaan, yang menghasilkan jumlah RU yang digunakan:

    db.runCommand({getLastRequestStatistics: 1})
    

    *Perintah ini menghasilkan dokumen JSON yang mirip dengan contoh berikut:

    {
      "_t": "GetRequestStatisticsResponse",
      "ok": 1,
      "CommandName": "find",
      "RequestCharge": 10.1,
      "RequestDurationInMilliSeconds": 7.2
    }
    
  • Anda juga dapat menggunakan pengaturan diagnostik untuk memahami frekuensi dan pola kueri yang dijalankan terhadap Azure Cosmos DB. Hasil dari log diagnostik dapat dikirim ke akun penyimpanan, instans Azure Event Hubs, atau Azure Log Analytics.

Perencanaan logistik pramigrasi

Akhirnya, sekarang Setelah Anda memiliki tampilan data estate yang ada dan desain untuk data estate Azure Cosmos DB baru, Anda siap untuk merencanakan cara menjalankan proses migrasi Anda secara end-to-end. Sekali lagi, lakukan perencanaan Anda di tingkat per sumber daya , menambahkan kolom ke spreadsheet Anda untuk mengambil dimensi logistik yang disertakan di bagian ini.

Logistik eksekusi

  • Tetapkan tanggung jawab untuk memigrasikan setiap sumber daya yang ada dari MongoDB ke Azure Cosmos DB. Cara Anda menerapkan sumber daya tim untuk menggembala migrasi Anda ke penyelesaian terserah Anda. Untuk migrasi kecil, Anda dapat meminta satu tim memulai seluruh migrasi dan memantau perkembangannya. Untuk migrasi yang lebih besar, Anda dapat menetapkan tanggung jawab kepada anggota tim per sumber daya untuk memigrasikan dan memantau sumber daya tersebut.

  • Setelah menetapkan tanggung jawab untuk memigrasikan sumber daya, sekarang Anda harus memilih alat migrasi yang tepat untuk melakukannya. Untuk migrasi kecil, Anda mungkin dapat menggunakan satu alat migrasi seperti alat asli MongoDB atau Azure DMS untuk memigrasikan semua sumber daya Anda dalam satu kali proses. Untuk migrasi yang lebih besar atau migrasi dengan persyaratan khusus, Anda sebaiknya memilih alat migrasi pada granularitas per sumber daya.

    • Sebelum Anda merencanakan alat migrasi mana yang akan digunakan, sebaiknya kenali terlebih dahulu opsi yang tersedia. Layanan Migrasi Database Azure untuk API Azure Cosmos DB for MongoDB menyediakan mekanisme yang menyederhanakan migrasi data dengan menyediakan platform hosting yang dikelola sepenuhnya, opsi pemantauan migrasi, dan penanganan pembatasan otomatis. Berikut adalah daftar lengkap opsi:

      Tipe migrasi Solusi Pertimbangan
      Online Azure Database Migration Service • Menggunakan pustaka pelaksana massal untuk Azure Cosmos DB
      • Cocok untuk himpunan data besar dan mengurus replikasi perubahan langsung
      • Hanya berfungsi dengan sumber MongoDB lainnya
      Offline Azure Database Migration Service • Menggunakan pustaka pelaksana massal untuk Azure Cosmos DB
      • Cocok untuk himpunan data besar dan mengurus replikasi perubahan langsung
      • Hanya berfungsi dengan sumber MongoDB lainnya
      Offline Azure Data Factory • Menggunakan pustaka pelaksana massal untuk Azure Cosmos DB
      • Cocok untuk himpunan data besar
      • Mudah diatur dan mendukung beberapa sumber
      • Kurangnya titik pemeriksaan berarti bahwa masalah apa pun selama migrasi akan memerlukan hidupkan ulang seluruh proses migrasi
      • Kurangnya antrean surat mati berarti bahwa beberapa file yang salah dapat menghentikan seluruh proses migrasi
      • Perlu kode kustom untuk meningkatkan throughput baca untuk sumber data tertentu
      Offline Alat Mongo yang Ada (mongodump, mongorestore, Studio3T) • Mudah diatur dan integrasi
      • Perlu penanganan kustom untuk pembatasan
      Offline/online Azure Databricks dan Spark • Kontrol penuh laju migrasi dan transformasi data
      • Memerlukan pengkodean khusus
    • Jika sumber daya Anda dapat mentolerir migrasi offline, gunakan diagram ini untuk memilih alat migrasi yang sesuai:

      Diagram of using offline migration tools based on the size of the tool.

    • Jika sumber daya Anda memerlukan migrasi online, gunakan diagram ini untuk memilih alat migrasi yang sesuai:

      Diagram of using online migration tools based on preference for turnkey or custom solutions.

    • Tonton gambaran umum dan demo video solusi migrasi.

  • Setelah Anda memilih alat migrasi untuk setiap sumber daya, langkah selanjutnya adalah memprioritaskan sumber daya yang akan Anda migrasikan. Prioritas yang baik dapat membantu menjaga migrasi Anda sesuai jadwal. Praktik yang baik adalah memprioritaskan migrasi sumber daya tersebut, yang membutuhkan waktu paling lama untuk dipindahkan; memigrasikan sumber daya ini terlebih dahulu membawa kemajuan terbesar menuju penyelesaian. Selain itu, karena migrasi yang memakan waktu ini biasanya melibatkan lebih banyak data, mereka lebih intensif sumber daya untuk alat migrasi dan oleh karena itu lebih cenderung mengekspos masalah dengan alur migrasi Anda sejak dini. Praktik ini meminimalkan kemungkinan jadwal Anda tergelincir karena kesulitan dengan alur migrasi Anda.

  • Rencanakan bagaimana Anda memantau kemajuan migrasi setelah dimulai. Jika Anda mengoordinasikan upaya migrasi data di antara tim, rencanakan irama reguler sinkronisasi tim juga, sehingga Anda memiliki pandangan komprehensif tentang bagaimana migrasi berprioritas tinggi berlangsung.

Skenario migrasi yang didukung

Pilihan terbaik alat migrasi MongoDB bergantung pada skenario migrasi Anda.

Jenis migrasi

Berikut adalah daftar alat yang kompatibel untuk setiap skenario migrasi:

Sumber Tujuan Rekomendasi proses
• Kluster lokal MongoDB
• MongoDB pada kluster IaaS VM
• Kluster MongoDB Atlas - Offline
Azure Cosmos DB Mongo API • <Data 10 GB: Alat asli MongoDB
• <Data 1 TB: Azure DMS
• > Data 1 TB: Spark
• Kluster lokal MongoDB
• MongoDB pada kluster IaaS VM
• Kluster MongoDB Atlas - Online
Azure Cosmos DB Mongo API • <Data 1 TB: Azure DMS
• >Data 1 TB: Spark + Mongo Changestream
• Perlu mengubah skema selama migrasi
Membutuhkan lebih banyak fleksibilitas daripada alat yang disebutkan di atas
Azure Cosmos DB Mongo API • ADF lebih fleksibel daripada DMS, mendukung modifikasi skema selama migrasi dan mendukung kombinasi sumber/tujuan terbanyak
• DMS lebih baik dalam hal skala (mis. migrasi yang lebih cepat)
• File JSON Azure Cosmos DB Mongo API • Alat asli MongoDB khususnya mongoimport
• File CSV Azure Cosmos DB Mongo API • Alat asli MongoDB khususnya mongoimport
• File BSON Azure Cosmos DB Mongo API • Alat asli MongoDB khususnya mongorestore

Dukungan peralatan untuk versi MongoDB

Mengingat Bahwa Anda bermigrasi dari versi MongoDB tertentu, alat yang didukung untuk setiap versi disertakan di sini:

Versi sumber MongoDB Versi tujuan Azure Cosmos DB untuk MongoDB Alat yang didukung Alat yang tidak didukung
<2.x, >4.0 3.2, 3.6, 4.0 Alat asli MongoDB, Spark DMS, ADF
3.2, 3.6, 4.0 3.2, 3.6, 4.0 Alat asli MongoDB, DMS, ADF, Spark Tidak ada

Pasca-migrasi

Dalam fase pra-migrasi, luangkan waktu untuk merencanakan langkah-langkah apa yang Anda ambil terhadap migrasi aplikasi dan pengoptimalan pascamigrasi.

  • Dalam fase pascamigrasi, Anda menjalankan cutover aplikasi untuk menggunakan Azure Cosmos DB alih-alih data estate MongoDB yang ada.
  • Lakukan upaya terbaik Anda untuk merencanakan pengindeksan, distribusi global, konsistensi, dan properti Azure Cosmos DB lainnya yang dapat diubah pada tingkat per sumber daya. Namun, pengaturan konfigurasi Azure Cosmos DB ini dapat dimodifikasi nanti, jadi harap lakukan penyesuaian pada pengaturan ini nanti. Anda menerapkan konfigurasi yang dapat diubah ini pascamigrasi.
  • Untuk panduan pasca migrasi, lihat Langkah pengoptimalan pasca migrasi saat menggunakan API Azure Cosmos DB untuk MongoDB.

Langkah berikutnya