目前各分布式数据库均宣称支持动态节点扩容和缩容,大家在主流分布式数据库是否进行过动态扩容和缩容操作,实施过程是否有什么问题,尤其是动态缩容操作,个人感觉相对难度较大点。
针对OB数据库来讲,扩容是非常简单的。一般扩容分集群级别扩缩容,和租户级别扩缩容。
集群级别的扩缩容稍微复杂点,需要先把相关server上的资源迁移走,然后在通过下线server方式缩容。都是在线操作,大部分操作都是OCP这个工具上实现,十分简单。
租户级别的扩缩容就更加简单了,可以说是秒级别就可以实现。就是通过修改租户的资源规格来达到动态扩缩容的。十分简单方便。
资源动态扩缩容是金融行业、特别是银行业普遍的需求,常见如下:
一方面,不同业务的高峰时段不一样,举个例子,日终清算和贷款批量扣款还款是不同时间段的业务。
另一方面,热点库、热点分区、热点账户的问题客观存在
综上,因此数据库必然有动态扩容需求、动态分割资源的需求,这时候,租户隔离和动态加减服务器就提上日程了。
租户隔离,不仅是线上数据库稳定的基本保证,应用通过容器实现微服务的拆分,实现有效隔离,数据库层怎么隔离呢? 就是要通过租户资源隔离,实现数据库层的有效隔离。从业务价值来看,租户隔离是实现资源动态、分时段分割的有效手段。一段时间给到日终清算,跑批完成后,给到贷款批量扣款还款。
动态加减服务器方面,选择支持一致性协议的数据库,那些基于开源魔改的数据库,用什么一致性Hash算法实现所谓的打散,能够扩容,缩容缩不了 或者缩容不平滑。
从实践方面,加减服务器就看蚂蚁和阿里的OceanBase,多年大促的打磨,从电子商务的高并发,到三方支付,这方面久经考验。数据库的成熟是业务场景磨出来的,不是研发写出来的。
数据库分两部分,一部分是提供业务服务的进程,一部分是需要持久化的数据。我们说扩缩容的时候,一般也要讨论这两部分。
一般而言扩容缩容是应对业务峰谷的。所以真正需要扩缩的其实是服务进程部分,这部分最好是需要时就拉起,不需要就关闭。
但这有两个问题要解决,首先如果服务进程不是无状态的,那么必然涉及到数据的搬迁重布局,也就是服务的扩容缩容实际上要带动数据一起。第二个问题是扩容缩容的前提是扩出来的服务能和主节点实时同步,而且能读能写。这样扩容出来的服务才能对业务增加吞吐,但是开源主从数据库要做这点并不容易。如果基于中间件切片,可能要重新切。
所以我的看法是,要能灵活扩容缩容,一定要把数据持久化部分独立出来,让数据库服务变成无状态。
然后无状态化的数据库要能实现一致性多读多写(对于MySQL可以参考我分享的文章《怎样才是分布式数据库存算分离的正确姿势》里面介绍的方法)。
接下来独立出来的持久化部分,涉及到的是容量扩容(容量缩容比较少见,除非把库删了)。因此只要选择可以平滑扩容的外置独立存储就行,这种企业级存储一般都能做到,选择面也是比较宽的。
收起分布式数据库的扩容肯定会涉及到数据的重分布,这个过程比较耗费资源,当然可能会影响正在运行的业务,就我接触的扩容来说,基本原理就是建立中间表将数据重新插入到新表,之后再做rename的操作,这个过程最好还是停止业务去做,如果同时做扩容和业务并行运行,可能会有很多不可预知的意外出现,尤其是数据的一致性。
收起在线扩缩容都有产品功能,但实际操作性不好说。比如一个小银行的数据量不会有爆发性增长,一个单库可能就会撑很久,根本没有这些需求呀。
再者,扩缩容时要不要停机对产品实现难度也不一样。如果中小银行,在产品不成熟时建议停机操作,这毕竟是偶发操作
在线扩容和在线缩容在原理上都很好实现,主要是看对业务的影响降低到什么程度
在线扩缩容肯定对业务都多多少少会有一些影响
一般建议是尽量申请停机窗口来做扩缩容
也有一些特殊业务很难申请停机窗口、或者申请的停机窗口时间很短的,那么这样的场景就是对数据库产品功能的考验了
在线扩缩容一般都会带来存储节点的IO冲击,进而影响到业务系统的SQL响应时间,在数据重均衡期间,如何平滑的使用存储节点的IOPS资源和其保护,尤其重要
收起分布式数据库均宣称支持动态节点扩容和缩容,大家在主流分布式数据库是否进行过动态扩容和缩容操作,实施过程是否有什么问题,尤其是动态缩容操作,个人感觉相对难度较大点。
解读要求:
1、支持动态的扩容缩容:要求做到动态实现,也即数据分片的数量是可以动态调整的。
2、无服务影响的扩容缩容:动态扩容缩容时,不能中断业务系统的数据服务。
实现技术:
1、思路之一:不改变数据分片的数量,且只腾挪数据分片的存储位置,支持动态扩容缩容服务器节点,例如:腾讯TDSQL、热璞数据库HotDB等支持此模式,可以有效规避软件出现Bug缺陷的数据错乱风险。
2、思路之二:改变数据分片的数量,且按数据分片颗粒度腾挪数据分片的存储位置,支持动态扩容缩容服务器节点,例如: 阿里云PolarDB-X、华为云GaussDB、腾讯TDSQL、热璞数据库HotDB等支持此模式,无法做到规避软件出现Bug缺陷的数据错乱风险。
3、思路之三:改变数据分片的数量,且按数据存储块颗粒度 数据分片的存储位置,支持动态扩容缩容服务器节点,例如: TiDB、OceanBase等支持此模式,无法做到规避软件出现Bug缺陷的数据错乱风险。
4、小结:
4.1 思路之一的颗粒度是最大的、思路之二的颗粒度是中等的、思路之三的颗粒度是最小的;
4.2 思路之一功能实现是无风险的、思路之二功能实现是有风险的的、思路之三功能实现是风险最大的;
4.3 思路之三有存储介质依赖,思路之一、思路之二无硬件设备依赖。
在银行行业中,分布式数据库的动态扩容和缩容是非常重要的,因为银行的业务量和数据量都是非常大的,需要不断地扩容来支持业务的发展。目前主流的分布式数据库都宣称支持动态节点扩容和缩容,但实际操作中还是存在一些问题的。
首先,动态扩容操作相对来说比较容易,只需要添加新的节点即可,但是需要注意的是,添加新节点后需要进行数据迁移,这个过程可能会比较耗时,需要进行合理的规划和调度,以避免对业务造成影响。
其次,动态缩容操作相对来说比较难,因为需要将节点上的数据迁移到其他节点上,同时还需要保证业务的正常运行。在实际操作中,可能会出现数据迁移失败、节点下线失败等问题,需要进行及时的处理和调整。
针对这些问题,建议在进行动态扩容和缩容操作时,需要进行充分的规划和测试,确保操作的安全性和可靠性。同时,建议使用国产数据库,因为国产数据库在分布式架构、动态扩容和缩容等方面都有很好的支持和优化,可以更好地满足银行行业的需求。