前言
        随着数据科技的进步，数据分析师早已不再满足于传统的T+1式报表或需要提前设置好维度与指标的OLAP查询。数据分析师更希望使用可以支持任意指标、任意维度并秒级给出反馈的大数据Ad-hoc查询系统，这对大数据技术来说是一项非常大的挑战，传统的大数据查询引擎根本无法做到这一点，最终俄罗斯Yandex公司开源的ClickHouse脱颖而出。
        ClickHouse源于俄罗斯的Yandex公司对数据聚合的实时需求，并逐步发展为面向现代CPU架构的高性能SQL数据库。与目前基于Hadoop的解决方案不同，ClickHouse尽可能减少了第三方依赖软件，以单二进制文件形式发布，能够快速完成系统部署。
        由于ClickHouse具有卓越的分析性能、极好的线性伸展和扩容性以及丰富的功能等，近些年，越来越多的企业开始将它作为实时分析引擎来使用。无论是在大数据领域还是在DevOps领域，只要涉及在线分析场景，ClickHouse都能通过它那极致的性能占有一席之地。

一、OLAP常见架构分类

        OLAP名为联机分析，又可以称为多维分析，是由关系型数据库之父埃德加•科德(Edgar Frank Codd)于1993年提出的概念。顾名思义，它指的是通过多种不同的维度审视数据，进行深层次分析。
维度可以看作观察数据的一种视角，例如人类能看到的世界是三维的，它包含长、宽、高三个维度。直接一点理解，维度就好比是一张数据表的字段，而多维分析则是基于这些字段进行聚合查询。
常见的OLAP架构大致分成三类

1.1 ROLAP(Relational OLAP关系型OLAP)1.1关系型联机分析处理

       顾名思义，它直接使用关系模型构建，数据模型常使用星型模型或者雪花模型，这是最先能够想到，也是最为直接的实现方法，因为OLAP概念在最初提出的时候，就是建立在关系型数据库之上的。多维分析的操作，可以直接转换成SQL查询。
       例如，通过上卷操作查看省份的销售额，就可以转换成类似下面的SQL语句：
SELECT SUM(价格) FROM 销售数据表GROUP BY省;

但是这种架构对数据的实时处理能力要求很高。试想一下，如果对一张存有上亿行数据的数据表同时执行数十个字段的GROUP BY查询，将会发生什么事情？

1.2 MOLAP(Multidimensional OLAP 多维型OLAP)

       它的出现是为了缓解ROLAP性能问题。MOLAP使用多维数组的形式保存数据，其核心思想是借助预先聚合结果，使用空间换取时间的形式最终提升查询性能。也就是说，用更多的存储空间换得查询时间的减少。
       其具体的实现方式是依托立方体模型的概念。首先，对需要分析的数据进行建模，框定需要分析的维度字段，然后通过预处理的形式，对各种维度进行组合并事先聚合；最后将聚合结果以某种索引或者缓存的形式保存起来(通常只保留聚合后的结果，不存储明细数据)，这样一来，在随后的查询过程中，就可以直接利用结果返回数据。
       但是这种架构也并不完美，维度预处理可能会导致数据的膨胀。以图1-1中所示的销售明细表为例，如果数据立方体包含了5个维度(字段)，那么维度组合的方式则有25(2n ，n=维度个数)个。例如，省和市两个维度的组合就有<湖北，武汉>、<湖北、宜昌>、<武汉、湖北>、<宜昌、湖北>等。
       可想而知，当维度数据基数较高的时候 (高基数意味着重复相同的数据少) ，其立方体预聚合后的数据量可能会达到10到20倍的膨胀，一张千万级别的数据表，就有可能膨胀到亿级别的体量。另外，由于使用了预处理的形式，数据立方体会有一定的滞后性，不能实时进行数据分析。而且立方体只保留了聚合后的结果数据，导致无法查询明细数据。

1.3 HOLAP(Hybrid OLAP 混合架构的OLAP)

      这种思路可以理解成ROLAP和MOLAP两者的集成。这里不再展开，我们重点关注ROLAP和MOLAP。

二、OLAP实现技术的演进

在介绍了OLAP几种主要的架构之后，再来看看它们背后技术的演进过程，我把这个演进过程简单划分成两个阶段。

2.1 传统关系型数据库阶段

