随着近年来互联网、云计算、大数据、人工智能等技术的飞速发展，银行业务量、数据量也呈现爆发式增长趋势，银行业务发展与传统关系型数据库已经呈现出非常多的矛盾。这主要表现为，数据量爆发式增长与传统数据库有限容量之间的矛盾；业务处理的高并发系统压力与传统数据库性能无法水平扩展之间的矛盾；越来越高标准的业务连续性要求与昂贵的传统数据库容灾技术越来越难以满足要求之间的矛盾。因此，我行新核心系统在解决传统核心系统面临的问题的同时，需要实现传统银行业务向数字化方向转型需求，新核心系统建设的很重要的一个考虑点，需要具备支持海量数据场景下的高性能、高扩展、高可用等关键特征的数据库，从而引伸出银行核心数据库由集中式向分布式架构转型的需求。然而引入分布式数据库必然会引起核心应用适配的问题，应用和分布式数据库的适配性改造是难度最大以及最需要资源投入的部分，既需要应用的适配改造，甚至数据库层面也需要做一定的改造，我行采用的方式是找专业的团队做专业的事，找应用的厂商做应用，找数据库的厂商做数据库，最关键的是由行方、应用厂商、数据库厂商组成技术攻坚小组，专门解决各类改造过程中的问题，也能达到培养行方开发和运维人员的目的。

我行新核心系统的整个改造实施过程分为两个阶段，第一个阶段是产品适配和功能性改造，第二个阶段是性能优化。整个改造过程是从简单到复杂，我们是先从高频交易入手，集中处理与高频交易相关的业务以及子系统，然后是跑批类交易，跑批与高频交易相比， SQL 相对复杂冗余但是占总交易类的比重较低。解决了高频交易其实就已经解决了大部分匹配问题，我行在这个过程中积累了丰富的调优经验，这些经验再应用到其它业务系统中可以更方便迅速地解决问题。

本期的线上分享嘉宾会就这个分布式数据库如何与核心应用适配进行大量经验和难点分享，帮助大家在引入分布式数据库克服核心应用适配改造的挑战。

Q1：传统核心架构向分布式双活架构迁移过程中，应该考虑哪些关键因素？

目前我行设想将核心系统由传统架构迁移至分布式微服务双活架构，作为操作系统低层运维人员，需要关注哪内容？

lulihuan1987 数据库管理员 , 张家港行

【 A 】 您说的这个情况是核心应用层面的集中式向分布式微服务架构转型的场景，目前核心应用微服务架构是个必然的趋势，而且有不少成功的案例。

应用微服务架构这块不是太专业，我谈谈我个人的理解，不够全面，希望对您有帮助。

对于系统运维人员，主要关注微服务框架行业应用情况、微服务架构的高可用情况（RTORPO）、灾备方案（或双活）、组件部署方案（云、虚拟机、容器等）、监控和管理平台情况以及与行内运维平台对接情况、应急预案等；

对于应用运维人员，除了要关注典型业务场景、业务流程外，微服务架构特有的业务拆分场景、异常情况下一个交易多个事务的一致性等问题。

对于数据库人员，主要关注微服务架构采用的数据库情况，如果采用分布式数据库，可以参照我们本次讨论的核心与分布式数据库适配的相关问题。

Q2：如何实现核心业务系统的传统数据库架构向分布式数据库转型？

如何实现核心业务系统的传统数据库架构向分布式数据库转型？分布式数据库在解决高并发和高扩展性上有哪些优势？

JanXC 系统架构师 , nec

【 A 】 回答这个问题得需要勇气啊，核心业务系统的数据库，重中之重啊。对于这个问题，我觉得分两方面，一方面需要从业务体量及发展上来看，是否需要这也做，承担分布式数据库架构相比传统架构在横向扩展方面有先天优势，但我们的业务是否到了需要横向扩展是否到了需要频繁扩容的地步，另外分布式数据库在简单事务处理方面的性能是低于传统的集中式数据库的，这个需要注意。 最后，是怎么做的问题，我可以很明确的指出，传统数据库架构改为分部式数据库，系统架构方面一定要重构，代码进行改造，当你要对系统重构的适合，对业务进行模块化拆分，程序方面的拆分以及数据库方面的拆分优化，一个大的集中式数据库拆分为低耦合的小数据库，那是否还有必要进一步使用分布式的数据库架构呢，这个我认为必要性不大

Q3：分布式数据库建立的必要性？

分布式数据库带来人员成本和设备成本的上升。而带来的性能的提升有时是不足以cover住这些成本的。请问，如何评估企业的业务是否适合于部署分布式数据库？

lulihuan1987 数据库管理员 , 张家港行

【 A 】 我们目前采用的是TDSQL（MySQL版本）数据库，其提供了分布式版本和非分布式版本，分布式版本是数据分片的，非分布式版本是数据不分片，为集中式数据库主备集群，两种数据库统一由管理平台管理，均实现自动化运维和智能运维。

我们根据我们行的业务规模，对一般业务系统，单节点的物理机性能足以满足其未来3-5年业务发展需求的，我们会采用非分布式版本；对于关键业务系统，像核心系统、互联网类、支付类、信贷类，后续随着业务的发展单节点（也受物理硬件限制）是无法满足业务发展需求的，会结合业务发展进行节点扩容的，我们通常采用分布式版本；

