什么是 ClickHouse？

ClickHouse 是一个用于联机分析(OLAP)的列式数据库管理系统(DBMS)。

在传统的行式数据库系统中，数据按如下顺序存储：

Row	WatchID	JavaEnable	Title	GoodEvent	EventTime
0	89354350662	1	Investor Relations	1	2016-05-18 05:19:20
1	90329509958	0	Contact us	1	2016-05-18 08:10:20
2	89953706054	1	Mission	1	2016-05-18 07:38:00
N	…	…	…	…	…

处于同一行中的数据总是被物理的存储在一起。

常见的行式数据库系统有：MySQL、Postgres和MS SQL Server。

在列式数据库系统中，数据按如下的顺序存储：

Row	#0	#1	#2	#N
WatchID	89354350662	90329509958	89953706054	…
JavaEnable	1	0	1	…
Title	Investor Relations	Contact us	Mission	…
GoodEvent	1	1	1	…
EventTime	2016-05-18 05:19:20	2016-05-18 08:10:20	2016-05-18 07:38:00	…

这些示例只显示了数据的排列顺序。来自不同列的值被单独存储，来自同一列的数据被存储在一起。

常见的列式数据库有： 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场景与其他通常业务场景(例如,OLTP或K/V)有很大的不同，因此想要使用OLTP或Key-Value数据库去高效的处理分析查询场景，并不是非常完美的适用方案。例如，使用OLAP数据库去处理分析请求通常要优于使用MongoDB或Redis去处理分析请求。

列式数据库更适合OLAP场景的原因

列式数据库更适合于OLAP场景(对于大多数查询而言，处理速度至少提高了100倍)，下面详细解释了原因(通过图片更有利于直观理解)：

row

column

column

看到差别了么？下面将详细介绍为什么会发生这种情况。

输入/输出

针对分析类查询，通常只需要读取表的一小部分列。在列式数据库中你可以只读取你需要的数据。例如，如果只需要读取100列中的5列，这将帮助你最少减少20倍的I/O消耗。
由于数据总是打包成批量读取的，所以压缩是非常容易的。同时数据按列分别存储这也更容易压缩。这进一步降低了I/O的体积。
由于I/O的降低，这将帮助更多的数据被系统缓存。

例如，查询«统计每个广告平台的记录数量»需要读取«广告平台ID»这一列，它在未压缩的情况下需要1个字节进行存储。如果大部分流量不是来自广告平台，那么这一列至少可以以十倍的压缩率被压缩。当采用快速压缩算法，它的解压速度最少在十亿字节(未压缩数据)每秒。换句话说，这个查询可以在单个服务器上以每秒大约几十亿行的速度进行处理。这实际上是当前实现的速度。

CPU

由于执行一个查询需要处理大量的行，因此在整个向量上执行所有操作将比在每一行上执行所有操作更加高效。同时这将有助于实现一个几乎没有调用成本的查询引擎。如果你不这样做，使用任何一个机械硬盘，查询引擎都不可避免的停止CPU进行等待。所以，在数据按列存储并且按列执行是很有意义的。

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

向量引擎：所有的操作都是为向量而不是为单个值编写的。这意味着多个操作之间的不再需要频繁的调用，并且调用的成本基本可以忽略不计。操作代码包含一个优化的内部循环。

代码生成：生成一段代码，包含查询中的所有操作。

这是不应该在一个通用数据库中实现的，因为这在运行简单查询时是没有意义的。但是也有例外，例如，MemSQL使用代码生成来减少处理SQL查询的延迟(只是为了比较，分析型数据库通常需要优化的是吞吐而不是延迟)。

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

ClickHouse的特性

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

在一个真正的列式数据库管理系统中，除了数据本身外不应该存在其他额外的数据。这意味着为了避免在值旁边存储它们的长度«number»，你必须支持固定长度数值类型。例如，10亿个UInt8类型的数据在未压缩的情况下大约消耗1GB左右的空间，如果不是这样的话，这将对CPU的使用产生强烈影响。即使是在未压缩的情况下，紧凑的存储数据也是非常重要的，因为解压缩的速度主要取决于未压缩数据的大小。

这是非常值得注意的，因为在一些其他系统中也可以将不同的列分别进行存储，但由于对其他场景进行的优化，使其无法有效的处理分析查询。例如： HBase，BigTable，Cassandra，HyperTable。在这些系统中，你可以得到每秒数十万的吞吐能力，但是无法得到每秒几亿行的吞吐能力。

