Pengumpulan sampah di Amazon DocumentDB - Amazon DocumentDB
Memahami Pengumpulan Sampah di Amazon DocumentDBProses pengumpulan sampahArsitektur penyimpanan dan penyimpanan yang diperluasMemantau pengumpulan sampahContoh keluaran CollStatsPertanyaan umum

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Pengumpulan sampah di Amazon DocumentDB

Amazon DocumentDB mengimplementasikan arsitektur database kontrol konkurensi multi-versi (MVCC) yang membuat versi baru entri dokumen dan indeks untuk setiap operasi pembaruan. Arsitektur ini menyediakan memungkinkan isolasi transaksi, mencegah perubahan satu transaksi muncul di transaksi lain.

Memahami Pengumpulan Sampah di Amazon DocumentDB

Pengumpulan sampah (GC) adalah proses latar belakang otomatis yang mempertahankan kinerja dan ketersediaan sistem yang optimal di Amazon DocumentDB. Seperti banyak database modern, arsitektur MVCC Amazon DocumentDB membuat versi dokumen dan indeks baru dengan setiap pembaruan. Setiap operasi penulisan menggunakan ID MVCC unik dari penghitung terbatas. Ini IDs mengidentifikasi transaksi mana yang dimiliki versi dokumen dan apakah telah dilakukan atau dibatalkan. Seiring waktu, versi lama ini dan MVCC mereka IDs menumpuk, membutuhkan pembersihan untuk mencegah penurunan kinerja.

Fungsi pengumpulan sampah

Pengumpul sampah melayani tiga fungsi penting:

  • Mendapatkan kembali ruang penyimpanan - Ini menghapus dokumen usang dan versi indeks yang tidak lagi diperlukan oleh kueri aktif, membebaskan ruang untuk operasi penulisan di masa depan.

  • Mencegah luapan ID MVCC — Ini mencegah luapan ID MVCC dengan mengelola penghitung terbatas MVCC. IDs Tanpa manajemen ini, penghitung pada akhirnya akan mencapai batasnya, memaksa database ke mode read-only sementara sampai IDs didaur ulang.

  • Mempertahankan kinerja kueri — Ini mempertahankan kinerja kueri yang optimal dengan menghilangkan versi dokumen mati yang jika tidak akan menumpuk dan memperlambat pemrosesan kueri.

Proses pengumpulan sampah

Proses GC beroperasi per koleksi dan dapat memiliki beberapa proses yang berjalan secara bersamaan pada koleksi yang berbeda. Prosesnya terdiri dari empat fase berurutan:

  1. Identifikasi — Sistem mengidentifikasi versi dokumen dan indeks yang tidak lagi direferensikan oleh transaksi atau kueri aktif.

  2. Memory loading — Dokumen lama dan entri indeks dimuat ke dalam memori jika belum ada.

  3. Penghapusan - Versi usang dihapus secara permanen untuk merebut kembali ruang penyimpanan.

  4. Daur ulang ID MVCC — Sistem mendaur ulang MVCC IDs dari versi yang dihapus untuk operasi baru.

Ketika pengumpulan sampah selesai memproses versi dokumen lama, ia menghapus MVCC tertua IDs dari sistem. Pembersihan ini sangat penting untuk mencegah luapan ID MVCC dengan mendaur ulang MVCC IDs, membuatnya tersedia untuk operasi penulisan baru di seluruh cluster. Tanpa proses daur ulang ini, sistem pada akhirnya akan menghabiskan penghitung ID MVCC yang terbatas dan memasuki status hanya-baca.

Penjadwalan pengumpulan sampah

Pengumpulan sampah berjalan secara otomatis di latar belakang pada interval berkala. Waktu dan frekuensi menyesuaikan secara dinamis berdasarkan beban sistem, sumber daya yang tersedia, volume tulis, dan tingkat konsumsi ID MVCC. Selama aktivitas tulis tinggi, proses GC mengeksekusi lebih sering untuk mengelola peningkatan jumlah versi dokumen.

Arsitektur penyimpanan dan penyimpanan yang diperluas

Amazon DocumentDB menggunakan arsitektur penyimpanan canggih yang memisahkan penyimpanan dokumen menjadi dua segmen berbeda:

Segmen penyimpanan dasar

