Kiat Perencanaan Skema MongoDB

Salah satu fitur MongoDB yang paling banyak diiklankan adalah kemampuannya untuk menjadi "tanpa skema". Ini berarti bahwa MongoDB tidak memaksakan skema apa pun pada dokumen apa pun yang disimpan di dalam koleksi. Biasanya, MongoDB menyimpan dokumen dalam format JSON sehingga setiap dokumen dapat menyimpan berbagai macam skema/struktur. Ini bermanfaat untuk tahap awal pengembangan tetapi pada tahap selanjutnya, Anda mungkin ingin menerapkan beberapa validasi skema saat memasukkan dokumen baru untuk kinerja dan skalabilitas yang lebih baik. Singkatnya, "Tanpa skema" tidak berarti Anda tidak perlu mendesain skema Anda. Dalam artikel ini, saya akan membahas beberapa tip umum untuk merencanakan skema MongoDB Anda.

Mencari tahu desain skema terbaik yang sesuai dengan aplikasi Anda terkadang menjadi membosankan. Berikut adalah beberapa poin yang dapat Anda pertimbangkan saat merancang skema Anda.

Hindari Menumbuhkan Dokumen

Jika skema Anda memungkinkan pembuatan dokumen yang ukurannya terus bertambah maka Anda harus mengambil langkah-langkah untuk menghindari hal ini karena dapat menyebabkan penurunan kinerja DB dan IO disk. Secara default, MongoDB mengizinkan ukuran 16MB per dokumen. Jika ukuran dokumen Anda meningkat lebih dari 16 MB selama periode waktu tertentu, itu adalah tanda desain skema yang buruk. Kadang-kadang dapat menyebabkan kegagalan kueri. Anda dapat menggunakan kumpulan dokumen atau teknik pra-alokasi dokumen untuk menghindari situasi ini. Jika aplikasi Anda perlu menyimpan dokumen berukuran lebih dari 16 MB maka Anda dapat mempertimbangkan untuk menggunakan MongoDB GridFS API.

Hindari Memperbarui Seluruh Dokumen

Jika Anda mencoba memperbarui seluruh dokumen, MongoDB akan menulis ulang seluruh dokumen di tempat lain di memori. Ini dapat secara drastis menurunkan kinerja penulisan database Anda. Alih-alih memperbarui seluruh dokumen, Anda dapat menggunakan pengubah bidang untuk memperbarui hanya bidang tertentu dalam dokumen. Ini akan memicu pembaruan di tempat di memori, sehingga meningkatkan kinerja.

Cobalah untuk Menghindari Penggabungan Tingkat Aplikasi

Seperti yang kita semua tahu, MongoDB tidak mendukung gabungan tingkat server. Oleh karena itu, kita harus mendapatkan semua data dari DB dan kemudian melakukan join di level aplikasi. Jika Anda mengambil data dari beberapa koleksi dan menggabungkan sejumlah besar data, Anda harus memanggil DB beberapa kali untuk mendapatkan semua data yang diperlukan. Ini jelas akan membutuhkan lebih banyak waktu karena melibatkan jaringan. Sebagai solusi untuk skenario ini, jika aplikasi Anda sangat bergantung pada gabungan, maka skema denormalisasi lebih masuk akal. Anda dapat menggunakan dokumen yang disematkan untuk mendapatkan semua data yang diperlukan dalam satu panggilan kueri.

Gunakan Pengindeksan yang Tepat

Saat melakukan pencarian atau agregasi, seseorang sering mengurutkan data. Meskipun Anda menerapkan pengurutan pada tahap terakhir dari saluran, Anda masih memerlukan indeks untuk mencakup pengurutan. Jika indeks pada bidang penyortiran tidak tersedia, MongoDB dipaksa untuk mengurutkan tanpa indeks. Ada batas memori 32MB dari ukuran total semua dokumen yang terlibat dalam operasi sortir. Jika MongoDB mencapai batas itu maka itu dapat menghasilkan kesalahan atau mengembalikan set kosong.

Setelah membahas penambahan indeks, penting juga untuk tidak menambahkan indeks yang tidak perlu. Setiap indeks yang Anda tambahkan dalam database, Anda harus memperbarui semua indeks ini saat memperbarui dokumen dalam koleksi. Hal ini dapat menurunkan kinerja database. Selain itu, setiap indeks akan menempati beberapa ruang dan memori juga, sehingga jumlah indeks dapat menyebabkan masalah terkait penyimpanan.

Satu lagi cara untuk mengoptimalkan penggunaan indeks adalah mengganti bidang _id default. Satu-satunya tujuan bidang ini adalah menyimpan satu bidang unik per dokumen. Jika data Anda berisi stempel waktu atau bidang id apa pun, Anda dapat mengganti bidang _id dan menyimpan satu indeks tambahan.

Rasio Baca v/s Tulis

Merancang skema untuk aplikasi apa pun sangat bergantung pada apakah aplikasi itu berat baca atau tulis berat. Misalnya, jika Anda membuat dasbor untuk menampilkan data deret waktu, Anda harus mendesain skema sedemikian rupa sehingga memaksimalkan throughput penulisan. Jika aplikasi Anda berbasis E-commerce, sebagian besar operasi akan menjadi operasi baca karena sebagian besar pengguna akan menelusuri semua produk dan menelusuri berbagai katalog. Dalam kasus seperti itu, Anda harus menggunakan skema denormalisasi untuk mengurangi jumlah panggilan ke DB untuk mendapatkan data yang relevan.

Tipe Data BSON

Pastikan Anda mendefinisikan tipe data BSON untuk semua bidang dengan benar saat merancang skema. Karena ketika Anda mengubah tipe data bidang apa pun, MongoDB akan menulis ulang seluruh dokumen di ruang memori baru. Misalnya, jika Anda mencoba menyimpan (int)0 sebagai ganti bidang (float)0.0, MongoDB menulis ulang seluruh dokumen di alamat baru karena perubahan tipe data BSON.

Kesimpulan

Singkatnya, adalah bijaksana untuk merancang skema untuk Basis Data Mongo Anda karena hanya akan meningkatkan kinerja aplikasi Anda. Mulai dari versi 3.2, MongoDB mulai mendukung validasi dokumen di mana Anda dapat menentukan bidang mana yang diperlukan untuk menyisipkan dokumen baru. Dari versi 3.6, MongoDB memperkenalkan cara yang lebih elegan untuk menerapkan validasi skema menggunakan Validasi Skema JSON. Dengan menggunakan metode validasi ini, Anda dapat menerapkan pemeriksaan tipe data bersama dengan pemeriksaan bidang yang diperlukan. Anda dapat menggunakan pendekatan di atas untuk memeriksa apakah semua dokumen menggunakan jenis skema yang sama atau tidak.