在这个阶段中，OLAP主要基于以Oracle、MySQL为代表的一众关系型数据实现。
在ROLAP架构下，直接使用这些数据库作为存储与计算的载体。
在MOLAP架构下，则借助物化视图的形式实现数据立方体。
在这个时期，不论是ROLAP还是MOLAP，在数据体量大、维度数目多的情况下都存在严重的性能问题，甚至存在根本查询不出结果的情况。

2.2 大数据技术阶段

由于大数据处理技术的普及，人们开始使用大数据技术重构ROLAP和MOLAP。
以ROLAP架构为例，传统关系型数据库就被Hive和SparkSQL这类新兴技术所取代。
虽然，以Spark为代表的分布式计算系统相比Oracle这类传统数据库而言，在面向海量数据的处理性能方面已经优秀很多，但是直接把它们作为面向终端用户的在线查询系统还是太慢了。我们的用户普遍缺乏耐心，如果一个查询响应需要几十秒甚至数分钟才能返回，那么这套方案就完全行不通。
再看MOLAP架构，MOLAP背后也转为依托MapReduce或Spark这类新兴技术，将其作为立方体的计算引擎，加速立方体的构建过程，其预聚合结果的存储载体也转向HBase这类高性能分布式数据库。
大数据技术阶段，主流MOLAP架构已经能够在亿万级数据的体量下，实现毫秒级的查询响应时间。尽管如此，MOLAP架构依然存在维度爆炸、数据同步实时性不高的问题。

三、ClickHouse简述

3.1 ClickHouse的名称含义

它的初始设计目标是服务自己公司的一款名叫Yandex.Metrica的产品。Metrica是一款Web流量分析工具，基于前方探针采集行为数据，然后进行一系列的数据分析，类似数据仓库的OLAP分析。
而在采集数据的过程中，一次页面click(点击)，会产生一个event(事件)。至此，整个系统的逻辑就十分清晰了，那就是基于页面的点击事件流，面向数据仓库进行OLAP分析。
所以ClickHouse的全称是Click Stream，Data WareHouse，简称ClickHouse。

3.2 ClickHouse适用的场景

因为ClickHouse在诞生之初是为了服务Yandex自家的Web流量分析产品Yandex.Metrica，所以在存储数据超过20万亿行的情况下，ClickHouse做到了90%的查询都能够在1秒内返回的惊人之举。
随后，ClickHouse进一步被应用到Yandex内部大大小小数十个其他的分析场景中，可以说ClickHouse具备了人们对一款高性能OLAP数据库的美好向往，所以它基本能够胜任各种数据分析类的场景，并且随着数据体量的增大，它的优势也会变得越为明显。
ClickHouse非常适用于商业智能领域(也就是BI领域)，除此之外，它也能够被广泛应用于广告流量、Web、App流量、电信、金融、电子商务、信息安全、网络游戏、物联网等众多其他领域。

3.3 ClickHouse优劣势

3.3.1 优势

1. 查询速度快，可高效的使用CPU，利用多核并行处理单个查询数据，不仅仅按列存储，同时还按向量进行处理；
2. 数据压缩空间大，减少IO，也就减少数据扫描范围和数据传输时的大小，处理单查询高吞吐量每台服务器每秒最多数十亿行；
3. 索引非B树结构，不需要满足最左原则，只要过滤条件在索引列中包含即可，即使在使用的数据不在索引中，由于各种并行处理机制ClickHouse全表扫描的速度也很快；
4. 写入速度非常快，50-200M/s，对于大量的数据更新非常适用；
5. 内置数较多(例如IP转化，URL分析等，预估计算/HyperLoglog等)；
6. 作为一个 DBMS，它具备如下功能：
    DDL(数据定义语言)：可以动态地创建、修改或者删除数据库、表和视图，而无需重启服务。
    DML(数据操作语言)：可以动态地查询、插入、修改或删除数据。
    权限控制：可以按照用户粒度设置数据库或者表的操作权限，保障数据的安全性。
    数据备份与恢复：提供了数据备份导出与导入恢复机制，满足生产环境的要求。
    分布式管理：提供集群模式，能够自动管理多个数据库节点。

3.3.2 劣势