所以我们主要看几方面：业务系统等级、业务系统性能要求、业务系统扩展性需求、数据库所在物理设备性能极限，优先采用分布式数据库。

这里顺便提一下，2019年中国人民银行印发《金融科技（FinTech）发展规划（2019-2021 年）》（银发〔2019〕209 号）金融科技发展三年规划中提到的“加强分布式数据库研发应用”的要求，目前已经接近收关，同时人民银行目前在进行XC试点，其涉及分布式数据库的应用，所以2022年明年起的分布式数据库应用的推广的力度可以大胆的预测一下，到时候看性能和成本可能只是一方面了。

fanyqing 系统架构师 , 厦门银行

【 A 】 是否要建立分布式数据库，还是要基于场景和具体的业务需求，不能一概而论。 分布式数据库本质上是物理上分散而逻辑上集中的数据库系统，利用分布式事务处理、数据自动分片、数据多副本存储等技术，将分散在计算机网络的多个逻辑相关节点连接起来，共同对外提供服务，因此，具有良好的扩展性，适用于大并发和海量数据的处理。但因分布式数据库将数据分散到各个节点上，需要利用分布式事务来保证数据的一致性，因此，必然会带来额外的开销，这就要求在数据库设计时，必须充分考虑应用产生的数据特点，合理选用分区键和数据分布策略，尽量减少跨节点的分布式事务，以提高数据库性能。故对设计人员的要求也较高。所以,如果应用系统需要处理的数据量不大，可用传统的集中式数据库，而不需要分布式数据库。

赵海 技术经理 , 大连

【 A 】 这是大家在分布式转型的时候，面临的首先要问题。也就是说我们为什么要进行分布式的转型？ 其实这个问题我觉得取决于两点：

1、 现有的 数据库 系统是不是已经无法支撑由于互联网业务转型带来的一系列需求？例如并发性，扩展性和灵活性？如果是那么分布式数据库无疑是我们应该研究的东西。

2、 传统架构下的一些平台是不是伴随着业务的不断更新，出现了新的数据类型或者数据结构变得复杂化了，比如说一些新的非结构化、半结构化影像数据？

如果没有以上问题，那么建设分布式数据库的步伐可以放缓，或者作为试验田。

JanXC 系统架构师 , nec

【 A 】 主要还是业务需求和系统架构吧。业务数据量非常大，每天的计算和落库数据很多，集中式数据库的锁等待问题严重，则有必要，但是如果应用尚未支持，则单纯数据库分布式意义也不大。 所以还是得从当前数据库的数据量、并发以及吞吐等情况综合衡量，当真的集中式满足不了的时候，提前规划。

孔再华 数据库运维工程师 , 中国民生银行

【 A 】 分布式数据库通过横向扩展资源来实现性能的扩展和高可用性的提升。所以看起来这项技术就是未来发展的方向，而当前也确实涌现出很多的优秀的分布式数据库产品。然而作为新兴的数据库技术，分布式到底能解决什么性能问题，是否也会存在新的瓶颈，带来新的损耗？分布式数据库的技术复杂性又会带来运维成本的提升，那么这些提升又是在什么方面呢？是不是预示着数据库运维已经面临一次很大的变革转型？下面仅仅代表个人的看法：

1、 分布式的性能不是万能的，但是必须的

从金融业内对分布式数据库技术的测试来看，采用不同分布式技术的数据库产品在测试里普遍出现了性能偏好。也就是使用的数据库技术主要是为了解决一类问题。面向tp的分布式数据库解决大表和热点数据等问题，通过数据分片和事务分发实现性能提升。面向AP的分布式数据库通过算子优化计算下推等方式，充分利用节点的分片计算性能来提升AP业务的速度。而部分存储计算分离的分布式数据库主推运维便利性。但是这些分布式技术可能带来延时变长，交互瓶颈和数据重分布等可能出现的分布式环境特有的问题，所以还需要搞清楚这些分布式数据库的缺点，避免踩坑。

所以面向特殊性能需求，选择合适的分布式数据库，这是最切合实际的做法。

2、 分布式数据库的复杂性对于运维带来的不仅是挑战，也是运维模式的改变。

分布式数据库的运维存在两面性，一方面新的技术复杂，另一方面运维分布式数据库的方式也在发生根本的改变。为了充分利用分布式数据库的能力，相信很多的客户更愿意使用多租户的方式来管理业务对数据库的需求。未来分布式数据库应用的分水岭不仅仅是性能，还在于这种多租户的管理能力。而分布式数据库的集中式运维，与数据库上云后的智慧运维其实是相似的。所以大家都要开始新的运维模式转变，不如从分布式数据库开始做起。

3、拥抱分布式，拥抱云，现在就开始

分布式数据库和数据库上云一定是趋势，现在正是熟悉这些技术并掌握的时候。如果等到不得不面对的时候，反而困难重重。因此不如从现在就开始挑选合适应用尝试使用分布式数据库，在实践中积累产品技术和运维经验，积硅步以至千里积懈怠以致深渊

luxh08 科技部门副总 , 某互联网银行

