背景概述
Clickhouse通过表数据的冗余存储,来达到防止数据丢失的问题。这也就是常说的数据副本机制,但是副本数据和真实数据都存储了,服务器的容量就不够了,这时我们就需要实现数据的水平切分,来解决单个服务器容量不够的问题。这就是常说的数据分片机制
数据副本机制
ClickHouse依靠ReplicatedMergeTree引擎族与ZooKeeper实现了复制表机制, 成为其高可用的基础.ReplicatedMergeTree引擎族包含如下的表种类
- ReplicatedMergeTree
- ReplicatedSummingMergeTree
- ReplicatedReplacingMergeTree
- ReplicatedAggregatingMergeTree
- ReplicatedCollapsingMergeTree
- ReplicatedVersionedCollapsingMergetree
- ReplicatedGraphiteMergeTree
目前阶段只有上面这些表种类支持副本机制。副本是表级别的,不是整个服务器级的。所以,服务器里可以同时有复制表和非复制表。因为Clickhouse复制表机制是通过zookeeper实现的。所以要使用副本,需在配置文件中设置 ZooKeeper 集群的地址。后面会详细介绍下ReplicatedMergeTree表引擎在Clickhouse数据库中是怎么做的。
数据副本的特点
作为数据副本的主要实现载体,ReplicatedMergeTree在设计上有一些显著特点。
- 依赖ZooKeeper:在执行INSERT和ALTER查询的时候,ReplicatedMergeTree需要借助ZooKeeper的分布式协同能力,以实现多个副本之间的同步。但是在查询副本的时候,并不需要使用ZooKeeper。
- 表级别的副本:副本是在表级别定义的,所以每张表的副本配置都可以按照它的实际需求进行个性化定义,包括副本的数量,以及副本在集群内的分布位置等。
- 多主架构(Multi Master):可以在任意一个副本上执行INSERT和ALTER查询,它们的效果是相同的。这些操作会借助ZooKeeper的协同能力被分发至每个副本以本地形式执行。
- Block数据块:在执行INSERT命令写入数据时,会依据max_insert_block_size的大小(默认1048576行)将数据切分成若干个Block数据块。所以Block数据块是数据写入的基本单元,并且具有写入的原子性和唯一性。
- 原子性:在数据写入时,一个Block块内的数据要么全部写入成功,要么全部失败。
- 唯一性:在写入一个Block数据块的时候,会按照当前Block数据块的数据顺序、数据行和数据大小等指标,计算Hash信息摘要并记录在案。在此之后,如果某个待写入的Block数据块与先前已被写入的Block数据块拥有相同的Hash摘要(Block数据块内数据顺序、数据大小和数据行均相同),则该Block数据块会被忽略。这项设计可以预防由异常原因引起的Block数据块重复写入的问题。
下面我们讲解下Clickhouse是如何通过ReplicatedMergeTree来达到数据复制高可用的。
ReplicatedMergeTree原理解析
上面说到clickhouse的副本机制是基于ReplicatedMergeTree表实现的. 用户在创建每张表的时候, 可以决定该表是否高可用。
表创建方式
CREATE TABLE table_name
(
EventDate DateTime,
CounterID UInt32,
UserID UInt32
) ENGINE = ReplicatedMergeTree('/clickhouse/tables/{layer}-{shard}/table_name', '{replica}')
PARTITION BY toYYYYMM(EventDate)
ORDER BY (CounterID, EventDate, intHash32(UserID))
SAMPLE BY intHash32(UserID)
<