Segmen penyimpanan dasar berisi data dokumen utama dan metadata. Segmen ini menyimpan:

  • Konten dokumen yang sesuai dengan ukuran halaman standar (8 KB).

  • Mendokumentasikan metadata dan informasi struktur.

  • Indeks primer dan entri mereka.

  • Statistik dan konfigurasi tingkat koleksi.

Segmen penyimpanan yang diperluas

Segmen penyimpanan yang diperluas menggunakan toko objek dokumen besar khusus yang dirancang untuk menangani dokumen yang melebihi ukuran halaman penyimpanan standar. Segmen ini menyediakan:

  • Penanganan Dokumen Besar yang Efisien — Dokumen yang lebih besar dari ambang penyimpanan dasar secara otomatis dipindahkan ke segmen penyimpanan yang diperluas.

  • Tata Letak Penyimpanan yang Dioptimalkan - Segmen ini menggunakan format penyimpanan berbeda yang dioptimalkan untuk objek besar, mengurangi fragmentasi dan meningkatkan pola akses.

  • Pengumpulan Sampah Independen — Segmen penyimpanan yang diperluas memiliki proses pengumpulan sampah sendiri yang dapat berjalan secara independen dari pembersihan penyimpanan dasar.

  • Akses Transparan — Aplikasi mengakses dokumen besar dengan mulus tanpa perlu mengetahui segmen penyimpanan mana yang berisi data.

Segmen penyimpanan yang diperluas sangat bermanfaat untuk:

  • Koleksi dengan dokumen yang berisi array tertanam besar.

  • Dokumen dengan struktur bersarang yang luas.

  • Koleksi menyimpan data biner atau bidang teks besar.

  • Aplikasi dengan ukuran dokumen campuran di mana beberapa dokumen secara signifikan melebihi ukuran rata-rata.

Memantau pengumpulan sampah

Metrik tingkat cluster

AvailableMVCCIds

  • Lokasi - Amazon CloudWatch

  • Deskripsi — Penghitung yang menunjukkan jumlah operasi tulis yang tersisa yang tersedia dari batas maksimum 1,8 miliar. Saat penghitung ini mencapai nol, klaster Anda memasuki mode hanya-baca hingga direklamasi dan IDs didaur ulang. Penghitung berkurang dengan setiap operasi penulisan dan meningkat saat pengumpulan sampah mendaur ulang IDs MVCC lama.

  • Rekomendasi — Atur alarm saat nilainya turun di bawah 1,3 miliar. Peringatan dini ini memungkinkan Anda untuk mengambil langkah-langkah yang disarankan dibahas nanti.

LongestActiveGCRuntime

  • Lokasi - Amazon CloudWatch

  • Deskripsi — Durasi dalam hitungan detik dari proses pengumpulan sampah aktif terpanjang. Memperbarui setiap menit dan hanya melacak operasi aktif, tidak termasuk proses yang selesai dalam jendela satu menit.

  • Rekomendasi — Bandingkan dengan data gcRuntimeStats historis untuk mengidentifikasi perilaku pengumpulan sampah yang tidak normal, seperti runtime yang diperpanjang selama penghapusan massal.

Metrik tingkat pengumpulan

MVCCIDStats: MVCCIdScale

  • Lokasi - Perintah CollStats Database

  • Deskripsi — Mengukur usia ID MVCC pada skala 0 hingga 1, di mana 1 menunjukkan usia maksimum sebelum klaster memasuki status hanya-baca. Gunakan metrik ini bersama AvailableMVCCIds untuk mengidentifikasi koleksi yang berisi MVCC tertua IDs yang menua cluster.

  • Rekomendasi - Pertahankan nilai di bawah 0,3 untuk setiap koleksi.

gcRuntimeStats

  • Lokasi - Perintah CollStats Database

  • Deskripsi — Memberikan riwayat metrik pengumpulan sampah selama dua bulan, termasuk total proses, durasi rata-rata, dan durasi maksimum. Hanya mencakup operasi pengumpulan sampah yang berlangsung lebih dari lima menit untuk memastikan statistik yang berarti.

penting

gcRuntimeStats,documentFragmentStats, dan pemecahan metrik tingkat koleksi menjadi storageSegmentBase dan hanya storageSegmentExtended tersedia untuk Amazon DocumentDB 8.0.

