clickhouse是什么

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.不同的表引擎，包括合并树表引擎，聚合合并树表引擎，内存表引擎等等，不同的应用场景可以使用不同的表引擎提高性能.

1. 内部高性能算法的使用，比如字符串查找的算法选择，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倍)，下面详细解释了原因(通过图片更有利于直观理解)：

行式

列式

看到差别了么？下面将详细介绍为什么会发生这种情况。

输入/输出

1. 针对分析类查询，通常只需要读取表的一小部分列。在列式数据库中你可以只读取你需要的数据。例如，如果只需要读取100列中的5列，这将帮助你最少减少20倍的I/O消耗。

2. 由于数据总是打包成批量读取的，所以压缩是非常容易的。同时数据按列分别存储这也更容易压缩。这进一步降低了I/O的体积。

3. 由于I/O的降低，这将帮助更多的数据被系统缓存。

例如，查询«统计每个广告平台的记录数量»需要读取«广告平台ID»这一列，它在未压缩的情况下需要1个字节进行存储。如果大部分流量不是来自广告平台，那么这一列至少可以以十倍的压缩率被压缩。当采用快速压缩算法，它的解压速度最少在十亿字节(未压缩数据)每秒。换句话说，这个查询可以在单个服务器上以每秒大约几十亿行的速度进行处理。这实际上是当前实现的速度。

8.性能对比图

9.clickhouse安装

https://blog.csdn.net/2301_76154806/article/details/128781183

安装完成后使用dbeaver连接测试.