Clickhouse简介及性能测试？
1. 什么是clickhouse？
ClickHouse是一个用于联机分析(OLAP)的列式数据库管理系统(DBMS)。
1.1 行式数据库
在传统的行式数据库系统中,处于同一行中的数据总是被物理的存储在一起。
| Row WatchID | JavaEnable | Title | GoodEvent | EventTime |
|---|---|---|---|---|
| #0 | 89354350662 | 1 Investor | Relations | 1 |
| #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。
1.2 列式数据库
| 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+。
1.3 不同类型数据库选择？
不同的数据存储方式适用不同的业务场景，数据访问的场景包括：进行了何种查询、多久查询一次以及各类查询的比例；每种类型的查询(行、列和字节)读取多少数据；读取数据和更新之间的关系；使用的数据集大小以及如何使用本地的数据集；是否使用事务,以及它们是如何进行隔离的；数据的复制机制与数据的完整性要求；每种类型的查询要求的延迟与吞吐量等等。
系统负载越高，依据使用场景进行定制化就越重要，并且定制将会变的越精细。没有一个系统能够同时适用所有不同的业务场景。如果系统适用于广泛的场景，在负载高的情况下，要兼顾所有的场景，那么将不得不做出选择。是要平衡还是要效率？
1.4 OLAP场景的关键特征
- 绝大多数是读请求
- 数据以相当大的批次(> 1000行)更新，而不是单行更新;或者根本没有更新。
- 已添加到数据库的数据不能修改。
- 对于读取，从数据库中提取相当多的行，但只提取列的一小部分。
- 宽表，即每个表包含着大量的列
- 查询相对较少(通常每台服务器每秒查询数百次或更少)
- 对于简单查询，允许延迟大约50毫秒
- 列中的数据相对较小：数字和短字符串(例如，每个URL 60个字节)
- 处理单个查询时需要高吞吐量(每台服务器每秒可达数十亿行)
- 事务不是必须的
- 对数据一致性要求低
- 每个查询有一个大表。除了他以外，其他的都很小。
- 查询结果明显小于源数据。换句话说，数据经过过滤或聚合，因此结果适合于单个服务器的RAM中
很容易可以看出，OLAP场景与其他通常业务场景(例如,OLTP或K/V)有很大的不同， 因此想要使用OLTP或Key-Value数据库去高效的处理分析查询场景，并不是非常完美的适用方案。例如，使用OLAP数据库去处理分析请求通常要优于使用MongoDB或Redis去处理分析请求。
1.5 列式数据库更适合OLAP场景的原因？
列式数据库更适合于OLAP场景(对于大多数查询而言，处理速度至少提高了100倍)
输入/输出
- 针对分析类查询，通常只需要读取表的一小部分列。在列式数据库中你可以只读取你需要的数据。例如，如果只需要读取100列中的5列，这将帮助你最少减少20倍的I/O消耗。
- 由于数据总是打包成批量读取的，所以压缩是非常容易的。同时数据按列分别存储这也更容易压缩。这进一步降低了I/O的体积。
- 由于I/O的降低，这将帮助更多的数据被系统缓存。
例如，查询«统计每个广告平台的记录数量»需要读取«广告平台ID»这一列，它在未压缩的情况下需要1个字节进行存储。如果大部分流量不是来自广告平台，那么这一列至少可以以十倍的压缩率被压缩。当采用快速压缩算法，它的解压速度最少在十亿字节(未压缩数据)每秒。换句话说，这个查询可以在单个服务器上以每秒大约几十亿行的速度进行处理。这实际上是当前实现的速度。
CPU
由于执行一个查询需要处理大量的行，因此在整个向量上执行所有操作将比在每一行上执行所有操作更加高效。同时这将有助于实现一个几乎没有调用成本的查询引擎。如果你不这样做，使用任何一个机械硬盘，查询引擎都不可避免的停止CPU进行等待。所以，在数据按列存储并且按列执行是很有意义的。
有两种方法可以做到这一点：
-
向量引擎：所有的操作都是为向量而不是为单个值编写的。这意味着多个操作之间的不再需要频繁的调用，并且调用的成本基本可以忽略不计。操作代码包含一个优化的内部循环。
-
代码生成：生成一段代码，包含查询中的所有操作。
这是不应该在一个通用数据库中实现的，因为这在运行简单查询时是没有意义的。但是也有例外，例如，MemSQL使用代码生成来减少处理SQL查询的延迟(只是为了比较，分析型数据库通常需要优化的是吞吐而不是延迟)。
请注意，为了提高CPU效率，查询语言必须是声明型的(SQL或MDX)， 或者至少一个向量(J，K)。 查询应该只包含隐式循环，允许进行优化。
2. 项目报表模块分析
由前面的OLAP场景分析可以得出，本项目的报表模块，十分符合OLAP的场景需要。
2.1 数据流程图
2.2 数据流程解读
- 将基础的学生数据及相关数据进行整合，以应用的形式，进行clickhouse列数据库的宽表处理，这种情况，可以适应大多数的以大宽表进行的数据维度统计分析，对于需要进行的分析型数据的多表分析，则可以考虑用MPP算力引擎Trino进行大数据的计算处理，并进行相应的clickhouse的表处理
- 根据报表页面的需求在clickhosue端进行数据获取
2.3 后续扩展性方案考虑
2.3.1 报表离线模式（数据实时性要求较低）
对于离线模式，即在数据实时性要求不高的情况下，可以采取定时方案，进行数据的生成更新删除等操作。
2.3.2 报表实时模式（数据实时性要求较高）
为了适应多变的需求的情况，报表存在对于数据实时性有较高要求的可能，参考clickhouse官方文档，如下：
数据读取方面
In the same case, Clickhouse can process hundreds of queries per second on a single server (at best, up to thousands). However, this is not applicable to analytical scenarios. Therefore, we recommend a maximum of 100 queries per second.
数据写入方面
We recommend that no less than 1000 rows of batch writes be written each time, or no more than one write request per second. When using the tab separated format to write a copy of data to the mergetree table, the write speed is about 50 to 200MB / s. If you write 1KB of data per line, the write speed is 50000 to 200000 lines per second. If your rows are smaller, the write speed will be higher. In order to improve the write performance, you can use multiple inserts to write in parallel, which will bring linear performance improvement.
尽管clickhouse的读取性能已经非常出色，还是不乏有一些缺陷，在数据读取方面，clickhouse可以保证QPS 100 完美并发量，在表现好的时候，这个并发量甚至可以达到1000，在数据写入方面，官方还是建议每次写入不少于1000行的批量写入，或每秒不超过一个写入请求。即对于报表流程图中，clickhouse主要面临数据明细表实时的进行clickhosue的更新，以及来自报表展示端的对于clickhosue的访问压力，可以主要对这一块可以引入hystrix或sentinel组件进行相应的限流处理，从而可以保证报表实时流程的正常运行。
3. 基础性能测试
3.1 导入测试数据
通过trino将mysql中的库数据导入至clickhouse中，可以看出，往tb_exam_eyesight_result2222单表中大约存入19G的空间,1700w
+数据。
3.2 常见聚合运算查询表现
3.2.1 方差
如图所见，sql查询时间652ms，满足秒级查询需求。
3.2.2 标准差
如图所见，sql查询时间594ms，满足秒级查询需求。
3.2.3 报表常见的维度聚合查询
如图所见，sql查询时间518ms，满足秒级查询需求。
3.2.4 修改表结构（增加数据列）
如图所见，sql查询时间23ms，满足秒级查询需求。
3.2.5 修改表结构（删除数据列）
如图所见，sql查询时间50ms，满足秒级查询需求。
1545
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
