ApsaraDB for MongoDB:Masalah performa akibat database dan koleksi berlebihan

Hapus koleksi yang tidak diperlukan

Identifikasi koleksi dalam database yang dapat dihapus, misalnya koleksi yang sudah kedaluwarsa atau tidak lagi digunakan. Gunakan perintah dropCollection untuk menghapusnya. Untuk informasi lebih lanjut, lihat dropCollection().

Gunakan perintah berikut untuk melihat informasi database dan koleksi:

• Jalankan perintah berikut untuk melihat jumlah koleksi dalam sebuah database.

  db.getSiblingDB(<dbName>).getCollectionNames().length

• Jalankan perintah berikut untuk melihat informasi detail tentang sebuah database, termasuk jumlah koleksi, indeks, dan dokumen, serta ukuran data total.

  // Lihat statistik untuk database tertentu.
  db.getSiblingDB(<dbName>).stats()

• Jalankan perintah berikut untuk melihat informasi detail tentang koleksi tertentu.

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

Hapus indeks yang tidak diperlukan

Mengurangi jumlah indeks juga mengurangi jumlah file disk dan struktur dhandle yang sesuai yang dipertahankan oleh mesin penyimpanan WiredTiger, yang membantu mengurangi masalah ini.

Ikuti prinsip dasar berikut untuk optimasi indeks:

• Hindari indeks yang tidak digunakan

  Jika kueri tidak pernah mengakses bidang tertentu, indeks apa pun pada bidang tersebut tidak akan digunakan. Indeks semacam itu dianggap tidak terpakai dan dapat dihapus.

• Ikuti aturan prefiks indeks

  Misalnya, jika Anda memiliki indeks {a:1} dan {a:1,b:1}, indeks pertama merupakan prefiks redundan dari yang kedua dan dapat dihapus.

• Pertimbangkan urutan bidang indeks untuk kueri equality

  Untuk pencocokan equality, urutan bidang dalam indeks komposit tidak berpengaruh. Misalnya, untuk kueri pada bidang a dan b, indeks {a:1,b:1} dan {b:1,a:1} secara fungsional setara. Anda dapat menghapus salah satu yang lebih jarang digunakan.

• Gunakan aturan ESR untuk kueri range

  Untuk membuat indeks komposit optimal bagi kueri Anda, susun bidang-bidangnya dalam urutan Equality, Sort, Range. Untuk informasi lebih lanjut, lihat Aturan ESR (Equality, Sort, Range).

• Tinjau indeks dengan jumlah hit rendah

  Indeks dengan jumlah hit rendah sering kali tumpang tindih dengan indeks yang lebih efisien. Analisis semua pola kueri terkait untuk menentukan apakah Anda dapat menghapusnya dengan aman.

Anda dapat menggunakan stage agregasi $indexStats MongoDB untuk melihat statistik semua indeks dalam sebuah koleksi. Pastikan Anda memiliki izin yang diperlukan sebelum menjalankan perintah berikut.

// Lihat statistik indeks untuk koleksi tertentu.
db.getSiblingDB(<dbName>).<collectionName>.aggregate({"$indexStats":{}})

Perintah tersebut mengembalikan output serupa contoh berikut.