【 A 】 技术服务业务，用什么数据库架构是业务发展带来的，很多银行为了技术先进性使用分布式数据库，明明oracle等单机关系数据库能搞定的事，一定要不顾成本的改造应用去适配分布式数据库，由于自身技术欠缺，还需要购买三方的服务，这种政绩式的项目也不需要去评估成本收益性。我们需要考虑在一些海量数据、海量用户的业务场景考虑分布式数据库，是因为在这种业务场景中，分布式数据库的性价比要远远高于单机关系型数据库，适不适合采用分布式数据库架构，完全由业务场景决定的。

韩成亮 数据库管理员 , KE

【 A 】 首先请问什么叫必要性？ 如题所说分布式数据库带来不少成本上升，而关心的却是性能是否cover住成本，这个其实有一点问题，不在点上，从性能而言，分布式其实并不好 需要知道分布式解决的问题是扩展和容灾，首要考虑的是数据强一致 而不仅仅说把分布式数据库当成分片数据库。

libai21 软件架构设计师 , 海通证券

【 A 】 我觉得分布式在架构方面是优于集中式的。 分布式数据库和集中式相比，性能肯定是下降的，分布式的事务成本太高了。但是在扩展性和可靠性上会比集中式好很多。这两种架构各有优劣。 分布式天然的支持DBaaS，也是一个明显的优点。可以把分布式和数据库上云这两件事一起做了。我觉得云化以后，硬件的成本应该差不多。

Q4：分布式数据库与云原生分布式数据库，分布式数据库未来的发展方向?

2019年以前，IT业界都在围绕分布式数据库/关系型分布式数据库进行研发和实践，这一阶段的分布式数据库主要是指分布式数据库是基于分布式存储的、而不是分布式计算的，这一阶段的分布式数据库从行业实践来看，效果实际上不太理想、银行核心系统很少有实际应用。从2020年开始，IT业界开始转向云原生分布式数据库，也许分布式数据库的成熟和应用就在云原生分布式数据库这一阶段？ 以上是个人的一点理解，请各位专家发表意见和看法，共同讨论、学习和成长。

lulihuan1987 数据库管理员 , 张家港行

【 A 】 从数据库技术发展趋势来看，云原生数据库，计算和存储真正解藕是数据库发展技术趋势。。。

云原生数据库也是从AWS aurora开始，国产tidb、腾讯CynosDB、阿里的PolarDB是国内云原生数据库的代表。

像目前在金融行业规模在用TDSQL、GOLDENDB、OB的版本，基本都是基于分布式存储的、而不是分布式计算的，这类数据库近几年在银行其实已经被广泛落地并成功实践了，包括银行最重要的核心系统。。。

Q5：分布式数据库结合两地三种架构怎么规划，和测试节点间性能？

分布式数据库结合两地三种架构怎么规划，和测试节点间性能？

lulihuan1987 数据库管理员 , 张家港行

【 A 】 两地三中心的话，同城两中心既可以双活接入业务也可以互为热备，异地三中心与主中心数据库进行数据同步，作为异地灾备。

对于核心交易型数据库（OLTP型），这里需要关注好网络延迟和网络质量，分布式数据库数据是分散在各节点的，节点间会有数据交互，一旦业务的事务较大，那么网络延迟对事务的影响可能会越明显，即一个事务，应用和数据库要交互越多越明显，所以在设计同城双中心双活的时候，一方面要保证双中心间的网络质量，另一方面要减少跨中心的业务流向，比如同中心的应用去访问同中心的数据库，中心间的流量尽可能是数据节点间的同步流量为主。

比如我们优化时有个贷款类业务，一个事务600多次数据库操作，每次要经过应用、数据库网关负责均衡器、数据库网关、数据库存储节点，如果网络延迟较大，那交易耗时在网络上的耗时就会很明显。所以网络质量对交易型分布式数据库还是比较重要的。

Q6：引入分布式数据库的核心系统，IT投入成本每年能下降多少？

您好，在核心系统引入分布式数据库后，IT投入成本每年能下降多少？毕竟除了号召国产化的同时，成本预算这块肯定要考虑的。首次分布式架构的改造成本以及未来每年的节约成本，能有个数据能更好地进行成本估算

lulihuan1987 数据库管理员 , 张家港行

【 A 】 对于这个问题，我们在和领导汇报的时候必然需要准备的。建议可以从如下几个方面进行对比分析：

1）硬件投入对比：分布式数据库通常都是通用X86或者ARM服务器，集中式数据库通常需要高端小型机、SAN、高端存储以及存储双活同步等，考虑集群加灾备，基本上是要考虑三套。

硬件成本投入的优势比较大。

2）数据库软件授权对比：这个看怎么谈了，通常分布式授权也不一定特别便宜。

3）应用适配投入：这块集中式数据库比较有优势，应用适配分布式数据库的改造可能会增加费用，这个也是看怎么谈，如果应用做过相关适配案例了，那这块成本会低一些。

4）咨询和测试投入：基本差别不大。

5）运维投入：分布式数据库通常自带自动化运维平台，是不是需要另外采购，看商务，集中式数据库运维工具和平台可能需要额外采购；至于运维人员的培养，笔者认为做核心必须在整个过程中培养几个对分布式数据库掌握程度非常高的DBA，这块应该算成本，不算投入。

