用 Postgres 就好

原文地址 https://mccue.dev/pages/8-16-24-just-use-postgres

这一部分是实用建议，一部分是对读者的提问。 建议：当你正在写一个需要持久存储数据的新应用程序，就像大多数网络应用程序那样，你默认的选择应该是 Postgres。

*** 为什么不是 sqlite?**

sqlite 是一个相当不错的数据库，但它的数据存储在单个文件中。这意味着无论你的应用程序是什么，它都只运行在一台机器上，或者至少是一个共享文件系统上。如果你正在写桌面或移动应用，那就完美了。如果你正在写网站，可能就不太适合了。使用 sqlite 为网站服务有很多成功案例，但他们大多数人都自己搭建服务器和基础设施。像Heroku、Railway、Render 等 PaaS 通常希望你使用通过网络访问的数据库。放弃这些平台提供的一些好处并没有错，但请考虑是否值得为了 sqlite 的优点而放弃平台提供的自动数据库备份以及配置超过一台应用服务器的能力。

*** 为什么不是 DynamoDB, Cassandra, 或者 MongoDB?**

无论 Rick Houlihan 在哪里，我希望他过得愉快。我看了很多会议的演讲，但他 2018 年关于 DynamoDB 深度解析的可能是我最常看的一个。我知道你们中很少有人会去看一个小时长的演讲，但你真应该去看一下。这个非常好。它主要阐述的是与 DynamoDB 同类型的数据库 - 包括 Cassandra 和 MongoDB - 如果满足以下条件则表现出色:

• 你事先完全清楚你的应用需要做什么；
• 你事先完全清楚你将如何使用数据；
• 你已知需要处理大量数据；
• 你可以接受放弃某种程度上的一致性；

这是因为这种数据库基本上就是一个巨大的分布式哈希映射。不需要扫描整个数据库就能工作的唯一操作是通过分区键进行查找和利用排序键进行扫描。无论你需要做什么查询，你都需要在存储之前将这些知识编码到其中一个索引中。你想要存储用户并通过名字或姓氏来查找他们吗？那么你最好有一个看起来像 $ 的排序键。你的访问模式应该被内置到如何存储数据中去。如果您的访问模式发生了重大变化，您可能需要重新处理所有数据。 这很烦人，因为特别是对于 MongoDB，人们接触它时通常会被告知它是一种更「灵活」的数据库。 是的，你不需要给它提供架构图。是的，你可以直接把 untyped JSON 倾倒进集合里。不, 这并不算得上一种灵活型数据库。它只能说效率高而已。

使用关系数据库，你可以通过在表上添加一个或两个索引，从获取一个人的所有宠物转到获取所有宠物的主人。但对于这种类型的 NoSQL 来说，这可能是一项艰巨的任务。如果你需要运行分析查询，效果也不会很好。像「过去一个月有多少用户注册」这样的任意问题可以通过编写 SQL 查询轻松回答，如果你担心在处理客户流量的同一台机器上运行昂贵的查询，也许可以在只读副本上进行。这就超出了这种数据库能处理范围之外了。你需要将数据 ETL 出去才能处理它。如果你看到大学生或刚毕业生正在使用 MongoDB，请阻止他们。他们需要帮助。他们已经走错路了。

If you see a college student or fresh grad using MongoDB stop them. They need help. They have been led astray.

译者注，这句的原文扎心了。

*** 为什么不是 Valkey?**

以前被称为 Redis 的艺术家最为人所知的是它是一个高效的进程外缓存。你只需要计算一次昂贵的东西，然后把它放在 Valkey 里，这样你拥有的 5 个或更多 HTTP 服务器就不需要重新计算了。然而，你也可以将其作为主数据库使用。它将所有数据存储在 RAM 中，因此如果你这么做，速度会非常快。

但也明显存在以下问题：

• 你只能拥有一定数量的 RAM。虽然你可以拥有比你想象中更多的 RAM，但与硬盘相比，它仍然相当有限。
• 就像 DynamoDB 那样，你需要在如何建模数据上做出让步。

*** 为什么不是 Datomic?**

如果你已经知道这个，那么你可以得到一个五角星。Datomic 是一个 NoSQL 数据库，但它是关系型的。「预先设计」的问题不存在，并且它确实具有一些不错的属性。你不在表格中存储数据。所有的都是「实体-属性-值-时间」（EAVT）对。与其存储带有 id、名字和年龄的人，不如存储 1 :person/name “Beth” 和 1 :person/age 30。然后你的查询基于「通用」索引进行工作。在进行查询时，你不需要与写入者协调。您按照给定时间查询数据库。新数据，甚至删除（或者他们称之为“撤回”），并没有真正删除旧数据。

