ApsaraDB for MongoDB:Ikhtisar\ fitur\ MongoDB\ 4\.4

Hidden indexes

Menghapus indeks yang ternyata masih dibutuhkan sangat mahal—indeks tersebut harus dibangun ulang, yang memakan waktu dan sumber daya. Hidden indexes memungkinkan Anda mengevaluasi dampak penghapusan indeks tanpa benar-benar menghapusnya.

Alibaba Cloud dan MongoDB mengembangkan fitur hidden index secara bersama sebagai mitra strategis.

Gunakan perintah collMod untuk menyembunyikan indeks:

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

Query planner mengabaikan hidden indexes, sehingga kueri langsung berhenti menggunakannya. Namun, indeks tersebut tetap diperbarui di latar belakang, yang berarti:

• Batasan indeks unik dan masa kadaluarsa time to live (TTL) tetap aktif.

• Membatalkan penyembunyian indeks membuatnya langsung tersedia—tidak perlu membangun ulang.

Jika penyembunyian indeks tidak menyebabkan error, indeks tersebut dapat dihapus dengan aman.

Refinable shard keys

Saat workload berubah, shard key yang awalnya dipilih dengan baik dapat menciptakan hotspots. Misalnya, shard key {customer_id: 1} bekerja dengan baik di awal. Seiring pelanggan utama mengumpulkan lebih banyak pesanan, semua kueri untuk pelanggan tersebut diarahkan ke satu shard saja, menciptakan hotspot. Mengubah hanya customer_id tidak dapat memperbaiki masalah ini karena pesanan terikat pada field tersebut.

Gunakan refineCollectionShardKey untuk menambahkan field sufiks ke shard key yang sudah ada tanpa migrasi data:

db.adminCommand({
  refineCollectionShardKey: "orders",
  key: { customer_id: 1, order_id: 1 }
})

Perintah ini hanya memodifikasi metadata di config server. Data didistribusikan ulang secara bertahap saat chunk terpecah atau bermigrasi. Sebelum menjalankan perintah, buatlah indeks yang mendukung shard key baru tersebut.

Dokumen dalam koleksi sharded dapat tidak memiliki field sufiks yang ditambahkan oleh refineCollectionShardKey. Hal ini didukung tetapi dapat menciptakan jumbo chunks—gunakan hanya jika diperlukan.

Compound hashed shard keys

Indeks hashed compound menyelesaikan dua masalah sharding:

• Kepatuhan zona: Mendistribusikan data secara merata di seluruh shard dalam suatu zona sekaligus memenuhi persyaratan residensi data geografis.

• Kunci yang meningkat secara monoton: Field seperti customer_id yang meningkat secara monoton mengarahkan semua write baru ke shard yang sama. Menjadikannya hashed mendistribusikan write secara merata.

Contoh—hash field customer_id dalam shard key compound:

sh.shardCollection(
  "examples.orders",
  { customer_id: "hashed", order_id: 1 }
)

Sebelum adanya indeks hashed compound, solusi alternatifnya adalah menghitung nilai hash secara manual, menyimpannya di field khusus, lalu menggunakan ranged sharding pada field tersebut. Pendekatan ini memerlukan logika aplikasi tambahan. Indeks hashed compound menghilangkan kebutuhan akan solusi alternatif tersebut.

Hedged reads

Hedged reads mengurangi latensi ekor (P95 dan P99) dalam kluster sharded. Saat operasi read dikeluarkan, mongos mengarahkannya ke dua anggota replica set per shard yang dikueri dan mengembalikan hasil dari respons pertama yang tiba.

Hedged reads diaktifkan per operasi sebagai bagian dari pengaturan preferensi read. Fitur ini tidak didukung ketika preferensi read diatur ke primary.

Langkah 1: Aktifkan hedged reads pada node mongos.

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

Langkah 2: Atur preferensi read per operasi. Jika preferensi read adalah nearest, hedged reads diaktifkan secara otomatis. Untuk mode lain (kecuali primary), atur hedgeOptions:

db.collection.find({}).readPref(
  "secondary",
  [{ datacenter: "B" }, {}],
  { enabled: true }
)

