ApsaraDB for MongoDB：Fitur MongoDB 4.4

Indeks tersembunyi

Meskipun sejumlah besar indeks dapat menurunkan kinerja penulisan, data yang kompleks membuat sulit bagi insinyur O&M untuk menghapus indeks yang mungkin tidak efektif. Jika indeks efektif dihapus secara tidak sengaja, jitter dapat terjadi. Selain itu, biaya untuk membuat ulang indeks yang terhapus secara tidak sengaja cukup tinggi.

Untuk menyelesaikan masalah ini, Alibaba Cloud dan MongoDB bersama-sama mengembangkan fitur indeks tersembunyi sebagai mitra strategis. Untuk informasi lebih lanjut, lihat halaman produk ApsaraDB for MongoDB. Fitur ini memungkinkan Anda menggunakan perintah collMod untuk menyembunyikan indeks. Indeks tersembunyi tidak digunakan dalam kueri berikutnya. Jika indeks tersembunyi tidak menyebabkan kesalahan, indeks tersebut dapat dihapus.

db.runCommand( {
   collMod: 'testcoll',
   index: {
      keyPattern: 'key_1',
      hidden: false
   }
} )

Indeks tersembunyi hanya tidak terlihat oleh query planner MongoDB. Indeks tetap memiliki beberapa fitur indeks seperti kendala indeks unik dan waktu kedaluwarsa (TTL).

Kunci shard yang dapat diperbaiki

Sebuah kunci shard memainkan peran penting dalam kluster sharded. Kunci shard dapat membuat kluster sharded lebih scalable di bawah beban kerja tertentu. Namun, dalam penggunaan aktual MongoDB, perubahan beban kerja dapat menyebabkan chunk jumbo atau hotspot kueri pada satu shard meskipun Anda memilih kunci shard dengan hati-hati. Chunk jumbo adalah chunk yang tumbuh melampaui ukuran chunk tertentu.

Pada MongoDB 4.0 dan sebelumnya, kunci shard untuk koleksi dan nilai kunci shard tidak dapat diubah. Pada MongoDB 4.2 dan seterusnya, Anda dapat mengubah nilai kunci shard. Namun, untuk mengubah nilai kunci shard, Anda harus memigrasikan data lintas shard berdasarkan transaksi terdistribusi. Mekanisme ini memiliki overhead kinerja yang tinggi dan tidak mampu mencegah chunk jumbo dan hotspot kueri. Misalnya, jika Anda menggunakan kunci shard {customer_id:1} untuk melakukan sharding pada koleksi pesanan, kunci shard tersebut cukup memadai pada tahap awal sebuah perusahaan karena jumlah pesanan yang ditempatkan oleh setiap pelanggan kecil. Namun, seiring berkembangnya perusahaan, jika pelanggan utama menempatkan lebih banyak pesanan, kueri sering dilakukan pada koleksi pesanan dan hotspot kueri tunggal-shard mungkin terjadi. Pesanan memiliki hubungan dekat dengan bidang customer_id, kueri tidak merata tidak dapat diselesaikan dengan mengubah bidang customer_id.

Dalam kasus ini, Anda dapat menggunakan perintah refineCollectionShardKey yang disediakan oleh MongoDB 4.4 untuk menambahkan satu atau lebih bidang akhiran ke kunci shard yang ada. Dengan cara ini, distribusi data yang lebih halus digunakan untuk dokumen dan chunk jumbo dicegah. Misalnya, Anda dapat menggunakan perintah refineCollectionShardKey untuk mengubah kunci shard menjadi {customer_id:1, order_id:1}. Dengan cara ini, hotspot kueri tunggal-shard dapat dicegah.

Perintah refineCollectionShardKey memiliki overhead kinerja yang rendah karena perintah ini hanya memodifikasi metadata pada node server config dan tidak memigrasikan data. Data didistribusikan secara bertahap ketika chunk dibagi atau dimigrasikan ke shard lain. Kunci shard harus didukung oleh indeks. Anda harus membuat indeks yang mendukung kunci shard baru sebelum menjalankan perintah refineCollectionShardKey.

Bidang akhiran tidak disimpan di semua dokumen. Untuk menyelesaikan masalah ini, MongoDB 4.4 menyediakan fitur kunci shard yang hilang. Dokumen dalam koleksi sharded dapat melewatkan bidang kunci shard tertentu. Kelemahan dari fitur kunci shard yang hilang adalah bahwa itu dapat menyebabkan chunk jumbo. Kami merekomendasikan agar Anda tidak menggunakan fitur ini kecuali diperlukan.