6）后续扩容：这个跟软件授权差不多，看怎么谈，最好要在初期就要明确，各家差别也比较大。

基本分布式数据库的投入肯定是要低于集中式数据库的，互联网企业早期去O的重要原因就是成本投入驱动。当然，金融行业国产化进程会越来越快，安全自主可控越来越重要。

eximbank 系统架构师 , 某金融企业

【 A 】 这个问题不能就数据本身来回答，一定是围绕应用生命周期来汇总汇总回答； 要不然就会偏颇。数据库、X86、信创或开源等，都是为了企业等业务战略，业务周期性、整体整体性投入，比如比如资产生命周期、空间、电力、人力、研发、运维等诸多诸多IT投入，按照时间不同阶段进行综合对比才算科学。 粗旷的描述，至少至少不够严谨，也不能最为决策依据。

Q7：分布式数据库效率和性能如何提升和优化？有哪些具体方法？

对于多表关联的效率低的问题，有哪些方法可以优化；月季度结息等批量业务如何设计；另外，对于一些热点账户如何进行优化提升效率等等。

lulihuan1987 数据库管理员 , 张家港行

【 A 】 （1）分布式数据库数据是分布在多个节点的，当需要进行多表关联时，往往很难避免数据在节点间流动，导致查询效率较低。建议从以下几个方面进行优化：

1）合理进行表设计，尽量避免跨节点表关联：

a) 对所有的库表进行重新设计，合理设置分区键，分区键也是表的字段，表根据分区键字段将数据打散在各个节点，因此分区键设置时要从全局和交易局综合考虑，将交易中经常用来关联的字段设置为分区键，比如客户账户。

b) 对于更新评论较少且数据量不大的表，建议设置成全局表，即每个数据节点保存该表的全量数据，这样分片表和全局表进行关联时，也不会有节点间数据流动。

2）对于跨节点关联的改造：

a)对此类SQL进行拆分，拆成多个单表SQL或者节点内关联SQL。无法拆分过程中可以考虑使用临时表（中间表），将中间数据放到临时表，中间表进行承上启下的关联。

b)对交易业务逻辑进行重新设计，改造复杂 SQL 。

总的就是交易中必须避免节点间数据的流动，以免影响系统并发性能和扩展性能。

（2）月季度结息逐笔进行，根据一定的规则进行分组，并发执行，然后，优化好每笔结息事务，进行SQL优化，比如优化跨节点多表关联，确保可以通过高并发实现快速结息，同时保证后续的可扩展性，较好适配分布式数据库。

（3）对于热点账户，建议设置为异步模式，即先记账，定时扣款，减少互锁，提升性能；为防止账务风险，可以设定阈值，账户余额低于阈值时，开启同步模式，高于阈值时开启异步模式；

Q8:分布式数据库事务管理器是如何满足核心业务系统需求的？

众所周知，分布式数据库虽然在资源扩展与高并发性能方面有着独特的优势，但是不同行业核心业务系统对于事务性要求也是不同的，分布式数据库的事务管理器是如何满足核心业务不同的事务性需求的？

lulihuan1987 数据库管理员 , 张家港行

【 A 】 以金融行业来说，对分布式数据库分布式事务要求应该是非常高的，不同数据库实现分布式事务的机制有所不同，以我行采用的TDSQL数据库来说，分布式事务主要实现方式如下：

1）分布式事务是二阶段提交，组件proxy是事务协调者，启动事务时分别在每个分片节点上启动子事务，

在prepare commit时，proxy向gtid_log_t中记全局事务日志，全局事务日志保存在gtid_log_t（分片表），（通过交易的第一条SQL访问的SET记录全局事务日志）；

2）prepare commit完成后，进入COMMIT阶段。

3）如果prepare commit 过程中发生异常时，各个set上的子事务回退。

4）进入COMMIT阶段，在COMMIT阶段的问题不会回退，会重复自动retry 提交，如果自动retry 提交超时，会在控制台出现一个事务提交报错，需要手工提交。

5）回退或retry提交都是依赖全局事务日志gtid_log_t。。全局事务日志保存在gtid_log_t分片表，依赖TDSQL一主多备确保零丢失。

6）主备之间的binlog传输是在prepare commit阶段完成。这样进入commit阶段，如果主节点故障，也不影响备节点retry提交事务。

7）全局一致性读，依靠TDSQL全局MC的组件，一个基于时间擢的全局序列，确保全局事务ID单调递增和唯一。

我们通常会通过破坏性测试来测试其分布式事务可靠性，例如一个表由ID和value组成，分布式事务是ID1+1，ID2+3，ID3+7，ID4-2，ID5-4，ID6-5，并发开启分布式事务，外部程序一定时间不断杀数据库DB进程，导致数据库故障主备切换，验证程序则不断地查分布式数据库整表sum(value)，查到的数值不会变化。

Q9:核心业务系统采用哪种分布式数据库更好一些？

核心业务系统采用哪种分布式数据库更好一些？最好能提供分布式数据库产品的对比数据和选型依据？

lulihuan1987 数据库管理员 , 张家港行

