从MongoDB到PostgreSQL：数据零丢失、成本砍半_MongoDB

Infisical 是一家开源的密钥管理平台，为团队及基础设施提供同步密钥的服务并防止密钥泄露。随着业务不断发展、数据不断增加，原有数据库已无法满足当前需求，Infisical 决定从 MongoDB 迁移到 PostgreSQL。本文将分享这一从非关系型数据库迁移至关系型数据库的决策判断及背后的迁移故事。

文章插图
Infisical 在过去一年里迅速扩张，目前平台每天处理超过 5000 万个密钥，向需要数据的团队、CI/CD 管道以及服务器/应用程序，发送应用程序配置和机密数据。
随着使用量不断增加，我们必须持续升级技术栈。最近，Infisical 进行了从MongoDB到PostgreSQL的数据库全面迁移。此次迁移涉及到对方案的审慎评估、采纳新技术、创建新的数据库模式（schema）、重构逻辑、重写查询语句，将数百万（如果不是数十亿）的数据库记录迁移到 PostgreSQL 。这过程十分复杂，但也是改善平台的必要一步。
本文将介绍我们从 MongoDB 迁移到 PostgreSQL 决策背后的故事以及迁移过程。希望这篇文章令人感兴趣，并为其他考虑进行类似数据库迁移的人提供帮助。
从何开始
最初构建 Infisical 时，我们选择了团队最熟悉的技术栈进行构建。作为这个方案中的一部分，我们选择了 MongoDB + Mongoose ORM，因为这种组合的开销最?。?⑻峁┝丝焖俳桓陡咧柿康墓δ?。
正如托尼·霍尔爵士所说，“过早优化是万恶之源” ，也确实没有进一步优化的必要，我们当时还专注于构建 Infisical Cloud（托管 SaSS 产品）。同时由于这一产品侧重点，我们并没有预计到有很多用户自行托管产品，所以也没有对这一用例设计相关方案。
为什么放弃 MongoDB？
虽然 MongoDB 在早期为 Infisical 提供了良好服务，但当我们产品场景发展到超出托管服务范围时，它开始显示出不足。随时间推移，我们发现许多组织，尤其是在合规性和安全性的交叉领域运营的组织，相较使用Infisical Cloud，更喜欢自托管 Infisical；同时用户也有些需要满足的本地需求。
【从MongoDB到PostgreSQL：数据零丢失、成本砍半】随着对自托管 Infisical 的需求不断增长，我们发现已经开发了相当多功能来减少自托管 Infisical 所需的学习曲线，而在这一趋势的影响下，我们最终放弃了 MongoDB，转而使用 PostgreSQL 。
在实践中，我们和我们的客户经常在功能和可用性方面受到 MongoDB 的限制，例如缺乏对事务、清理的支持、云厂商托管产品的版本控制不一致，更不用说无模式（schema-less）数据库设计结构等相关问题。
下面详细阐述其中的一些挑战：

配置数据库事务困难：使用MongoDB设置事务并不容易，因为它需要在集群模式下运行 MongoDB，并产生各种配置开销。由于需要MongoDB 的生产设置，客户运行简单的 Infisical POC 变得极其困难。对于处理高度敏感数据且必须保证数据完整性的产品来说，这是难以接受的。
缺少关系型功能：使用 MongoDB ，意味着失去了关系型世界中的许多优秀功能，例如 CASCADE，每当删除目标资源时，就可以删除其他表中引用的所有资源；这造成了相当大的损失，因为我们的数据很大部分是关系型。所以，我们在旧代码库中使用了大量的删除函数，但这些函数从未完全完成工作，并在 MongoDB 数据库中留下了悬置资源。
缺乏跨云提供商的支持：在 MongoDB 将许可证更改为 SSPL 后，许多云提供商选择提供旧版本的 MongoDB 。因此我们发现，除了使用最新稳定版本MongoDB 的客户外，很难确保运行在其他版本上 Infisical 的功能可用性。
MongoDB 实操经验不足：由于更多人熟悉部署基于 SQL 的数据库，他们常常难以扩展和正确配置 MongoDB；这导致我们需要为客户提供的支持量大幅增加，特别是因为他们不熟悉 MongoDB 。

除了以上及其他原因之外，我们还意识到，将完整的数据库迁移到更通用的东西是让世界各地的团队和组织更容易使用 Infisical 所需的最终功能。
选择 PostgreSQL 的原因？
在寻找新数据库时，我们先列出最看重的几个方面：易于管理（即包括配置、部署和扩展）、内置事务支持以及关系型功能。我们还考虑了是否应该构建自己的集成存储或寻求外部存储解决方案。
以下是备选方案：