1. 不支持事务，不支持真正的删除/更新，不支持UPDATE/DELETE操作，不擅长按行删除数据(虽然支持)，不擅长根据主键按行粒度进行查询(虽然支持)
2. 不支持高并发，官方建议qps为100，可以通过修改配置文件增加连接数，但是在服务器足够好的情况下；
3. SQL满足日常使用80%以上的语法，join写法比较特殊，最新版已支持类似SQL的join，但性能不好；
4. 尽量做1000条以上批量的写入，避免逐行insert或小批量的insert，update，delete操作，因为ClickHouse底层会不断的做异步的数据合并，会影响查询性能，这个在做实时数据写入的时候要尽量避开；
5. Clickhouse快是因为采用了并行处理机制，即使一个查询，也会用服务器一半的CPU去执行，所以ClickHouse不能支持高并发的使用场景，默认单查询使用CPU核数为服务器核数的一半，安装时会自动识别服务器核数，可以通过配置文件修改该参数；
6. 聚合结果必须小于一台机器的内存大小，否则失败；

这些弱点并不能视为ClickHouse的缺点，事实上其他同类高性能的OLAP数据库同样也不擅长上述的这些方面。因为对于一款OLAP数据库而言，上述这些能力并不是重点，只能说这是为了极致查询性能所做的权衡。

四、ClickHouse架构

4.1 ClickHouse核心特性

4.1.1 完备的DBMS功能

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

4.1.2 列式存储与数据压缩

4.1.2.1 列式存储
按列存储与按行存储相比，前者可以有效减少查询时所需扫描的数据量。假设一张数据表A拥有50个字段A1～A50，以及100行数据。现在需要查询前5个字段并进行数据分析，则可以用如下SQL实现：SELECT A1，A2，A3，A4，A5 FROM A
如果数据按行存储，数据库首先会逐行扫描，并获取每行数据的所有50个字段，再从每一行数据中返回A1～A5这5个字段。
不难发现，尽管只需要前面的5个字段，但由于数据是按行进行组织的，实际上还是扫描了所有的字段。如果数据按列存储，就不会发生这样的问题。
由于数据按列组织，数据库可以直接获取A1～A5这5列的数据，从而避免了多余的数据扫描。

4.1.2.2 数据压缩

按列存储相比按行存储的另一个优势是对数据压缩的友好性。
假设有两个字符串abcdefghi和bcdefghi，现在对它们进行压缩，如下所示：
压缩前：abcdefghi_bcdefghi
压缩后：abcdefghi_(9,8)
可以看到，压缩的本质是按照一定步长对数据进行匹配扫描，当发现重复部分的时候就进行编码转换。例如上述示例中的(9,8)，表示如果从下划线开始向前移动9个字节，会匹配到8个字节长度的重复项，即这里的bcdefghi。
真实的压缩算法自然比这个示例更为复杂，但压缩的实质就是如此，数据中的重复项越多，则压缩率越高；压缩率越高，则数据体量越小；而数据体量越小，则数据在网络中的传输越快，对网络带宽和磁盘IO的压力也就越小。既然如此，那怎样的数据最可能具备重复的特性呢？答案是属于同一个列字段的数据，因为它们拥有相同的数据类型和现实语义，重复项的可能性自然就更高。
ClickHouse是一款使用列式存储的数据库，数据按列进行组织，属于同一列的数据会被保存在一起，列与列之间也会由不同的文件分别保存
数据默认使用LZ4算法压缩，在Yandex.Metrica的生产环境中，数据总体的压缩比可以达到8:1(未压缩前17PB，压缩后2PB)。
列式存储除了降低IO和存储的压力之外，还为向量化执行做好了铺垫。

4.1.3 向量化执行引擎

坊间有句玩笑，即“能用钱解决的问题，千万别花时间”。而业界也有种调侃如出一辙，即“能升级硬件解决的问题，千万别优化程序”。有时候，你千辛万苦优化程序逻辑带来的性能提升，还不如直接升级硬件来得简单直接。
这虽然只是一句玩笑不能当真，但硬件层面的优化确实是最直接、最高效的提升途径之一。向量化执行就是这种方式的典型代表，这项寄存器硬件层面的特性，为上层应用程序的性能带来了指数级的提升。
向量化执行，可以简单地看作一项消除程序中循环的优化。为了实现向量化执行，需要利用CPU的SIMD指令。SIMD的全称是Single Instruction Multiple Data，即用单条指令操作多条数据。现代计算机系统概念中，它是通过数据并行以提高性能的一种实现方式(其他的还有指令级并行和线程级并行)，它的原理是在CPU寄存器层面实现数据的并行操作。
 在计算机系统的体系结构中，存储系统是一种层次结构。典型服务器计算机的存储层次结构如图2-1所示。一个实用的经验告诉我们，存储媒介距离CPU越近，则访问数据的速度越快。

