MongoDB 至今仍是开发者最青睐的 NoSQL 文档数据库，但 DocumentDB 等兼容性替代方案的出现，提供了比以往更丰富的选择。

　　在8月的欧洲开源峰会上，Linux 基金会宣布，DocumentDB——一个基于 PostgreSQL 构建且兼容 MongoDB 的文档数据库——已作为新的开源项目加入基金会。微软于2025年初首次宣布此项目，旨在支持开发者快速部署应用程序数据库，并简化数据查询。然而，此举无疑让围绕文档数据库的选型规划变得更加复杂。面对更多的选项，如何选择既满足当前需求又适应未来发展的方案？

　　为何选择文档数据库？

　　首先，我们需要理解为何会选择文档数据库，而非传统的关系型数据库。文档数据库以 JSON（JavaScript 对象表示法）格式存储数据，这种格式更易于操作。对于不熟悉关系型数据库的复杂性，或尚不明确未来数据模式需求的开发者而言，使用文档数据库能够实现更快速、高效的工作流程。

　　随着快速原型设计和敏捷开发的兴起，对文档数据库的关注度大幅提升。其中的典型代表是 MongoDB，目前其客户数量已超过 59,000 家。过去十年间，MongoDB 已成为只想专注构建的开发者最热门的选择之一。其他公司也相继推出了自己的文档数据库项目，市场上也出现了兼容 MongoDB API 的服务。DocumentDB 作为 Linux 基金会项目的推出，将进一步开辟新的选择空间。

　　当前应采取何种基础设施策略？

　　如今，关于数据库需要做出两个决策：选择何种技术，以及选择何种运行方式。后者涵盖了一系列部署选项，从在自有硬件和存储上自行部署技术实例，到选择完全抽象化基础设施、仅提供 API 的数据库即服务。在这两者之间，还可以选择在云上托管自有实例（即管理软件，而云服务提供商管理基础设施），或采用托管服务（即自行决定设计，其他一切由服务商完成）。

　　在这种情况下，需要评估团队拥有多少时间和资源用于管理基础设施，以及对基础设施的控制程度。一方面，托管服务能提供更快的交付速度。另一方面，更高的控制度意味着可以根据应用需求优化数据库，从而获得更好的性能。

　　使用云服务的一个潜在挑战在于，你可能会在多大程度上被锁定在该提供商特定的运作方式中。同时，你也需要承担其成本和定价模型。如果无法迁移系统，当提供商提高价格时，你可能不得不承受更高的成本。这可能会影响你的发展战略，迫使你根据不可控的外部因素调整计划。

　　部分原因也解释了为何有更多运行文档数据库的选项——特别是兼容 MongoDB 的数据库服务——进入市场。MongoDB 鼓励企业迁移到其 Atlas 云服务的做法受到部分用户欢迎，但其他企业可能无法或不愿承诺上云。他们的选择是继续使用成本更高的许可证，或者寻找替代方案。

　　运行文档数据库实例有哪些选择？

　　尽管 DocumentDB 成为 Linux 基金会项目可能会促进更多迁移，但它并非唯一可用的选择。对于已在使用 MongoDB 的组织而言，转向其他选项有助于在未来保持对技术战略的控制。

　　选择一：考虑运行 MongoDB 的替代方式。 除了完全兼容 MongoDB API 的方案，你还可以选择不同版本的 MongoDB 或其他方案来满足文档数据库需求。例如，如果你不想迁移到云端使用 MongoDB Atlas，而 MongoDB Enterprise 又成本高昂，一种方法是采用 MongoDB 社区版以降低许可成本。但这可能不包含企业级工作负载所需的全部功能。

　　如果情况如此，可考虑使用提供企业级功能（如备份和安全）的替代发行版。其中一个例子是 Percona Server for MongoDB，它在保持与 SSPL 兼容的同时，增加了必要的支持与功能。使用不同的发行版能最大程度保持与现有 MongoDB 应用的兼容性，对于那些希望使用 MongoDB 但不想绑定于 Atlas 或 Enterprise 的用户而言，也是一个合理的选择。

　　选择二：采用与 MongoDB API 兼容的服务。 对于某些工作负载，API 兼容性足以支持迁移到其他服务，且影响极小甚至没有影响。DocumentDB 在实践中正是如此运作：其 API 与 MongoDB 相同，但后端基础设施基于 PostgreSQL。除了 Linux 基金会的 DocumentDB 项目，还有其他提供兼容性的云服务。例如，AWS 提供支持 MongoDB 的 DocumentDB 服务，微软的 CosmosDB 也支持 MongoDB。另一个选择是 FerretDB，这是一个开源项目，能够复制 MongoDB 驱动程序，使其在 PostgreSQL 之上工作。

　　选择三：选用其他文档数据库。 在开源世界中，Apache CouchDB 是另一个使用 JSON 的文档数据库，可用于项目。它在应用程序可能同时运行于移动设备和云实例的场景下尤其有用；移动支持是 MongoDB 已弃用的功能。然而，迁移到 CouchDB 可能涉及对应用程序设计的一些修改。当然，任何潜在的重构或重新设计成本都应纳入考量清单。

　　要在此做出选择，需评估与 MongoDB 的兼容性对你的应用程序有多重要。如果你需要实现完整的 MongoDB 技术栈，那么选择是使用 MongoDB 或其替代发行版。如果只需要 API 或驱动程序兼容性，那么你的选择范围更广。如果希望或必须在私有云环境中运行，选择则会相对有限。采用由 Kubernetes Operator 管理的容器化数据库等方法，可以提供与云服务相当的功能，同时避免将你锁定在特定的云服务提供商中。这也可以融入平台工程模型，实现资源分配、部署和实例管理的自动化。

　　MongoDB 与文档数据库的长期未来

　　MongoDB 仍然是开发者中最受欢迎的 NoSQL 文档数据库，在 2025 年 StackOverflow 调查的总体数据库排名中位列第 6。这种受欢迎程度短期内不会下降。但如今，运行这些工作负载的选择比以往任何时候都多。整个社区现在可以投入开发自己的文档数据库方案，而不必仅依赖一家公司对该项目的投入。

　　更广泛的技术格局演变也将影响文档数据库的未来。对 AI 服务的需求提升了企业数据的价值，将数据转化为生成式 AI 项目的向量嵌入，反过来又推动了更多文档数据库的部署以支持这些数据。对开发者而言，使用文档数据库将企业数据存储为向量，可以更便捷地并行管理这些数据。

　　选择增多应有助于巩固 MongoDB 作为一种长期技术方法的地位，正如 SQL 被采纳并作为关系型数据库标准超过 50 年一样。但现在，实现这种方法的方式比以往更多样，从兼容的发行版到使用相同 API 或支持相同驱动程序、但采用其他基础设施方法的项目。

　　所有这些创新都表明，市场对文档数据库方法持续青睐，但开发者希望在其构建方式上拥有更多的选择和灵活性。开源社区已经介入以满足这些需求，无论是采纳新的发行版，还是在如何应用这种方法上提供更多选项。