ClickHouse中文官方文档
什么是 ClickHouse？
ClickHouse® 是一个面向列的数据库管理系统 (DBMS)，用于查询的在线分析处理 (OLAP)。
在“正常”的面向行的 DBMS 中，数据按以下顺序存储：
| 排 | 手表ID | Java启用 | 标题 | 好活动 | 事件时间 |
|---|---|---|---|---|---|
| #0 | 89354350662 | 1 | 投资者关系 | 1 | 2016-05-18 05:19:20 |
| #1 | 90329509958 | 0 | 联系我们 | 1 | 2016-05-18 08:10:20 |
| #2 | 89953706054 | 1 | 使命 | 1 | 2016-05-18 07:38:00 |
| #N | … | … | … | … | … |
换句话说，与行相关的所有值在物理上彼此相邻存储。
面向行的 DBMS 的示例有 MySQL、Postgres 和 MS SQL Server。
在面向列的 DBMS 中，数据的存储方式如下：
| 排： | #0 | #1 | #2 | #N |
|---|---|---|---|---|
| 手表ID： | 89354350662 | 90329509958 | 89953706054 | … |
| Java启用： | 1 | 0 | 1 | … |
| 标题： | 投资者关系 | 联系我们 | 使命 | … |
| 好活动： | 1 | 1 | 1 | … |
| 活动时间： | 2016-05-18 05:19:20 | 2016-05-18 08:10:20 | 2016-05-18 07:38:00 | … |
这些示例仅显示了数据的排列顺序。来自不同列的值是分开存储的，来自同一列的数据是一起存储的。
面向列的 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 场景与其他流行场景（如 OLTP 或 Key-Value 访问）有很大不同。因此，如果您想获得不错的性能，尝试使用 OLTP 或 Key-Value DB 来处理分析查询是没有意义的。例如，如果您尝试使用 MongoDB 或 Redis 进行分析，与 OLAP 数据库相比，您将获得非常差的性能。
为什么面向列的数据库在 OLAP场景
面向列的数据库更适合 OLAP 场景：它们在处理大多数查询时至少快 100 倍。原因在下面详细解释，但事实更容易直观地展示：
面向行的 DBMS
面向列的 DBMS
看到不同？
输入/输出
- 对于分析查询，只需要读取少量的表列。在面向列的数据库中，您可以只读取您需要的数据。例如，如果您需要 100 列中的 5 列，则可以预期 I/O 减少 20 倍。
- 由于数据是以数据包的形式读取的，因此更容易压缩。列中的数据也更容易压缩。这进一步减少了 I/O 量。
- 由于 I/O 减少，更多数据适合系统缓存。
例如，查询“统计每个广告平台的记录数”需要读取一个“广告平台ID”列，未压缩占用1个字节。如果大部分流量不是来自广告平台，您可以预计此列至少压缩 10 倍。使用快速压缩算法时，可以以每秒至少几千兆字节的未压缩数据的速度进行数据解压缩。换句话说，这个查询可以在单个服务器上以大约每秒数十亿行的速度处理。这个速度实际上是在实践中达到的。
中央处理器
由于执行查询需要处理大量行，它有助于为整个向量而不是单独的行分派所有操作，或者实现查询引擎以便几乎没有分派成本。如果你不这样做，对于任何半体面的磁盘子系统，查询解释器不可避免地会停止 CPU。将数据存储在列中并在可能的情况下按列处理数据是有意义的。
有两种方法可以做到这一点：
-
矢量引擎。所有操作都是为向量编写的，而不是为单独的值编写的。这意味着您不需要经常调用操作，并且调度成本可以忽略不计。操作码包含优化的内部循环。
-
代码生成。为查询生成的代码包含所有间接调用。
这不是在“普通”数据库中完成的，因为在运行简单查询时它没有意义。但是，也有例外。例如，MemSQL 在处理 SQL 查询时使用代码生成来减少延迟。（相比之下，分析型 DBMS 需要优化吞吐量，而不是延迟。）
请注意，为了 CPU 效率，查询语言必须是声明性的（SQL 或 MDX），或者至少是一个向量（J，K）。查询应该只包含隐式循环，允许优化。