---

前言

ClickHouse 是俄罗斯的 Yandex 于 2016 年开源的列式存储数据库（DBMS），使用 C++
语言编写，主要用于在线分析处理查询（OLAP）（对数据删除和更新不友好），能够使用 SQL 查询实时生成分析数据报
告。
官网地址

---

一、行式存储

	行式存储	列式存储
写入	每一行的所有字段都存在一起，优点：对数据进行插入和修改操作很方便	当一条新数据到来，每一列单独存储，缺点：插入和修改操作麻烦
查询	查询时即使只涉及某几列，所有数据也都会被读取；优点：适合随机查询；在整行的读取上，要优于列式存储；缺点：行式存储不适合扫描，这意味着要查询一个范围的数据	查询时只有涉及到的列会被读取；缺点：查询完成时，被查询的列要重新进行组装
寻道范围	读取数据的时候硬盘寻址范围很大	由于仅对需要的列进行查找，因此硬盘寻道范围小
索引	缺点：要加速查询的话需要建立索引，建立索引需要花费很多时间。	优点：任何列都能作为索引（每一列单独存储，查询个别列的时候，可以仅读取需要的那几个列，相当于为每一列都建立了索引）
压缩	缺点：不利于压缩	把一列数据保存在一起，而一列的数据类型相同 ；优点：利于压缩
空间	按行存储，不利于压缩，压缩比较差，占空间大	列式存储的时候可以为每一列创建一个字典，存储的时候就仅存储数字编码即可，降低了存储空间需求
聚合	不利于聚合操作	按列存储，利于数据聚合操作
应用	MySQL中的iInnoDB和MyISAM存储引擎是行式存储	MySQL中的infobright存储引擎是列式存储
适用场景	OLTP（存储关系型数据，用于使用数据的时候需要经常用到数据之间的依赖关系的场景，即读取的时候需要整行数据或者整行中大部分列的数据，需要经常用到插入、修改操作）	OLAP（分布式数据库和数据仓库，适合于对大量数据进行统计分析，列与列之间关联性不强，仅进行插入和读取操作的场景）

• 列式存储好处：
  • 对于列的聚合，计数，求和等统计操作原因优于行式存储。
  • 由于某一列的数据类型都是相同的，针对于数据存储更容易进行数据压缩，每一列选择更优的数据压缩算法，大大提高了数据的压缩比重。
  • 由于数据压缩比更好，一方面节省了磁盘空间，另一方面对于 cache 也有了更大的发挥空间。

二、DBMS功能

• 几乎覆盖了标准 SQL 的大部分语法，包括 DDL 和 DML，以及配套的各种函数，用户管理及权限管理，数据的备份与恢复。

三、多样化引擎

• ClickHouse 和 MySQL 类似，把表级的存储引擎插件化，根据表的不同需求可以设定不同的存储引擎。目前包括合并树、日志、接口和其他四大类 20 多种引擎。

四、高吞吐写入能力

• ClickHouse 采用类 LSM Tree的结构，数据写入后定期在后台 Compaction。通过类 LSM tree的结构，ClickHouse 在数据导入时全部是顺序 append 写，写入后数据段不可更改，在后台compaction 时也是多个段 merge sort 后顺序写回磁盘。顺序写的特性，充分利用了磁盘的吞吐能力，即便在 HDD 上也有着优异的写入性能。
• 官方公开 benchmark 测试显示能够达到 50MB-200MB/s 的写入吞吐能力，按照每行100Byte 估算，大约相当于 50W-200W 条/s 的写入速度。

五、数据分区与线程级并行

• 分区的作用：避免全表扫描
• ClickHouse 将数据划分为多个 partition，每个 partition 再进一步划分为多个 index
  granularity(索引粒度)，然后通过多个 CPU核心分别处理其中的一部分来实现并行数据处理。
  在这种设计下，单条 Query 就能利用整机所有 CPU。极致的并行处理能力，极大的降低了查
  询延时。
  • ClickHouse 即使对于大量数据的查询也能够化整为零平行处理。但是有一个弊端
    就是对于单条查询使用多 cpu，就不利于同时并发多条查询。所以对于高 qps 的查询业务， ClickHouse 并不是强项。

六、场景

• 适用场景：
  • 1.大宽表：ClickHouse不适合初始表的存储，适合处理过大量数据的宽表存储
  • 2.单表查询性能极优
• 不适用场景：
  • 1.join的效率不高，需要优化语句达到最佳性能。
    • 因为A join B的时候，B表会被加载到内存，再一条条去匹配A表的数据。如果是分布式的，那么效率就更低了。
  • 2.高QPS的场景。

七、特定版本

• 20.5的版本：final支持多线程
• 20.6.3的版本：支持explain
• 20.8的版本：增加了引擎，支持实时同步MySQL信息