Clickhouse简介和性能对比
Clickhouse简介和性能对比
ClickHouse是一个用于联机分析(OLAP)的列式数据库管理系统(DBMS)。
常见的列式数据库有： Vertica、 Paraccel (Actian Matrix，Amazon Redshift)、 Sybase IQ、 Exasol、 Infobright、 InfiniDB、 MonetDB (VectorWise， Actian Vector)、 LucidDB、 SAP HANA、 Google Dremel、 Google PowerDrill、 Druid、 kdb+。
不同的存储方式适合不同的场景，这里的查询场景包括：
- 进行了哪些查询
- 多久查询一次
- 各类查询的比例
- 每种查询读取多少数据————行、列和字节
- 读取数据和写入数据之间的关系
- 使用的数据集大小以及如何使用本地的数据集
- 是否使用事务,以及它们是如何进行隔离的
- 数据的复制机制与数据的完整性要求
- 每种类型的查询要求的延迟与吞吐量
系统负载越高，根据使用场景进行定制化就越重要，并且定制将会变的越精细。没有一个系统同样适用于明显不同的场景。如果系统适用于广泛的场景，在负载高的情况下，所有的场景可以会被公平但低效处理，或者高效处理一小部分场景。
OLAP场景的关键特征
- 大多数是读请求
- 数据总是以相当大的批(> 1000 rows)进行写入
- 不修改已添加的数据
- 每次查询都从数据库中读取大量的行，但是同时又仅需要少量的列
- 宽表，即每个表包含着大量的列
- 较少的查询(通常每台服务器每秒数百个查询或更少)
- 对于简单查询，允许延迟大约50毫秒
- 列中的数据相对较小： 数字和短字符串(例如，每个URL 60个字节)
- 处理单个查询时需要高吞吐量（每个服务器每秒高达数十亿行）
- 事务不是必须的
- 对数据一致性要求低
- 每一个查询除了一个大表外都很小
- 查询结果明显小于源数据，换句话说，数据被过滤或聚合后能够被盛放在单台服务器的内存中
Clickhouse优缺点
优点
- 数据压缩
- 多核并行处理
- 支持数据复制和数据完整性
- shard分片
- replica副本
- 多服务器分布式处理。其他列式数据库管理系统中，几乎没有一个支持分布式的查询处理
- 支持sql
- 大部分情况下是与SQL标准兼容的。 支持的查询包括 GROUP BY，ORDER BY，IN，JOIN以及非相关子查询。 不支持窗口函数和相关子查询。
- 向量引擎
- 实时数据插入
- 稀疏索引
- 适合在线查询
缺点
- 没有完整的事务支持。
- 缺少高频率，低延迟的修改或删除已存在数据的能力。仅能用于批量删除或修改数据，但这符合 GDPR。
- 稀疏索引使得ClickHouse不适合通过其键检索单行的点查询。
性能对比
官方的性能测试对比报告参见：https://clickhouse.yandex/benchmark.html
知乎上的一篇OLAP引擎比较：https://zhuanlan.zhihu.com/p/54907288
在一张有44个字段的大表中做单表查询并且和Amazon RedShift做对比，结果如下：
Clickhouse 测试环境：单CPU 2核 4G内存
cat /proc/cpuinfo| grep "physical id"| sort| uniq| wc -l # # 查看物理CPU个数
cat /proc/cpuinfo| grep "cpu cores"| uniq # 查看每个物理CPU中core的个数(即核数)数据量：1580万
clickhouse engine和index：
ENGINE = ReplacingMergeTree(insert_time)
order by (membership_uid, business_group_uid, calendar_date, insert_time);Sql执行速度取决于：执行时间execution和数据拉取时间fetching
Clickhouse:
select * from dm.delphi_membership_properties t where t.membership_id=666; -- 160ms
select * from dm.delphi_membership_properties t where t.membership_uid='3ec723abeffc470ea42593f0d1e9d279'; -- 120ms
select count(*) from dm.delphi_membership_properties t where t.business_group_id=44; -- 120ms
select account_phone from dm.delphi_membership_properties t where t.membership_id=666; -- 58ms
select account_phone from dm.delphi_membership_properties t where t.membership_uid='3ec723abeffc470ea42593f0d1e9d279'; -- 44 ms
select account_phone from dm.delphi_membership_properties t where t.business_group_id=44; -- 190msRedShift: 机器配置高于clickhouse单机数倍
select * from dm.delphi_membership_properties t where t.business_group_id=44; -- 1286条数据一次取出来时间较长
select * from dm.delphi_membership_properties t where t.business_group_uid='7a68b4a7350c4d7288e8befef91f8581'; -- 1286条数据一次取出来时间较长
select count(*) from dm.delphi_membership_properties t where t.business_group_uid='fa26f456030940b8b6ec4b56e256aee2'; -- 250ms
select account_phone from dm.delphi_membership_properties t where t.business_group_uid='7a68b4a7350c4d7288e8befef91f8581'; -- 360ms
select count(distinct t.membership_uid) from dm.delphi_membership_properties t where t.business_group_uid='fa26f456030940b8b6ec4b56e256aee2'; -- 450ms将clickhouse 表engine的order by key修改如下：颗粒度小的在后
ENGINE = ReplacingMergeTree(insert_time)
order by (business_group_uid, calendar_date, created_at, insert_time, membership_uid);修改order by key之后含有bguid的查询速度大幅提升，均低于60ms。这个速度提升主要是clickhouse的稀疏索引导致的，关于索引会在其他文章中介绍到。