需要说明的是，ClickHouse不单单是一个数据库，它是一个数据库管理系统。因为它允许在运行时创建表和数据库、加载数据和运行查询，而无需重新配置或重启服务。

数据压缩

在一些列式数据库管理系统中(例如：InfiniDB CE 和 MonetDB) 并没有使用数据压缩。

但是, 若想达到比较优异的性能，数据压缩确实起到了至关重要的作用。

除了在磁盘空间和CPU消耗之间进行不同权衡的高效通用压缩编解码器之外，ClickHouse还提供针对特定类型数据的专用编解码器，这使得ClickHouse能够与更小的数据库(如时间序列数据库)竞争并超越它们。

数据的磁盘存储

许多的列式数据库(如 SAP HANA, Google PowerDrill)只能在内存中工作，这种方式会造成比实际更多的设备预算。

ClickHouse被设计用于工作在传统磁盘上的系统，它提供每GB更低的存储成本，但如果可以使用SSD和内存，它也会合理的利用这些资源。

多核心并行处理

ClickHouse会使用服务器上一切可用的资源，从而以最自然的方式并行处理大型查询。

多服务器分布式处理

上面提到的列式数据库管理系统中，几乎没有一个支持分布式的查询处理。

在ClickHouse中，数据可以保存在不同的shard上，每一个shard都由一组用于容错的replica组成，查询可以并行地在所有shard上进行处理。这些对用户来说是透明的

支持SQL

ClickHouse支持一种基于SQL的声明式查询语言，它在许多情况下与ANSI SQL标准相同。

支持的查询GROUP BY, ORDER BY, FROM, JOIN, IN以及非相关子查询。

相关(依赖性)子查询和窗口函数暂不受支持，但将来会被实现。

向量引擎

为了高效的使用CPU，数据不仅仅按列存储，同时还按向量(列的一部分)进行处理，这样可以更加高效地使用CPU。

实时的数据更新

ClickHouse支持在表中定义主键。为了使查询能够快速在主键中进行范围查找，数据总是以增量的方式有序的存储在MergeTree中。因此，数据可以持续不断地高效的写入到表中，并且写入的过程中不会存在任何加锁的行为。

索引

按照主键对数据进行排序，这将帮助ClickHouse在几十毫秒以内完成对数据特定值或范围的查找。

适合在线查询

在线查询意味着在没有对数据做任何预处理的情况下以极低的延迟处理查询并将结果加载到用户的页面中。

支持近似计算

ClickHouse提供各种各样在允许牺牲数据精度的情况下对查询进行加速的方法：

用于近似计算的各类聚合函数，如：distinct values, medians, quantiles

基于数据的部分样本进行近似查询。这时，仅会从磁盘检索少部分比例的数据。

不使用全部的聚合条件，通过随机选择有限个数据聚合条件进行聚合。这在数据聚合条件满足某些分布条件下，在提供相当准确的聚合结果的同时降低了计算资源的使用。

自适应连接算法

ClickHouse支持自定义JOIN多个表，它更倾向于散列连接算法，如果有多个大表，则使用合并-连接算法

支持数据复制和数据完整性

ClickHouse使用异步的多主复制技术。当数据被写入任何一个可用副本后，系统会在后台将数据分发给其他副本，以保证系统在不同副本上保持相同的数据。在大多数情况下ClickHouse能在故障后自动恢复，在一些少数的复杂情况下需要手动恢复。

更多信息，参见数据复制。

角色的访问控制

ClickHouse使用SQL查询实现用户帐户管理，并允许角色的访问控制，类似于ANSI SQL标准和流行的关系数据库管理系统。

限制

没有完整的事务支持。

缺少高频率，低延迟的修改或删除已存在数据的能力。仅能用于批量删除或修改数据，但这符合 GDPR。稀疏索引使得ClickHouse不适合通过其键检索单行的点查询。

性能

根据Yandex的内部测试结果，ClickHouse表现出了比同类可比较产品更优的性能。你可以在这里查看具体的测试结果。

许多其他的测试也证实这一点。你可以使用互联网搜索到它们，或者你也可以从我们收集的部分相关连接中查看。

单个大查询的吞吐量

