Clickhouse(3)---Clickhouse系统架构之Clickhouse特征

Clickhouse特征

1.完备的DBMS系统

ClickHouse拥有完备的管理功能，所以它称得上是一个DBMS（Database Management System，数据库管理系统），而不仅是一个数据库。作为一个DBMS，它具备了一些基本功能，如下所示。

• DDL（数据定义语言）：可以动态地创建、修改或删除数据库、表和视图，而无须重启服务。
• DML（数据操作语言）：可以动态查询、插入、修改或删除数据。
• 权限控制：可以按照用户粒度设置数据库或者表的操作权限，保障数据的安全性。
• 数据备份与恢复：提供了数据备份导出与导入恢复机制，满足生产环境的要求。
• 分布式管理：提供集群模式，能够自动管理多个数据库节点。这里只列举了一些最具代表性的功能，但已然足以表明为什么Click House称得上是DBMS了。

2.真正的列式数据库管理系统

在一个真正的列式数据库管理系统中，除了数据本身外不应该存在其他额外的数据。这意味着为了避免在值旁边存储它们的长度«number»，你必须支持固定长度数值类型。例如，10亿个UInt8类型的数据在未压缩的情况下大约消耗1GB左右的空间，如果不是这样的话（数据加数据长度），这将对CPU的使用产生强烈影响。即使是在未压缩的情况下，紧凑的存储数据也是非常重要的，因为解压缩的速度主要取决于未压缩数据的大小。
这是非常值得注意的，因为在一些其他系统中也可以将不同的列分别进行存储，但由于对其他场景进行的优化，使其无法有效的处理分析查询。例如： HBase，BigTable，Cassandra，HyperTable。在这些系统中，你可以得到每秒数十万的吞吐能力，但是无法得到每秒几亿行的吞吐能力。
————————————————
版权声明：官方文档
原文链接：https://clickhouse.com/docs/zh/introduction/distinctive-features/

首先看一下HBase中数据存储结构
HBase数据存储格式

可以看出来HBase底层存储数据会存储数据的长度。在CK中是存储了数据本身，这样在数据解压性性能方面大大提升，因为解压缩的速度主要取决于未压缩数据的大小

3.数据压缩

在一些列式数据库管理系统中(例如：InfiniDB CE 和 MonetDB) 并没有使用数据压缩。但是, 若想达到比较优异的性能，数据压缩确实起到了至关重要的作用,那么CK底层数据的存储使用的是列式数据存储,所有方便实时压缩算法,并且压缩比例和读取性能都比较理想

4.数据的磁盘存储

许多的列式数据库(如 SAP HANA, Google PowerDrill)只能在内存中工作，这种方式会造成比实际更多的设备预算。ClickHouse被设计用于工作在传统磁盘上的系统，它提供每GB更低的存储成本，但如果有可以使用SSD和内存，它也会合理的利用这些资源。

5.多核心并行处理

ClickHouse会使用服务器上一切可用的资源，从而以最自然的方式并行处理大型查询。因为底层使用c++,对硬件使用更优秀。

6.多服务器分布式处理

上面提到的列式数据库管理系统中，几乎没有一个支持分布式的查询处理。
在ClickHouse中，数据可以保存在不同的shard上，每一个shard都由一组用于容错的replica组成，查询可以并行地在所有shard上进行处理。这些对用户来说是透明的

7.支持SQL高阶函数

ClickHouse支持基于SQL的声明式查询语言，该语言大部分情况下是与SQL标准兼容的。
支持的查询包括 GROUP BY，ORDER BY，IN，JOIN以及非相关子查询。
不支持窗口函数和相关子查询。

8.向量引擎 (并行)

为了高效的使用CPU，数据不仅仅按列存储，同时还按向量(列的一部分)进行处理，这样可以更加高效地使用CPU。利用CPU的SIMD指令。SIMD的全称是 Single Instruction Multiple Data。它的原理是在CPU寄存器层 面实现数据的并行操作!

处理使用多线程处理数据以外，CK也使用CPU的寄存器,单指令并行处理数据,将数据的处理效率做到极致!

9.实时的数据更新 （MergeTree表引擎的表）