从上图中可以看到，从左向右，距离CPU越远，则数据的访问速度越慢。
从寄存器中访问数据的速度，是从内存访问数据速度的300倍，是从磁盘中访问数据速度的3000万倍，所以利用CPU向量化执行的特性，对于程序的性能提升意义非凡。
ClickHouse目前利用SSE4.2指令集实现向量化执行。

4.1.4 SQL查询与关系模型

4.1.4.1 SQL查询
相比HBase和Redis这类NoSQL数据库，ClickHouse使用关系模型描述数据并提供了传统数据库的概念(数据库、表、视图和函数等)。
与此同时，ClickHouse完全使用SQL作为查询语言(支持GROUP BY、ORDER BY、JOIN、IN等大部分标准SQL)，这使得它平易近人，容易理解和学习。
因为关系型数据库和SQL语言，可以说是软件领域发展至今应用最为广泛的技术之一，拥有极高的“群众基础”，也正因为ClickHouse提供了标准协议的SQL查询接口，使得现有的第三方分析可视化系统可以轻松与它集成对接。
在SQL解析方面，ClickHouse是大小写敏感的，这意味着SELECT a和SELECT A所代表的语义是不同的。

4.1.4.2 关系模型

关系模型相比文档和键值对等其他模型，拥有更好的描述能力，也能够更加清晰地表述实体间的关系。更重要的是，在OLAP领域，已有的大量数据建模工作都是基于关系模型展开的(星型模型、雪花模型乃至宽表模型)。
ClickHouse使用了关系模型，所以将构建在传统关系型数据库或数据仓库之上的系统迁移到ClickHouse的成本会变得更低，可以直接沿用之前的经验成果。

4.1.5 多样化的表引擎

也许因为Yandex.Metrica的最初架构是基于MySQL实现的，所以在ClickHouse的设计中，能够察觉到一些MySQL的影子，表引擎的设计就是其中之一。与MySQL类似，ClickHouse也将存储部分进行了抽象，把存储引擎作为一层独立的接口。
截至目前，ClickHouse共拥有合并树、内存、文件、接口和其他6大类20多种表引擎，其中每一种表引擎都有着各自的特点，用户可以根据实际业务场景的要求，选择合适的表引擎使用。
通常而言，一个通用系统意味着更广泛的适用性，能够适应更多的场景。但通用的另一种解释是平庸，因为它无法在所有场景内都做到极致。在软件的世界中，并不会存在一个能够适用任何场景的通用系统，为了突出某项特性，势必会在别处有所取舍。
将表引擎独立设计的好处是显而易见的，通过特定的表引擎支撑特定的场景，十分灵活。对于简单的场景，可直接使用简单的引擎降低成本，而复杂的场景也有合适的选择。

4.1.6 多线程与分布式

4.1.6.1 多线程

ClickHouse几乎具备现代化高性能数据库的所有典型特征，对于可以提升性能的手段可谓是一一用尽，对于多线程和分布式这类被广泛使用的技术，自然更是不在话下。
如果说向量化执行是通过数据级并行的方式提升了性能，那么多线程处理就是通过线程级并行的方式实现了性能的提升。相比基于底层硬件实现的向量化执行SIMD，线程级并行通常由更高层次的软件层面控制。
现代计算机系统早已普及了多处理器架构，所以现今市面上的服务器都具备良好的多核心多线程处理能力。由于SIMD不适合用于带有较多分支判断的场景，ClickHouse也大量使用了多线程技术以实现提速，以此和向量化执行形成互补。

4.1.6.2 分布式

如果一个篮子装不下所有的鸡蛋，那么就多用几个篮子来装，这就是分布式设计中分而治之的基本思想。
同理，如果一台服务器性能吃紧，那么就利用多台服务的资源协同处理。
为了实现这一目标，首先需要在数据层面实现数据的分布式。因为在分布式领域，存在一条金科玉律——计算移动比数据移动更加划算。在各服务器之间，通过网络传输数据的成本是高昂的，所以相比移动数据，更为聪明的做法是预先将数据分布到各台服务器，将数据的计算查询直接下推到数据所在的服务器。
ClickHouse在数据存取方面，既支持分区(纵向扩展，利用多线程原理)，也支持分片(横向扩展，利用分布式原理)，可以说是将多线程和分布式的技术应用到了极致。

