clickhouse分布式之弹性扩缩容的故事

2023-11-20 14:20

本文主要是介绍clickhouse分布式之弹性扩缩容的故事,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

现状

社区不支持喔,以后也不会有了。曾经尝试过,难道是是太难了,无法实现吗?因为他们企业版支持了,可能是利益相关吧,谁知道呢,毕竟开源也要赚钱,谁乐意一直付出没有回报呢。

社区之前有个"残废"的 Zero-copy replication特性,本质就是为了做弹性扩缩容的。该特性一直半推半就,直到现在官方都说不稳定,bug多,不推荐使用。推荐使用云原生企业版SharedMergeTree,建议你花钱。

Zero-copy replication

从名字看,是个零拷贝复制。原理如图:

原理图

  1. server-1收到插入业务数据请求
  2. server-1把业务数据写入到远端的对象存储中
  3. server-1在本地磁盘记录业务数据的元数据(例如,业务数据存储在对象存储中的位置)
  4. server-1通过clickhouse-keeper (zoo-keeper) 通知server-2和server-3,自己有新的元数据
  5. server-2和server-3从server-1下载对应的元数据,写入到本地磁盘

这种改变,对于clickhouse来说,数据不需要“再均衡”,弹性扩缩容变得很容易。同时也带来了如下几个问题:

  • 需要分布式引用计数。当删除数据时,首先要确保所有节点上,关于该数据的元数据都被删除后,才能真的删除该数据。
  • 需要分布式锁。合并和变更同时只能一个节点去做。
  • 元数据仍然与计算节点耦合,本地磁盘是附加的故障点。
  • 很难用于大规模集群。大量节点之间的元数据同步和锁的竞争,会拖垮整个集群。

SharedMergeTree

这个就是企业版中弹性扩缩容的依仗。既然是企业版,那么就意味着代码没有开源。

从名字看,
首先是共享,也必然是shared storage架构,只有这样才能做到快速的弹性扩缩容,而不影响集群数据的完整性。

然后是MergeTree,依然是MergeTree家族系列。意味着你也可以继承MergeTree从而实现自己的SharedMergeTree。

原理如图:

在这里插入图片描述

  1. server-1收到插入业务数据请求
  2. server-1把业务数据写入到远端的对象存储中
  3. server-1在本地磁盘和keeper中记录业务数据的元数据(例如,业务数据存储在对象存储中的位置)
  4. server-1向查询者确认插入
  5. server-2和server-3从keeper中收到元数据变更通知,更新元数据到本地磁盘

这种改动使得集群间的节点之间不需要再同步元数据,keeper充当集群的协调者。
新增一个节点,该节点只需要从keeper中同步完元数据后,即可参与数据处理。
移除一个节点,该节点从keeper中注销自己,即可优雅下线。

其实很多细节官方都没有描述出来,
比如数据的merge和update问题,节点越多,速度越快。节点间的merge和update协调如何做的?
再比如对一个单一查询,节点越多,速度越快。怎么做的任务切分和最终聚合?

如何既要又要

那么如何做到既要分布式弹性伸缩,又要不花钱?

自己二次开发

就像上面说的,自己继承MergeTree,实现自己的SharedMergeTree。比较考验技术水平,同时需要的时间和精力比较多。

参考 redis cluster

redis3.0官方出的cluster方案,仔细分析就会发现,服务端其实没多少复杂改动,工作量基本都push到了客户端。但是并不妨碍这种集群方案的流行。
回归到clickhouse呢?相比较redis的客户端,clickhouse的客户端工作量要少一半,对于读取,分布式查询clickhouse天然支持的很完美,那么关注点只需要在写入上就可以了。

实现方案

下图演示如何针对clickhous集群做节点的扩缩容。此处写入用的是本地表,这也是官方建议的。写分布式表意味着集群越大,性能越差。

  1. 由于加入/移除分片shard3,需要在clickhouse管理平台上添加节点的信息,生成新的配置文件后,由管理平台分发到集群的6个节点上(如果是移除,则是4个节点)覆盖老的配置文件。无需重启服务,配置文件会被热加载。
  2. 把集群信息 全量/增量写入keeper中(此处复用集群的keeper)
  3. 业务系统收到集群信息变更后
  4. 如果是移除节点,则需要针对分片3的数据做再平衡。从节点3读取数据,均衡写入到分片1和2,完成此操作后,通知clickhouse管理平台,节点缩容成功。虽然缩容过程可能较为耗时,但是在非云服务环境下,缩容场景本身就不常见,此处只是给出一个可行方案。
    此时,数据写入因为分片3被移除,所以需要动态调整写入。数据读取因为分布式查询无需做任何改动。
    如果是添加节点,业务系统则需要对分片3的2个节点创建分布式表。此时数据写入因为分片3的新增,所以需要动态调整写入。数据读取因为分布式查询无需做任何改动。

总结