{
   "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 parameter dalam informasi yang dikembalikan.

Jika Anda mengamati bahwa suatu indeks memiliki jumlah hit yang sangat rendah, misalnya accesses.ops bernilai 1, kemungkinan besar indeks tersebut redundan atau tidak terpakai sehingga dapat dipertimbangkan untuk dihapus. Jika instans MongoDB Anda versi 4.4 atau lebih baru, Anda dapat menggunakan perintah hideIndex untuk menyembunyikan indeks tersebut sebelum menghapusnya. Hal ini memungkinkan Anda memastikan tidak ada dampak negatif terhadap aplikasi dalam jangka waktu tertentu, sehingga mengurangi risiko penghapusan indeks.

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

Konsolidasikan data dari beberapa koleksi

Konsolidasikan data dari beberapa koleksi ke dalam satu koleksi untuk mengurangi jumlah total koleksi.

Sebagai contoh, database bernama temperatures menyimpan data suhu dari sensor. Sensor beroperasi dari pukul 10:00 hingga 22:00, membaca dan menyimpan data suhu setiap setengah jam. Data suhu harian disimpan dalam koleksi terpisah yang dinamai berdasarkan tanggal.

Cuplikan berikut menampilkan data sebagian dari dua koleksi, temperatures.march-09-2020 dan temperatures.march-10-2020.

• Koleksi temperatures.march-09-2020

  {
    "_id": 1,
    "timestamp": "2020-03-09T010:00:00Z",
    "temperature": 29
  }
  {
    "_id": 2,
    "timestamp": "2020-03-09T010:30:00Z",
    "temperature": 30
  }
  ...
  {
    "_id": 25,
    "timestamp": "2020-03-09T022:00:00Z",
    "temperature": 26
  }

• Koleksi temperatures.march-10-2020

  {
    "_id": 1,
    "timestamp": "2020-03-10T010:00:00Z",
    "temperature": 30
  }
  {
    "_id": 2,
    "timestamp": "2020-03-10T010:30:00Z",
    "temperature": 32
  }
  ...
  {
    "_id": 25,
    "timestamp": "2020-03-10T022:00:00Z",
    "temperature": 28
  }
  

Seiring waktu, jumlah koleksi dalam database meningkat. Karena MongoDB tidak memberlakukan batas keras pada jumlah koleksi dan model ini tidak memiliki kebijakan siklus hidup data yang jelas, jumlah koleksi dan indeks yang sesuai terus bertambah tanpa batas.

Selain masalah jumlah koleksi yang terus bertambah, model data ini menyulitkan pelaksanaan kueri yang mencakup beberapa hari. Untuk mengkueri data lintas beberapa hari guna menganalisis tren suhu jangka panjang, Anda perlu menggunakan kueri $lookup, yang kurang performanya dibandingkan kueri dalam satu koleksi.

Model data yang lebih baik adalah menyimpan semua pembacaan suhu dalam satu koleksi, dengan data harian disimpan dalam satu dokumen. Pendekatan ini merupakan contoh Bucket Pattern. Contoh berikut menunjukkan model yang dioptimalkan.

// 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
    }
  ]
}

Model yang dioptimalkan ini mengonsumsi jauh lebih sedikit resource dibandingkan model aslinya. Anda tidak perlu lagi membuat indeks berdasarkan waktu dalam sehari, dan indeks default _id pada koleksi memfasilitasi kueri berdasarkan tanggal. Ini juga menyelesaikan masalah jumlah koleksi yang tidak terbatas.

Pisahkan instans

Jika Anda tidak dapat mengurangi jumlah total database dan koleksi dalam satu instans MongoDB, pertimbangkan pemisahan logis instans database beserta perubahan yang sesuai pada aplikasi Anda.

Anda dapat menerapkan pendekatan ini dalam dua skenario:

Migrasikan ke kluster sharded dengan shard tags

Jika semua koleksi Anda berada dalam satu database dan Anda ingin mengelolanya sebagai satu instans logis, pertimbangkan migrasi data Anda ke arsitektur kluster sharded dan gunakan shard tags untuk manajemen. Metode manajemen shard tag sedikit lebih kompleks dan memerlukan langkah operasional tambahan (menggunakan sh.addShardTag dan sh.addTagRange). Namun, satu instans MongoDB tetap mengelola semua koleksi, sehingga hanya memerlukan perubahan minimal pada aplikasi Anda. Anda hanya perlu mengganti string koneksi dengan string koneksi instans kluster sharded baru.

