Basis data modern harus memiliki kapasitas untuk menangkap dan bereaksi terhadap data yang mengalir secara real-time. Ini menjelaskan mengapa MongoDB memiliki fitur yang disebut MongoDB Change Streams yang bertanggung jawab untuk menangkap dan merespons data secara real-time. Change Streams adalah fitur yang diperkenalkan untuk mengalirkan informasi dari aplikasi ke database secara real-time. Ini didasarkan pada kerangka kerja agregasi yang memantau koleksi dan memungkinkan perubahan terjadi dalam database dan koleksi database. Selain itu, MongoDB Change Stream dapat menangkap data dari sensor IOT dan memperbarui laporan seperti perubahan data operasional di perusahaan. Blog ini akan membuka wacana tentang Aliran Perubahan MongoDB dan mengubah rekomendasi dalam produksi.
MongoDB Mengubah Aliran dan Menghapus Koleksi
Mengganti nama atau menghapus database atau koleksi akan menyebabkan penutupan kursor jika ada aliran perubahan terbuka yang bekerja melawan koleksi yang dihapus. Mengganti nama atau menjatuhkan koleksi membuat kursor dengan FullDocument:updateLookup mengembalikan nol pada dokumen pencarian yang diberikan. Terjadi kesalahan jika seseorang mencoba untuk melanjutkan setelah menjatuhkan database dengan aliran perubahan yang sedang berjalan.
Selain itu, semua perubahan pada data yang dibuat sebelum mengganti nama koleksi dengan aliran perubahan yang dijalankan akan hilang. Batas dokumen untuk aliran Perubahan masih 16 MB BSON; oleh karena itu, dokumen yang lebih besar dari 16MB tidak diterima. Jika seseorang mencoba bekerja dengan dokumen yang lebih besar dari 16 MB, pemberitahuan gagal, dan dokumen tersebut diganti dengan dokumen lain yang memenuhi batas yang ditetapkan.
Bila koleksi atau database dengan aliran perubahan yang dibuka terhadapnya dijatuhkan atau diganti namanya, kursor aliran perubahan cenderung menutup saat mereka maju ke titik itu di oplog. Jika Anda mengubah kursor aliran dengan dokumen lengkap, opsi updateLookup dapat mengembalikan null ke dokumen pencarian.
Oleh karena itu, upaya untuk melanjutkan aliran perubahan terhadap koleksi yang telah dihapus akan mengakibatkan kesalahan. Setiap kemunculan perubahan data dalam koleksi antara peristiwa terakhir dari aliran perubahan yang ditangkap dan peristiwa pelepasan koleksi akan hilang.
Dokumen respons perubahan aliran harus mematuhi batas dokumen BSON 16 MB. Bergantung pada ukuran dokumen dalam koleksi tempat Anda membuka aliran perubahan, notifikasi mungkin gagal jika dokumen notifikasi yang dihasilkan lebih dari 16 MB. Contoh yang baik adalah operasi pembaruan pada aliran perubahan yang diatur untuk mengembalikan dokumen yang diperbarui sepenuhnya atau mengganti/menyisipkan proses dengan dokumen pada batas atau sedikit di bawah batas.
MongoDB Ubah Aliran dan Kumpulan Replika
Set Replika MongoDB adalah kumpulan proses di MongoDB yang kumpulan datanya tidak berubah; yaitu, kumpulan data tetap sama. Dalam kasus set replika yang memiliki anggota arbiter, aliran perubahan cenderung tetap menganggur jika anggota yang memuat data yang cukup tidak tersedia sehingga mayoritas tidak dapat melakukan operasi. Sebagai contoh, kita dapat mempertimbangkan set replika yang memiliki tiga anggota dengan dua node pembawa data di samping arbiter. Dalam kasus sekunder terjadi turun, misalnya, sebagai akibat dari kegagalan atau upgrade atau pemeliharaan, tidak mungkin untuk operasi tulis menjadi mayoritas dilakukan. Aliran perubahan akan tetap terbuka tetapi tidak akan mengirimkan pemberitahuan. Dalam skenario yang ada, aplikasi dapat mengejar semua operasi yang telah terjadi dalam periode waktu henti, selama operasi terakhir yang diterima oleh aplikasi masih dalam oplog dari kumpulan replika tertentu. Selain itu, perintah rs.printReplicationInfo() digunakan untuk mengambil data dari oplog; data yang diambil mencakup berbagai operasi dan ukuran oplog.
Jika waktu henti diperkirakan secara signifikan, misalnya, untuk melakukan peningkatan atau dalam kasus bencana, meningkatkan ukuran oplog akan menjadi pilihan terbaik untuk mempertahankan operasi untuk jangka waktu yang lebih lama dari perkiraan waktu henti. Untuk mengambil informasi status oplog, perintah yang digunakan adalah printReplicationInfo(). Perintah akan mengambil tidak hanya informasi status oplog tetapi juga ukuran oplog dan rentang waktu operasi.
MongoDB Ubah Ketersediaan Aliran
Aliran perubahan MongoDB dapat diperoleh untuk kumpulan replika dan kluster sharded:Baca Kekhawatiran Pengaktifan “mayoritas”, Mesin Penyimpanan, dan Versi Protokol Kumpulan Replika. Baca Kekhawatiran "mayoritas" Pemberdayaan:Dimulai dengan MongoDB versi 4.2 dan di atasnya, aliran perubahan dapat diakses meskipun keadaan yang berlaku dari dukungan perhatian "mayoritas" membaca, yang berarti bahwa dukungan membaca keprihatinan mayoritas dapat diaktifkan atau dinonaktifkan. Di MongoDB versi 4.0 dan versi yang lebih lama, Aliran perubahan hanya tersedia jika dukungan masalah baca "mayoritas" diaktifkan.
- Mesin Penyimpanan:Mesin penyimpanan WiredTiger adalah jenis mesin penyimpanan yang digunakan oleh kumpulan replika dan kluster sharded.
- Replica Set Protocol Version:Kumpulan replika dan sharded cluster harus selalu menggunakan versi 1 dari protokol kumpulan replika (pv1).
Cluster Sharded MongoDB
Kluster sharded di MongoDB terdiri dari shard, mongos, dan server konfigurasi. Pecahan terdiri dari subset data pecahan. Dalam kasus MongoDB 3.6, pecahan digunakan sebagai set replika. Mongos menyediakan antarmuka antara sharded cluster dan aplikasi klien; mongos memainkan peran sebagai router kueri. Dari MongoDB versi 4.4 dan di atasnya, mongos mendukung pembacaan lindung nilai untuk menurunkan latensi. Server konfigurasi adalah lokasi penyimpanan untuk pengaturan konfigurasi cluster dan metadata.
Aliran perubahan menggunakan jam logis global untuk menyediakan pengurutan global perubahan di seluruh pecahan. MongoDB memastikan bahwa urutan perubahan dipertahankan dan bahwa pemberitahuan aliran perubahan dapat ditafsirkan dengan aman sesuai urutan penerimaannya. Misalnya, kursor aliran perubahan yang dibuka terhadap cluster 3-pecahan mengembalikan pemberitahuan perubahan mengenai urutan total perubahan di tiga pecahan.
Untuk memastikan urutan total perubahan, Mongos memeriksa setiap pecahan untuk melihat apakah ada perubahan terbaru untuk setiap pemberitahuan perubahan. Cluster shard dengan satu hingga beberapa shard dengan sedikit atau tanpa aktivitas pengumpulan atau "dingin" cenderung memiliki efek negatif pada waktu respons aliran perubahan karena mongos masih harus memeriksa dengan shard dingin tersebut untuk memastikan pemesanan total perubahan. Efek ini mungkin lebih terlihat ketika shard didistribusikan secara geografis atau ketika beban kerja dengan sebagian besar operasi terjadi pada subset shard dalam sebuah cluster. Jika koleksi shard memiliki aktivitas tingkat tinggi, mongos mungkin tidak dapat melacak perubahan di semua shard. Pertimbangkan untuk menggunakan filter notifikasi untuk jenis koleksi ini, misalnya, meneruskan pipa $match, yang dikonfigurasi untuk memfilter operasi penyisipan saja.
Dalam kasus koleksi yang di-shard, operasi pembaruan multi:yang tepat kemungkinan akan menyebabkan aliran perubahan yang dibuka terhadap koleksi untuk mengirim pemberitahuan untuk dokumen yang ditinggalkan. Mulai dari saat koleksi yang tidak di-sharding di-sharding hingga saat aliran perubahan mencapai potongan migrasi pertama, documentKey dalam dokumen pemberitahuan aliran perubahan hanya menyertakan id dokumen dan bukan kunci shard lengkap.
Kesimpulan
Tujuan dari aliran perubahan adalah untuk memungkinkan perubahan data aplikasi secara real-time, tanpa risiko menguntit oplog dan tanpa kerumitan apa pun. Aplikasi MongoDB menggunakan aliran perubahan untuk menandatangani perubahan data pada database, koleksi, atau penerapan, dan segera bereaksi terhadapnya. Karena aliran perubahan menggunakan kerangka kerja agregasi, aplikasi dapat memfilter perubahan tertentu dan mengonversi notifikasi sendiri.
