什么是ClickHouse?

ClickHouse 是面向 OLAP 的分布式列式 DBMS.

在“正常”的面向行的DBMS中，数据按顺序进行存储：

5123456789123456789    1      Eurobasket - Greece - Bosnia and Herzegovina - example.com      1      2011-09-01 01:03:02    6274717  1294101174      11409  612345678912345678      0      33      6      http://www.example.com/basketball/team/123/match/456789.html http://www.example.com/basketball/team/123/match/987654.html      0      1366    768    32      10      3183      0      0      13      0\0    1      1      0      0                      2011142 -1      0              0      01321    613    660    2011-09-01 08:01:17    0      0      0      0      utf-8  1466    0      0      0      5678901234567890123              277789954      0      0      0      0      0

5234985259563631958    0      Consulting, Tax assessment, Accounting, Law      1      2011-09-01 01:03:02    6320881  2111222333      213    6458937489576391093    0      3      2      http://www.example.ru/        0      800    600      16      10      2      153.1  0      0      10      63      1      1      0      0                      2111678 000      0      588    368    240    2011-09-01 01:03:17    4      0      60310  0      windows-1251    1466    0      000              778899001      0      0      0      0      0

...

换句话说，与一行相关的所有值都被存储在一起。面向行的DBMS主要有MySQL，Postgres，MS SQL Server等等。

在面向列的DBMS中，数据存储如下：

WatchID:5385521489354350662    5385521490329509958    5385521489953706054    5385521490476781638    5385521490583269446    5385521490218868806    5385521491437850694  5385521491090174022      5385521490792669254    5385521490420695110    5385521491532181574    5385521491559694406    5385521491459625030    5385521492275175494  5385521492781318214      5385521492710027334    5385521492955615302    5385521493708759110    5385521494506434630    5385521493104611398

JavaEnable:1      0      1      0      0      0      1      0      1      1      1      1      1      1      0      1      0      0      1      1

Title:Yandex  Announcements - Investor Relations - Yandex    Yandex — Contact us — Moscow    Yandex — Mission        Ru      Yandex — History — History of Yandex    Yandex Financial Releases - Investor Relations - Yandex Yandex — Locations      Yandex Board of Directors - Corporate Governance - Yandex      Yandex — Technologies

GoodEvent:1      1      1      1      1      1      1      1      1      1      1      1      1      1      1      1      1      1      1      1

EventTime:2016-05-18 05:19:20    2016-05-18 08:10:20    2016-05-18 07:38:00    2016-05-18 01:13:08    2016-05-18 00:04:06    2016-05-18 04:21:30    2016-05-18 00:34:16    2016-05-18 07:35:49    2016-05-18 11:41:59    2016-05-18 01:13:32...

这些示例仅显示数据排列的顺序。不同列的值分开存储，同一列的数据一起存储。例如，面向列的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 ms的延迟。

- 列值相当小 - 数字和短字符串（例如，每个URL 60个字节）。

- 处理单个查询时需要高吞吐量（每台服务器每秒高达数十亿行）。

- 无事务处理。

- 数据一致性要求低- 每个查询有一个大表，其他所有的表都是小表。

- 查询结果显著小于源数据。也就是说，数据被过滤或聚合。结果可以放在单个服务器的内存中。

很容易看出，OLAP方案与其他常见方案（如OLTP或Key-Value访问）有很大不同。所以，如果你想获得不错的表现，尝试使用OLTP或Key-Value DB来处理分析查询是没有意义的。例如，如果您尝试使用MongoDB或Elliptics进行分析，与OLAP数据库相比，您的性能会很差。

面向列的数据库更适合于OLAP方案（对于大多数查询，处理速度至少提高了100倍），原因如下：

1.对于I/O

1.1 对于分析查询，只需要读取少量的列。在面向列的数据库中，您只能读取所需的数据。例如，如果您需要100列中的5列，则I/O可能会减少20倍。

1.2 由于数据是以数据包的形式读取的，因此压缩比较容易。列中的数据也更容易压缩。这进一步减少了I/O量。

1.3 由于减少的I/O，更多的数据适合在系统缓存中。

例如，查询“统计每个广告平台的记录数量”需要读取一个“广告平台ID”列，其占用1个未压缩字节。如果大多数流量不是来自广告平台，那么您可以期望至少有10倍的压缩比。当使用快速压缩算法时，数据解压缩速度可以达到每秒至少几千兆字节的未压缩数据。换句话说，这个查询可以在一台服务器上以每秒大约几十亿行的速度处理。这个速度实际上是在实践中是容易实现的。

milovidov@████████.yandex.ru:~$ clickhouse-client