Sebagai contoh, jika instans Anda memiliki 100.000 koleksi aktif, Anda dapat membeli instans kluster sharded baru dengan 10 shard. Ikuti proses berikut untuk mengonfigurasi instans dan migrasi data, yang akan menghasilkan 10.000 koleksi aktif per shard. Prosedurnya sebagai berikut:

1. Beli instans kluster sharded baru. Contoh ini menggunakan instans 2-shard. Untuk petunjuk cara membuat kluster sharded, lihat Create a sharded cluster instance.

2. Hubungkan ke node mongos instans kluster sharded. Untuk informasi lebih lanjut, lihat Connect to an ApsaraDB for MongoDB sharded cluster instance by using the mongo shell.

3. Jalankan perintah berikut untuk menambahkan shard tag ke setiap shard.

   sh.addShardTag("d-xxxxxxxxx1", "shard_tag1")
   sh.addShardTag("d-xxxxxxxxx2", "shard_tag2")

   Catatan

   • Sebelum menjalankan perintah ini, pastikan akun yang Anda gunakan memiliki izin yang diperlukan.

   • DMS (Data Management) saat ini tidak mendukung perintah sh.addShardTag. Kami menyarankan menghubungkan ke instans dengan mongo shell atau mongosh untuk menjalankan perintah ini.

4. Pra-konfigurasikan aturan distribusi rentang berbasis tag untuk semua koleksi yang di-shard.

   use <dbName>
   sh.enableSharding("<dbName>")
   sh.addTagRange("<dbName>.test", {"_id":MinKey}, {"_id":MaxKey}, "shard_tag1")
   sh.addTagRange("<dbName>.test1", {"_id":MinKey}, {"_id":MaxKey}, "shard_tag2")

   Contoh ini menggunakan _id sebagai kunci shard. Pilih kunci shard yang sesuai dengan workload Anda, dan pastikan semua operasi kueri menyertakan bidang kunci shard. Kunci shard harus konsisten dengan bidang yang digunakan pada langkah berikutnya. Anda juga harus menggunakan batas [MinKey,MaxKey] untuk memastikan semua data untuk satu koleksi berada di satu shard.

5. Jalankan operasi shardCollection untuk semua koleksi yang akan dimigrasikan.

   sh.shardCollection("<dbName>.test", {"_id":1})
   sh.shardCollection("<dbName>.test1", {"_id":1})

6. Jalankan perintah sh.status() untuk memastikan aturan tersebut berlaku.

   zhongli.test
           shard key: { "_id" : 1 }
           unique: false
           balancing: true
           chunks:
                   d-xxx	1
           { "_id" : { "$minKey" : 1 } } -->> { "_id" : { "$maxKey" : 1 } } on : d-xxx Timestamp(1, 0)
            tag: shard_tag1  { "_id" : { "$minKey" : 1 } } -->> { "_id" : { "$maxKey" : 1 } }
   zhongli.test1
           shard key: { "_id" : 1 }
           unique: false
           balancing: true
           chunks:
                   d-xxx	1
           { "_id" : { "$minKey" : 1 } } -->> { "_id" : { "$maxKey" : 1 } } on : d-xxx Timestamp(1, 0)
            tag: shard_tag2  { "_id" : { "$minKey" : 1 } } -->> { "_id" : { "$maxKey" : 1 } }

7. Migrate data from a replica set instance to a sharded cluster instance.

   Catatan

   Karena Anda telah melakukan pra-sharding koleksi di instans tujuan, semua informasi database dan koleksi sudah ada. Oleh karena itu, Anda harus mengatur Processing Mode of Conflicting Tables menjadi Ignore Errors and Proceed dalam tugas DTS Anda.

8. Setelah memverifikasi konsistensi data, alihkan aplikasi Anda untuk mengakses instans kluster sharded baru.

Migrasikan ke kluster sharded dengan zona

Metode ini mirip dengan penggunaan shard tags, tetapi menggunakan fitur Zones MongoDB. Metode ini memerlukan langkah operasional tambahan, khususnya sh.addShardToZone() dan sh.updateZoneKeyRange().

