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

上传人:王** 文档编号:1422494 上传时间:2024-07-08 格式:DOCX 页数:11 大小:25.92KB
下载 相关 举报
国产数据库应用实践三大难点剖析总结.docx_第1页
第1页 / 共11页
国产数据库应用实践三大难点剖析总结.docx_第2页
第2页 / 共11页
国产数据库应用实践三大难点剖析总结.docx_第3页
第3页 / 共11页
国产数据库应用实践三大难点剖析总结.docx_第4页
第4页 / 共11页
国产数据库应用实践三大难点剖析总结.docx_第5页
第5页 / 共11页
国产数据库应用实践三大难点剖析总结.docx_第6页
第6页 / 共11页
国产数据库应用实践三大难点剖析总结.docx_第7页
第7页 / 共11页
国产数据库应用实践三大难点剖析总结.docx_第8页
第8页 / 共11页
国产数据库应用实践三大难点剖析总结.docx_第9页
第9页 / 共11页
国产数据库应用实践三大难点剖析总结.docx_第10页
第10页 / 共11页
亲,该文档总共11页,到这儿已超出免费预览范围,如果喜欢就下载吧!
资源描述

《国产数据库应用实践三大难点剖析总结.docx》由会员分享,可在线阅读,更多相关《国产数据库应用实践三大难点剖析总结.docx(11页珍藏版)》请在优知文库上搜索。

1、企业国产数据座应用实践问题及难点剖析总结导读传统企业现在的系统绝大多数还是运行在Orade,D82等国外商业数据库上,随者近也年来数据库的变化,正有越来越多的企业面临将传统数据库迁移到开源或新型商业产品上才能实现自主可控的目标.然而不同数据库的特性有差别SQ1.语法也有很多差异,因此在迁移数据库的过程中不仅涉及数据的迁移,还包括应用的适配改造.首先,从传统集中式数据库迁移到国产分布式数据库,异构的两种数据库差别非常大,计笄方式、数据存储、架构设计都区别较大,系统迁移时往往涉及大量的表结构设计调整、业务Ift构应用改造,同时给数据迁移带来了一定困难:其次,分布式数据库多节点设计给全局一致性的实现

2、带来了一定的要求和难度.分布式数据库如果不实现全局一致,可能会带来踏节点任务的数据不一致性问题(当然,这个问题可以通过应用改造去规避,但是对业务的侵入性较大):最后,应用适配分布式数据库,不仅仪是SQ1.语法语义层面的转换,还会涉及到业务的优化,应用架构优化等等方面。所以,困绕喟产数据库数据分片和迁移魔点实现、“全局一致性疑点实现”以及“应用改造魔点实现二个方面.本期论坛组织了“国产数据库应用实践难点线上核心探讨特邀请了金融企业有国产数据库实践经验的专家,针对以上三个方面进行了充分的讨论.现将交流内容和精彩Ial答整理如下,以供大家学习交流.执笔专家卢欢数据库自主可控用户委员会委员云原生应用创

