1、建表基本问题 结合银行业务系统改造案例，介绍下如何进行表容量规划？

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

@hanfeng_twt  SphereEx 数据库架构师

1.表容量的规划

这一问题本质是数据对象的生命周期管理，针对数据对象在生命周期内的创建、增、删、改及归档销毁等做到前期规划。根据数据访问特征，对表内数据量的变化做到预测评估，尽量在早期阶段对表做好分片、分区、归档策略等规划。

2.常用SQL提取分析

对数据对象的访问，SQL是主要的方式。需要在定期分析SQL，提升访问效率。对表的访问玩玩是比较多元的，需要区分业务与非业务、常规与非常规、定期与随机、高频与低频等SQL访问特征。优先处理业务、常规、定期、高频的SQL。提取方法是有很多，很多平台也都提供了相应工具完成提取和分析的工作。

3.字段类型选择

关于字段类型的选择上，可本着如下原则

- 尽量使用简单字段类型，针对如LOB、JSON等类型减少使用

- 选择合适的数据类型（如日期就选择日期类型，而非数字 字符 和适当的精度

- 对于超长的数据，原则上不建议在数据库内存储，可通过外置方式保存。

@xiamx 某农商行 DBA

字段类型选择通常都用varchar,字段长度固定的情况才使用char， 日期就用日期 ，文档图片类型用lob；你的问题不太明确，不清楚你在哪些字段抉择上遇到问题。

表容量问题和业务情况息息相关，通常只计算流水、交易记录等量大的表，三年未能达到千万级的表通常不考虑。而这些量大的数据通常有生命周期，保留三年 者五年，需要根据业务去估算周期内的行数，在乘以1.2 1.8进行预留，行数和所占空间的比例需要测试才能知道结果，最终能估算出所需的空间。

2、结合银行关键业务系统表类型如何设计，重点表分别选择了什么类型的表？

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

@hanfeng_twt  SphereEx 数据库架构师

选择表的类型，还是根据表的使用特征来分析。

1.广播表 适合于低频修改，高频查询的场景

2.分片表 适合于数据规模大，需要数据拆分的场景

3.普通表 适合于需精确控制存储位置 者使用频率很低，性能要求不高的情况

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

广播表（每个数据节点都有全量 小表广播，数据量不大，经常关联但更新较少的场景，比如参数表，像机构表、利率表、产品表等；

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

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

3、结合银行关键业务系统介绍下分片字段选择的原则？

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

@xiamx 某农商行 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能快速定位。

1、如何比较准确的评估改用分布式数据库时，应用的改造量？

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

@huawei851120 江苏省农村信用社联合社 数据库运维工程师

这个问题其实很普遍，现在头部国产分布式数据库的几个大厂都有工具，跑一下可以把需要改造的SQL领出来看看，用工具和来辅助我们判断改造的工作量。好搞，不难！
如果之前是Oracle的，难度会较小，工作量不是很大。改造量最小的是MySQL的。

2、分布式数据库应用层面优化难点？

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

@hanfeng_twt  SphereEx 数据库架构师

1.分布式事务

各分布式数据库对分布式事务的实现，存在很大差异。能在上层由应用解决，对企业来说选择面更大。

2.微服务拆分

微服务拆分，是架构层面的一种措施，将业务拆分为独立单元处理。针对这一架构，对底层数据库来说会造成数据库的拆分，但是否采用分布式架构支撑不是强关联。可以通过分布式数据库，支撑多个微服务的业务单元，但需做好必要的资源隔离等。且还需关注风险性。

3.缓存与数据库

缓存的引入可以有效的解决数据库的压力问题。这其中的核心点在于效率、一致性的平衡。

4.单元化设计

单元化的设计，有效地降低了对数据库的承载力的需求。也是比较推荐的方式，这样可减低对数据库的依赖性。

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