对于中小城商行,单个交易系统的数据量远不如大行,集中式数据库已经能满足业务需求,在此情形下,是否还需要引入分布式数据库,什么情况下需要引入?如何进行分布式数据库选型,重点应关注哪些方面?
在做出合适选择之前,需要以下准备工作:
1. 业务画像
针对不同的业务,做出业务侧的数据库画像,包括但不限于如下维度
上述因素综合考虑后,才能做出相对合理的选择。
收起分布式是大趋势,不仅体现在数据库上,也体现在应用上。
数据库有分布式数据库,应用也有分布式架构。容器、云、分布式,这些技术潮流还是要赶上的,也许目前不需要,但总要防患于未然。
并且,即使是中小城商行,业务规模将来总会增大的,现在提前把技术平台搭建好,以应对未来业务所需。
如果行里有线上交易系统,或者有系统已经开始拆分业务节点和数据库节点,那么可以换到分布式数据库。
在分布式数据库选型时,应该关注数据库的综合能力,不仅要测试对于数据库传统功能的支持度、分布式特性(如弹性伸缩、高可用、高性能),更要测试数据库运维管理能力和兼容性,后者是应用迁移最为关注的问题。此外,也要考虑成本,根据行里预算进行选型。
收起对于中小城商行,从性能和数据量上来说,单个交易系统使用传统数据库也可以满足要求。引入分布式数据库主要是从提高响应业务的敏捷性,弹性扩容、降低运营成本等几个方面来考虑。引入分布式数据库,由于性能一般都能满足要求,可以从数据库产品的稳定性、功能、协议支持的完备性、服务质量这些方面来选型。
收起判断两个点:
1.数据量和业务规模
分布式数据库解决的最核心的问题是业务规模和扩展性。
如果业务量大到集中式数据库物理机承载上限了,就需要分布式,否则并不是强要求。
我举个例子:
客户他业务规模要16C64G足够的话,就没有必要搞分布式
收起根据您的描述,目前传统数据库如Oracle、DB2应该是能够满足你3-5年内的需求的,所以现在这是引入分布式数据库(推荐信创产品)的最佳契机,你有3-5年的试用时间,可以现在非核心系统进行试用,逐步用到核心系统中。
收起分布式数据库分为2种:存算分离的分片数据库,例如MySQL体系的。还有就是TiDB Oceanbase这样的。
一般来说,企业的重要业务系统全分布式改造,动作比较大,在国内银行中改造成功的较少。且这种替代需要3-5年的过渡期。
中小城商行可以选择一些互联网、线上营销的业务,在业务软件引入的同时,进行分布式数据库更换。如果技术力量薄弱,也可以先基于测试、开发类业务进行试用,逐渐上生产。
总之,国内大部分分布式数据库都已经开源,开源意味着运维、开发等综合能力的体现,你的、你团队的技术能力决定分布式数据库的应用范围大小。
收起说句反潮流的话:采用分布式数据库的目的是什么?其实是更好地处理集中式的业务。银行的业务是大集中的,因此不管是分布式还是集中式,最终都是用各种方式满足大集中的业务需求。分布式和集中式只是手段不同。如果集中式可以满足业务要求首先从需求上就没了更换的必要。
另外这个业务需求除了自主可控外,主要来自于业务支撑压力,而非成本等因素。再说句反潮流的话,当前(注意这个限定)用分布式替换集中式架构多数成本会更高。
如果出于其它考虑,打算引入分布式数据库,那么说一些数据库之外可能需要考虑的东西: