从 Rockset 到 ClickHouse：Lens 如何使其数据库更快更高效

Lens 是一个开放的社交协议，所有内容和互动都存储在区块链上。Lens 为用户提供对其个人资料、社交关系图和数据的所有权和控制权，同时提供技术堆栈，使开发人员能够在 Lens 上构建他们选择的社交应用程序。

与其他社交网络一样，Lens Protocol 严重依赖机器学习来创建更相关、更愉快和更值得信赖的用户体验。正如 Lens 团队解释的那样，Lens 的 ML 系统处理所有事情，从决定内容向用户显示的顺序的 Feed 排名算法，到识别和减轻恶意活动的复杂机器人检测机制。

每天，Lens 团队计算和评估各个时间段的数百个特征，以评估用户行为和内容互动。这包括大量的批处理作业（定期运行以更新模型和特征）和较轻的实时作业（例如回复排名），这些作业需要即时处理和更低的延迟以提供即时反馈。

该团队最初依赖 Postgres 和 Rockset 来支持他们的数据需求。然而，在旧设置下，他们苦于数据摄取延迟和查询并发限制，之后他们转向 ClickHouse Cloud，以获得更快、更高效的数据操作。

Lens Protocol 构建于 Polygon 区块链之上，但正在 2024 年第四季度过渡到 Lens 网络。最初，Lens 使用简单的 Postgres 数据库来管理用户互动和内容。为了使集成商（在 Lens Protocol 上构建的开发人员）更容易与区块链互动并构建前端应用程序，实施了 GraphQL API 而不是传统的 RPC 端点。

据 Lens 团队称，这最初运作良好。但随着平台的增长，以及集成商要求更复杂的功能，Postgres 的局限性变得显而易见。数据科学团队转而使用 Rockset，后者提供了更好的数据处理能力，尤其是在复杂查询和聚合方面。

然而，即使在过渡到 Rockset 之后，也出现了新的挑战。为了将数据从 Postgres 摄取到 Rockset 中，他们必须结合使用 AWS Database Migration Service (DMS) 和 Amazon Kinesis Data Streams。此过程涉及使用 DMS 从 Postgres 捕获更改，然后通过 Kinesis 流式传输数据以到达 Rockset。

Lens 团队发现，拥有多层结构增加了同步方面的延迟。此过程增加了数秒，有时甚至数分钟的延迟。对于实时作业来说，这是一个大问题。

Lens 团队描述的另一个重大挑战是 Rockset 并发查询限制。Rockset 对可以同时执行的查询数量有预定义的限制；当达到这些限制时，Lens 可以升级到更昂贵的计划（他们升级了几次，直到成本变得不可行），或者其他查询必须等待，导致数据处理延迟。这对于实时机器学习任务尤其成问题，在实时机器学习任务中，及时的数据检索和处理是关键。他们尝试了自定义解决方案来解决这些限制，但不仅约束仍然存在，而且它们还增加了整体架构的复杂性，尤其是在 Lens 的数据处理需求增长时。

因此，Lens 团队发现自己处于寻找更好的数据库管理解决方案的过程中。

当他们探索 Lens 的 Rockset 替代方案时，该团队曾短暂考虑过 Amazon Aurora，启动 RDS 集群来管理他们迫在眉睫的数据需求。然而，Aurora 被认为不足以满足 Lens 的长期需求。他们知道他们需要一个可以处理高速查询并在 Lens Protocol 增长时有效扩展的数据库。

几周前，Lens 开始将 ClickHouse 用于另一个项目。他们对该项目的主要要求是一个可以尽可能快地执行原始查询的数据库。正如 Lens 团队的一名成员所说，“如果您要寻找的唯一指标是查询速度，那么您就应该选择 ClickHouse。”

基于他们早期的 ClickHouse 经验，他们开始探索将其用于 Lens Protocol。起初，他们研究了使用 Kubernetes 运算符部署并自行管理它。然而，在更多地了解 ClickHouse Cloud 并看到它的成本效益和入门的简单性之后，他们选择了云产品。

“数据库从来都不是真正有趣的运行，”一位团队成员笑着解释道。“作为一项托管服务，ClickHouse Cloud 为我们减轻了很多负担。”

他们开发了一个快速的概念验证，设置了现有 Postgres 数据库和 ClickHouse 之间的数据同步。他们使用 PeerDB 来管理 CDC 流程，有效地将 Postgres 的更新流式传输到 ClickHouse，而无需复杂的自定义配置。通过创建数据镜像和配置必要的 helm charts，他们很快就拥有了一个功能齐全的设置。

正如一位 Lens 团队成员所说，“集成非常快。只需一两天即可完成实施。”

该团队将迁移描述为“无缝”。随着他们的大部分数据已经迁移并在 ClickHouse 中运行，该团队现在专注于调整和重写以前依赖 Rockset API 的现有代码，以使其与 ClickHouse 的 API 一起工作。

据 Lens 称，这比预期的要快，因为他们不必围绕 Rockset 所需的库构建大量方法。他们只需要处理查询和数据插入，而无需担心扩展 VI 或其他复杂性。PeerDB 集成使流程更加顺畅，因为这两个系统都是为彼此构建的。

过渡到 ClickHouse 已经为 Lens Protocol 的数据操作带来了重大利益。通过消除以前 Rockset 所需的多个数据传输层，该团队实现了近乎即时的数据处理。对于包含数千万行的表，使用 Rockset 时摄取时间约为 24 小时，而现在使用 ClickHouse 和 PeerDB 时仅为 1-2 小时。

正如一位团队成员所说，“我们减少了摩擦。我们现在拥有 ClickHouse 和 PeerDB，它们是为彼此量身定制的，而不是拥有三个勉强协同工作的工具。这让我们的生活变得更轻松，并且完全消除了延迟问题。”

ClickHouse 在不降低性能的情况下处理大量并发查询的能力是另一个巨大的优势。与 Rockset 不同，在 Rockset 中，查询限制阻碍了 Lens 团队的工作并导致了令人沮丧的瓶颈，ClickHouse 允许团队随着 Lens Protocol 的增长而扩展其 ML 操作。额外的容量将提高其数据处理工作流程的速度和效率，使团队能够支持更复杂的功能并改善平台上整体用户体验。

“我们希望尽可能多地服务请求，”一位团队成员说。“我们对 ClickHouse 给我们带来的东西非常满意。”

回顾迁移过程，一个重要的经验教训是快速原型设计的价值。使用 ClickHouse 入门和开发 POC 非常容易，这使 Lens 能够快速测试和验证其性能。

“使用产品始终比阅读文档和构建架构图更好。使用产品是了解某些东西是否有效的最简单方法。”

Lens 团队还反思了平台工程的重要性，以及选择长期、可扩展且协同工作的解决方案的重要性。

展望未来，Lens 对 ClickHouse 为 Lens Network 及其未来社交产品解锁的可能性感到兴奋。这包括开发 特征存储，以简化跨不同机器学习模型的特征管理和重用，从而提高一致性并加速新 ML 解决方案的部署。

通过迁移到 ClickHouse Cloud，Lens 在过渡到 Lens 网络时，能够很好地扩展数据操作。除了 ClickHouse 在性能和效率方面提供的价值外，Lens 团队还认识到迁移提供的可扩展性和安全感。

正如团队成员所说，“当事情顺利且容易时，作为开发人员，您会有一种良好的直觉。我们不必经历一个漫长的过程，寻找奇怪的错误。ClickHouse 让我们有信心，我们做出了正确的决定，并且可以扩展。”