Clickhouse 是一个 用于联机分析(OLAP)的 列式存储数据库管理系统(DBMS).
常见的列式数据库有: Vertica、 Paraccel (Actian Matrix，Amazon Redshift)、 Sybase IQ、 Exasol、 Infobright、 InfiniDB、 MonetDB (VectorWise， Actian Vector)、 LucidDB、 SAP HANA、 Google Dremel、 Google PowerDrill、 Druid、 kdb+.
OLAP 场景的关键特征
- 绝大多数是读请求
- 数据以相当大的批次(> 1000行)更新，而不是单行更新;或者根本没有更新。
- 已添加到数据库的数据不能修改。
- 对于读取，从数据库中提取相当多的行，但只提取列的一小部分。
- 宽表，即每个表包含着大量的列
- 查询相对较少(通常每台服务器每秒查询数百次或更少)
- 对于简单查询，允许延迟大约50毫秒
- 列中的数据相对较小：数字和短字符串(例如，每个URL 60个字节)
- 处理单个查询时需要高吞吐量(每台服务器每秒可达数十亿行)
- 事务不是必须的
- 对数据一致性要求低
- 每个查询有一个大表。除了他以外，其他的都很小。
- 查询结果明显小于源数据。换句话说，数据经过过滤或聚合，因此结果适合于单个服务器的RAM中
列式数据库更适合OLAP场景的原因
列式数据库更适合于OLAP场景(对于大多数查询而言，处理速度至少提高了100倍).
为什么会出现这种情况?
1. IO
- 针对分析类查询, 通常只需要读取表的一小部分列.在列式数据库中你可以只读取你需要的数据.例如，如果只需要读取100列中的5列，这将帮助你最少减少20倍的I/O消耗.
- 由于数据总是打包成批量读取的，所以压缩是非常容易的.同时数据按列分别存储这也更容易压缩.这进一步降低了I/O的体积.
- 由于I/O的降低,这将帮助更多的数据被系统缓存.
- 例如: 查询
统计每个广告平台的记录数量需要读取广告平台ID这一列,它在未压缩的情况下需要1个字节进行存储.如果大部分流量不是来自广告平台，那么这一列至少可以以十倍的压缩率被压缩.当采用快速压缩算法,它的解压速度最少在十亿字节(未压缩数据)每秒.换句话说,这个查询可以在单个服务器上以每秒大约几十亿行的速度进行处理.这实际上是当前实现的速度。
2. CPU
由于执行一个查询需要处理大量的行,因此在整个向量上执行所有操作将比在每一行上执行所有操作更加高效.
同时这将有助于实现一个几乎没有调用成本的查询引擎.如果你不这样做,使用任何一个机械硬盘.查询引擎都不可避免的停止CPU进行等待.
所以,在数据按列存储并且按列执行是很有意义的.
有两种方法可以做到这一点:
向量引擎: 所有的操作都是为向量而不是为单个值编写的.这意味着多个操作之间的不再需要频繁的调用,并且调用的成本基本可以忽略不计.操作代码包含一个优化的内部循环.
代码生成: 生成一段代码,包含查询中的所有操作.
[参考]
什么是clickhouse