Prosedurnya sebagai berikut:

1. Beli instans kluster sharded baru. Contoh ini menggunakan instans 2-shard. Untuk petunjuk cara membuat kluster sharded, lihat Create a sharded cluster instance.

2. Hubungkan ke node mongos instans kluster sharded. Untuk informasi lebih lanjut, lihat Connect to an ApsaraDB for MongoDB sharded cluster instance by using the mongo shell.

3. Jalankan perintah berikut untuk menetapkan setiap shard ke zona.

   sh.addShardToZone("d-xxxxxxxxx1", "ZoneA")
   sh.addShardToZone("d-xxxxxxxxx2", "ZoneB")

   Catatan

   • Sebelum menjalankan perintah ini, pastikan akun yang Anda gunakan memiliki izin yang diperlukan.

   • DMS saat ini tidak mendukung perintah sh.addShardToZone. Kami menyarankan menghubungkan ke instans dengan mongo shell atau mongosh untuk menjalankan perintah ini.

4. Pra-konfigurasikan aturan distribusi rentang berbasis zona untuk semua koleksi.

   use <dbName>
   sh.enableSharding("<dbName>")
   sh.updateZoneKeyRange("<dbName>.test", { "_id": MinKey }, { "_id": MaxKey }, "ZoneA")
   sh.updateZoneKeyRange("<dbName>.test1", { "_id": MinKey }, { "_id": MaxKey }, "ZoneB")

   Contoh ini menggunakan _id sebagai kunci shard. Pilih kunci shard yang sesuai dengan workload Anda, dan pastikan semua operasi kueri menyertakan bidang kunci shard. Kunci shard harus konsisten dengan bidang yang digunakan pada langkah berikutnya. Anda juga harus menggunakan batas [MinKey,MaxKey] untuk memastikan semua data untuk satu koleksi berada di satu shard.

5. Jalankan operasi shardCollection untuk semua koleksi yang akan dimigrasikan.

   sh.shardCollection("<dbName>.test", { "_id": 1 })
   sh.shardCollection("<dbName>.test1", { "_id": 1 })

6. Jalankan perintah sh.status() untuk melihat distribusi sharding dan memastikan konfigurasi zona berlaku. Output contohnya sebagai berikut:

   {  "_id" : "shardDistributionDB",  "primary" : "d-xxx24",  "partitioned" : false,  "version" : {  "uuid" : UUID("1dc635xxx"),  "lastMod" : 1 } }
           shardDistributionDB.test
                   shard key: { "_id" : "hashed" }
                   unique: false
                   balancing: true
                   chunks:
                           d-2ze9797089ef3704      1
                   { "_id" : { "$minKey" : 1 } } -->> { "_id" : { "$maxKey" : 1 } } on : d-xxx04 Timestamp(1, 0)
                    tag: ZoneA  { "_id" : { "$minKey" : 1 } } -->> { "_id" : { "$maxKey" : 1 } }
           shardDistributionDB.test1
                   shard key: { "_id" : "hashed" }
                   unique: false
                   balancing: true
                   chunks:
                           d-2zed2e752c35af24      1
                   { "_id" : { "$minKey" : 1 } } -->> { "_id" : { "$maxKey" : 1 } } on : d-xxx24 Timestamp(1, 0)
                    tag: ZoneB  { "_id" : { "$minKey" : 1 } } -->> { "_id" : { "$maxKey" : 1 } }

7. Migrate data from a replica set instance to a sharded cluster instance.

   Catatan

   Karena Anda telah melakukan pra-sharding koleksi di instans tujuan, semua informasi database dan koleksi sudah ada. Oleh karena itu, Anda harus mengatur Processing Mode of Conflicting Tables menjadi Ignore Errors and Proceed dalam tugas DTS Anda.

8. Setelah memverifikasi konsistensi data, alihkan aplikasi Anda untuk mengakses instans kluster sharded baru.