亚马逊 DocumentDB 中的垃圾收集 - Amazon DocumentDB
了解 Amazon DocumentDB 中的垃圾收集垃圾收集流程监控垃圾收集collStats输出示例常见问题

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

亚马逊 DocumentDB 中的垃圾收集

Amazon DocumentDB 实现了多版本并发控制 (MVCC) 数据库架构，该架构可为每次更新操作创建新版本的文档和索引条目。这种架构允许读取查询使用版本化文档而无需锁定，从而提供读取隔离。

了解 Amazon DocumentDB 中的垃圾收集

垃圾收集 (GC) 是一个自动后台进程，可在 Amazon DocumentDB 中保持最佳的系统性能和可用性。与覆盖现有数据的传统数据库不同，Amazon DocumentDB 的 MVCC 架构每次更新操作都会创建新版本的文档和索引条目。生成新文档版本的每个写入操作都会消耗有限计数器中的唯一 MVCC ID，因此高效的清理至关重要。随着时间的推移，这些旧版本会不断积累，必须对其进行清理以防止性能下降。

垃圾收集的功能

垃圾收集器有三个基本功能：

  • 回收存储空间 — 它会删除活动查询不再需要的过时文档和索引版本，从而为将来的写入操作腾出空间。

  • 防止 MVCC ID 溢出 — 它通过管理 MVCC 的有限计数器来防止 MVCC ID 溢出。 IDs如果没有这种管理，计数器最终将达到其极限，从而迫使数据库进入临时的只读模式，直到 IDs 被回收为止。

  • 保持查询性能-它通过消除失效的文档版本来保持最佳的查询性能，否则这些版本会累积并减慢查询处理速度。

垃圾收集流程

GC 进程对每个集合进行操作，并且可以在不同的集合上同时运行多个进程。该过程由四个连续阶段组成：

  1. 识别-系统识别活动事务或查询不再引用的文档和索引版本。

  2. 内存加载-如果旧文档和索引条目尚不存在，则会加载到内存中。

  3. 删除-永久删除过时的版本以回收存储空间。

  4. MVCC ID 回收 — 系统 IDs 从已删除的版本中回收 MVCC 以进行新操作。

当垃圾收集完成对旧文档版本的处理后，它会 IDs 从系统中删除最旧的 MVCC。这种清理对于通过回收 MVCC 来防止 MVCC ID 溢出至关重要 IDs，使它们可用于集群中的新写入操作。如果没有这种回收过程，系统最终将耗尽其有限的 MVCC ID 计数器并进入只读状态。

垃圾收集计划

垃圾收集会定期在后台自动运行。定时和频率会根据系统负载、可用资源、写入量和 MVCC ID 消耗水平进行动态调整。在高写入活动期间，GC 进程的执行频率会更高，以管理不断增加的文档版本。

监控垃圾收集

集群级别指标

AvailableMVCCIds

  • 地点-亚马逊 CloudWatch

  • 描述-一个计数器，显示在达到零之前剩余的可用写入操作数。当此计数器达到零时，您的集群将进入只读模式，直到 IDs 被回收和回收。计数器会随着每次写入操作而减少，并随着垃圾收集回收旧的 M IDs VCC 而增加。

  • 建议-当价值跌至13亿以下时设置警报。此预警允许您采取稍后讨论的建议步骤。

LongestRunningGCProcess

  • 地点-亚马逊 CloudWatch

  • 描述-最长活动垃圾收集过程的持续时间（以秒为单位）。每分钟更新一次，仅跟踪活动操作，不包括在一分钟窗口内完成的进程。

  • 建议 —

集合级别指标

MVCCIDStats: MvccIdAgeScale

  • 位置-数据库 collStats 命令

  • 描述 — 以 0 到 1 的等级衡量 MVCC ID 年龄，其中 1 表示集群进入只读状态之前的最大年龄。同时使用此指标AvailableMVCCIds来识别包含使集群老化的最旧 MVCC IDs 的集合。

  • 建议-将每个集合的值保持在 0.3 以下。

GCRuntimeStats

  • 位置-数据库 collStats 命令

  • 描述-提供两个月的垃圾收集指标历史记录，包括总运行次数、平均持续时间和最长持续时间。仅包括持续时间超过五分钟的垃圾收集操作，以确保有意义的统计数据。

UnusedStorageSize（集合级别）

  • 位置-数据库 collStats 命令

  • 描述-根据抽样统计数据估算集合中未使用的存储空间。它包括已删除文档和空白段落的空间。

索引级别指标

