MongoDB 教会我的关于 Postgres 的经验

Source: Dev.to

使用 MongoDB 可以说让我对 Postgres 的了解比使用 Postgres 本身学到的更多。

听我说完。以前，我的第一反应总是选择 Postgres 来启动新项目。说实话——这算是一个相对安全的赌注。但只使用 Postgres 限制了我对它的理解——以及它的优势和局限性。

听起来很奇怪，竟然说我通过不使用它学到了更多。但这是真的，这也是我把这篇文章作为系列第一篇的原因。因为我真的从不使用 Postgres 中学到了很多。

我最初是怎么开始使用 MongoDB 的？

我加入的这家初创公司在我加入时已经选用了 MongoDB。这主要是基于当时的实际经验，以及 schema 正在快速演进的事实。一个文档型数据库，拥有几乎无限的 schema 灵活性，自然非常合适。

但这种灵活性是有代价的

一开始，摆脱了那种“迁移文件夹死亡之地”，不再承载数月 schema 发现过程中的无数来回迁移的伤痕，这让我感到非常愉快。Schema 的变更很快，而且——配合 Pydantic——还能持续确保代码库的高度一致性。

没有出现崩溃，系统始终在运行。然而，它变得越来越慢，成本也越来越高。没有刚性的 schema，必须在应用代码中重复进行验证，不仅在写入时，还要在读取时进行。

当 Pydantic 验证在大规模下运行时，服务的 CPU 消耗很快就变得显而易见。由于我们的验证依赖完整模型，这进一步限制了投影（projection）的有效使用。简单的查询开始变成完整文档的读取。

我突然开始欣赏 Postgres 那种有意的刚性。把验证紧贴在数据旁边是高效的——不仅因为它经过了优化，还因为验证只会执行一次。Postgres 的约束非常强大，能够把假设转化为保证。

话虽如此，在很多方面，将验证放在业务逻辑附近也是很好的。如果我们当初更好地处理迁移，防御性且昂贵的应用代码需求本可以降低。别忘了 MongoDB 的 schema 验证——这是我使用不足的一个特性。

从最初对 MongoDB 灵活性的喜爱，我很快领悟到一个重要真理：schema 纪律不会消失——但你可以选择让它存在于应用代码中，还是数据库中。