Kunci shard hash majemuk

Versi sebelum MongoDB 4.4 tidak mendukung indeks hash majemuk. Anda hanya dapat menentukan kunci hash dengan satu bidang. Ini dapat menyebabkan distribusi data yang tidak merata di koleksi lintas shard data.

MongoDB 4.4 mendukung indeks hash majemuk. Anda dapat menentukan bidang hash tunggal dalam indeks majemuk sebagai bidang awalan atau akhiran.

Sintaks:

sh.shardCollection(
  "examples.compoundHashedCollection",
  { "region_id" : 1, "city_id": 1, field1" : "hashed" }
)
sh.shardCollection(
  "examples.compoundHashedCollection",
  { "_id" : "hashed", "fieldA" : 1}
)

Jika indeks hash majemuk tidak didukung, Anda harus menghitung nilai hash dari satu bidang, menyimpan nilai hash dalam bidang khusus dokumen sebagai nilai indeks, dan kemudian menggunakan fitur sharding berbasis rentang untuk menentukan nilai indeks sebagai kunci shard Anda.

Pada MongoDB 4.4, Anda hanya perlu menentukan bidang sebagai hashed. Dalam skenario kedua yang disebutkan sebelumnya, Anda hanya perlu menyetel kunci shard menjadi {customer_id:'hashed', order_id:1}. Ini menyederhanakan logika bisnis.

Bacaan lindung nilai

Latensi jaringan dapat menyebabkan kerugian ekonomi. Laporan dari Google menunjukkan bahwa jika halaman membutuhkan waktu lebih dari 3 detik untuk dimuat, lebih dari separuh pengunjung meninggalkan halaman. Untuk informasi lebih lanjut tentang laporan tersebut, kunjungi 7 Page Speed Stats Every Marketer Should Know. Untuk meminimalkan latensi jaringan, MongoDB 4.4 menyediakan fitur bacaan lindung nilai. Dalam kluster sharded, node mongos mengarahkan operasi baca ke dua anggota set replika per shard yang diquery dan mengembalikan hasil dari responden pertama per shard ke klien. Dengan cara ini, latensi P95 dan P99 dikurangi. Latensi P95 dan P99 menunjukkan bahwa latensi rata-rata untuk 5% dan 1% permintaan terlambat selama 10 detik terakhir berada dalam batas.

db.collection.find({ }).readPref(
   "secondary",                      // mode
   [ { "datacenter": "B" },  { } ],  // tag set
   { enabled: true }                 // hedge options
)

Dukungan node mongos untuk fitur bacaan lindung nilai juga harus diaktifkan. Untuk mengaktifkan dukungan, Anda harus menyetel parameter readHedgingMode ke on.

db.adminCommand( { setParameter: 1, readHedgingMode: "on" } )

Latensi replikasi berkurang

MongoDB 4.4 mengurangi latensi replikasi utama/sekunder. Latensi replikasi utama/sekunder memengaruhi operasi baca/tulis di MongoDB. Dalam beberapa skenario, database sekunder harus mereplikasi dan menerapkan pembaruan inkremental dari database utama dalam periode waktu singkat. Jika tidak, database sekunder tidak dapat melanjutkan operasi baca dan tulis. Latensi yang lebih rendah memberikan konsistensi utama/sekunder yang lebih baik.

Replikasi streaming

Pada versi sebelum MongoDB 4.4, database sekunder harus mem-poll data upstream untuk mendapatkan pembaruan inkremental. Untuk mem-poll data upstream, database sekunder mengirimkan perintah getMore ke database utama untuk memindai koleksi oplog. Jika koleksi oplog memiliki entri, database sekunder mengambil batch entri oplog. Batch dapat berukuran maksimum 16 MB. Jika pemindaian mencapai akhir koleksi oplog, database sekunder menggunakan parameter awaitData untuk memblokir perintah getMore. Ketika data baru dimasukkan ke dalam koleksi oplog, database sekunder mengambil batch entri oplog berikutnya. Operasi pengambilan menggunakan thread OplogFetcher yang memerlukan waktu perjalanan bolak-balik (RTT) antara mesin sumber dan tujuan. Jika set replika berada dalam kondisi jaringan yang buruk, latensi jaringan menurunkan kinerja replikasi.

Pada MongoDB 4.4, database utama mengirimkan aliran kontinu entri oplog ke database sekunder alih-alih menunggu database sekunder mem-poll data upstream. Dibandingkan dengan metode di mana database sekunder mem-poll data upstream, setidaknya setengah dari RTT dihemat untuk setiap batch entri oplog. Anda dapat memanfaatkan sepenuhnya replikasi streaming dalam skenario berikut:

• Jika Anda menyetel parameter writeConcern ke "majority" untuk operasi penulisan, operasi penulisan "majority" harus menunggu replikasi beberapa kali. Bahkan dalam kondisi jaringan latensi tinggi, replikasi streaming dapat meningkatkan kinerja rata-rata hingga 50% untuk operasi penulisan "majority".

• Jika Anda menggunakan sesi konsisten kausal, Anda dapat membaca operasi penulisan Anda sendiri di database sekunder. Fitur ini memerlukan database sekunder untuk segera mereplikasi koleksi oplog dari database utama.

Pembuatan indeks simultan

Versi sebelum MongoDB 4.4 mengharuskan Anda membuat indeks di database utama sebelum dapat mereplikasi indeks ke database sekunder. Metode pembuatan indeks di database sekunder bervariasi berdasarkan versi yang berbeda. Dampak pada koleksi oplog di database sekunder bervariasi berdasarkan metode yang berbeda untuk membuat indeks di database sekunder.

Pada MongoDB 4.2, indeks foreground dan background dibuat dengan cara yang sama. Koleksi memegang kunci eksklusif hanya pada awal dan akhir proses pembuatan indeks. Meskipun metode penguncian granular ini, overhead CPU dan I/O dari proses pembuatan indeks menyebabkan latensi replikasi. Beberapa operasi khusus juga dapat memengaruhi koleksi oplog di database sekunder. Misalnya, jika Anda menggunakan perintah collMod untuk memodifikasi metadata koleksi, koleksi oplog mungkin terblokir. Koleksi oplog juga dapat memasuki status Recovering karena koleksi oplog historis di database utama tertimpa.

Pada MongoDB 4.4, indeks dibuat secara simultan di database utama dan sekunder. Dengan cara ini, latensi utama/sekunder dikurangi. Database sekunder dapat membaca data terbaru bahkan selama proses pembuatan indeks.

Indeks hanya dapat digunakan ketika sebagian besar node pemungutan suara menyelesaikan pembuatan indeks. Ini dapat mengurangi perbedaan kinerja yang disebabkan oleh indeks yang berbeda dalam skenario pemisahan baca/tulis.

Bacaan cermin

Fenomena umum di ApsaraDB for MongoDB adalah bahwa sebagian besar pengguna yang membeli instance set replika tiga-node hanya melakukan operasi baca dan tulis pada node utama, sedangkan node sekunder tidak memproses lalu lintas baca. Dalam hal ini, failover sesekali menyebabkan latensi akses yang nyata dan kecepatan akses hanya dapat dipulihkan ke normal setelah periode waktu tertentu. Latensi akses terjadi karena node utama yang terpilih memproses lalu lintas baca untuk pertama kalinya. Node utama yang terpilih tidak mengakui karakteristik data yang sering diakses dan tidak memiliki cache yang sesuai. Setelah node utama yang terpilih memproses lalu lintas baca, operasi baca mengalami sejumlah besar cache miss dan data harus dimuat ulang dari disk. Ini menghasilkan peningkatan latensi akses. Masalah ini jelas terlihat pada instance yang memiliki kapasitas memori besar.

MongoDB 4.4 menyediakan fitur bacaan cermin. Node utama dapat menggunakan bacaan cermin untuk mencerminkan subset operasi baca yang diterimanya dan mengirimkannya ke subset database sekunder yang dapat dipilih. Ini membantu database sekunder mempersiapkan cache. Bacaan cermin adalah operasi fire-and-forget. Operasi fire-and-forget adalah operasi non-blocking yang tidak berdampak pada kinerja database utama. Namun, beban kerja meningkat di database sekunder.

Anda dapat menentukan laju bacaan cermin dengan menggunakan parameter mirrorReads. Laju default adalah 1%.

Sintaks:

db.adminCommand( { setParameter: 1, mirrorReads: { samplingRate: 0.10 } } )

Anda juga dapat menggunakan perintah db.serverStatus( { mirroredReads: 1 } ) untuk mengumpulkan statistik bacaan cermin. Sintaks:

SECONDARY> db.serverStatus( { mirroredReads: 1 } ).mirroredReads
{ "seen" : NumberLong(2), "sent" : NumberLong(0) }

Penyinkronan awal yang dapat dilanjutkan

Pada versi sebelum MongoDB 4.4, database sekunder harus memulai ulang seluruh proses penyinkronan penuh awal jika terjadi gangguan jaringan. Ini sangat memengaruhi beban kerja jika Anda memiliki volume data yang besar.

Pada MongoDB 4.4, database sekunder dapat mencoba melanjutkan proses sinkronisasi. Jika database sekunder tidak dapat melanjutkan penyinkronan penuh awal selama periode tertentu, sistem memilih sumber baru dan memulai ulang proses sinkronisasi penuh dari awal. Secara default, database sekunder mencoba melanjutkan penyinkronan awal selama 24 jam. Anda dapat menggunakan parameter replication.initialSyncTransientErrorRetryPeriodSeconds untuk mengubah sumber sinkronisasi ketika database sekunder mencoba melanjutkan proses sinkronisasi.

Jika jaringan mengalami kesalahan koneksi non-transien, database sekunder harus memulai ulang seluruh proses penyinkronan penuh awal.

Penyimpanan oplog berbasis waktu

Di MongoDB, koleksi oplog mencatat semua operasi yang memodifikasi data di database Anda. Koleksi oplog adalah infrastruktur vital yang dapat digunakan untuk replikasi, pencadangan inkremental, migrasi data, dan langganan data.

Dalam sebagian besar skenario, Anda perlu menyimpan entri oplog yang dihasilkan dalam periode terakhir. Namun, jumlah entri oplog yang dihasilkan dalam periode terakhir sulit ditentukan.

Pada MongoDB 4.4, Anda dapat menggunakan parameter storage.oplogMinRetentionHours untuk menentukan jumlah minimum jam untuk menyimpan entri oplog. Anda dapat menggunakan perintah replSetResizeOplog untuk memodifikasi jumlah minimum jam. Sintaks:

// Pertama, tampilkan nilai konfigurasi saat ini
db.getSiblingDB("admin").serverStatus().oplogTruncation.oplogMinRetentionHours
// Modifikasi
db.adminCommand({
  "replSetResizeOplog" : 1,
  "minRetentionHours" : 2
})

Union

Versi sebelum MongoDB 4.4 menyediakan tahap $lookup yang mirip dengan fitur LEFT OUTER JOIN dalam SQL untuk kueri union. Pada MongoDB 4.4, tahap $unionWith menyediakan fitur serupa dengan operator UNION ALL dalam SQL. Anda dapat menggunakan tahap $lookup untuk menggabungkan hasil pipeline dari beberapa koleksi menjadi satu set hasil, dan kemudian menanyakan dan memfilter data berdasarkan kondisi tertentu. $unionWith stage berbeda dari $lookup stage dalam mendukung kueri pada koleksi sharded. Anda dapat menggunakan beberapa $unionWith stages untuk mencampur beberapa koleksi dan pipeline agregasi. Sintaks:

{ $unionWith: { coll: "<collection>", pipeline: [ <stage1>, ... ] } }

Anda juga dapat menentukan tahap yang berbeda dalam parameter pipeline untuk memfilter data berdasarkan koleksi tertentu sebelum agregasi. Metode ini fleksibel untuk digunakan. Misalnya, asumsikan bahwa Anda perlu menyimpan data pesanan bisnis di koleksi yang berbeda berdasarkan tabel. Sintaks:

db.orders_april.insertMany([
  { _id:1, item: "A", quantity: 100 },
  { _id:2, item: "B", quantity: 30 },
]);
db.orders_may.insertMany([
  { _id:1, item: "C", quantity: 20 },
  { _id:2, item: "A", quantity: 50 },
]);
db.orders_june.insertMany([
  { _id:1, item: "C", quantity: 100 },
  { _id:2, item: "D", quantity: 10 },
]);

Pada versi sebelum MongoDB 4.4, jika Anda memerlukan laporan penjualan produk yang berbeda di kuartal kedua, Anda harus membaca semua data sendiri dan menggabungkan data di lapisan aplikasi. Atau, Anda harus menggunakan gudang data untuk menganalisis data. Pada MongoDB 4.4, Anda hanya perlu menggunakan pernyataan agregat tunggal untuk menggabungkan data. Sintaks:

db.orders_april.aggregate( [
   { $unionWith: "orders_may" },
   { $unionWith: "orders_june" },
   { $group: { _id: "$item", total: { $sum: "$quantity" } } },
   { $sort: { total: -1 }}
] )

Ekspresi agregasi kustom

Untuk menjalankan kueri kompleks pada versi sebelum MongoDB 4.4, Anda dapat menggunakan operator $where dalam perintah find. Atau, Anda dapat menjalankan file JavaScript di server dengan menggunakan perintah MapReduce. Namun, metode-metode ini tidak dapat menggunakan pipeline agregasi.

Pada MongoDB 4.4, Anda dapat menggunakan operator pipeline agregasi $accumulator dan $function sebagai pengganti operator $where dan perintah MapReduce. Anda dapat mendefinisikan ekspresi kustom Anda sendiri dalam JavaScript dan mengeksekusi ekspresi tersebut di server database sebagai bagian dari pipeline agregasi. Dengan cara ini, kerangka kerja pipeline agregasi memudahkan untuk menggabungkan kueri kompleks, yang meningkatkan pengalaman pengguna.

Operator $accumulator bekerja dengan cara yang mirip dengan perintah MapReduce. Fungsi init digunakan untuk menginisialisasi status untuk dokumen input. Kemudian, fungsi accumulate digunakan untuk memperbarui status untuk setiap dokumen input dan menentukan apakah akan mengeksekusi fungsi merge.

Sebagai contoh, jika Anda menggunakan operator $accumulator pada koleksi sharded, fungsi merge diperlukan untuk menggabungkan beberapa status. Jika Anda juga menentukan fungsi finalize, fungsi merge mengembalikan hasil gabungan dari status yang telah digabungkan berdasarkan hasil fungsi finalize setelah semua dokumen diproses.

Operator $function bekerja dengan cara yang mirip dengan operator $where. Manfaat tambahan adalah bahwa operator $function dapat bekerja dengan operator pipeline agregasi lainnya. Anda juga dapat menggunakan operator $function bersama dengan operator $expr dalam perintah find. Kombinasi operator ini setara dengan operator $where. Manual resmi MongoDB juga menyarankan untuk menggunakan operator $function.

Operator pipeline agregasi baru

Pemantauan dan Pooling Koneksi

Pada MongoDB 4.4, Anda dapat menggunakan driver untuk mengonfigurasi dan memantau perilaku pooling koneksi. API standar diperlukan untuk berlangganan ke event yang terkait dengan pool koneksi. Event termasuk pembuatan dan penutupan koneksi dalam pool koneksi, serta pembersihan pool koneksi. Anda juga dapat menggunakan API untuk mengonfigurasi opsi pool koneksi, seperti jumlah maksimum atau minimum koneksi yang diizinkan untuk sebuah pool, jumlah waktu maksimum yang dapat dihabiskan oleh sebuah koneksi, dan jumlah waktu maksimum yang dapat dihabiskan oleh sebuah thread untuk menunggu ketersediaan koneksi. Untuk informasi lebih lanjut, kunjungi Connection Monitoring and Pooling.

Kepedulian Baca dan Tulis Global

Pada versi sebelum MongoDB 4.4, jika Anda tidak menentukan parameter readConcern atau writeConcern untuk suatu operasi, nilai default digunakan. Nilai default dari readConcern adalah local, sedangkan nilai default dari writeConcern adalah {w: 1}. Nilai-nilai default ini tidak dapat dimodifikasi. Sebagai contoh, jika Anda ingin menggunakan "majority" write concerns untuk semua operasi insert, Anda harus menyetel parameter writeConcern ke {w: majority} di semua kode akses MongoDB.

Pada MongoDB 4.4, Anda dapat menggunakan perintah setDefaultRWConcern untuk menentukan pengaturan default global readConcern dan writeConcern. Sintaks:

db.adminCommand({
  "setDefaultRWConcern" : 1,
  "defaultWriteConcern" : {
    "w" : "majority"
  },
  "defaultReadConcern" : { "level" : "majority" }
})

Anda juga dapat menggunakan perintah getDefaultRWConcern untuk mendapatkan pengaturan default global saat ini untuk parameter readConcern dan writeConcern.

Shell MongoDB Baru (beta)

Rangkuman

MongoDB 4.4 adalah rilis pemeliharaan. Selain fitur utama yang disebutkan sebelumnya, peningkatan umum juga disediakan, seperti optimasi operator agregasi $indexStats, dukungan untuk koneksi TCP Fast Open (TFO), dan optimasi penghapusan indeks. Beberapa peningkatan besar juga tersedia, seperti log terstruktur (logv2) dan mekanisme autentikasi baru untuk keamanan.

Untuk informasi lebih lanjut, kunjungi Catatan Rilis untuk MongoDB 4.4.