(杨祥合 北京奥星贝斯金融行业解决方案架构师 & 北京金融科技产业联盟高级专家)
最近,关于金融级数据库的话题,行业内讨论热烈。在这方面我想抛砖引玉,分享下自己的观点。
10多年来,我一直在分布式数据库领域探索实践,从DBA到架构师工作经历可以分为两大段。第一段作为数据库管理员,我参与了阿里 “从Oracle到去O”的工作,通过了Oracle 10G OCP和11G的Specilist的认证,在阿里参与Mysql去O、并与分布式数据库OceanBase结缘,是OceanBase第一批DBA,从OceanBase 0.3版本开始使用,从此迈入原生分布式数据库行业。第二段作为数据库及存储架构师,我从0到1建成了浙江网商银行的数据库存储架构,七年时间建成多地多活、单元化、云原生、国密密态的银行,其中多地多活的单元化方案获得2019人民银行金融科技发展奖二等奖。
多年来,基于技术和产业一线的工作经验,作为核心作者之一,我参与编写了架构畅销书《金融级IT架构-云原生数字银行解密》。恰逢金融行业数字化转型的浪潮,心中燃起服务金融行业的执念。2021年底来到奥星贝斯(OceanBase),聚焦服务金融行业客户。
中国信通院《大数据白皮书2018》(第11页)指出“一致性协议的诞生为分布式数据库发展铺平了道路”,并明确列出事务型数据库架构演进图。
这份白皮书中明确了一致性协议对分布式数据库的重要意义,同时指明了原生分布式数据库是必然方向。换言之,真正的分布式数据库一致性协议是标配。
磁盘固件门及各类静默错误的新挑战:
一些新问题的出现需要用技术去面对、去解决,用今天的眼光去看,传统数据库主备架构、Raid冗余机制对冷数据的磁盘静默错误无效。
2018年,一家企业“前沿数控”的数据在国内某云上全部丢失,将磁盘静默错误推到风口浪尖。
2021年,FaceBook的论文 《Silent Data Corruptions at Scale》,CPU静默错误已成为行业公开的秘密。
(2) 金融级分布式数据库的坚守:
创始人阳振坤老师很早前曾说过“数据一致性是OceanBase的生命线,宁可少做几个功能,要确保数据绝对一致”。今天回头看,数据一致性的五道防线深入内核层,成为该领域新的产品功能的制高点。只有地基打的牢,楼才能盖的高,正所谓“根深叶茂”。
五道防线保障数据一致性
冷数据定时扫描: 发现数据中的错误,如: 磁盘的静默错误等
(1)“三地五中心”的浙江网商银行2022年双11大促全链路联合压测中,性能的容量是国内多家使用大型主机的银行的性能之和。
在《金融级IT架构》一书中披露过,浙江网商银行是“三地五中心”的架构,具备全行业务多地多活的能力,即城市级故障30秒自动恢复、数据不丢。根据一致性协议(多数派协议),5副本下至少要写成功3副本,即需保证每个事务跨城市写成功。 相邻城市之间的距离200多公里,第3城市1000公里以上。 每个事务增加6~8毫秒,即commit语句增加6~8毫秒,DML语句性能不变。
(2)获得2019年人民银行科技发展奖二等奖
网商银行以“三地五中心、多地多活的单元化架构”,获得了2019年人民银行科技发展奖二等奖,项目名称《网商银行持续演进的云单元技术架构体系》,核心特点是性能、容灾两个都要。分布式数据库OceanBase承载着全行的业务基石,而一致性协议是分布式数据库的基石。
从这几点来看,有人认为“OceanBase 节点间实时同步,对任何同城超过50公里以上的机房间,基本也不适用 ”的逻辑,与包括浙江网商银行在内的众多OceanBase实践案例不符,与人民银行科技发展奖中的价值点-性能与容灾兼顾的逻辑不符。
## 3.数据库行业的国际权威测试
TPC-C交易型数据库的榜单上,OceanBase世界第一;如果有更好的实现方式取代一致性协议,那必然有另一款产品取代TPC-C世界第一的位置。
综上,一致性协议(多数派协议)是分布式数据库的根基,中国信通院的大数据白皮书、Google Chunby的作者都给予了肯定。从性能角度,浙江网商银行多地多活的高容灾&高性能兼具,数据库权威测试TPC-C中世界第一排名的成绩,给予了有力佐证。
(1)主流通用PC服务器机型最具性价比
从PC服务器的硬件发展来看,主流机型是性价比最高的,因为其单位功率的电力可提供更高性能。例如,今天我们买电脑不会买赛扬1.0,而会选择I7、I5等这样的电脑。因为主流机型提供更高的性能。在同等算力下,大幅减少机房、机柜、网络等的占用。
如下是,常见主流机型,非最小可用机型。
ARM | X86 |
48*2=96C | 2622=104 core |
512G | 512G |
不仅支持主流机型,而且支持老旧机型与新机型的混合部署,充分考虑到新老服务器过保的情况。例如,浙江网商银行3年、4年前的机型可以与新机型一起在同一个OceanBase集群上提供服务。
(2)分布式数据库的硬件目标是充分发挥主流服务器硬件能力
OceanBase有效利用大内存是"浪费"内存吗?
要充分利用主流机型的能力,数据库内核就需驾驭超大内存管理能力,这恰恰是完全自研数据库的强项。Oracle在一台服务器上部署一个实例可以将资源最大化利用,而Mysql在行业里很少有一台物理机只部署一个Mysql实例的情况。根因是Mysql多核能力以及大内存利用能力要弱一些。从行业部署现状来看,国内使用Mysql的方式,无论单独的使用,还是做成分库分表的体系化部署,都使用单机多实例的方式,一台物理机部署多个实例成为"常态",最重要的原因是CPU、内存利用率差;
新技术用内存换磁盘IO提升生产力。BloomFilter(布隆过滤器)用内存容量换取静态数据的磁盘访问,无论select、insert、update、delete语句都有一个"查询"的逻辑,查询下数据库中究竟有没有符合条件的记录,如果没有记录,就无需实际去执行磁盘扫描。这在传统数据库上是难以实现的,因为持续不断地将修改过的“脏”数据页刷新到磁盘上的逻辑,数据一直在变化。因此,需客观看待技术创新带来的价值,因循守旧、抱残守缺不会成为主流。
LSM能够成为热门架构,其适应时代发展、解决了行业痛点。Google基于LSM架构做成了大名鼎鼎的分布式存储BigTable,OceanBase基于LSM架构做成了分布式数据库登顶TPC-C世界第一。 这12年来,伴随CPU多核、固态SSD的盘的应用,其LSM架构将传统数据库的随机写变成了顺序写,解决了传统数据库在固态盘上的写放大问题。
因为LSM架构,分布式数据库的压缩比5:1 ~ 10:1之间,对业务性能几乎无影响,降本增效明显。
生产服务器的存储空间1台抵传统数据库的5台
大幅节约备份恢复的时间,备份时间是同等数据量的mysql、postgre SQL等的1/5 ~ 1/10,提高了备份恢复的效率
从应用范围来看,LSM 被很多存储产品作为存储结构,比如 Apache HBase, Apache Cassandra, MongoDB 的 Wired Tiger 存储引擎, LevelDB 存储引擎, RocksDB 存储引擎等。
换个角度来看,如果LSM架构存在重大缺陷,你如何看待行业中LSM架构的产品百花齐放。Google的BigTable成为分布式存储领域的经典,OceanBase创造TPC-C的世界记录...
(3)OceanBase数据库支持多样化的部署方式
1.部署方式支持,物理机、裸金属服务器、国内和国外主流云厂商的云虚拟机或者容器化部署。
2.OceanBase可支持国内外各种PC服务器,不存在指定的服务器的情况。因为金融行业客户有各种各样的场景
从技术发展的角度,应用的分布式带来了云原生、微服务化,数据库的分布式带来原生分布式数据库。无论应用还是数据库的分布式客观上都会增加网络占用。那我们会不会因噎废食,从云原生、微服务的架构转回到大单体架构呢?显然是不会的。 因为技术的潮流奋勇向前、不可阻挡。
云原生、微服务增加了网络带宽、增加了链路耗时,但是带来业务的敏捷性。
分布式数据库带来了架构的无限扩展、超强的容灾能力,带来更好的业务连续性。
无线互联网都已经5G时代了,几年前,云厂商100G网络已经试点应用,如果还用100兆带宽,交换机坏了都没地方买;中国电信、中国移动等的千兆网络进家门,当家用网络已达千兆,金融行业万兆网络要求高吗?“东数西算” 推动我国新型算力网络体系构建,打造高速智能网络是基础。2022年9月,打造高速智能网络,中国移动联合中兴通讯完成了全球首个400G QPSK准实时系统模拟现网真实参数传输验证; 5G技术的诞生和应用越来越热门。网络带宽越来越宽是必然趋势,作为IT系统底层的数据库,应该更好的更充分的利用高速网络、多核CPU、超大内存、固态硬盘等等先进的硬件,而不是相反。周小川先生讲“金融业是半个IT行业、数字金融是现代金融业发展的重要特征",作为金融行业的从业者,应积极拥抱IT技术的发展,为行业创造更多价值。
(5)OceanBase使用的服务器多吗?
在某省的两个同等规模城商行,同一家核心系统开发商的V8版本,使用OceanBase的用了18台机器,使用某分库分表数据库的用了35台机器,经行里沟通压缩到30+的机器。
支持一致性协议的数据库部署方式基本一致的。
为了保障备份真实有效,恢复性测试成为必需品,白屏化的备份恢复性测试,让备份更加安全可信。
当一款产品从内部走向外部,简洁易用是基本原则,分布式数据库的复杂度比单机数据库或者基于分库分表的开源魔改库要复杂。此时,“将复杂留给自己,把简单易用留给客户”尤为重要。多年的内部实践经验,优选最有效、最常用的监控指标展现,这是产品易用性的体现。
OceanBase的CEO杨冰2021年说“过去一年OceanBase客户数实现翻倍,达400多家,客户数有目前全国Top 200的头部金融机构中有1/4都将OceanBase作为核心系统升级首选”。从金融到能源、电信,再到国计民生的各个通用领域,OCP管理平台始终守住OceanBase内核的状态,为客户提供集群管理、功能监控、告警等需求。在银行业,从国有大行到中小规模城商行、农商行等,满足通用需求。
从OCP发展的历史来看,从阿里到蚂蚁在内部打磨了10多年,从黑屏到白屏、从功能简陋到繁盛,再到简约的过程。商业化之后,倾听客户的声音,易用性、功能上持续加强。如果有个性化需求反馈,一定能够听的到的。如果是极为小众的个性化需求,大量内部表统计信息的收集,这是原生分布式数据库的巨大优势。作为分布式一体化的设计,大量的监控指标使用内存指针计算的方式(实现方式与Oracle的动态性能视图类似)。
1.监控层面
以客户为中心,通过分类分级,展现关键指标,隐藏次关键指标,选中即可展现。请注意【指标选择】
2.架构层面--融入全行一体化治理体系中
OCP是OceanBase管理平台的简称,作为全行一体化治理的一部分,因此API开放的较为全面。
https://www.oceanbase.com/docs/enterprise-oceanbase-ocp-cn-10000000000379276
1.数据合并是数据持久化的需要
数据落盘是数据库中数据持久化的保障,其必然占用数据库资源,这个过程在LSM架构数据库是数据合并,在传统B+Tree数据库中是近实时的异步刷盘。LSM和Btree各有优势,其中LSM架构优化了写操作,对海量数据写入性能远高于Btree的写入。换言之,LSM架构将磁盘的大量小块随机写入转换为大块的顺序写,大幅提升了磁盘寿命。
2.数据合并对性能影响
以某商业银行的核心系统做性能测试,500并发情况下,做持续性压力测试,检测每日合并中业务影响情况。
每日合并配置: 合并线程数10,开启轮转合并
每日合并效果汇总:
分类 | 合并前 | 合并最低点 | 下跌最大点百分比 |
TPS | 21.7万 | 18.29 | 15.7 |
QPS | 34.4万 | 28.98 | 15.7 |
这里对业务的正常运行是无损、无影响的。
每日合并影响大吗?
即如何理解,每日合并对业务的影响?有人认为,每日合并就不符合金融级交易数据库的标准吗?
当然不是。相较于主备模式的数据库,OceanBase的机器资源利用率是翻倍的,举个例子。
先假定没有资源瓶颈的情况下
3.会话迁移能力分布式数据库都需要
业务高峰期切主节点,就需要会话的迁移能力。从会话迁移的角度看,无论是Btree的数据还是LSM架构的数据库都是需要的,实现机制基本一致的。也就是说,只要是分布式数据库做会话迁移,都会存在处理能力下跌的情况。伴随技术发展和产品迭代,这种会话迁移的影响越来越小。
从目前的数据库实践来看,这款原生分布式数据库在金融行业走出了四条快速转型的路径。
平滑迁移是更快的转型升级路线。某国内头部保险公司,创造了分布式数据库转型中“速度最快、范围最广”的转型案例。
关键特点:
从数据库产品角度,Oracle语法的全面兼容、“一库多芯、数据自校验”的产品能力、历经几十万次验证的迁移、校验一体平台OMS等,对国产数据库行业的发展有借鉴意义。
严谨的方案是更快的转型升级路线,在华中某城商行新一代核心系统2022年上半年在银行核心和村镇银行的多法人核心全面上线。
该行从2018年10月开始使用OceanBase,从客户、账户、权益、交易等业务中台开始使用,3年的持续稳定。2020年下半年开始启动新核心建设,该行有银行和村镇银行两套核心,涉及多法人主体。
特点:
总体来说,前瞻性、多重容灾、超强逃生的能力,实现了业界新高度。
同城双活5副本: 不仅可容忍任意机房级别的故障 或者任意的两个Zone同时故障,如果机房3的距离较远,在机房1故障后,可以选择性的从5副本降为3副本,此时,只要实现机房2的2个副本写成功就可以提交。有效降低己方故障时的耗时,提升业务的性能。
一步到位下大型主机就是更快方案。在某国有大行贷记卡核心从大型主机DB2上,一步到位下移到分布式数据库上。
贷记卡核心一步到位迁移到分布式数据库上来,其重要意义如下:
1.对客户和ISV
新的篇章:云+OB全家桶首个国有大行核心大机下移的案例,具有标杆意义和示范效应
部分金融行业客户已经使用Mysql的情况下,转型到分布式数据库,可以选择OceanBase的Mysql模式,像使用单机数据库一样享受分布式数据库的扩展性、容灾、以及安全性等。
金融行业数据库的需求层次
最上面一行,从全行架构角度来看:
1. 业务连续性是根本要求 ,数据库/应用的双活/多活应该是标配
浙江网商银行三地五中心、多地多活的案例,目前是国内唯一全行业务多地多活案例。
从国有大行的单元化、到多家城商行双活的银行核心系统案例,已经上线。
注意: 这里多活是指互相之间数据不丢,数据库、应用服务可接管 ,不是把数据简单拆分。
2.业务的敏捷性、安全性是业务发展的要求 ,微服务、云原生(双Mesh)带来业务的敏捷性,透明存储加密、透明传输加密带来数据的安全性。
具体下来,金融级分布式数据库应有能力TOP 10:
关键能力 | 用途 | OceanBase | 备注或者举例 |
数据一致性 | 数据库的生存之本,磁盘静默错误显示出传统数据库技术的不足 | 5道防线、7层校验和冷数据自校验,防静默错误 | 多种静默错误以及PC服务器宕机情况下,对数据一致性形成挑战。eg:前沿数控一家企业的数据在某云上全部丢失,根因是磁盘静默错误 |
一库多芯 | 解决芯片供应问题 | 一库多芯,“零”计算主动校验,主备集群、集群内双混部署模式 | |
Oracle兼容性 | 业务系统平滑迁移到分布式数据库上来 | 主打Oracle兼容性 | |
透明加密 | 既是金融监管的要求,也是金融消费者隐私保护的诉求 | •支持,性能损耗2%~4% | 传统数据库性能损失50% |
云原生DBMesh | 云原生两大Mesh之一 | 支持,目前蚂蚁集团、浙江网商银行,全面DBMesh化。具有应用极速启动、多版本并行运行、透明传输加密、账密托管、容器级SQL限流等优势 | 传统数据库上做分库分表,其SQL代理是胖代理,无法与应用SideCar模式部署在容器,因为本质是计算层,对CPU和内存的消耗是不确定的。目前只有一种数据库支持DBMesh,且有大规模应用实践。 |
高压缩比 | 1.降本节约服务器数量2.提升备份恢复SLA3.降低历史库归档频率 | •所有客户均开启,性能几乎无损•压缩比5:1~10:1 | 如果1台服务器顶5台,备份恢复效率是传统数据库5倍。这就是技术创新带来生产力。 |
云原生-DB租户隔离 | 对应微服务的数据库端资源隔离 | 微服务应用使用容器级隔离,对应的数据库端就是数据库的租户隔离。租户资源动态分割,满足不同时段业务对数据库资源要求。 | 单机数据库中Oracle支持租户隔离,即PDB和CDB的能力; 在分布式数据库的产品中,目前只有一种数据库支持多租户。 |
产权 | 1.是否存在法律风险2.是否可增强竞争力 | 完全自主知识产权,非Mysql/postgreSQL等开源魔改 | 1.甲骨文对 mysql拥有完全知识产权2.GPL协议在中国有法律效力,已有法院判例 |
多地多活单元化案例 | 1.支持同城双活、多地多活2.支持单元化 | 浙江网商银行多地多活案例国有大行及多家城商行多活案例 | |
扩展性 | 1.平滑扩展2.无库或者分区热点 | •水平扩缩无影响•分区水平扩,热点做二级分区,做分区重定义 |
最后,洞察分布式数据库的行业,以三个观点结束本文
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞15
添加新评论1 条评论
2023-06-30 11:08
flywiththewind: @yulu4314 中小企业还有必要去o么