这是我参与「第五届青训营」笔记创作活动的第8天

ClickHouse数据库

什么是 ClickHouse

ClickHouse 是“Clickstream Data Warehouse”的缩写，是一个列式 OLAP 数据库，最初是为 Yandex Metrica 中的网络分析而构建的。通常，ClickHouse 以其高插入率、快速分析查询和类似 SQL 的方言而闻名。

ClickHouse 架构

ClickHouse 专为具有特定特征的 OLAP 工作负载而设计。在ClickHouse 文档中，以下是此类工作负载的一些要求：

• 绝大多数请求都是针对读取访问的。
• 数据以相当大的批量（> 1000 行）插入，而不是单行插入；或者它根本没有更新。
• 数据被添加到数据库但未被修改。
• 对于读取，从数据库中处理了相当多的行，但只处理了一小部分列。
• 表是“宽的”，这意味着它们包含大量的列。
• 查询相对较少（通常每台服务器每秒数百次或更少的查询）。
• 对于简单的查询，允许有 50 毫秒左右的延迟。
• 列值相当小：数字和短字符串（例如，每个 URL 60 个字节）。
• 处理单个查询时需要高吞吐量（每台服务器每秒高达数十亿行）。
• 交易不是必需的。
• 对数据一致性要求低。
• 每个查询有一个大表。所有桌子都很小，除了一张。
• 查询结果明显小于源数据。换句话说，数据被过滤或聚合，因此结果适合单个服务器的 RAM.

ClickHouse表引擎

为了改进 ClickHouse 中数据的存储和处理，列式数据存储是使用表“引擎”的集合来实现的。表引擎确定表的类型以及可用于处理存储在其中的数据的功能。

ClickHouse 主要使用MergeTree 表引擎作为数据写入和组合的基础。几乎所有其他表引擎都派生自 MergeTree，并允许在（稍后）处理数据以进行长期存储时自动执行其他功能。

（快速澄清：从现在开始，每当我们提到 MergeTree 时，我们指的是整个 MergeTree 架构设计和从中派生的所有表类型，除非我们指定特定的 MergeTree 类型）

在高层次上，MergeTree 允许将数据非常快速地写入和存储到多个不可变文件（ClickHouse 称为“部分”）。这些文件稍后会在将来的某个时候在后台处理并合并成一个更大的部分，目的是减少磁盘上的 部分总数（更少的文件 = 以后更有效的数据读取）。这是 ClickHouse 在大批量上具有惊人的高插入性能的关键原因之一。

表中的所有列都存储在单独的部分（文件）中，每列中的所有值都按照主键的顺序存储。这种列分离和排序实现使未来的数据检索更加高效，特别是在计算大范围连续数据的聚合时。

ClickHouse索引

一旦数据被存储并合并到每个列的最有效的部分集合中 ， 查询就需要知道如何有效地查找数据。为此，Clickhouse 依赖两种类型的索引：主索引和辅助（数据跳过）索引。

与知道如何在表中定位任何行的传统 OLTP、BTree 索引不同，ClickHouse 主索引本质上是稀疏的，这意味着它没有指向主索引每个值位置的指针。相反，因为所有数据都按主键顺序存储，主索引每隔 N 行存储主键的值（称为 index_granularity，默认为 8192）。这样做的具体设计目标是将主索引装入内存以实现极快的处理速度。

当我们的查询模式适合这种类型的索引时，稀疏特性有助于显着提高查询速度。一个限制是我们不能在特定列上创建其他索引来帮助改进不同的查询模式。

使用场景

Clickhouse是为OLAP查询而设计的。

• 它可以处理少量包含大量字段的表。
• 查询可以使用从数据库中提取的大量行，但只用一小部分字段。
• 查询相对较少(通常每台服务器大约100个RPS)。
• 对于简单的查询，允许大约50毫秒的延迟。
• 列值相当小，通常由数字和短字符串组成（例如每个URL，60字节。
• 处理单个查询时需要高吞吐量（每台服务器每秒数十亿行）。
• 查询结果主要是过滤或聚合的。
• 数据更新使用简单的场景（通常只是批量处理，没有复杂的事务）。

ClickHouse的一个常见情况是服务器日志分析。在将常规数据上传到ClickHouse之后（建议将数据每次1000条以上批量插入），就可以通过即时查询分析事件或监视服务的指标，如错误率、响应时间等。

ClickHouse还可以用作内部分析师的内部数据仓库。ClickHouse可以存储来自不同系统的数据（比如Hadoop或某些日志），分析人员可以使用这些数据构建内部指示板，或者为了业务目的执行实时分析。