Penerapan cluster sangat penting dalam memastikan ketersediaan data yang tinggi serta melindunginya. MongoDB meningkatkan ini melalui replikasi dan sharding, di mana replikasi memastikan penskalaan vertikal melalui pengangkatan redundansi sedangkan sharding meningkatkan penskalaan horizontal.
Secara umum, kedua pendekatan mencoba untuk mendistribusikan beban kerja di antara anggota dan dengan demikian mengurangi beban kerja yang dapat menjadi sasaran satu node. Kinerja database kemudian dapat terlihat cepat dalam melayani pengguna dengan operasi throughput. Namun, tanpa arsitektur kluster utama, Anda mungkin tidak melihat tingkat hasil yang sama, bahkan jika Anda mencoba sharding dan replikasi.
Jika anggota kumpulan replika genap, maka akan sulit bagi anggota untuk memilih dan memilih pemilihan pendahuluan baru jika yang sudah ada gagal di beberapa titik. Di blog ini kita akan membahas arsitektur penerapan standar yang dapat digunakan, tetapi ini dapat bervariasi sesuai dengan persyaratan aplikasi.
Strategi Penerapan MongoDB
Arsitektur set replika sangat menentukan kapasitas dan kapabilitas MongoDB.
Satu set replika tiga node adalah penerapan klaster standar untuk MongoDB di lingkungan produksi apa pun karena menyediakan redundansi data dan toleransi kesalahan. Redundansi penting terutama dalam pemulihan basis data setelah terjadi bencana. Kumpulan replika tiga simpul mungkin merupakan arsitektur penerapan dasar, tetapi ini dapat bervariasi sesuai dengan spesifikasi dan persyaratan aplikasi. Namun, jangan membuatnya terlalu rumit karena dapat membawa Anda ke beberapa masalah konfigurasi yang lebih besar.
Strategi Sharding MongoDB
Sharding mengurangi beban kerja di mana database bekerja untuk kueri tertentu dengan mengurangi jumlah dokumen yang harus ditindaklanjuti. Oleh karena itu, ini meningkatkan penskalaan horizontal yang memungkinkan basis data tumbuh melampaui batas perangkat keras dari satu server. Bergantung pada permintaan beban kerja, node dapat ditambahkan atau dihapus dari cluster dan MongoDB akan menyeimbangkan kembali data secara optimal tanpa intervensi operasi.
Beberapa strategi penerapan terbaik untuk sharded cluster meliputi:
Memastikan Shard Key Didistribusikan Secara Merata
Alasan di balik sharding adalah untuk menskalakan database secara horizontal dan mengurangi jumlah operasi throughput yang dapat dilakukan oleh satu instance. Jika Anda tidak mendistribusikan kunci pecahan secara seragam, Anda mungkin akan mendapatkan pecahan dalam jumlah kecil. Dengan sedikit pecahan, operasi mungkin dibatasi oleh kapasitas pecahan tunggal sehingga membuat operasi baca dan tulis menjadi lambat.
Potongan Harus Dibagi Sebelumnya dan Didistribusikan Terlebih Dahulu
Shards memiliki potongan data yang dikelompokkan menurut beberapa kriteria kunci shard. Saat membuat koleksi pecahan baru, sebelum memuatnya dengan data, Anda harus membuat potongan kosong dan mendistribusikannya secara merata di semua pecahan. Saat Anda akan mengisi MongoDB dengan data, akan mudah untuk menyeimbangkan beban di seluruh pecahan yang terlibat. Opsi numInitialChunks dapat digunakan untuk melakukan ini secara otomatis jika Anda menggunakan sharding berbasis hash. Namun nilai integer harus kurang dari 8192 per pecahan.
Jumlah Pecahan
Dua pecahan sering kali diperlukan sebagai jumlah minimum untuk mencapai signifikansi pecahan. Satu shard hanya berguna jika Anda ingin meletakkan dasar pengaktifan sharding di masa mendatang dan tidak perlu selama waktu penerapan.
Lebih memilih Sharding Berbasis Rentang daripada Sharding Berbasis Hash
Sharding berbasis rentang bermanfaat karena menyediakan lebih banyak shard, sehingga operasi dapat diarahkan ke shard paling sedikit yang diperlukan dan lebih sering ke satu shard. Praktis ini mungkin sulit kecuali Anda memiliki pemahaman yang baik tentang data dan pola kueri yang terlibat. Sharding yang di-hash meningkatkan distribusi operasi throughput yang seragam dengan mengorbankan penyediaan operasi berbasis rentang yang lebih rendah.
Gunakan Kueri Scatter-Gather hanya untuk Kueri Agregasi Besar
Kueri yang tidak dapat dirutekan berdasarkan shard key harus disiarkan ke semua shard untuk evaluasi dan karena melibatkan banyak shard untuk setiap permintaan, mereka tidak menskalakan secara linier karena lebih banyak shard ditambahkan sehingga menimbulkan overhead yang menurunkan kinerja database. Operasi ini dikenal sebagai scatter-gather dan hanya dapat dihindari jika Anda menyertakan kunci shard dalam kueri Anda.
Pendekatan ini hanya berguna saat menangani kueri agregasi besar yang memungkinkan setiap kueri dijalankan secara paralel di semua shard.
Strategi Replikasi MongoDB
Replikasi meningkatkan penskalaan vertikal di MongoDB sehingga beban kerja didistribusikan di antara anggota yang terlibat. Dalam lingkungan produksi, ini adalah beberapa pertimbangan yang harus dibuat untuk arsitektur cluster yang optimal.
Jumlah Node
Jumlah maksimum node yang dapat dimiliki oleh kumpulan replika adalah 50 dengan 7 anggota voting. Setiap anggota setelah tanggal 7 dianggap non-voting. Sebuah cluster yang baik karena itu harus memiliki 7 anggota voting untuk membuat proses pemilihan nyaman.
Menerapkan jumlah anggota pemilih ganjil dan jika Anda hanya memiliki kurang dari 7 tetapi jumlah anggota genap, maka Anda perlu menggunakan arbiter sebagai anggota pemilih lainnya. Arbiter tidak menyimpan salinan data sehingga akan membutuhkan lebih sedikit sumber daya untuk dikelola. Selain itu, seseorang dapat membuat mereka tunduk pada lingkungan yang tidak dapat Anda tundukkan pada anggota lainnya.
Pertimbangan Toleransi Kesalahan
Terkadang beberapa anggota mungkin tidak tersedia karena faktor seperti pemadaman listrik atau transien dan pemutusan jaringan. Jumlah anggota yang tersisa di himpunan dan mampu memilih primer menciptakan situasi yang dikenal sebagai Toleransi kesalahan. Oleh karena itu, perbedaan antara jumlah total anggota himpunan replika dan mayoritas anggota pemungutan suara yang diperlukan untuk memilih pemilihan pendahuluan. Tidak adanya perintah utama bahwa operasi tulis tidak dapat dijalankan.
Tabel di bawah menunjukkan contoh hubungan antara ketiganya.
| Total anggota kumpulan replika | Mayoritas diperlukan untuk Memilih sekolah dasar baru | Toleransi Kesalahan |
| 3 | 2 | 1 |
| 4 | 3 | 1 |
| 5 | 3 | 2 |
| 6 | 4 | 2 |
| 7 | 5 | 2 |
Hubungannya tidak begitu langsung karena jika Anda menambahkan lebih banyak anggota ke himpunan, itu tidak diberikan bahwa toleransi kesalahan akan meningkat seperti yang terlihat dari tabel. Anggota tambahan memberikan dukungan untuk fungsi khusus seperti pencadangan dan pelaporan.
Perencanaan Kapasitas dan Penyeimbangan Beban untuk Pembacaan Berat
Anda harus memiliki kapasitas cadangan untuk penerapan Anda dengan menambahkan anggota baru sebelum permintaan saat ini memenuhi kapasitas set yang ada.
Untuk lalu lintas baca yang sangat tinggi, distribusikan throughput yang dibaca ke anggota sekunder dan setiap kali cluster bertambah, tambahkan atau pindahkan anggota ke pusat data alternatif untuk mencapai redundansi dan meningkatkan ketersediaan data.
Anda juga dapat menggunakan operasi target dengan kumpulan tag untuk menargetkan operasi baca ke anggota tertentu atau mengubah masalah penulisan untuk meminta pengakuan dari anggota tertentu.
Node Harus Didistribusikan Secara Geografis
Pusat data juga dapat gagal karena beberapa bencana . Oleh karena itu, disarankan untuk menyimpan setidaknya satu atau dua anggota di pusat data terpisah untuk tujuan perlindungan data. Jika memungkinkan, gunakan jumlah pusat data ganjil dan pilih distribusi yang memaksimalkan kemungkinan bahwa bahkan dengan hilangnya pusat data, anggota kumpulan replika yang tersisa dapat membentuk mayoritas atau minimal memberikan salinan data.
Gunakan Jurnal untuk Kegagalan Tak Terduga
Secara default ini diaktifkan di MongoDB. Anda harus memastikan opsi ini diaktifkan untuk melindungi kehilangan data jika terjadi gangguan layanan seperti reboot mendadak dan mati listrik.
Pola Penerapan
Terutama ada dua pendekatan penerapan yaitu:
- Tiga set replika Anggota yang menyediakan arsitektur minimum yang disarankan untuk set replika.
- Set replika yang didistribusikan di dua atau lebih pusat data untuk melindungi dari kegagalan khusus fasilitas seperti pemadaman listrik.
Namun, polanya bergantung pada persyaratan aplikasi, tetapi jika memungkinkan, Anda dapat menggabungkan fitur dari keduanya dalam arsitektur penerapan Anda.
Nama Inang dan Penamaan Kumpulan Replika
Gunakan nama host DNS logis daripada alamat ip saat mengonfigurasi anggota kumpulan replika atau anggota sharded cluster. Ini untuk menghindari kesulitan yang terkait dengan perubahan konfigurasi yang perlu Anda lakukan sebagai akibat dari alamat ip yang diubah.
Dalam hal penamaan kumpulan replika, gunakan nama yang berbeda untuk kumpulan karena beberapa driver mengelompokkan koneksi kumpulan replika menurut nama kumpulan replika.
Kesimpulan
Tata letak arsitektur untuk set replika menentukan kapasitas dan kemampuan penerapan Anda. Perlindungan data dan kinerja sistem adalah pertimbangan utama saat menyiapkan arsitektur. Seseorang harus mempertimbangkan faktor-faktor penting seperti Toleransi kesalahan, jumlah anggota kumpulan replika, kunci sharding yang optimal, dan pola penerapan untuk ketersediaan tinggi &perlindungan data. Distribusi geografis dari kumpulan node replika dapat mengatasi banyak faktor ini dengan memastikan redundansi dan memberikan toleransi kesalahan jika salah satu pusat data tidak ada.
