作者lulihuan1987

·2022-08-08 16:31

数据库管理员·张家港行

企业国产数据库应用实践问题及难点剖析总结

字数 10874阅读 5796评论 2赞 14

> 本文为云原生应用创新实践联盟——数据库自主可控课题组线上交流活动总结，相关协作专家如下所示， 更多内容可[**点击此处进入云原生应用创新实践联盟**](https://cnaipa.talkwithtrend.com/?action-topic-id-403) 进行查看。

> **执笔专家：**
**[卢丽欢， 数据库自主可控用户委员会委员](https://www.talkwithtrend.com/home/space.php?uid=1222691 "卢丽欢， 数据库自主可控用户委员会委员")**
云原生应用创新实践联盟——数据库自主可控方向课题组专家。长期从事数据库尤其是分布式数据库应用实践工作，具备银行核心系统、互联网聚合支付系统、信贷系统、中间业务等银行关键业务系统采用国产分布式数据库落地实践经验。

> **协作专家：**
**[苑华伟 数据库自主可控用户委员会委员](https://www.talkwithtrend.com/home/space.php?uid=1229763 "苑华伟 数据库自主可控用户委员会委员")**
云原生应用创新实践联盟——数据库自主可控方向课题组专家。计算机硕士学历，从事生产运维10余年，被国际灾备协会授予大师级业务连续性管理专家（MBCP）认证。先后从事IBM主机系统管理员、灾备管理员、ESB管理员、中间件管理员、数据库管理员等工作。擅长灾备建设与演练、MQ中间件运维管理、国产数据库运维管理工作。

> **[韩锋，数据库自主可控用户委员会委员](https://www.talkwithtrend.com/home/space.php?uid=1228765 "韩锋，数据库自主可控用户委员会委员")**
云原生应用创新实践联盟——数据库自主可控方向课题组专家。有着丰富的一线数据库架构、软件研发、产品设计、团队管理经验。曾担任多家公司首席DBA、数据库架构师等职。在云、电商、金融、互联网等行业均有涉猎，精通多种关系型数据库，对NoSQL及大数据相关技术也有涉足，实践经验丰富。曾著有数据库相关著作《SQL优化最佳实践》、《数据库高效优化》。

> **[李建明 数据库自主可控用户委员会委员](https://www.talkwithtrend.com/home/space.php?uid=51231 "李建明 数据库自主可控用户委员会委员")**
云原生应用创新实践联盟——数据库自主可控方向课题组专家。擅长基础架构规划和管理，尤其擅长全栈式性能优化，将基于云计算+微服务+OceanBase技术栈的新一代分布式架构核心系统性能优化到8000tps，在数据库方面有丰富的经验（熟悉informix、oracle、elasticsearch、oceanbase等数据库）

> **夏茂宣 农商银行 资深DBA**

**摘要：**
传统企业现在的系统绝大多数还是运行在Oracle，DB2等国外商业数据库上，随着近些年来数据库的变化，正有越来越多的企业面临将传统数据库迁移到开源或新型商业产品上才能实现自主可控的目标。然而不同数据库的特性有差别，SQL语法也有很多差异，因此在迁移数据库的过程中不仅涉及数据的迁移，还包括应用的适配改造。

首先，从传统集中式数据库迁移到国产分布式数据库，异构的两种数据库差别非常大，计算方式、数据存储、架构设计都区别较大，系统迁移时往往涉及大量的表结构设计调整、业务重构、应用改造，同时给数据迁移带来了一定困难；
其次，分布式数据库多节点设计给全局一致性的实现带来了一定的要求和难度，分布式数据库如果不实现全局一致，可能会带来跨节点任务的数据不一致性问题（当然，这个问题可以通过应用改造去规避，但是对业务的侵入性较大）；
最后，应用适配分布式数据库，不仅仅是SQL语法语义层面的转换，还会涉及到业务的优化，应用架构优化等等方面。所以围绕“国产数据库数据分片和迁移难点实现”、“全局一致性难点实现”以及“应用改造难点实现”三个方面，本期论坛组织了此次“国产数据库应用实践难点线上核心探讨”活动，特邀请了金融企业有国产数据库实践经验的专家，针对以上三个方面进行了充分的讨论，现将交流内容和精彩回答整理如下，以供大家学习交流。

# 一、国产数据库数据分片和迁移难点实现

## 1、建表基本问题：结合银行业务系统改造案例，介绍下如何进行表容量规划？
建表时需要考虑表的容量，该表常用SQL以及字段类型选择，请结合银行业务系统改造案例，介绍下如何进行表容量规划，该表常用SQL的提取分析，以及字段类型选择的注意点（主要是字段长度较长的情况）等。

**专家建议**
-  **hanfeng_twt  数据库架构师 , SphereEx**
1.表容量的规划
这一问题本质是数据对象的生命周期管理，针对数据对象在生命周期内的创建、增、删、改及归档销毁等做到前期规划。根据数据访问特征，对表内数据量的变化做到预测评估，尽量在早期阶段对表做好分片、分区、归档策略等规划。
2.常用SQL提取分析
对数据对象的访问，SQL是主要的方式。需要在定期分析SQL，提升访问效率。对表的访问玩玩是比较多元的，需要区分业务与非业务、常规与非常规、定期与随机、高频与低频等SQL访问特征。优先处理业务、常规、定期、高频的SQL。提取方法是有很多，很多平台也都提供了相应工具完成提取和分析的工作。
3.字段类型选择
关于字段类型的选择上，可本着如下原则：
 - 尽量使用简单字段类型，针对如LOB、JSON等类型减少使用
 - 选择合适的数据类型（如日期就选择日期类型，而非数字或字符）和适当的精度
 - 对于超长的数据，原则上不建议在数据库内存储，可通过外置方式保存。

- **xiamx_ksrcb  dba , 某农商行**
字段类型选择通常都用varchar,字段长度固定的情况才使用char， 日期就用日期 ，文档图片类型用lob；你的问题不太明确，不清楚你在哪些字段抉择上遇到问题。
表容量问题和业务情况息息相关，通常只计算流水、交易记录等量大的表，三年未能达到千万级的表通常不考虑。 而这些量大的数据通常有生命周期，保留三年或者五年，需要根据业务去估算周期内的行数，在乘以1.2~1.8进行预留，行数和所占空间的比例需要测试才能知道结果，最终能估算出所需的空间。

## 2、结合银行关键业务系统表类型如何设计，重点表分别选择了什么类型的表？
分布式数据库里有广播表（每个数据节点都有全量）、分片表（每个数据节点存储部分数据）以及普通表（仅存在于某个数据节点），请结合银行关键业务系统案例，介绍该系统表类型如何设计，重点表分别选择了什么类型的表？

**专家建议：**
- **hanfeng_twt  数据库架构师 , SphereEx**
选择表的类型，还是根据表的使用特征来分析。
1.广播表：适合于低频修改，高频查询的场景
2.分片表：适合于数据规模大，需要数据拆分的场景
3.普通表：适合于需精确控制存储位置或者使用频率很低，性能要求不高的情况

- **lulihuan1987  数据库管理员 , 张家港行**
广播表（每个数据节点都有全量） ：小表广播，数据量不大，经常关联但更新较少的场景，比如参数表，像机构表、利率表、产品表等；

分片表（每个数据节点存储部分数据） ：除小表广播以外的其他业务相关的表，建议均采用分片表，以确保分布式数据库的性能和扩展性，例如账户信息表、客户信息表、交易信息表等等；

普通表（仅存在于某个数据节点） ：不具备可扩展性，所以业务表不建议使用，除非是一些特点场景，比如一些临时表，数据量也不少特别大的可以使用。

## 3、结合银行关键业务系统介绍下分片字段选择的原则？
分片字段选择是分布式数据库适配的关键，关系到数据的分布，查询的效率，以及扩展性，请结合银行关键业务系统案例，介绍下分片字段选择的原则，重点表如何选取分片字段。可以和“表类型选择”问题联合进行介绍。

**专家建议：**
- **xiamx_ksrcb  dba , 某农商行**
这个问题是要和该表适不适合做分表、其他相关联表的分片字段一起讨论的。
通常做分表的数据量一定是足够大才考虑的，如果数据量小，就算有良好的分片字段，也没有做分片的必要，可以考虑做成广播表或单表。 这样就可以规避掉很多分片字段的选择场景。
分布式数据库在分表之间关联时，如果关联字段不是分片字段，则会引发数据上拉进行跨分片关联，性能损耗极大。因此在选择分片字段依据并且只依据关联分表的分片字段情况。
首先定好分片基调，例如银行系统通常选择是账号或卡号，将所有与账户关联的分表全部按业务逻辑的账号或卡号的字段进行分片，便于与账户主表的关联。对于其他的分表，则根据关联查询的表一起协定用一个字段做分片，尽可能统一。如果一个分表同时要和两个分表做关联，且关联字段不同，解决思路:1.该表能否做成广播表;2.是否能改查询逻辑，与其中一个分表不做直接关联
如果分表没有关联其他表，字段选择优先能够让数据均匀分布到各个分片上的字段，通常选唯一主键。

- **hanfeng_twt  数据库架构师 , SphereEx**
分片字段的选择，需涉及的因素很多，可大致分为以下几个方面：
1.数据结构
主键或唯一索引字段是否要包含如分片字段。很多数据库丛唯一性校验，是必须要求包含分片键在其中，否则无法完成校验工作。
索引字段对分片字段的选择上，没有直接影响。对于全局索引的，可考虑通过二级索引表的方式解决；对于普通索引，则可以在分片基础上做本地索引。
字段类型，选择适合分片的字段作为分片键。常见的分片类型包括有数字、日期、文本等。

2.数据特征
表规模，是是否使用分片的关键因素之一。表做了分片后，势必后造成一定的“功能退化”，如能采取其他方式缩小表的大小，尽量采用。可通过表的全生命周期规划，如常规的数据归档、压缩、转储、清理策略，减少数据量。此外，数据库内置的如表分区、垂直分表等策略也可以有效减小表的大小。
数据离散度，按某个字段或字段组合后，表的数据是否足够分散。数据分片的初衷就是减少表的规模，尽量做到数据打散是其根本原则之一。这里需要统计数据拆分后离散程度，尽量选择能充分打散的字段作为分片键。这里需注意，如果选择字段是带有业务特征，还要关注未来业务变化对它的影响。

3.访问特征
可变化性，选择相对固定、不再变化的字段作为分片键。虽然有些数据库也支持分片键的修改，但毕竟修改后会涉及数据移动，成本代价很高；还是优选不变的字段为好。
事务隔离，尽量选择按字段拆分后的数据，对数据的变化处理可集中在分片内解决。这样大量的业务变化是可以通过Local的事务完成，开销比全局的要小很多，效率也高。
关联字段，如后续此表与其他关联表经常联合使用，优先那些参与到关联操作的字段为佳。尽量是数据在关联后，能在本地完成Join的动作，减少数据 Shuffle或上移汇聚类的操作

4.其他因素
如涉及到多个字段作为分片键的话，还需考虑如字段顺序等问题。

## 4、国产分布式数据库如何解决计算下沉的问题，是否有一些通用的规则？
国产分布式数据库如何解决计算下沉的问题，是否有一些通用的规则。

**专家建议：**
- **lulihuan1987  数据库管理员 , 张家港行**
分布式数据库数据下沉属于数据库查询算法优化的范畴，对于我们使用者来说，尽可能在数据库表设计的时候合理设计，例如分片字段的设计，广播表的使用，增加冗余字段作为分区建，查询时减少关联层级，尽可能使用分区建关联，才能达到较好的性能。

## 5、分布式数据库的通用分片规则参考的因素有哪些，分别如何评估和取舍，是否有统一的方法论？

**专家建议：**
- **lych370  系统运维工程师 , 某公司**
分片分为横向和纵向，一般都选择横向分片，按照一个统一的字段进行分片，按照数据量的大小，分片字段建议重复值少，便于索引，通常选择编号类的主键进行分片，分片不建议太多，适量就行，要考虑检索的速度和后期的扩展性。一般很少有人用纵向分片，主要是因为目前的数据结构化原因，纵向类似业务的分库分表，代价大，难度高

- **huawei851120  数据库运维工程师 , 江苏省农村信用社联合社**
你好！说句实在话，Oracle也好，DB2也好，其实功能非常丰富，但是我们能用的功能非常少。用的功能越简单，越不会出问题。国产分布式数据库也是的，进行分片，别搞哪些千奇百怪的，什么自定义分片规则、三级分片、分片之后再分片的多级分片之类的看起来很高端，复杂容易出问题。就是最简单的，哈希，或者范围（Range）。如果这两种搞不定，这套系统就先不要搞分布式改造！！！！！！！真的，简单约好！

## 6、在表结构，业务重构的情况下，如何进行数据迁移，确保安全准确？
数据迁移难题：这里的重点不讨论迁移工具，讨论落地迁移方案，确保数据迁移的准确性，尤其是在表结构，业务重构的情况下，如何进行数据迁移，确保安全准确。请结合银行关键业务系统案例，介绍下数据迁移的方案。

**专家建议：**
- **hanfeng_twt  数据库架构师 , SphereEx**
数据迁移的方案，从大的分类上有三种：
1.基于数据的逻辑迁移
这种方式的适配范围更广，适配场景多，但迁移效率一般较差其对库表结构有要求。
2.基于日志的物理迁移
这种方式的实时性较高，但需做更多的适配性工作。
3.基于应用的数据迁移
这种方式属于定制方案，需要应用侧解决数据迁移问题。效率中等，可加入定制策略。

在保证数据安全方面，可通过数据校验完成。一般的迁移都支持离线的校验，原理是通过某种算法对部分或全部字段实现校验；或者通过采样统计的方式完成。

# 二、全局一致性难点实现

## 1、金融企业应用分布式数据库全局强一致性与性能取舍，这方面问题如何考虑？
提供全局强一致性校验的分布式数据库，能够达到集中式数据库那样的强一致性需求，但是相应也会带来性能的损失，而有的业务系统为了确保性能，通过业务改造和数据库设计，弱化强一致性要求，即使全局最终一致性也能满足业务需求。那么，坚持开启全局强一致，还是关闭全局强一致，通过改造规避影响？结合银行核心、信用卡、互联网金融系统等关键业务系统改造案例，介绍该方面的问题是如何考虑的？

**专家建议**
- **lulihuan1987  数据库管理员 , 张家港行**
从分布式数据库的角度看，全局强一致性开启后会由专门的组件负责全局事务的管理，在数据查询时也需要判断数据的提交状态，对于存在大量分布式事务两阶段提交场景的应用，会有一定的查询性能的下降，大概会下降10%左右。从分布式数据库的发展来看，全局强一致性是必要的功能，起码把开启和关闭的权限交由客户决定，通过提高全局事务管理组件的性能和高可用，可以缓解性能下降的问题，对于事务较小的交易，例如单事务的平均SQL数量在100以内的交易，开启强一致性查询带来的性能损耗是完全可以接受的，而对于单事务的平均SQL数量在300以上的交易，那么开启后带来的性能损耗客户是有一点感知的，一个交易应用和数据库进行300次以上的交互，其中网络、数据库的耗时加起来，交易耗时可能达到500ms以上。当然这个问题也可以通过将事务改造成小事务来解决问题，当然也会给应用的改造带来一定负担。现阶段的情况来看，建议业务迁移分布式数据库时原则上是开启全局强一致性，通过优化抵消开启的损耗。

- **fcospt  数据库管理员 , 云南红塔银行**
“分库分表”类型的分布式数据库一般采用强同步的方式实现写一致性，可用性较差，而原生分布式数据库一般采用Paxos/Raft等多节点同步一致性的技术，可用性较好。此外 “分库分表”类型的分布式数据库，应用在不知道数据的分片键的情况下，需要对所有主库发起SQL，导致性能较差；为提高系统性能，在操作数据时应用需要带上分片键，使得对应用的改造量很大。

- **hanfeng_twt  数据库架构师 , SphereEx**
是否启用强一致性，主要取决于业务架构。针对全局强一致是刚需，绝大部分业务都是需要的。只有当业务做过单元化改造，也做到局部的业务闭环下可考虑关闭全局一致，提升效率。

- **huawei851120  数据库运维工程师 , 江苏省农村信用社联合社**
本次回答是基于2022年国产数据库的发展阶段进行。对于金融行业，保证分布式数据库的强一致性是金融企业的首选。尤其对于银行业来说，哪怕不是核心系统，也不是什么重要系统，就是重要等级一般但是交易并发量高的系统。保证分布式数据库的强一致性，仍然是首选。至于性能方面的取舍，我不认为这是个问题。如果有问题的话，可能是某家银行引进的国产分布式数据库，还不够成熟稳定，或则用的不是国内头部几家大厂的分布式数据库产品。我们想想，MySQL开源社区版，很多商业银行用MySQL既能保障数据库的强一致性，也能支持一定的并发。如果花钱用了某款商用的国产分布式数据库（很可能是基于MySQL改进的），性能反而不如MySQL，或者没法保障事务的强一致性了。那我只能说：1，别玩了，换头部厂家的国产分布式数据库吧。个别银行的核心系统的数据库已经完成了国产化改造，已经实现了超高并发的同时解决了强一致性的问题。这个问题的提出可能是客户用到了不够成熟的产品。2，可能真的是这个系统的交易量太大，那就再等等，先别拿这个系统的数据库做国产化改造，再等等。先改造交易量小、并发低的系统，等两年再看看，那时候再根据国产数据库的发展情况对这个高并发系统开展国产化改造。

## 2、分布式实例一致性备份恢复如何实现？低效率SQL如何快速定位？
自动化运维：自动化运维的关注点有哪些？运维工具选择与行内现有平台的结合？分布式实例一致性备份恢复如何实现？低效率SQL如何快速定位？

**专家建议：**
- **lulihuan1987  数据库管理员 , 张家港行**
分布式数据库组件和节点较多，需要自动化运维平台方便管理，自动化平台需要重点关注：
1、 自动化安装部署，包括全量和增量部署；
2、 自动化数据库实例申请和快速自动交付；
3、 各分布式管控组件的管理和监控；
4、 各数据库节点的性能监控，例如CPU、IO、内存等等；
5、 数据库实例监控，数据库运行状态、各性能指标；性能问题快速定位，提供慢查询语句快速定位；故障诊断分析；异常会话管理等；
6、 数据库的故障切换管理，故障自动切换，故障节点更换等维护；
7、 数据库在线扩缩容；
8、 数据库备份和恢复；
分布式数据库的各节点的备份通常是物理备份，恢复时各节点通过物理备份加日志的形式进行恢复，恢复时需要考虑分布式事务一致性问题，多个节点在恢复完成后，需要确保各节点间的分布式事务是一致的，因此给恢复带来了一定的难度，需要通过日志和全局事务ID进行分布式事务补齐，各类异常场景比较复杂，可能会造成数据库一致性恢复失败，比如一些跨度较长的事务，需要各厂商提供更为完备的恢复方案，这一块在引入时需要重点关注。

慢SQL：
需要分布式数据库提供完备的自动化运维平台，能够对慢SQL进行及时收集和分析展示，便于出现性能问题时DBA能快速定位。

- **huawei851120  数据库运维工程师 , 江苏省农村信用社联合社**
问题一：分布式实例一致性备份恢复如何实现？
备份恢复是最常用的数据库日常运维手段，在分布式数据库集群中 我们一般会关注两个问题 ： 一是 数据 分片/分区存储后 ， 如何保证 备份功能 的 简单易用； 二是 在数据恢复时 如何 保证全局事务的一致性。 下面以基于MySQL+分布式中间件的xx DB 为例：
在保证分布式架构下备份功能的简单易用方面， xxDB 提供多种灵活的备份配置 ， 支持 全量 / 增量备份、定时 / 实时备份 ， 备份操作可通过管理门户界面 发起，备份任务可进行全程 可视化管理 。 此外， xxDB 提供原子脚本，可以与商用备份工具进行对接，接入统一运维系统 ， 极大降低了 备份恢复 的使用和对接难度 。
在备份恢复一致性方面， xxDB 具备 全局一致性 备份恢复能力，支持恢复到备份阶段任意时刻，恢复前后的数据保持一致，相同数据的多个副本之间保持一致 。 其实现原理主要是，利用全局事务管理器GTM保存的恢复时间点所有处在活跃状态的事务日志和全局状态信息（包含元数据、表数据、BinLog活跃事务列表等）， 将恢复出的未提交事务回滚，达到 剔除活跃事务的目的， 保证 恢复数据 的全局一致性 。

**问题二： 低效率SQL如何快速定位？**
针对低效率SQL我们需要快速定位， 分析SQL语句并优化 。 xxDB 支持对事务、SQ L 执行、锁 的 统计与审计 ，并提供DB级别的AWR报告。具体介绍如下：
1． 支持对事务进行统计与审计。举例如下： TOP5事务信息； 性能指标，TPS峰值/平均值、时延情况； 事务分布情况，总数、失败数、提交异常数等；分布式事务分布情况，包括比重、分发情况等。
2． 支持锁冲突情况展示和分析。举例如下： 数据节点上的表锁冲突率、行锁平均等待时长； 计算节点上分布式锁冲突情况，可展示发生冲突的用户原始的读/写SQL、每条SQL冲突次数、SQL详情（SQl执行时长）、SQL最终执行结果（成功、失败）等；自动记录发生锁资源竞争SQL的情况，方便用户进行关联性分析；数据节点和计算节点的锁超时次数统计。
3． 支持对SQL执行情况进行统计与审计。举例如下：慢SQL分析。按执行总时间最长、平均执行时间最长、按执行次数统计等； 各类SQL语句统计。

- **fcospt  数据库管理员 , 云南红塔银行**
分布式实例一致性备份恢复如何实现
全局一致性备份依赖于全局序发生器的生成，原生分布式数据库如oceanbase支持全局一致性备份而有的“分库分表”类型的数据库，由于有些数据库没有实现全局序生成器的机制，并不能支持全局一致性备份恢复。

低效率SQL如何快速定位
需要数据记录了SQL的执行时间、cpu、io、节点等信息，通过统一的管理平台或者系统性能视图查询低效sql。

# 三、应用改造难点实现

## 1、如何比较准确的评估改用分布式数据库时，应用的改造量？
目前的应用都是使用集中式的数据库，需要进行应用改造，但是目前面临一个问题就是：如何比较准确、客观的评估改用分布式数据库时，应用的改造量？

**专家建议：**
- **huawei851120  数据库运维工程师 , 江苏省农村信用社联合社**
这个问题其实很普遍，现在头部国产分布式数据库的几个大厂都有工具，跑一下可以把需要改造的SQL领出来看看，用工具和来辅助我们判断改造的工作量。好搞，不难！
如果之前是Oracle的，难度会较小，工作量不是很大。改造量最小的是MySQL的。

## 2、分布式数据库应用层面优化难点？
应用层面优化：分布式事务由应用实现还是数据库实现？微服务业务场景拆分时和分布式数据库适配的注意点？高速缓存集群的引入减少数据库压力，如何设计？SQL改造方面如何优化？

**专家建议：**
- **hanfeng_twt  数据库架构师 , SphereEx**
1. 分布式事务
各分布式数据库对分布式事务的实现，存在很大差异。能在上层由应用解决，对企业来说选择面更大。
2.微服务拆分
微服务拆分，是架构层面的一种措施，将业务拆分为独立单元处理。针对这一架构，对底层数据库来说会造成数据库的拆分，但是否采用分布式架构支撑不是强关联。可以通过分布式数据库，支撑多个微服务的业务单元，但需做好必要的资源隔离等。且还需关注风险性。
3.缓存与数据库
缓存的引入可以有效的解决数据库的压力问题。这其中的核心点在于效率、一致性的平衡。
4.单元化设计
单元化的设计，有效地降低了对数据库的承载力的需求。也是比较推荐的方式，这样可减低对数据库的依赖性。

# 四、总结

**通过本次交流达成交流共识如下以供参考：**

首先在应用分布式数据库时，数据库表在设计时需要考虑业务场景、表容量、常用查询SQL等因素，尽可能避免和减少跨节点流动的原则，选择合适的表类型和进行表分区；
其次，数据迁移方面，专家也给出了基于数据的逻辑迁移、基于日志的物理迁移以及基于应用的数据迁移三种方式供参考；
再次，分布式数据库全局一致性是必要的，性能的损失可以通过其他方式弥补；
最后专家对应用改造难点做了建议，从分布式事务、微服务拆分、缓存与数据库、单元化设计等方面给出了相关建议参考。

## 参与贡献嘉宾：
**苑华伟 某省农信社 分布式数据库专家**
计算机硕士学历，从事生产运维10余年，被国际灾备协会授予大师级业务连续性管理专家（MBCP）认证。先后从事IBM主机系统管理员、灾备管理员、ESB管理员、中间件管理员、数据库管理员等工作。擅长灾备建设与演练、MQ中间件运维管理、国产数据库运维管理工作。目前是twt社区数据库自主可控课题组成员之一。

**卢丽欢 江苏张家港农商银行金融科技总部运维中心主任**
长期从事数据库尤其是分布式数据库应用实践工作，具备银行核心系统、互联网聚合支付系统、信贷系统、中间业务等银行关键业务系统采用国产分布式数据库落地实践经验。

**韩锋 数据库专家**
有着丰富的一线数据库架构、软件研发、产品设计、团队管理经验。曾担任多家公司首席DBA、数据库架构师等职。在云、电商、金融、互联网等行业均有涉猎，精通多种关系型数据库，对NoSQL及大数据相关技术也有涉足，实践经验丰富。曾著有数据库相关著作《SQL优化最佳实践》、《数据库高效优化》。

**李建明 云南红塔银行信息科技部运维中心经理**
擅长基础架构规划和管理，尤其擅长全栈式性能优化，将基于云计算+微服务+OceanBase技术栈的新一代分布式架构核心系统性能优化到8000tps，在数据库方面有丰富的经验（熟悉informix、oracle、elasticsearch、oceanbase等数据库）

** 夏茂宣  农商银行 资深DBA**

银行数据库国产化应用改造国产数据库数据库迁移数据一致性

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！