-
Notifications
You must be signed in to change notification settings - Fork 5
/
Copy pathclickhouse.txt
229 lines (130 loc) · 16.2 KB
/
clickhouse.txt
1
2
3
4
5
6
7
8
9
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
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
https://clickhouse.yandex/docs/en/
https://clickhouse.yandex/#quick-start
https://hub.docker.com/r/yandex/clickhouse-server/
数据库ClickHouse易观OLAP大数据
摘要：ClickHouse在易观2017年下半年举办的OLAP大赛上，以转化漏斗的实际应用场景，在40多支国内顶尖参赛队伍和比赛的众多苛刻软硬件环境下，开源组第一名使用的ClickHouse以速度惊人的成绩最终摘得了此次大赛桂冠。
初识ClickHouse还是在易观2017年下半年举办的OLAP大赛上，当时以转化漏斗的实际应用场景，在40多支国内顶尖参赛队伍中，在比赛的众多苛刻软硬件环境下，开源组第一名使用的ClickHouse以速度惊人的成绩最终摘得了此次大赛桂冠，赢得了10万奖金，ClickHouse“一战成名”，易观CTO郭炜同时发起了ClickHouse中国区用户组社区“ClickHouse User Group in China”，越来越多的对ClickHouse感兴趣的伙伴加入了该社区，社区地址：ClickHouse中文社区 (www.clickhouse.com.cn), 但依然有很多对ClickHouse不甚熟悉的伙伴（这也是撰写该文的重要原因），普及吸收先进技术是技术人的孜孜追求，欢迎各位小伙伴参加2018年1月27日Clickhouse中国第一次线下Meetup，本次Meetup是ClickHouse官方支持的Meetup，yandex团队现场分享。下面先对ClickHouse做个介绍，希望对大家熟悉ClickHouse有所帮助。
ClickHouse是“战斗民族”俄罗斯搜索巨头Yandex公司开源的一个极具"战斗力"的实时数据分析数据库，是面向 OLAP 的分布式列式DBMS，圈内人戏称为“喀秋莎数据库”。ClickHouse有一个简称"CK"，与Hadoop、Spark这些巨无霸组件相比，ClickHouse很轻量级，其特点：
列式存储数据库，数据压缩
关系型、支持SQL
分布式并行计算，把单机性能压榨到极限
高可用
数据量级在PB级别
实时数据更新
索引
ClickHouse最大的特点就是快，快，快，重要的话说三遍。为啥这样快呢？
优秀的代码编写，强⼤的底层优化，严格的单元测试，内置300多个函数
A vector engine & Code generation
CPU底层指令集的使⽤
C++新特性
其实关于性能，可以参考这两篇：
CK出众的原因也跟其引擎有关，合并树（MergeTree）系列的引擎通过主键进行字典序排列. 主键可以是列或表达式的任意 tuple。数据按照主键顺序存储数据，主键自身是稀疏的，它不定位到每一行，而是一些数据范围，当我们从MergeTree引擎中读取数据时，首先定位了可能包含请求数据的范围，要注意的合并树不是一个LSM树，因为它不包含内存表 和日志，插入的数据直接写入到文件系统，在生产环境中，写入的话主要以批量插入数据为主。在查询过程中，数据通过数组来处理(向量或者列Chunk)，查询时，操作被转发到数组上，而不是在特定的值上。因此被称为”向量化查询执行”，相对于实际的数据处理成本，向量化处理具有更低的转发成本。
据悉，目前已经有新浪、verta、percona、品友、电信等公司在使用，为了更好的传播优秀的ClickHouse技术，欢迎各位小伙伴参加2018年1月27日Clickhouse线下Meetup。活动报名链接：http://www.huodongxing.com/event/5418742362800，Meetup地点在中关村创业大街，海置创投大厦7层创业邦DemoSpace，具体更新请大家关注ClickHouse中文社区。
些示例只显示了数据排列的顺序。来自不同列的值分开存储，来自同一列的数据被存储在一起。
面向列的DBMS的示例：Vertica、Paraccel（Actian Matrix and Amazon Redshift）、Sybase IQ、Exasol、Infobright、InfiniDB、MonetDB（VectorWise and Actian Vector）、LucidDB、SAP HANA、Google Dremel、Google PowerDrill、Druid和kdb+。
存储数据的不同顺序更适合于不同的场景。数据访问场景涉及进行什么查询、多久进行查询以及以什么比例进行查询；每种类型的查询读取了多少数据——行、列和字节；读取和更新数据之间的关系；数据的工作大小以及本地如何使用它；事务是否重用，以及它们是如何隔离的；对数据复制和逻辑完整性的要求；对每种类型的查询的延迟和吞吐量的要求等等。
系统上的负载越高，定制为满足使用场景的要求而设置的系统就越重要，并且这种定制变得越细粒度。没有一个系统同样适用于显著不同的场景。如果系统在高负载下能够适应广泛的场景集，那么系统将同样地处理所有场景，或者对于可能的场景中的一种或几种将工作得很好。
OLAP场景的关键特性
绝大多数的请求是读访问。
数据以相当大的批次（＞1000行）更新，而不是由单个行更新，或者根本不更新。
数据被添加到数据库中，但是没有被修改。
对于读取，从DB中提取了相当多的行，但只有一小部分的列。
表是“宽”的，意味着它们包含大量的列。
查询相对较少（通常每服务器数百个查询或每秒更少）。
对于简单查询，允许50毫秒的潜伏期。
列值相当小：数字和短字符串（例如，每个URL为60字节）。
在处理单个查询时需要高吞吐量（每个服务器每秒高达数十亿行）。
交易是不必要的。
数据一致性要求低。
每个查询有一个大表。除了一张桌子，所有的桌子都很小。
查询结果明显小于源数据。换言之，数据被过滤或聚合，因此结果适合于单个服务器的RAM。
很容易看出，OLAP场景与其他流行场景（例如OLTP或KEY值访问）非常不同。因此，如果希望获得良好的性能，那么尝试使用OLTP或键值DB来处理分析查询是没有意义的。例如，如果您尝试使用MangGDB或ReDIS进行分析，与OLAP数据库相比，您将获得非常差的性能。
为什么面向列的数据库在OLAP场景中工作得更好
面向列的数据库更适合于OLAP场景：它们在处理大多数查询时至少快100倍。原因详细解释如下，但事实更容易直观地演示：
面向行的数据库管理系统
面向行的
关于列存储数据库
列导向
看到差别了吗？
输入输出
对于分析查询，只需要读取少量的表列。在面向列的数据库中，您可以读取所需的数据。例如，如果需要100列中的5列，则可以预期I/O.减少20倍。
由于数据在分组中被读取，所以压缩更容易。列中的数据也更容易压缩。这进一步降低了I/O体积。
由于减少的I/O，更多的数据适合于系统缓存。
例如，查询“计算每个广告平台的记录数量”需要读取一个“广告平台ID”列，该列占用未压缩的1个字节。如果大部分的流量不是来自广告平台，那么你可以期望这个栏目至少压缩10倍。当使用快速压缩算法时，可以以每秒至少几千兆字节未压缩数据的速度进行数据解压缩。换句话说，这个查询可以在单个服务器上以每秒大约几十亿行的速度进行处理。这种速度实际上是在实践中实现的。
例子
中央处理器
因为执行查询需要处理大量的行，所以它有助于调度整个向量的所有操作而不是单独的行，或者实现查询引擎，使得几乎没有调度成本。如果你不这样做，任何半正版磁盘子系统，查询解释器不可避免地拖延CPU。在列中存储数据并在可能的情况下通过列处理数据是有意义的。
有两种方法可以做到这一点：
向量引擎。所有操作都是为向量编写的，而不是为单独的值编写的。这意味着你不需要经常调用操作，调度成本是可以忽略不计的。操作代码包含优化的内部循环。
=====
What is ClickHouse?
ClickHouse is a column-oriented database management system (DBMS) for online analytical processing of queries (OLAP).
CLIKHOOK是一种面向列的数据库管理系统（DBMS），用于在线分析查询处理（OLAP）。
In a "normal" row-oriented DBMS, data is stored in this order:
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 ... ... ... ... ...
In order words, all the values related to a row are physically stored next to each other.
Examples of a row-oriented DBMS are MySQL, Postgres, and MS SQL Server.
In a column-oriented DBMS, data is stored like this:
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 ...
T
hese examples only show the order that data is arranged in. The values from different columns are stored separately, and data from the same column is stored together.
Examples of a column-oriented DBMS: Vertica, Paraccel (Actian Matrix and Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise and Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, and kdb+.
Different orders for storing data are better suited to different scenarios. The data access scenario refers to what queries are made, how often, and in what proportion; how much data is read for each type of query – rows, columns, and bytes; the relationship between reading and updating data; the working size of the data and how locally it is used; whether transactions are used, and how isolated they are; requirements for data replication and logical integrity; requirements for latency and throughput for each type of query, and so on.
The higher the load on the system, the more important it is to customize the system set up to match the requirements of the usage scenario, and the more fine grained this customization becomes. There is no system that is equally well-suited to significantly different scenarios. If a system is adaptable to a wide set of scenarios, under a high load, the system will handle all the scenarios equally poorly, or will work well for just one or few of possible scenarios.
Key Properties of the OLAP scenario
The vast majority of requests are for read access.
Data is updated in fairly large batches (> 1000 rows), not by single rows; or it is not updated at all.
Data is added to the DB but is not modified.
For reads, quite a large number of rows are extracted from the DB, but only a small subset of columns.
Tables are "wide," meaning they contain a large number of columns.
Queries are relatively rare (usually hundreds of queries per server or less per second).
For simple queries, latencies around 50 ms are allowed.
Column values are fairly small: numbers and short strings (for example, 60 bytes per URL).
Requires high throughput when processing a single query (up to billions of rows per second per server).
Transactions are not necessary.
Low requirements for data consistency.
There is one large table per query. All tables are small, except for one.
A query result is significantly smaller than the source data. In other words, data is filtered or aggregated, so the result fits in a single server's RAM.
It is easy to see that the OLAP scenario is very different from other popular scenarios (such as OLTP or Key-Value access). So it doesn't make sense to try to use OLTP or a Key-Value DB for processing analytical queries if you want to get decent performance. For example, if you try to use MongoDB or Redis for analytics, you will get very poor performance compared to OLAP databases.
Why Column-Oriented Databases Work Better in the OLAP Scenario
Column-oriented databases are better suited to OLAP scenarios: they are at least 100 times faster in processing most queries.
The reasons are explained in detail below, but the fact is easier to demonstrate visually:
Row-oriented DBMS
Row-oriented
Column-oriented DBMS
Column-oriented
See the difference?
Input/output
For an analytical query, only a small number of table columns need to be read. In a column-oriented database, you can read just the data you need. For example, if you need 5 columns out of 100, you can expect a 20-fold reduction in I/O.
Since data is read in packets, it is easier to compress. Data in columns is also easier to compress. This further reduces the I/O volume.
Due to the reduced I/O, more data fits in the system cache.
For example, the query "count the number of records for each advertising platform" requires reading one "advertising platform ID" column, which takes up 1 byte uncompressed. If most of the traffic was not from advertising platforms, you can expect at least 10-fold compression of this column. When using a quick compression algorithm, data decompression is possible at a speed of at least several gigabytes of uncompressed data per second. In other words, this query can be processed at a speed of approximately several billion rows per second on a single server. This speed is actually achieved in practice.
对于分析查询，只需要读取少量的表列。在面向列的数据库中，您可以读取所需的数据。例如，如果需要100列中的5列，则可以预期I/O.减少20倍。
由于数据在分组中被读取，所以压缩更容易。列中的数据也更容易压缩。这进一步降低了I/O体积。
由于减少的I/O，更多的数据适合于系统缓存。
例如，查询“计算每个广告平台的记录数量”需要读取一个“广告平台ID”列，该列占用未压缩的1个字节。如果大部分的流量不是来自广告平台，那么你可以期望这个栏目至少压缩10倍。当使用快速压缩算法时，可以以每秒至少几千兆字节未压缩数据的速度进行数据解压缩。换句话说，这个查询可以在单个服务器上以每秒大约几十亿行的速度进行处理。这种速度实际上是在实践中实现的。
Example
CPU
Since executing a query requires processing a large number of rows, it helps to dispatch all operations for entire vectors instead of for separate rows, or to implement the query engine so that there is almost no dispatching cost. If you don't do this, with any half-decent disk subsystem, the query interpreter inevitably stalls the CPU. It makes sense to both store data in columns and process it, when possible, by columns.
There are two ways to do this:
A vector engine. All operations are written for vectors, instead of for separate values. This means you don't need to call operations very often, and dispatching costs are negligible. Operation code contains an optimized internal cycle.
Code generation. The code generated for the query has all the indirect calls in it.
This is not done in "normal" databases, because it doesn't make sense when running simple queries. However, there are exceptions. For example, MemSQL uses code generation to reduce latency when processing SQL queries. (For comparison, analytical DBMSs require optimization of throughput, not latency.)
Note that for CPU efficiency, the query language must be declarative (SQL or MDX), or at least a vector (J, K). The query should only contain implicit loops, allowing for optimization.
因为执行查询需要处理大量的行，所以它有助于调度整个向量的所有操作而不是单独的行，或者实现查询引擎，使得几乎没有调度成本。如果你不这样做，任何半正版磁盘子系统，查询解释器不可避免地拖延CPU。在列中存储数据并在可能的情况下通过列处理数据是有意义的。
有两种方法可以做到这一点：
向量引擎。所有操作都是为向量编写的，而不是为单独的值编写的。这意味着你不需要经常调用操作，调度成本是可以忽略不计的。操作代码包含优化的内部循环。
代码生成。为查询生成的代码具有所有的间接调用。
这不是在“正常”数据库中完成的，因为在运行简单查询时没有意义。
然而，也有例外。例如，MEMSQL使用代码生成来减少处理SQL查询时的等待时间。（相比之下，分析DBMS需要优化吞吐量，而不是延迟。）
注意，对于CPU效率，查询语言必须是声明性的（SQL或MDX），或者至少是向量（j，k）。
查询应该只包含隐式循环，允许优化。