【 A 】 目前国内分布式数据库产品很多，需求量也在逐步增加，随着XC工程推动，未来3年内会有越来越多的分布式数据库将适配到金融行业的关键核心业务系统，实施案例多效果好成熟度高的分布式数据库会脱引而出，所以银行核心系统选择一个实力和潜力强的数据库尤为重要，所以选择的时候首先看厂商的背景和实力；第二，看产品应用情况，重点互联网、金融领域；第三，调研核心案例情况；第四，产品的发展演进路线和潜力；第五，根据以上几点选取产品进行现场POC测试，性能测试（数据加载、查询性能、事务性能），功能测试（易开发、易运维以及安全性）；

选定数据库后，核心应用和数据库的适配实施必然会有一定适配改造，这部分需要提前评估；

最后，核心系统非常重要，必须控制实施风险，必要时需要配置后备库，确保万无一。

一力搜索 数据库架构师 , 股份制银行

看你的分布式数据库产品。我们核心交易系统在用，一个多亿用户。不过定制化优化必不可少，监控运维系统得跟上

Q10:迁移到MySQL性能上是否有保证，是否有验证过的可行方案可供参考？

目前我们的数据量大概是150张表，其中大概30张表达到千万级，并且涉及DML和查询并行，Oracle中我们使用索引+表分区来保证性能，迁移到MySQL性能上是否有保证，是否有验证过的可行方案可供参考？

lulihuan1987 数据库管理员 , 张家港行

【 A 】 从ORALCE迁移到MYSQL的话，同档软硬件条件情况下，无并发基准查询速度肯定是下降的，毕竟Oracle的查询优化器做的非常好；

如果是迁移到基于MySQL的分布式数据库，通过合理的适配改造，无并发基准查询的速度可能也没有Oracle快的，而分布式数据库易扩展特性，通过增加节点提升性能，整体性能是完全可以超过原Oracle的。

我们行采用的TDSQL（MYSQL版本内核）数据库，核心1600多张表，超过千万的肯定超过30多张表的，就是通过多节点保障整体性能（TPS）并可扩展。

所以您的性能通过合理的适配改造是可以保证的。

一力搜索 数据库架构师 , 股份制银行

【 A 】 你这些数据量和表数量都挺小的。mysql同样也有表分区的，往深里说，改innodb页大小也可以让b+深度不增加

Q11:分布式数据库品牌多，如何选型？

分布式数据库品牌多，好多都是基于开源产品改装而来，未经过大规模使用验证 现有的长期稳定使用关系数据库，可以了通过分库分表，通过mycat等中间件增强分布式性能 分布式数据库优势和稳定性能全面超越吗？选型又主要考量哪些方面？

Ocean_ it技术咨询顾问 , 华为数据存储解决方案中心

