数据采集、数据融合、平台能力构建、AI算法支持等方面最新技术实践分享>> 了解详情
写点什么

从 0 到 1,我的分布式数据库落地经验谈

  • 2022-02-17
  • 本文字数:3884 字

    阅读完需:约 13 分钟

从 0 到 1,我的分布式数据库落地经验谈

采访嘉宾:周传凯。天津银行股份有限公司,数据中心系统软件组组长、数据中心云数据库架构师、数据中心云系统架构师。

 

对于金融行业而言,IT 系统的每一次架构换代升级都是关系到企业整体业务安全性、可靠性,甚至可能影响金融市场稳定性的重大事项。与此同时,金融企业面对迅速增长的业务规模与日新月异的市场需求又必须紧跟趋势,及时完成 IT 系统技术升级,从而保持自身的市场地位与竞争力,满足用户多元需求。在这样的背景下,企业 IT 部门就要充分把握好技术架构换代过程中的平衡,在确保安全可靠的前提下尽快充分利用新兴技术的各项优势。

 

近年来,随着云计算、微服务等技术理念逐渐取代传统的单体架构,数据库领域也开始迎来由分布式数据库主导的变革潮流。对于银行等金融企业而言,分布式数据库可以带来很多显而易见的收益,但出于金融准确性、安全性、稳定性的极高要求,如何在不影响业务可靠性的前提下平稳落地这一新兴技术,是很多企业管理者和 IT 部门面对的挑战。在国内,天津银行自 2018 年起就开始了分布式数据库落地的实践探索,至今已经取得了值得称道的成果,完成了项目立项之初设定的各个目标。近日,InfoQ 采访了天津银行数据中心系统架构师周传凯;他从个人经验出发,分享了金融企业从 0 到 1 落地分布式数据库的完整历程。

 

从传统数据库到分布式数据库,转型的驱动力源自何处?

 

2018 年之前,天津银行主要使用的数据库分别是 Informix 和 Oracle 两种单体数据库。前者运行在 AIX 小型机上,主要处理记账类业务。后者运行在较新的服务器上,处理的业务更加全面。

 

回顾历史,金融行业的 IT 系统曾经长期被 IOE(IBM、Oracle、EMC)的单体软硬件架构统治。国内各大银行每年都要投入巨资维护和更新基于 IOE 产品的 IT 系统,天津银行所使用的 Informix 与 Oracle 数据库就是一个典型案例。在云时代到来之前,IOE 体系以其强大的性能、极高的稳定性/可靠性和广泛深厚的功能积累深得金融企业信赖,很少有人试图对这一局面发起质疑和挑战。

 

但随着时间推移,尤其是云原生潮流席卷全球 IT 行业后,IOE 体系遭遇到了前所未有的冲击。由于 IOE 软硬件架构本质上仍以传统的单体设计为主,难以适应云时代去中心化、分布式的设计开发理念;相关产品高昂的购买升级与维护成本也令企业愈加不堪重负;最重要的是,IOE 软硬件很难满足新时代金融业务快速增长和变化的业务需求,逐渐成为企业竞争力提升道路上的“绊脚石”。正因如此,近年来金融行业开始探索利用围绕云原生理念的 IT 系统架构,逐渐替换传统的 IOE 解决方案。

 

在天津银行的运营实践中,Informix 与 Oracle 两种传统数据库就随着业务增长而逐渐暴露出了一系列问题:

 

1. Informix 的维护、迭代和演进高度依赖 IBM,存在对接维护人员经常更换、长期维护较为困难的问题;

2. Informix 不具备横向扩展能力,只能通过硬件更新实现性能提升;

3. 数据量达到 PB 量级后,Oracle 会出现性能瓶颈,需要做分区表等优化;

4. Oracle 对双活切换不够友好,双线切换延迟较大。

 

与此同时,天津银行正在与蚂蚁集团等外部企业展开合作,并引入敏捷开发、分布式事务等技术理念,自然就需要将数据库从传统的单体架构升级为分布式架构,与整体的开发变革步伐相适应和匹配。2019 年,天津银行引入阿里云的整套产品线打造专有云,周传凯由此接触到了 100%自主研发的 OceanBase 原生分布式数据库产品,开始带领银行 IT 部门正式踏上了分布式数据库落地之路,开启了银行在数据库领域对传统架构的升级的旅程。

 

回顾银行选择分布式数据库产品的经历,周传凯认为这里的关键在于专有云的架构选项。在他看来,分布式数据库与专有云是一个整体,分布式的数据场景、微服务化的业务和分布式数据库可以共同形成 1+1 大于 2 的效应。因此,很少有金融企业会单独购买某种分布式数据库产品,更多情况下还是会像天津银行这样,将分布式数据库作为专有云架构的一个捆绑解决方案。但与之前的 IOE 时代相比,企业在云原生升级选型时可选的解决方案提供商数量要多很多,厂商之间的竞争更为激烈,技术迭代升级步伐更快,这样的局面自然更符合行业客户的长期利益。

 

