分布式引擎 | ClickHouse Docs

ClickHouse集群（Cluster）

在物理构成上，ClickHouse集群是由多个ClickHouse Server实例组成的分布式数据库。这些ClickHouse Server根据购买规格的不同而可能包含1个或多个副本（Replica）、1个或多个分片（Shard）。在逻辑构成上，一个ClickHouse集群可以包含多个数据库（Database）对象。

副本配置（Edition）ClickHouse集群包含如下副本。

  • 双副本版：每个节点包含两个副本，某个副本服务不可用的时候，同一分片的另一个副本还可以继续服务。
  • 单副本版：每个节点只有1个副本，该副本服务不可用时，会导致整个集群不可用，需要等待此副本完全恢复服务状态，集群才能继续提供稳定服务。

说明

  • 双副本版的资源以及对应的购买成本都是单副本版的2倍。
  • 由于底层云盘提供高可靠保证，即便是单副本版也能确保数据不会丢失。

分片（Shard）

在超大规模海量数据处理场景下，单台服务器的存储、计算资源会成为瓶颈。为了进一步提高效率，云数据库ClickHouse将海量数据分散存储到多台服务器上，每台服务器只存储和处理海量数据的一部分，在这种架构下，每台服务器被称为一个分片（Shard）。

副本（Replica）

为了在异常情况下保证数据的安全性和服务的高可用性，云数据库ClickHouse提供了副本机制，将单台服务器的数据冗余存储在2台或多台服务器上。

表（Table）

表是数据的组织形式，由多行、多列构成。云数据库ClickHouse的表从数据分布上，可以分为本地表和分布式表两种类型。

类型

说明

区别

本地表（Local Table）

数据只会存储在当前写入的节点上，不会被分散到多台服务器上。

  • 本地表的写入和查询，受限于单台服务器的存储、计算资源，不具备横向拓展能力。
  • 分布式表的写入和查询，可以利用多台服务器的存储、计算资源，具有较好的横向拓展能力。

分布式表（Distributed Table）

本地表的集合，它将多个本地表抽象为一张统一的表，对外提供写入、查询功能。当写入分布式表时，数据会被自动分发到集合中的各个本地表中；当查询分布式表时，集合中的各个本地表都会被分别查询，并且把最终结果汇总后返回。

1.clickhouse集群配置

  • Distributed表引擎主要是用于分布式，自身不存储任何数据，数据都分散存储在某一个

分片上，能够自动路由数据至集群中的各个节点，需要和其他数据表引擎一起协同工作

  • 一张分布式表底层会对应多个分片数据表，由具体的分片表存储数据，分布式表与分片表是

一对多的关系

clickhouse的集群依赖zookeeper 因此在配置集群时需要启动zookeeper程序。

这里使用了两台主机 10.8.5.232 ens1 和10.8.5.233ens2

以下配置两台主机均需修改

1.配置metrika.xml

metrika.xml主要是用来服务于集群搭建的。它里面是关于zookeeper、shard以及replica的配置。

metrika.xml文件需要自行创建（这里创建路径为/etc/clickhouse-server/metrika.xml），每台分布式数据库服务器都需要配置下面示例：

 10.8.5.2322181  10.8.5.232900010.8.5.2339000rootspPXilAvRFBNguSm  ::/0 01ens1

2.配置config.xml

该配置文件是存在路径/etc/clickhouse-server中，需要增加以下配置

<!--这里需要注意  需要写入正确的metrika.xml路径 --> /etc/clickhouse-server/metrika.xml

3.重启clickhouse数据库

systemctl restart clickhouse-server

4.clickhouse查询集群

select * from system.clusters;

5.clickhouse集群操作

/*【选一个节点】创建好本地表后，在1个节点创建，会在其他节点都存在 cluster_2shards_1replicas 集群名字 */create table ENS3.zwt_order on cluster cluster_2shards_1replicas (id Int8,name String) engine =MergeTree order by id;/*【选一个节点】创建分布式表名 zwt_order_all，在1个节点创建，会在其他节点都存在 cluster_2shards_1replicas集群名 ENS3数据库名 zwt_order表名 */CREATE TABLE IF NOT EXISTS ENS3.zwt_order_all ON CLUSTER cluster_2shards_1replicas as ENS3.zwt_order ENGINE = Distributed(cluster_2shards_1replicas,ENS3, zwt_order,hiveHash(id)); /*【插入数据到分布式表 会根据策略存储在不同节点的本地表中】 */INSERT INTO ENS3.zwt_order_all (id,name) VALUES (14,'5'), (11,'fgd'), (12,'fdsr'); /*【任意节点查询-分布式，全部数据】*/ select * from ENS3.user_cluster;

写入数据​

向集群写数据的方法有两种：

一，自已指定要将哪些数据写入哪些服务器，并直接在每个分片上执行写入。换句话说，在分布式表上«查询»，在数据表上 INSERT。 这是最灵活的解决方案 – 你可以使用任何分片方案，对于复杂业务特性的需求，这可能是非常重要的。 这也是最佳解决方案，因为数据可以完全独立地写入不同的分片。

二，在分布式表上执行 INSERT。在这种情况下，分布式表会跨服务器分发插入数据。 为了写入分布式表，必须要配置分片键（最后一个参数）。当然，如果只有一个分片，则写操作在没有分片键的情况下也能工作，因为这种情况下分片键没有意义。

每个分片都可以在配置文件中定义权重。默认情况下，权重等于1。数据依据分片权重按比例分发到分片上。例如，如果有两个分片，第一个分片的权重是9，而第二个分片的权重是10，则发送 9 / 19 的行到第一个分片， 10 / 19 的行到第二个分片。

1、分布式表在写入的时候，是谁写入谁负责将分片发送给其他分片服务器，此实操设计中，当数据插入进某台服务器上时，该服务器负责将数据分发到其他分片服务器，如下图：

通过上图我们了解到，如果直接insert into 分布式表会造成某台节点的压力过大的问题，故官方建议通过外部分布式引擎直接写入到本地表中，分摊压力