垂直分区是相对容易且影响很大的扩展杠杆，能快速为我们带来显著的发展空间，也是迈向水平分片的垫脚石。Figma 的数据库堆栈自 2020 年以来增长了近 100 倍，虽业务在扩张是好事，但也带来了技术挑战。过去四年，他们努力保持领先，2020 年使用单台 AWS 最大物理实例上的 Postgres 数据库，到 2022 年底构建了带有缓存、只读副本和十几个垂直分区数据库的分布式架构，将相关表组分成自己的垂直分区以实现增量扩展。

尽管有增量扩展进展，但他们知道垂直分区有局限性，初始扩展努力集中在降低 Postgres CPU 利用率，随着集群变大和异构，开始监控各种瓶颈，确定这些限制对预测每个分片的可用空间很关键。数据显示一些表太大，导致可靠性受影响，垂直分区已无法解决，需要更大的杠杆——水平分片。

他们制定了一系列目标和必备条件来应对短期挑战并为长期增长做准备，如最小化开发者影响、透明扩展、避免昂贵回填等。在探索选项时，考虑了多种水平分片数据库解决方案，因切换到其他数据库需复杂数据迁移且有风险，而 NoSQL 数据库不适合他们复杂的关系数据模型，所以决定在现有垂直分区 RDS Postgres 基础设施上构建水平分片解决方案，选择适合 Figma 特定架构的方案，避免通用实现，同时保持向后兼容性。

水平分片比之前的扩展努力复杂一个数量级，会失去 ACID SQL 数据库的一些可靠性和一致性属性，他们知道实现全水平分片是多年的努力，首先要在生产中分片一个相对简单但流量高的表以证明其可行性，这花费了团队约九个月时间。他们的水平分片工作有一些独特设计，如 coloc（水平分片组）、逻辑分片、DBProxy 查询引擎、影子应用准备和全逻辑复制等。

在水平分片实现中，选择合适的分片键很重要，他们根据 Figma 的数据模型选择了 UserID、FileID 等分片键，并引入 coloc 提供友好抽象，为确保数据均匀分布，虽避免了迁移到更随机的 ID，但决定使用分片键的哈希进行路由。为降低水平分片推出的风险，他们分离了逻辑和物理分片，先进行逻辑分片以验证服务栈，再进行物理分片操作。为支持水平分片，他们重建了后端堆栈，构建了 DBProxy 服务，包括查询引擎等组件，处理复杂的查询解析和执行。对于一些复杂查询，需要进行“散射 - 聚集”操作，他们确定了支持 90%常见查询的子集语言。

他们还通过创建 Postgres 视图来封装逻辑分片，先在未分片的物理数据库上创建视图，逐渐进行分片操作并通过功能标志回滚，同时收集查询语料进行负载测试以验证视图的性能影响。在拓扑管理方面，他们构建了数据库拓扑来表示逻辑和物理分片抽象，使其能快速更新状态并避免路由错误，还简化了数据库管理。

最后进行物理分片操作时，复用了很多水平分片逻辑，但有一些差异，他们能够更快地推进首次物理分片操作。他们已经在 2023 年 9 月推出了第一个水平分片表，未来将继续分片更复杂的数据库，同时也将重新评估水平分片的方法。他们在水平分片之旅中取得了很多进展，但挑战才刚刚开始，感谢相关团队成员的努力。