文档型数据库解读14：文档型数据库建模之{归档模式}

在数据管理的复杂环境中，对于永久保存数据的需求是一项常见而关键的挑战。项目可能因法规要求或其他合理原因，需要长时间（甚至无限期）保存数据。然而，对于很多项目来说，对数据的常用查询仅涉及最近的一段时间，将所有数据都保存在同一高成本的存储中显然不是一种明智的做法。为了解决这一问题，{归档模式}（Archive Pattern）应运而生，通过对数据进行分层存储，以满足不同数据访问频率的需求。

{归档模式}的介绍

{归档模式}旨在解决永久保存数据的需求，通过将数据分层存储，实现对使用频率较低的数据采用更经济存储方式。在典型的归档需求中，例如金融、制药、医疗、教育或其他法规约束的应用中，常常需要实现以下存储策略：

1. 在核心生产数据库中，存储不超过2年的数据。

2. 在成本更低的存储介质中，存储2到7年之间的数据，如外部对象存储服务（如Amazon S3）、更便宜的集群等。

3. 删除超过7年的数据（或存储到磁带机、蓝光盘等冷存储介质）。

这种策略既满足了数据的长期保存需求，又避免了不必要的高成本存储。

{归档模式}的原理

实现{归档模式}，首先需要两个（或以上）存储位置。第一个位置存放访问频繁的文档，通常是不超过两年的文档，保存在核心数据库中。而第二个位置存储成本相对较低的文档，常见的选择包括外部对象存储服务、更便宜的集群或同一数据库中的另一个集合。

• 对象存储： 使用对象存储如Amazon S3，虽然存储成本较低，但查询数据的成本较高，因为难以在不读取大文件区块的情况下读取单个文档。

• 更便宜的集群： 将文档复制到一个同样部署了「巨杉文档型数据库」但硬件配置更低的集群（如更低规格的CPU、更少的内存、容量更大但性能更低的HDD机械盘存储）。这种方案费用上可能比对象存储要高一些，但因为它仍然是一个「巨杉文档型数据库」集群，可以直接访问文档并使用索引，因此业务查询所需的逻辑成本较低。

• 同一集群中的另一个集合： 将文档复制到同一数据库中的另一个集合。虽然存储空间及硬件费用相同，但旧文档可以不用建立太多索引，从而节省资源。当应用程序需要访问旧文档，又不希望单独建立新集群增加维护管理成本时，还可以通过从节点或分析节点进行查询。

如何实现{归档模式}

要实现{归档模式}，需要以下步骤：

1. 使用嵌入关系： 尽量使用嵌入关系，选择进行归档的理想文档应包含所有数据，避免从许多碎片中重新建档。

2. 添加存活期字段： 在文档中添加一个字段表示文档的存活期，即数据的保存时长。

3. 设定存活期： 对于那些永不过期或者不需要移动的文档，将存活期字段设为"永久保留"。

4. 选择存储位置： 选择一个跟生产数据不同的位置用于存储归档文档，可以是对象存储、更便宜的集群或同一数据库中的另一个集合。

5. 创建脚本或修改应用程序： 创建一个脚本或修改应用程序来归档或删除文档，根据存活期字段的设定来执行相应的操作。

6. 制定归档和删除计划： 确定归档和删除文档的计划，使用TTL索引可以帮助删除文档。

使用{归档模式}案例

新能源车企对不同型号产品，会在APP形成和用户的交互记录，通过文档型数据库{归档模式}实现交互记录的有效归档。在产品交互记录被定期归档，超过3个月的记录移至另一个低配置的「巨杉文档型数据库」集群。文档以月份为单位，存储每月的交互内容，如下所示：

{
    "_id": {
        "model_id": "car84738",
        "month": ISODate("2024-06-01T05:00:00Z")
    },
    "model_name": "Model D",
    "month": ISODate("2024-06-01T05:00:00Z"),
    "interactions": [
        {
            "ts": ISODate("2024-06-16T20:10:00Z"),
            "userid": 27465,
            "name": "张三"
        },
        {
            "ts": ISODate("2024-06-17T19:30:00Z"),
            "userid": 19847,
            "name": "李四"
        }
    ]
}

归档字段为$month，userid字段和产品文档的引用字段使用{扩展引用模式（将在日后进行讲解）}，提高读取和搜索文档的效率。

需要定期运行查询脚本，查找所有超过3个月的文档，并将其复制到另一个低配置的「巨杉文档型数据库」集群中，最后在数据库中删除这些文档。以下是示例查询脚本：

db.interactions.aggregate([
  {
    $match:
      {
        month: {
          $lt: new Date(
            new Date().setMonth(
              new Date().getMonth() - 3
            )
          ),
        },
      },
  },
])

通过这种方式，文档型数据库实现了宠物交互记录的高效归档和管理，满足了宠物收养项目的需求。

{归档模式}的优点：

1. 降低管理成本： 主要旨在降低管理旧文档的成本。当数据库中存在大量历史数据时，使用{归档模式}可以有效减轻管理负担，保持数据库的高效性。

2. 满足法规要求： 适用于需要满足长期保存数据的法规要求的场景。对于那些需要保存数据多年的业务，将文档归档到合适的存储介质中，可以更好地满足法规合规性的需求。

{归档模式}的局限性：

1. 检索效率相对较低： 归档的文档存储在较慢的数据存储设备上，可能缺乏索引。这导致检索这些文档的速度相对较慢，需要在设计中平衡查询性能和存储成本。

2. IO消耗较高： 没有索引的归档文档可能导致每次检索的IO消耗较高，特别是在使用按流量计费的云对象存储（如Amazon S3）时，必须确保归档不会导致不必要的成本增加。

3. 更新挑战： 更新已归档的数据通常是一个挑战，特别是在像Amazon S3这样的云对象存储中，不支持"就地更新"。如果更新是关键需求，可能需要考虑使用其他替代解决方案，如较慢的集群，以满足更新的要求。

{归档模式}总结

{归档模式}的目标是尽可能降低系统的总体成本，而不是提高性能。金融和医疗保健公司经常使用此模式来满足政府的法务要求以及运营各类数据。如：业务的流水日志，随着时间推移变得很少被访问，就可以利用这种模式提升效益。