分布式数据库落地实践,步步为营才是成功之道

 

如前所述,金融企业在落地新兴技术架构时都会采取非常谨慎的态度,天津银行自然也不例外。选定 OceanBase 后,银行为分布式数据库的落地安排了三期工程,分为三年实施。一期工程主要以技术验证为目的,承载一些银行二类产品的开户、记账等功能。在这一期间,周传凯带领的团队遇到了非常多的问题,往往需要与 OceanBase 技术团队共同探讨和解决。

 

2020 年的二期工程中,银行将 OceanBase 从 1.4.79 升级到了 2.2.76,引入了一些 Oracle 相关特性。二期工程开始将银行自营网贷、风控和门户转移到 OceanBase,并规划了同城双活架构。这一过程中涉及的主要问题更多是架构和规划层面,周传凯会经常与阿里团队探讨诸如链路延时、多副本冗余度等细节和技术目标。


2021 年三期工程开始后,天津银行在某次巡检中发现在单体时代传统的业务上线、审批流程不一定适应云原生、分布式数据库的使用场景,并通过此次事件对业务上线流程做了优化。经过打磨调优后,OceanBase 与业务开发端的协同能力得到增强,可用性、安全性进一步提升,也为未来更多业务逐步上云巩固了基础。天津银行上线了一个重要的银行卡系统。该系统涉及的业务场景需要对每一笔与银联系统的交易做流水表查销,交易量达到 1100 万规模。然而上线半个多月后,结果发现原因在于缺少字段统一索引。虽然问题很快得到了解决,但这也暴露出了新业务上线存在的挑战。为此,周传凯团队与 OceanBase 团队做了深入讨论、调优和培训,最终圆满解决问题的同时,为后续的迁移工作保障提前打好了基础,这也得益于 OceanBase 数据库是 100% 自主研发的国产原生分布式数据库,在遇到一些核心应用的问题的时候,原厂研发人员可以快速定位进行优化,通过快速的迭代精准解决用户痛点。

 

归根结底,企业从传统单体数据库转向分布式数据库的最终目的是要更好地解决业务实践中遇到的种种问题和挑战。从 2019 年的第一期工程开始到现在,周传凯团队对分布式数据库的优势与收益有了更加深入的体会:

 

1. OceanBase 高度兼容 Oralce 和 MySQL 引擎,实际使用中非常便利。

2. OceanBase 的数据同步方式很好用。与传统数据库往往只能在两个副本之间同步的设置相比,OceanBase 可以实现三个、五个、七个副本的同步,获得灵活的扩展能力。

3. OceanBase 的透明迁移能力可以在业务运行状态下完成很多升级事项,对于强监管的金融行业来说非常便利。业务不中断意味着不需要根据监管要求提前报备,可以有效改善客户体验。

4. OceanBase 对容灾建设有着很强的支持能力,可以轻松实现多活、副本迁移等工作。

5. OceanBase 具备灵活的资源扩展能力,一个租户可以迅速无停机扩展 CPU 核心数量,在高压力交易场景实现实时扩容,很好地应对未来的业务增长要求。

 

除此之外,周传凯还发现 OceanBase 的运行效率与优化改进是息息相关的。例如现有的分库分表的具体实现方式、索引方案等等,都可以根据 OceanBase 的实际运行情况做针对性配置调整和优化。经过实践中的逐渐优化过程,OceanBase 就能发挥出很高的效率,相应的优化措施也可以沉淀为具体的技术规范。企业使用 OceanBase 的时间越久,积累下来的领域知识也会越丰富,从分布式数据库中获得的收益自然就能水涨船高。在实际使用过程中,也发现 OceanBase 的 LSM Tree 压缩技术可以极大的节省原先的存储资源成本,某些特定场景下甚至可以节省 90%以上,这也给整个项目组带来实实在在的成本节省。

 

展望未来,分布式数据库的改进方向

 

谈到对分布式数据库未来发展的期待,周传凯希望相关产品的定价能够更加实惠便宜。从天津银行的实践过程来看,业务系统的云端迁移花费的成本巨大,系统改造、重构和新业务开发都需要资源投入。在这样的背景下,留给分布式数据库的预算必然吃紧,这时如果产品本身的价格能够更加优惠,银行就能加快原有业务的升级步伐。

 

另一方面,如果分布式数据库能够更多兼容传统数据库的功能、语法和特性,也能有效节省客户上云改造的成本和时间。例如 Oracle 的 AWR 运维性能分析报告,以及调优功能逻辑模块,都是分布式数据库可以参考借鉴的技术特性。从产品层面,周传凯也期待与 OceanBase 团队的合作能够不断引入更多前沿技术理念和新的产品功能,并更早转化为实际的业务收益,实现降本增效的目的。

 

