clickhouse简介
一、Clickhouse简介
Ø 1.真正的面向列的DBMS
Ø 2.数据高效压缩
Ø 3.磁盘存储的数据
Ø 4.多核并行处理
Ø 5.在多个服务器上分布式处理
Ø 6.SQL语法支持
Ø 7.向量化引擎
Ø 8.实时数据更新
Ø 9.索引
Ø 10.适合在线查询
Ø 11.支持近似预估计算
Ø 12.支持嵌套的数据结构
Ø 支持数组作为数据类型
Ø 13.支持限制查询复杂性以及配额
Ø 14.复制数据复制和对数据完整性的支持
#我们来看看其中的一些功能：
1.真正的面向列的DBMS
在一个真正的面向列的DBMS中，没有任何“垃圾”存储在值中。例如，必须支持定长数值，以避免在数值旁边存储长度“数字”。例如，十亿个UInt8类型的值实际上应该消耗大约1 GB的未压缩磁盘空间，否则这将强烈影响CPU的使用。由于解压缩的速度（CPU使用率）主要取决于未压缩的数据量，所以即使在未压缩的情况下，紧凑地存储数据（没有任何“垃圾”）也是非常重要的。
因为有些系统可以单独存储单独列的值，但由于其他场景的优化，无法有效处理分析查询。例如HBase，BigTable，Cassandra和HyperTable。在这些系统中，每秒钟可以获得大约十万行的吞吐量，但是每秒不会达到数亿行。
另外，ClickHouse是一个DBMS，而不是一个单一的数据库。ClickHouse允许在运行时创建表和数据库，加载数据和运行查询，而无需重新配置和重新启动服务器。
2.数据压缩
一些面向列的DBMS（InfiniDB CE和MonetDB）不使用数据压缩。但是，数据压缩确实提高了性能。
3.磁盘存储的数据
许多面向列的DBMS（SAP HANA和GooglePowerDrill）只能在内存中工作。但即使在数千台服务器上，内存也太小，无法在Yandex.Metrica中存储所有浏览量和会话。
4.多核并行处理
多核多节点并行化大型查询。
5.在多个服务器上分布式处理
上面列出的列式DBMS几乎都不支持分布式处理。在ClickHouse中，数据可以驻留在不同的分片上。每个分片可以是用于容错的一组副本。查询在所有分片上并行处理。这对用户来说是透明的。
6.SQL支持
如果你熟悉标准的SQL，我们不能真正谈论SQL的支持。NULL不支持。所有的函数都有不同的名字。JOIN支持。子查询在FROM，IN，JOIN子句中被支持;标量子查询支持。关联子查询不支持。
7.向量化引擎
数据不仅按列存储，而且由矢量 - 列的部分进行处理。这使我们能够实现高CPU性能。
8.实时数据更新
ClickHouse支持主键表。为了快速执行对主键范围的查询，数据使用合并树(MergeTree)进行递增排序。由于这个原因，数据可以不断地添加到表中。添加数据时无锁处理。
9.索引
例如，带有主键可以在特定的时间范围内为特定客户端（Metrica计数器）抽取数据，并且延迟时间小于几十毫秒。
10.支持在线查询
这让我们使用该系统作为Web界面的后端。低延迟意味着可以无延迟实时地处理查询，而Yandex.Metrica界面页面正在加载（在线模式）。
11.支持近似计算
1.系统包含用于近似计算各种值，中位数和分位数的集合函数。
2.支持基于部分（样本）数据运行查询并获得近似结果。在这种情况下，从磁盘检索比例较少的数据。
3.支持为有限数量的随机密钥（而不是所有密钥）运行聚合。在数据中密钥分发的特定条件下，这提供了相对准确的结果，同时使用较少的资源。
12.数据复制和对数据完整性的支持。
使用异步多主复制。写入任何可用的副本后，数据将分发到所有剩余的副本。系统在不同的副本上保持相同的数据。数据在失败后自动恢复
ClickHouse的不完美：
Ø 1.不支持事务（大数据量的事务会降低系统吞吐）。
Ø 2.不支持直接的Update/Delete操作，需要使用alter来更新或删除。
Ø 3.支持有限操作系统。
二、clickhouse常见的引擎(MergeTree家族)
1）(Replicated)MergeTree
该引擎为最简单的引擎，存储最原始数据不做任何的预计算，任何在该引擎上的select语句都是在原始数据上进行操作的，常规场景使用最为广泛，其他引擎都是该引擎的一个变种。
2）(Replicated)SummingMergeTree
该引擎拥有“预计算(加法)”的功能。
实现原理：在merge阶段把数据加起来(对于需要加的列需要在建表的时候进行指定)，对于不可加的列，会取一个最先出现的值。
3）(Replicated)ReplacingMergeTree
该引擎拥有“处理重复数据”的功能。
使用场景：“最新值”，“实时数据”。
4）(Replicated)AggregatingMergeTree
该引擎拥有“预聚合”的功能。
使用场景：配合”物化视图”来一起使用，拥有毫秒级计算UV和PV的能力。
5）(Replicated)CollapsingMergeTree
该引擎和ReplacingMergeTree的功能有点类似，就是通过一个sign位去除重复数据的。
需要注意的是，上述所有拥有"预聚合"能力的引擎都在"Merge"过程中实现的，所以在表上进行查询的时候SQL是需要进行特殊处理的。
如SummingMergeTree引擎需要自己sum(), ReplacingMergeTree引擎需要使用时间+版本进行order by + limit来取到最新的值，由于数据做了预处理，数据量已经减少了很多，所以查询速度相对会快非常多。
7、最佳实践
1）实时写入使用本地表，不要使用分布式表
分布式表引擎会帮我们将数据自动路由到健康的数据表进行数据的存储，所以使用分布式表相对来说比较简单，对于Producer不需要有太多的考虑，但是分布式表有些致命的缺点。
- 数据的一致性问题，先在分布式表所在的机器进行落盘，然后异步的发送到本地表所在机器进行存储，中间没有一致性的校验，而且在分布式表所在机器时如果机器出现down机，会存在数据丢失风险；
- 据说对zookeeper的压力比较大(待验证)。
2）推荐使用(*)MergeTree引擎，该引擎是clickhouse最核心的组件，也是社区优化的重点
数据有保障，查询有保障，升级无感知。
3）谨慎使用on cluster的SQL
使用该类型SQL hang住的案例不少，我们也有遇到，可以直接写个脚本直接操作集群的每台进行处理。
三、安装启动clickhouse
sudo yum install yum-utils
sudo rpm --import https://repo.clickhouse.tech/CLICKHOUSE-KEY.GPG
sudo yum-config-manager --add-repo https://repo.clickhouse.tech/rpm/stable/x86_64
sudo yum install clickhouse-server clickhouse-client
sudo /etc/init.d/clickhouse-server start
clickhouse-client
启动：sudo /etc/init.d/clickhouse-server start四、查询速度比较
| 查询sql |
mysql全 |