集群的变动带来的工作量基本都push到了客户端。缩容时,读取数据再平衡写入到其他分片。扩容时候,写入数据动态平衡。

这种replicateMergeTree+分片的架构,和sharedMergeTree在某些方面比较相似:

  1. 单个查询加速,节点越多速度越快,因为数据是分片的,每个分片都计算处理自己的数据,相互不干扰,最终聚合。
  2. merge和update也都是分片独立处理自己的数据

与sharedMergeTree在某些方面也有不同之处:

  1. 节点移除时,数据需要再均衡,需要时间
  2. 分片之间的副本需要同步数据,也会降低一些性能

这篇关于clickhouse分布式之弹性扩缩容的故事的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/395239

相关文章

Python FastAPI+Celery+RabbitMQ实现分布式图片水印处理系统

《PythonFastAPI+Celery+RabbitMQ实现分布式图片水印处理系统》这篇文章主要为大家详细介绍了PythonFastAPI如何结合Celery以及RabbitMQ实现简单的分布式... 实现思路FastAPI 服务器Celery 任务队列RabbitMQ 作为消息代理定时任务处理完整

redis+lua实现分布式限流的示例

《redis+lua实现分布式限流的示例》本文主要介绍了redis+lua实现分布式限流的示例,可以实现复杂的限流逻辑,如滑动窗口限流,并且避免了多步操作导致的并发问题,具有一定的参考价值,感兴趣的可... 目录为什么使用Redis+Lua实现分布式限流使用ZSET也可以实现限流,为什么选择lua的方式实现

Seata之分布式事务问题及解决方案

《Seata之分布式事务问题及解决方案》:本文主要介绍Seata之分布式事务问题及解决方案,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录Seata–分布式事务解决方案简介同类产品对比环境搭建1.微服务2.SQL3.seata-server4.微服务配置事务模式1

CSS弹性布局常用设置方式

《CSS弹性布局常用设置方式》文章总结了CSS布局与样式的常用属性和技巧,包括视口单位、弹性盒子布局、浮动元素、背景和边框样式、文本和阴影效果、溢出隐藏、定位以及背景渐变等,通过这些技巧,可以实现复杂... 一、单位元素vm 1vm 为视口的1%vh 视口高的1%vmin 参照长边vmax 参照长边re

java如何分布式锁实现和选型

《java如何分布式锁实现和选型》文章介绍了分布式锁的重要性以及在分布式系统中常见的问题和需求,它详细阐述了如何使用分布式锁来确保数据的一致性和系统的高可用性,文章还提供了基于数据库、Redis和Zo... 目录引言:分布式锁的重要性与分布式系统中的常见问题和需求分布式锁的重要性分布式系统中常见的问题和需求

Golang使用etcd构建分布式锁的示例分享

《Golang使用etcd构建分布式锁的示例分享》在本教程中,我们将学习如何使用Go和etcd构建分布式锁系统,分布式锁系统对于管理对分布式系统中共享资源的并发访问至关重要,它有助于维护一致性,防止竞... 目录引言环境准备新建Go项目实现加锁和解锁功能测试分布式锁重构实现失败重试总结引言我们将使用Go作

Redis分布式锁使用及说明

《Redis分布式锁使用及说明》本文总结了Redis和Zookeeper在高可用性和高一致性场景下的应用,并详细介绍了Redis的分布式锁实现方式,包括使用Lua脚本和续期机制,最后,提到了RedLo... 目录Redis分布式锁加锁方式怎么会解错锁?举个小案例吧解锁方式续期总结Redis分布式锁如果追求

集中式版本控制与分布式版本控制——Git 学习笔记01

什么是版本控制 如果你用 Microsoft Word 写过东西,那你八成会有这样的经历: 想删除一段文字,又怕将来这段文字有用,怎么办呢?有一个办法,先把当前文件“另存为”一个文件,然后继续改,改到某个程度,再“另存为”一个文件。就这样改着、存着……最后你的 Word 文档变成了这样: 过了几天,你想找回被删除的文字,但是已经记不清保存在哪个文件了,只能挨个去找。真麻烦,眼睛都花了。看

开源分布式数据库中间件

转自:https://www.csdn.net/article/2015-07-16/2825228 MyCat:开源分布式数据库中间件 为什么需要MyCat? 虽然云计算时代,传统数据库存在着先天性的弊端,但是NoSQL数据库又无法将其替代。如果传统数据易于扩展,可切分,就可以避免单机(单库)的性能缺陷。 MyCat的目标就是:低成本地将现有的单机数据库和应用平滑迁移到“云”端

【Go】go连接clickhouse使用TCP协议

离开你是傻是对是错 是看破是软弱 这结果是爱是恨或者是什么 如果是种解脱 怎么会还有眷恋在我心窝 那么爱你为什么                      🎵 黄品源/莫文蔚《那么爱你为什么》 package mainimport ("context""fmt""log""time""github.com/ClickHouse/clickhouse-go/v2")func main(