1.简介
ClickHouse 是俄罗斯的 Yandex 于 2016 年开源的用于在线分析处理查询(OLAP :Online Analytical Processing)MPP架构的列式存储数据库(DBMS:Database Management System),能够使用 SQL 查询实时生成分析数据报告。ClickHouse的全称是Click Stream,Data WareHouse。
2.ClickHouse的特点
开源的列存储数据库管理系统,支持线性扩展,简单方便,高可靠性,
容错跑分快:比Vertica快5倍,比Hive快279倍,比MySQL快800倍,其可处理的数据级别已达到10亿级别
功能多:支持数据统计分析各种场景,支持类SQL查询,异地复制部署
3.ClickHouse为什么快
1.数据压缩. clickhouse是一个列式存储的数据库,每一列数据都经过了lz4的压缩,由于列数据之间重复性极高,所以拥有非常可观的压缩比,这样查询一列数据时,扫描速度极快,这样clickhouse可以得到非常极端的数据压缩比(20%)
2.cpu指令层面的优化,大量使用了向量化的操作的指令,并且非常善于利用cpu的L1,L2,L3缓存,尽量减少读取内存或者磁盘的操作.
3.不同的场景使用不同的算法或者数据结构,比如数据量较小时就是用array数组存储,数据中等大小时就用hashset结构存储,数据量庞大时使用hyperloglog结构存储
4.不同的表引擎,包括合并树表引擎,聚合合并树表引擎,内存表引擎等等,不同的应用场景可以使用不同的表引擎提高性能.
内部高性能算法的使用,比如字符串查找的算法选择,clickhouse会去选择速度最快的算法.
4.Clickhouse的优缺点介绍
优点:
为了高效的使用CPU,数据不仅仅按列存储,同时还按向量进行处理;
数据压缩空间大,减少IO;处理单查询高吞吐量每台服务器每秒最多数十亿行;
索引非B树结构,不需要满足最左原则;只要过滤条件在索引列中包含即可;即使在使用的数据不在索引中,由于各种并行处理机制ClickHouse全表扫描的速度也很快;
写入速度非常快,50-200M/s,按照每行100Byte估算,大约相当于50W-200W条/s的写入速度。对于大量的数据更新非常适用。
缺点:
不支持事务;
不支持高并发,官方建议qps为100,可以通过修改配置文件增加连接数,但是在服务器足够好的情况下;
SQL满足日常使用80%以上的语法,join写法比较特殊;最新版已支持类似SQL的join,但性能不好;
尽量做1000条以上批量的写入,避免逐行insert或小批量的insert,update,delete操作,因为ClickHouse底层会不断的做异步的数据合并,会影响查询性能,这个在做实时数据写入的时候要尽量避开;
Clickhouse快是因为采用了并行处理机制,即使一个查询,也会用服务器一半的CPU去执行,所以ClickHouse不能支持高并发的使用场景,默认单查询使用CPU核数为服务器核数的一半,安装时会自动识别服务器核数,可以通过配置文件修改该参数。
5.扩展: 什么是列式存储数据库
在传统的行式数据库系统中,数据按如下顺序存储:
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 |
… |
… |
… |
… |
… |
处于同一行中的数据总是被物理的存储在一起。
常见的行式数据库系统有:MySQL、Postgres和MS SQL Server。
在列式数据库系统中,数据按如下的顺序存储:
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+。
不同的数据存储方式适用不同的业务场景,数据访问的场景包括:进行了何种查询、多久查询一次以及各类查询的比例;每种类型的查询(行、列和字节)读取多少数据;读取数据和更新之间的关系;使用的数据集大小以及如何使用本地的数据集;是否使用事务,以及它们是如何进行隔离的;数据的复制机制与数据的完整性要求;每种类型的查询要求的延迟与吞吐量等等。
系统负载越高,依据使用场景进行定制化就越重要,并且定制将会变的越精细。没有一个系统能够同时适用所有不同的业务场景。如果系统适用于广泛的场景,在负载高的情况下,要兼顾所有的场景,那么将不得不做出选择。是要平衡还是要效率?
6.OLAP场景的关键特征
绝大多数是读请求
数据以相当大的批次(> 1000行)更新,而不是单行更新;或者根本没有更新。
已添加到数据库的数据不能修改。
对于读取,从数据库中提取相当多的行,但只提取列的一小部分。
宽表,即每个表包含着大量的列
查询相对较少(通常每台服务器每秒查询数百次或更少)
对于简单查询,允许延迟大约50毫秒
列中的数据相对较小:数字和短字符串(例如,每个URL 60个字节)
处理单个查询时需要高吞吐量(每台服务器每秒可达数十亿行)
事务不是必须的
对数据一致性要求低
每个查询有一个大表。除了他以外,其他的都很小。
查询结果明显小于源数据。换句话说,数据经过过滤或聚合,因此结果适合于单个服务器的RAM中
很容易可以看出,OLAP场景与其他通常业务场景(例如,OLTP或K/V)有很大的不同, 因此想要使用OLTP或Key-Value数据库去高效的处理分析查询场景,并不是非常完美的适用方案。例如,使用OLAP数据库去处理分析请求通常要优于使用MongoDB或Redis去处理分析请求。
7.列式数据库更适合OLAP场景的原因
列式数据库更适合于OLAP场景(对于大多数查询而言,处理速度至少提高了100倍),下面详细解释了原因(通过图片更有利于直观理解):
行式
列式
看到差别了么?下面将详细介绍为什么会发生这种情况。
输入/输出
针对分析类查询,通常只需要读取表的一小部分列。在列式数据库中你可以只读取你需要的数据。例如,如果只需要读取100列中的5列,这将帮助你最少减少20倍的I/O消耗。
由于数据总是打包成批量读取的,所以压缩是非常容易的。同时数据按列分别存储这也更容易压缩。这进一步降低了I/O的体积。
由于I/O的降低,这将帮助更多的数据被系统缓存。
例如,查询«统计每个广告平台的记录数量»需要读取«广告平台ID»这一列,它在未压缩的情况下需要1个字节进行存储。如果大部分流量不是来自广告平台,那么这一列至少可以以十倍的压缩率被压缩。当采用快速压缩算法,它的解压速度最少在十亿字节(未压缩数据)每秒。换句话说,这个查询可以在单个服务器上以每秒大约几十亿行的速度进行处理。这实际上是当前实现的速度。
8.性能对比图
9.clickhouse安装
https://blog.csdn.net/2301_76154806/article/details/128781183
安装完成后使用dbeaver连接测试.