Greenplum VS ClickHouse (单表11亿数据)

标签: | 发表时间:2021-08-25 11:37 | 作者:
出处:https://dusen.me

导言

公司的一个报表业务,数据量比较大,用户使用频繁。为了更好的用户体验,我们之前尝试过多种技术: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并发

相关 [greenplum vs clickhouse] 推荐:

Greenplum VS ClickHouse (单表11亿数据)

- -
公司的一个报表业务,数据量比较大,用户使用频繁. 为了更好的用户体验,我们之前尝试过多种技术:MongoDB、ElasticSearch、Greenplum 等,但是一直没办法做到大部分查询秒级响应. 前段时间探索了很多大数据产品,无意中发现 ClickHouse,很快就被其极致的性能所吸引. 在一番实验和研究后,我们决定用 ClickHouse 解决这个历史债务.

开源OLAP引擎哪个快? (Presto、HAWQ、ClickHouse、GreenPlum) - 知乎

- -
现在大数据组件非常多,众说不一,在每个企业不同的使用场景里究竟应该使用哪个引擎呢. 这是易观Spark实战营出品的开源Olap引擎测评报告,团队选取了Hive、Sparksql、Presto、Impala、Hawq、Clickhouse、Greenplum大数据查询引擎,在原生推荐配置情况下,在不同场景下做一次横向对比,供大家参考.

ClickHouse Better Practices

- - 简书首页
经过一个月的调研和快速试错,我们的ClickHouse集群已经正式投入生产环境,在此过程中总结出了部分有用的经验,现记录如下. 看官可去粗取精,按照自己项目中的实际情况采纳之. (版本为19.16.14.65). 因为我们引入ClickHouse的时间并不算长,还有很多要探索的,因此不敢妄称“最佳实践”,还是叫做“更佳实践”比较好吧.

聊聊Greenplum发展过程

- -
笔者有幸从04年就开始从事大规模数据计算的相关工作,08年作为Greenplum 早期员工加入Greenplum团队(当时的工牌是“005”,哈哈),记得当时看了一眼Greenplum的 架构(嗯,就是现在大家耳熟能详的那个好多个X86框框的图),就义无反顾地加入了,转眼之间,已经到了第8个年头.

GIF vs APNG vs WebP

- - JayXon
GIF 是一个非常古老的格式,1987 年诞生,最后一个版本是 1989 年. (这就是为什么 GIF 文件头的 magic number 是 GIF89a). APNG 相对新一些,是 Mozilla 在 2004 年推出的,十几年的科技进步是不容小觑的,所以 APNG相对于 GIF 的优势十分明显,后面会分析.

大规模并行处理系统 Greenplum

- Le - 开源中国社区最新软件
Greenplum是一家总部位于美国加利福尼亚州,为全球大型企业用户提供新型企业级数据仓库(EDW)、企业级数据云(EDC)和商务智能(BI)提供解决方案和咨询服务的公司. Greenplum的架构采用了MPP(大规模并行处理). 在 MPP 系统中,每个 SMP 节点也可以运行自己的操作系统、数据库等.

blong/clickhouse .md at master · xingxing9688/blong · GitHub

- -
https://clickhouse.yandex/tutorial.html快速搭建集群参考. https://clickhouse.yandex/reference_en.html官网文档. https://habrahabr.ru/company/smi2/blog/317682/关于集群配置参考.

转 redis vs memcached

- - 数据库 - ITeye博客
传统MySQL+ Memcached架构遇到的问题.   实际MySQL是适合进行海量数据存储的,通过Memcached将热点数据加载到cache,加速访问,很多公司都曾经使用过这样的架构,但随着业务数据量的不断增加,和访问量的持续增长,我们遇到了很多问题:.   1.MySQL需要不断进行拆库拆表,Memcached也需不断跟着扩容,扩容和维护工作占据大量开发时间.

开源OLAP引擎综评:HAWQ、Presto、ClickHouse

- - InfoQ推荐
谈到大数据就会联想到Hadoop、Spark整个生态的技术栈. 大家都知道开源大数据组件种类众多,其中开源OLAP引擎包含Hive、SparkSQL、Presto、HAWQ、ClickHouse、Impala、Kylin等. 当前企业对大数据的研究与应用日趋理性,那么,如何根据业务特点,选择一个适合自身场景的查询引擎呢.

ClickHouse 权限控制与资源隔离

- - IT瘾-dev
使用clickhouse多半应用在实时数仓项目来支持adhoc查询,为了确保企业数据安全高效的使用,那么权限控制与资源隔离是必不可少的. clickhouse在20.4之后的版本开始支持基于RBAC的访问控制管理;主要包括的功能有:用户创建、角色创建、权限管理以及资源隔离;接下来我们将演示如何使用这些功能.