Setelah mengembangkan aplikasi dan model database Anda (ketika tiba waktunya untuk memindahkan lingkungan ke produksi) ada beberapa hal yang perlu dilakukan terlebih dahulu. Seringkali pengembang gagal mempertimbangkan langkah-langkah penting MongoDB tambahan sebelum menerapkan database ke dalam produksi. Akibatnya, dalam mode produksi mereka akhirnya menghadapi kemunduran mendasar yang tidak disajikan dalam mode pengembangan. Kadang-kadang mungkin terlambat atau lebih tepatnya banyak data akan hilang jika terjadi bencana. Selain itu, beberapa langkah yang dibahas di sini akan memungkinkan seseorang untuk mengukur kesehatan database dan karenanya merencanakan tindakan yang diperlukan sebelum bencana terjadi.
Gunakan Versi Saat Ini dan Driver Terbaru
Umumnya, versi terbaru dalam teknologi apa pun hadir dengan fitur yang ditingkatkan sehubungan dengan fungsionalitas yang mendasarinya daripada pendahulunya. Versi terbaru MongoDB lebih tangguh dan lebih baik daripada pendahulunya dalam hal kinerja, skalabilitas, dan kapasitas memori. Hal yang sama berlaku untuk driver terkait karena driver tersebut dikembangkan oleh engineer database inti dan diperbarui lebih sering daripada database itu sendiri.
Ekstensi asli yang dipasang untuk bahasa Anda dapat dengan mudah meletakkan platform untuk prosedur cepat dan standar untuk menguji, menyetujui, dan meningkatkan versi driver baru. Ada juga perangkat lunak otomotif seperti Ansible, Puppet, SaltStack, dan Chef yang dapat digunakan untuk meningkatkan MongoDB dengan mudah di semua node Anda tanpa menimbulkan biaya dan waktu profesional.
Pertimbangkan juga untuk menggunakan mesin penyimpanan WiredTiger karena ini adalah yang paling berkembang dengan fitur modern yang sesuai dengan harapan basis data modern
Berlangganan ke milis MongoDB untuk mendapatkan informasi terbaru sehubungan dengan perubahan pada versi &driver baru dan perbaikan bug sehingga terus diperbarui.
Gunakan Sistem 64-bit untuk Menjalankan MongoDB
Dalam sistem 32-bit, proses MongoDB dibatasi hingga sekitar 2,5 GB data karena database menggunakan file yang dipetakan memori untuk performa. Ini menjadi batasan untuk proses yang mungkin melampaui batas yang mengarah ke naksir. Dampak utamanya adalah:jika terjadi kesalahan, Anda tidak akan dapat memulai ulang server hingga Anda menghapus data atau memigrasikan database ke sistem yang lebih tinggi seperti 64-bit sehingga waktu henti yang lebih tinggi untuk aplikasi Anda.
Jika Anda harus tetap menggunakan sistem 32-bit, pengkodean Anda harus sangat sederhana untuk mengurangi jumlah bug dan latensi untuk operasi throughput.
Namun untuk kerumitan kode seperti pipa agregasi dan geodata, disarankan untuk menggunakan sistem 64-bit.
Pastikan Dokumen Dibatasi ke Ukuran 16MB
Dokumen MongoDB terbatas pada ukuran 16MB tetapi Anda tidak perlu mendekati batas ini karena akan berimplikasi pada penurunan kinerja. Dalam praktiknya, dokumen tersebut sebagian besar berukuran KB atau kurang. Ukuran dokumen bergantung pada strategi pemodelan data antara penyematan dan referensi. Penyematan lebih disukai di mana ukuran dokumen diharapkan tidak bertambah banyak. Misalnya, jika Anda memiliki aplikasi media sosial tempat pengguna memposting dan memiliki komentar, praktik terbaiknya adalah memiliki dua koleksi, satu untuk menyimpan informasi postingan.
{
_id:1,
post: 'What is in your mind?',
datePosted: '12-06-2019',
postedBy:'xyz',
likes: 10,
comments: 30
}dan yang lainnya menahan komentar untuk postingan tersebut.
{
_id: ObjectId('2434k23k4'),
postId: 1,
dateCommented: '12-06-2019',
commentedBy:'ABCD',
comment: 'When will we get better again',
}Dengan memiliki model data seperti itu, komentar akan disimpan dalam koleksi yang berbeda dari postingan. Ini mencegah dokumen dalam koleksi posting tumbuh keluar dari ikatan jika akan ada begitu banyak komentar. Pastikan Anda menghindari pola aplikasi yang memungkinkan dokumen tumbuh tanpa batas.
Pastikan Work Set Pas di Memori
Basis data mungkin gagal membaca data dari memori virtual (RAM) yang menyebabkan kesalahan halaman. Kesalahan halaman akan memaksa database untuk membaca data dari disk fisik yang menyebabkan peningkatan latensi dan akibatnya kinerja aplikasi secara keseluruhan menjadi lambat. Kesalahan halaman terjadi karena bekerja dengan set besar yang tidak muat di memori. Ini mungkin karena beberapa dokumen memiliki ukuran yang tidak terbatas atau strategi sharding yang buruk. Perbaikan untuk kesalahan halaman adalah:
- Memastikan dokumen dibatasi hingga ukuran 16MB.
- Memastikan strategi sharding yang baik dengan memilih kunci sharding optimal yang akan membatasi jumlah dokumen yang akan dikenakan operasi throughput.
- Tingkatkan ukuran instance MongoDB untuk mengakomodasi lebih banyak set kerja.
Pastikan Anda Memiliki Set Replika
Dalam dunia database, tidak ideal untuk mengandalkan satu database karena fakta bahwa malapetaka dapat menyerang. Selain itu, Anda akan mengharapkan peningkatan jumlah pengguna ke database maka perlu memastikan ketersediaan data yang tinggi. Replikasi adalah pendekatan penting untuk memastikan ketersediaan tinggi jika terjadi kegagalan. MongoDB memiliki kemampuan untuk melayani data secara geografis:yang berarti pengguna dari lokasi yang berbeda akan dilayani oleh host cloud terdekat sebagai salah satu cara untuk mengurangi latensi permintaan.
Jika node utama gagal, node sekunder dapat memilih yang baru untuk mengikuti operasi tulis daripada aplikasi mengalami downtime selama failover. Sebenarnya, beberapa platform cloud hosting yang cukup mempertimbangkan replikasi tidak mendukung MongoDB yang tidak direplikasi untuk lingkungan produksi.
Aktifkan Penjurnalan
Meskipun penjurnalan berimplikasi pada beberapa penurunan kinerja, ini juga penting. Penjurnalan meningkatkan operasi tulis ke depan yang berarti jika database gagal dalam proses melakukan pembaruan, pembaruan akan disimpan di suatu tempat dan ketika dihidupkan kembali, prosesnya dapat diselesaikan. Penjurnalan dapat dengan mudah memfasilitasi pemulihan kerusakan sehingga harus diaktifkan secara default.
Pastikan Anda Menyiapkan Strategi Pencadangan
Banyak bisnis gagal untuk melanjutkan setelah kehilangan data karena tidak ada atau sistem pencadangan yang buruk. Sebelum menerapkan database Anda ke dalam produksi, pastikan Anda telah menggunakan salah satu dari strategi pencadangan berikut:
- Mongodump :optimal untuk penerapan kecil dan saat membuat cadangan yang difilter berdasarkan kebutuhan khusus.
- Menyalin pokok :optimal untuk penerapan besar dan pendekatan yang efisien untuk mengambil cadangan penuh dan memulihkannya.
- Layanan Manajemen MongoDB (MMS) :menyediakan pencadangan online berkelanjutan untuk MongoDB sebagai layanan yang terkelola sepenuhnya. Optimal untuk sharded cluster dan replika set.
File cadangan juga tidak boleh disimpan di penyedia host database yang sama. Backup Ninja adalah layanan yang dapat digunakan untuk ini.
Bersiaplah untuk Pertanyaan Lambat
Hampir tidak ada yang bisa menyadari kueri lambat di lingkungan pengembangan karena fakta bahwa sedikit data yang terlibat. Namun, ini mungkin tidak terjadi dalam produksi mengingat Anda akan memiliki banyak pengguna atau banyak data akan terlibat. Kueri lambat dapat muncul jika Anda gagal menggunakan indeks atau menggunakan kunci pengindeksan yang tidak optimal. Namun demikian, kami harus menemukan cara yang akan menunjukkan kepada Anda alasan kueri yang lambat.
Oleh karena itu, kami memutuskan untuk mengaktifkan MongoDB Query Profiler. Sebanyak ini dapat menyebabkan penurunan kinerja, profiler akan membantu dalam mengungkap masalah kinerja. Sebelum men-deploy database, Anda harus mengaktifkan profiler untuk koleksi yang Anda curigai memiliki kueri lambat, terutama yang melibatkan dokumen dengan banyak penyematan.
Hubungkan ke Alat Pemantauan
Perencanaan kapasitas adalah tugas yang sangat penting di MongoDB. Anda juga perlu mengetahui kesehatan db Anda pada waktu tertentu. Untuk kenyamanan, menghubungkan database Anda ke alat pemantauan akan menghemat waktu Anda dalam menyadari apa yang Anda butuhkan untuk meningkatkan database Anda seiring waktu. Misalnya, representasi grafis yang menunjukkan kinerja CPU yang lambat sebagai akibat dari peningkatan kueri akan mengarahkan Anda untuk menambahkan lebih banyak sumber daya perangkat keras ke sistem Anda.
Alat pemantauan juga memiliki sistem peringatan melalui surat atau pesan singkat yang dengan mudah memperbarui Anda tentang beberapa masalah sebelum meningkat menjadi bencana. Oleh karena itu, dalam produksi, pastikan database Anda terhubung ke alat pemantauan.
ClusterControl menyediakan pemantauan MongoDB gratis di Edisi Komunitas.
Terapkan Tindakan Keamanan
Keamanan basis data adalah fitur penting lainnya yang perlu diperhitungkan secara ketat. Anda perlu melindungi instalasi MongoDB dalam produksi dengan memastikan beberapa daftar periksa keamanan pra-produksi dipatuhi. Beberapa pertimbangannya adalah:
- Mengonfigurasi Kontrol Akses Berbasis Peran
- Mengaktifkan Kontrol Akses dan Menerapkan Otentikasi
- Mengenkripsi koneksi masuk dan keluar (TLS/SSL)
- Membatasi eksposur jaringan
- Mengenkripsi dan melindungi data
- Memiliki rencana pelacakan akses dan perubahan konfigurasi database
Hindari injeksi eksternal dengan menjalankan MongoDB dengan opsi konfigurasi yang aman. Misalnya, menonaktifkan skrip sisi server jika tidak menggunakan operasi sisi server JavaScript seperti mapReduce dan $where. Gunakan validator JSON untuk pengumpulan data Anda melalui beberapa modul seperti luwak untuk memastikan bahwa semua dokumen yang disimpan dalam format BSON yang valid.
Pertimbangan Perangkat Keras dan Perangkat Lunak
MongoDB memiliki sedikit prasyarat perangkat keras, karena secara eksplisit dirancang dengan pertimbangan besar pada perangkat keras komoditas yang diperlukan. Berikut ini adalah pertimbangan perangkat keras utama untuk MongoDB yang perlu Anda pertimbangkan sebelum diterapkan ke produksi.
- Tetapkan RAM dan CPU yang memadai
- Gunakan mesin penyimpanan WiredTiger. Dirancang untuk menggunakan cache sistem file dan cache internal WiredTiger sehingga meningkatkan kinerja. Misalnya, saat beroperasi dengan sistem RAM 4 GB, cache WiredTiger menggunakan 1,5 GB RAM ( 0,5 * (4 GB -1 GB) =1,5 GB) sedangkan sistem dengan RAM 1,2 GB, cache WiredTiger hanya menggunakan 256 MB.
- NUMA Perangkat Keras. Ada banyak masalah operasional yang mencakup kinerja yang lambat dan penggunaan proses sistem yang tinggi, oleh karena itu, seseorang harus mempertimbangkan untuk mengonfigurasi kebijakan interleave memori.
- Sistem Disk dan Penyimpanan:Gunakan solid state Disk (SSD):MongoDB menunjukkan rasio harga-kinerja yang lebih baik dengan SSD SATA
Kesimpulan
Database dalam produksi sangat penting untuk memastikan kelancaran bisnis sehingga harus diperlakukan dengan banyak pertimbangan. Seseorang harus menetapkan beberapa prosedur yang dapat membantu mengurangi kesalahan atau lebih tepatnya menyediakan cara mudah untuk menemukan kesalahan ini. Selain itu, disarankan untuk menyiapkan sistem peringatan yang akan menunjukkan kondisi database dengan waktu untuk perencanaan kapasitas dan mendeteksi masalah sebelum dimitigasi menjadi bencana.