吞吐量可以使用每秒处理的行数或每秒处理的字节数来衡量。如果数据被放置在page cache中，则一个不太复杂的查询在单个服务器上大约能够以2-10GB／s（未压缩）的速度进行处理（对于简单的查询，速度可以达到30GB／s）。如果数据没有在page cache中的话，那么速度将取决于你的磁盘系统和数据的压缩率。例如，如果一个磁盘允许以400MB／s的速度读取数据，并且数据压缩率是3，则数据的处理速度为1.2GB/s。这意味着，如果你是在提取一个10字节的列，那么它的处理速度大约是1-2亿行每秒。

对于分布式处理，处理速度几乎是线性扩展的，但这受限于聚合或排序的结果不是那么大的情况下。

处理短查询的延迟时间

如果一个查询使用主键并且没有太多行(几十万)进行处理，并且没有查询太多的列，那么在数据被page cache缓存的情况下，它的延迟应该小于50毫秒(在最佳的情况下应该小于10毫秒)。否则，延迟取决于数据的查找次数。如果你当前使用的是HDD，在数据没有加载的情况下，查询所需要的延迟可以通过以下公式计算得知：查找时间（10 ms） * 查询的列的数量 * 查询的数据块的数量。

处理大量短查询的吞吐量

在相同的情况下，ClickHouse可以在单个服务器上每秒处理数百个查询（在最佳的情况下最多可以处理数千个）。但是由于这不适用于分析型场景。因此我们建议每秒最多查询100次。

数据的写入性能

我们建议每次写入不少于1000行的批量写入，或每秒不超过一个写入请求。当使用tab-separated格式将一份数据写入到MergeTree表中时，写入速度大约为50到200MB/s。如果您写入的数据每行为1Kb，那么写入的速度为50，000到200，000行每秒。如果您的行更小，那么写入速度将更高。为了提高写入性能，您可以使用多个INSERT进行并行写入，这将带来线性的性能提升。

ClickHouse历史

ClickHouse最初是为 YandexMetrica 世界第二大Web分析平台而开发的。多年来一直作为该系统的核心组件被该系统持续使用着。目前为止，该系统在ClickHouse中有超过13万亿条记录，并且每天超过200多亿个事件被处理。它允许直接从原始数据中动态查询并生成报告。本文简要介绍了ClickHouse在其早期发展阶段的目标。

Yandex.Metrica基于用户定义的字段，对实时访问、连接会话，生成实时的统计报表。这种需求往往需要复杂聚合方式，比如对访问用户进行去重。构建报表的数据，是实时接收存储的新数据。

截至2014年4月，Yandex.Metrica每天跟踪大约120亿个事件（用户的点击和浏览）。为了可以创建自定义的报表，我们必须存储全部这些事件。同时，这些查询可能需要在几百毫秒内扫描数百万行的数据，或在几秒内扫描数亿行的数据。

Yandex.Metrica以及其他Yandex服务的使用案例

在Yandex.Metrica中，ClickHouse被用于多个场景中。它的主要任务是使用原始数据在线的提供各种数据报告。它使用374台服务器的集群，存储了20.3万亿行的数据。在去除重复与副本数据的情况下，压缩后的数据达到了2PB。未压缩前（TSV格式）它大概有17PB。

ClickHouse还被使用在：

存储来自Yandex.Metrica的会话重放数据。处理中间数据与Analytics一起构建全球报表。为调试Yandex.Metrica引擎运行查询分析来自API和用户界面的日志数据 ClickHouse在其他Yandex服务中至少有12个安装：search verticals, Market, Direct, business analytics, mobile development, AdFox, personal services等。

聚合与非聚合数据

有一种流行的观点认为，想要有效的计算统计数据，必须要聚合数据，因为聚合将降低数据量。

但是数据聚合是一个有诸多限制的解决方案，例如：

你必须提前知道用户定义的报表的字段列表用户无法自定义报表当聚合条件过多时，可能不会减少数据，聚合是无用的。存在大量报表时，有太多的聚合变化（组合爆炸）当聚合条件有非常大的基数时（如：url），数据量没有太大减少（少于两倍）聚合的数据量可能会增长而不是收缩用户不会查看我们为他生成的所有报告，大部分计算将是无用的各种聚合可能违背了数据的逻辑完整性如果我们直接使用非聚合数据而不进行任何聚合时，我们的计算量可能是减少的。

然而，相对于聚合中很大一部分工作被离线完成，在线计算需要尽快的完成计算，因为用户在等待结果。

