本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
Amazon DocumentDB 中的垃圾回收
Amazon DocumentDB 實作多版本並行控制 (MVCC) 資料庫架構，為每個更新操作建立新的文件和索引項目版本。此架構提供啟用交易隔離，防止一個交易的變更出現在另一個交易中。
了解 Amazon DocumentDB 中的垃圾回收
垃圾回收 (GC) 是一種自動化背景程序，可在 Amazon DocumentDB 中維持最佳的系統效能和可用性。如同許多現代資料庫，Amazon DocumentDB 的 MVCC 架構會在每次更新時建立新的文件和索引版本。每個寫入操作都會從有限計數器使用唯一的 MVCC ID。這些 IDs會識別文件版本所屬的交易，以及文件版本是否已遞交或復原。隨著時間的推移，這些舊版本及其 MVCC IDs會累積，需要清除以防止效能降低。
垃圾回收的函數
垃圾收集器提供三個基本函數：
回收儲存空間 — 它移除作用中查詢不再需要的過時文件和索引版本，為未來的寫入操作釋放空間。
防止 MVCC ID 溢位 — 透過管理 MVCC ID 的有限計數器來防止 MVCC IDs 溢位。如果沒有此管理，計數器最終會達到其限制，強制資料庫進入暫時唯讀模式，直到 IDs回收為止。
維持查詢效能 — 它透過消除可能累積和減慢查詢處理的無效文件版本，來維持最佳的查詢效能。
垃圾回收程序
GC 程序會依集合操作，並且可以在不同的集合上同時執行多個程序。程序包含四個循序階段：
識別 — 系統會識別作用中交易或查詢不再參考的文件和索引版本。
記憶體載入 — 如果舊文件和索引項目尚未存在，則會載入記憶體。
刪除 — 永久刪除過時的版本以回收儲存空間。
MVCC ID 回收 — 系統會從已刪除的版本回收 MVCC IDs 以進行新操作。
當垃圾收集完成處理舊文件版本時，它會從系統中移除最舊的 MVCC IDs。此清除對於透過回收 MVCC ID 來防止 MVCC IDs 溢位至關重要，使其可用於整個叢集的新寫入操作。如果沒有此回收程序，系統最終會耗盡其有限的 MVCC ID 計數器，並進入唯讀狀態。
垃圾回收排程
垃圾回收會定期在背景中自動執行。時間和頻率會根據系統負載、可用資源、寫入磁碟區和 MVCC ID 耗用量層級動態調整。在高寫入活動期間，GC 程序會更頻繁地執行，以管理增加的文件版本數量。
儲存架構和擴充儲存
Amazon DocumentDB 使用複雜的儲存架構，將文件儲存區分成兩個不同的區段：
基本儲存區段
基本儲存區段包含主要文件資料和中繼資料。此區段存放區：
符合標準頁面大小 (8 KB) 的文件內容。
文件中繼資料和結構資訊。
主要索引及其項目。
集合層級統計資料和組態。
擴充儲存區段
延伸的儲存區段使用專門的大型文件物件存放區，旨在處理超過標準儲存頁面大小的文件。此區段提供：
高效率大型文件處理 — 大於基本儲存閾值的文件會自動移至擴充儲存區段。
最佳化儲存配置 — 區段使用針對大型物件最佳化的不同儲存格式，減少分段並改善存取模式。
獨立垃圾回收 — 延伸的儲存區段具有自己的垃圾回收程序，可以獨立於基本儲存清理執行。
透明存取 — 應用程式無縫存取大型文件，而不需要知道哪些儲存區段包含資料。
延伸的儲存區段特別有益於：
包含大型內嵌陣列之文件的集合。
具有廣泛巢狀結構的文件。
儲存二進位資料或大型文字欄位的集合。
混合文件大小的應用程式，其中某些文件明顯超過平均大小。
監控垃圾收集
叢集層級指標
AvailableMVCCIds
位置 — Amazon CloudWatch
描述 — 顯示最大限制為 18 億的剩餘寫入操作數量的計數器。當此計數器達到零時，您的叢集會進入唯讀模式IDs直到 ID 回收和回收為止。計數器會隨著每次寫入操作而減少，並隨著垃圾回收回收舊的 MVCC IDs 而增加。
建議 — 當值低於 13 億時設定警示。此提早警告可讓您採取稍後討論的建議步驟。
LongestActiveGCRuntime
位置 — Amazon CloudWatch
描述 — 最長作用中垃圾收集程序的持續時間，以秒為單位。每分鐘更新一次，並僅追蹤作用中的操作，不包括在一分鐘時段內完成的程序。
建議 — 與
gcRuntimeStats歷史資料進行比較，以識別異常的垃圾收集行為，例如在大量刪除期間延長執行時間。
集合層級指標
MVCCIDStats: MVCCIdScale
位置 — 資料庫 collStats 命令
描述 — 以 0 到 1 的規模測量 MVCC ID 存留期，其中 1 表示叢集進入唯讀狀態之前的最大存留期。將此指標與 一起
AvailableMVCCIds用於識別包含正在使叢集老化之最舊 MVCC IDs集合。建議 — 將每個集合的值保持在 0.3 以下。
gcRuntimeStats
位置 — 資料庫 collStats 命令
描述 — 提供垃圾收集指標的兩個月歷史記錄，包括總執行次數、平均持續時間和最長持續時間。僅包含持續超過五分鐘的垃圾回收操作，以確保有意義的統計資料。
重要
gcRuntimeStats、 documentFragmentStats和 將集合層級指標分解為 storageSegmentBase，storageSegmentExtended且僅適用於 Amazon DocumentDB 8.0。
storageSizeStats
位置 — 資料庫 collStats 命令
描述 — 提供不同儲存區段的儲存使用率詳細明細：
storageSegmentBase— 標準文件的基礎儲存區段所使用的儲存體storageSegmentExtended— 擴充儲存區段用於大型文件的儲存體
用量 — 協助識別具有大量大型文件儲存的集合，並了解儲存分佈模式。
unusedStorageSize （集合層級）
位置 — 資料庫 collStats 命令
描述 — 根據取樣的統計資料，估計集合中未使用的儲存空間。它包含已刪除文件和空白區段的空間。指標同時提供合併總計和每個區段明細：
在所有儲存區段
unusedPercent中結合unusedBytes和storageSegmentBase— 特別是在基本儲存區段中未使用的空間storageSegmentExtended— 特別是在擴充儲存區段中未使用的空間
documentFragmentStats
位置 — 資料庫 collStats 命令
描述 — 提供有關集合中文件片段和無效資料的詳細資訊。文件片段代表資料庫引擎使用的內部儲存單位，而無效片段則表示無法再存取但尚未回收的資料。此指標包括：
totalDocFragmentsCount— 集合中的文件片段總數deadDocFragmentsCount— 包含無效 （無法存取） 資料的片段數量deadDocFragmentsPercent— 包含無效資料的片段百分比deadDocFragmentBytes— 無效文件片段耗用的預估位元組數storageSegmentBase和 的每個區段明細storageSegmentExtended
用量 — 監控此指標以了解垃圾收集的有效性，並識別可能受益於維護操作的收集。高百分比的無效片段表示垃圾回收可能落後，或集合將受益於最佳化。
索引層級指標
unusedStorageSize （索引層級）
Location — 資料庫 indexStats 命令
描述 — 根據取樣的統計資料，估計索引中未使用的儲存空間。它包含來自過時索引項目和空白區段的空間。
建議 — 使用
reIndex命令來重建索引，無需停機時間並回收未使用的空間。如需詳細資訊，請參閱管理索引。
collStats 輸出範例
下列範例顯示具有垃圾收集和儲存指標的典型collStats輸出：
{ "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) }
常見問答集
如何識別垃圾回收是否無法有效運作？
監控這些警告訊號，指出垃圾回收效率不佳：
過多的集合 Bloat — 在大量寫入或大量刪除期間穩定增加
unusedStorageSize指標，尤其是大型索引。高無效片段百分比 —
documentFragmentStats持續顯示高deadDocFragmentsPercent值 （高於 10-15%)。查詢延遲降級 — 由於累積的無效文件而增加的查詢延遲。
延長 GC 持續時間 — 垃圾回收操作耗時超過 中的歷史平均值
gcRuntimeStats。提升 GC 處理 — 高
LongestActiveGCRuntime表示垃圾收集器無法跟上系統需求。
垃圾回收是否會影響我的資料庫效能？
在正常情況下，垃圾回收對效能的影響最小。不過，當垃圾回收落後時，您可能會遇到：
從累積的無效文件增加儲存成本。
因索引項目過時而降低查詢效能。
如果 MVCC IDs，則為暫時唯讀模式。
密集收集執行期間較高的資源使用量，特別是在較小的執行個體上。
降低大型文件擴充儲存區段操作的效率。
我可以手動觸發垃圾回收嗎？
否，Amazon DocumentDB 中的垃圾回收無法手動觸發。系統會自動管理垃圾回收，做為其內部維護操作的一部分。
我應該將哪些警示設定為操作最佳實務？
我們建議在叢集和集合層級設定監控，以確保 Amazon DocumentDB 系統的最佳效能。
對於叢集層級監控，請先為閾值為 13 億的AvailableMVCCIds指標建立 Amazon CloudWatch 警示。這可讓您有足夠的時間在指標達到零之前採取動作，此時您的叢集會進入唯讀模式。請記住，此指標可能會根據您的特定使用模式而波動，有些客戶會看到它低於 13 億，然後隨著垃圾回收完成其工作而復原超過 15 億。
透過 Amazon CloudWatch 監控LongestActiveGCRuntime指標也很重要。此指標與 gcRuntimeStats可協助您了解整個系統垃圾收集的效率。
對於集合層級監控，請專注於這些關鍵指標：
MVCCIdScale— 留意顯示 MVCC IDs 正在老化且可能需要注意的增加值。gcRuntimeStats— 識別需要異常長時間或持續數天的垃圾回收程序。documentFragmentStats— 監控deadDocFragmentsPercent值 - 持續高百分比 （超過 10-15%) 可能表示垃圾回收落後。storageSizeStats和unusedStorageSize— 追蹤儲存使用率模式，並在任一儲存區段中識別具有顯著未使用空間的集合。
具有頻繁寫入操作的集合需要額外注意，因為它們為垃圾收集器產生更多工作。對於具有繁重寫入活動的集合，我們建議您更頻繁地檢查這些指標，以確保垃圾收集與您的工作負載保持一致。
請注意，這些監控建議做為起點。當您更熟悉系統的行為時，建議您調整這些閾值，以更符合您的特定使用模式和需求。
如果我的 AvailableMVCCIds 低於 13 億，該怎麼辦？
如果您的AvailableMVCCIds指標低於 13 億，建議您立即採取行動，以防止您的叢集進入唯讀模式。我們建議您先擴展執行個體大小，為垃圾收集器提供更多運算資源。這是我們的主要建議，因為它可讓您的應用程式繼續正常操作，同時為垃圾收集器提供追上所需的額外能力。
如果單獨擴展無法改善情況，建議您考慮減少寫入操作。使用 MVCCIdScale 指標來識別哪些特定集合包含需要注意的較舊 MVCC IDs。此外，監控 documentFragmentStats 以識別具有高無效片段百分比的集合，這些百分比可能會導致垃圾回收效率低下。
識別這些集合之後，您可能需要暫時減少這些集合的寫入操作，以允許垃圾收集追上進度。在復原期間，我們建議您密切監控 AvailableMVCCIds 指標，以確保您的動作具有所需的效果。一旦AvailableMVCCIds值回到 15 億或更高，您的叢集就會被視為運作狀態良好。
請記住，這些步驟是預防措施，可協助您的系統在達到嚴重狀態之前復原。看到指標降到 13 億以下之後，您採取動作的速度越快，就越有可能避免對寫入操作造成任何影響。