【 A 】 在讨论如何做数据库选型之前，我们必须了解几个问题，否则选型这两个字就无从谈起。 第一个问题是你的需求是什么？你用数据库来干什么，用到了数据库的哪些特殊的功能？很多用户其实并不清楚自己选数据库的目的是什么，只是和我说，有没有和Oracle差不多的数据库可以替代它？我问他哪方面像Oracle，他说所有的，性能，稳定性，可扩展性等等。我告诉他一个不好的答案，就是没有，Oracle是独一无二的数据库界的老大，如果以Oracle为标杆来选数据库，最后只能选到Oracle身上了。不过我会问他第二个问题，你的业务需求是什么，是不是只有Oracle才能满足你的要求？别的数据库可能没有Oracle那么稳定，偶尔会出现一些问题，宕库的机率也比Oracle高，但是达到四个9或者五个9，对于目前的绝大多多数数据库借助一些技术手段，在绝大多数场景下还是可以实现的。别的数据库可能没有RAC，但是你的应用一定需要rac才能运行吗，读写分离高可用集群是不是也能满足你的需求呢？你真的需要分布式数据库来替代Oracle吗？你是否了解单机的处理能力有多高呢？只有真正的回答好了这些问题，真正的了解了你的应用，这样你才能有更准确的选择。了解了这一切后，你可能了解到你的数据库就是用来存放数据的，每天插入几百万条数据，删除几万条数据，修改十来万条数据，另外就是对一些千万级的表做一些统计查询。这样的系统恐怕一台虚拟机上的MYSQL或者PG数据库就完全胜任了。你为什么非要去选比Oracle还强大的数据库呢？ 第二个问题是你需要了解硬件的真实能力，一台两路服务器的配置是什么样的，处理能力可以达到多少，一块SATA SSD盘的IO性能是一块普通HDD的多少倍？万兆网络上能跑多少流量，IO延时大概是多少？可能很多DBA干了一辈子都对这些数据不甚了解。只有了解了这些问题，才不会问出“我的数据库每天要新增上千万条记录，得多少个节点的分布式数据库才处理的过来？”这样的问题。在一台不到10万块钱的4路服务器上，我们曾经测试过，对于简单的高并发大批量数据插入，可以达到每秒钟500万条数据的写入，这还不是最快的水平。在数据库领域，能用硬件解决的问题，尽可能让硬件来解决，和能够提供的性能来对比，多花的这点钱简直不要太值了。现在很多企业的集采都特别注重价格，而不太关注相同价格下的配置问题，这一点也是不足取的。同样一台4路服务器，集采的采购者往往注重CPU的数量与频率，以及内存的大小，而不会去关注PCI-E插槽的数量与规格，RAID卡数量以及RAID卡的缓冲大小与吞吐量大小这些指标，我有一次和一个服务器厂商的工程师讨论这方面的问题，我问他如果RAID卡换成吞吐量大一些的，大概需要花多少钱。他说另外一款RAID卡还是挺贵的，比你现在配的这块贵100多块钱。在集采的招标中，正是这些100多块钱的便宜，让我们吃了更大的亏，很多时候是买了台很便宜的法拉利，却只能开出桑塔纳的性能来。说到能用硬件解决的问题就尽可能不要用其他手段，可能会有一些极端，不过在很多场合是适用的。大概十多年前，老白还是靠系统优化混饭吃的时候，有个朋友找到老白，说他有套ERP系统需要做个优化，让我报个价。他告诉我这套ERP跑在两台2路服务器上，做了一个RAC，大概有400G的数据量，存储是一台EMC的CX3-40。我分析了他的系统，然后给他报了个特别便宜的价格，大概是不到30万。他听了觉得有点贵，问有没有更便宜的方案。我说很简单，买台新服务器，插上一些SSD盘，然后把数据库迁移到SSD盘的单机上，原来的服务器、存储和这套新的数据库做一个ADG，再把ERP部署调整成支持ADG的模式，他当时的大部分问题就都解决了。这样的话，总共也就花不到10万块钱就可以搞定。他照着去做了，结果效果很好。 第三个问题是你的企业的IT基础架构与应用架构的发展策略是什么，今后企业是走云平台还是容器化为主的技术路线？集中式的大型数据库还是分散的小型数据库？业务规模的发展是什么样的？这些都会对你的数据库选型产生重要的影响。适合你的企业的IT发展是数据库选择前最重要的需要分析的问题之一，只有回答好了这个问题，后面的数据库选型才真正有意义。而IT发展必须是适应企业业务发展的，因此最终还是你的企业的主要业务的特点决定了你的数据库选型。如果你的企业的业务是灵活多变，的IT必须采用更为敏捷的方式进行交付，那么有可能你的企业会选择基于微服务的容器云，那么你选择Oracle这样大型数据库就不合适了。 第四个问题是了解你的备选数据库的基本特性，这些数据库的架构是什么样的，技术特征如何，技术指标与参数如何，与Oracle的兼容性如何等等。在回答第四个问题的时候，我们需要从下面的几个方面去考虑。这些选择数据库的选择分析并不一定十分科学，只是老白这些年工作经验的总结，算是一家之言，仅供大家参考。 •通用性与适用性：这款数据库是通用型数据库还是专用型数据库，中国人是十分会玩文字游戏的，非通用型数据库可能会被命名为金融级数据库，似乎十分高大上，金融都没问题，别说其他应用了，可能实际上是这款数据库因为MVCC上存在的一些缺陷，导致在某些场景下的支撑不足。如果某个数据库脱胎于一些场景比较简单的互联网应用，那么可能被称为“云原生”数据库，到今天为止老白也没弄明白“云原生”和天生的数据库到底有啥区别，在这里也就不做评价了。对于适用性也很重要，你的业务与应用系统的特点可能会影响你的数据库选型。实际上并不存在一个包打天下，万物通吃的数据库产品，所有的HTAP数据库的噱头大于实际效果。OLTP与OLAP的场景十分复杂，一套适合数据仓库应用的数据库可能无法支撑高并发高吞吐的十分简单的ODS场景，而让一套普通的行数据库去做数据仓库擅长的几十亿条记录表之间的复杂统计也会效果不佳； •部署便捷性：随着DEVOPS的发展，IT交付的快捷性也是企业追求的重要目标。所以老白把部署便捷性放在了比较重要的位置上，能否快捷的实现自动化部署，自动化配置是今后选择数据库的一个十分重要的考量指标； •使用与维护成本：数据库不是一次性消费品，数据库选型中使用与维护成本的考虑十分关键，这也决定了今后企业IT在这方面的投资规模； •高可用/备份/容灾等方案的完整性以及实用性：再好的数据库也不可能永远不出事，虽然我们不希望发生这些事情，但是一旦发生数据库故障，宕库，主库无法使用的时候，必须不能丢失数据。很多数据库具有很高的可用性，采用了包括多副本、消除单点故障等的设计，不过对于关键性的IT基础设施来说，这些还是不够的，我们不能总说做了万无一失的准备，但是遇到了百年不遇的问题，每年都遇到的百年不遇就是一年一遇。这些方案不仅要存在，还要完整，而且可实施，被验证有效； •接口完整性：我们常用的接口都需要支持，包括JDBC/ODBC/OLEDB/C语言/PYTHON、GO等运维自动化工具常用的语言。完备的接口可以保证今后数据库产品在深入应用时不会遇到坑，也不会让企业的IT被数据库牵着走； •工具完整性：围绕着数据库的各种工具，包括开发、数据处理、数据管理、运维、部署、备份/恢复、安全审计、报表平台、ETL工具、数据复制工具等，这些工具都是今后数据库应用进入深水区的时候必然会用到的，可能我们刚刚使用数据库的时候并不会关注这些工具，但是一旦我们要用的时候发现这些都需要花大价钱去开发或者购买的时候，就麻烦了； •生态完整性：和数据库相关的工具、应用软件、报表工具、管理工具、容器支持、云平台支持等方面的生态是否完备是考量一个数据库是否被业界广泛接受的一个重要的因素，数据库功能插件与第三方解决方案的多寡也可以看出某个数据库是否在生态链中处于强势地位，这些都是在数据库选型的时候不得不考虑的。对于开源数据库，开源生态的活跃度也是产品生态中的重要因素，选择开源产品的时候，如果你选择了一个两三年后不再活跃的开源项目，那么今后数据库的优化与发展就完全要依靠自己了，你首先要想清楚自己是不是做数据库产品的料； •与主流商用数据库的兼容性：如果我们是从某个数据库迁移数据库到新的数据库产品上，那么我们就要考虑兼容性的问题了，兼容性可能决定了迁移的成本。当然并不是所有的用户都需要考虑兼容性的，如果应用架构本身就已经屏蔽了数据库的特性，那么这方面的考虑就可以比较少，如果应用正好要升级或者重构，那么对兼容性的考虑也可以降低； •原厂服务能力与第三方服务能力：我们已经习惯了Oracle强大的原厂服务于第三方服务能力，这也是这些年Oracle能在中国这么流行的重要原因，在选择数据库产品的时候，我们必须知道一点，今后服务是依靠我们自己的力量还是依靠厂家和第三方，如果是后者，那么在选择数据库产品的时候，需要十分认证的去考虑这些问题。 •原厂的规模与企业稳定性：在IT行业，百年老厂能活下来的少之又少，因此选择数据库产品的时候，对厂家也要有一些考虑，可能某个数据库产品十分先进，但是原厂规模十分小，那么你可能会面临十分痛苦的选择。这种情况下，可能选择开源社区的类似版本会比选择一个小厂优化过的版本是更好的选择； •市场与行业应用效果与销售规模：数据库产业是一个高投入，慢产出的行业，没有十年磨一剑的耐心是很难做出一款好的数据库产品的。你选择的数据库产品的时候，也需要考虑这一方面，现在的数据库产品数量太多，十年后，估计能活下来的产品并不多； •DB ENGINE流行度排名：DB ENGINE目前还是最好的数据库排名网站，流行度是用户对某个数据库的认可程度，因此其参考价值还是很大的。不幸的是，好像天朝的数据库产品都不屑于参加排行，或者说老外还不太关注我们的数据库产品，因此上榜的国产数据库十分少。