ClickHouse client version 0.0.52053.

Connecting to localhost:9000.

Connected to ClickHouse server version 0.0.52053.

:) SELECT CounterID, count() FROM hits GROUP BY CounterID ORDER BY count() DESC LIMIT 20

SELECT

CounterID,

count()

FROM hits

GROUP BY CounterID

ORDER BY count() DESC

LIMIT 20

┌─CounterID─┬──count()─┐

│    114208 │ 56057344 │

│    115080 │ 51619590 │

│      3228 │ 44658301 │

│    38230 │ 42045932 │

│    145263 │ 42042158 │

│    91244 │ 38297270 │

│    154139 │ 26647572 │

│    150748 │ 24112755 │

│    242232 │ 21302571 │

│    338158 │ 13507087 │

│    62180 │ 12229491 │

│    82264 │ 12187441 │

│    232261 │ 12148031 │

│    146272 │ 11438516 │

│    168777 │ 11403636 │

│  4120072 │ 11227824 │

│  10938808 │ 10519739 │

│    74088 │  9047015 │

│    115079 │  8837972 │

│    337234 │  8205961 │

└───────────┴──────────┘

20 rows in set. Elapsed: 0.153 sec. Processed 1.00 billion rows, 4.00 GB (6.53 billion rows/s., 26.10 GB/s.)

:)

2.对于CPU

由于执行查询需要处理大量的行，因此它有助于为整个向量而不是单独的行指派所有操作，或者实现查询引擎，以便没有指派成本。如果你不这样做，任何半象限的磁盘子系统，查询解释器不可避免地中断CPU。将数据存储在列中并在可能的情况下按列处理是有意义的。

有两种方法可以做到这一点：

1.向量引擎。所有的操作都是为向量而写的，而不是单独的值。这意味着您不需要经常调用操作，调度成本可以忽略不计。操作代码包含一个优化的内部循环。

2.代码生成。为查询生成的代码具有所有的间接调用。

这不是在“普通”数据库中完成的，因为运行简单查询时没有意义。但是，也有例外。例如，MemSQL在处理SQL查询时使用代码生成来减少延迟。（为了比较，分析DBMS需要优化吞吐量，而不是延迟。）

请注意，为了提高CPU效率，查询语言必须是声明式的（SQL或MDX），或者至少是一个向量（J，K）。查询应该只包含隐式循环，以便优化。

ClickHouse的显著特性

1.真正的面向列的DBMS

2.数据高效压缩

3.磁盘存储的数据

4.多核并行处理

5.在多个服务器上分布式处理

6. SQL语法支持

7.向量化引擎

8.实时数据更新

9.索引

10.适合在线查询

11.支持近似预估计算

12.支持嵌套的数据结构

支持数组作为数据类型

13.支持限制查询复杂性以及配额

14.复制数据复制和对数据完整性的支持

我们来看看其中的一些功能：

1.真正的面向列的DBMS

在一个真正的面向列的DBMS中，没有任何“垃圾”存储在值中。例如，必须支持定长数值，以避免在数值旁边存储长度“数字”。例如，十亿个UInt8类型的值实际上应该消耗大约1 GB的未压缩磁盘空间，否则这将强烈影响CPU的使用。由于解压缩的速度（CPU使用率）主要取决于未压缩的数据量，所以即使在未压缩的情况下，紧凑地存储数据（没有任何“垃圾”）也是非常重要的。

因为有些系统可以单独存储单独列的值，但由于其他场景的优化，无法有效处理分析查询。例如HBase，BigTable，Cassandra和HyperTable。在这些系统中，每秒钟可以获得大约十万行的吞吐量，但是每秒不会达到数亿行。

另外，ClickHouse是一个DBMS，而不是一个单一的数据库。ClickHouse允许在运行时创建表和数据库，加载数据和运行查询，而无需重新配置和重新启动服务器。

2.数据压缩

一些面向列的DBMS（InfiniDB CE和MonetDB）不使用数据压缩。但是，数据压缩确实提高了性能。

3.磁盘存储的数据

许多面向列的DBMS（SAP HANA和Google PowerDrill）只能在内存中工作。但即使在数千台服务器上，内存也太小，无法在Yandex.Metrica中存储所有浏览量和会话。

4.多核并行处理

多核多节点并行化大型查询。

5.在多个服务器上分布式处理

上面列出的列式DBMS几乎都不支持分布式处理。在ClickHouse中，数据可以驻留在不同的分片上。每个分片可以是用于容错的一组副本。查询在所有分片上并行处理。这对用户来说是透明的。

6. SQL支持

