关于数据库:设计-ClickHouse-分布式表实现数据同步

62次阅读

共计 4789 个字符，预计需要花费 12 分钟才能阅读完成。

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

次要负责保护 MySQL 及 ClickHouse 产品开发，善于故障剖析，性能优化。

在多正本分布式 ClickHouse 集群中，通常须要应用 Distributed 表写入或读取数据，Distributed 表引擎本身不存储任何数据，它可能作为分布式表的一层通明代理，在集群外部主动发展数据的写入、散发、查问、路由等工作。

Distributed 表实现正本数据同步有两种计划：

  1. Distributed + MergeTree
  2. Distributed + ReplicateMergeTree

| Distributed + MergeTree

在应用这种计划时 internal_replication 须要设为 false，向 Distributed 表写入数据，Distributed 表会将数据写入集群内的每个正本。Distributed 节点须要负责所有分片和正本的数据写入工作。

1. 集群配置 

<logical_consistency_cluster>
    <shard>
        <internal_replication>false</internal_replication>
        <replica>
            <host>shard1-repl1</host>
            <port>9000</port>
        </replica>
        <replica>
            <host>shard1-repl2</host>
            <port>9000</port>
        </replica>
    </shard>
</logical_consistency_cluster>

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 须要同时负责分片和正本的数据写入工作，单点写入很有可能会成为零碎性能的瓶颈，所有有接下来的第二种计划。

| Distributed + ReplicateMergeTree

在应用这种计划时 internal_replication 须要设为 true，向 Distributed 表写入数据。Distributed 表在每个分片中抉择一个适合的正本并对其写入数据。

分片内多个正本之间的数据复制会由 ReplicatedMergeTree 本人解决，不再由 Distributed 负责。

1. 配置文件 

<physical_consistency_cluster>
    <shard>
        <internal_replication>true</internal_replication>
        <replica>
            <host>shard1-repl1</host>
            <port>9000</port>
        </replica>
        <replica>
            <host>shard1-repl2</host>
            <port>9000</port>
        </replica>
    </shard>
</physical_consistency_cluster>

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 减负，应用第一种计划 + 负载平衡轮询的形式能够升高单节点写入的压力。

总结

  • internal_replication = false

应用 Distributed + MergeTree 可实现逻辑统一分布式。

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

  • internal_replication = true

应用 Distributed + ReplicateMergeTree 可实现物理统一分布式。

数据内容完全一致，数据存储格局完全一致。数据同步须要依赖 ZooKeeper，ZooKeeper 会成为零碎瓶颈。

正文完
数据库
发表至： 数据库
2021-09-23
 0
关于数据库:从一条更新-SQL-的执行过程窥探-InnoDB-之-REDOLOG
关于数据库:ShardingSphere-4x-ShardingJDBC-JDBC不支持项
关于数据库:火山引擎DataLeap数据质量解决方案和最佳实践三最佳实践
关于数据库:如何保证缓存与数据库的双写一致性