designs\project\database-CH

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 能显著提升查询性能