ReplicatedMergeTree靠谱吗?
发布于 2 个月前 作者 kikanjuu 354 次浏览 来自 问答

我们在考虑用ReplicatedMergeTree表做数据副本。有没有用过它的朋友,分享下经验?

请教几个问题: 海量数据写入时,对Zookeeper造成的压力大不大? 有没有遇到过Zookeeper挂了,导致表不可写入,如何处理的?

建表感觉比较麻烦,要在每个Shard节点上为每个副本建一张ReplicatedMergeTree表。有没有简化的办法?

ReplicatedMergeTree的后台同步机制,有没有遇到过失败的情况?

10 回复

1、对zk压力不大 2、包括zk之类的问题导致写入失败,会进行数据的失败重传 3、54370版本以上支持了create table on cluster,可以分布式建表。 4、节点挂掉重启如果表结构变动大会启动不成功,官方文档的data replication章说到数据恢复方式。 5、没遇到其余后台同步失败问题,比较稳定。

@liangchen 你每天写入的数据量有多少,能否介绍下?

关于分布式建表,我有4个shard,每个shard有2个副本。集群有4台机器,每台维护2个副本。 所以我要执行以下语句八次:

CREATE TABLE demo … ENGINE = ReplicatedMergeTree( ’/clickhouse/tables/{shard}/demo’, ’{replica}’, …); 其中的shard值为1-4,replica为1或2。

我要分别在每台服务器上运行两次以上语句。比较麻烦。

按你说的,用create table on cluster,似乎不能解决问题——因为参数shard和replica值是变化的。有没有好办法简化我的建表流程?

1、你架构改一下,4台机器,12、34互为replica,13、24互为shard,那么建表语句就统一了。 2、我每秒2w写入

@liangchen “13、24互为shard” 之所以要分成4个shard,是为了在全表扫描查询时,把4台机器的CPU都用上,让4台机器都参与查询计算。 如果只有2个shard,那么一次查询只会有4台中的2台做查询计算,不能充分利用集群所有CPU。

@kikanjuu 没有必要的,除非你并发很低很低。并发只需要稍稍高点,4台cpu自然都会用上的。

@liangchen 我如果只有2个shard,查询时Distributed表的负载均衡策略,只会选择2个副本查询,那么只有2台机器会处理查询请求。为什么能用到4台机器呢?

@kikanjuu 如果同时2个请求,一个可以到13,另一个可以到24了呀

@liangchen 按您说的, 1、3各自提供一个Shard,1、3共同组成一张表的全量数据, 2、4各自提供一个Shard,2、4也共同组成同一张表的全量数据。

为了分布式查询,需要建立和访问Distributed表。 这张Distributed表,应该基于1、3建立,还是2、4建立呢? 无论是哪种,当查询Distributed表时,都只能访问1、3或2、4,只能利用一半的机器做查询计算。

如果这张Distributed表,是基于1、2、3、4全部四个节点建立,那么查询这张Distributed表,会看到数据重复了两份,功能不正确。

最后,确实可以建两张Distributed表,第一张基于1、3;第二张基于2、4. 这两张Distributed表的名字/所属数据库必须不同。这就要求应用并发访问时,有轮询策略,访问不同的Distributed表。——可以充分利用4台机器查询,但是需要应用层代码改造,实现轮询访问两张Distributed表。

不需要应用层代码改造的,应用层作轮训访问分布式表就行。在4台机器建同一名称的分布式表就行,应用层轮训访问4台机器的分布式表。例如轮训到1机器的分布式表就会访问1和3的本地表。

@liangchen 如果是轮询写入多张分布式表,则每张分布式表里,都没有全量的数据。因为每张分布式表只接收到了一部分的写入请求。 怎么做到有两个全量的副本呢?

同时还要保证查询时,4个节点的cpu都用上。

回到顶部