翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon DocumentDB のガベージコレクション
Amazon DocumentDB は、更新オペレーションごとにドキュメントエントリとインデックスエントリの新しいバージョンを作成するマルチバージョン同時実行制御 (MVCC) データベースアーキテクチャを実装します。このアーキテクチャにより、トランザクションの分離が可能になり、あるトランザクションの変更が別のトランザクションに表示されなくなります。
**Topics**
+ [Amazon DocumentDB のガベージコレクションについて](#understanding-garbage-collection)
+ [ガベージコレクションプロセス](#garbage-collection-process)
+ [ストレージアーキテクチャと拡張ストレージ](#storage-architecture)
+ [ガベージコレクションのモニタリング](#monitoring-garbage-collection)
+ [collStats 出力の例](#example-collstats-output)
+ [よくある質問](#garbage-collection-faq)
## Amazon DocumentDB のガベージコレクションについて
ガベージコレクション (GC) は、Amazon DocumentDB で最適なシステムパフォーマンスと可用性を維持する自動化されたバックグラウンドプロセスです。多くの最新のデータベースと同様に、Amazon DocumentDB の MVCC アーキテクチャは、更新ごとに新しいドキュメントバージョンとインデックスバージョンを作成します。各書き込みオペレーションは、有限カウンターから一意の MVCC ID を消費します。これらの IDsは、ドキュメントバージョンが属するトランザクションと、コミットされたかロールバックされたかを識別します。時間の経過とともに、これらの古いバージョンとその MVCC IDsが蓄積され、パフォーマンスの低下を防ぐためにクリーンアップが必要になります。
### ガベージコレクションの機能
ガベージコレクターには 3 つの重要な機能があります。
+ **ストレージスペースの再利用** — アクティブなクエリで不要になった古いドキュメントバージョンとインデックスバージョンを削除し、将来の書き込みオペレーションのためのスペースを解放します。
+ **MVCC ID オーバーフローの防止** — MVCC ID の有限カウンターを管理することで、MVCC ID のオーバーフローを防止します。この管理を行わないと、カウンターは最終的に制限に達し、ID がリサイクルされるまで、データベースを強制的に一時的な読み取り専用モードにします。
+ **クエリパフォーマンスを維持** — そうしない場合にクエリ処理が蓄積および遅くなるデッドドキュメントバージョンを排除することで、最適なクエリパフォーマンスを維持します。
## ガベージコレクションプロセス
GC プロセスはコレクションごとに動作し、異なるコレクションで複数のプロセスを同時に実行できます。このプロセスは 4 つのシーケンシャルフェーズで構成されます。
1. **識別** — システムは、アクティブなトランザクションまたはクエリによって参照されなくなったドキュメントバージョンとインデックスバージョンを識別します。
1. **メモリロード**—古いドキュメントとインデックスエントリがメモリに存在しない場合、メモリにロードされます。
1. **削除** — 古いバージョンは、ストレージ容量を再利用するために完全に削除されます。
1. **MVCC ID リサイクル** — システムは、新しいオペレーションのために、削除されたバージョンの MVCC ID をリサイクルします。
ガベージコレクションが古いドキュメントバージョンの処理を完了すると、システムから最も古い MVCC ID が削除されます。このクリーンアップは、MVCC ID をリサイクルして MVCC ID のオーバーフローを防ぎ、クラスター全体の新しい書き込みオペレーションで使用できるようにするために不可欠です。このリサイクルプロセスがないと、システムは最終的に有限の MVCC ID カウンターを使い果たし、読み取り専用状態になります。
### ガベージコレクションのスケジューリング
ガベージコレクションは、定期的にバックグラウンドで自動的に実行されます。タイミングと頻度は、システム負荷、使用可能なリソース、書き込み容量、MVCC ID 消費レベルに基づいて動的に調整されます。書き込みアクティビティが多い場合、GC プロセスはより頻繁に実行され、ドキュメントバージョン数の増加を管理します。
## ストレージアーキテクチャと拡張ストレージ
Amazon DocumentDB は、ドキュメントストレージを 2 つの異なるセグメントに分割する高度なストレージアーキテクチャを使用します。
### ベースストレージセグメント
ベースストレージセグメントには、プライマリドキュメントデータとメタデータが含まれます。このセグメントは以下を保存します。
+ 標準ページサイズ (8 KB) に収まるコンテンツを文書化します。
+ ドキュメントメタデータと構造情報。
+ プライマリインデックスとそのエントリ。
+ コレクションレベルの統計と設定。
### 拡張ストレージセグメント
拡張ストレージセグメントは、標準ストレージページサイズを超えるドキュメントを処理するように設計された特殊なラージドキュメントオブジェクトストアを使用します。このセグメントは以下を提供します。
+ **効率的な大規模ドキュメント処理 — **ベースストレージのしきい値を超えるドキュメントは、拡張ストレージセグメントに自動的に移動されます。
+ **最適化ストレージレイアウト** — セグメントは、大きなオブジェクト用に最適化された異なるストレージ形式を使用するため、断片化が軽減され、アクセスパターンが向上します。
+ **独立したガベージコレクション** — 拡張ストレージセグメントには、ベースストレージのクリーンアップとは独立して実行できる独自のガベージコレクションプロセスがあります。
+ **透過的なアクセス** — アプリケーションは、データを含むストレージセグメントを知ることなく、大規模なドキュメントにシームレスにアクセスします。
拡張ストレージセグメントは、以下にとって特に有益です。
+ 大きな埋め込み配列を含むドキュメントを含むコレクション。
+ 広範なネスト構造を持つドキュメント。
+ バイナリデータまたは大きなテキストフィールドを保存するコレクション。
+ 一部のドキュメントが平均サイズを大幅に超える、ドキュメントサイズが混在するアプリケーション。
## ガベージコレクションのモニタリング
### クラスターレベルのメトリクス
**`AvailableMVCCIds`**
+ **場所** — Amazon CloudWatch
+ **説明** — 最大制限 18 億から使用可能な残りの書き込みオペレーションの数を示すカウンター。このカウンターがゼロに達すると、ID が再利用されてリサイクルされるまで、クラスターは読み取り専用モードになります。カウンターは書き込みオペレーションごとに減少し、ガベージコレクションが古い MVCC ID をリサイクルすると増加します。
+ **推奨事項** — 値が 13 億を下回ったときにアラームを設定します。この早期警告により、後で説明する推奨手順を実行できます。
**`LongestActiveGCRuntime`**
+ **場所** — Amazon CloudWatch
+ **説明** — 最も長いアクティブなガベージコレクションプロセスの秒単位の期間。1 分ごとに更新し、1 分以内に完了したプロセスを除き、アクティブなオペレーションのみを追跡します。
+ **推奨事項** — `gcRuntimeStats`履歴データと比較して、一括削除中の拡張ランタイムなど、異常なガベージコレクション動作を特定します。
### コレクションレベルのメトリクス
**`MVCCIDStats: MVCCIdScale`**
+ **場所** — Database collStats コマンド
+ **説明** — 0～1 のスケールで MVCC ID の経過時間を測定します。1 は、クラスターが読み取り専用状態になる前の最大経過時間を示します。このメトリクスを `AvailableMVCCIds` と一緒に使用して、クラスターを古くしている最も古い MVCC ID を含むコレクションを識別します。
+ **推奨事項** — コレクションごとに 0.3 未満の値を維持します。
**`gcRuntimeStats`**
+ **場所** — Database collStats コマンド
+ **説明** — 合計実行数、平均期間、最大期間など、ガベージコレクションメトリクスの 2 か月の履歴を提供します。意味のある統計を確保するために 5 分以上続くガベージコレクションオペレーションのみが含まれます。
**重要**
`gcRuntimeStats`、`documentFragmentStats`、およびコレクションレベルのメトリクスの `storageSegmentBase`および への分割`storageSegmentExtended`は、Amazon DocumentDB 8.0 でのみ使用できます。
**`storageSizeStats`**
+ **場所** — Database collStats コマンド
+ **説明** — さまざまなストレージセグメントのストレージ使用率の詳細な内訳を示します。
+ `storageSegmentBase` — 標準ドキュメントのベースストレージセグメントで使用されるストレージ
+ `storageSegmentExtended` — ラージドキュメントの拡張ストレージセグメントで使用されるストレージ
+ **使用状況** — 大規模なドキュメントストレージを持つコレクションを特定し、ストレージの分散パターンを理解するのに役立ちます。
**`unusedStorageSize`** (コレクションレベル)
+ **場所** — Database collStats コマンド
+ **説明** — サンプル統計に基づいて、コレクション内の未使用のストレージ領域を推定します。削除されたドキュメントと空のセグメントからのスペースが含まれます。メトリクスは、合計とセグメントごとの内訳の両方を提供します。
+ すべてのストレージセグメント`unusedPercent`で `unusedBytes`と を結合
+ `storageSegmentBase` — 特にベースストレージセグメントで未使用のスペース
+ `storageSegmentExtended` — 拡張ストレージセグメントで特に未使用のスペース
**`documentFragmentStats`**
+ **場所** — Database collStats コマンド
+ **説明** — コレクション内のドキュメントフラグメントとデッドデータに関する詳細情報を提供します。ドキュメントフラグメントは、データベースエンジンで使用される内部ストレージユニットを表し、デッドフラグメントは、アクセスできなくなり、まだ再利用されていないデータを示します。このメトリクスには以下が含まれます。
+ `totalDocFragmentsCount` — コレクション内のドキュメントフラグメントの合計数
+ `deadDocFragmentsCount` — デッド (アクセスできない) データを含むフラグメントの数
+ `deadDocFragmentsPercent` — デッドデータを含むフラグメントの割合
+ `deadDocFragmentBytes` — デッドドキュメントフラグメントによって消費される推定バイト数
+ `storageSegmentBase` および のセグメントごとの内訳 `storageSegmentExtended`
+ **使用状況** — このメトリクスをモニタリングしてガベージコレクションの有効性を理解し、メンテナンスオペレーションの恩恵を受ける可能性のあるコレクションを特定します。デッドフラグメントの割合が高いことは、ガベージコレクションが遅れているか、コレクションが最適化の恩恵を受ける可能性があることを示しています。
### インデックスレベルのメトリクス
**`unusedStorageSize`** (インデックスレベル)
+ **場所** — データベース 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)
}
```
## よくある質問
### ガベージコレクションが効率的に機能していないかどうかを確認するにはどうすればよいですか?
非効率的なガベージコレクションを示す次の警告サインをモニタリングします。
+ **過剰なコレクション肥大化** — 特に大きなインデックスでは、大量の書き込みや一括削除中に`unusedStorageSize`メトリクスが着実に増加します。
+ **高いデッドフラグメントの割合 — **一貫して高い`deadDocFragmentsPercent`値 (10～15% 以上) `documentFragmentStats`を示します。
+ **クエリレイテンシーの低下** — デッドドキュメントの蓄積によるクエリレイテンシーの増加。
+ **延長 GC 期間** — ガベージコレクションオペレーションには、 の履歴平均よりも時間がかかります`gcRuntimeStats`。
+ **GC 処理の引き上げ** — ガベージコレクターがシステムの需要に追いついていない`LongestActiveGCRuntime`ことを示す高。
### ガベージコレクションはデータベースのパフォーマンスに影響しますか?
通常の条件下では、ガベージコレクションのパフォーマンスへの影響は最小限です。ただし、ガベージコレクションが遅れると、以下が発生する可能性があります。
+ 蓄積されたデッドドキュメントのストレージコストが増加しました。
+ 古いインデックスエントリにより、クエリのパフォーマンスが遅くなります。
+ MVCC IDsが枯渇した場合の一時的な読み取り専用モード。
+ 特に小規模なインスタンスでは、集中的な収集の実行中のリソース使用量が増加します。
+ 大規模なドキュメントの拡張ストレージセグメントオペレーションの効率が低下しました。
### ガベージコレクションを手動でトリガーできますか?
いいえ。Amazon DocumentDB のガベージコレクションを手動でトリガーすることはできません。システムは、内部メンテナンスオペレーションの一部としてガベージコレクションを自動的に管理します。
### 運用上のベストプラクティスとして設定する必要があるアラームは何ですか?
Amazon DocumentDB システムの最適なパフォーマンスを確保するために、クラスターレベルとコレクションレベルの両方でモニタリングをセットアップすることをお勧めします。
クラスターレベルのモニタリングでは、まずしきい値が 13 億の`AvailableMVCCIds`メトリクスの Amazon CloudWatch アラームを作成します。これにより、メトリクスが 0 に達する前にアクションを実行するのに十分な時間が与えられます。ゼロに達した時点で、クラスターは読み取り専用モードになります。このメトリクスは、特定の使用パターンに基づいて変動する場合があることに注意してください。一部のお客様は、ガベージコレクションが作業を完了すると 13 億を下回ってから 15 億を回復します。
また、Amazon CloudWatch を介して`LongestActiveGCRuntime`メトリクスをモニタリングすることも重要です。このメトリクスは、`gcRuntimeStats` とともに、システム全体でのガベージコレクションのパフォーマンスを理解するのに役立ちます。
コレクションレベルのモニタリングでは、次の主要なメトリクスに焦点を当てます。
+ `MVCCIdScale` — MVCC IDs が古くなっていて注意が必要な可能性があることを示す値の増加に注意してください。
+ `gcRuntimeStats` — ガベージコレクションプロセスが異常に長くかかるか、数日間にわたって延長されることを特定します。
+ `documentFragmentStats` — `deadDocFragmentsPercent`値をモニタリングする - 一貫して高い割合 (10～15%) は、ガベージコレクションが遅れていることを示している可能性があります。
+ `storageSizeStats` および `unusedStorageSize` — ストレージ使用率パターンを追跡し、いずれかのストレージセグメントに大量の未使用領域があるコレクションを特定します。
書き込みオペレーションが頻繁なコレクションでは、ガベージコレクターの作業が増えるため、特に注意が必要です。ガベージコレクションがワークロードに遅れないように、書き込みアクティビティが多いコレクションでは、これらのメトリクスをより頻繁にチェックすることをお勧めします。
これらのモニタリングレコメンデーションが出発点となることに注意してください。システムの動作に慣れたら、特定の使用パターンと要件に合わせてこれらのしきい値を調整することをお勧めします。
### `AvailableMVCCIds` が 13 億を下回った場合はどうすればよいですか?
`AvailableMVCCIds` メトリクスが 13 億を下回る場合は、クラスターが読み取り専用モードにならないようにすぐにアクションを実行することをお勧めします。まずインスタンスサイズをスケールアップして、ガベージコレクターにより多くのコンピューティングリソースを提供することをお勧めします。これは、アプリケーションが通常のオペレーションを継続し、ガベージコレクターに追いつくために必要な追加の能力を与えることができるため、当社の主な推奨事項です。
単独でスケールアップしても状況が改善しない場合は、書き込みオペレーションの削減を検討することをお勧めします。`MVCCIdScale` メトリクスを使用して、注意が必要な古い MVCC ID を含む特定のコレクションを特定します。さらに、モニタリング`documentFragmentStats`して、ガベージコレクションの非効率に寄与している可能性のあるデッドフラグメントの割合が高いコレクションを特定します。
これらのコレクションを特定したら、ガベージコレクションが追いつくことができるように、それらのコレクションへの書き込みオペレーションを一時的に減らす必要がある場合があります。復旧期間中は、`AvailableMVCCIds` メトリクスを注意深くモニタリングして、アクションが望ましい効果を持っていることを確認することをお勧めします。`AvailableMVCCIds` 値が 15 億以上に戻ると、クラスターは正常と見なされます。
これらのステップは、システムが重大な状態になる前に復旧するための予防策であることに注意してください。メトリクスが 13 億を下回った後に早くアクションを実行すればするほど、書き込みオペレーションへの影響を回避できる可能性が高くなります。