3、新实践联盅一一数据库自主可控方向课题组专家.长期从事数据库尤其是分布式数据库应用实践工作,具备银行核心系统、互联网聚合支付系统、信贷系统、中间业务等假行关犍业务系统采用国产分布式数据库落地实践经验.协作专家苑华伟数据库自主可控用户委员会委员云原生应用创新实践联盅一一数据库自主可控方向深四组专家.计JT机硕土学历,从事生产说维10氽年,被国际灾需协会授予大师级业务连续性管理(?家(MBCP)认证。先后从事IBM主机系统管理员、灾备管埋员、ESB管理员、中间件管理员,数据库管理员等工作.班氏灾备建设与演练、MQ中间件运维管理、国产数据库运维管理工作.“悻数据鼻自主可控用户委员会委员云原生应用创新实

4、践联盅一一数据库自主可控方向深四组专家.有辱丰常的一跳数据庠架构、软件研发、产品设计、团队管理经脸.普拒仔多家公司首席DBA.数据库架构师等职。在云、电商、金融、互联网等行业均有涉猎,精辿多种关系型数据库,对N。$Ql.及大数据相关技术也有涉足,实践经脸丰亩,内普有数据库相关著作ESQ1.优化最佳实践:,、(数据库高效优化.李建典数据率自主可控用户委员会委员云原生应用创新实践联盟一一数据库自主可控方向课超组专家.投长基础架构规划和管理,尤其擅长全栈式性能优化,将基于云计总+微服务+。CeanBase技术栈的新一代分布式架构核心系统性能优化到8000tps:在数据库方面仃上富的般验.熟悉Info

5、rmix.oracleelasticsearchOCeanbaSe等数据库。一、国产数据摩数据分片和迁移难点实现1、建表基本问题,结合做行业务系统改造案例,介绍下如何进行表容量规划?【问题描述】建表时褥要考虑我的容IK该表常用SQ1.以及字段类型选择,请结合银行业务系统改造案例,介绍卜.如何遂行表容量规划,该表常用SQ1.的提取分析,以及字段类型选择的注意点(主要是字段长度较长的情况)等.专家建议Im数据阵自主可拄用户委员会委员,1.表容量的规划这一问题本质是数据对象的生命周期管理,针对数据对象在生命周期内的创建、增、喇、改及归档销毁等做到前期规划根据数据访问特征,对表内数据量的变化做到预测评

6、估.尽量在早期阶段对表做好分片分区、归档策珞等规划.2 .常用SQ1.提取分析对数据时象的访问,SQl是主要的方式.船要定期分析SQl,提升访问效率.对表的访问往往是比较多元的,需要区分业务与非业务、常规与非常规、定期与随机、高频与低频等SQ1.访问特征优先处理业务、常规、定期、高频的SQ1.提取方法是有很多,很多平台也都提供了相应工具完成提取和分析的工作.3 .字段类型选择关于字段类型的选择上,可本若如下原则:-尽量使用筒的字段类型,针时如1.OB、JSoN等类型减少使用选择鲁适的数据类型(如口期就选择口期类型,而非数字或字符和适当的精度对于超长的数据,原则上不建议在数据库内存储,可通过外置

7、方式保存.Xiamx某农商行DBAj字段类型选择通常都用Vardlar,字段长度固定的情况才使用char日期就用日期,文档图片类型用lob:你的问然不太明确,不清楚你在哪些字段抉择上遇到问题.表容量问题和业务情况总息相关,通常只计算流水、交易记录等量大的表,三年未能达到千万级的表通常不考虑。而这些量大的数据通常有生命周期,保留三年或者五年,需要根据业务去估算周期内的行数,在乘以121.8进行预留,行数和所占空间的比例需要测试才能知道结果,城终能估算出所需的空间.2、结合银行关健业务系统表类型如何设计,重点表分别选算了什么类型的表?【问时描述】分布式数据库里有广播表(年个数据节点都有全埴)、分片

8、表(年个数据节点存储部分数据)以及普通表(仅存在于某个数据节点),请结合银行关键业务系统案例介绍该系统表类型如何设计,重点表分别选择了什么类型的表?专家建议Im数据阵自主可控用户委员会委员:选择表的类型,还是根据表的使用特征来分析。1 .广播表:适合于低频修改,高频台询的场景2 .分片表:适合于数据规模大,制要数据拆分的场景3 .普通表:适合于需精确控制存储位置或者使用频率很低,性能要求不高的情况卢加欢数据摩自主可控用户委员会委员,广播我(每个数据节点都有全扇):小表广播,数据破不大,经常关联但更新较少的场景,比如参数表,像机构表、利率表、产品衣等:分片表(每个数据打点存船部分数据):除小表广

9、播以外的其他业务相关的表,建议均采用分片表,以确保分布式数据库的性能和扩展性,例如账户信息表、客户信息表、交易信息表等等:普通表仅存在于某个数据书点):不具备可扩展性,所以业务表不建议使用,除非是一些特点场景,比如一些临时表,数据G也不少特别大的可以使用。3、结合18行知业务系统介阚下分片字段选算的原则?【问题描述】分片字段选择是分布式数据库适配的关键,关系到数据的分布,鱼询的效率,以及扩展性,请结合银行关进业务系统案例介绍卜分片字段选择的原则,重点表如何选取分片字段,可以和“表类型选择“问题联合ia行介绍专家建披,xiamx某农育行DBA:这个问题是要和该表适不适合做分表、其他相关联表的分片

10、字段一起讨论的“通常做分表的数据地一定是足劣大才考虑的,如果数据地小,就算有良好的分片字段,也没有做分片的必要,可以考虑做成广播表或单表。这样就可以规避掉很多分片字段的选择场景。分布式数据库在分表之间关联时,如果关联字段不是分片字段,则会引发数据上拉进行蹈分片关联,性能损耗极大因此在选择分片字段依据并且只依据关联分表的分片字段情况。首先定好分片基调,例如银行系统通常选择是账号或卡号,将所有与账户关联的分表全部按业务逻辑的账号或卡号的字段进行分片,便于与账户主表的关联,对于其他的分表.则根据关联查询的表一起协定用一个字段做分片,尽可加统一.如果一个分表同时要和两个分表做关联,且关联字段不同,解决

11、思路:1.该表能否做成广播表;2.是否能改查询逻粉,与其中一个分表不做直接关联。如果分表没有关联其他表,字段选择优先能够让数据均匀分布到各个分片上的字段,通常选唯一主键.苒锋数据嗥自主可拄用户委员会委员.分片字段的选界,制涉及的因素很多,可大致分为以下几个方面:1 .数据结构主键或唯一索引字段是否要包含如分片字段,很多数据库从唯一性校险,是必须要求包含分片键在其中,否则无法完成校验工作.索引字段对分片字段的选择上,没有直接影响,对于全国索引的,可考虑通过二级索引表的方式解决:对于普通索引,则可以在分片基础上做本地索引.字段类型,选择适合分片的字段作为分片被。常见的分片类不包括有数字、口期、文本

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

13、片湿。虽然有些数据库也支持分片键的修改,但毕竟修改后会涉及数据移动,成本代价很高:还是优选不变的字段为好.事务隔宙,尽量选择按字段拆分后的数据,对数据的变化处理可集中在分片内解决.这样大家的业务变化是可以通过1.ocal的事务完成,开销比全匾的要小很多,效率也高。关联字段,如后续此表与其他关联表经常联合使用,优先那些参与到关联操作的字段为佳.尽批是数据在关联后,能在本地完成Join的动作,减少数据ShUffle或上移汇聚类的操作。4 .其他因索如涉及到多个字段作为分片键的话,还需考虑如字段顺序等问题。4、国产分布式数据阵如何解决计算下沉的问JB,是否有一些通用的规则?专索建议I卢丽欢数据库自主

14、可控用户委员会委员I分布式数据库数据下沉属于数据底杳询算法优化的范晡,时于我们使用者来说,尽可能在数据库表设计的时候合理设计,例如分片字段的设计,广播表的使用,增加冗余字段作为分区建,杳询时她少关联层级,尽可能使用分区建关联,才能达到较好的性能,5、分布式数据阵的通用分片规则参考的因素有哪些,分别如何评估和取舍,是否有统一的方法论?专宗建议:ych370北银金科系统运修工程师;分片分为横向和纵向,一般都选择横向分片,按照个线一的字段进行分片,按照数据砧的大小,分片字段建议复僧少,便于索引,通常选择编号类的主铤进行分片,分片不建议太多,适量就行,要考虑检索的速度和后期的扩展性。一般很少有人用双向

15、分片,主要是因为目前的数据结构化原因,纵向类似业务的分库分表,代价大,难度高苑华伟数据率自主可控用户委员会委员:说句实在话,Oracle也好,DB2也好,其实功能非常丰田,但是我们能用的功能非常少.用的功能越简单,越不会出问即,国产分布式数据库也是的,进行分片,别搞那些千奇百怪的,什么自定义分片规则、三级分片、分片之后再分片的多级分片之类的看起来很高端,复杂容易出问题.就是奴简单的,哈希,或者范因(Range).如果这两种搞不定,这套系统就先不要摘分布式改造!真的,越简单越好!6、在表结构,业务构的情况下,如何进行数Ie迁移,确保安全准确?【问题描述】数据迁移难题:这里的曳点不讨论迁移工具,讨论落地迁移方案,确保数如迁移的准确性,尤其是在表结构,业务重构的情况下,如何进行数据迁移,确保安全准确。请结合银行关犍业务系统案例,介绍下数据迁移的方案.专媒建议:KW数据志自主可拄用户委员会委员.数据迁移的方案,从大的分类上有三种:1 .基于数据的逻辑迁移这种方式的适配范围更广,适配场景多,但迁移效率一般较差其对库表结构有要求.2 .基于H志的物理迁移这种方式的实时性较高,但需做更多的适配性工作,3 .基于应用的数据迁移这种方式属于定制方案,需要应用例解决数据迁移问题,效率中等,可加入定制策略,在保证数据安全方面,可通过数据校验完成.一般的迁移都支持窗线的校验,原理

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 办公文档 > 工作总结

copyright@ 2008-2023 yzwku网站版权所有

经营许可证编号:宁ICP备2022001189号-2

本站为文档C2C交易模式,即用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。装配图网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知装配图网,我们立即给予删除!