【clickhouse踩坑记录】clusters表中分片副本的浅析

背景

对于一个数据开发，刚接手一套新的clickhouse集群，仅通过clickhouse中system表，快速了解clickhouse的架构

角度

分片副本

通过clusters表，可以很清晰的看到clickhouse集群的分片副本情况。

select * from system.clusters;

主要字段说明：
cluster： 集群的命名
shard_num： 分片的编号
shard_weight： 分片的权重
replica_num： 副本的编号
host_name： 机器的host名称
host_address： 机器的ip地址
port： clickhouse集群的端口
is_local： 是否为你当前查询本地
user： 创建用户

结果说明：

例一（一分片三副本）：

cluster	shard_num	shard_weight	replica_num	host_name	host_address	port	is_local
cluster_test	1	1	1	ck_01	xxx.xxx.xxx.xxx	9000	1
cluster_test	1	1	2	ck_02	xxx.xxx.xxx.xxx	9000	0
cluster_test	1	1	3	ck_03	xxx.xxx.xxx.xxx	9000	0

这种部署方式需要3台机器，没做分片，三个副本，可实现高可用。架构比较绕。
因为副本数为3，每次写入一条数据，都会把这条数据写入到三台机器上，所以在机器/存储有限的情况下，资源利用率并不会很高。

优点则是部署相对简单，不用去修改很多的配置文件。

例二（三分片双副本）：

cluster	shard_num	shard_weight	replica_num	host_name	host_address	port	is_local
cluster_test	1	1	1	ck_01	xxx.xxx.xxx.xxx	9000	1
cluster_test	2	1	1	ck_01	xxx.xxx.xxx.xxx	9000	1
cluster_test	3	1	1	ck_02	xxx.xxx.xxx.xxx	9000	0
cluster_test	1	1	2	ck_02	xxx.xxx.xxx.xxx	9000	0
cluster_test	2	1	2	ck_03	xxx.xxx.xxx.xxx	9000	0
cluster_test	3	1	2	ck_03	xxx.xxx.xxx.xxx	9000	0

这种部署方式需要3台机器，三个分片，两个副本，可实现高可用。
因为副本数为2，每次写入一条数据，都会把这条数据写入到其中的两台机器上，所以相比于第一架构方式，资源利用率更高。但是假设通过ck_01节点写入，数据会存到分片1与分片2中，如果你连接ck_02进行查询本地表，是查不到写入分片2的数据。如何解决这个问题呢？目前博主想到的解决方案是在本地表上面再建一个分布式表。

例三（三分片双副本）：

cluster	shard_num	shard_weight	replica_num	host_name	host_address	port	is_local
cluster_test	1	1	1	ck_01	xxx.xxx.xxx.xxx	9000	1
cluster_test	1	1	2	ck_02	xxx.xxx.xxx.xxx	9000	0
cluster_test	2	1	1	ck_03	xxx.xxx.xxx.xxx	9000	0
cluster_test	2	1	2	ck_04	xxx.xxx.xxx.xxx	9000	0
cluster_test	3	1	1	ck_05	xxx.xxx.xxx.xxx	9000	0
cluster_test	3	1	2	ck_06	xxx.xxx.xxx.xxx	9000	0

这种部署方式需要6台机器，三个分片，两个副本，可实现高可用。架构相对较清晰。
因为副本数为2，每次写入一条数据，都会把这条数据写入到其中的两台机器上，其他四台机器上没有此数据。 假设通过ck_01节点写入，数据仅会在ck_01跟ck_02两个节点，如果链接ck_03的数据库，此时是查不到任何数据的。

存储大小

select * from system.disks;

主要字段说明：
name： 磁盘名称
path： 数据对应在相应磁盘的路径
free_space： 可用存储大小
total_space： 总存储大小

另外，还可通过下面查看对应的存储策略，因为考虑到集群的扩展性，一些表可以指定存储策略存到指定磁盘下

select * from system.storage_policies;

主要字段说明：
policy_name： 存储策略名称
volume_name： 卷名称
disks： 对应磁盘名称

总结

通过clusters表，可以让我们快速的了解集群的架构，同时遇到需要较大存储的项目，可利用disks跟storage_policies进行评估，是否需要扩容。以上，仅为笔者对clickhouse的一点浅显理解，如果疑问，欢迎讨论与指正。