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

你可能感兴趣的:(DB,数据库)