随着业务的增长，ClickHouse 已经为 Yandex.Metrica 存储了超过二十万亿行数据，90% 的自定义查询都能在 1 秒内响应结果，集群规模也超过了 400 台服务器。
ClickHouse 的核心特性
ClickHouse 是一款 MPP 架构的列式数据库，但 MPP 和列式存储并不是什么新鲜玩意，为什么只有 ClickHouse 的性能如此出众？通过前面的介绍，我们知道ClickHouse 发展至今的演进过程。一共经历了四个阶段，每一个阶段的迭代都是取其精华去其糟粕。可以说 ClickHouse 吸收了个各种技术的精髓，下面了解一下 ClickHouse 数据库的一些和新特性，正是这些特性使得 ClickHouse 如此有优秀。
完整的 DBMS 功能
ClickHouse 具备完整的管理功能，所以称得上 DBMS (Datbase Management System，数据库管理系统)，不仅仅是一个数据库，作为一个 DBMS，还具备以下功能（仅为代表性功能，并非全部功能）：
- DDL (数据库定义语言)：动态的创建、修改或删除数据库、表或视图。
- DML (数据操作语言)：查询、插入、修改、删除记录。
- 权限控制：按照用户粒度设置数据库或者表的操作权限，保障数据安全。
- 数据备份与恢复：提供数据库备份与导入导出恢复机制，满足生产环境需求。
- 分部署管理：提供集群模式，能够自动管理多个数据库节点。
列式存储和数据压缩
列式存储和数据压缩，对于一款高性能数据库来说一个必不可少的特性。如果你想让查询变得更快，最简单有效的方法是减少数据扫描范围和数据传输时的大小，而列式存储可以帮助我们实现上述两点。列式存储和数据压缩通常是相伴而生的，一般来说列式存储是数据压缩的前提。
列式存储相比行式存储，可以减少查询时所需扫描的数据量。例如一个用户表有 50 个字段，查询前 5 个字段，因为是行式存储，所以逐行扫描时实际会获取所有的字段，然后返回前五个。这样就意味着需要扫描磁盘更多空间，然后不返回这些数据。如果是按列获取数据，就不会存在这样的问题，直接扫描并返回前五列数据即可，避免了多余的数据扫描。
按照列式存储相比按行式存储另一个优势就是对数据压缩的友好性。ClickHouse 的数据按列进行组织，属于同一列的数据会被保存在一起，而压缩的本质就是如此，同一列的数据类型和语义相同，数据具有更高比例的重复性，对应的压缩比也会也大。数据默认采用LZ4 压缩算法，在 Yandex.Metrica 的生产环境中，数据总体的压缩比可以达到 8:1 (由 17PB 压缩至 2PB)。列式存储除了降低 IO 和存储的压力之外，还为向量化执行做好了铺垫。
HBase，BigTable 这些系统也能实现列式存储，但无法有效处理分析查询需求。在这些系统中，每秒可以实现数十万的数据吞吐量，但不会达到数亿行的级别。
向量化执行引擎
向量化执行是 CPU 寄存器硬件层面的特性，为上层应用带来指数级的提升。
向量化执行可以看作是一项消除程序中循环结果的优化。为了实现向量化执行，需要利用 CPU 的 SIMD 指令（全称是 ingle Instruction Multiple Data 即 单条指令操作多条数据）。它是通过数据并行以提高性能的一种实现方式，原理是在 CPU 寄存器层面实现并行操作。
具体实现原理参考：Clickhouse SIMD 使用初探 - 简书
关系模型和 SQL 查询
相比 Redis 和 HBase 这类 NoSQL 数据库，ClickHouse 使用关系模型描述数据并提供了传统数据库的概念（数据库、表、视图和函数等）。与此同时，ClickHouse 完全支持使用 SQL 作为查询语言，兼容大多数标准 SQL 。也正因为 ClickHouse 提供标准协议的 SQL 查询接口，是的现有的第三方系统可以轻松与它对接。在 SQL 解析方面，ClickHouse 是大小写敏感的。
关系模型相比文档或键值对等其他模型，拥有更好的描述能力，也能够更加清晰的表述实体之间的关系。更重要的是，在 OLAP 领域，已有的大量数据建模工作都是基于关系模型展开的（星型模型、雪花模型或宽表模型）。ClickHouse 使用了关系模型，所以构建在传统关系型数据库或数据仓库之上的系统迁移到 ClickHouse 的成本会变得更低。
多样化的表引擎
因为 Yandex.Metrica 的最初架构是基于 MySQL 实现的，所以在 ClickHouse 的设计中，能够看到 MySQL 的影子，表引擎的设计就是其中之一。与 MySQL 类似， ClickHouse 也将存储部分进行了抽象，把存储引擎作为一层独立的接口。ClickHouse 拥有合并树、内存、文件、接口和其他 6 大类 20 多种表引擎，每个引擎都有各自的特点，用户需要根据实际的业务场景选择适合的表引擎。
在 IT 技术和发展的长河中，并不会存在能够适应任何场景的通用系统，所以将表引擎独立设计的好处显而易见，通过特定的表引擎支撑特定的场景，可以直接使用简单的引擎降低成本，而复杂的场景也有合适的选择。
多线程和分布式
如果说向量化执行是通过数据级并行的方式提升了性能，那么多线程执行就是通过线程级并行的方式实现了性能提升。相比基于底层硬件实现的向量化执行 SIMD，线程级并行通常由更高层次软件层面控制。现在市面上的服务器早已普及多处理器架构，具有良好的多核心多线程处理能力。由于 SIMD 不适用于较多的分支判断场景，所以 ClickHouse 也大量使用了多线程技术进行提速，以和向量化执行形成互补。
如果一台服务器性能吃紧，那么就要利用的多台服务器的资源协同处理。为了实现这一目标，首先要在数据层面实现数据的分布式。因为在分布式领域，有一条金科玉律：“计算移动比数据移动更划算”。在各服务器之间，使用网络传输数据的成本的高昂的，所以相比移动数据，更聪明的做法是预先将数据分布到各台服务器上，将数据的计算查询直接推送到数据所在的服务器。ClickHouse 在数据存取方面，既支持分区（纵向扩展，利用多线程原理），也支持分片（横向扩展，利用分布式原理）。
多主架构
HDFS、Spark、HBase 和 Elasticsearch 这类分布式系统，都采用了 Master - Slave 主从架构，让一个节点作为 Leader 掌控全局。而 ClickHouse 采用 Multi - Master 的多主架构，集群中的每个节点角色对等，客户端访问任意一个节点都能达到相同的结果。这种多主架构有许多优势，例如对等的角色使系统架构变的更加简单，不再区分主控节点、数据节点和计算节点，集群中所有节点的功能相同。正因如此，ClickHouse 天然规避了单点故障的问题，非常适用于多数据中心、异地多活等场景。
在线查询
ClickHouse 经常被拿来和其他的分析型数据库做对比，例如 Vertica、SparkSQL、Hive 和 Elasticsearch 等， ClickHouse 与这些数据库确实有相似之处，例如都可以支持海量数据的查询场景，都拥有分布式架构、列式存储、数据分配、计算下推等特性。这也侧面说明了 ClickHouse 在设计上确实吸取了各路的奇技淫巧。在具备这些功能的同时，ClickHouse 也拥有明显的优势。例如，Vertica 这类商业数据库价高昂；SparkSQL 与 Hive 这类系统无法保障 90% 的查询都在一秒内返回，在大数据量的情况下的复杂查询甚至需要分钟级的响应时间；而 ES 这类搜索引擎在处理过亿级别数据的聚合查询时显得捉襟见肘。
其他的开源系统太慢，商用的系统太贵，而 ClickHouse 在成本和性能之间做了完美平衡。同时 ClickHouse 当之无愧的阐释了 "在线" 二字的含义，即便是在复杂的查询场景下，也能做到极快的响应，而无需对数据进行预处理加工。
数据分片与分布式查询
数据分片是将数据横向切分，这是一种面对海量数据的场景下，解决存储和查询瓶颈的有效手段，是一种分治思想的体现。ClickHouse 支持分片，而分片依赖集群。每个集群由一个到多个分片组成，而每个分片对应了 ClickHouse 的一个服务节点。分片数量的上限取决于节点数量（一个分片只能对应一个服务节点）。
ClickHouse 并不像其他分布式系统那样，拥有高度自动化的分片功能。ClickHouse 提供了本地表（Local Table）和分布式表 （Distributed Table） 的概念。一张本地表扽沟通与一份数据的分片，而分布式表本身不存储任何数据，他只是本地表的代理访问，类似于其他分库中间件。借助分表能够代理访问多个数据分片，从而实现分布式查询。
这种设计类似于数据库的分库分表，十分灵活。比如系统上线初期，数据量不高，只需要使用单台服务器（单个数据分片）即可满足需求，等到业务增长，数据量增大时，再通过新增分布式表的方式分流数据，并通过分布式表实现分布式查询。
ClickHouse 为什么如此之快
虽然前面解释了 ClickHouse 是列式存储并且用了向量化引擎所以快，但依旧不能解释所有的疑问。因为市面上由很多数据库同样使用着这些技术，但依然没有 ClickHouse 这么快，所以我们从另一个角度探讨一下 ClickHouse 的秘诀到底是什么。
首先我们要抛出一个疑问：在设计软件架构时，做设计的原则应该是自上而下的去设计，还是自下而上的去设计呢？在传统的观念中，自然是自上而下的去设计，通常我们都被教导过要做好顶层设计。而 ClickHouse 的设计则是采用自下而上的方式。
着手硬件，先想后做
首先从硬件方面下手，需要思考如下的问题：
- 我们使用的硬件水平如何？包含 cpu、硬盘、内存、网络等。
- 在这样的硬件上，我们需要达到什么样的性能，包括吞吐、延迟等。
- 我们准备使用怎样的数据结构，包含 String、HashTable、Vector 等。
- 选择这些数据结构，在我们的硬件上会如何工作？
基于将硬件功效最大化的目的，ClickHouse 会在内存中进行 GROUP BY，并使用 HashTable 来装在数据。同时，技术团队非常在一 CPU L3 级别的缓存，因为一次 L3 级别的缓存失效将会带来 70 ~ 100ns 的延迟。意味着在单核 CPU 上会浪费 4000万次/秒的运算；在 32 线程的 CPU 上，可能会浪费 5 亿次/秒的运算。别小看这些运算细节，一点一滴的累加起来，带来的数据是非常可观的。正因为 ClickHouse 在设计之初就考虑到了这些细节，所以才能再基准查询中做到 1.75 亿次/秒的数据扫描性能。
算法在前，抽象在后
ClickHouse 在底层的实现中，经常会面对一些重复的场景，例如字符串子串查询、数组排序、使用 HashTable 等。如何才能实现性能的最大化？算法的选择才是重中之重。例如在字符串搜索方面，针对不同的场景，ClickHouse 选择了这些算法：对于常量，使用 VoInitsky 算法；对于非常量，使用 CPU 的向量化执行 SIMD，暴力优化；正则匹配使用 re2 和 hyperscan 算法。性能是算法选择的重要考量指标。
勇于尝鲜，不行就换
除了字符串之外，其他的场景也类似，ClickHouse 会使用最合适、最快的算法。如果市面上出现了性能更强大的新算法，ClickHouse 团队会立即对其进行验证。如果效果不错，就会纳入 ClickHouse 中，并替换掉现有的算法。
特定场景，特殊优化
针对同一个场景的不同状况，使用不同的实现方式，尽可能的将性能最大化。签名介绍的字符串查询，针对不同的场景选择不同的算法就是这一思路的体现。还例如去重计数 uniqCombined 函数，会根据数据量的不同选择不同的算法：当数据量较小时，会使用 Array 保存；当数据量中等时，会使用 HashSet；当数据量很大时，则会使用 HyperLogLog 算法。
对于数据结构比较清晰的场景，会通过代码生成技术展开循环，以减少循环次数。接着就是利用了向量化执行。SIMD 被更广泛的应用于文本转换、数据过滤、数据解压和 JSON 转换等场景。相较于单纯的使用CPU，利用寄存器暴力优化也算是一种降维打击了。
持续测试，持续改进
如果只是单纯在上述细节上下功夫，也不足以构建出强大的 ClickHouse，还需要拥有一个能够持续验证和改进的机制。这也是 Yandex 的天然优势，ClickHouse 经常会使用真实的数据进行测试，这一点很好的保证了测试数据的真实性，与此同时，ClickHouse 的发版节奏也是非常快的，差不多每个月都有个新版本。
小结
本篇文章分析了 ClickHouse 的核心特性，通过核心特性的部分展示，ClickHouse 如此强悍的缘由已初见端倪，列式存储、向量化引擎和表引擎都是它的杀手锏。