Figma 的数据库团队如何撑过规模增长

原文 ↗ Hacker News 讨论 ↗

分布式数据库 vs. 分片 Postgres

  • 许多人认为这是个经典故事：先从单个 RDS 实例开始，遇到扩展瓶颈后花几年时间做分片；也有人说应该从第一天起就“直接用分布式数据库”。
  • 另一些人反驳说，在 2012–2016 年间，成熟的分布式 SQL 方案很有限，尤其不适合有大量联表查询的高度关系型工作负载。
  • 还有人指出没有免费午餐：分布式系统会增加复杂性、成本，并且需要尽早做出有时很脆弱的分区键决策。

Cloud Spanner 与云厂商锁定

  • Spanner 被称为 Google 内部“神奇”的技术，拥有很强的保证，但也被认为：
    • 很贵。
    • 对 GCP 形成深度锁定，而许多人因为对产品频繁变动以及过去停服/定价问题的印象而不信任它。
  • 有些人宁愿要自己掌控的差一点的技术，也不要被供应商绑定的更强技术；另一些人则表示，Spanner 的托管一致性/复制能力值得这个溢价。

按租户数据库 vs 逻辑分片

  • 许多人疑惑，为什么不为每个客户单独放一个 DB（或 schema），从而避免跨租户事务。
  • 被提到的优点：心智模型更简单、隔离性更好、备份更容易、可把大租户在节点间迁移。
  • 被提到的缺点：到了成千上万租户时，迁移/schema 会变得很痛苦；如果租户共享物理实例，仍然会有“吵闹邻居”问题；Postgres 的元数据和迁移本身也可能成为瓶颈。
  • 一些团队报告说，他们在数千个租户 schema 上取得了很大成功；另一些团队则表示最终放弃了这种方式，因为它难以管理。

现有 Postgres / NewSQL 方案

  • 评论者提到 Citus 或 Vitess 的相似性，并推测为什么没有使用它们：
    • RDS 不支持 Citus 这类扩展。
    • 早期 Citus 的限制（协调器瓶颈、联表限制）。
    • 相比在已知的 RDS Postgres 上渐进式分片，完整迁移的风险和工作量更大。
  • NewSQL 系统（CockroachDB、Yugabyte、TiDB）被认为很适合绿地项目，但：
    • 会带来新的运维学习曲线。
    • 对某些工作负载可能有更差的延迟/吞吐。
    • 在 Figma 这样的规模下，仍然需要复杂且高风险的数据迁移。

成本、风险与工程权衡

  • 有人估算，自研分片的工程成本可能高达数百万美元，并且要几年时间才能相对托管分布式方案“回本”。
  • 也有人回应称，对于一个高价值、快速增长的产品来说，尽量降低迁移风险并利用已有的 Postgres/RDS 经验，比纯粹的成本优化更重要。

其他主题

  • 一般认为 NoSQL 不适合 Figma 这种高度关系型的数据模型。
  • 有些人觉得这个方案很巧妙，但也过度工程化，并担心长期维护和“关键人物”风险。
  • 还提到了 Aurora Limitless，但被认为太新，而且很可能非常昂贵。