Metrik latensi P95 dan P99 merepresentasikan latensi rata-rata untuk 5% dan 1% permintaan paling lambat dalam 10 detik terakhir.

Streaming replication

Pada model polling, setiap pengambilan batch memerlukan waktu round-trip penuh (RTT) antara primary dan secondary. Setiap batch memiliki ukuran maksimum 16 MB. Dalam kondisi jaringan berlatensi tinggi, hal ini menurunkan performa replikasi.

Streaming replication menghemat setidaknya separuh RTT per batch. Ini memberikan dua manfaat praktis:

• Write "majority": Dalam jaringan berlatensi tinggi, streaming replication meningkatkan performa rata-rata operasi write "majority" hingga 50%, karena write jenis ini menunggu replikasi ke beberapa node.

• Sesi konsisten kausal: Membaca write Anda sendiri dari secondary memerlukan secondary untuk segera mereplikasi oplog primary. Streaming replication membuat hal ini andal.

Simultaneous indexing

Membuat indeks terlebih dahulu di primary lalu mereplikasinya ke secondary menyebabkan lag replikasi. Beban CPU dan I/O selama pembuatan indeks, serta operasi khusus seperti collMod, dapat memblokir oplog atau mendorong secondary ke status Recovering.

Simultaneous indexing menjaga secondary tetap sinkron selama proses pembuatan. Secondary dapat melayani read sepanjang proses tersebut. Indeks hanya menjadi dapat digunakan setelah mayoritas anggota voting menyelesaikan pembuatannya, sehingga mencegah skenario pemisahan baca/tulis mengembalikan hasil yang tidak konsisten akibat perbedaan indeks.

Mirrored reads

Setelah failover, primary yang baru terpilih mulai dengan cache dingin. Read yang masuk menghasilkan cache miss, dan data harus dimuat ulang dari disk—menyebabkan lonjakan latensi yang signifikan hingga cache menghangat. Efek ini paling terasa pada instans dengan memori besar.

Bacaan yang dicerminkan menghangatkan cache sekunder terlebih dahulu dengan mencerminkan sebagian operasi baca primer ke sekunder yang dipilih. Jika sekunder tersebut dipilih, cachenya sudah dalam keadaan hangat.

Mirrored reads bersifat fire-and-forget: primary tidak menunggu respons, sehingga tidak berdampak pada performa primary. Workload secondary meningkat.

Atur laju sampling dengan parameter mirrorReads (default: 1%):

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

Periksa statistik mirrored read:

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

Resumable initial sync

Secara default, secondary mencoba melanjutkan selama 24 jam. Gunakan replication.initialSyncTransientErrorRetryPeriodSeconds untuk menyesuaikan periode retry atau mengubah sumber sinkronisasi.

Jika error jaringan bersifat non-transien, secondary harus memulai ulang seluruh initial sync terlepas dari apa pun.

Time-based oplog retention

Oplog adalah koleksi capped yang mencatat semua operasi yang memodifikasi data. Oplog digunakan untuk replikasi, cadangan inkremental, migrasi data, dan konsumen change stream. Sejak MongoDB 3.6, replSetResizeOplog menyesuaikan ukuran maksimum oplog dalam byte—tetapi tidak ada jaminan bahwa entri oplog dalam rentang waktu tertentu akan dipertahankan.

Retensi berbasis waktu mengatasi skenario seperti:

• Secondary dimatikan untuk maintenance terjadwal dari pukul 02.00 hingga 04.00. Tanpa retensi oplog yang cukup, primary dapat memicu full sync saat secondary terhubung kembali.

• Konsumen change stream offline hingga 3 jam. Jika oplog bergulir selama jendela tersebut, konsumen tidak dapat melanjutkan dari posisi terakhir.

Atur periode retensi minimum menggunakan storage.oplogMinRetentionHours:

// Periksa nilai yang saat ini dikonfigurasi
db.getSiblingDB("admin").serverStatus().oplogTruncation.oplogMinRetentionHours

// Atur retensi minimum menjadi 2 jam
db.adminCommand({
  replSetResizeOplog: 1,
  minRetentionHours: 2
})

$unionWith

