Clera 如何一夜迁移 500 GB 生产环境 Postgres 数据库

作者：Daniel Wintermeyer，CTO 兼联合创始人，以及 Julian Bouchard，创始工程师。本文的一个版本也发布在 ClickHouse 博客上。

招聘已经失灵。候选人投递简历后石沉大海，创始人淹没在他们根本不想读的简历里，而真正合适的人几乎从未有机会相遇。我们决定必须找到更好的方式。你不再需要搜索工作，而是直接与 Clera 对话。

我们是一个 AI 人才代理，服务于市场的两端，代表超过 200,000 名候选人，帮助他们在纽约和旧金山主要以 pre-seed 到 B 轮为主的公司找到工作。目前，平台上大约有 2,250 个在招职位，每天有超过 2,000 名新候选人加入。

在底层，我们运行着一个多智能体系统。在候选人端，你注册后通过电子邮件、iMessage 或聊天界面与我们交流，智能体处理从初次接触、了解你的偏好，到为你推荐和匹配合适职位的一切事务。在公司端，我们入驻创始人的 Slack 频道并直接介绍候选人，因此没有申请环节。我们只推荐合适的职位，并且我们严格筛选，大约 50% 的推荐能带来面试。由于我们采用基于成功收费的模式，对我们来说最重要的是让人们在他们想工作的地方获得职位。

系统中最核心的部分是数据。每一次接触对话、职位列表，以及关于谁适合什么角色的信号，都会输入匹配引擎，而引擎的好坏完全取决于其背后的数据。事实证明，这是一个非常难以解决的问题。

超越旧数据库供应商

迁移时，我们在 Postgres 上运行着超过 500 GB 的数据（现在接近 1 TB）。在迁移到 ClickHouse Managed Postgres 之前，我们与之前的数据库供应商遇到了许多许多问题。

最明显的例子之一是一个单一的人才查询，一个本应瞬间完成的候选人查找，却花了大约三秒钟。我们到处都有分析查询，还有数据库连续六天 CPU 占用率达到 100% 的情况。还有超时，以及丢失和失败的写入。如果你遇到过这些问题，你就知道它们有多痛苦，因为你需要重试，而你绝对不希望数据库让你失望。最糟糕的时候，我们甚至无法通过主键向表写入更新。

当 Julian 审视我们的工作负载时，它分为三种类型：

• 热读取：较小的 CTE、职位列表查询和物化视图读取，当有人浏览网站时需要快速返回。
• 点查找：微小的主键读写，在没有阻塞时应该是亚毫秒级的。
• 后台工作：团队运行或仪表板展示的重型分析 CTE，以及用于 SEO 的物化视图刷新。

最大的痛点是点查找。它们需要花费数秒，因为被后台查询阻塞了。除此之外，我们抓取大量数据，因此会出现突发的抓取高峰，在一切之上堆积 IOPS、CPU 和实际耗时。

我们决定需要一个运营型 Postgres，在分析和抓取高峰同时运行时，点查找仍能保持快速，存储能够承受 IOPS，并且由他人管理。我们并不是真正的数据库专家。我们想要一个能直接工作的方案。

选择 ClickHouse Managed Postgres

我们最初评估了四家供应商：Supabase、Neon、PlanetScale 和 ClickHouse Managed Postgres。我们并不知道 ClickHouse 也是一个选项，直到我们在 Langfuse 的朋友说：“哦对了，ClickHouse 现在也加入了竞争。他们提供带 NVMe 存储的托管 Postgres。你们也应该和他们聊聊。”

我们通过两种方式测试了这些供应商。首先是在我们自己的生产数据上，在实际运行的工作负载下模拟负载进行回放；其次是用标准化基准测试，以获得一个其他供应商也会发布结果的通用数字。

对我们的生产工作负载进行基准测试

对于回放，我们将约 500 GB 的生产数据加载到全部四家供应商上，并运行上述三类查询，测量：

• 每秒查询数（QPS）
• P99 延迟
• 错误百分比
• 获取时间
• 等待事件（我们不希望被阻塞的事情被阻塞的频率）

Julian 尝试通过每家供应商的连接池运行所有内容，但连接池的设置各不相同，统一它们并不值得，因此最终数据基于直连。

ClickHouse Managed Postgres 几乎在所有方面胜出，尤其是 IOPS。差异在于 本地 NVMe 存储 与大多数供应商使用的网络附加存储，后者会在每次磁盘读写时增加延迟。仅这一点就足以立即淘汰 Supabase 和 Neon，剩下 PlanetScale 和 ClickHouse。

用 TPC-C 验证基准测试

