商业银行如何进行分布式数据库选型思考

Posted 2021-04-29 数据和云

行业背景

 

1、银行业为什么需要采用分布式数据库？

背景及现状：

在传统数据大集中的环境下，银行核心系统很容易发生故障，而且一旦发生故障，影响面将特别广，带来很大的舆论压力和监管压力，历史上大型商业银行核心系统故障的例子不在少数。而且传统的集中式架构不易扩展，各模块间高度耦合，最终造成核心系统体量太过庞大、业务太过繁重。

分布式数据库优势：

企业采用分布式数据库，我觉得有多方面原因：

① 传统的数据库是否已经难以承受当前的负载

② 是否需要规避全局风险

分布式数据库天然可扩展的架构正好解决了上述问题。分布式数据库项目既可以避免将鸡蛋放在一个篮子里，又可以水平扩展，提高吞吐量。但是目前分布式数据库总体还不是很成熟，因此需要全面的评估测试后才能决定。

 

2、如何评估银行分布式数据库项目的整体成本？

成本可以分为开发测试成本、数据库的软硬件成本、运营维护成本等。开发测试成本主要是开发该项目的人力成本，这个因项目而异。分布式数据库的硬件成本主要包括PC服务器加本地SSD盘，软件成本因厂商而异。大致如下：

硬件成本	服务器	数万~数十万
	SSD盘	数万
软件成本	数据库软件	数十万~数百万
开发测试成本（自行开发）	人力研发成本	数百万
运营维护成本	服务费	数十万

 

 

3、银行行业中用分布式数据库的多吗？现在是什么形势？

目前银行业对分布式数据的使用还是持一个比较谨慎的态度，但是各大银行都在进行分布式数据库的探索，包括选型测试等。目前有些银行已经在核心系统上线了开源的分布式数据库，其他还有些银行在和一些企业进行联合创新研发，我行目前也在积极探索中。

 

4、在银行业中，分布式数据库的供应商有哪些？

目前市面上分布式数据库产品很多，比较流行的主要有pingcap的tidb，巨杉的sequoiaDB，阿里的OceanBase、polardb，腾讯的Tbase、tdsql，华为的gaussdb，亚信的antdb等。各个产品大致特点如下：

产品	特点
TiDB	由tidb、tikv、pd、tispark等组件组成，底层使用rocksdb kv存储引擎。Pd负责全局事务管理，数据层基于region级别做raft复制，节点间数据根据负载实时移动。产品开源、轻量、社区生态良好，是互联网企业分布式数据库首选。
SequoiaDB	Nosql数据库，在金融行业历史数据平台和归档平台上有着十分广泛的应用。目前加入了mysql server层做sql解析，正在做全局事务管理器，底层是巨杉的可插拔式多模存储引擎。产品整体在朝着交易型newsql数据库方向发展。
OceanBase	阿里为应对淘宝双十一等业务场景由蚂蚁金服团队专门开发的数据库，因为数据库有着一定的场景局限性，所以目前在市场上应用其实并不广泛，而且在双十一场景下为了保证性能数据库是基本不允许使用分布式事务的。
PolarDB	阿里研发的云数据库产品，采用计算存储分离的架构，由上层计算层dbserver和存储层chunk server组成，之间通过rdma高速网络连接。计算层基于mysql或者postgresql数据库，能够做到弹性伸缩。
Tbase	基于经典pgxc架构做的偏分析型分布式数据库。
TDSql	腾讯基于mysql半同步做的分布式数据库，使用zookeeper做元数据管理，在上层加入网关层做路由转发个主备切换。
GaussDB	华为研发的金融级分布式数据库，基于经典pgxc架构，但是做了很大的改动，目前Gauss300是面向交易型的分布式数据库，具备高可靠、高性能、强一致等特点。
Antdb	基于经典pgxc架构开发。

 

 

方案设计

 

5、在分布式数据库项目中，如何进行技术路线的选择？

分布式一般分为三条技术路线：分布式访问客户端、分布式中间件模式、分布式数据库模式。其中分布式访问客户端对应用侵入性大，改造难度很高；分布式中间件则类似mycat等产品，在数据库和应用间架一层proxy，这种方案无法支持分布式事务、也无法支持跨库关联，分布式数据库方案则将分库分表等中间件实现的功能下推到数据库层面来做，对应用透明，应用就像使用单机数据库来使用分布式数据库，同时天然地支持分布式事务。

 

6、如何进行分布式数据库项目的系统方案设计？有哪些具体的设计内容？