lulihuan1987 数据库管理员 , 张家港行

【 A 】 目前用于银行核心交易系统的分布式数据库主要有基于开源数据库内核的数据库（如TDSQL、GOLEDENDB）和原生纯自研数据库（如OCEANBASE），像TDSQL、GOLEDENDB已经有银行核心系统成功案例，像OCEANBASETDSQL都是经过互联网海量数据流量验证的，所以内核成熟度都是能满足核心业务系统业务连续性要求的。

基于中间件分库分表实现分布式的数据库也可实现分布式架构，通过合理的架构设计和业务设计，性能非常卓越的，但是其对业务的侵入性比较强，对架构设计和业务设计要求较高，无论是分库分表还是分片式分布式数据库，在银行核心系统都有应用案例，笔者认为只要设计得好，自身开发和运维能力能跟上，符合自身技术发展路线，两种数据库均是可选项。

核心分片式分布式数据库选型时可以考虑几点：

1）产品行业应用情况，核心应用情况

2）厂商实施团队情况，对该项目的重视情况和资源投入情况

3）产品POC测试情况，例如基本技术指标、sysbench压力测试、TPCC测试情况、自动化运维管理工具、异构数据库同步工具、产品手册完善情况等

4）建设和运维成本投入，后续扩容投入

5）是否满足XC要求

6）行内领导的支持

Q12:企业引入分布式数据库的安全问题？

众所周知，分布式数据库无论是newsql型（tidb，oceanbase），还是传统的mysql分片式（tdsql、golden db），安全问题都很难完美解决。不同于Oracle等传统商业数据库，分布式数据库厂商将大量的精力用于功能的完善，对安全问题往往淡化，比如数据的分散部署难以加密、备份的明文等等。请问，如何解决这个问题？

lulihuan1987 数据库管理员 , 张家港行

【 A 】 数据库安全问题选型时也要考虑

例如产品是否符合国家相关信息安全标准，是否通过等保X级（至少3级），以及其他国家和国际认证，选型时同时让厂商提供以下几个方面的支持和实现情况：

（1）ssl连接加密

（2）数据透明加密，密文物理存储；

（3）ip黑白名单，允许白名单的客户端访问；

（4）sql防火墙，阻止不符合要求的sql访问，以及sql注入等

（5）安全审计

（6）其他的内核级的安全

Q13:如何应对外围系统到核心系统取数的问题？

核心系统不是独立的系统，会与外围系统进行大量的数据交互，例如数仓卸数和实时数仓，如何给这些系统供数，如何既能保证数据实效性又能对不影响核心系统正常运行。

lulihuan1987 数据库管理员 , 张家港行