Yandex.Metrica 有一个专门用于聚合数据的系统，称为Metrage，它可以用作大部分报表。从2009年开始，Yandex.Metrica还为非聚合数据使用专门的OLAP数据库，称为OLAPServer，它以前用于报表构建系统。 OLAPServer可以很好的工作在非聚合数据上，但是它有诸多限制，导致无法根据需要将其用于所有报表中。如，缺少对数据类型的支持（只支持数据），无法实时增量的更新数据（只能通过每天重写数据完成）。OLAPServer不是一个数据库管理系统，它只是一个数据库。

为了消除OLAPServer的这些局限性，解决所有报表使用非聚合数据的问题，我们开发了ClickHouse数据库管理系统。

用户

https://clickhouse.com/docs/zh/introduction/adopters

TODO

部署实战

chat

详细介绍一下 Clickhouse

ClickHouse（点击豪斯）是一个开源的列式数据库管理系统（DBMS），专为OLAP（联机分析处理）工作负载而设计。它由俄罗斯的Yandex公司开发，最初是为了满足他们日益增长的数据分析需求而创建的。

ClickHouse以其出色的性能和能够处理大规模数据集而受到青睐。

以下是ClickHouse的一些关键特性和优势：

列式存储结构： ClickHouse采用了列式存储结构，与传统的行式数据库相比，这种结构更适合OLAP工作负载。它将相同列的数据存储在一起，这样在分析性查询时可以实现更高的压缩比和查询性能。
高性能： ClickHouse的主要优势之一是其卓越的查询性能。它通过采用高度优化的列存储引擎和并行查询处理来实现快速的数据检索和分析。
扩展性： ClickHouse支持水平扩展，可以通过添加更多的节点来增加处理能力和存储容量。这使得它能够轻松应对大规模数据集和高并发查询的需求。
实时数据分析： 尽管ClickHouse主要是为OLAP设计的，但它也具有一些实时数据分析的能力。例如，支持合并树结构和实时数据注入，这些特性使其适用于需要快速响应的分析场景。
灵活的数据模型： ClickHouse支持灵活的数据模型，可以处理各种数据类型，包括数值、日期、字符串等。此外，它还支持对数据进行高级的压缩和编码，以减小存储空间的占用。
支持 SQL： ClickHouse使用SQL作为查询语言，这使得对于熟悉SQL的开发者来说更容易上手。同时，ClickHouse的SQL支持也相当强大，可以执行复杂的分析查询。
数据可靠性： ClickHouse具有强大的数据可靠性和容错性能。它通过数据复制和分布式架构来确保数据的持久性和可靠性。
社区支持和活跃开发： ClickHouse是一个开源项目，拥有活跃的社区和不断发展的开发团队。这意味着用户可以从社区获取支持，同时也能够受益于持续的改进和更新。

总体而言，ClickHouse是一个专注于高性能、可扩展性和实时数据分析的列式数据库管理系统，适用于处理大规模数据集的OLAP场景。

类似 Clickhouse 的开源列式数据库有哪些？

在开源领域，有几个类似于ClickHouse的列式数据库，它们都专注于高性能的OLAP工作负载。以下是一些常见的开源列式数据库：

Apache Druid:
- Druid是一款开源的分布式列式存储数据库，专注于实时数据分析。它支持对大规模数据集的实时查询和分析，并且具有强大的水平扩展性和灵活的数据模型。
Apache Cassandra:
- Cassandra是一款分布式NoSQL列式数据库，旨在处理大规模的分布式数据。虽然它最初是为OLAP而设计的，但由于其分布式特性，也适用于OLAP场景。
InfluxDB:
- InfluxDB是一个高性能的开源时间序列数据库，专注于处理时序数据。它采用了列式存储结构，适用于监控、IoT和实时分析等场景。
TimescaleDB:
- TimescaleDB是一款基于PostgreSQL的开源时间序列数据库，采用了列式存储结构。它结合了关系型数据库和时间序列数据库的特性，适用于复杂的时间序列数据分析。
MonetDB:
- MonetDB是一款用于OLAP工作负载的开源列式数据库，旨在提供高性能的分析查询。它支持SQL查询语言，并具有自适应优化和向量化执行引擎。
Greenplum Database:
- Greenplum是一个开源的、基于PostgreSQL的大规模数据仓库系统，支持并行处理和高性能的分布式查询。它在处理大规模数据集的分析场景中表现出色。

这些数据库在设计上可能有一些差异，包括数据模型、查询语言、扩展性和适用场景等。选择适合特定需求的列式数据库需要考虑到项目的具体要求和性能需求。

