我们很高兴欢迎The Guild作为嘉宾来到我们的博客。继续阅读以了解他们为什么使用ClickHouse以及他们从Elasticsearch迁移到ClickHouse的历程。
什么是GraphQL Hive？
GraphQL Hive是一个用于GraphQL API的Schema注册中心、监控和分析解决方案。
作为一个完全开源的工具，GraphQL Hive帮助您跟踪更改历史，防止API中断并分析API的流量。
GraphQL Hive让您了解GraphQL API的使用方式以及最终用户的体验。
什么是GraphQL？
对于不熟悉GraphQL的人来说，它是一种前端和后端之间的通信协议。我们建议阅读GraphQL基金会撰写的“GraphQL入门”，我们The Guild也是其中的一员。
如您所见，只获取了少量数据，项目名称和贡献者保持不变。这就是GraphQL Hive的目标，研究和分析GraphQL API的使用情况。
用于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请求的详细信息。
之前，在GraphQL Hive中……
此类数据不适合修改，需要生存时间机制以及用于分析和数据聚合的一组函数。
我们决定使用Elasticsearch，因为它满足了所有条件并且足够灵活，可以随着时间的推移发展产品。
Elasticsearch的问题
我对Elasticsearch的最大担忧是查询语言。Guild（GraphQL Hive背后的公司）的每个人都熟悉SQL，因此基于JSON的语言意味着陡峭的学习曲线。
在预览程序的某个阶段，我们遇到了第一个扩展问题。
随着我们存储越来越多的数据，平均响应时间变得越来越慢。
另一个问题与索引相关。一个大型用户会影响其他小型用户的查询性能。
我们尝试通过为每个用户创建索引来改进它，但由于Elasticsearch的整体速度远低于我们的预期，因此我们开始寻找替代方案。
Elasticsearch的替代方案
在寻找替代方案时，这些是我们的要求
- 易于学习和维护
- 卓越的性能
- 适合数据分析和聚合
- 内置TTL
- 类型系统
- 高基数没有问题
必须承认，数据库的数量超过了人类，基准测试更是数不胜数，结论也各不相同。
经过研究，我们决定测试**InfluxDB**、**TimescaleDB**、**Druid**和**ClickHouse**。
我们创建了一个包含2000万行的数据集，其中一个用户拥有其中的一半。为了衡量性能，我们尝试计算一些高百分位数，并查看一个大型用户是否会影响其他小型用户的查询性能。
Elasticsearch的基线是10秒。
我们对**InfluxDB**寄予厚望，它看起来像是一个极快的时序数据库。不幸的是，它不支持高基数。GraphQL Hive中收集的每个HTTP请求都可以使用所有用户之间无限数量的值进行标记。
我们也发现很难上手。
查询时间约为5秒。
接下来是**TimescaleDB**。我们喜欢它使用SQL并且支持表之间关系的事实。整体性能比我们在Elasticsearch中体验到的要好得多。
响应时间接近3秒。
在我们进行研究时（2021年4月），**ClickHouse**对我们来说感觉非常神秘。我们没有听说过太多关于它的信息，并且只找到了一些案例研究。它似乎与TimescaleDB非常相似，但提供了更广泛的数据分析功能集，并且表引擎的集合非常适合我们的用例。
查询时间为……约100毫秒。
我们没有测试Druid，它感觉太复杂了。尽管它可能能够处理海量数据，但我们希望找到一些简单而强大的东西，而ClickHouse似乎非常合适。
从Elasticsearch迁移
从Elasticsearch到ClickHouse的迁移是逐步进行的，并不复杂。
在预览程序期间，收集数据的生存时间仅为30天。
因此，我们决定同时将数据写入两个目标，持续一个月。这使我们能够在不中断服务的情况下将读取操作无缝切换到ClickHouse。
GraphQL Hive和ClickHouse
切换后，与之前的数据管道相比，我们平均看到了100倍的性能提升。
ClickHouse帮助我们将数据量从每月数百万行扩展到数十亿行，且毫无压力。
如果您对我们的数据库结构以及我们如何使用ClickHouse感到好奇，我们建议您查看GitHub上的源代码。
我们还撰写了一篇更深入的文章，解释了我们的ClickHouse设置以及我们如何能够每月处理数十亿个GraphQL请求。
使用ClickHouse Cloud提升到新的水平
我们当前的数据管道使用ClickHouse的单个实例。它运行良好，到目前为止，我们还没有遇到任何问题，但最终需要将其扩展到更多节点。
这就是我们开始迁移到**ClickHouse Cloud**的原因。
由于其开箱即用的分片和复制支持，我们可以专注于开发新功能，并让ClickHouse Cloud处理其余工作。
