共计 12905 个字符，预计需要花费 33 分钟才能阅读完成。
随着业务的迅猛增长，Yandex.Metrica 目前曾经成为世界第三大 Web 流量剖析平台，每天解决超过 200 亿个跟踪事件。可能领有如此惊人的体量，在它背地提供撑持的 ClickHouse 功不可没。ClickHouse 曾经为 Yandex.Metrica 存储了超过 20 万亿行的数据，90% 的自定义查问可能在 1 秒内返回，其集群规模也超过了 400 台服务器。尽管 ClickHouse 起初只是为了 Yandex.Metrica 而研发的，但因为它出众的性能，目前也被广泛应用于 Yandex 外部其余数十个产品上。
初识 ClickHouse 的时候，我曾产生这样的感觉：它好像违反了物理定律，没有任何毛病，是一个不实在的存在。一款高性能、高可用 OLAP 数据库的所有诉求，ClickHouse 仿佛都能满足，这股神秘的气味引起了我极大的好奇。
刚从 Hadoop 生态转向 ClickHouse 的时候，我曾有诸多的不适应，因为它和咱们平常应用的技术 ” 性情 ” 大同小异。如果把数据库比作汽车，那么 ClickHouse 俨然就是一辆手动挡的赛车。它在很多方面不像其余零碎那样高度自动化。ClickHouse 的一些概念也与咱们通常的了解有所不同，特地是在分片和正本方面，有些时候数据的分片甚至须要手动实现。在进一步深刻应用 ClickHouse 之后，我慢慢地了解了这些设计的目标。
某些看似不够自动化的设计，反过来却在应用中带来了极大的灵活性。与 Hadoop 生态的其余数据库相比，ClickHouse 更像一款 ” 传统 ”MPP 架构的数据库，它没有采纳 Hadoop 生态中罕用的主从架构，而是应用了多主对等网络结构，同时它也是基于关系模型的 ROLAP 计划。
本文就让咱们抽丝剥茧，看看 ClickHouse 都有哪些外围个性。
ClickHouse 的外围个性
ClickHouse 是一款 MPP 架构的列式存储数据库，但 MPP 和列式存储并不是什么 ” 稀奇 ” 的设计。领有相似架构的其余数据库产品也有很多，然而为什么偏偏只有 ClickHouse 的性能如此出众呢？通过上一章的介绍，咱们晓得了 ClickHouse 倒退至今的演进过程。它一共经验了四个阶段，每一次阶段演进，相比之前都进一步取其精华去其糟粕。能够说 ClickHouse 吸取了各家技术的精华，将每一个细节都做到了极致。接下来将介绍 ClickHouse 的一些外围个性，正是这些个性造成的合力使得 ClickHouse 如此优良。
1. 齐备的 DBMS 性能
ClickHouse 领有齐备的治理性能，所以它称得上是一个 DBMS (Database Management System，数据库管理系统)，而不仅是一个数据库。作为一个 DBMS，它具备了一些基本功能，如下所示。
- DDL (数据定义语言)：能够动静地创立、批改或删除数据库、表和视图，而无须重启服务。
- DML (数据操作语言)：能够动静查问、插入、批改或删除数据。
- 权限管制：能够依照用户粒度设置数据库或者表的操作权限，保障数据的安全性。
- 数据备份与复原：提供了数据备份导出与导入复原机制，满足生产环境的要求。
- 分布式治理：提供集群模式，可能主动治理多个数据库节点。
这里只列举了一些最具代表性的性能，但未然足以表明为什么 Click House 称得上是 DBMS 了。
2. 列式存储与数据压缩
列式存储和数据压缩，对于一款高性能数据库来说是必不可少的个性。一个十分风行的观点认为，如果你想让查问变得更快，最简略且无效的办法是缩小数据扫描范畴和数据传输时的大小，而列式存储和数据压缩就能够帮忙咱们实现上述两点。列式存储和数据压缩通常是伴生的，因为一般来说列式存储是数据压缩的前提。
按列存储与按行存储相比，前者能够无效缩小查问时所需扫描的数据量，这一点能够用一个示例简略阐明。假如一张数据表 A 领有 50 个字段 A1～A50，以及 100 行数据。当初须要查问前 5 个字段并进行数据分析，则能够用如下 SQL 实现：
SELECT A1，A2，A3，A4，A5 FROM A如果数据按行存储，数据库首先会逐行扫描，并获取每行数据的所有 50 个字段，再从每一行数据中返回 A1～A5 这 5 个字段。不难发现，只管只须要后面的 5 个字段，但因为数据是按行进行组织的，实际上还是扫描了所有的字段。如果数据按列存储，就不会产生这样的问题。因为数据按列组织，数据库能够间接获取 A1～A5 这 5 列的数据，从而防止了多余的数据扫描。
按列存储相比按行存储的另一个劣势是对数据压缩的敌对性。同样能够用一个示例简略阐明压缩的实质是什么。假如有两个字符串 abcdefghi 和 bcdefghi，当初对它们进行压缩，如下所示：
压缩前：abcdefghi_bcdefghi
压缩后：abcdefghi_(9,8)能够看到，压缩的实质是依照肯定步长对数据进行匹配扫描，当发现重复部分的时候就进行编码转换。例如上述示例中的 (9，8)，示意如果从下划线开始向前挪动 9 个字节，会匹配到 8 个字节长度的反复项，即这里的 bcdefghi。
实在的压缩算法天然比这个示例更为简单，但压缩的本质就是如此。数据中的反复项越多，则压缩率越高；压缩率越高，则数据体量越小；而数据体量越小，则数据在网络中的传输越快，对网络带宽和磁盘 IO 的压力也就越小。既然如此，那怎么的数据最可能具备反复的个性呢？答案是属于同一个列字段的数据，因为它们领有雷同的数据类型和事实语义，反复项的可能性天然就更高。
ClickHouse 就是一款应用列式存储的数据库，数据按列进行组织，属于同一列的数据会被保留在一起，列与列之间也会由不同的文件别离保留 (这里次要指 MergeTree 表引擎)。数据默认应用 LZ4 算法压缩，在 Yandex.Metrica 的生产环境中，数据总体的压缩比能够达到 8:1 (未压缩前 17PB，压缩后 2PB)。列式存储除了升高 IO 和存储的压力之外，还为向量化执行做好了铺垫。
3. 向量化执行引擎
坊间有句玩笑，即 ” 能用钱解决的问题，千万别花工夫 ”。而业界也有种调侃一模一样，即 ” 能降级硬件解决的问题，千万别优化程序 ”。有时候，你含辛茹苦优化程序逻辑带来的性能晋升，还不如间接降级硬件来得简略间接。这尽管只是一句玩笑不能当真，但硬件层面的优化的确是最间接、最高效的晋升路径之一。向量化执行就是这种形式的典型代表，这项寄存器硬件层面的个性，为下层应用程序的性能带来了指数级的晋升。
向量化执行，能够简略地看作一项打消程序中循环的优化。这里用一个形象的例子比喻。小胡经营了一家果汁店，尽管店里的鲜榨苹果汁深受大家青睐，但客户总是埋怨制作果汁的速度太慢。小胡的店里只有一台榨汁机，每次他都会从篮子里拿出一个苹果，放到榨汁机内期待出汁。如果有 8 个客户，每个客户都点了一杯苹果汁，那么小胡须要反复循环 8 次上述的榨汁流程，能力榨出 8 杯苹果汁。如果制作一杯果汁须要 5 分钟，那么全副制作结束则须要 40 分钟。为了晋升果汁的制作速度，小胡想出了一个方法。他将榨汁机的数量从 1 台减少到了 8 台，这么一来，他就能够从篮子里一次性拿出 8 个苹果，别离放入 8 台榨汁机同时榨汁。此时，小胡只须要 5 分钟就可能制作出 8 杯苹果汁。为了制作 n 杯果汁，非向量化执行的形式是用 1 台榨汁机反复循环制作 n 次，而向量化执行的形式是用 n 台榨汁机只执行 1 次。
为了实现向量化执行，须要利用 CPU 的 SIMD 指令。SIMD 的全称是 Single Instruction Multiple Data，即用单条指令操作多条数据。古代计算机系统概念中，它是通过数据并行以进步性能的一种实现形式 (其余的还有指令级并行和线程级并行)，它的原理是在 CPU 寄存器层面实现数据的并行操作。
在计算机系统的体系结构中，存储系统是一种层次结构。典型服务器计算机的存储层次结构如图 1 所示。一个实用的教训通知咱们，存储媒介间隔 CPU 越近，则拜访数据的速度越快。
从上图中能够看到，从左向右，间隔 CPU 越远，则数据的访问速度越慢。从寄存器中拜访数据的速度，是从内存拜访数据速度的 300 倍，是从磁盘中拜访数据速度的 3000 万倍。所以利用 CPU 向量化执行的个性，对于程序的性能晋升意义不凡。
ClickHouse 目前利用 SSE4.2 指令集实现向量化执行。
4. 关系模型与 SQL 查问
相比 HBase 和 Redis 这类 NoSQL 数据库，ClickHouse 应用关系模型形容数据并提供了传统数据库的概念 (数据库、表、视图和函数等)。与此同时，ClickHouse 齐全应用 SQL 作为查询语言 (反对 GROUP BY、ORDER BY、JOIN、IN 等大部分规范 SQL)，这使得它平易近人，容易了解和学习。因为关系型数据库和 SQL 语言，能够说是软件畛域倒退至今利用最为宽泛的技术之一，领有极高的 ” 大众根底 ”。也正因为 ClickHouse 提供了标准协议的 SQL 查问接口，使得现有的第三方剖析可视化零碎能够轻松与它集成对接。在 SQL 解析方面，ClickHouse 是大小写敏感的，这意味着 SELECT a 和 SELECT A 所代表的语义是不同的。
关系模型相比文档和键值对等其余模型，领有更好的形容能力，也可能更加清晰地表述实体间的关系。更重要的是，在 OLAP 畛域，已有的大量数据建模工作都是基于关系模型开展的 (星型模型、雪花模型乃至宽表模型)。ClickHouse 应用了关系模型，所以将构建在传统关系型数据库或数据仓库之上的零碎迁徙到 ClickHouse 的老本会变得更低，能够间接沿用之前的教训成绩。
5. 多样化的表引擎
兴许因为 Yandex.Metrica 的最后架构是基于 MySQL 实现的，所以在 ClickHouse 的设计中，可能察觉到一些 MySQL 的影子，表引擎的设计就是其中之一。与 MySQL 相似，ClickHouse 也将存储局部进行了形象，把存储引擎作为一层独立的接口。截至本书完稿时，ClickHouse 共领有合并树、内存、文件、接口和其余 6 大类 20 多种表引擎。其中每一种表引擎都有着各自的特点，用户能够依据理论业务场景的要求，抉择适合的表引擎应用。
通常而言，一个通用零碎意味着更宽泛的适用性，可能适应更多的场景。但通用的另一种解释是平庸，因为它无奈在所有场景内都做到极致。
在软件的世界中，并不会存在一个可能实用任何场景的通用零碎，为了突出某项个性，势必会在别处有所取舍。其实世间万物都遵循着这样的情理，就像信天翁和蜂鸟，尽管都属于鸟类，但它们各自的特点却铸就了齐全不同的体貌特征。信天翁善于远距离航行，盘绕地球一周只须要 1 至 2 个月的工夫。因为它可能长时间处于滑行状态，5 蠢才须要扇动一次翅膀，心率可能放弃在每分钟 100 至 200 次之间。而蜂鸟可能垂直悬停航行，每秒能够挥动翅膀 70～100 次，航行时的心率可能达到每分钟 1000 次。如果用数据库的场景类比信天翁和蜂鸟的特点，那么信天翁代表的可能是应用一般硬件就能实现高性能的设计思路，数据按粗粒度解决，通过批处理的形式执行；而蜂鸟代表的可能是按细粒度解决数据的设计思路，须要高性能硬件的反对。
将表引擎独立设计的益处是不言而喻的，通过特定的表引擎撑持特定的场景，非常灵便。对于简略的场景，可间接应用简略的引擎降低成本，而简单的场景也有适合的抉择。
6. 多线程与分布式
ClickHouse 简直具备现代化高性能数据库的所有典型特色，对于能够晋升性能的伎俩堪称是一一用尽，对于多线程和分布式这类被宽泛应用的技术，天然更是不在话下。
如果说向量化执行是通过数据级并行的形式晋升了性能，那么多线程解决就是通过线程级并行的形式实现了性能的晋升。相比基于底层硬件实现的向量化执行 SIMD，线程级并行通常由更高层次的软件层面管制。古代计算机系统早已遍及了多处理器架构，所以现今市面上的服务器都具备良好的多外围多线程解决能力。因为 SIMD 不适宜用于带有较多分支判断的场景，ClickHouse 也大量应用了多线程技术以实现提速，以此和向量化执行造成互补。
如果一个篮子装不下所有的鸡蛋，那么就多用几个篮子来装，这就是分布式设计中分而治之的根本思维。同理，如果一台服务器性能吃紧，那么就利用多台服务的资源协同解决。为了实现这一指标，首先须要在数据层面实现数据的分布式。因为在分布式畛域，存在一条清规戒律—计算挪动比数据挪动更加划算。在各服务器之间，通过网络传输数据的老本是昂扬的，所以相比挪动数据，更为聪慧的做法是事后将数据分布到各台服务器，将数据的计算查问间接下推到数据所在的服务器。ClickHouse 在数据存取方面，既反对分区 (纵向扩大，利用多线程原理)，也反对分片 (横向扩大，利用分布式原理)，能够说是将多线程和分布式的技术利用到了极致。
7. 多主架构
HDFS、Spark、HBase 和 Elasticsearch 这类分布式系统，都采纳了 Master-Slave 主从架构，由一个管控节点作为 Leader 兼顾全局。而 ClickHouse 则采纳 Multi-Master 多主架构，集群中的每个节点角色对等，客户端拜访任意一个节点都能失去雷同的成果。这种多主的架构有许多劣势，例如对等的角色使零碎架构变得更加简略，不必再辨别主控节点、数据节点和计算节点，集群中的所有节点性能雷同。所以它人造躲避了单点故障的问题，非常适合用于多数据中心、异地多活的场景。
8. 在线查问
ClickHouse 常常会被拿来与其余的剖析型数据库作比照，比方 Vertica、SparkSQL、Hive 和 Elasticsearch 等，它与这些数据库的确存在许多相似之处。例如，它们都能够撑持海量数据的查问场景，都领有分布式架构，都反对列存、数据分片、计算下推等个性。这其实也侧面阐明了 ClickHouse 在设计上的确汲取了各路奇技淫巧。与其余数据库相比，ClickHouse 也领有显著的劣势。例如，Vertica 这类商用软件价格昂扬；SparkSQL 与 Hive 这类零碎无奈保障 90% 的查问在 1 秒内返回，在大数据量下的简单查问可能会须要分钟级的响应工夫；而 Elasticsearch 这类搜索引擎在解决亿级数据聚合查问时则显得顾此失彼。
正如 ClickHouse 的 ” 广告词 ” 所言，其余的开源零碎太慢，商用的零碎太贵，只有 Clickouse 在老本与性能之间做到了良好均衡，即又快又开源。ClickHouse 当之无愧地阐释了 ” 在线 ” 二字的含意，即使是在简单查问的场景下，它也可能做到极快响应，且毋庸对数据进行任何预处理加工。
9. 数据分片与分布式查问
数据分片是将数据进行横向切分，这是一种在面对海量数据的场景下，解决存储和查问瓶颈的无效伎俩，是一种分治思维的体现。ClickHouse 反对分片，而分片则依赖集群。每个集群由 1 到多个分片组成，而每个分片则对应了 ClickHouse 的 1 个服务节点。分片的数量下限取决于节点数量 (1 个分片只能对应 1 个服务节点)。
ClickHouse 并不像其余分布式系统那样，领有高度自动化的分片性能。ClickHouse 提供了本地表 (Local Table) 与分布式表 (Distributed Table) 的概念。一张本地表等同于一份数据的分片。而分布式表自身不存储任何数据，它是本地表的拜访代理，其作用相似分库中间件。借助分布式表，可能代理拜访多个数据分片，从而实现分布式查问。
这种设计相似数据库的分库和分表，非常灵便。例如在业务零碎上线的初期，数据体量并不高，此时数据表并不需要多个分片。所以应用单个节点的本地表 (单个数据分片) 即可满足业务需要，待到业务增长、数据量增大的时候，再通过新增数据分片的形式分流数据，并通过分布式表实现分布式查问。这就好比一辆手动挡赛车，它将所有的选择权都交到了使用者的手中。
ClickHouse 的架构设计
目前 ClickHouse 公开的材料绝对匮乏，比方在架构设计层面就很难找到残缺的材料，甚至连一张整体的架构图都没有。我想这就是它为何身为一款开源软件，但又显得如此神秘的起因之一吧。即便如此，咱们还是能从一些零散的资料中找到一些蛛丝马迹。接下来会阐明 ClickHouse 底层设计中的一些概念，这些概念能够帮忙咱们理解 ClickHouse。
1.Column 与 Field
Column 和 Field 是 ClickHouse 数据最根底的映射单元。作为一款百分之百的列式存储数据库，ClickHouse 按列存储数据，内存中的一列数据由一个 Column 对象示意。Column 对象分为接口和实现两个局部，在 IColumn 接口对象中，定义了对数据进行各种关系运算的办法，例如插入数据的 insertRangeFrom 和 insertFrom 办法、用于分页的 cut，以及用于过滤的 filter 办法等。而这些办法的具体实现对象则依据数据类型的不同，由相应的对象实现，例如 ColumnString、ColumnArray 和 ColumnTuple 等。在大多数场合，ClickHouse 都会以整列的形式操作数据，但凡事也有例外。如果须要操作单个具体的数值 (也就是单列中的一行数据)，则须要应用 Field 对象，Field 对象代表一个单值。与 Column 对象的泛化设计思路不同，Field 对象应用了聚合的设计模式。在 Field 对象外部聚合了 Null、UInt64、String 和 Array 等 13 种数据类型及相应的解决逻辑。
2.DataType
数据的序列化和反序列化工作由 DataType 负责。IDataType 接口定义了许多正反序列化的办法，它们成对呈现，例如 serializeBinary 和 deserializeBinary、serializeTextJSON 和 deserializeTextJSON 等，涵盖了罕用的二进制、文本、JSON、XML、CSV 和 Protobuf 等多种格局类型。IDataType 也应用了泛化的设计模式，具体方法的实现逻辑由对应数据类型的实例承载，例如 DataTypeString、DataTypeArray 及 DataTypeTuple 等。
DataType 尽管负责序列化相干工作，但它并不间接负责数据的读取，而是转由从 Column 或 Field 对象获取。在 DataType 的实现类中，聚合了相应数据类型的 Column 对象和 Field 对象。例如，DataTypeString 会援用字符串类型的 ColumnString，而 DataTypeArray 则会援用数组类型的 ColumnArray，以此类推。
3.Block 与 Block 流
ClickHouse 外部的数据操作是面向 Block 对象进行的，并且采纳了流的模式。尽管 Column 和 Filed 组成了数据的根本映射单元，但对应到实际操作，它们还短少了一些必要的信息，比方数据的类型及列的名称。于是 ClickHouse 设计了 Block 对象，Block 对象能够看作数据表的子集。Block 对象的实质是由数据对象、数据类型和列名称组成的三元组，即 Column、DataType 及列名称字符串。Column 提供了数据的读取能力，而 DataType 晓得如何正反序列化，所以 Block 在这些对象的根底之上实现了进一步的形象和封装，从而简化了整个应用的过程，仅通过 Block 对象就能实现一系列的数据操作。在具体的实现过程中，Block 并没有间接聚合 Column 和 DataType 对象，而是通过 ColumnWithTypeAndName 对象进行间接援用。
有了 Block 对象这一层封装之后，对 Block 流的设计就是瓜熟蒂落的事件了。流操作有两组顶层接口：IBlockInputStream 负责数据的读取和关系运算，IBlockOutputStream 负责将数据输入到下一环节。Block 流也应用了泛化的设计模式，对数据的各种操作最终都会转换成其中一种流的实现。IBlockInputStream 接口定义了读取数据的若干个 read 虚办法，而具体的实现逻辑则交由它的实现类来填充。
IBlockInputStream 接口总共有 60 多个实现类，它们涵盖了 ClickHouse 数据摄取的方方面面。这些实现类大抵能够分为三类：第一类用于解决数据定义的 DDL 操作，例如 DDLQueryStatusInputStream 等；第二类用于解决关系运算的相干操作，例如 LimitBlockInput-Stream、JoinBlockInputStream 及 AggregatingBlockInputStream 等；第三类则是与表引擎响应，每一种表引擎都领有与之对应的 BlockInputStream 实现，例如 MergeTreeBaseSelect-BlockInputStream (MergeTree 表引擎)、TinyLogBlockInputStream (TinyLog 表引擎) 及 KafkaBlockInputStream (Kafka 表引擎) 等。
IBlockOutputStream 的设计与 IBlockInputStream 一模一样。IBlockOutputStream 接口同样也定义了若干写入数据的 write 虚办法。它的实现类比 IBlockInputStream 要少许多，一共只有 20 多种。这些实现类根本用于表引擎的相干解决，负责将数据写入下一环节或者最终目的地，例如 MergeTreeBlockOutputStream、TinyLogBlockOutputStream 及 StorageFileBlock-OutputStream 等。
4.Table
在数据表的底层设计中并没有所谓的 Table 对象，它间接应用 IStorage 接口指代数据表。表引擎是 ClickHouse 的一个显著个性，不同的表引擎由不同的子类实现，例如 IStorageSystemOneBlock (零碎表)、StorageMergeTree (合并树表引擎) 和 StorageTinyLog (日志表引擎) 等。IStorage 接口定义了 DDL (如 ALTER、RENAME、OPTIMIZE 和 DROP 等)、read 和 write 办法，它们别离负责数据的定义、查问与写入。在数据查问时，IStorage 负责依据 AST 查问语句的批示要求，返回指定列的原始数据。后续对数据的进一步加工、计算和过滤，则会对立交由 Interpreter 解释器对象解决。对 Table 发动的一次操作通常都会经验这样的过程，接管 AST 查问语句，依据 AST 返回指定列的数据，之后再将数据交由 Interpreter 做进一步解决。
5.Parser 与 Interpreter
Parser 和 Interpreter 是十分重要的两组接口：Parser 分析器负责创立 AST 对象；而 Interpreter 解释器则负责解释 AST，并进一步创立查问的执行管道。它们与 IStorage 一起，串联起了整个数据查问的过程。Parser 分析器能够将一条 SQL 语句以递归降落的办法解析成 AST 语法树的模式。不同的 SQL 语句，会经由不同的 Parser 实现类解析。例如，有负责解析 DDL 查问语句的 ParserRenameQuery、ParserDropQuery 和 ParserAlterQuery 解析器，也有负责解析 INSERT 语句的 ParserInsertQuery 解析器，还有负责 SELECT 语句的 ParserSelectQuery 等。
Interpreter 解释器的作用就像 Service 服务层一样，起到串联整个查问过程的作用，它会依据解释器的类型，聚合它所须要的资源。首先它会解析 AST 对象；而后执行 ” 业务逻辑 ” (例如分支判断、设置参数、调用接口等)；最终返回 IBlock 对象，以线程的模式建设起一个查问执行管道。
6.Functions 与 Aggregate Functions
ClickHouse 次要提供两类函数—一般函数和聚合函数。一般函数由 IFunction 接口定义，领有数十种函数实现，例如 FunctionFormatDateTime、FunctionSubstring 等。除了一些常见的函数 (诸如四则运算、日期转换等) 之外，也不乏一些十分实用的函数，例如网址提取函数、IP 地址脱敏函数等。一般函数是没有状态的，函数成果作用于每行数据之上。当然，在函数具体执行的过程中，并不会一行一行地运算，而是采纳向量化的形式间接作用于一整列数据。
聚合函数由 IAggregateFunction 接口定义，相比无状态的一般函数，聚合函数是有状态的。以 COUNT 聚合函数为例，其 AggregateFunctionCount 的状态应用整型 UInt64 记录。聚合函数的状态反对序列化与反序列化，所以可能在分布式节点之间进行传输，以实现增量计算。
7.Cluster 与 Replication
ClickHouse 的集群由分片 (Shard) 组成，而每个分片又通过正本 (Replica) 组成。这种分层的概念，在一些风行的分布式系统中非常广泛。例如，在 Elasticsearch 的概念中，一个索引由分片和正本组成，正本能够看作一种非凡的分片。如果一个索引由 5 个分片组成，正本的基数是 1，那么这个索引一共会领有 10 个分片 (每 1 个分片对应 1 个正本)。
如果你用同样的思路来了解 ClickHouse 的分片，那么很可能会在这里栽个跟头。ClickHouse 的某些设计总是显得自成一家，而集群与分片就是其中之一。这里有几个不同凡响的个性。
- ClickHouse 的 1 个节点只能领有 1 个分片，也就是说如果要实现 1 分片、1 正本，则至多须要部署 2 个服务节点。
- 分片只是一个逻辑概念，其物理承载还是由正本承当的。
代码清单 1 所示是 ClickHouse 的一份集群配置示例，从字面含意了解这份配置的语义，能够了解为自定义集群 ch_cluster 领有 1 个 shard (分片) 和 1 个 replica (正本)，且该正本由 10.37.129.6 服务节点承载。
从实质上看，这组 1 分片、1 正本的配置在 ClickHouse 中只有 1 个物理正本，所以它正确的语义应该是 1 分片、0 正本。分片更像是逻辑层的分组，在物理存储层面则对立应用正本代表分片和正本。所以真正示意 1 分片、1 正本语义的配置，应该改为 1 个分片和 2 个正本，如代码清单 2 所示。
ClickHouse 为何如此之快
很多用户心中始终会有这样的疑难，为什么 ClickHouse 这么快？后面的介绍对这个问题曾经做出了科学合理的解释。比方说，因为 ClickHouse 是列式存储数据库，所以快；也因为 ClickHouse 应用了向量化引擎，所以快。这些解释都站得住脚，然而仍然不能打消全副的疑难。因为这些技术并不是机密，世面上有很多数据库同样应用了这些技术，然而仍然没有 ClickHouse 这么快。所以我想从另外一个角度来探讨一番 ClickHouse 的秘诀到底是什么。
首先向各位读者抛出一个疑难：在设计软件架构的时候，做设计的准则应该是自顶向下地去设计，还是应该自下而上地去设计呢？在传统观念中，或者说在我的观点中，天然是自顶向下的设计，通常咱们都被教诲要做好顶层设计。而 ClickHouse 的设计则采纳了自下而上的形式。ClickHouse 的原型零碎早在 2008 年就诞生了，在诞生之初它并没有雄伟的布局。相同它的目标很单纯，就是心愿能以最快的速度进行 GROUP BY 查问和过滤。他们是如何实际自下而上设计的呢？
1. 着眼硬件，先想后做
首先从硬件性能层面着手设计，在设计伊始就至多须要想分明如下几个问题。
- 咱们将要应用的硬件程度是怎么的？包含 CPU、内存、硬盘、网络等。
- 在这样的硬件上，咱们须要达到怎么的性能？包含提早、吞吐量等。
- 咱们筹备应用怎么的数据结构？包含 String、HashTable、Vector 等。
- 抉择的这些数据结构，在咱们的硬件上会如何工作？
如果能想分明下面这些问题，那么在入手实现性能之前，就曾经可能计算出粗略的性能了。所以，基于将硬件效用最大化的目标，ClickHouse 会在内存中进行 GROUP BY，并且应用 HashTable 装载数据。与此同时，他们十分在意 CPU L3 级别的缓存，因为一次 L3 的缓存生效会带来 70～100ns 的提早。这意味着在单核 CPU 上，它会节约 4000 万次 / 秒的运算；而在一个 32 线程的 CPU 上，则可能会节约 5 亿次 / 秒的运算。所以别小看这些细节，一点一滴地将它们累加起来，数据是十分可观的。正因为留神了这些细节，所以 ClickHouse 在基准查问中能做到 1.75 亿次 / 秒的数据扫描性能。
2. 算法在前，形象在后
常有人念叨：” 有时候，抉择比致力更重要。” 的确，路线选错了再致力也是白搭。在 ClickHouse 的底层实现中，常常会面对一些反复的场景，例如字符串子串查问、数组排序、应用 HashTable 等。如何能力实现性能的最大化呢？算法的抉择是重中之重。以字符串为例，有一本专门解说字符串搜寻的书，名为 ”Handbook of Exact String Matching Algorithms”，列举了 35 种常见的字符串搜索算法。各位猜一猜 ClickHouse 应用了其中的哪一种？答案是一种都没有。这是为什么呢？因为性能不够快。在字符串搜寻方面，针对不同的场景，ClickHouse 最终抉择了这些算法：对于常量，应用 Volnitsky 算法；对于十分量，应用 CPU 的向量化执行 SIMD，暴力优化；正则匹配应用 re2 和 hyperscan 算法。性能是算法抉择的首要考量指标。
3. 敢于尝鲜，不行就换
除了字符串之外，其余的场景也与它相似，ClickHouse 会应用最合适、最快的算法。如果世面上呈现了号称性能弱小的新算法，ClickHouse 团队会立刻将其纳入并进行验证。如果成果不错，就保留应用；如果性能不尽人意，就将其摈弃。
4. 特定场景，非凡优化
针对同一个场景的不同情况，抉择应用不同的实现形式，尽可能将性能最大化。对于这一点，其实在后面介绍字符串查问时，针对不同场景抉择不同算法的思路就有体现了。相似的例子还有很多，例如去重计数 uniqCombined 函数，会依据数据量的不同抉择不同的算法：当数据量较小的时候，会抉择 Array 保留；当数据量中等的时候，会抉择 HashSet；而当数据量很大的时候，则应用 HyperLogLog 算法。
对于数据结构比拟清晰的场景，会通过代码生成技术实现循环展开，以缩小循环次数。接着就是大家熟知的大杀器—向量化执行了。SIMD 被宽泛地利用于文本转换、数据过滤、数据解压和 JSON 转换等场景。相较于单纯地应用 CPU，利用寄存器暴力优化也算是一种降维打击了。
5. 继续测试，继续改良
如果只是单纯地在上述细节上下功夫，还不足以构建出如此弱小的 ClickHouse，还须要领有一个可能继续验证、继续改良的机制。因为 Yandex 的人造劣势，ClickHouse 常常会应用实在的数据进行测试，这一点很好地保障了测试场景的真实性。与此同时，ClickHouse 也是我见过的发版速度最快的开源软件了，差不多每个月都能公布一个版本。没有一个牢靠的继续集成环境，这一点是做不到的。正因为领有这样的发版频率，ClickHouse 才可能疾速迭代、疾速改良。
所以 ClickHouse 的黑魔法并不是一项繁多的技术，而是一种自底向上的、谋求极致性能的设计思路。这就是它如此之快的秘诀。
小结
本文咱们疾速浏览了世界第三大 Web 流量剖析平台 Yandex.Metrica 背地的支柱 ClickHouse 的外围个性和逻辑架构。通过对外围个性局部的展现，ClickHouse 如此强悍的原因已初见端倪，列式存储、向量化执行引擎和表引擎都是它的撒手锏。
在架构设计局部，则进一步展现了 ClickHouse 的一些设计思路，例如 Column、Field、Block 和 Cluster。理解这些设计思路，可能帮忙咱们更好地了解和应用 ClickHouse。最初又从另外一个角度探讨了 ClickHouse 如此之快的秘诀。
作者：朱凯 文章来源不明，本文只作分享用处，版权归原作者所有，如有版权问题请分割小编解决，谢谢。
