数据分片

数据分片是将数据进行横向切分，这是一种在面对海量数据的场景下，解决存储和查询瓶颈的有效手段，是一种分治思想的体现。Clickhouse支持分片，而分片则依赖集群。每个集群由1到多个分片组成，每个分片则对应了Clickhouse的1个服务节点。分片的数量上限取决于节点数量（1个分片只能对应1个服务节点）。

Clickhouse提供了本地表与分布式表的概念。一张本地表等同于一份数据分片。而分布式表本身不存储任何数据，它是本地表的访问代理，其作用类似分库中间件。借助分布式表，能够代理访问多个数据分片，从而实现分布式查询。

这种设计类似数据库的分库和分表，十分灵活。例如在业务系统上线的初期，数据体量并不高，此时数据表并不需要多个分片。所以使用单个节点的本地表（单个数据分片）即可满足业务要求，待到业务增长、数据量增大的时候，再通过新增数据分片的方式分流数据，并通过分布式表实现分布式查询。

列式存储

1）分析场景种往往需要读大量行中的少数几个列。在行存模式下，数据按行连续存储，所有列的数据都存储在一个block中，不参与计算的列在IO时也要全部读出，读取操作被严重放大。而列存模式下，只需要读取参与计算的列即可，极大的减低了IO cost，加速了查询。

2）同一列中的数据属于同一类型，压缩效果显著。列存往往有着高达十倍甚至更高的压缩比，节省了大量的存储空间，降低了存储成本。

3）更高的压缩比意味着更小的data size，从磁盘中读取相应数据耗时更短。

4）自由的压缩算法选择。不同列的数据具有不同的数据类型，适用的压缩算法也就不尽相同。可以针对不同列类型，选择最合适的压缩算法。

5）高压缩比，意味着同等大小的内存能够存放更多数据，系统cache效果更好。

向量化

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

1）对每一行数据都要调用相应的函数，函数调用开销占比高；

2）存储层按列存储数据，在内存中也按列组织，但是计算层按行处理，无法充分利用CPU cache的预读能力，造成CPU cache miss严重。

3）按行处理，无法利用高效的SIMD指令：

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

SIMD：单指令多数据流，能够赋值多个操作数，并把它们打包在大型寄存器的一组指令集。以同步方式，在同一时间内执行同一条指令。

分区

Clickhouse支持PARTITION BY子句，在建表时可以指定按照任意合法表达式进行数据分区操作，比如通过toYYYYMM()将数据按月进行分区、toMondy()将数据按照周几进行分区、对Enum类型的列直接每种取值一个分区等。数据以分区的形式统一管理和维护一批数据！

副本

数据存储副本，在集群模式下实现高可用，简单理解就是相同的数据备份，在CK中通过复制集，我们实现保障了数据可靠性外，也通过多副本的方式，增加了CK查询的并发能力。这里一般2种方式：（1）基于Zookeeper的表复制方式；（2）基于Cluster的复制方式。由于我们推荐的数据写入方式本地表写入，禁止分布式表写入，所以我们的复制表只考虑Zookeeper的表复制方案。

引擎

不同的引擎决定了表数据的存储特点和表数的操作行为：

1）决定表存储在哪里以及以何种方式存储。

2）支持哪些查询以及如何支持。

3）并发数据访问。

4）索引的使用

5）是否可以执行多现成请求

6）数据复制参数。

表引擎决定了数据在文件系统中存储方式，常用的也是官方推荐的存储引擎是MergeTree系列，如果需要数据副本的话可以使用ReplicatedMergeTree系列，相当于MergeTree副本版本。读取集群数据需要使用分布式表引擎Distribute。