Praktik Terbaik untuk Menjalankan MongoDB dalam Cluster

Menyebarkan database berkerumun adalah satu hal, tetapi bagaimana Anda mempertahankan DBM Anda saat berada di klaster bisa menjadi tugas besar untuk menyajikan aplikasi Anda secara konsisten. Seseorang harus sering memperbarui status basis data terutama metrik yang paling penting untuk mendapatkan petunjuk tentang apa yang harus ditingkatkan atau lebih tepatnya diubah sebagai cara untuk mencegah kemacetan yang mungkin muncul.

Ada banyak pertimbangan mengenai MongoDB yang harus dipertimbangkan, terutama fakta bahwa pemasangan dan pengoperasiannya adalah kemungkinan besar untuk mengabaikan praktik manajemen basis data dasar.

Seringkali, pengembang gagal memperhitungkan pertumbuhan di masa depan dan peningkatan penggunaan database yang akibatnya mengakibatkan aplikasi atau data mogok dengan beberapa masalah integritas selain tidak konsisten.

Pada artikel ini kita akan membahas beberapa praktik terbaik yang harus diterapkan untuk klaster MongoDB untuk kinerja aplikasi Anda yang efisien. Beberapa faktor yang harus dipertimbangkan termasuk...

1. Meningkatkan versi ke versi terbaru
2. Mesin penyimpanan yang sesuai
3. Alokasi sumber daya perangkat keras
4. Replikasi dan sharding
5. Jangan pernah mengubah file konfigurasi server
6. Strategi Keamanan yang Baik

Meningkatkan ke Versi Terbaru

Saya telah bekerja dengan MongoDB dari versi sebelum 3.2 dan sejujurnya, hal-hal tidak mudah saat itu. Dengan perkembangan yang luar biasa, bug yang diperbaiki, dan fitur yang baru diperkenalkan, saya akan menyarankan Anda untuk selalu mengupgrade database Anda ke versi terbaru. Misalnya, pengenalan kerangka agregasi memiliki dampak kinerja yang lebih baik daripada mengandalkan konsep Pengurangan Peta yang sudah ada. Dengan versi terbaru 4.0, seseorang kini memiliki kemampuan untuk memanfaatkan fitur transaksi multi dokumen yang umumnya meningkatkan operasi throughput. Versi terbaru juga memiliki beberapa operator konversi tipe baru tambahan seperti $toInt, $toString, $trim dan $toBool. Operator ini akan sangat membantu dalam validasi data sehingga menciptakan rasa konsistensi data. Saat memutakhirkan, harap merujuk ke dokumen sehingga Anda dapat menghindari kesalahan kecil yang dapat meningkat menjadi kesalahan.

Pilih Mesin Penyimpanan yang Sesuai

MongoDB mendukung 3 mesin penyimpanan saat ini yaitu:Mesin penyimpanan WiredTiger, In-Memory dan MMAPv1. Masing-masing mesin penyimpanan ini memiliki kelebihan dan keterbatasan dibandingkan yang lain, tetapi pilihan Anda akan bergantung pada spesifikasi aplikasi dan fungsionalitas inti mesin tersebut. Namun, saya pribadi lebih suka mesin penyimpanan WiredTiger dan saya akan merekomendasikan ini untuk orang yang tidak yakin yang mana yang akan digunakan. Mesin penyimpanan WiredTiger sangat cocok untuk sebagian besar beban kerja, menyediakan model konkurensi tingkat dokumen, pos pemeriksaan, dan kompresi.

Beberapa pertimbangan mengenai pemilihan mesin penyimpanan bergantung pada aspek ini:

1. Transaksi dan atomisitas: penyediaan data selama penyisipan atau pembaruan yang dilakukan hanya ketika semua kondisi dan tahapan dalam aplikasi telah berhasil dijalankan. Oleh karena itu, operasi digabungkan bersama dalam unit yang tidak dapat diubah. Dengan ini, transaksi multi-dokumen dapat didukung seperti yang terlihat di MongoDB versi terbaru untuk mesin penyimpanan WiredTiger.
2. Jenis penguncian: itu adalah strategi kontrol pada akses atau pembaruan informasi. Selama durasi penguncian, tidak ada operasi lain yang dapat mengubah data objek yang dipilih hingga operasi saat ini dijalankan. Akibatnya, kueri terpengaruh saat ini sehingga penting untuk memantaunya dan mengurangi sebagian besar mekanisme penguncian dengan memastikan Anda memilih mesin penyimpanan yang paling sesuai untuk data Anda.
3. Pengindeksan: Mesin penyimpanan di MongoDB menyediakan strategi pengindeksan yang berbeda tergantung pada tipe data yang Anda simpan. Efisiensi struktur data itu harus cukup bersahabat dengan beban kerja Anda dan seseorang dapat menentukan ini dengan mempertimbangkan setiap indeks tambahan sebagai memiliki beberapa overhead kinerja. Struktur data yang dioptimalkan untuk penulisan memiliki overhead yang lebih rendah untuk setiap indeks dalam lingkungan aplikasi dengan sisipan tinggi daripada struktur data yang dioptimalkan untuk non-tulis. Ini akan menjadi kemunduran besar terutama di mana sejumlah besar indeks terlibat dan pemilihan mesin penyimpanan yang tidak tepat. Oleh karena itu, memilih mesin penyimpanan yang tepat dapat memberikan dampak yang dramatis.

Alokasi Sumber Daya Perangkat Keras

Saat pengguna baru masuk ke aplikasi Anda, basis data bertambah seiring waktu dan pecahan baru akan diperkenalkan. Namun, Anda tidak dapat mengandalkan sumber daya perangkat keras yang telah Anda buat selama tahap penerapan. Akan ada peningkatan koresponden pada beban kerja dan karenanya memerlukan lebih banyak penyediaan sumber daya pemrosesan seperti CPU dan RAM untuk mendukung cluster data besar Anda. Ini sering disebut perencanaan kapasitas di MongoDB. Praktik terbaik seputar perencanaan kapasitas meliputi:

• Pantau database Anda secara konstan dan sesuaikan sesuai dengan harapan. Seperti disebutkan sebelumnya, peningkatan jumlah pengguna akan memicu lebih banyak kueri selanjutnya dengan peningkatan beban kerja yang ditetapkan terutama jika Anda menggunakan indeks. Anda mungkin mulai mengalami dampak ini pada akhir aplikasi saat mulai merekam perubahan persentase penulisan versus pembacaan seiring waktu. Oleh karena itu, Anda perlu mengkonfigurasi ulang konfigurasi perangkat keras Anda untuk mengatasi masalah ini. Gunakan alat mongoperf dan MMS untuk mendeteksi perubahan parameter kinerja sistem.
• Dokumentasikan semua persyaratan kinerja Anda di awal. Ketika Anda menghadapi masalah yang sama, Anda setidaknya akan memiliki titik referensi yang akan menghemat waktu Anda. Rekaman Anda harus melibatkan ukuran data yang ingin Anda simpan, analisis kueri dalam hal latensi dan berapa banyak data yang ingin Anda akses pada waktu tertentu. Di lingkungan produksi, Anda perlu menentukan berapa banyak permintaan yang akan Anda tangani per detik dan terakhir berapa banyak latensi yang akan Anda toleransi.
• Menampilkan Bukti Konsep. Lakukan desain skema/indeks dan pahami pola kueri, lalu sempurnakan perkiraan Anda tentang ukuran set kerja. Catat konfigurasi ini sebagai titik referensi untuk pengujian dengan revisi aplikasi yang berurutan.
• Lakukan pengujian Anda dengan beban kerja nyata. Setelah melakukan tahap konsep pembuktian, terapkan hanya setelah melakukan pengujian substansial dengan data dunia nyata dan persyaratan kinerja.

Replikasi dan Sharding

Ini adalah dua konsep utama untuk memastikan Ketersediaan data yang Tinggi dan peningkatan skalabilitas horizontal masing-masing di klaster MongoDB.

Sharding pada dasarnya mempartisi data di seluruh server menjadi bagian-bagian kecil yang dikenal sebagai pecahan. Penyeimbangan data antar pecahan dilakukan secara otomatis, pecahan dapat ditambahkan atau dihapus tanpa harus membuat database offline.

Replikasi di ujung lain mempertahankan beberapa salinan data yang berlebihan untuk ketersediaan tinggi. Ini adalah fitur bawaan di MongoDB dan bekerja di jaringan area luas tanpa memerlukan jaringan khusus. Untuk pengaturan cluster, saya sarankan Anda memiliki setidaknya 2+ mongos, 3 server konfigurasi, 1 pecahan dan memastikan konektivitas antara mesin yang terlibat dalam cluster pecahan. Gunakan nama DNS daripada IP dalam konfigurasi.

Untuk lingkungan produksi, gunakan set replika dengan setidaknya 3 anggota dan ingat untuk mengisi lebih banyak variabel konfigurasi seperti ukuran oplog.

Saat memulai instance mongod untuk anggota Anda, gunakan file kunci yang sama.

Beberapa pertimbangan shardkey Anda harus mencakup:

• Kunci dan nilai tidak dapat diubah
• Selalu pertimbangkan untuk menggunakan indeks dalam koleksi sharding
• Perintah pembaruan driver harus berisi kunci pecahan
• Batasan unik yang harus dipertahankan oleh kunci shard.
• Kunci shard tidak boleh berisi jenis indeks khusus dan tidak boleh melebihi 512 byte.

Jangan Pernah Ubah File Konfigurasi Server

Setelah melakukan penerapan pertama Anda, disarankan untuk tidak mengubah banyak parameter dalam file konfigurasi jika tidak, Anda mungkin mendapat masalah terutama dengan pecahan. Tautan terlemah dengan sharding adalah server konfigurasi. Artinya, semua instance mongod harus dijalankan agar sharding berfungsi.

Strategi Keamanan yang Baik

MongoDB telah rentan terhadap serangan eksternal dalam beberapa tahun terakhir, oleh karena itu, penting bagi database Anda untuk memiliki beberapa protokol keamanan. Selain menjalankan proses di port yang berbeda, setidaknya seseorang harus menggunakan salah satu dari 5 cara berbeda untuk mengamankan database MongoDB. Anda dapat mempertimbangkan platform seperti MongoDB Atlas yang mengamankan database secara default melalui enkripsi data baik saat transit maupun saat istirahat. Anda dapat menggunakan strategi seperti TLS/SSL untuk semua koneksi masuk dan keluar.

Kesimpulan

Kontrol cluster MongoDB bukanlah tugas yang mudah dan melibatkan banyak solusi. Basis data tumbuh sebagai hasil dari lebih banyak pengguna sehingga meningkatkan set beban kerja. Oleh karena itu, On memiliki mandat untuk memastikan kinerja DBM sejalan dengan peningkatan jumlah pengguna ini. Praktik terbaik melampaui peningkatan sumber daya perangkat keras dan menerapkan beberapa konsep MongoDB seperti sharding, replikasi, dan pengindeksan. Namun, banyak ketidaknyamanan yang mungkin timbul dapat diatasi dengan baik dengan memutakhirkan versi MongoDB Anda. Lebih sering versi terbaru memiliki bug yang diperbaiki, permintaan fitur baru terintegrasi dan hampir tidak ada dampak negatif terhadap peningkatan bahkan dengan nomor revisi besar.