【 A 】 核心系统与外围系统进行数据交互，根据场景，可以通过如下方案解决：

1）T+1应用:卸数，通常需要取多个表的全量数据，取数量大，时间长，建议通过只读账户直接从备库取数。

2）实时应用：例如实时数仓，需要实时取数，可以通过数据准实时同步到消息队列（例如kafka）方式与大数据实时计算平台对接，同时不影响生产，建议从备机同步。

alphaaries 技术总监 , 华为数据存储解决方案中心

【 A 】 1. 传统意义上的核心系统与外围系统的数据交互有，但不应该太多。从本质上来讲，核心系统主要的任务不应该是交易，而更多的应该是批量、清算等。 2. 数仓与包括核心系统在内的交易系统进行交互时，主要是通过卸数+导入的过程来实现，可以考虑建设ODS数据平台，各系统将数据统一卸载到ODS平台，再导入数仓。 3. 实时数仓可以通过读写分离的方式来减少性能影响。

一力搜索 数据库架构师 , 股份制银行

【 A 】 这些场景完全可以读写分离。备库做就行，脚本自动寻找备库

Q14:分布式数据库核心难点之乐观锁适配问题探讨？

在金融领域，绝大多数的银行业应用设计都是基于传统单机关系型数据库，没有从整体应用架构考虑与第三代分布式数据库进行适配，尤其在银行核心系统应用第三代分布式数据库案例甚少，没有可复制的成功经验可以借鉴，从数据库自身机制和核心系统应用等方面，面临核心难点之乐观锁适配问题：

乐观锁在事前对表不会加锁，只在提交的时候比对提交版本号，不能保证每笔交易都能提交成功，在高并发的金融记账业务场景里，会造成大量的交易超时，出现用户短款现象，不能满足银行业务连续性和数据“强一致性”的要求。

大家针对这个核心难点问题有何解？有什么比较好的方法和经验吗？欢迎谈谈！

wanglaye 项目经理 , 某大型金融机构

【 A 】 不知道“金融记账业务”是否指的是账务核心系统？我们对于账务核心没有做分布式数据库改造，对于记账来说，一致性放在第一位。 我们在选择哪些系统使用分布式数据库时，主要根据系统交易量是否具有明显波峰波谷特点、是否对可用性要求很高、数据增长是否非常快速这几个方面。分布式数据库的弹性扩缩容、高可用机制可以更好适配这些场景，提高行内资源使用率，保证重要时期系统稳定性。主要是面向网络交易的系统在用。你说的乐观锁无法做到强一致性的，所以这块是很难做到的，除非能牺牲少量一致性原则，否则。。。

lulihuan1987 数据库管理员 , 张家港行

【 A 】 乐观锁和悲观锁应用的场景不同，悲观锁更注重数据安全，更新数据前，读取数据时先利用数据库的锁机制将该数据行进行锁定，直到事务提交才释放，强调安全性，持有锁时间长，并发效率在某些场景效率不高；

乐观锁在最后提交的时候才去比较数据版本号，锁持有时间短，并发效率高，但是如果出现大量的数据冲突，会导致大量交易失败，所以乐观锁应用的前提应该是该业务场景下数据冲突的概率很小。

所以还是要结合业务场景和特点，在安全性保证的前提下，考虑使用乐观锁还是悲观锁，我们行大部分业务场景都是采用的悲观行锁，通过其他途径去提升并发效率，比如大事务改小事务，事务中锁尽量往后放等。

分布式数据库比集中式数据库有个全局一致性读的特殊性，现在分布式数据库通过增加全局时间戳组件实现了全局一致性读，能满足数据“强一致性”的要求。

johncyj 其它 , 农信

【 A 】 乐观锁确实会出现成功率不高的问题，那就换悲观锁呗，那么带来了新的问题，多个会话同时更新一条数据，势必会带来争抢，tps也上不去，不如牺牲一点点性能，采用分而治之的思想，将账户按一定的规则拆分一下，成为多个子账户，会话按照一定的规则去访问子账户，这样就降低了争抢；不过...现在的分布式数据库还存在这个情况？

t3573393 研发工程师 , 兴业数金

【 A 】 按照互联网的内存数据库方案能极大的提高性能，参考oceanbase的内存是最新的，增量刷新数据到盘里面。由于内存更新极快完全可以通过队列串行的方式修改一条记录。

Q15:分布式数据库跟其他数据库之间的数据同步问题？

当前分布式数据库方兴未艾，进步很快，但是其生态仍需要不断完善，比如分布式数据库跟传统的数据库，或者其他的分布式数据库之间的数据同步问题，目前市场上支持这种异构数据库的t数据同步工具还很稀缺，即使有，也是漏洞百出，远不如传统数据库完善

lulihuan1987 数据库管理员 , 张家港行

【 A 】 我行当初上线时采用的分布式数据库和集中式数据库数据准实时同步的方案，这个方案是更加数据库提供的同步工具设计的，当然同步工具也做了适配改造。具体的可以参见文章https://www.talkwithtrend.com/Article/250951

像TDSQL、OCEANBASE等数据库都有对应的异构同步工具，而且也有案例，使用上可能没OGG之类的成熟，但是总体来说还是可用的，从可用到好用，国产数据库未来可期。