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

外部存储：可以简单地将 MongoDB 替换为其他数据库（例如 PostgreSQL 或 MySQL），并使用其内置的扩展功能。尽管该解决方案并没有完全消除 Infisical 使用时需要外部依赖项的问题，但我们认为这项方案由于不使用 MongoDB 而带来了显著优点。讨论到支持一个或多个数据库时，我们认为支持多个数据库意味着会失去各个解决方案的独特优势，同时增加的工程开销。

经过慎重考虑，我们选择了PostgreSQL 。除了拥有充满活力的社区、广泛的文档以及众多可用的解决方案和扩展之外，我们最欣赏它的开源特性和绝大多数云提供商都支持 PostgreSQL 托管服务。
最重要的是，这意味着 Infisical 的用户可以更轻松地在任何云提供商上自行托管我们的平台，并将其与相应的托管 PostgreSQL 服务配对。此外，鉴于 PostgreSQL 已得到广泛采用，我们相信用户在使用 Infisical 时操作会更加便捷。
如何处理 ORM？
选择 PostgreSQL 后，我们需要弄清楚应用程序如何与数据库交互。我们第一反应是找到一些与使用 Mongoose ORM 的 MongoDB 体验类似的工具。因此，我们开始根据成熟度、可视化和迁移支持以及适当的抽象级别来评估候选工具；我们主要考虑了 Drizzle ORM、 Prisma ORM、 TypeORM和 Knex.js （一种查询构建器）。
最后，我们决定使用 Knex.js而非 ORM，以便更好地控制数据库。无可否认的是，原始 SQL 是最通用的且抽象最少，但我们认为这种方法太容易出错，而且坦白说，在没有适当的TypeScript 支持的情况下，维护起来很麻烦。
此外，除了接近裸露的 SQL 之外，Knex.js 还自带用于播种和迁移工具包，拥有成熟的生态系统，其中包含出色的文档和几乎任何可能查询的答案。再加上一些定制的 Zod 集成工作，我们尽力使其对 TypeScript 的支持达到了令人满意的水平。
在决定了数据库和 ORM 后，我们启动了一个流程，最终导致整个应用程序重写数十个数据结构和数百个查询。
我们如何计划迁移？
代码重写即将结束之时，我们开始考虑如何进行迁移操作，将 MongoDB 数据映射到 PostgreSQL ，同时将对 Infisical 云平台的干扰降至最低。
鉴于 Infisical 在客户基础设施中的关键作用，我们立即排除了绝对停机方案的可能性。我们不得不妥协的是，在短暂的迁移窗口期间禁止写入操作（即客户将无法创建或更新应用程序配置），以换取更高的数据完整性保证。这种权衡似乎可以接受，因为客户主要从 Infisical 获取机密信息，并且他们每秒更新其应用程序配置的可能性较少。
接下来，关于实际的迁移操作，我们需要从 MongoDB 转储数据、仔细转换，然后将其插入回 PostgreSQL 。在审核迁移顺序时，我们克服了一些挑战，例如确保 NoSQL 中的各种树状结构正确转换为其关系对应结构；这对于具有递归考虑的文件夹等数据结构尤其敏感。
我们还发现需要一种持久的方式来存储 MongoDB 中的标识符并将其映射到 PostgreSQL 中的标识符；考虑到处理的数据量之庞大，在内存中这样操作是行不通的。最后，我们决定使用 LevelDB 键值存储来协助标识符存储和查找操作，将数据逐表移动到 PostgreSQL 中。
迁移
最后，我们准备好进行迁移。此时，没有直接参与代码库重写的人员用了一个季度的时间来改进 Infisical 的其他方面，包括进行前端更改、执行维护补丁、扩展客户端功能以及编写更好的文档。此时，所有人重新聚集起来，为迁移这一过程做准备——把应用程序代码库替换为新代码库，并将数据从 MongoDB 传输到 PostgreSQL 。
作为准备工作的一部分，我们起草了一份详细的迁移清单以及预期时间表。
计划大体如下：

执行迁移的几周前，通过电子邮件和应用内横幅提前通知用户数据库即将进行升级。我们将对平台上的每个功能流程进行彻底测试，并对迁移进行试运行。
迁移过程预计六小时，期间平台仅允许读取操作。在此窗口期，我们将运行迁移脚本，将数据从 MongoDB 移动到 PostgreSQL，检查数据是否丢失，如果成功则将 DNS 切换到新实例。我们还有备用计划，以防意外。
迁移后，我们将解决残留问题，并推出使用 Infisical 和 PostgreSQL 的新文档。

准备好计划，我们就着手执行了。
迁移效果
幸运的是，迁移执行顺利，数据零丢失，仅有一些非必要功能出现故障；我们在随后的36 小时内解决了这些问题，将对客户的影响降到最低。