提速 100 倍：GraphQL Hive 从 Elasticsearch 迁移到 ClickHouse

我们欢迎 The Guild 作为嘉宾来到我们的博客。请继续阅读，了解他们为何使用 ClickHouse 以及他们从 Elasticsearch 迁移到 ClickHouse 的历程。

GraphQL Hive 是一个用于 GraphQL API 的 Schema 注册表、监控和分析解决方案。

作为一个完全开源的工具，GraphQL Hive 帮助您跟踪变更历史记录，防止 API 发生中断，并分析 API 的流量。

GraphQL Hive 让您了解您的 GraphQL API 如何被使用以及最终用户的体验如何。

对于那些不熟悉 GraphQL 的人来说，它是一种前端和后端之间的通信协议。我们建议阅读 GraphQL 基金会撰写的“GraphQL 简介”，我们 The Guild 也是该基金会的成员。

正如您所看到的，只获取了少量数据，项目名称和贡献者保持不变。这就是 GraphQL Hive 的目的，研究和分析 GraphQL API 的使用情况。

首先，让我们解释一下 GraphQL Hive 操作的数据类型。

我们可以将它们分为三类：

• Schema 注册表
• 监控
• 分析

本文将主要关注监控和分析功能，这些功能最终成为最具扩展挑战的部分。

GraphQL Hive 尝试回答以下问题：

• 谁是 GraphQL API 的消费者？
• GraphQL API 的哪些部分被谁消费？
• GraphQL API 的性能如何？

为了回答这些问题，GraphQL Hive 分析每个 HTTP 请求并收集：

• API 消费者的名称和版本
• 请求的类型和字段列表（如 User、Comment、User.id、User.name）
• 总体延迟
• 请求的主体

GraphQL Hive 存储每个 HTTP 请求的详细信息。

这种类型的数据不应被修改，需要生存时间机制和一组用于分析和数据聚合的函数。

我们决定使用 Elasticsearch，因为它满足了所有要求，并且足够灵活，可以随着时间的推移发展产品。

我对 Elasticsearch 最大的担忧是查询语言。The Guild（GraphQL Hive 背后的公司）的每个人都熟悉 SQL，因此基于 JSON 的语言意味着陡峭的学习曲线。

在预览计划的某个时候，我们遇到了第一个扩展问题。

随着我们存储的数据越来越多，平均响应时间越来越慢。

另一个问题与索引有关。一个大用户影响了其他小用户的查询性能。

我们尝试通过为每个用户创建一个索引来改进它，但是由于 Elasticsearch 的整体速度远低于我们的预期，我们开始寻找替代方案。

在寻找替代方案时，这些是要求：

• 易于学习和维护
• 卓越的性能
• 适用于数据分析和聚合
• 内置 TTL
• 类型系统
• 高基数无问题

我们必须说，数据库比人还多，基准测试也更多，结论也各不相同。

经过研究，我们决定测试 InfluxDB、TimescaleDB、Druid 和 ClickHouse。

我们创建了一个包含 2000 万行的数据集，其中一个用户拥有其中一半。为了衡量性能，我们尝试计算几个高百分位数，并查看一个大用户是否会影响其他小用户的查询性能。

我们对 InfluxDB 抱有很高的期望，它看起来像是一个极快的时序数据库。不幸的是，它不支持高基数。GraphQL Hive 中收集的每个 HTTP 请求都可以用所有用户的无限数量的值进行标记。

对我们来说，入门也很困难。

查询时间约为 5 秒。

接下来是 TimescaleDB。我们喜欢它使用 SQL 并且支持表之间关系的事实。总体性能比我们使用 Elasticsearch 的体验好得多。

响应时间接近 3 秒。

在我们研究时（2021 年 4 月），ClickHouse 对我们来说感觉非常神秘。我们没有听说太多关于它的信息，我们只找到了一些案例研究。它看起来与 TimescaleDB 非常相似，但为数据分析提供了更广泛的功能集，并且表引擎的集合非常适合我们的用例。

查询时间是… ~100 毫秒。

我们没有测试 Druid，它感觉太复杂了。即使它可能能够处理大量数据，我们也想找到一些简单而强大的东西，而 ClickHouse 似乎是一个完美的契合。

从 Elasticsearch 到 ClickHouse 的迁移是逐步完成的，并且并不复杂。

在预览计划期间，收集数据的生存时间仅为 30 天。

这就是为什么我们决定在一个月内同时将数据写入两个目的地。这使我们能够无缝地将读取操作转移到 ClickHouse，而不会造成任何停机。

切换后，与之前的数据管道相比，我们看到了平均 100 倍的改进。

ClickHouse 帮助我们将每月的数据量从数百万扩展到数十亿，而没有出现任何麻烦。

如果您对我们的数据库结构以及我们如何使用 ClickHouse 感兴趣，我们建议您查看 GitHub 上的源代码 on GitHub。

我们还撰写了一篇更深入的文章，解释了我们的 ClickHouse 设置以及我们如何每月处理数十亿个 GraphQL 请求。

我们当前的数据管道使用 ClickHouse 的单个实例。它运行良好，到目前为止，我们还没有遇到任何问题，但是最终将需要将其扩展到更多节点。

这就是为什么我们开始转向 ClickHouse Cloud。

由于其开箱即用的分片和复制支持，我们可以专注于开发新功能，并让 ClickHouse Cloud 负责其余的工作。