Clickhouse简介

一、Clickhouse定义

Clickhouse是一个列式数据库，通常适合OLAP场景

二、适合Clickhouse的场景或一般的OLAP场景

• 绝大多数的请求都是读请求；

• 数据更新适合大批量，比如一次更新1000条以上，或者不更新，不适合一次更新1条记录；

• 对于读取，会从数据库中获取相当多的行，但只有每行的一小部分列。

• clickhouse适合大宽表，但是每次查询只查询几列；

• 每列的值相对较小，通常为int或较短的字符串（60个bytes以内比较合适）

• 每个查询最多只有一张大表或全部是小表

• 查询结果明显小于源数据。换句话说，数据被过滤或聚合，因此每个查询获取的结果通常当个服务器的内存就可以承受。

• 查询并发通常不太多（通常单台server控制在每秒并发100以内）

• 对于简单查询，延迟大约在50毫秒左右。

• 处理单个查询时需要高吞吐量（每台服务器每秒高达数十亿行），需要对大量数据进行处理。

• 不需要事物

• 数据一致性需求较低

三、列式数据库为什么比行存储数据库做OLAP场景查询更快

3.1 input/output

• 对于面向列式存储的数据库，每次只需要读取需要列的数据，如对于100列中只需要查询5列，则至少有20倍I/O的减少；
• 相同数据的格式更容易压缩，进一步减少I/O；
• 由于减少了数据和I/O，系统也可以缓存更多的数据；

使用快速压缩算法每秒单机可以至少解压数GB的未压缩数据，也就是说每秒单机可以处理数十亿行数据的查询。

3.2 cpu

向量化处理

四、Clickhouse的特性

4.1 真正的列式数据库管理系统

• 每列数据之间不存储其他数据比如数据长度，没有任何垃圾，只存储真正的值
• 不仅仅是一个database，还是一个数据库管理系统，可以在线创建表、加载数据、查询等

4.2 数据压缩

• 一些列式数据库并没有启用压缩，但是压缩在数据性能方面起到非常重要的作用

4.3 硬盘存储数据

• 数据根据主键物理排序存储，这使得查询一定范围的数据只需要很少的时间。一些列式数据库只能支持在内存中工作，这将加大预算。Clickhouse面向普通硬盘设计，这样每GB数据成本将更少。

4.4 单机上多核并行计算

大型查询以自然的方式并行化，占用当前服务器上可用的所有必要资源。

4.5 多服务器并行计算

在ClickHouse中，数据可以驻留在不同的shards上。每个shards可以是一组用于容错的副本。查询在所有shards上并行处理。这对用户是透明的。

4.6 多服务器并行计算

支持标准的SQL查询，包括子查询、group by 、order by等，不支持依赖子查询和窗口函数。

4.7 向量引擎

数据不仅由列存储，而且由向量（列的一部分）处理。这使我们能够实现高CPU效率。

4.8 向量引擎

ClickHouse支持带有主键的表。为了快速对主键的范围执行查询，使用合并树对数据进行增量排序。因此，数据可以不断地添加到表中。当接收到新数据时，不会执行任何锁定。

4.9 实时数据更新

ClickHouse支持带有主键的表。为了快速对主键的范围执行查询，使用合并树对数据进行增量排序。因此，数据可以不断地添加到表中。当接收到新数据时，不会执行任何锁定。

4.10 索引

通过按主键对数据进行物理排序，可以在不到几十毫秒的时间内提取特定值或值范围的数据。

4.11 适合低延迟查询

低延迟意味着在加载用户界面页面的同时，可以毫不延迟地处理查询，而无需提前准备答案。换句话说，在线。

4.12 支持近似计算

• 如Hyper Log近似算法
• 针对样例数据sample抽样计算等

4.13 数据副本和完整性

使用异步多主机复制。在写入任何可用的副本后，数据将分发到后台的所有剩余副本。系统在不同的副本上维护相同的数据。大多数故障后的恢复是自动执行的，在复杂情况下是半自动的。
clickhouse replication