这个对于MergeTree表引擎的表引擎有要求的。
ClickHouse支持在表中定义主键。为了使查询能够快速在主键中进行范围查找，数据总是以增量的方式有序的存储在MergeTree中。因此，数据可以持续不断地高效的写入到表中，并且写入的过程中不会存在任何加锁的行为

10.索引

按照主键对数据进行排序，这将帮助ClickHouse在几十毫秒以内完成对数据特定值或范围的查找

11.适合在线查询

在线查询意味着在没有对数据做任何预处理的情况下以极低的延迟处理查询并将结果加载到用户的页面中。类比于Kylin,Kylin对数据进行了预处理，所以维度是固定的，做不到在线查询。

12.支持近似计算

ClickHouse提供各种各样在允许牺牲数据精度的情况下对查询进行加速的方法：

1. 用于近似计算的各类聚合函数，如：distinct values, medians, quantiles
2. 基于数据的部分样本进行近似查询。这时，仅会从磁盘检索少部分比例的数据。
3. 不使用全部的聚合条件，通过随机选择有限个数据聚合条件进行聚合。这在数据聚合条件满足某些分布条件下，在提供相当准确的聚合结果的同时降低了计算资源的使用。

13.多主架构

HDFS、Spark、HBase和Elasticsearch这类分布式系统，都采用了Master-Slave主从架构，由一个管控节点作为Leader统筹全局。而ClickHouse则采用Multi-Master多主架构，集群中的每个节点角色对等，客户端访问任意一个节点都能得到相同的效果。这种多主的架构有许多优势，例如对等的角色使系统架构变得更加简单，不用再区分主控节点、数据节点和计算节点，集群中的所有节点功能相同。所以它天然规避了单点故障的问题，非常适合用于多数据中心、异地多活的场景

14.支持数据复制和数据完整性

ClickHouse使用异步的多主复制技术。当数据被写入任何一个可用副本后，系统会在后台将数据分发给其他副本，以保证系统在不同副本上保持相同的数据。在大多数情况下ClickHouse能在故障后自动恢复，在一些少数的复杂情况下需要手动恢复。

Clickhouse优缺点

优点

• 为了高效的使用CPU，数据不仅仅按列存储，同时还按向量进行处理；
• 数据压缩空间大，减少IO；处理单查询高吞吐量每台服务器每秒最多数十亿行；
• 索引非B树结构，不需要满足最左原则；只要过滤条件在索引列中包含即可；即使在使用的数据不在索引中，由于各种并行处理机制ClickHouse全表扫描的速度也很快；
• 写入速度非常快，50-200M/s，对于大量的数据更新非常适用。

缺点

1. 不支持事务，不支持真正的删除/更新
2. 不支持高并发，官方建议qps为100，可以通过修改配置文件增加连接数，但是在服务器足够好的情况下；
3. 不支持真正的删除/更新 不支持事务（期待后续版本支持）
4. 有限的SQL支持，join实现与众不同
5. 不支持窗口功能
6. 元数据管理需要人工干预维护
7. SQL满足日常使用80%以上的语法，join写法比较特殊；最新版已支持类似SQL的join，但性能不好；
8. 尽量做1000条以上批量的写入，避免逐行insert或小批量的insert，update，delete操作，因为ClickHouse底层会不断的做异步的数据合并，会影响查询性能，这个在做实时数据写入的时候要尽量避开；
9. ClickHouse快是因为采用了并行处理机制，即使一个查询，也会用服务器一半的CPU去执行，所以ClickHouse不能支持高并发的使用场景，默认单查询使用CPU核数为服务器核数的一半，安装时会自动识别服务器核数，可以通过配置文件修改该参数。
10. zookeeper的依赖,集群要依赖zookeeper

Clickhouse查询为什么快

• 底层使用C++，更好应用硬件优势
• 摒弃Hadoop 主从的架构，使用多主结构
• 数据底层列式数据存储
• 利用单台机器（单节点）的多线程并行处理数据（利用CPU的多个核并行处理）
• 数据建立索引，一级，二级索引，稀疏索引
• 使用大量算法分析处理数据
• 支持向量化处理数据（寄存器中一个命令并行多个数据）
• 支持预先设计运算模型，预先计算（类似与kylin）