国产数据库应用实践三大难点剖析总结.docx

企业国产数据座应用实践问题及难点剖析总结导读传统企业现在的系统绝大多数还是运行在Orade,D82等国外商业数据库上，随者近也年来数据库的变化,正有越来越多的企业面临将传统数据库迁移到开源或新型商业产品上才能实现自主可控的目标.然而不同数据库的特性有差别SQ1.语法也有很多差异，因此在迁移数据库的过程中不仅涉及数据的迁移，还包括应用的适配改造.首先,从传统集中式数据库迁移到国产分布式数据库,异构的两种数据库差别非常大,计笄方式、数据存储、架构设计都区别较大,系统迁移时往往涉及大量的表结构设计调整、业务Ift构'应用改造，同时给数据迁移带来了一定困难：其次,分布式数据库多节点设计给全局一致性的实现带来了一定的要求和难度.分布式数据库如果不实现全局一致，可能会带来踏节点任务的数据不一致性问题（当然,这个问题可以通过应用改造去规避，但是对业务的侵入性较大）：最后,应用适配分布式数据库,不仅仪是SQ1.语法语义层面的转换，还会涉及到业务的优化,应用架构优化等等方面。所以，困绕喟产数据库数据分片和迁移魔点实现"、“全局一致性疑点实现”以及“应用改造魔点实现"二个方面.本期论坛组织了“国产数据库应用实践难点线上核心探讨特邀请了金融企业有国产数据库实践经验的专家，针对以上三个方面进行了充分的讨论.现将交流内容和精彩Ial答整理如下，以供大家学习交流.执笔专家卢欢数据库自主可控用户委员会委员云原生应用创新实践联盅一一数据库自主可控方向课题组专家.长期从事数据库尤其是分布式数据库应用实践工作，具备银行核心系统、互联网聚合支付系统、信贷系统、中间业务等假行关犍业务系统采用国产分布式数据库落地实践经验.协作专家苑华伟数据库自主可控用户委员会委员云原生应用创新实践联盅一一数据库自主可控方向深四组专家.计JT机硕土学历,从事生产说维10氽年，被国际灾需协会授予大师级业务连续性管理（?家（MBCP）认证。先后从事IBM主机系统管理员、灾备管埋员、ESB管理员、中间件管理员,数据库管理员等工作.班氏灾备建设与演练、MQ中间件运维管理、国产数据库运维管理工作.“悻数据鼻自主可控用户委员会委员云原生应用创新实践联盅一一数据库自主可控方向深四组专家.有辱丰常的一跳数据庠架构、软件研发、产品设计、团队管理经脸.普拒仔多家公司首席DBA.数据库架构师等职。在云、电商、金融、互联网等行业均有涉猎，精辿多种关系型数据库，对N。$Ql.及大数据相关技术也有涉足，实践经脸丰亩,内普有数据库相关著作ESQ1.优化最佳实践：，、（数据库高效优化.李建典数据率自主可控用户委员会委员云原生应用创新实践联盟一一数据库自主可控方向课超组专家.投长基础架构规划和管理,尤其擅长全栈式性能优化，将基于云计总+微服务+。CeanBase技术栈的新一代分布式架构核心系统性能优化到8000tps:在数据库方面仃上富的般验.熟悉Informix.oracle«elasticsearchOCeanbaSe等数据库。一、国产数据摩数据分片和迁移难点实现1、建表基本问题，结合做行业务系统改造案例，介绍下如何进行表容量规划？【问题描述】建表时褥要考虑我的容IK该表常用SQ1.以及字段类型选择，请结合银行业务系统改造案例,介绍卜.如何遂行表容量规划，该表常用SQ1.的提取分析,以及字段类型选择的注意点（主要是字段长度较长的情况）等.专家建议Im数据阵自主可拄用户委员会委员，1.表容量的规划这一问题本质是数据对象的生命周期管理，针对数据对象在生命周期内的创建、增、喇、改及归档销毁等做到前期规划根据数据访问特征,对表内数据量的变化做到预测评估.尽量在早期阶段对表做好分片'分区、归档策珞等规划.2 .常用SQ1.提取分析对数据时象的访问，SQl是主要的方式.船要定期分析SQl,提升访问效率.对表的访问往往是比较多元的，需要区分业务与非业务、常规与非常规、定期与随机、高频与低频等SQ1.访问特征优先处理业务、常规、定期、高频的SQ1.提取方法是有很多,很多平台也都提供了相应工具完成提取和分析的工作.3 .字段类型选择关于字段类型的选择上，可本若如下原则：-尽量使用筒的字段类型，针时如1.OB、JSoN等类型减少使用选择鲁适的数据类型（如口期就选择口期类型，而非数字或字符和适当的精度对于超长的数据，原则上不建议在数据库内存储，可通过外置方式保存.Xiamx某农商行DBAj字段类型选择通常都用Vardlar,字段长度固定的情况才使用char日期就用日期，文档图片类型用lob：你的问然不太明确，不清楚你在哪些字段抉择上遇到问题.表容量问题和业务情况总息相关,通常只计算流水、交易记录等量大的表,三年未能达到千万级的表通常不考虑。而这些量大的数据通常有生命周期,保留三年或者五年，需要根据业务去估算周期内的行数,在乘以121.8进行预留,行数和所占空间的比例需要测试才能知道结果，城终能估算出所需的空间.2、结合银行关健业务系统表类型如何设计，重点表分别选算了什么类型的表？【问时描述】分布式数据库里有广播表（年个数据节点都有全埴）、分片表（年个数据节点存储部分数据）以及普通表（仅存在于某个数据节点）,请结合银行关键业务系统案例介绍该系统表类型如何设计,重点表分别选择了什么类型的表？专家建议Im数据阵自主可控用户委员会委员：选择表的类型,还是根据表的使用特征来分析。1 .广播表：适合于低频修改，高频台询的场景2 .分片表：适合于数据规模大，制要数据拆分的场景3 .普通表：适合于需精确控制存储位置或者使用频率很低，性能要求不高的情况卢加欢数据摩自主可控用户委员会委员，广播我（每个数据节点都有全扇）：小表广播，数据破不大，经常关联但更新较少的场景，比如参数表，像机构表、利率表、产品衣等：分片表（每个数据打点存船部分数据）：除小表广播以外的其他业务相关的表，建议均采用分片表，以确保分布式数据库的性能和扩展性，例如账户信息表、客户信息表、交易信息表等等：普通表仅存在于某个数据书点）：不具备可扩展性，所以业务表不建议使用,除非是一些特点场景，比如一些临时表，数据G也不少特别大的可以使用。3、结合18行知业务系统介阚下分片字段选算的原则？【问题描述】分片字段选择是分布式数据库适配的关键，关系到数据的分布，鱼询的效率，以及扩展性，请结合银行关进业务系统案例介绍卜分片字段选择的原则,重点表如何选取分片字段,可以和“表类型选择“问题联合ia行介绍专家建披，xiamx某农育行DBA：这个问题是要和该表适不适合做分表、其他相关联表的分片字段一起讨论的“通常做分表的数据地一定是足劣大才考虑的，如果数据地小，就算有良好的分片字段，也没有做分片的必要,可以考虑做成广播表或单表。这样就可以规避掉很多分片字段的选择场景。分布式数据库在分表之间关联时，如果关联字段不是分片字段，则会引发数据上拉进行蹈分片关联,性能损耗极大因此在选择分片字段依据并且只依据关联分表的分片字段情况。首先定好分片基调，例如银行系统通常选择是账号或卡号，将所有与账户关联的分表全部按业务逻辑的账号或卡号的字段进行分片，便于与账户主表的关联，对于其他的分表.则根据关联查询的表一起协定用一个字段做分片，尽可加统一.如果一个分表同时要和两个分表做关联,且关联字段不同，解决思路：1.该表能否做成广播表;2.是否能改查询逻粉，与其中一个分表不做直接关联。如果分表没有关联其他表,字段选择优先能够让数据均匀分布到各个分片上的字段,通常选唯一主键.苒锋数据嗥自主可拄用户委员会委员.分片字段的选界，制涉及的因素很多，可大致分为以下几个方面：1 .数据结构主键或唯一索引字段是否要包含如分片字段，很多数据库从唯一性校险,是必须要求包含分片键在其中，否则无法完成校验工作.索引字段对分片字段的选择上，没有直接影响，对于全国索引的，可考虑通过二级索引表的方式解决：对于普通索引，则可以在分片基础上做本地索引.字段类型，选择适合分片的字段作为分片被。常见的分片类不包括有数字、口期、文本等.2 .数据特征表规模，是是否使用分片的关键因素之一,表做分片后，协必会造成一定的"功能退化3如能采取其他方式缩小表的大小，尽后采用。可通过表的全生命周期规划，如常规的数据归档、压缩、转储、清理策略，然少数据的。此外，数据库内置的如去分区、垂直分表等策略也Ur以有效减小表的大小。数据离散度，按某个字段或字段组合后，表的数据是否足鲂分散。数据分片的初理就是政少表的规模，尽量做到数据打放是其根本晚则之一。这里需要统计数据拆分后离散程度,尽量选择能充分打散的字段作为分片键.这里需注意如果选择字段是带有业务特征，还要关注未来业务变化对它的影响.3 .访问特征可变化性，选择相对固定、不再变化的字段作为分片湿。虽然有些数据库也支持分片键的修改，但毕竟修改后会涉及数据移动，成本代价很高：还是优选不变的字段为好.事务隔宙，尽量选择按字段拆分后的数据,对数据的变化处理可集中在分片内解决.这样大家的业务变化是可以通过1.ocal的事务完成，开销比全匾的要小很多，效率也高。关联字段,如后续此表与其他关联表经常联合使用，优先那些参与到关联操作的字段为佳.尽批是数据在关联后，能在本地完成Join的动作，减少数据ShUffle或上移汇聚类的操作。4 .其他因索如涉及到多个字段作为分片键的话，还需考虑如字段顺序等问题。4、国产分布式数据阵如何解决计算下沉的问JB,是否有一些通用的规则？专索建议I卢丽欢数据库自主可控用户委员会委员I分布式数据库数据下沉属于数据底杳询算法优化的范晡，时于我们使用者来说，尽可能在数据库表设计的时候合理设计，例如分片字段的设计,广播表的使用，增加冗余字段作为分区建，杳询时她少关联层级，尽可能使用分区建关联，才能达到较好的性能，5、分布式数据阵的通用分片规则参考的因素有哪些，分别如何评估和取舍，是否有统一的方法论？专宗建议：ych370北银金科系统运修工程师;分片分为横向和纵向，一般都选择横向分片，按照个线一的字段进行分片，按照数据砧的大小，分片字段建议复僧少，便于索引，通常选择编号类的主铤进行分片，分片不建议太多，适量就行，要考虑检索的速度和后期的扩展性。一般很少有人用双向分片，主要是因为目前的数据结构化原因,纵向类似业务的分库分表,代价大，难度高苑华伟数据率自主可控用户委员会委员：说句实在话,Oracle也好,DB2也好，其实功能非常丰田，但是我们能用的功能非常少.用的功能越简单，越不会出问即，国产分布式数据库也是的，进行分片，别搞那些千奇百怪的，什么自定义分片规则、三级分片、分片之后再分片的多级分片之类的看起来很高端，复杂容易出问题.就是奴简单的，哈希,或者范因(Range).如果这两种搞不定,这套系统就先不要摘分布式改造！真的，越简单越好！6、在表结构，业务构的情况下，如何进行数Ie迁移，确保安全准确？【问题描述】数据迁移难题：这里的曳点不讨论迁移工具，讨论落地迁移方案，确保数如迁移的准确性，尤其是在表结构，业务重构的情况下，如何进行数据迁移，确保安全准确。请结合银行关犍业务系统案例，介绍下数据迁移的方案.专媒建议：KW数据志自主可拄用户委员会委员.数据迁移的方案，从大的分类上有三种：1 .基于数据的逻辑迁移这种方式的适配范围更广,适配场景多,但迁移效率一般较差其对库表结构有要求.2 .基于H志的物理迁移这种方式的实时性较高，但需做更多的适配性工作，3 .基于应用的数据迁移这种方式属于定制方案，需要应用例解决数据迁移问题，效率中等，可加入定制策略，在保证数据安全方面，可通过数据校验完成.一般的迁移都支持窗线的校验，原理是通过某种算法时部分或全部字段实现校验：或者通过采样统计的方式完成，二、全局一致性点实现1、金融企业应用分布式数据摩全局强一致性与性能取舍，这方面问题如何考虑？【问题描述】提供全局强一致性校验的分布式数据库,能第达到集中式数据库那样的强一致性需求,但是相应也会带来性能的损失,而有的业务系统为了确保性能,通过业务改造和数据陈设计，弱化强一致性要求，即使全局最终一致性也能满足业务需求.那么，坚持开启全局强致，还是关闭全局强一致，通过改造规避影响？结合银行核心、信用卡、互联网金融系统等关键业务系统改造案例，介绍该方面的问题是如何考虑的？专家建议：卢丽欢数据库自主可控用户委员会委员，从分布式数据库的角度看，金局强致性开启后会由专门的组件负责全局事务的管理，在数据查询时也褥要判断数据的提交状态，对于存:在大地分布式M务两阶段提交场景的应用.公有一定的查询性能的卜降,大概公卜降10%左右.从分布式数据庠的发展来看.全局强一致性是必要的功能,起码把开启和关闭的权限交由客户决定，通过提高全局事务管理组件的性能和高可用，可以缓解性能下降的问题,对于事务较小的交易，例如单事务的平均SQl数G在100以内的交易，开启强一致性杳询带来的性能损耗是完全可以接受的，而对于电事务的平均SQI数m在300以上的交易，那么开启后带来的性能损耗客户是有一点感知的，一个交易应用和数据库进行300次以上的交互，其中网络、数据库的耗时加起来交易耗时可能达到SoomS以上.当然这个问题也Ur以通过将事务改造成小事务来解决问题，当然也会给应用的改造带来一定负担.，现阶段的情况来看，建议业务迁移分布式数据库时原则上是开启全局强一致性，通过优化抵消开启的损耗.李建明数据库自主可控用户委员会委员，“分年分表”类型的分布式数据库一般采用强同步的方式实现写一致性，可用性较差，而原生分布式数据摩一般采用PaxosRaft等多节点同步一致性的技术，可用性较好。此外“分库分表”类型的分布式数据库，应用在不知道数据的分片被的情况下,需要对所有主库发起SQ1.导致性或较差：为提高系统性能，在操作数据时应用需要带上分片窟，使得对应用的改造搔很大.骅修数据定自主可拄用户委员会委员I是否启用强一致性，主要取决丁业务架构。针对全局强一致是刚需，绝大部分业务都是器要的.只有当业务做过单元化改造，也做到局部的业务闭环下可考虑关闭全局一致，提升效率.苑华伟数据帛自主可控用户委员会委员,本次回答是培T2022年国产数据库的发展阶段进行.财丁金融行业，保证分布式数据库的强一致性是金融企业的首选,尤其对于银行业来说哪怕不是核心系统,也不是什么重要系统,就是更要等级一段但是交易并发量高的系统。保证分布式数据库的强一致性，仍然是首选.至于性能方面的取舍，我不认为这是个问题.如果有问题的话，可能是某家银行引进的国产分布式数据库，还不够成熟稳定，或者用的不是国内头部几家大厂的分布式数据库产品，我们想想，MySQ1.开源社区版，很多商业银行用MySQl既能保障数据库的强一致性，也能支持一定的并发。如果花钱用了某款商用的国产分布式数据库（很可能是基于MySQ1.改进的），性能反而不如MySQ1.,或者没法保障事务的强一致性了。那我只能说：1.别玩了,换头部厂家的国产分布式数据库吧个别银行的核心系统的数据库已经完成了国产化改造，已经实现了超高并发的同时解决了强一致性的问题,这个问西的提出可能是客户用到了不够成熟的产品。2.可能真的是这个系统的交易量太大，那就再等等，先别泉这个系统的数据库做国产化改造，再等等.先改造交易量小、并发低的系统，等两年再看看，那时候再根据国产数据库的发展情况对这个商并发系统开展国产化改造，2、分布式实例一致性备份恢复如何实现？低效率SQ1.如何快速定位？.【问题描述】自动化运维：自动化运维的关注点有哪些？运维工具选择与行内现有平台的结合？分布式实例一致性备份恢复如何实现？低效率SQl如何快速定位？专嘉建议，卢国欢数据库自主可控用户委员会委员，分布式数据库组件和节点较多，制要自动化运维平台方便管理，自动化平台能要更点关注：1、自动化安袋部署,包括全fit和地量部署：2.自动化数据库实例申请和快速自动交付：3、各分布式管控组件的管理和监控：4、各数据库节点的性能监控，例如CPU、10、内存等等：写、数据库实例监控,数据库运行状态、各性能指标：性能同胞快速定位,提供慢查询语句快速定位：故障诊断分析：异常会话管理等：6、数据库的故障切换管理，故障自动切换，故障节点更换等维护；7、数据库在线扩缩容;8、数据库省份和恢IG分布式数据底的各节点的名份通常是物理备份，快史时各节点通过物理备份加H志的形式进行恢复，恢宏时而要考虑分布式事务一致性何时，多个节点在恢复完成后，福要确保各节点间的分布式事务是一致的，因此给恢发带来了一定的难度，需要通过日志和全局事务ID进行分布式事务补齐.各类异常场景比较现杂，可能会造成数据库一致性恢12失败,比如一些跨度较长的事务，需要各厂商提供更为完拓的恢亚方案，这一块在引入时需要重点关注.接SQ1.福要分布式数据库提供完的自动化运维平台，能修时慢SQ1.进行及时收集和分析展示,便FHI现性能问题时DBA能快速定位。苑华伟数霜率自主可控用户委员会委员：问题一：分布式实例一致性备份恢复如何实现？符份帙笈是必常用的数据库日常运维手段,在分布式数据库集群中，我们一般会关注两个问题：一是数据分片/分区存储后，如何保证得份功能的简单易用：二是在数据恢复时如何保证全局事务的一致性.下面以基于MVSQ1.分布式中间件的某数据库为例：在保证分布式架构下备份功能的简单易用方面，该数据摩提供多种灵活的备份配迎.支持全量/增St备份、定时/实时得份,备份操作可通过管理门户界面发起,备份任务Ur进行全程可视化管理.此外，该数据扉提供原子脚本，可以与商用备份工具进行对接,接入统一运维系统,极大降低了备份快史的使用和对接难度.在备份恢复一致性方面，该数据库具备全局一致性备份恢复能力,支持恢应到备份阶段任意时刻，恢复前后的数据保持一致,相同数据的多个副本之间保持一致.其实现原理主要足，利用全局事务管理岩GTM保存的恢红时间点所有处在活跌状态的事务日志和全局状态信息（包含元数据、表数拉;、Binlog活跃事务列表等），将恢复出的未提交事务回滚，达到别除活跃事务的目的，保证恢笈数据的全局一致性。问题二：低效率SQI如何快速定位？针对低效率SQl我们需要快速定位,分析SQ1.语句并优化。该数据库支持对事务、SQ1.执行'船的统计与审计，并提供DB级别的AWR报告.具体介绍如下：1）支持对事务进行统计与审计.举例如下：T0P5%务信息；性能指标，TPS峰值/平均值、时必情况：事务分布情况，总数、失双数、提交异常数等：分布式事务分布情况.包括比电、分发情况等.2）支持镇冲突情况展示和分析，举例如下：数据节点上的表锁冲突率、行镇平均等待时长：计并节点上分布式锁冲突情况，可展示发生冲突的用户原始的读/写SQ1.、杼条SQ1.冲突次数、SQ1.详情（SQl执行时长）、SQ1.最终执行结果（成功、失败）等:自动记录发生镣资源竞争SQ1.的情况，方便用户进行关联性分析：数据书点和计算打点的领超时次数统计。3）支持对SQ1.执行情况进行统计与审计。举例如F：慢SQ1.分析，按执行总时间最长、平均执行时间最长、按执行次数统计等：各类SQ1.语句统计.李建明数据库自主可控用户委员会委员，分布式实例致性备份恢宏如何实现？全局一致性备份依赖于全周序发生揖的生成.有的原生分布式数据库支持全局一致性备份而有的"分库分表”类况的数据库，但右些数据标没H实现全局序生成落的机制，并不能支持全局一致性备份恢攵.低效率SQ1.如何快速定位？需要数据记录了SQ1.的执行时间、CPU.10、节点等信息，通过统一的管理平台或者系统性能视图查询低效Sq1.三、应用改造难点实现1、如何比较准确的评估改用分布式敷Ii座时，应用的改造：?【问题描述】目前的应用都是使用集中式的数据库，需要进行应用改造，但是目前面临一个问Sfi就是：如何比较准确、客观的评估改用分布式数据阵时，应用的改造以？专家建议，苑华伟数据库自主可控用户委员会委员I这个问咫其实很普遍，现在头部国产分布式数据库的几个大厂都有工具，跑下可以把需要改造的SQI领出来看看，用工具和来辅助我们判断改造的工作依，好搞，不难！如果之前是Orade的，维度会较小，工作量不是很大。改造城城小的是MYSQ1.的.2、分布式嫡翼阵应用层面优化膜点？【问题描述】应用层面优化：分布式步务由应用实现还是数据摩实现？微服务业务场景拆分时和分布式数据库适配的注意点？高速缓存集群的引入减少数据库压力,如何设计？SQ1.改造方面如何优化？专家建披，WW数据席自主可控用户委员会委员：1.分布式事务各分布式数据库对分布式事务的实现，存在很大差异e能在上层由应用解决，对企业来说选择面更大。2 .微服务拆分微服务拆分，是架构层面的一种措施，将业务拆分为独立单元处理.针对这一架构，对底层数据阵来说会造成数据库的拆分，但是否采用分布式架构支撑不是强关联。可以通过分布式数据库，支捽多个微服务的业务IR元，但褥做好必要的资源隔阈等，且还褥关注风险性。3 .缓存与数据库缓存的引入可以有效的斛决数据库的压力问题。这其中的核心点在于效率、一致性的平衡.4 .单元化设计的元化的设计，有效地降低了对数据库的承载力的噩求。也是比较推荐的方式，这样可降低对数据库的依赖性.四、总结通过本次交流达成交流共识如下以供参考：首先，花应用分布式数据库时，数据库表在设计时需要考虑业务场景、发容Gh常用杳询SQ1.等因素，尽可能避免和减少跨节点流动的原则，选择会适的表类型和进行表分区：其次，数据迁移方面，C家也给出了基丁数据的遗辑迂移、基于口志的物理迂移以及基F应用的数据迂移三种方式供参考：再次，分布式数据库全同致性足必要的，性能的损失可以通过其他方式弥补：后，专家对应用改造难点做了建议，从分布式事务、徵服务拆分、缓存与数据库、单.元化设计等方面绐出了相关建议参考。