如果你熟悉标准的SQL，我们不能真正谈论SQL的支持。

NULL不支持。

所有的函数都有不同的名字。

JOIN支持。

子查询在FROM，IN，JOIN子句中被支持;

标量子查询支持。

关联子查询不支持。

7.向量化引擎

数据不仅按列存储，而且由矢量 - 列的部分进行处理。这使我们能够实现高CPU性能。

8.实时数据更新

ClickHouse支持主键表。为了快速执行对主键范围的查询，数据使用合并树(MergeTree)进行递增排序。由于这个原因，数据可以不断地添加到表中。添加数据时无锁处理。

9.索引

例如，带有主键可以在特定的时间范围内为特定客户端（Metrica计数器）抽取数据，并且延迟时间小于几十毫秒。

10.支持在线查询

这让我们使用该系统作为Web界面的后端。低延迟意味着可以无延迟实时地处理查询，而Yandex.Metrica界面页面正在加载（在线模式）。

11.支持近似计算

1.系统包含用于近似计算各种值，中位数和分位数的集合函数。

2.支持基于部分（样本）数据运行查询并获得近似结果。在这种情况下，从磁盘检索比例较少的数据。

3.支持为有限数量的随机密钥（而不是所有密钥）运行聚合。在数据中密钥分发的特定条件下，这提供了相对准确的结果，同时使用较少的资源。

12.数据复制和对数据完整性的支持。

使用异步多主复制。写入任何可用的副本后，数据将分发到所有剩余的副本。系统在不同的副本上保持相同的数据。数据在失败后自动恢复，或对复杂情况使用“按钮”。有关更多信息，请参阅“数据复制”一节。

ClickHouse目前未实现功能

1.无事务处理。

2.对于聚合，查询结果必须适合单个服务器上的内存。但是，查询的源数据量可能无限大。

3.缺乏全面的UPDATE / DELETE实现

Yandex.Metrica任务

我们需要根据点击和会话获取自定义报告，并使用用户设置的自定义。报告数据实时更新。查询必须立即运行（在线模式）。我们必须能够在任何时间段建立报告。必须计算复杂的汇总，例如唯一访客的数量。目前（2014年4月），Yandex.Metrica每天接收约120亿次事件（浏览量和鼠标点击）。所有这些事件都必须存储以建立自定义报告。单个查询可能需要几秒钟扫描数亿行，或者数百万行不超过几百毫秒。

汇总和非汇总数据

有一种流行的观点认为，为了有效地计算统计数据，您必须汇总数据，因为这会减少数据量。

但是数据聚合是一个非常有限的解决方案，原因如下：

- 您必须具有用户需要的预定义报告列表。用户不能进行自定义报告。

- 聚合大量密钥时，数据量不会减少，聚合无用。

- 对于大量的报告，聚合变化太多（组合爆炸）。

- 聚合高基数密钥（如URL）时，数据量不会减少太多（小于两倍）。出于这个原因，聚合的数据量可能会增长，而不是缩小。

- 用户不会查看我们为他们计算的所有报告。大部分的计算是无用的。

- 各种聚合可能违反数据的逻辑完整性。

如果我们不汇总任何内容并使用非汇总的数据，这实际上可能会减少计算量。

但是，通过汇总，相当一部分工作脱离了线索，相对冷静地完成了工作。相反，在线计算需要尽可能快地计算，因为用户正在等待结果。

Yandex.Metrica有一个专门的系统来汇总称为Metrage的数据，这个数据用于大多数报告。从2009年开始，Yandex.Metrica还使用专门的OLAP数据库来处理非聚合数据，称为OLAPServer，以前用于报告生成器。OLAPServer对非汇总数据运行良好，但是它有许多限制，不能根据需要用于所有报告。这些包括缺乏对数据类型（仅数字）的支持，以及无法实时增量更新数据（只能通过每天重写数据来完成）。OLAPServer不是一个DBMS，而是一个专门的DB。

为了消除OLAPServer的限制，并解决所有报告使用非汇总数据的问题，我们开发了ClickHouse DBMS。

用于Yandex.Metrica和其他Yandex服务

ClickHouse在Yandex.Metrica中用于多种用途。其主要任务是使用非聚合数据以在线模式构建报告。它使用374个服务器的集群，在数据库中存储超过8万亿行（超过四十亿个值）。压缩数据量不计复制和复制，大约是800TB。未压缩的数据量（以TSV格式）将大约为7PB。

ClickHouse还用于：

- 存储WebVisor数据。

- 处理中间数据。

- 使用Google Analytics构建全球报告。

- 运行查询以调试Metrica引擎。