4.1.7 多主架构

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

4.1.8 在线查询

ClickHouse经常会被拿来与其他的分析型数据库作对比，比如Vertica、SparkSQL、Hive和Elasticsearch等，它与这些数据库确实存在许多相似之处。例如，它们都可以支撑海量数据的查询场景，都拥有分布式架构，都支持列存、数据分片、计算下推等特性。这其实也侧面说明了ClickHouse在设计上确实吸取了各路技巧，与其他数据库相比，ClickHouse也拥有明显的优势，例如Vertica这类商用软件价格高昂。
SparkSQL与Hive这类系统无法保障90%的查询在1秒内返回，在大数据量下的复杂查询可能会需要分钟级的响应时间；而Elasticsearch这类搜索引擎在处理亿级数据聚合查询时则显得捉襟见肘。
正如ClickHouse的“广告词”所言，其他的开源系统太慢，商用的系统太贵，只有Clickouse在成本与性能之间做到了良好平衡，即又快又开源。
ClickHouse当之无愧地阐释了“在线”二字的含义，即便是在复杂查询的场景下，它也能够做到极快响应，且无须对数据进行任何预处理加工。

4.1.9 数据分片与分布式查询

数据分片是将数据进行横向切分，这是一种在面对海量数据的场景下，解决存储和查询瓶颈的有效手段，是一种分治思想的体现。
ClickHouse支持分片，而分片则依赖集群。每个集群由1到多个分片组成，而每个分片则对应了ClickHouse的1个服务节点。分片的数量上限取决于节点数量(1个分片只能对应1个服务节点)。
ClickHouse并不像其他分布式系统那样，拥有高度自动化的分片功能。ClickHouse提供了本地表(Local Table)与分布式表(Distributed Table)的概念。一张本地表等同于一份数据的分片，而分布式表本身不存储任何数据，它是本地表的访问代理，其作用类似分库中间件。借助分布式表，能够代理访问多个数据分片，从而实现分布式查询。
这种设计类似数据库的分库和分表，十分灵活。例如在业务系统上线的初期，数据体量并不高，此时数据表并不需要多个分片。所以使用单个节点的本地表(单个数据分片)即可满足业务需求，待到业务增长、数据量增大的时候，再通过新增数据分片的方式分流数据，并通过分布式表实现分布式查询。
这就好比一辆手动挡赛车，它将所有的选择权都交到了使用者的手中。

4.2 ClickHouse集群模式分类

当前基于ClickHouse的特性，目前部署ClickHouse集群时，主要有以下4种集群架构。

4.2.1 MergeTree + Distributed+单副本

4.2.1.1 架构说明
•写
MergeTree + Distributed的分布式架构方案，利用的是Distributed表的特性+MergeTree表的特性，数据写入集群任意节点的Distributed(分布式)表，Distributed表不存储数据，通过Distributed表将数据写入3个shard(数据实际写到本地表)，每台节点存储三分之一的数据。
写入数据可以写入分布式表，不过这样的写入方式问题很多，一般是禁止写入分布式表的；另一种是写入本地表，需要通nginx或其它Load Balance插件进行负载均衡，将数据分散写入到Node1，Node2，Node3本地表，也可以只写入其中一台，那么使用方式就是单机版的，写入性能会受到影响。
•读
用户查询的时候是从分布式表所在的节点聚合从Node1，Node2，Node3的查询结果，然后返回用户。
一般都是通过nginx或其它Load Balance插件进行负载均衡，查询某一个节点的分布式表，由CK集群内部调用其他的Node节点，进行分布式并行查询，查询性能高。

4.2.1.2 优缺点
•优点
架构简单，可以单机使用，可以分布式使用，关键在于表引擎的选择，并行的查询分布式表，性能非常棒。
不需要做数据冗余，写入性能最高且磁盘空间使用相对较少(无副本)，查询时能有效利用整体集群计算能力，相对查询数据较快。
•缺点
本地表+分布式表，分布式表如果某个节点宕机就会丢失数据，用户查询服务就会报错，如果节点磁盘损坏，那么数据将大概率丢失，无法恢复，即使恢复也会付出极大的成本。
有致命的缺陷，没有数据备份，当一台节点下线后，将导致整个集群处于不可用状态，一般不推荐使用。