UnusedStorageSize（索引级别）

  • 位置-数据库 IndexStats 命令

  • 描述-根据采样统计数据估算索引中未使用的存储空间。它包括过时的索引条目和空段的空间。

  • 建议-使用reIndex命令在不停机的情况下重建索引并回收未使用的空间。有关更多详细信息，请参阅管理索引。

collStats输出示例

{
    "ns": "xid_consumption_test_db.xid_test_collection",
    "MVCCIdStats": {
        "MVCCIdScale": 0.03
    },
    "gcRuntimeStats": {
        "numRuns": 1,
        "historicalAvgRuntime": 3295,
        "historicalMaxRuntime": 3295,
        "lastRuntime": 3295,
        "lastRuntimeStart": ISODate("2025-06-24T08:47:14Z")
    },
    "collScans": 14,
    "count": 30000000,
    "size": 1320000000,
    "avgObjSize": 44,
    "storageSize": 6461497344,
    "capped": false,
    "nindexes": 2,
    "totalIndexSize": 9649553408,
    "indexSizes": {
        "_id_": 1910661120,
        "c_1": 7738892288
    },
    "unusedStorageSize": {
        "unusedBytes": 4201881600,
        "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指标会稳步增加，尤其是在索引较大的情况下

  • 查询延迟降低 — 由于累积的失效文档导致查询延迟增加

  • GC 持续时间延长 — 垃圾收集操作花费的时间比历史平均值长 GCRuntimeStats

  • GC 处理能力提高 — 高LongestRunningGCProcess表示垃圾收集器无法满足系统需求

垃圾收集会影响我的数据库性能吗？

在正常情况下，垃圾收集对性能的影响微乎其微。但是，当垃圾收集落后时，你可能会遇到：

  • 积累的失效文档导致存储成本增加。

  • 由于索引条目过时，查询性能降低。

  • 如果 MVCC 已耗尽，则 IDs 为临时只读模式。

  • 在密集收集运行期间，资源使用量更高，尤其是在较小的实例上。

我可以手动触发垃圾回收吗？

不可以，无法手动触发亚马逊文档数据库中的垃圾回收。作为内部维护操作的一部分，系统会自动管理垃圾收集。

作为操作最佳实践，我应该设置哪些警报？

我们建议在集群和馆藏级别设置监控，以确保您的 Amazon DocumentDB 系统获得最佳性能。

用于集群级监控

首先为阈值为 13 亿的AvailableMVCCId指标创建 CloudWatch 警报。这使您有足够的时间在指标达到零之前采取行动，届时您的集群将进入只读模式。请记住，此指标可能会根据您的特定使用模式而波动。一些客户认为它降至13亿以下，然后随着垃圾收集工作的完成，恢复到15亿以上。

通过监控LongestRunningGCProcess指标也很重要 CloudWatch。此指标以及可GCRuntimeStats帮助您了解整个系统中垃圾回收的执行效率。

用于馆藏级监控

重点关注两个关键指标。首先，我们建议您查看每个集合的MvccIdAgeScale价值。值的增加表明 MVCC IDs 正在老化，可能需要注意。其次，监控GCRuntimeStats以识别任何耗时异常长或持续多天的垃圾收集过程。需要特别注意具有频繁写入操作的集合，因为它们会为垃圾收集器生成更多工作。我们建议更频繁地检查写入活动繁重的集合的这些指标，以确保垃圾收集跟上您的工作负载。

请注意，这些监控建议仅作为起点。随着您对系统的行为越来越熟悉，您可能需要调整这些阈值，以更好地匹配您的特定使用模式和要求。

如果我的收入AvailableMVCCId跌至13亿以下，我该怎么办？

如果您的AvailableMVCCId指标降至13亿以下，我们建议您立即采取措施以防止您的集群进入只读模式。我们建议先扩大实例大小，为垃圾收集器提供更多计算资源。这使您的应用程序能够继续正常运行，同时为垃圾收集器提供 catch 所需的额外功能。

如果仅靠向上扩展并不能改善这种情况，我们建议您考虑减少写入操作。使用该MvccIdAgeScale指标来确定哪些特定集合包含需要注意的较旧 MVCC IDs 。识别出这些集合后，可能需要暂时减少对它们的写入操作，以允许垃圾回收赶上。在恢复期间，我们建议您密切监视该AvailableMVCCId指标，以确保您的操作达到预期的效果。一旦AvailableMVCCId值恢复到 15 亿或更高，您的集群就会被视为运行状况良好。

请记住，这些步骤是预防措施，可帮助您的系统在达到临界状态之前恢复。在看到该指标降至13亿以下后，您越早采取行动，就越有可能避免对写入操作造成任何影响。