导言
公司的一个报表业务，数据量比较大，用户使用频繁。为了更好的用户体验，我们之前尝试过多种技术：MongoDB、ElasticSearch、Greenplum 等，但是一直没办法做到大部分查询秒级响应。
前段时间探索了很多大数据产品，无意中发现 ClickHouse，很快就被其极致的性能所吸引。在一番实验和研究后，我们决定用 ClickHouse 解决这个历史债务。花了一个月的时间，用 ClickHouse 重写了之前的业务逻辑，经过详细的验证，功能和之前保持一摸一样。性能是一个很好的衡量指标，于是这两天我做了这个性能对比测试。
结论
- 相同业务场景下，ClickHouse 只用了 Greenplum 一半的机器资源，但是比 Greenplum 快 10倍+
- ClickHouse 很少会把机器 CPU 全部用满；Greenplum 基本上会把机器 CPU 全占满
- ClickHouse 和 Greenplum 内存使用量都很少，只用到了20多GB
- 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并发
