ClickHouse 笔记
-
clickHouse 不使用任何的缓存,而是有一套并行 io 体系
-
clickHouse 没有 Optimise ,只是简单的并行 io 查询,每个查询都去读取磁盘
-
clickHouse 对事务的支持?后面会讲
-
clickHouse 这么快的原因:
-
简单的库,只使用了 C++ ,架构足够简单
-
支持 SQL
-
架构上,没有任何 Shared (去中心化),利于水平扩展
-
列存储 + 并行的垂直查询
-
内置 分片 和 副本集 策略
-
-
源码写的很整洁
-
clickHouse 很快
-
每个功能点本身很快,接口是依据 算法 来定的
-
lz4
-
排序算法
-
根据数据大小来决定是否应该放在内存
-
各种优化算法
-
-
MergeTree 引擎
-
Table 能指定:
-
存储引擎:栗如 MergeTree
-
指定分片策略:PARTITION BY toYYYYMM(FlightDate)
-
指定每个分片的排序 + 索引策略: ORDER BY (Carrier, FlightDate)
-
-
Table 被拆分为一个一个的 Part ,每个 Part 包含
-
Index
-
2017-01-01 | AA (小颗粒:Granule)
-
2018-01-01 | UA
-
-
Columns:根据 ORDER BY 排序
-
列1
-
xx.mrk
- bin 的索引
-
xx.bin
- 压缩后的数据
-
-
列2
- xxxx
-
-
-
cliekHouse 会在后台做 原子的 Merge ??? Compression ???
-
物化视图在 clickhouse 种非常高效,得益于 clickhouse 的 merge 机制
集群方案
-
umbrella 和 ReplicatedMergeTree 存储引擎,用于集群
-
原生的 Replication 方案,信息存在 ZooKeeper 上
-
像副本leader的选举
-
副本表写入的同步
-
整个集群、表的meta信息
-
-
分布式查询的工作方式
-
查询访问到某一个 node1
-
node1 将 任务分发到 node1.2 和 node1.3
-
node1.2 悄悄的将任务分发给 node1.4
-
node1.4 默默的合并 node1.2 和 node1.4 的查询结果
-
-
node1 合并 node1.2 和 node1.3 的查询结果
-
-
如果存在 join 查询
-
最左边的查询,将下发给底层
-
会创建临时表
-
之类的,没咋看懂
-
-
多个 shard 能显著提升查询性能