迈克尔·蔡 - 博客 - 为什么 Figma 用 PostgreSQL 重新发明了轮子？

Sammy Steele (opens new window):

数据显示，我们的一些表格包含几千兆字节和数十亿行，已经变得太大，无法适应一个单一的数据库。在这种规模下，我们开始在 Postgres 的清理过程中看到可靠性受到影响，这些清理是保持 Postgres 不会耗尽事务 ID 并崩溃的重要后台操作。我们最高写入的表格增长得如此之快，以至于我们很快就会超过亚马逊关系型数据库服务（RDS）支持的每秒最大 IO 操作（IOPS）。垂直分区在这里无法拯救我们，因为最小的分区单元是单个表。为了防止我们的数据库崩溃，我们需要一个更大的杠杆。

[…]

水平分片比我们之前的扩展工作复杂一个数量级。当一个表被拆分到多个物理位置时，查询就变得更加复杂。在这种环境下，我们发现将数据分片到多个数据库中是最好的方法，因为这样就能够将负载均衡到多个节点，而不是依赖于单个数据库处理所有请求。 物理数据库，我们失去了ACID SQL数据库中所默认的许多可靠性和一致性属性。

我们构建了一个名为DBProxy的服务，拦截应用程序层生成的SQL查询，并动态地将查询路由到各种Postgres数据库。DBProxy包括一个能够解析和执行复杂水平分片查询的查询引擎。DBProxy还使我们能够实现诸如动态负载分担和请求对冲等功能。

我们避免了实现“过滤逻辑复制”（仅将数据的子集复制到每个分片）的必要。相反，我们复制了整个数据集，然后只允许读取/写入属于特定分片的数据子集。 他们利用亚马逊RDS订阅PostgreSQL服务。关于大型云提供商和小型供应商提供的PostgreSQL托管服务，有一个常被忽视的有趣事实。尽管这些服务通常提供所有核心的PostgreSQL功能，但支持的扩展列表取决于服务提供商。

现在，我们有CitusData，这是一个成熟的用于分片的PostgreSQL扩展，而我们知道Figma使用亚马逊的RDS，这是一个完全托管的PostgreSQL服务。然而，如果您查看RDS支持的PostgreSQL扩展列表，您会发现CitusData并不包含在内。

所以，现在让我猜测一下。Figma重新发明轮子并为分片创建自己的定制解决方案的真正原因可能就是这么简单——Figma想要继续使用RDS，而且由于亚马逊过去已经决定不支持CitusData扩展，Figma团队别无选择，只能从头开始开发他们自己的分片解决方案。 MJTSai (opens new window) 数据库 (opens new window) Figma (opens new window) 优化 (opens new window) PostgreSQL (opens new window) 编程 (opens new window) SQL (opens new window) Web (opens new window)