Mengoptimalkan performa penulisan di Azure Cosmos DB for MongoDB

  • Berlaku untuk: ✅ MongoDB

BERLAKU UNTUK: MongoDB

Important

Apakah Anda ingin memigrasikan aplikasi MongoDB yang sudah ada atau menggunakan fitur MongoDB Query Language (MQL)? Pertimbangkan Azure DocumentDB.

Apakah Anda mencari solusi database untuk skenario skala tinggi dengan perjanjian tingkat layanan ketersediaan (SLA) 99,999%, skala otomatis instan, dan failover otomatis di beberapa wilayah? Pertimbangkan Azure Cosmos DB untuk NoSQL.

Mengoptimalkan performa tulis membantu Anda memaksimalkan Azure Cosmos DB untuk skala tak terbatas MongoDB. Tidak seperti layanan MongoDB terkelola lainnya, API MongoDB secara otomatis dan transparan memecah koleksi Anda (ketika menggunakan koleksi yang terpecah) untuk penskalaan tanpa batas.

Cara Anda menulis data perlu memperhatikan hal ini dengan menggunakan metode paralelisasi dan menyebarkan data di seluruh shard untuk memaksimalkan jumlah penulisan pada database dan koleksi Anda. Artikel ini menjelaskan praktik terbaik untuk mengoptimalkan performa penulisan.

Sebarkan beban di seluruh partisi Anda

Saat menulis data ke API yang terpecah untuk kumpulan MongoDB, data Anda dipecah menjadi irisan kecil dan ditulis ke setiap pecahan berdasarkan nilai bidang kunci pecahan Anda. Anda dapat menganggap setiap irisan sebagai bagian kecil dari mesin virtual yang hanya menyimpan dokumen yang berisi satu nilai kunci pecahan yang unik.

Jika aplikasi Anda menulis sejumlah besar data ke satu pecahan, ini tidak akan efisien karena aplikasi akan memaksimalkan throughput hanya satu pecahan alih-alih menyebarkan beban di semua pecahan Anda. Beban tulis Anda tersebar merata di koleksi Anda dengan menulis secara paralel dengan banyak dokumen dengan nilai kunci shard yang unik.

Salah satu contohnya adalah aplikasi katalog produk yang dipartisi pada field kategori. Daripada menulis ke satu kategori (pecahan) secara satu per satu, lebih baik menulis ke semua kategori secara bersamaan untuk mencapai throughput tulis yang maksimum.

Mengurangi jumlah indeks

Pengindeksan adalah fitur yang bagus untuk mengurangi waktu yang diperlukan untuk mengkueri data Anda secara drastis. Untuk pengalaman kueri yang paling fleksibel, API untuk MongoDB memungkinkan penggunaan indeks wildcard pada data Anda secara default untuk mempercepat kueri terhadap semua bidang. Namun, semua indeks, yang mencakup indeks wildcard memperkenalkan beban tambahan saat menulis data karena penulisan mengubah koleksi dan indeks.

Mengurangi jumlah indeks hanya untuk indeks yang Anda butuhkan untuk mendukung kueri Anda membuat penulisan Anda lebih cepat dan lebih murah. Sebagai aturan umum, rekomendasi berikut berlaku:

  • Bidang apa pun yang Anda filter harus memiliki indeks bidang tunggal yang sesuai untuknya. Opsi ini juga memungkinkan pemfilteran multi-bidang.
  • Setiap kelompok bidang yang Anda urutkan harus memiliki indeks komposit untuk grup tersebut.

Set diperintahkan untuk salah pada driver MongoDB

Secara default, driver MongoDB mengatur opsi yang dipesan menjadi "benar" saat menulis data, yang menulis setiap dokumen dalam urutan satu per satu. Opsi ini mengurangi performa tulis karena setiap permintaan tulis harus menunggu yang sebelumnya selesai. Saat menulis data, atur opsi ini ke salah untuk meningkatkan performa.

db.collection.insertMany(
   [ <doc1> , <doc2>, ... ],
   {
      ordered: false
   }
)

Atur untuk ukuran batch optimal dan jumlah thread

Paralelisasi operasi penulisan data di banyak utas/proses adalah kunci untuk meningkatkan skala penulisan data. API untuk MongoDB menerima penulisan dalam batch hingga 1.000 dokumen untuk setiap proses/utas.

Jika Anda menulis lebih dari 1.000 dokumen sekaligus per proses/utas, fungsi klien seperti insertMany() harus dibatasi hingga sekitar 1.000 dokumen. Jika tidak demikian, klien menunggu setiap batch untuk dikomit sebelum melanjutkan ke batch berikutnya. Dalam beberapa kasus, memisahkan kelompok dengan jumlah yang kurang dari atau sedikit lebih dari 1.000 dokumen lebih cepat.

Langkah berikutnya

  • Last updated on