文章详情

短信预约信息系统项目管理师 报名、考试、查分时间动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

设计 | ClickHouse 分布式表实现数据同步

2021-07-11 18:31

关注

设计 | ClickHouse 分布式表实现数据同步

作者:吴帆 青云数据库团队成员

主要负责维护 MySQL 及 ClickHouse 产品开发,擅长故障分析,性能优化。

在多副本分布式 ClickHouse 集群中,通常需要使用 Distributed 表写入或读取数据,Distributed 表引擎自身不存储任何数据,它能够作为分布式表的一层透明代理,在集群内部自动开展数据的写入、分发、查询、路由等工作。

Distributed 表实现副本数据同步有两种方案:

  1. Distributed + MergeTree
  2. Distributed + ReplicateMergeTree

在使用这种方案时 internal_replication 需要设为 false,向 Distributed 表写入数据,Distributed 表会将数据写入集群内的每个副本。Distributed 节点需要负责所有分片和副本的数据写入工作。

file

1. 集群配置


    
        false
        
            shard1-repl1
            9000
        
        
            shard1-repl2
            9000
        
    

2. 数据写入

CREATE TABLE test.t_local  on cluster logical_consistency_cluster
(
    EventDate DateTime,
    CounterID UInt32,
    UserID UInt32
) ENGINE MergeTree() PARTITION BY toYYYYMM(EventDate) ORDER BY (CounterID, EventDate) ;

CREATE TABLE test.t_logical_Distributed on cluster logical_consistency_cluster
(
    EventDate DateTime,
    CounterID UInt32,
    UserID UInt32
)
ENGINE = Distributed(logical_consistency_cluster, test, t_local, CounterID) ;

INSERT INTO test.t_logical_Distributed VALUES ("2019-01-16 00:00:00", 1, 1),("2019-02-10 00:00:00",2, 2),("2019-03-10 00:00:00",3, 3)

3. 数据查询

# shard1-repl1

SELECT *
FROM test.t_local

Query id: bd031554-b1e0-4fda-9ff8-1145ffae5b02

┌───────────EventDate──┬─CounterID─┬─UserID─┐
│ 2019-03-10 00:00:00 │         3 │      3 │
└─────────────────────┴───────────┴────────┘
┌───────────EventDate─┬─CounterID─┬─UserID─┐
│ 2019-02-10 00:00:00 │         2 │      2 │
└─────────────────────┴───────────┴────────┘
┌───────────EventDate─┬─CounterID─┬─UserID─┐
│ 2019-01-16 00:00:00 │         1 │      1 │
└─────────────────────┴───────────┴────────┘

3 rows in set. Elapsed: 0.004 sec. 

------------------------------------------

# shard1-repl2

SELECT *
FROM test.t_local

Query id: 636f7580-02e0-4279-bc9b-1f153c0473dc

┌───────────EventDate─┬─CounterID─┬─UserID─┐
│ 2019-01-16 00:00:00 │         1 │      1 │
└─────────────────────┴───────────┴────────┘
┌───────────EventDate─┬─CounterID─┬─UserID─┐
│ 2019-03-10 00:00:00 │         3 │      3 │
└─────────────────────┴───────────┴────────┘
┌───────────EventDate─┬─CounterID─┬─UserID─┐
│ 2019-02-10 00:00:00 │         2 │      2 │
└─────────────────────┴───────────┴────────┘

3 rows in set. Elapsed: 0.005 sec. 

通过写入测试我们可以看到每个副本数据是一致的。

即使本地表不使用 ReplicatedMergeTree 表引擎,也能实现数据副本的功能。但每个副本的数据是通过 Distributed 表独立写入,文件存储格式不会完全一致,可以理解这种方式为逻辑一致性。

Distributed 需要同时负责分片和副本的数据写入工作,单点写入很有可能会成为系统性能的瓶颈,所有有接下来的第二种方案。

在使用这种方案时 internal_replication 需要设为 true,向 Distributed 表写入数据。Distributed 表在每个分片中选择一个合适的副本并对其写入数据。

