View a markdown version of this page

Pengumpulan sampah di Amazon DocumentDB - Amazon DocumentDB

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 multi-version concurrency control (MVCC) yang membuat versi baru dari entri dokumen dan indeks untuk setiap operasi pembaruan. Arsitektur ini 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 optimal di Amazon DocumentDB. Seperti banyak database modern, arsitektur MVCC Amazon DocumentDB membuat dokumen baru dan versi indeks dengan setiap pembaruan. Setiap operasi penulisan menggunakan ID MVCC unik dari penghitung terbatas. ID ini mengidentifikasi transaksi yang dimiliki versi dokumen dan apakah transaksi tersebut telah dilakukan atau dibatalkan. Seiring waktu, versi lama dan ID MVCC mereka menumpuk, membutuhkan pembersihan untuk mencegah penurunan kinerja.

Fungsi pengumpulan sampah

Pengumpul sampah melayani tiga fungsi penting:

  • Mengembalikan ruang penyimpanan — Ini menghapus dokumen usang dan versi indeks yang tidak lagi diperlukan oleh kueri aktif, membebaskan ruang untuk operasi penulisan di masa mendatang.

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

  • Mempertahankan kinerja kueri — Ini mempertahankan kinerja kueri yang optimal dengan menghilangkan versi dokumen mati yang sebaliknya 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. Identi fikasi — Sistem mengidentifikasi versi dokumen dan indeks yang tidak lagi direferensikan oleh transaksi atau kueri aktif.

  2. Memuat memori - Dokumen lama dan entri indeks dimuat ke dalam memori jika belum ada.

  3. Penghapusan — Versi usang dihapus secara permanen untuk mendapatkan kembali ruang penyimpanan.

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

Ketika pengumpulan sampah selesai memproses versi dokumen lama, itu menghapus ID MVCC tertua dari sistem. Pembersihan ini sangat penting untuk mencegah meluap ID MVCC dengan mendaur ulang ID MVCC, 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 read-only.

Penjadwalan pengumpulan sampah

Pengumpulan sampah berjalan secara otomatis di latar belakang pada interval berkala. Waktu dan frekuensi disesuaikan secara dinamis berdasarkan beban sistem, sumber daya yang tersedia, volume tulis, dan tingkat konsumsi ID MVCC. Selama aktivitas penulisan tinggi, proses GC dieksekusi 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).

  • Metadata dokumen dan informasi struktur.

  • Indeks utama dan entri mereka.

  • Collection-level statistik dan konfigurasi.

Segmen penyimpanan yang diperluas

Segmen penyimpanan yang diperluas menggunakan penyimpanan 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 menggunakan format penyimpanan berbeda yang dioptimalkan untuk objek besar, mengurangi fragmentasi dan meningkatkan pola akses.

  • Pengumpulan S ampah 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. Ketika penghitung ini mencapai nol, cluster Anda memasuki mode read-only hingga ID direklamasi dan didaur ulang. Penghitung berkurang dengan setiap operasi penulisan dan meningkat saat pengumpulan sampah mendaur ulang ID MVCC lama.

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

LongestActiveGCRuntime

  • Lokasi - Amazon CloudWatch

  • Deskripsi — Durasi dalam detik dari proses pengumpulan sampah aktif terpanjang. Memperbarui setiap menit dan melacak hanya 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 koleksi

MVCCIDStats: MVCCIdScale

  • Lokasi — Perintah CollStats Database

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

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

gcRuntimeStats

  • Lokasi — Perintah CollStats Database

  • Deskripsi — Menyediakan 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.

storageSizeStats

  • Lokasi — Perintah CollStats Database

  • Deskripsi - Memberikan rincian rinci pemanfaatan penyimpanan di berbagai segmen penyimpanan:

    • 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 koleksi)

  • 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 perincian per segmen:

    • Gabungan unusedBytes dan unusedPercent di semua segmen penyimpanan

    • storageSegmentBase— Ruang yang tidak digunakan secara khusus di segmen penyimpanan dasar

    • storageSegmentExtended— Ruang yang tidak digunakan secara khusus di segmen penyimpanan yang diperluas

