Greenplum VS ClickHouse (单表11亿数据)

导言

公司的一个报表业务，数据量比较大，用户使用频繁。为了更好的用户体验，我们之前尝试过多种技术：MongoDB、ElasticSearch、Greenplum 等，但是一直没办法做到大部分查询秒级响应。

前段时间探索了很多大数据产品，无意中发现 ClickHouse，很快就被其极致的性能所吸引。在一番实验和研究后，我们决定用 ClickHouse 解决这个历史债务。花了一个月的时间，用 ClickHouse 重写了之前的业务逻辑，经过详细的验证，功能和之前保持一摸一样。性能是一个很好的衡量指标，于是这两天我做了这个性能对比测试。

结论

1. 相同业务场景下，ClickHouse 只用了 Greenplum 一半的机器资源，但是比 Greenplum 快 10倍+
2. ClickHouse 很少会把机器 CPU 全部用满；Greenplum 基本上会把机器 CPU 全占满
3. ClickHouse 和 Greenplum 内存使用量都很少，只用到了20多GB
4. 30并发之后，Greenplum 开始偶尔无法响应，并抛出异常；ClickHouse 到100并发还完好，只是会稍微慢一点

测试准备

1. 数据集

• 数据总量： 380 GB
• 1个事实表： 11 亿数据（26列）
• 2个纬度表：
  • 纬度表B：8000 数据（45列）
  • 纬度表C：1000 数据（52列）
• 为了充分发挥数据库的特性，数据模型在不同的数据库上会有不同的设计，业务逻辑不变
  • ClickHouse 擅长单表查询，于是我会在原始表的基础上，创建一个新表(宽表)基于 MergeTree引擎，通过 materialized view 实时同步数据到新表
  • Greenplum 用分区策略加速查询

2. 机器配置

• Greenplum
  • 主节点：16C、64G、2.5TB HDD
  • 副节点：16C、64G、1.5GB HDD
• ClickHouse
  • 主节点：16C、64G、2.5TB HDD

3. 查询条件

• Q1:动态时间区间 < 30 天；动态店铺ID；动态Limit Offset；
• Q2:动态时间区间 < 30 天；动态店铺ID；更多动态Where条件；动态Limit Offset；
• Q3:动态时间区间 > 30 天、< 180天；动态店铺ID；动态Limit Offset；
• Q4:动态时间区间 > 30 天、< 180天；动态店铺ID；更多动态Where条件；动态Limit Offset；
• Q5:动态时间区间 < 30 天；标签汇总；动态店铺ID；动态Limit Offset；
• Q6:动态时间区间 < 30 天；标签汇总；动态店铺ID；更多动态Where条件；动态Limit Offset；
• Q7:动态时间区间 > 30 天、< 180天；标签汇总；动态店铺ID；动态Limit Offset；
• Q8:动态时间区间 > 30 天、< 180天；标签汇总；动态店铺ID；更多动态Where条件；动态Limit Offset；

4. 压测步骤

• 使用 Golang 语言开发程序，生成查询SQL、请求数据库、提供统一的 API 接口
• 使用 Jmeter 调用Golang 提供的 Rest API 接口
• 压测前，使用 Jmeter 单线程模式，循环调用 10次 x 4组查询API ， 预热系统
• 压测中，使用 Jmeter 1并发、10并发、30并发、50并发、100并发模式测试，每种并发，循环 3 次
• 压测后，收集 监控到的请求响应数据
  • 平均响应时间
  • 95% Line

5. 结果可视化

• 使用 Python + plotly + pandas 生成图表

压测结果

1并发

10并发

30并发

50并发

100并发