- 分析来自API和用户界面的日志。

ClickHouse在其他Yandex服务中至少安装了十几个安装：搜索行业，市场，Direct，业务分析，移动开发，AdFox，个人服务等。

类似开源系统

有没有类似的ClickHouse可用。目前（2016年5月），没有任何可用的开源和免费系统具有上面列出的所有功能。但是，这些功能对于Yandex.Metrica是绝对必要的。

可能愚蠢的问题

1.为什么不使用map-reduce等系统？

像map-reduce这样的系统是分布式计算系统，其中使用分布式排序来执行缩减阶段。回顾这个方面，map-reduce与YAMR，Hadoop，YT等其他系统类似。

这些系统由于延迟而不适合在线查询，所以不能用于后台级别的网页界面。这样的系统也不适合实时更新。分布式排序并不是减少操作的最佳解决方案，如果操作的结果和所有中间结果都存在，就像通常在联机分析查询的情况下发生的那样，它们适合单个服务器的运行内存。在这种情况下，执行reduce操作的最佳方法是使用散列表。map-reduce任务的常用优化方法是在内存中使用散列表的组合操作（partial reduce）。这个优化是由用户手动完成的。分布式排序是简单的map-reduce作业长时间延迟的主要原因。

与map-reduce类似的系统可以在集群上运行任何代码。但是，对于OLAP，使用情况下的执行查询语言更为合适，因为经过调研它们可以更快地运行。例如，Hadoop有Hive和Pig。还有其他：Cloudera Impala,Shark (depricated)andSpark SQLforSpark,Presto,Apache Drill.。然而，与专门系统的性能相比，这些任务的性能是非常不理想的，相对较高的延迟不允许将这些系统用作网络接口的后端。YT允许您存储单独的一组列。但YT不是一个真正的列式存储系统，因为系统没有固定长度的数据类型（所以你可以有效地存储一个数字而不是“垃圾”），而且没有向量化引擎。YT中的任务由流模式下的任意代码执行，因此不能被充分优化（每台服务器每秒高达数亿行）。在2014-2016年，YT将开发使用合并树，强类型值和类SQL语言支持的“动态表格排序”功能。动态排序的表不适用于OLAP任务，因为数据存储在行中。YT中的查询语言开发仍处于孵化阶段，不能专注于这个功能。YT开发人员正在考虑在OLTP和Key-Value方案中使用动态排序的表。

性能

根据内部测试结果，ClickHouse在可用于测试的同类系统中显示出最佳性能。这包括长查询的最高吞吐量和短查询的最低延迟。测试结果显示在此页面上。

吞吐量为单个大型查询

吞吐量可以以每秒行数或兆字节每秒来衡量。如果数据放置在页面缓存中，则在现代硬件上处理不太复杂的查询，在单个服务器上以大约2-10 GB / s的未压缩数据的速度进行处理（对于最简单的情况，速度可能会达到30 GB / s）。如果数据不在页面缓存中，则速度取决于磁盘子系统和数据压缩率。例如，如果磁盘子系统允许以400 MB / s读取数据，并且数据压缩率为3，则速度将在1.2 GB / s左右。要获得每秒行数的速度，请将查询中使用的列的总大小除以每秒字节数。例如，如果提取10个字节的列，速度将在每秒大约1到2亿行。

处理速度对于分布式处理几乎线性地增加，但是只有在聚合或排序产生的行数不太大的情况下。

处理短的查询时延迟

如果一个查询使用一个主键，并且没有选择太多的行来处理（成千上万），并且不使用太多的列，我们可以预计到不到50毫秒的延迟（最好的情况下，单位为毫秒）if数据被放置在页面缓存中。否则，延迟是根据搜索的数量来计算的。如果使用旋转驱动器，对于没有过载的系统，延迟时间通过以下公式计算：查找时间（10 ms）*查询的列数*数据部分的数量。

处理大量的短查询时的吞吐量

在相同的条件下，ClickHouse可以在单个服务器上每秒处理几百个查询（在最好的情况下可以达到几千个）。由于这种情况对分析型DBMS并不常见，因此我们建议每秒最多可以查询100个查询。

数据插入性能

我们建议将数据插入至少1000行的数据包中，或者每秒不超过一个请求。从制表符分隔转储插入到MergeTree表时，插入速度将从50到200 MB / s。如果插入的行大小约为1Kb，速度将从每秒50,000到200,000行。如果行很小，则每秒的行数会更高（Yandex Banner System数据 - > 500,000行/秒，Graphite数据 - > 1,000,000行/秒）。为了提高性能，可以并行执行多个INSERT查询，并且性能会线性增加。