documentFragmentStats

  • Lokasi — Perintah CollStats Database

  • Deskripsi - Memberikan informasi terperinci 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

    • Per-segment rincian untuk storageSegmentBase dan storageSegmentExtended

  • Penggunaan — Pantau metrik ini untuk memahami efektivitas pengumpulan sampah dan mengidentifikasi pengumpulan yang mungkin mendapat manfaat dari operasi pemeliharaan. Persentase pecahan mati yang tinggi menunjukkan bahwa pengumpulan sampah mungkin tertinggal atau 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:

  • Kembung Koleksi Berle bihan — unusedStorageSize Metrik terus meningkat selama penulisan berat atau penghapusan massal, terutama dengan indeks besar.

  • Persentase Fragmen M ati documentFragmentStats Tinggi — 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 digcRuntimeStats.

  • Peningkatan Pemrosesan GC - Tinggi LongestActiveGCRuntime menunjukkan pengumpul sampah tidak dapat memenuhi tuntutan sistem.

Apakah pengumpulan sampah memengaruhi 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 baca-saja sementara jika ID MVCC habis.

  • Penggunaan sumber daya yang lebih tinggi selama proses pengumpulan intensif, terutama pada instans 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 atur sebagai praktik terbaik operasional?

Siapkan pemantauan di tingkat cluster dan pengumpulan 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 cluster Anda akan memasuki mode read-only. 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 koleksi, fokuslah pada metrik utama berikut:

  • MVCCIdScale— Perhatikan peningkatan nilai yang menunjukkan ID MVCC menua dan mungkin perlu diperhatikan.

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

  • documentFragmentStatsdeadDocFragmentsPercent 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 yang tidak terpakai yang signifikan di kedua segmen penyimpanan.

Koleksi dengan operasi penulisan yang sering membutuhkan perhatian ekstra, karena menghasilkan lebih banyak pekerjaan untuk pengumpul sampah. Periksa metrik ini lebih sering untuk koleksi dengan aktivitas penulisan berat untuk memastikan pengumpulan sampah sesuai dengan 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 AvailableMVCCIDS saya turun di bawah 1.3 miliar?

Jika AvailableMVCCIds metrik Anda turun di bawah 1,3 miliar, segera ambil tindakan untuk mencegah cluster memasuki mode read-only. Pertama, tingkatkan ukuran instans Anda untuk menyediakan lebih banyak sumber daya komputasi kepada pengumpul sampah. Hal ini memungkinkan aplikasi Anda untuk melanjutkan operasi normal sambil memberi pengumpul sampah daya tambahan yang dibutuhkan untuk mengejar ketinggalan.

Jika peningkatan skala saja tidak memperbaiki situasi, pertimbangkan untuk mengurangi operasi penulisan Anda. Gunakan MVCCIdScale metrik untuk mengidentifikasi koleksi spesifik mana yang berisi ID MVCC lama yang perlu diperhatikan. Selain itu, pantau documentFragmentStats untuk mengidentifikasi koleksi dengan persentase fragmen mati tinggi yang mungkin berkontribusi pada inefisiensi pengumpulan sampah.

Setelah Anda mengidentifikasi koleksi ini, Anda mungkin perlu mengurangi sementara operasi penulisan untuk memungkinkan pengumpulan sampah mengejar ketinggalan. Selama periode pemulihan, pantau AvailableMVCCIds metrik dengan cermat untuk memastikan tindakan Anda memiliki efek yang diinginkan. Cluster Anda dianggap sehat setelah nil AvailableMVCCIds ainya 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 metrik turun di bawah 1,3 miliar, semakin besar kemungkinan Anda untuk menghindari dampak apa pun pada operasi penulisan Anda.