Clickhouse 的特点和应用场景

ClickHouse是一款专注于高性能OLAP工作负载的开源列式数据库管理系统，具有许多特点和适用场景，其中一些关键特点和应用场景包括：

特点：

列式存储结构： ClickHouse采用列式存储结构，有助于提高查询性能和压缩比。对于分析性查询，它只检索所需列，从而减少了IO操作和提高了效率。
高性能： ClickHouse以其卓越的查询性能而闻名，能够在处理大规模数据集时提供快速的查询和分析。这归功于其列式存储引擎、并行查询处理以及优化的执行引擎。
扩展性： ClickHouse支持水平扩展，可以通过添加更多的节点来增加处理能力和存储容量。这使得它能够轻松应对不断增长的数据需求。
实时数据注入： ClickHouse支持实时数据注入，可以在查询过程中实时插入新数据。这对于需要实时分析的场景非常有用。
SQL支持： ClickHouse使用SQL作为查询语言，这使得对于熟悉SQL的开发者来说更易上手。同时，ClickHouse的SQL支持也相当强大，可以执行复杂的分析查询。
数据可靠性： ClickHouse具有强大的数据可靠性和容错性。通过数据复制和分布式架构，它确保数据的持久性和可靠性。
灵活的数据模型： ClickHouse支持灵活的数据模型，可以处理各种数据类型，包括数值、日期、字符串等。同时，它还支持对数据进行高级的压缩和编码。

应用场景：

大规模数据分析： ClickHouse适用于需要在大规模数据集上执行复杂分析查询的场景，例如数据仓库、业务智能和数据分析平台。
时序数据分析： 由于其高性能和实时数据注入支持，ClickHouse也非常适合处理时序数据，例如日志、监控数据、传感器数据等。
日志分析： ClickHouse在处理大量日志数据时表现出色，可以用于实时分析、统计和报告。
实时业务分析： ClickHouse的快速查询能力使其成为实时业务分析的理想选择，支持快速的数据查询和实时决策。
大规模数据仓库： ClickHouse的扩展性和性能使其成为大规模数据仓库的理想解决方案，能够应对复杂的数据处理和分析需求。

总体而言，ClickHouse 在大规模数据分析、时序数据分析以及实时业务分析等场景中都具有强大的性能和适用性。

ClickHouse 和其他数据库对比有什么优缺点？

与其他数据库相比，ClickHouse在某些方面具有独特的优势，同时也存在一些限制。以下是ClickHouse与其他数据库的一些比较，注意这些比较可能因使用情境和具体需求而异：

ClickHouse 与传统行式数据库对比：

优势：

查询性能： ClickHouse在OLAP工作负载下表现出色，尤其在大规模数据集上的分析查询方面，由于其列式存储结构和优化的查询引擎。
数据压缩： 列式存储结构通常具有更好的压缩比，因为相同类型的数据存储在一起，这有助于减小存储空间的占用。
水平扩展： ClickHouse天生支持水平扩展，通过添加更多节点可以轻松地增加处理能力和存储容量。
实时数据分析： ClickHouse支持实时数据注入，使其在实时数据分析场景中更具优势。

限制：

事务处理（OLTP）： ClickHouse主要专注于OLAP工作负载，对于事务处理（OLTP）并不是最佳选择。传统的行式数据库在处理事务性操作方面更有优势。
更新操作： ClickHouse对于频繁的更新操作并不是很高效，因为它的设计更适用于批处理和大量数据的分析。

ClickHouse 与其他列式数据库对比：

与Apache Druid对比：

灵活性： Druid更适用于实时数据的分析，而ClickHouse的灵活性和对SQL的支持更广泛。
水平扩展： ClickHouse在水平扩展方面可能更为直接，而Druid专注于实时数据的高性能。

与InfluxDB对比：

查询性能： ClickHouse在某些场景下可能提供更好的查询性能，特别是对于大规模数据集的复杂查询。
灵活性： InfluxDB专注于时序数据，而ClickHouse的数据模型更为灵活，适用于更广泛的分析场景。

与TimescaleDB对比：

性能： ClickHouse可能在某些大规模数据集的查询性能上略有优势，但TimescaleDB提供了与PostgreSQL兼容的SQL接口。
时序数据支持： TimescaleDB专注于时序数据，因此在特定的时序数据分析场景中可能更为适用。

总体比较：