如何使用 Postgres 折叠您的堆栈 实现一切#postgresql认证

技术蔓延如何蔓延

假设您正在开发一款新产品或新功能。一开始，您的团队会列出需要解决的技术问题。有些解决方案您将自行开发（您的秘诀），而其他解决方案您将使用现有技术（可能至少包括一个数据库）来解决。

#PG培训#PG考试#postgresql培训#postgresql考试
除非您从事数据库构建业务，否则自行开发数据库通常是不明智的；它很复杂、风险很大，而且需要非常专业的技能。因此，您最终可能会采用各种现有数据库：Postgres 用于事务数据，Elastic 用于全文搜索，Influx 用于时间序列，Pinecone 用于矢量操作，ClickHouse 用于分析。突然之间，您的技术堆栈变得庞大。

为什么堆栈蔓延是一个问题

添加的每个新数据库都会带来一系列挑战：需要学习不同的语言、需要理解一致性模型，以及无法忽略的操作细节。这不仅增加了复杂性，还带来了我所说的“虚线”复杂性，即数据在每对系统之间流动时产生的额外开销。数据库越多，虚线越多，推断整个系统的状态就越困难。

你拥有更多的数据库，因此，你遇到的问题也更多。

崩溃的理由

那么还有什么替代方案呢？在我看来，这会让你的堆栈崩溃。如果你用一个数据库解决更多问题，那么你就可以移除多个复杂的软件以及它们之间的虚线复杂性。在头脑中保持数据流的心理模型以及推理不同时间的数据一致性要容易得多。你可以节省出原本花在操作这些新数据库上的时间，并且可以将这些时间用于构建功能。

PostgreSQL 在堆栈折叠方面表现出色，因为它既通用又专用。它不仅是一个出色的关系数据库，还通过其扩展框架支持广泛的额外用例。PostgreSQL 可以轻松处理 全文搜索 、 时间序列数据、 AI 向量 和分析等工作负载。

PostgreSQL 不仅功能多样，而且强大而成熟。人们已经在生产环境中使用 PostgreSQL 超过 20 年，随着采用速度的加快，PostgreSQL 的发展没有任何放缓的迹象。边缘情况众所周知，部署模式、恢复策略和高可用性定义明确，并且有许多公司和拥护者可以为您提供帮助。

正因为如此，我鼓励您使用 PostgreSQL 解决尽可能多的问题，压缩您的堆栈，降低复杂性，并让您有时间专注于构建。

对位：最适合这项工作的工具？

有一个众所周知的论点，即您应该选择“最适合工作的工具”，但这个论点有时会被颠倒过来，即“如果您只有一把锤子，那么所有东西看起来都像钉子”。我认为“PostgreSQL 适用于一切”的原则并不与这些原则相矛盾，只要您确保着眼于大局即可。

您如何定义“最适合该工作的数据库”？它是速度最快的吗？最容易使用的吗？最容错的吗？还是可以最无缝地集成到您现有的基础架构中并且您知道如何使用的数据库（也许是已经存在的数据库）？最佳选择通常介于这些标准之间。

您应该选择数据库 X 来获得其速度，数据库 Y 来获得其效率，还是数据库 Z 来获得其云优化？如果老牌的 PostgreSQL 能够满足您现在的需求（具有久经考验的有效性），并且可以进一步扩展（可能达到您当前需求的 10 倍），那么我认为您应该从已知数量开始。只有当 PostgreSQL 缺乏关键功能时才考虑添加其他数据库，权衡其好处与管理多个系统的额外复杂性。或者，换一种说法， 选择无聊的技术 （对不起 Postgres，我保证我仍然认为你很令人兴奋）。

让我们考虑两种可能的情况：

• PostgreSQL 适用于一切 ：多年后，您的工作量超出了原有系统的能力。PostgreSQL
  在某些方面表现不佳，但这是一个“好问题”——成功的标志，也是改进架构的提示。
• 过度设计，包含多个数据库
  ：您已准备好处理庞大的规模，但系统却很脆弱、充满极端情况且难以维护。这不仅具有挑战性，而且会威胁到您的运营稳定性。

考虑到这些情况，我认为以 PostgreSQL 为中心的系统在理论上的未来挑战，要比目前过早选择多数据库架构的复杂性更可取。

最后的话

“PostgreSQL 适用于一切”并不意味着永远不使用其他数据库。老实说，它甚至不是说将 PostgreSQL 用于一切。它是反对过早过度设计解决方案的格言，也是倡导简单性的好处的格言。请记住，世界上有很多公司和应用程序，在 Timescale 等公司的帮助下，PostgreSQL 将扩展以满足他们的大多数需求。