ApsaraDB for MongoDB:Jumlah\ database\ dan\ tabel\ yang\ berlebihan\ menyebabkan\ instans\ tersendat\ atau\ berperilaku\ tidak\ normal

Mendiagnosis kueri lambat

Saat kontensi lock akibat terlalu banyak koleksi menyebabkan kueri lambat, log kueri lambat berisi entri seperti berikut:

2024-03-07T15:59:16.856+0800 I  COMMAND  [conn4175155] command db.collections command: count { count: "xxxxxx", query: { A: 1, B: 1 },
$readPreference: { mode: "secondaryPreferred" }, $db: "db" } planSummary: COLLSCAN keysExamined:0 keysExaminedBySizeInBytes:0
docsExamined:1 docsExaminedBySizeInBytes:208 numYields:1 queryHash:916BD9E3 planCacheKey:916BD9E3 reslen:185
locks:{ ReplicationStateTransition: { acquireCount: { w: 2 } }, Global: { acquireCount: { r: 2 } }, Database: { acquireCount: { r: 2 } },
Collection: { acquireCount: { r: 2 } }, Mutex: { acquireCount: { r: 1 } } } storage:{ data: { bytesRead: 304, timeReadingMicros: 4 },
timeWaitingMicros: { handleLock: 40, schemaLock: 134101710 } } protocol:op_query 134268ms

Dalam contoh ini, operasi count pada koleksi berisi satu dokumen memakan waktu 134.268 ms. Bidang kuncinya adalah timeWaitingMicros: { handleLock: 40, schemaLock: 134101710 }, yang menunjukkan bahwa permintaan baca menghabiskan hampir seluruh waktunya menunggu untuk mendapatkan handle lock dan schema lock di lapisan penyimpanan—bukan melakukan pekerjaan aktual.

Tabel berikut menjelaskan bidang-bidang utama dalam entri log kueri lambat:

Gunakan perintah berikut untuk mendiagnosis jumlah koleksi dan indeks sebelum mengambil tindakan:

// Menghitung jumlah koleksi dalam sebuah database
db.getSiblingDB(<dbName>).getCollectionNames().length

// Menampilkan statistik database (jumlah koleksi, jumlah indeks, jumlah dokumen, ukuran total)
db.getSiblingDB(<dbName>).stats()

// Menampilkan statistik untuk koleksi tertentu
db.getSiblingDB(<dbName>).<collectionName>.stats()

Hapus koleksi yang tidak diperlukan

Identifikasi koleksi yang sudah kedaluwarsa atau tidak lagi diperlukan, lalu hapus menggunakan dropCollection. Untuk informasi lebih lanjut, lihat dropCollection().

Hapus indeks yang tidak diperlukan

Setiap indeks membuat file disk terpisah di WiredTiger dan menambahkan dhandle terkait. Mengurangi jumlah indeks secara langsung mengurangi tekanan dhandle.

Gunakan tahap agregasi $indexStats untuk mengidentifikasi indeks yang jarang digunakan. Jalankan perintah berikut sebelum melakukan perubahan (memerlukan izin yang sesuai):

// Menampilkan statistik akses untuk semua indeks dalam sebuah koleksi
db.getSiblingDB(<dbName>).<collectionName>.aggregate({"$indexStats":{}})

Contoh output:

{
   "name" : "item_1_quantity_1",
   "key" : { "item" : 1, "quantity" : 1 },
   "host" : "examplehost.local:27018",
   "accesses" : {
      "ops" : NumberLong(1),
      "since" : ISODate("2020-02-10T21:11:23.059Z")
   }
}

Tabel berikut menjelaskan bidang-bidang utama dalam output:

Terapkan aturan berikut saat memutuskan indeks mana yang harus dihapus:

• Indeks tidak valid: Hapus indeks pada bidang yang tidak diakses oleh kueri apa pun.

• Redundansi awalan indeks: Jika indeks {a:1} dan {a:1,b:1} keduanya ada, maka {a:1} bersifat redundan—indeks {a:1,b:1} mencakup semua kueri yang akan menggunakannya.

• Urutan kueri ekuivalen: Jika indeks {a:1,b:1} dan {b:1,a:1} keduanya ada, hapus yang memiliki jumlah hit lebih sedikit. Untuk pencocokan ekuivalen, urutan bidang tidak memengaruhi hasil.

• Aturan ESR untuk kueri rentang: Bangun indeks gabungan dalam urutan Equality, Sort, Range. Untuk informasi lebih lanjut, lihat Aturan ESR (Equality, Sort, Range).

• Indeks dengan hit rendah: Indeks semacam ini sering kali diduplikasi oleh indeks dengan hit lebih tinggi. Evaluasi terhadap semua pola kueri sebelum menghapusnya.

Jika instans Anda menjalankan MongoDB 4.4 atau versi lebih baru, gunakan db.collection.hideIndex() untuk menyembunyikan indeks sebelum menghapusnya. Pantau instans selama periode tertentu untuk memastikan tidak ada kueri yang bergantung pada indeks tersebut sebelum menghapusnya secara permanen. Untuk informasi lebih lanjut, lihat db.collection.hideIndex().

