clickhouse

clickhouse 面对海量数据，比如单表过百亿可以使用集群（复制 + 分片）

如果数据量比较小，比如单表 10-20 亿使用单机就足以满足查询需求

https://segmentfault.com/a/1190000023702890

数据量

https://www.jianshu.com/p/fc384f18ff1a

ClickHouse在计算层做了非常细致的工作，竭尽所能榨干硬件能力，提升查询速度。它实现了单机多核并行、分布式计算、向量化执行与SIMD指令、代码生成等多种重要技术

ClickHouse将数据划分为多个partition，每个partition再进一步划分为多个index granularity，然后通过多个CPU核心分别处理其中的一部分来实现并行数据处理。在这种设计下，单条Query就能利用整机所有CPU。极致的并行处理能力，极大的降低了查询延时。

多核并行

除了优秀的单机并行处理能力，ClickHouse还提供了可线性拓展的分布式计算能力。ClickHouse会自动将查询拆解为多个task下发到集群中，然后进行多机并行处理，最后把结果汇聚到一起。

分布式计算

ClickHouse不仅将数据按列存储，而且按列进行计算。传统OLTP数据库通常采用按行计算，原因是事务处理中以点查为主，SQL计算量小，实现这些技术的收益不够明显。但是在分析场景下，单个SQL所涉及计算量可能极大，将每行作为一个基本单元进行处理会带来严重的性能损耗：

•对每一行数据都要调用相应的函数，函数调用开销占比高；•存储层按列存储数据，在内存中也按列组织，但是计算层按行处理，无法充分利用CPU cache的预读能力，造成CPU Cache miss严重；•按行处理，无法利用高效的SIMD指令；

ClickHouse实现了向量执行引擎（Vectorized execution engine），对内存中的列式数据，一个batch调用一次SIMD指令（而非每一行调用一次），不仅减少了函数调用次数、降低了cache miss，而且可以充分发挥SIMD指令的并行能力，大幅缩短了计算耗时。向量执行引擎，通常能够带来数倍的性能提升。

向量化执行与SIMD

即 single instruction multiple data 英文首字母缩写，单指令流多数据流，也就是说一次运算指令可以执行多个数据流，一个简单的例子就是向量的加减。

SSE（为Streaming SIMD Extensions的缩写）是由 Intel公司在1999年推出Pentium III处理器时，同时推出的新指令集。如同其名称所表示的，SSE是一种SIMD指令集。SSE有8个128位寄存器，XMM0 ~XMM7。可以用来存放四个32位的单精确度浮点数。可以看出，SSE 是一套专门为 SIMD（单指令多数据）架构设计的指令集。通过它，用户可以同时在多个数据片段上执行运算，实现数据并行（aka:矢量处理）。

span style=\

SSE 与 SMID 关系

编译器优化 即使用C/C++编写程序之后，带有SIMD优化选项编译，在CPU支持的情况下，编译器按照自己的规则去优化。

使用intrinsic指令 参考Intel手册，针对SIMD指令，可以在编程时直接使用其内置的某些库函数，编译的时候在cpu和编译器的支持下会生成对应的SIMD指令。比如：double _mm_cvtsd_f64 (__m128d a) 该函数编译时就会翻译成指令：movsd

嵌入式汇编 内联汇编直接在程序中嵌入对应的SIMD指令。

C++使用SIMD编程的3种方法

要能够使用 Intel 的 SIMD 指令集，不仅需要当前 Intel 处理器的硬件支持，还需要编译器的支持。

$ grep -q sse4_2 /proc/cpuinfo && echo \"SSE 4.2 supported\" || echo \"SSE 4.2 not supported\"

如果你的机器支持SSE4.2，那么，将打印：

SSE 4.2 supported

计算机硬件支持与编译器支持

SIMD

利用优点： 频繁调用的基础函数，大量的可并行计算

尽量避免： SSE指令集对分支处理能力非常的差，而且从128位的数据中提取某些元素数据的代价又非常的大，因此不适合有复杂逻辑的运算。

使用SIMD考量

大家在搜索CLICKHOUSE为什么快的文章中，都提到了CH使用到的技术列式存储，压缩，向量引擎。

CH在所有能够提高CPU计算效率的地方，都大量的使用了SIMD。

How Clickhouse USE SIMD

向量化

https://blog.csdn.net/qq_23160237/article/details/105683601

1、查询不全，由于分片的数据不均，会出现查询数据不全的问题，所以JOIN表和 IN子句 也要使用 _all 分布式表;

2、查询放大，由于JOIN表 和 IN子句 也是 _all 分布式表，所以每个分片又会向其他远端的分片发起分布式查询，最终的查询次数是 N 的平方(N=分片数量);