storageSizeStats

  • Lokasi - Perintah CollStats Database

  • Deskripsi - Memberikan rincian rinci pemanfaatan penyimpanan di segmen penyimpanan yang berbeda:

    • storageSegmentBase— Penyimpanan yang digunakan oleh segmen penyimpanan dasar untuk dokumen standar

    • storageSegmentExtended— Penyimpanan yang digunakan oleh segmen penyimpanan yang diperluas untuk dokumen besar

  • Penggunaan - Membantu mengidentifikasi koleksi dengan penyimpanan dokumen besar yang signifikan dan memahami pola distribusi penyimpanan.

unusedStorageSize(tingkat pengumpulan)

  • Lokasi - Perintah CollStats Database

  • Deskripsi — Memperkirakan ruang penyimpanan yang tidak digunakan dalam koleksi berdasarkan statistik sampel. Ini termasuk ruang dari dokumen yang dihapus dan segmen kosong. Metrik ini menyediakan total gabungan dan kerusakan per segmen:

    • Gabungan unusedBytes dan unusedPercent di semua segmen penyimpanan

    • storageSegmentBase— Ruang yang tidak terpakai khususnya di segmen penyimpanan dasar

    • storageSegmentExtended— Ruang yang tidak terpakai khususnya di segmen penyimpanan yang diperluas

documentFragmentStats

  • Lokasi - Perintah CollStats Database

  • Deskripsi — Memberikan informasi rinci tentang fragmen dokumen dan data mati dalam koleksi. Fragmen dokumen mewakili unit penyimpanan internal yang digunakan oleh mesin database, dan fragmen mati menunjukkan data yang tidak lagi dapat diakses tetapi belum direklamasi. Metrik ini meliputi:

    • totalDocFragmentsCount— Jumlah total fragmen dokumen dalam koleksi

    • deadDocFragmentsCount— Jumlah fragmen yang berisi data mati (tidak dapat diakses)

    • deadDocFragmentsPercent— Persentase fragmen yang berisi data mati

    • deadDocFragmentBytes— Perkiraan byte yang dikonsumsi oleh fragmen dokumen mati

    • Rincian per segmen untuk dan storageSegmentBase storageSegmentExtended

  • Penggunaan — Pantau metrik ini untuk memahami efektivitas pengumpulan sampah dan mengidentifikasi koleksi yang mungkin mendapat manfaat dari operasi pemeliharaan. Persentase fragmen mati yang tinggi menunjukkan bahwa pengumpulan sampah mungkin tertinggal atau bahwa pengumpulan akan mendapat manfaat dari pengoptimalan.

Metrik tingkat indeks

unusedStorageSize(tingkat indeks)

  • Lokasi - Perintah Database IndexStats

  • Deskripsi — Memperkirakan ruang penyimpanan yang tidak digunakan dalam indeks berdasarkan statistik sampel. Ini termasuk ruang dari entri indeks usang dan segmen kosong.

  • Rekomendasi — Gunakan reIndex perintah untuk membangun kembali indeks tanpa downtime dan merebut kembali ruang yang tidak digunakan. Lihat Mengelola Indeks untuk detail selengkapnya.

Contoh keluaran CollStats

Contoh berikut menunjukkan collStats output tipikal dengan pengumpulan sampah dan metrik penyimpanan:

