文章目录
一、环境描述
1.1 服务部署规划
服务器名称 | IP地址 | 服务配置 |
---|---|---|
mdw | 172.16.104.11 | grafana、prometheus、ck |
sdw1 | 172.16.104.12 | chproxy、ck、zk |
sdw2 | 172.16.104.13 | ck、zk |
sdw3 | 172.16.104.14 | ck、zk |
本地环境资源有所限制,生产环境建议不同的服务分别部署在不同的服务器上。
1.2 CK集群设置
┌─cluster──────┬─shard_num─┬─shard_weight─┬─replica_num─┬─host_name─┬─host_address──┬─port─┬─is_local─┬─user────┬─default_database─┬─errors_count─┬─estimated_recovery_time─┐
│ shard2_repl1 │ 1 │ 1 │ 1 │ mdw │ 172.16.104.11 │ 9000 │ 1 │ default │ │ 0 │ 0 │
│ shard2_repl1 │ 1 │ 1 │ 2 │ sdw1 │ 172.16.104.12 │ 9000 │ 0 │ default │ │ 0 │ 0 │
│ shard2_repl1 │ 2 │ 1 │ 1 │ sdw2 │ 172.16.104.13 │ 9000 │ 0 │ default │ │ 0 │ 0 │
│ shard2_repl1 │ 2 │ 1 │ 2 │ sdw3 │ 172.16.104.14 │ 9000 │ 0 │ default │ │ 0 │ 0 │
└──────────────┴───────────┴──────────────┴─────────────┴───────────┴───────────────┴──────┴──────────┴─────────┴──────────────────┴──────────────┴─────────────────────────┘
二、chproxy的使用
2.1 chproxy的优势
1、原生clickhouse集群的缺点
- ck通过本地表和分布式表来完成分布式查询与写入,这就导致语句执行初始数据库节点(配合zk进行协调处理操作)进行数据下发时产生大量的网络带宽消耗;
- 对于分布式表的写入,数据会先在分布式表所在的机器进行落盘,然后异步的发送到本地表所在机器进行存储,中间没有一致性的校验,存在数据一致性风险;
- 对于分布式表的写入,分布式表所在机器时如果机器出现down机,会存在数据丢失风险;
- 某些场景下,使用原生分布式表,会导致分片节点上数据写入分布不均匀;
- 谨慎使用on cluster的SQL,目前该语法还不是很完善,某些情况下会导致SQL hang住的情况;
- 对于分布式表的使用,建议只再个别节点创建,专门用来进行分布式查询操作;
2、chproxy的优化
- 直接通过chproxy进行轮询路由,将数据直接写入本地表,避免原生分布式表可能会产生的数据一致性、数据丢失的风险;
- 直接通过chproxy进行轮询路由,避免多分片表节点数据分布不均;
- 直接通过chproxy进行轮询路由,避免语句执行初始数据库节点进行数据下发时,产生的成倍的网络带宽消耗;
- chproxy可将ck集群划分为多个逻辑集群,不同逻辑集群按需进行配置(不同逻辑指定CK集群内指定节点,将数据写入、查询进行逻辑上的隔离,避免资源影响干扰等)
- 在Chproxy上层挂在负载均衡,可做到chproxy层面的高可用,也可横向扩展业务能力
- 对逻辑用户进行查询、访问、安全等限制;
2.2 Clickhouse集群安装部署
可参考文档:CK集群搭建部署
2.3 chproxy安装部署
1、软件安装
# wget -c https://github.com/Vertamedia/chproxy/releases/download/v1.14.0/chproxy-linux-amd64-v1.14.0.tar.gz
# tar xf chproxy-linux-amd64-v1.14.0.tar.gz
2、编写chproxy配置文件
# mkdir -pv /da