分片内多个副本之间的数据复制会由 ReplicatedMergeTree 自己处理,不再由 Distributed 负责。

file

1. 配置文件


    
        true
        
            shard1-repl1
            9000
        
        
            shard1-repl2
            9000
        
    

2. 数据写入

CREATE TABLE test.t_local on cluster  physical_consistency_cluster 
(
    EventDate DateTime,
    CounterID UInt32,
    UserID UInt32
)
ENGINE = ReplicatedMergeTree("{namespace}/test/t_local", "{replica}")
PARTITION BY toYYYYMM(EventDate)
ORDER BY (CounterID, EventDate, intHash32(UserID))
SAMPLE BY intHash32(UserID);



CREATE TABLE test.t_physical_Distributed on cluster physical_consistency_cluster
(
    EventDate DateTime,
    CounterID UInt32,
    UserID UInt32
)
ENGINE = Distributed(physical_consistency_cluster, test, t_local, CounterID);

INSERT INTO test.t_physical_Distributed VALUES ("2019-01-16 00:00:00", 1, 1),("2019-02-10 00:00:00",2, 2),("2019-03-10 00:00:00",3, 3)

3. 数据查询

# shard1-repl1

SELECT *
FROM test.t_local

Query id: d2bafd2d-d0a8-41b4-8d79-ece37e8159e5

┌───────────EventDate──┬─CounterID─┬─UserID─┐
│ 2019-03-10 00:00:00 │         3 │      3 │
└─────────────────────┴───────────┴────────┘
┌───────────EventDate─┬─CounterID─┬─UserID─┐
│ 2019-02-10 00:00:00 │         2 │      2 │
└─────────────────────┴───────────┴────────┘
┌───────────EventDate─┬─CounterID─┬─UserID─┐
│ 2019-01-16 00:00:00 │         1 │      1 │
└─────────────────────┴───────────┴────────┘

3 rows in set. Elapsed: 0.004 sec. 

------------------------------------------

# shard1-repl2

SELECT *
FROM test.t_local

Query id: b5f0dc80-f73f-427e-b04e-e5b787876462

┌───────────EventDate─┬─CounterID─┬─UserID─┐
│ 2019-01-16 00:00:00 │         1 │      1 │
└─────────────────────┴───────────┴────────┘
┌───────────EventDate─┬─CounterID─┬─UserID─┐
│ 2019-03-10 00:00:00 │         3 │      3 │
└─────────────────────┴───────────┴────────┘
┌───────────EventDate─┬─CounterID─┬─UserID─┐
│ 2019-02-10 00:00:00 │         2 │      2 │
└─────────────────────┴───────────┴────────┘

3 rows in set. Elapsed: 0.005 sec. 

ReplicatedMergeTree 需要依靠 ZooKeeper 的事件监听机制以实现各个副本之间的协同,副本协同的核心流程主要有:INSERT、MERGE、MUTATION 和 ALTER 四种。

通过写入测试我们可以看到每个副本数据也是一致的,副本之间依靠 ZooKeeper 同步元数据,保证文件存储格式完全一致,可以理解这种方式是物理一致。

ReplicatedMergeTree 也是在分布式集群中最常用的一种方案,但数据同步需要依赖 ZooKeeper,在一些 DDL 比较频繁的业务中 Zookeeper 往往会成为系统性能的瓶颈,甚至会导致服务不可用。

我们需要考虑为 ZooKeeper 减负,使用第一种方案 + 负载均衡轮询的方式可以降低单节点写入的压力。

使用 Distributed + MergeTree 可实现逻辑一致分布式。

数据内容完全一致,数据存储格式不完全一致,数据同步不依赖 ZooKeeper,副本的数据可能会不一致,单点写入压力较大。

使用 Distributed + ReplicateMergeTree 可实现物理一致分布式。

数据内容完全一致,数据存储格式完全一致。数据同步需要依赖 ZooKeeper,ZooKeeper 会成为系统瓶颈。

阅读原文内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题
  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-数据库
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