{
    "ns" : "Mvcc_consumption_test_db.mvcc_test_collection",
    "MVCCIdStats" : {
        "MVCCIdScale" : 0.03
    },
    "gcRuntimeStats" : {
        "numRuns" : 1,
        "historicalAvgRuntime" : 3295,
        "historicalMaxRuntime" : 3295,
        "lastRuntime" : 3295,
        "lastRuntimeStart" : ISODate("2025-06-24T08:47:14Z")
    },
    "documentFragmentStats" : {
        "totalDocFragmentsCount" : 45000000,
        "deadDocFragmentsCount" : 2250000,
        "deadDocFragmentsPercent" : 5.0,
        "deadDocFragmentBytes" : 98304000,
        "storageSegmentBase" : {
            "totalDocFragmentsCount" : 30000000,
            "deadDocFragmentsCount" : 1500000,
            "deadDocFragmentsPercent" : 5.0,
            "deadDocFragmentBytes" : 65536000
        },
        "storageSegmentExtended" : {
            "totalDocFragmentsCount" : 15000000,
            "deadDocFragmentsCount" : 750000,
            "deadDocFragmentsPercent" : 5.0,
            "deadDocFragmentBytes" : 32768000
        }
    },
    "collScans" : 14,
    "count" : 30000000,
    "size" : 1320000000,
    "avgObjSize" : 44,
    "storageSize" : 6461497344,
    "storageSizeStats" : {
        "storageSegmentBase" : 4307664896,
        "storageSegmentExtended" : 2153832448
    },
    "capped" : false,
    "nindexes" : 2,
    "totalIndexSize" : 9649553408,
    "indexSizes" : {
        "_id_" : 1910661120,
        "c_1" : 7738892288
    },
    "unusedStorageSize" : {
        "unusedBytes" : 4201881600,
        "unusedPercent" : 65.05,
        "storageSegmentBase" : {
            "unusedBytes" : 2801254400,
            "unusedPercent" : 65.05
        },
        "storageSegmentExtended" : {
            "unusedBytes" : 1400627200,
            "unusedPercent" : 65.05
        }
    },
    "cacheStats" : {
        "collBlksHit" : 171659016,
        "collBlksRead" : 754061,
        "collHitRatio" : 99.5627,
        "idxBlksHit" : 692563636,
        "idxBlksRead" : 1177921,
        "idxHitRatio" : 99.8303
    },
    "idxScans" : 41823984,
    "opCounter" : {
        "numDocsIns" : 0,
        "numDocsUpd" : 20911992,
        "numDocsDel" : 0
    },
    "lastReset" : "2025-06-24 05:57:08.219711+00",
    "ok" : 1,
    "operationTime" : Timestamp(1750968826, 1)
}

Pertanyaan umum

Bagaimana cara mengidentifikasi jika pengumpulan sampah tidak bekerja secara efisien?

Pantau tanda-tanda peringatan ini yang menunjukkan pengumpulan sampah yang tidak efisien:

  • Excess Collection Bloat — unusedStorageSize Metrik yang terus meningkat selama penulisan berat atau penghapusan massal, terutama dengan indeks besar.

  • Persentase Fragmen Mati Tinggi - documentFragmentStats menunjukkan deadDocFragmentsPercent nilai tinggi secara konsisten (di atas 10-15%).

  • Latensi Kueri Terdegradasi — Peningkatan latensi kueri karena akumulasi dokumen mati.

  • Durasi GC yang Diperpanjang — Operasi pengumpulan sampah memakan waktu lebih lama dari rata-rata historis di. gcRuntimeStats

  • Elevated GC Processing — Tinggi LongestActiveGCRuntime menunjukkan bahwa pengumpul sampah tidak dapat memenuhi permintaan sistem.

Apakah pengumpulan sampah mempengaruhi kinerja database saya?

Dalam kondisi normal, pengumpulan sampah memiliki dampak kinerja minimal. Namun, ketika pengumpulan sampah tertinggal, Anda mungkin mengalami:

  • Peningkatan biaya penyimpanan dari akumulasi dokumen mati.

  • Kinerja kueri lebih lambat karena entri indeks usang.

  • Mode hanya-baca sementara jika MVCC habis IDs .

  • Penggunaan sumber daya yang lebih tinggi selama proses pengumpulan intensif, terutama pada instance yang lebih kecil.

  • Mengurangi efisiensi dalam operasi segmen penyimpanan yang diperluas untuk dokumen besar.

Bisakah saya memicu pengumpulan sampah secara manual?

Tidak, pengumpulan sampah di Amazon DocumentDB tidak dapat dipicu secara manual. Sistem mengelola pengumpulan sampah secara otomatis sebagai bagian dari operasi pemeliharaan internalnya.

Alarm apa yang harus saya tetapkan sebagai praktik terbaik operasional?

Sebaiknya siapkan pemantauan di tingkat cluster dan koleksi untuk memastikan kinerja optimal sistem Amazon DocumentDB Anda.