然后我们运行了 sysbench TPC-C。它基本上是一个模拟业务的数据集，混合了读和写查询。（需要注意的是，sysbench 并不完全符合 TPC-C 标准，但它给了我们一个可比较的基线。）两家供应商都在同一机器规格上运行，使用 500 GB 生成数据。一个实验使用 8、16、32、64 和 128 线程，连续运行三次，这样我们可以测量运行之间的方差以及吞吐量。我们运行了多个实验，再次跟踪 QPS、P99 和错误率，这次还测量了每秒事务数（TPS）和变化。

ClickHouse Managed Postgres 再次横扫。在默认配置下，未做任何调整，其吞吐量优势从 128 线程时约 16% 到 16 线程时 42% 不等：

需要注意的是，它们开箱即用的 PostgreSQL 设置并不相同。调优是每家供应商产品的一部分，但也可以在一定程度上手动调整。因此我们从 PlanetScale 那里获得了关于如何统一这些设置的建议，并已将其纳入考虑，不过如果不通过他们的工程团队，我们无法测试大页。

所有内容都在 GitHub 上的开源仓库 中，包括所有结果、日志、脚本和 Terraform 文件，还有一份简短的 LaTeX 报告以及供你的 LLM 使用的上下文转储。请查看、仔细审查、复现，如果有错误请发邮件给我们。如果你正在评估任何类型的数据库，我们鼓励你自己运行类似的东西并将其开源。你可能会出错，然后人们可以纠正你。这就是在社区中分享知识的美妙之处。

用 ClickPipes 在一夜之间迁移数据库

决定采用 ClickHouse Managed Postgres 是在一个周四。周五早上，Daniel 拿了一杯馥芮白，走进我们上午 10 点的每日例会，准备讨论即将进行的迁移。Julian 说：“哦对了，我们已经用上 ClickHouse 了。”

前一天晚上 11 点，Julian 完成了最后的准备工作。他知道，如果我们把所有准备工作都做完然后搁置，就会一直往后推。所以，想着这事迟早得做，他决定不如现在就做。

在准备阶段，我们遵循了 ClickHouse 的迁移指南。在源端，这意味着设置 WAL 生命周期、启用发布，以及对键和扩展进行预检查。扩展是最头疼的部分。Postgres 提供了种类繁多的扩展，而有些提供商还有非常特殊的扩展，无法移植到其他地方。Julian 事先花了几天时间修改系统的部分内容来绕过这个问题，并确保我们能干净地迁移到任何提供商。

他设置了两条 ClickPipes 管道，一条用于核心数据，一条用于非必要数据，这样他就可以专注于核心数据，同时让两条管道并行运行。我们的创始团队是德国人，数据库一直在欧盟，所以我们借此机会同时把它迁到了美国。那是 500 多张表跨越大西洋，同时生产流量还在冲击它。在测试期间，Julian 一度因为欧盟延迟加上表数量的组合而遇到了一个问题。ClickHouse 有人在晚上 11 点为此提交了一个 PR。这种响应速度很棒，让迁移轻松了很多。

迁移本身还算容易。更难的部分是重新设置触发器、重建索引和重新排序表。然后是数据一致性检查和实际切换，重新部署整个系统指向新数据库，并确保没有严重故障。这一切都必须快速完成，因为我们会应用大量 schema 变更，你不希望在旧 schema 已经被复制到新库时还有人去改它。到早上 6 点或 7 点，主要就是监控和清理了。上午 10 点的每日例会后，Julian 去睡觉了。

查询更快，随时可扩展

使用 ClickHouse Managed Postgres 后，我们的用户和内部管理员的一切加载都快了很多，他们每天都用我们的工具，对此非常感激。再也没人担心团队里有人会随手跑一个耗时数小时的分析查询，把整个系统拖垮。这种情况以前偶尔会发生，但现在不会了。

同样重要的是，我们有了喘息的空间。目前大部分时间 CPU 使用率在 10% 到 20% 左右。迁移以来我们没有改过任何一项设置。开箱即用的性能已经针对我们的需求调优好了，对我们来说就是直接能用。价格方面，和之前差不多，甚至略便宜一点，但性能和可扩展性更好。

值得一提的是，我们迁移到的不是 ClickHouse 分析数据库。我们迁移到的是他们的托管 Postgres 服务，本质上就是原版 Postgres，但底层用的是本地 NVMe 存储，而不是网络附加磁盘。目前这就是我们所需要的，但如果业务的分析侧将来超出了它的能力，路径已经在那里了。需要时，Managed Postgres 可以同步到 ClickHouse。与此同时，我们有信心可以给系统施加更大的负载。

数据一览

• 500 GB 已迁移（现在接近 1 TB）
• 500+ 张表从欧盟迁至美国
• 1 个晚上，从最终准备到切换完成
• 100% → 10 到 20% CPU
• 在 sysbench TPC-C 上，TPS 比第二名高出多达 42%
• 迁移以来更改了 0 项设置