clickhouse适用场景,ck应用场景有哪些?

1、什么情况下适合使用clickhouse

  • 数据量超过亿级
  • 最好存储的是“事实数据”,也就是说数据只增,不改(包括删除)。最常见的比如:监控日志、用户行为收集等等
  • 如果数据是需要删改,也能使用版本折叠树引擎(VersionedCollapsingMergeTree)来解决。但是查询上就会有诸多限制。
  • 最好是单表查询就能解决问题,因此对表的设计有所要求。可以支持宽表(多个字段)。
  • 如果需要关联查询,不超过2个表。
  • ck擅长单个字段的聚合查询(比如,求和、求平均值)

2、不同MergeTree表引擎的适用场景

2.1 MergeTree

  • 适合事实数据
  • 满足多个维度,各种方式的查询。
  • 当数据量过多(单分片,单表)超过十亿时,速度会变慢。此时考虑使用其他引擎。

2.2 ReplacingMergeTree

  • 继承MergeTree的场景
  • 会自动按照主键去重,以节省磁盘空间。但是去重的时机不确定,因此我们不能依赖该引擎的去重特性。该引擎的为了是节省空间,去重只是手段,不是目的。

2.3 SummingMergeTree和AggregatingMergeTree

  • 当MergeTree的数据太多(几十亿)时,一些聚合统计速度会变慢,此时使用SummingMergeTree和AggregatingMergeTree就会自动帮你合并固化数据。能极大的提高聚合速度。
  • AggregatingMergeTree比SummingMergeTree支持更多的聚合函数。

2.4 CollapsingMergeTree和VersionedCollapsingMergeTree

  • 当存量数据可能会变动时,使用这这两个引擎。sync2any中mysql同步到clickhouse就是使用这两个引擎实现的。
  • 缺点是,这两个引擎无法再配合物化视图进一步加速查询。因为使用物化视图之后,就无法保证修改数据之后的准确性了。

3、数据实测

配置:4c\16G

3.1 单表查询

  • 数据量:1500万条记录。

  • 表引擎:ReplicatedCollapsingMergeTree

  • 执行时间:345ms

1
2
3
4
5
6
7
8
select member_code, sum(_sign) as c
from A
where group_code = '66666'
group by member_code
having c > 10
and c < 20
order by c desc
limit 20;

3.2 多表关联

  • 数据量:A:1500万条记录,B:5000万条记录

  • 表引擎:ReplicatedCollapsingMergeTree

  • 执行时间:400ms

1
2
3
4
5
6
7
8
9
10
11
select j.member_code ,sum(ncount) as ncount
from B l final
global inner join (select group_code, order_code, member_code
from A final
prewhere order_code is not null
and group_code = '666666' group by group_code,member_code,order_code having sum(_sign)> 0 ) as j on j.order_code = l.order_code
where l.group_code = '666666'
and j.group_code = '666666'
group by j.member_code
order by sum_night_count desc
limit 10;