问题导读
1.什么是ClickHouse？
2.ClickHouse适合哪些场景？
3.为什么面向列的数据库查询如此快？
1.什么是ClickHouse
ClickHouse是一个面向列的数据库管理系统（DBMS），用于在线分析处理查询（OLAP）。
在“传统”面向行的DBMS中，数据按以下顺序存储：
换句话说，与行相关的所有值都物理地存储在彼此旁边。
面向行的DBMS的示例是MySQL，Postgres和MS SQL Server。
在面向列的DBMS中，数据存储如下：
这些示例仅显示数据的排列顺序。不同列的值分别存储，同一列的数据存储在一起。
面向列的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 +。
存储数据的不同顺序更适合于不同的场景。数据访问场景是指进行了哪些查询，多长时间以及以何种比例进行查询;为每种类型的查询读取多少数据 - 行，列和字节;读取和更新数据之间的关系;数据大小以及如何使用本地数据;transactions是否被使用，以及它们是否隔离;数据replication和逻辑完整性的要求;每种类型的查询的延迟和吞吐量要求，等等。
系统负载越高，定制系统设置以匹配使用方案的要求就越重要，并且此定制变得越精细。没有一个系统同样适用于明显不同的场景。如果系统适应各种场景，在高负载下，系统将同样处理所有场景，或者仅适用于一种或几种可能的场景。
2.OLAP场景的关键属性
绝大多数请求都是读访问权限。
数据以相当大的批次（> 1000行）更新，而不是单行更新;或者它根本没有更新。
数据已添加到数据库，但未进行修改。
对于读取，从DB中提取了相当多的行，但只提取了一小部分列。
表格“宽”，意味着它们包含大量列。
查询相对较少（通常每台服务器数百个查询或每秒更少）。
对于简单查询，允许延迟大约50毫秒。
列值相当小：数字和短字符串（例如，每个URL 60个字节）。
处理单个查询时需要高吞吐量（每个服务器每秒最多数十亿行）。
Transactions不是必需的。
对数据一致性要求低。
每个查询有一个大表。所有表都很小，除了一个。
查询结果明显小于源数据。换句话说，数据被过滤或聚合，因此结果适合单个服务器的RAM。
很容易看出OLAP场景与其他流行场景（例如OLTP或键值访问）非常不同。 因此，如果希望获得不错的性能，尝试使用OLTP或键值DB来处理分析查询是没有意义的。 例如，如果尝试使用MongoDB或Redis进行分析，则与OLAP数据库相比，性能会非常差。
3.为什么面向列的数据库在OLAP场景中更好地工作
面向列的数据库更适合OLAP场景：它们在处理大多数查询时至少快100倍。 原因在下面详细解释，但事实更容易在视觉上展示：
面向行的DBMS
面向列的DBMS
看到不同？
输入/输出
对于分析查询，只需要读取少量表列。 在面向列的数据库中，只能读取所需的数据。 例如，如果需要100列中的5列，则可以预期I / O减少20倍。
由于数据以数据包形式读取，因此更容易压缩。 列中的数据也更容易压缩。 这进一步减少了I / O量。
由于I / O减少，更多数据适合系统缓存。
例如，查询“计算每个广告平台的记录数”需要读取一个“广告平台ID”列，其占用未压缩的1个字节。 如果大多数流量不是来自广告平台，则可以预期此列的压缩率至少为10倍。 当使用快速压缩算法时，数据解压缩可以每秒至少几千兆字节的未压缩数据的速度进行。 换句话说，可以在单个服务器上以每秒大约几十亿行的速度处理该查询。 这种速度实际上是在实践中实现的。
例子：
[Bash shell] 纯文本查看 复制代码
?
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
|
$ 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
.)
:)
|
CPU
由于执行查询需要处理大量行，因此有助于为整个向量而不是单独的行调度所有操作，或者实现查询引擎以便几乎不需要调度成本。如果不这样做，使用任何half-decent的磁盘子系统，查询解释器将不可避免地停止CPU。将数据存储在列中并在可能的情况下按列处理它是有意义的。
有两种方法可以做到这一点：
向量引擎：所有操作都是为向量而不是为单独的值编写的。这意味着不需要经常调用操作，并且调度成本可以忽略不计。操作代码包含优化的内部循环。
代码生成：为查询生成的代码中包含所有间接调用。
这不是在“传统”数据库中完成的，因为在运行简单查询时没有意义。但是，也有例外。例如，MemSQL使用代码生成来减少处理SQL查询时的延迟。 （为了进行比较，分析DBMS需要优化吞吐量，而不是延迟。）
请注意，对于CPU效率，查询语言必须是声明性的（SQL或MDX），或者至少是向量（J，K）。查询应该只包含隐式循环，允许优化。
每天进步一点点，欢迎关注公众号
↑ 翘首以盼等你关注
转载注明本文链接：
http://www.aboutyun.com/forum.php?mod=viewthread&tid=26264
----------------------------END----------------------------
1.about云知识星球,扫码可了解
2.加好友领取项目资料，附上“2”；
项目介绍：
http://www.aboutyun.com/forum.php?mod=viewthread&tid=25235
本公众号精彩文章推荐：
【1】Hadoop 2.x与3.x 22点比较：3.x将节省大量存储空间
【2】区块链零基础学习线路
【6】腾讯大数据面试及参考答案
【7】kafka学习线路指导入门：包括理论、部署、实战知识汇总整理
【8】技术走向管理一些深度思考
3283
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
