彻底摆脱现有的系统

转自https://blog.danslimmon.com/2023/08/11/squeeze-the-hell-out-of-the-system-you-have/#like-2777

大约一年前，我向同事和经理提出了关于 Postgres 性能的危险信号。我们的数据库正在努力跟上我们的整体 SaaS 应用程序生成的负载。 CPU 利用率在 60% 到 80% 之间，并且至少有一次飙升至 100%，导致短暂中断。

现在，我们长期以来一直在考虑 Postgres 的容量。当数据库看起来太忙时，我们会用更大的实例替换它并继续。这节省了我们很多时间，让我们能够专注于其他事情，比如构建功能，这非常棒。

但这一次，无法垂直扩展数据库服务器：我们已经在最大的实例上。我们即将让该实例超载。

许多方案都已浮出水面。其中最重要的是：

• 分片写入。启动一组独立的数据库，并根据某种分区策略将数据写入其中一个数据库。

• 实施微服务。将整体拆分为多个互连的服务，每个服务都有自己的数据存储，可以根据自己的条件进行扩展。

这两个选项都很酷！任何一种都可以根据其优点提出强有力的理由。通过写入分片，我们有可能将容量提高 2 甚至 3 个数量级。借助微服务，我们可以自由地使用“适合工作的工具”，选择针对每个服务工作负载的要求进行优化的数据存储。技能树的任何一个分支都将为容错和操作弹性提供令人兴奋的选项。

无论哪种方式，每个人都必须同意：我们已经超越了旧的、天真的实现。步步高升！我们可以做困难的事情！

在这种情况下，面对一系列令人眼花缭乱的下一代架构选项，这些选项可以让我们度过这十年，我们很容易忘记我们的目标是什么：获得数据库性能尽在掌控。

复杂性耗费注意力

有时，必须在复杂性上做出飞跃。这通常是一个好问题。如果对您的系统的需求足够大，以致您现有的技术变得过时，那么更多的增长可能即将到来！如果您现在就可以投入投资并构建更先进的架构，那么您将看到不受限制的逐年成功的光明未来。

但不要只考虑实施成本。复杂性增加的真正成本（通常是更大的成本）是注意力。

如果您决定跨数据库进行分片，那么您不仅必须付出构建新架构的金钱、时间和机会成本：您还必须采用新架构在每个后续技术决策中都要考虑复杂性。想要分片写入吗？很好，但这会使未来有关备份、监控、迁移、ORM 和网络拓扑（仅举几例）的决策变得复杂。别让我开始研究微服务。

想想这些成本有多大。为了支持额外的架构复杂性，需要延迟或放弃多少功能交付？

始终优先减缓复杂性的增长

我们应该尽可能推迟复杂性的显着增加。

当复杂性飞跃出现时，通常还有机会从您现有的系统中榨取一些额外的能量。通过调整工作负载、调整性能或以某种方式补充系统，您可能能够增加数月甚至数年的运行时间。如果可行，这些选项总是比构建下一代系统更可取。

让我们回到重载的 Postgres 实例的示例。在这种情况下，我们最终要做的是双重的：

1. 两名工程师（我和我的同事 Ted，但主要是 Ted）花了大约 3 个月的时间主要研究数据库性能问题。没有灵丹妙药。我们使用遥测技术来识别大量查询，深入研究（Rails）代码库以了解它们来自哪里，并优化或消除它们。我们还调整了很多 Postgres 设置。

2. 另外两名工程师在代码库中开辟了一条路径，在副本数据库上运行某些昂贵的只读查询。这项工作与 (1) 大约在同一时间取得了成果，当时我们卸载了单个最频繁的查询（通过轮询 Web 客户端触发的 SELECT）。

这两项努力共同将数据库的每周最大 CPU 使用率从 90% 降低到 30%。

现在我们晚上可以睡觉了。无论是在 CPU 空间还是从主节点卸载负载的能力方面，我们都有巨大的增长空间。此外，由于我们的工作涉及代码库的许多部分，并且需要与许多不同的开发人员协作，因此我们现在拥有关于现有系统的强大的分布式知识库。如果需要的话，我们有能力进一步挤压它。

并不意味着复杂性不好

当然，我并不是说复杂性不好。有必要。有一天，我们将达到数据库架构的基本极限，在那一天到来之前，我们需要在复杂性上进行跳跃。

但在那之前，因为我们先挤压，所以我们可以继续使用最无聊的系统。这是迄今为止更便宜、更实用的选择。