// Struktur dokumen koleksi players
{
  "_id": "ObjectId(123)",
  "first_name": "John",
  "last_name": "Doe",
  "coins": 11,
  "stars": 2
}

Integrasikan data dari beberapa koleksi

Saat koleksi bertambah seiring waktu karena pola partisi berbasis waktu, menggabungkannya ke dalam satu koleksi menghilangkan masalah akumulasi tersebut.

Sebelum optimasi — database temperatures menyimpan pembacaan harian dalam koleksi terpisah:

// temperatures.march-09-2020
{ "_id": 1, "timestamp": "2020-03-09T010:00:00Z", "temperature": 29 }
{ "_id": 2, "timestamp": "2020-03-09T010:30:00Z", "temperature": 30 }
// ... total 25 pembacaan (sensor berjalan pukul 10:00–22:00, setiap 30 menit)
{ "_id": 25, "timestamp": "2020-03-09T022:00:00Z", "temperature": 26 }

// temperatures.march-10-2020
{ "_id": 1, "timestamp": "2020-03-10T010:00:00Z", "temperature": 30 }
// ...

Setiap hari baru membuat koleksi baru dan indeks _id baru. Kueri lintas hari memerlukan $lookup, yang performanya lebih buruk daripada kueri pada satu koleksi.

Setelah optimasi — satu koleksi temperatures.readings menyimpan semua data, satu dokumen per hari. Indeks default _id mendukung kueri berbasis tanggal tanpa perlu indeks tambahan untuk pembacaan setiap hari:

// temperatures.readings
{
  "_id": ISODate("2020-03-09"),
  "readings": [
    { "timestamp": "2020-03-09T010:00:00Z", "temperature": 29 },
    { "timestamp": "2020-03-09T010:30:00Z", "temperature": 30 },
    // ...
    { "timestamp": "2020-03-09T022:00:00Z", "temperature": 26 }
  ]
}
{
  "_id": ISODate("2020-03-10"),
  "readings": [
    { "timestamp": "2020-03-10T010:00:00Z", "temperature": 30 },
    { "timestamp": "2020-03-10T010:30:00Z", "temperature": 32 },
    // ...
    { "timestamp": "2020-03-10T022:00:00Z", "temperature": 28 }
  ]
}

Hal ini menghilangkan masalah pertumbuhan koleksi tak terbatas dan menghapus kebutuhan untuk membuat indeks setiap hari.

Untuk workload deret waktu, pertimbangkan penggunaan koleksi deret waktu (MongoDB 5.0 dan versi lebih baru). Untuk informasi lebih lanjut, lihat Deret Waktu.

Pisahkan instans

Jika jumlah total koleksi dalam instans mandiri ApsaraDB for MongoDB tidak dapat dikurangi, bagi data tersebut ke beberapa instans.

Migrasi ke kluster sharded menggunakan tag shard

Jika semua koleksi harus tetap berada dalam satu instans logis dan tidak dapat dikurangi, migrasikan ke instans kluster sharded dan gunakan tag shard untuk mengikat setiap koleksi ke shard tertentu. Hal ini mendistribusikan beban dhandle ke beberapa shard tanpa memerlukan perubahan aplikasi—hanya string koneksi yang berubah.

Sebagai contoh, 100.000 koleksi aktif yang dimigrasikan ke kluster 10-shard menghasilkan sekitar 10.000 koleksi per shard.

Untuk informasi lebih lanjut, lihat sh.addShardTag() dan sh.addTagRange().

Migrasi ke kluster sharded menggunakan zona

Zona bekerja sama seperti tag shard, tetapi menggunakan perintah yang lebih baru: sh.addShardToZone() dan sh.updateZoneKeyRange(). Untuk informasi lebih lanjut, lihat Kelola Zona Shard, sh.addShardToZone(), dan sh.updateZoneKeyRange().

Hindari menjalankan dropDatabase pada database dengan banyak koleksi

Saat dropDatabase dijalankan, WiredTiger secara asinkron menghapus metadata dan file fisik semua koleksi dalam database tersebut. Hal ini dapat memengaruhi replikasi primary-to-secondary, menyebabkan lag replikasi terus meningkat. Mekanisme flow control MongoDB diaktifkan selama proses ini, dan semua operasi tulis dengan {writeConcern: majority} mungkin terpengaruh.

Untuk menghindari masalah ini, gunakan salah satu pendekatan berikut:

• Hapus koleksi satu per satu dengan jeda antar penghapusan, lalu jalankan dropDatabase setelah semua koleksi dihapus.

• Gunakan DTS atau alat migrasi lain untuk memigrasikan database dan koleksi yang ingin dipertahankan ke instans baru, lalu nonaktifkan instans asli setelah migrasi selesai.

Konfigurasikan peringatan lag replikasi pada instans Anda. Jika masalah ini terjadi, ajukan tiket untuk dukungan teknis.ajukan tiketajukan tiket