总结：整体读写性能都非常好，但是存在数据丢失的较大风险，慎用。

4.2.2 MergeTree + Distributed+多副本

MergeTree+Distribute+多副本架构是在单副本架构基础上衍生而来，主要解决了4.2.1模式中的数据无备份、不安全问题。
此架构使数据安全性得到了解决，集合CLickHouse集群的复制，有了副本，3个shard各自拥有三分之一的数据，每个shard有2个副本，数据一样。
其中CK1的Shard有两副本，分别在CK1，CK2；CK2的shard也有两副本，分别在CK2，CK3；CK3的shard也是两副本，分别在CK1和CK3。

4.2.2.1 架构说明
•写
数据写入集群任意节点的Distributed表，由CK按照随机的方式对各个节点写入至少2个shard数据，如架构图，数据一共有2份，每台节点理论上保存了2/3；
•读
查询某一个节点的分布式表；由CK集群内部调用其他的Node节点，进行分布式并行查询，查询性能较高。

4.2.2.2 优缺点
•优点
数据有了副本机制，数据的安全性有了保障，每一个shard有两个副本；
数据的查询的并行度没有改变，但是因为副本的存在，shard节点数据的查询选择性多了，即使任意一台节点下线，整个集群还是能正常使用。
•缺点
如需要替换其中一台机器，由于没有数据同步机制，将导致该节点缺少历史数据，导致查询时数据可能不完整。

4.2.3 MergeTree + Distributed+节点复制

4.2.3.1 架构说明
•写
数据写入集群中任意节点中的Distribute表，有CK负责将全量数据写入各个节点中；
•读
由于相同的MergeTree表在各个节点数据都是一致的，查询性能也不错，并发查询性能和分布式集群模式差距可以忽略；

4.2.3.2 优缺点
•优点
数据有多个全量副本，数据丢失风险非常小；整体查询性能不弱；
•缺点
写入性能较差，单查询时没有充分利用分布式集群性能优势，不适合做较大规模以上的集群；当单个节点数据写入出现问题，将导致集群数据不一致；

4.2.4 ReplicatedMergeTree + Distributed

4.2.4.1 架构说明
•写
数据通过LB(可自己实现负载均衡策略)直接写入ReplicatedMergeTree表，由CK通过Zookeeper保障写入对应的副本中；
•读
查询对应的Distribute表，有CK路由至各个节点shard下的某一个副本，进行分布式查询，整体查询性能较高，且相同shard CK会进行负载查询各个副本，能有效的利用集群资源；单个查询能力较强(有 1/副本 的集群资源参与单次查询)，并发查询能力较强；
•建议
1、 需要注意：写本地表，读分布式表。
2、 结合业务及数据的特性及所需的机器的资源，合理的选择分布式表的建表的CK节点。
3、 SELECT查询并不需要借助ZooKeeper，复本并不影响SELECT的性能，查询复制表与非复
制表速度是一样的。查询分布式表时，CK的处理方式可通过设置
max_replica_delay_for_distributed_queries、fallback_to_stale_replicas_for_distributed_queries修改。
4、 集群配置里，我们用了域名，本想着方便切换，但是CK只有在启动的时候，才会做解析。那故障了怎么切换? CK有一个厉害的地方，节点变动，无需重启，会自动加载。
利用上述特性，我们先去掉一个节点的配置，再加上这个节点的配置(DNS变更后)，即可不重启就完成fail over。

4.2.4.2 优缺点
•优点
数据有副本机制，能保障数据安全；单节点下线后不影响整体集群功能；查询和写入性能都较高。

4.2.5 架构总结

•优点
1、 Chproxy会定期发送心跳检测CK节点，自动判断节点是否进行路由分发，节点掉线和上线Chproxy可以自动检测到，无需维护；
2、 负载均衡策略Chproxy内置多种常用的策略，满足需求；
3、 chproxy可以实现用户管理和限流管理，减少了客户端的开发成本，对接CK转变到对接Chproxy无需做客户端的代码调整；
4、 继承了ReplicatedMergeTree+Distributed 集群模式的全部优点；

4.3 ClickHouse分布式集群架构