总结:分布式数据库是行业大势所趋

 

从行业层面来看,周传凯认为分布式数据库的全面普及已经是不可阻挡的趋势。即便在金融行业这样业务要求非常高的领域中,分布式数据库也已经具备了替代传统核心的能力。在云原生浪潮的推动下,分布式数据库作为云原生架构不可分割的一环,必然会逐渐取代传统单体数据库成为企业数据库的主流选项。但在具体的落地过程中,分布式数据库产品开发商和客户仍需要通力合作,根据实际业务需求和实践中遇到的挑战对产品进行持续打磨和优化,不断降低产品成本和部署难度。

 

长远来看,从单体架构发展到微服务、云原生、分布式软件体系,背后都是不断增长和愈加复杂多变的业务需求推动的。随着业务规模的扩张,企业对数据价值和安全性更加重视,分布式数据库天然具备的高可扩展性、高可用性、灵活性、高性价比等优势会越来越凸显。在金融行业,金融科技兴起,行业全面转向云原生的大背景下分布式数据库成为主流也只是时间问题。天津银行与 OceanBase 的合作经验为行业在这一领域的探索提供了很好的榜样参考,也标志着分布式数据库在金融领域即将迎来大规模普及,为企业数字化转型带来可观价值与驱动力。

2022-02-17 14:364027

评论 2 条评论

发布
用户头像
“1. Informix 的维护、迭代和演进高度依赖 IBM,存在对接维护人员经常更换、长期维护较为困难的问题;”  

说的好像自己公司的人不离职似的。
2022-01-28 09:15
回复
我也注意到这点. 可能意思是 IBM 在中国发展不够稳定吧. 我们之前还期望 Cloudant 服务进入中国, 但遥遥无期.
2022-01-28 09:56
回复
没有更多了
发现更多内容

能源区块链研究|区块链与核电安全

CECBC

区块链 核电

第五周作业

晴空万里

极客大学架构师训练营

JVM垃圾回收原理,秒杀系统架构方案

garlic

极客大学架构师训练营

架构师训练营第 9 周课后练习

叶纪想

极客大学架构师训练营

真零基础Python开发web

MySQL从删库到跑路

Python django Web bottle

架构师训练营第九周课程笔记及心得

Airs

二分法求平方根,swift面向协议编程protocol从入门到精通、《格局》吴军著读后感、John 易筋 ARTS 打卡 Week 27

John(易筋)

collection ARTS 打卡计划 格局 吴军 李嘉图定律 面向协议protocol编程

【架构师训练营】第九周作业:性能优化

MindController

秒杀系统

架构师训练营 week5 学习总结

花果山

极客大学架构师训练营

5G+工业互联网的中国登山队,如何攀跃“产业化”山峦?

脑极体

应届秋招生,熬夜吃透华为架构师这份‘典藏级’计算机网络+计算机操作系统,成功上岸腾讯

网络协议 编程之路 计算机知识

第九周作业

极客大学架构师训练营

架构师训练营 - 第九周总结

一个节点

极客大学架构师训练营

Java 中常见的细粒度锁实现

rookiedev

Java 多线程 细粒度锁

秒杀系统

橘子皮嚼着不脆

架构师训练营—第九周作业

Geek_shu1988

【架构师训练营第 1 期 09 周】 学习总结

Bear

极客大学架构师训练营

架构师训练营 week5 课后作业

花果山

极客大学架构师训练营

Week5 作业1

shuyaxx

架构师训练营第 9 周作业

netspecial

极客大学架构师训练营

架构师训练营第二期 Week 5 总结

bigxiang

极客大学架构师训练营

Week 9 作业01

Croesus

一次用户故事拆(SPIDR)法实践

Bruce Talk

Agile 用户故事 User Story

架构师训练营 1 期第 9 周:性能优化(三)- 总结

piercebn

极客大学架构师训练营

InfoQ 写作平台的魔力

Yolanda

第9周作业1

Yangjing

极客大学架构师训练营

助推城市智慧化!正舵者携手中科院演绎区块链魅力

CECBC

区块链 人工智能

技术选型总结一

Mars

技术选型

【喜讯】Apache DolphinScheduler 荣获 “2020 年度十大开源新锐项目”

代立冬

Apache 大数据 开源 DolphinScheduler Apache DolphinScheduler

第9周作业2

Yangjing

极客大学架构师训练营

架构师训练营第二期 Week 5 作业

bigxiang

极客大学架构师训练营

从 0 到 1,我的分布式数据库落地经验谈_架构_王强_InfoQ精选文章