系统方案主要包括：

①如何进行服务器选型：

一般分布式数据库都会采用廉价x86 pc服务器，搭配本地ssd固态盘、万兆网卡，硬件成本较低。

②软件规划和部署方案：

分布式数据库组件众多，而且每个组件都有高可用备份，所以在有限数量的服务器下进行组件的分配要尽量考虑达到各个服务器负载的均衡，gtm作为分布式数据库的瓶颈尽量和他们组件分开部署。

③监控方案：

监控一般可以采用开源的zabbix进行定制化开发，当然也可以基于grafana+prometheus的方案做监控。

④如何进行调优：

因为不同厂商研发的数据库sql优化器及执行计划都有所不同，所以要根据不同产品进行学习。

⑤备份方案：

分布式数据库如何做一致性备份也是研发难点，要做到真正意义上的pitr就需要做到分布式环境下每个全局事务的“barrier”操作。

⑥应急方案：

因为分布式数据库还处于发展阶段，还不成熟，技术比较复杂，所以生产环境下要制定详细的应急方案，让不了解分布式数据库的同事也能够在出现问题时按照手册操作。

 

7、在分布式数据库项目中，为进行系统规格设计，如何进行定量需求分析？需要收集哪些需求数据信息？

主要考虑以下几个方面：

①系统的最大并发数：

为了节省成本，多套小系统可以共用一套数据库，但是负载很大的高并发场景还是独立搭建。

②系统的最大数据量：

多租户系统下需要考虑各个系统的数据量之和。

③系统最大可容忍的业务中断时间：

分布式数据库节点宕机并不是对业务没有任何影响，主节点宕机都涉及到一个切换的问题，切换就是影响业务的时间，要充分评估业务能否忍受这么长时间的中断。

④系统的迁移成本：

分布式数据库不可能做到oracle、db2、mysql所有数据库的百分之百兼容，所以不同类型的数据库在迁移上都会或多或少的涉及到应用的改造。

 

8、如何解决分布式数据库项目中的某个难点问题？

我觉得分布式数据库主要有以下几个难点：

①分布式事务：分布式事务的实时一致性是分布式数据库研发的难点，cap理论中分区容错性是一定要保证的，那么在c和a中我相信对于银行用户应该会牺牲可用性来保证一致性。

②性能：为了保证事务全局一致，分布式数据库都需要一个全局事务管理器gtm，用于分配全局事务id，任何一个事务开启都需要先去gtm申请事务号，这样gtm就会成为分布式数据库的性能瓶颈，厂商所宣称的性能和机器数量成正比就要打个问号了。

③备份恢复：如何进行全局一致性备份，如何支持全局的前滚恢复。

④高可用：分布式数据库宕掉节点或多或少的都会造成数据库hang一段时间，对标成熟的互联网主备架构的切换时间，这个还需要优化。

 

9、在分布式数据库项目中，什么模块如何进行设计？

分布式数据库一般包括如下几个重要模块：

① 访问层：也叫SQL转发层。这一层定位在SQL执行计划的生成和下发，多个访问层节点理想情况下要进行无状态设计，使用负载均衡技术统一对外提供服务；负责数据的排序、归并等集合操作；负责分布式事务的控制。

② 数据层：数据经过分片后存储在不同的数据节点上，数据节点根据协调节点的请求进行读写数据文件，对数据进行节点内的预处理，同时通常具有一主多从的多副本数据复制能力。

③ 全局事务管理器：处理全局事务，为各协调节点生成唯一的全局事务编号和全局序列号。因为是分布式数据库的瓶颈，为了减小gtm的网络交互，可以设计为事务id批量分配，一次分配一段事务号。同时也可以将事务号存储在分布式存储中，比如etcd，这样能避免一些性能和高可用问题。 

  

10、分布式数据库上线后，如何对运维工作进行管理安排？

分布式数据库类的运维工作主要包括如下几类：

① 准备常用运维脚本、应急手册、运维手册等。

② 做好监控，通常要与监控工具进行对接和整合。

③ 做好相关技术手册培训。

④ 做好生产演练，如定期的重启、切换等。

数据和云

ID：OraNews

如有收获，请划至底部，点击“在看”，谢谢！

  |  |  |  |  | 

  

 |  | |  |  | 

 |  |  |  |  

 |  |  |  |   |  |  |  | 

云和恩墨大讲堂 | 一个分享交流的地方

请备注：云和恩墨大讲堂