Untuk pemantauan tingkat cluster, mulailah dengan membuat CloudWatch alarm Amazon untuk AvailableMVCCIds metrik dengan ambang 1,3 miliar. Ini memberi Anda waktu yang cukup untuk mengambil tindakan sebelum metrik mencapai nol, di mana klaster Anda akan memasuki mode hanya-baca. Perlu diingat bahwa metrik ini dapat berfluktuasi berdasarkan pola penggunaan spesifik Anda - beberapa pelanggan melihatnya turun di bawah 1,3 miliar dan kemudian pulih di atas 1,5 miliar saat pengumpulan sampah menyelesaikan pekerjaannya.

Penting juga untuk memantau LongestActiveGCRuntime metrik melalui Amazon CloudWatch. Metrik ini, bersama dengangcRuntimeStats, membantu Anda memahami seberapa efisien kinerja pengumpulan sampah di seluruh sistem Anda.

Untuk pemantauan tingkat pengumpulan, fokuslah pada metrik utama ini:

  • MVCCIdScalePerhatikan peningkatan nilai yang menunjukkan MVCC IDs menua dan mungkin perlu perhatian.

  • gcRuntimeStats— Identifikasi proses pengumpulan sampah yang memakan waktu yang sangat lama atau diperpanjang selama beberapa hari.

  • documentFragmentStats— deadDocFragmentsPercent Nilai monitor - persentase tinggi secara konsisten (di atas 10-15%) dapat mengindikasikan pengumpulan sampah tertinggal.

  • storageSizeStatsdan unusedStorageSize — Lacak pola pemanfaatan penyimpanan dan identifikasi koleksi dengan ruang signifikan yang tidak terpakai di kedua segmen penyimpanan.

Koleksi dengan operasi menulis yang sering membutuhkan perhatian ekstra, karena mereka menghasilkan lebih banyak pekerjaan untuk pengumpul sampah. Sebaiknya periksa metrik ini lebih sering untuk koleksi dengan aktivitas menulis berat untuk memastikan pengumpulan sampah mengikuti beban kerja Anda.

Perhatikan bahwa rekomendasi pemantauan ini berfungsi sebagai titik awal. Saat Anda menjadi lebih akrab dengan perilaku sistem Anda, Anda mungkin ingin menyesuaikan ambang batas ini agar lebih sesuai dengan pola dan persyaratan penggunaan spesifik Anda.

Apa yang harus saya lakukan jika saya AvailableMVCCIds jatuh di bawah 1,3 miliar?

Jika AvailableMVCCIds metrik Anda turun di bawah 1,3 miliar, kami sarankan untuk segera mengambil tindakan untuk mencegah klaster Anda memasuki mode hanya-baca. Kami sarankan terlebih dahulu meningkatkan ukuran instans Anda untuk menyediakan lebih banyak sumber daya komputasi kepada pengumpul sampah. Ini adalah rekomendasi utama kami karena memungkinkan aplikasi Anda untuk melanjutkan operasi normal sambil memberi pengumpul sampah daya tambahan yang dibutuhkan untuk mengejar ketinggalan.

Jika penskalaan saja tidak memperbaiki situasi, sebaiknya pertimbangkan pengurangan operasi penulisan Anda. Gunakan MVCCIdScale metrik untuk mengidentifikasi koleksi spesifik mana yang berisi MVCC lama IDs yang perlu diperhatikan. Selain itu, pantau documentFragmentStats untuk mengidentifikasi koleksi dengan persentase fragmen mati tinggi yang mungkin berkontribusi terhadap inefisiensi pengumpulan sampah.

Setelah Anda mengidentifikasi koleksi ini, Anda mungkin perlu untuk sementara mengurangi operasi penulisan untuk memungkinkan pengumpulan sampah untuk mengejar ketinggalan. Selama periode pemulihan, kami sarankan untuk memantau AvailableMVCCIds metrik dengan cermat untuk memastikan tindakan Anda memiliki efek yang diinginkan. Cluster Anda dianggap sehat setelah AvailableMVCCIds nilainya kembali ke 1,5 miliar atau lebih tinggi.

Ingatlah bahwa langkah-langkah ini adalah tindakan pencegahan untuk membantu sistem Anda pulih sebelum mencapai keadaan kritis. Semakin cepat Anda mengambil tindakan setelah melihat penurunan metrik di bawah 1,3 miliar, semakin besar kemungkinan Anda untuk menghindari dampak apa pun pada operasi penulisan Anda.