但是也存在一些重大问题：

• 它只适用于 JVM 语言。
• 除了 Clojure 这种相对小众的语言，其 API 表现糟糕。
• 如果你构建的查询结构不佳，得到的错误信息会非常糟糕。
• 脱离于整个 SQL 的工具集。

*** 为什么不是 XTDB？**

Clojure 的人们搞了很多数据库。XTDB 在精神上与 Datomic 相似，但是：

• 它有一个 HTTP API，所以你不会被锁定在 JVM 上。
• 它有两个可以查询的时间轴。「系统时间」- 记录插入的时间 - 和「有效时间」。
• 它有一个 SQL API。

对它最大的反对点是：

• 它是新的。其 SQL API 是去年突然出现的东西。它最近改变了整个存储模型。背后的公司能否在未来 10 年内生存下来？谁知道呢！

好的，这只是一个观点。我确信我能想到更多，但请把这个当作任何最近开发的数据库的典型。最佳预测某个东西将继续存在于未来的指标就是它已经存在了多久 (The best predictor something will continue to exist into the future is how long it has existed)。COBOL 已经存在了几十年，它可能会继续存在几十年。

如果你有持久存储，你希望得到尽可能长期的支持。你当然可以选择为你的应用程序选择一个较新或实验性质的数据库，但无论技术属性如何，那都是一个冒险的选择。这不应该成为你默认选项。

*** 为什么不是 Kafka?**

Kafka 是一个只能追加的日志。它可以处理 TB 级别的数据。这是一个非常好的只能追加的日志。如果你想做事件源类型的事情，有来自多个由人类团队维护的服务流入的数据，它工作得非常出色。

但是：

• 在一定规模内，Postgres 中的表作为仅追加日志工作得非常好。
• 你的产品可能并没有数百人在使用，也不会有 TB 级别的事件流入。
• 弄一个 Kafka 消费者比你预期的要更容易出错。毕竟，你需要跟踪你在日志中的位置。
• 即使由云提供商维护（而且有很好的托管 Kafka 服务），这也是另一块你需要监控的基础设施。

*** 为什么不是 ElasticSearch?**

您的产品的主要功能是否是搜索数据？

如果是，ElasticSearch 将为您提供一些真正的优势。你需要将你的数据 ETL 到其中，并管理整个过程，但 ElasticSearch 就是为搜索而构建的。它擅长搜索。

如果不是，Postgres 就足够了。稍微使用一些 ilike 和内置全文搜索对于大多数应用程序来说已经足够了。您总可以在以后添加一个专门的搜索功能。

*** 为什么不是 MSSQL 或者 Oracle?**

你应该真正问自己的问题是：这些值得价格标签吗？

我不仅指直接的许可成本，还有锁定成本。一旦你的数据在 Oracle DB 中，你将永远付费给 Oracle。你将不得不永远培训你的编码人员来适应它的特性。你将必须永远在企业功能和钱包之间做出选择。

我知道你很可能不会对 Postgres 提交补丁，所以我不会假装存在某种神奇的「开源力量」，但我认为如果没有非常具体的需求去选择专有数据库，那就没必要使用它。如果没有 MSSQL 中至关重要、无法离开的功能，就别用它了。

译者注，其实多少都有吧，比如 MSSQL 的 SQL Server Management Studio (SSMS) 还是很香的。

*** 为什么不是 MySQL ?**

这是我需要一些观众帮助的一个问题。

MySQL 是 Oracle 公司的产品。有些功能被锁定在他们的企业版中。在某种程度上，你会遇到和其他数据库相同的锁定问题。但免费版的 MySQL 也已经被广泛应用于各种事物中。它已经存在了很长时间，有很多人知道如何使用它。

我的问题是，我在职业生涯中只花了大约 6个月的时间来使用它。我真的不够了解它，无法全面地将其与 Postgres 进行比较。我确信它并非秘密地好到让我在告诉人们使用 Postgres 时是在忽悠他们，并且我记得曾经读过关于Postgres 通常如何更好地支持数据库强制约束的能力，但如果有人能在这里给我上一课，我也不介意。

*** 为什么不用一些 AI 向量数据库呢？**

大多数都是新的。记住使用新事物的风险。

AI 就像一个泡沫，虽然它能承重，但终究还是个泡沫。如果可以避免，就别在上面建房子。

即使你的业务是另一种 AI 骗局，你可能只需要导入 openai 就够了。

*** 为什么不是 Google Sheets?**

你说得对。我想不出有什么缺点。就它了。

---

💡 更多资讯，请关注 Bytebase 公号：Bytebase