Clera 一夜之间将 500GB 生产库迁至 ClickHouse Managed Postgres

这是 Daniel Wintermeyer（CTO 兼联合创始人）和创始工程师 Julian Bouchard 的客座文章。Clera的 CTO 兼联合创始人），以及创始工程师 Julian Bouchard 撰写的客座文章。原文发布在 Clera 的博客上 这里。

招聘已经坏了。候选人投递简历后石沉大海，创始人淹没在自己不想读的简历里，而真正合适的人几乎从不会出现在同一个房间里。我们认定一定有更好的办法。你不是去搜索一份工作。你去和 Clera 对话。

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

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

系统中最重要的是数据。每一次录入对话、每一条职位列表，以及关于谁适合什么角色的每一个信号，都会喂给匹配引擎，而这个引擎的质量取决于其背后的数据。事实证明，这是一个非常难解决的问题。

超越我们旧数据库供应商

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

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

当 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 生命周期设置、启用 publications，以及对键和扩展进行预检查。扩展是最大的痛点。Postgres 提供种类繁多的扩展，而有些提供商有非常特定的扩展，无法移植到其他地方。Julian 事先花了几天时间修改系统的部分内容来绕过这一点，并确保我们能够干净地迁移到任何提供商。

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

迁移本身还算容易。更难的部分是把触发器放回去、重建索引，以及重新排列表的顺序。然后是奇偶校验和实际的切换，重新部署整个系统指向新数据库，并确保没有东西崩得太厉害。这一切都必须快速完成，因为我们应用了大量 schema 变更，而你不希望在新的 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 个设置