摘自：https://dusen.me/greenplum-vs-clickhouse-1100million-data/
导言
公司的一个报表业务，数据量比较大，用户使用频繁。为了更好的用户体验，我们之前尝试过多种技术：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 生成图表