3、解决思路，使用 GLOBAL IN 和 GLOBAL JOIN 可以避免查询放大的问题。

join和in

可以使用跨表本地化的策略

在ClickHouse集群中跨表进行Select查询时，采用Global IN/Global Join语句性能较为低下。分析原因，是在此类操作会生成临时表，并跨设备同步该表，导致查询速度慢。

解决方案：采用一致性hash，将相同主键数据写入同一个数据分片，在本地local表完成跨表联合查询，数据均来自于本地存储，从而提高查询速度。

这种优化方案也有一定的潜在问题，目前ClickHouse尚不提供数据的Reshard能力，当Shard所存储主键数据量持续增加，达到磁盘容量上限需要分拆时，目前只能根据原始数据再次重建CK集群，有较高的成本。

对于跨表查询

分布式表-Distributed表引擎

https://zhuanlan.zhihu.com/p/377506070

ClickHouse 单机JOIN操作默认采用HASH JOIN算法，可选MERGE JOIN算法。其中，MERGE JOIN算法数据会溢出到磁盘，性能相比前者较差

SELECT <expr_list>FROM <left_table>[GLOBAL] [INNER|LEFT|RIGHT|FULL|CROSS] [OUTER|SEMI|ANTI|ANY|ASOF] JOIN <right_table>(ON <expr_list>)|(USING <column_list>) ...

从right_table 读取该表全量数据，在内存中构建HASH MAP；

从left_table 分批读取数据，根据JOIN KEY到HASH MAP中进行查找，如果命中，则该数据作为JOIN的输出；

从这个实现中可以看出，如果right_table的数据量超过单机可用内存空间的限制，则JOIN操作无法完成。通常，两表JOIN时，将较小表作为right_table.

ClickHouse 的 HASH JOIN算法实现比较简单：

ClickHouse单机JOIN实现

ClickHouse 是去中心化架构，非常容易水平扩展集群。当以集群模式提供服务时候，分布式JOIN查询就无法避免。这里的分布式JOIN通常指，JOIN查询中涉及到的left_table 与 right_table 是分布式表。

Broadcast JOINShuffle JoinColocate JOIN

分布式JOIN实现机制无非如下几种：

ClickHouse集群并未实现完整意义上的Shuffle JOIN，实现了类Broadcast JOIN，通过事先完成数据重分布，能够实现Colocate JOIN。

如果右表为分布式表，则集群中每个节点会去执行分布式查询。这里就会存在一个非常严重的读放大现象。假设集群有N个节点，右表查询会在集群中执行N*N次。

ClickHouse 普通分布式JOIN查询是一个简单版的Shuffle JOIN的实现，或者说是一个不完整的实现。不完整的地方在于，并未按JOIN KEY去Shuffle数据，而是每个节点全量拉去右表数据。这里实际上是存在着优化空间的。

在生产环境中，查询放大对查询性能的影响是不可忽略的。

普通JOIN实现

GLOBAL JOIN 可以看做一个不完整的Broadcast JOIN实现。如果JOIN的右表数据量较大，就会占用大量网络带宽，导致查询性能降低。

GLOBAL JOIN 将右表的查询在initiator节点上完成后，通过网络发送到其他节点，避免其他节点重复计算，从而避免查询放大。

GLOBAL JOIN 实现

ClickHouse 的分布式JOIN查询可以分为两类，带GLOBAL关键字的，和不带GLOBAL关键字的情况。

ClickHouse根据JOIN的右表数据，构建HASH MAP，并将SQL中所需的列全部读入内存中。如果右表数据量过大，节点内存无法容纳后，无法完成计算。在实际中，我们通常将较小的表作为右表，并尽可能增加过滤条件，降低进入JOIN计算的数据量。

尽量减少JOIN右表数据量

如果右表或者子查询的数据量可控，可以使用GLOBAL JOIN来避免读放大。需要注意的是，GLOBAL JOIN 会触发数据在节点之间传播，占用部分网络流量。如果数据量较大，同样会带来性能损失。

利用GLOBAL JOIN 避免查询放大带来性能损失

当JOIN涉及的表数据量都非常大时，读放大，或网络广播都带来巨大性能损失时，我们就需要采取另外一种方式来完成JOIN计算了。

根据“相同JOIN KEY必定相同分片”原理，我们将涉及JOIN计算的表，按JOIN KEY在集群维度作分片。将分布式JOIN转为为节点的本地JOIN，极大减少了查询放大问题。

由于数据以及预分区了，相同的JOIN KEY对应的数据一定在一起，不会跨节点存在，所以无需对右表做分布式查询，也能获得正确结果。

数据预分布实现Colocate JOIN

分布式JOIN最佳实践

分布式JOIN实现

分布式join

clickhouse