$unionWith menggabungkan output pipeline satu koleksi dengan output koleksi lainnya. Beberapa stage $unionWith dapat dirangkai untuk menggabungkan hasil dari banyak koleksi.

Contoh: Sebuah bisnis menyimpan data pesanan di tiga koleksi berdasarkan bulan. Untuk membuat laporan penjualan triwulan:

// Masukkan data sampel
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 }
]);

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

Output yang diharapkan:

[
  { _id: "A", total: 150 },
  { _id: "C", total: 120 },
  { _id: "B", total: 30 },
  { _id: "D", total: 10 }
]

Sebelum $unionWith, agregasi lintas koleksi memerlukan pembacaan semua data di lapisan aplikasi atau penggunaan data warehouse.

Setiap stage $unionWith juga menerima parameter pipeline, yang memungkinkan Anda memfilter atau mentransformasi data tiap koleksi sebelum menggabungkannya.

Ekspresi agregasi kustom

MongoDB 4.4 menambahkan dua operator yang memungkinkan Anda mendefinisikan logika JavaScript kustom di dalam aggregation pipeline.

$accumulator — bekerja mirip MapReduce. Gunakan untuk mengagregasi data lintas dokumen dengan manajemen state kustom:

• init: menginisialisasi state untuk setiap grup.

• accumulate: memperbarui state untuk setiap dokumen.

• merge: menggabungkan state saat dijalankan pada koleksi sharded.

• finalize (opsional): mentransformasi state gabungan menjadi hasil akhir.

$function — bekerja mirip $where tetapi terintegrasi dengan stage pipeline lainnya. Gunakan dengan $expr dalam perintah find sebagai ekuivalen langsung dari $where.

{ $accumulator: {
    init: function() { return { count: 0, sum: 0 }; },
    accumulate: function(state, value) {
      return { count: state.count + 1, sum: state.sum + value };
    },
    accumulateArgs: ["$price"],
    merge: function(s1, s2) {
      return { count: s1.count + s2.count, sum: s1.sum + s2.sum };
    },
    finalize: function(state) { return state.sum / state.count; },
    lang: "js"
} }

Operator aggregation pipeline baru

Selain $accumulator dan $function, MongoDB 4.4 memperkenalkan operator-operator berikut:

Pemantauan dan pooling koneksi

MongoDB 4.4 menstandarkan API untuk mengonfigurasi dan memantau connection pools melalui driver. Berlangganan event connection pool—termasuk koneksi yang dibuka dan ditutup, serta pembersihan pool—menggunakan API event standar.

Opsi pool yang dapat dikonfigurasi meliputi:

• Jumlah koneksi maksimum dan minimum

• Waktu maksimum koneksi dapat menganggur

• Waktu maksimum thread menunggu koneksi yang tersedia

Untuk daftar lengkap opsi, lihat Connection pool options.

Global read and write concerns

Atur default global dengan setDefaultRWConcern:

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

Ambil default global saat ini dengan getDefaultRWConcern:

db.adminCommand({ getDefaultRWConcern: 1 })

MongoDB 4.4 juga mencatat provenance setiap read atau write concern dalam log kueri lambat dan log diagnostik:

MongoDB Shell baru (beta)

MongoDB 4.4 hadir dengan MongoDB Shell baru yang meningkatkan pengalaman developer melalui:

• Penyorotan sintaks

• Pengisian otomatis perintah

• Pesan error yang lebih jelas

Shell baru ini masih dalam tahap beta. Gunakan untuk eksplorasi dan pengujian, bukan untuk skrip produksi, sambil menunggu pengembangan perintah tambahan.

Ringkasan

MongoDB 4.4 adalah rilis maintenance yang berfokus pada keandalan, fleksibilitas operasional, dan produktivitas developer. Selain fitur-fitur yang dijelaskan di atas, rilis ini mencakup:

• Optimisasi operator agregasi $indexStats

• Dukungan koneksi TCP Fast Open (TFO)

• Optimisasi penghapusan indeks

• Pencatatan log terstruktur (logv2)

• Mekanisme autentikasi baru

Untuk daftar lengkap perubahan, lihat Release notes for MongoDB 4.4.