面对今天的互联网大环境,越来越多的企业IT部门开始探寻一条属于自己的互联网IT架构之路。那么这里首先遇到的抉择就是分布式架构的选择,尤其是分布式数据库的抉择。金融行业在面临这个新选择的时候,首先是覆盖范围的问题,究竟是全新改造还是混合并用?其次是选型问题,究竟该选择什么样的分布式产品,用在什么样的业务场景?再次是如何用的问题,是直接应用到数据库上,还是需要应用、中间件、存储侧的统合改造? 面对这些问题,本次活动围绕这些主线,召集金融同业来共同探讨,以问答形式总结如下:
1. 关于金融行业分布式转型的必要性探讨。
【问题分享】
Q:金融行业把交易型业务使用数据库从传统的商业数据库切换到分布式数据库,可行性和现状?
Q: 金融行业的分布式数据库转型 必要性 提纲挈领的建议?
Q:金融行业的分布式数据库应用有没有必要性的场景?
【问题解答】
这是大家在分布式转型的时候,面临的首先要问题。也就是说我们为什么要进行分布式的转型?
其实这个问题我觉得取决于两点:
传统架构下的一些平台是不是伴随着业务的不断更新,出现了新的数据类型或者数据结构变得复杂化了,比如说一些新的非结构化、半结构化影像数据?
如果没有以上问题,那确实没有必要改。
结合以上的问题,我们觉得在金融行业当中,首先面临分布式转型决策的场景:
2. 关于金融行业分布式数据库应用场景的探讨。
【问题分享】
Q:保险行业分布式数据库的应用场景有哪些?
Q:证券行业分布式数据库应用场景有哪些?
Q:在金融行业,分布式数据库适合的应用和业务类型?
【问题解答】
我们觉得在金融行业当中,首先面临分布式转型决策的场景:
保险行业当中有一个非常重要的业务,那就是如何根据客户的多维度信息来计算客户应该交纳的保费,还可以对客户进行精确划分。比如车险业务,传统的方法就是根据车型、车龄、历史年度理赔情况等等这些信息来判断这个客户的保费,这种算法模型显得有些粗放。还有一点,目前很多保险公司的各类系统数据不能很好整合,相互独立,导致客户的信息不够完整统一。所以,未来利用大数据的思路来整合各个系统的数据,甚至结合公有云电子商务平台的相关数据,一起来进行分析计算,设计针对客户的个性化保险方案是一个发展方向。那么,由于数据类型、复杂程度、获取源头、数据量各方面的复杂性,显然分布式数据库会更适合这样的场景。
关于证券行业,就说一个场景吧,大家买基金股票,看大盘的投资客户端,有没有发现互联网平台的从速度和实时性上都要比普通证券公司的APP要好一些?关键原因是不是在数据库架构上?
3. 关于金融行业分布式数据库转型的选型策略及关键点的讨论。
【问题分享】
Q:对于开源分布式数据库怎么看?如何挑选和管理好开源分布式产品?
Q:金融业挑选分布式数据库应该看中什么能力?
Q:金融业目前优秀的分布式数据库产品方案有哪些?
Q:银行保险行业的影像平台如果希望从内容管理平台产品转向分布式数据库,该如何选型?
【问题解答】**
面对众多的开源或者以开源为基础的分布式数据库,我觉得得从以下几个方面考虑:
那么在分布式转型的过程中,包括选型及运维的考虑,我觉得需要从以下几个方面去考虑:
1. 质量:产品应该成熟可靠,经过大规模业务持续验证,拥有可信落地案例;
2. 团队:建立能用、会用、用好国产数据库的建设运维团队;
3. 持续:生态持续性要好,产品可以持续演进发展;
4. 服务:不仅包括数据库,更能覆盖金融全技术栈的服务能力。
毕竟,金融行业并不是技术企业,技术是为了业务服务的,大多数中小企业没有必要花费巨大的代价去搞一套自己企业独有的分布式技术框架,利用现成的就好,只不过需要仔细去评估。至于行业标准,现在还没有看到一套正式的标准,但是先行的企业经验可以作为参考。
如果从转型过程或者前期的技术规划上,我觉得从上到下都需要关注。
4. 关于金融行业分布式数据库转型的关键技术问题讨论。
【问题分享】
Q:分布式数据库如何保证业务数据的完整性和一致性?
Q:分布式数据库对传统数据库支持如何?
Q:系统中越来越多的数据库该如何管理和架构设计?
Q:与传统数据库相比,分布式数据库的事务算法应用于传统金融业务系统有什么优缺点?
【问题解答】
分布式数据库与关系型数据库相比而言,事务一致性是其的一个弱项。
但是现实业务当中,其实有很多场景对事务的要求并不是极端的苛刻,只是我们没有好好去挖掘业务的特性。也有一些业务场景是可以接受经过算法改良之后的分布式事务机制的。例如:
如果某一个分布式数据库产品具备类似以上的事务处理机制,无疑是可以作为我们某些业务系统的备选方案。
关于应用迁移是否可以做到应用无感知?
这个有点困难,尤其在金融行业。Oracle 转 Mysql 的时候,会因为二者之间的存储引擎的差异,事务处理机制的差异以及表、块、锁等机制的差异导致一些莫名奇妙的问题。大家只能事先尽量系统化设计考量,过程中遇到问题逐一解决,最终达到稳定过度。这是一个长时间的事情。
关于OLTP和OLAP共用的设计是否合理?
共用可以,从设计角度来讲这是一个失败的设计。各有各的特点,OLTP并发高,锁粒度小但是频繁。OLAP没什么并发,以全表读写为主要特点。这二者混为一起,参数调优都没法儿干。
关于数据库系统架构管理的复杂性问题及解决方法。
其实这个问题,很多企业都会遇到。企业的数据库系统少则几十套,多则成千上万。数据库类型也是五花八门。DBA往往需要好多个,针对不同的数据库系统去做变更、配置、优化。这个问题我相信没有一种产品或者架构能够完全解决。只能通过我们对数据库管理的策略和思路来尽量优化。也就是 “数据库的整合”。
我们可以通过对业务系统对数据存取特点、业务重要性、业务相关性、数据量的规模等等维度把数据库系统进行统合分类,通过这样的手段把数量庞大的数据库个体划分为几个范围。那么同范围的系统是不是看可以考虑数据库的管理策略标准话,数据库的架构采用资源池架构,数据库的配置和变更可以采用同一个平台。例如:有的企业通过业务重要性和数据量的基础维度将数据库进行分片划分,然后采用Oracle 资源池的架构来解决一大堆中小数据库的整合问题。
5. 关于金融行业分布式数据库转型的过程管理问题讨论。
【问题分享】
Q:如何从传统数据库模式过渡到分布式数据库?
Q:从传统OLTP数据库转到分布式数据库,大家踩过哪些坑?
Q:分布式数据库转型过程当中需要关注的要点有哪些(应用层面、数据层面、存储层面等)?
【问题解答】
某银行转型的具体经过:
2018~2019 年,确定基于 Oracle+MySQL 实现双技术栈团队建设,并选择互联网银行业务选择开源 MySQL 方案;
2020 年,试改造, 团队对 MySQL 熟悉后,实现核心业务系统基于分布式数据库上线并开始运营;
2021 年,新老系统并行,数据保证实施同步回老业务系统,如新系统故障确保老系统可用;
2022 年,最终核心交易全量切换,封存老系统。
金融行业的分布式转型,这是一个漫长的过程。如果要选择分布式数据库进行升级换代,那么也必须是从应用、中间件、数据库等纵向全部改造之后的系统才能采用分布式数据库。
在这个过程当中,大家会遇到很多问题,不同的企业、场景、技术架构都会遇到不同的问题。
不同的产品不同的缺陷,下面这个文章总结的不错,可以参考:
https://blog.csdn.net/z136370204/article/details/108821328
在设计和实时过程当中来讲,就关系型数据库,Oracle和MySQL本身的存储引擎是不一样的,对事务的处理机制也是有区别的,所以更多的是要看这些细节的区别可能导致的具体业务系统的问题。当然有些问题可以提前判断,然后通过应用改造避免。有些问题还真就得结合具体应用,实践当中碰到逐一解决。
传统集中式架构向分布式架构转型的过程中,企业需要应用的上层到下层进行一个全方位的思考和设计。
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞4
添加新评论0 条评论