本文为云原生应用创新实践联盟——数据库自主可控课题组线上交流活动总结,相关协作专家如下所示, 更多内容可点击此处进入云原生应用创新实践联盟 进行查看。
执笔专家:
卢丽欢, 数据库自主可控用户委员会委员
云原生应用创新实践联盟——数据库自主可控方向课题组专家。长期从事数据库尤其是分布式数据库应用实践工作,具备银行核心系统、互联网聚合支付系统、信贷系统、中间业务等银行关键业务系统采用国产分布式数据库落地实践经验。协作专家:
苑华伟 数据库自主可控用户委员会委员
云原生应用创新实践联盟——数据库自主可控方向课题组专家。计算机硕士学历,从事生产运维10余年,被国际灾备协会授予大师级业务连续性管理专家(MBCP)认证。先后从事IBM主机系统管理员、灾备管理员、ESB管理员、中间件管理员、数据库管理员等工作。擅长灾备建设与演练、MQ中间件运维管理、国产数据库运维管理工作。韩锋,数据库自主可控用户委员会委员
云原生应用创新实践联盟——数据库自主可控方向课题组专家。有着丰富的一线数据库架构、软件研发、产品设计、团队管理经验。曾担任多家公司首席DBA、数据库架构师等职。在云、电商、金融、互联网等行业均有涉猎,精通多种关系型数据库,对NoSQL及大数据相关技术也有涉足,实践经验丰富。曾著有数据库相关著作《SQL优化最佳实践》、《数据库高效优化》。李建明 数据库自主可控用户委员会委员
云原生应用创新实践联盟——数据库自主可控方向课题组专家。擅长基础架构规划和管理,尤其擅长全栈式性能优化,将基于云计算+微服务+OceanBase技术栈的新一代分布式架构核心系统性能优化到8000tps,在数据库方面有丰富的经验(熟悉informix、oracle、elasticsearch、oceanbase等数据库)夏茂宣 农商银行 资深DBA
摘要:
传统企业现在的系统绝大多数还是运行在Oracle,DB2等国外商业数据库上,随着近些年来数据库的变化,正有越来越多的企业面临将传统数据库迁移到开源或新型商业产品上才能实现自主可控的目标。然而不同数据库的特性有差别,SQL语法也有很多差异,因此在迁移数据库的过程中不仅涉及数据的迁移,还包括应用的适配改造。
首先,从传统集中式数据库迁移到国产分布式数据库,异构的两种数据库差别非常大,计算方式、数据存储、架构设计都区别较大,系统迁移时往往涉及大量的表结构设计调整、业务重构、应用改造,同时给数据迁移带来了一定困难;
其次,分布式数据库多节点设计给全局一致性的实现带来了一定的要求和难度,分布式数据库如果不实现全局一致,可能会带来跨节点任务的数据不一致性问题(当然,这个问题可以通过应用改造去规避,但是对业务的侵入性较大);
最后,应用适配分布式数据库,不仅仅是SQL语法语义层面的转换,还会涉及到业务的优化,应用架构优化等等方面。所以围绕“国产数据库数据分片和迁移难点实现”、“全局一致性难点实现”以及“应用改造难点实现”三个方面,本期论坛组织了此次“国产数据库应用实践难点线上核心探讨”活动,特邀请了金融企业有国产数据库实践经验的专家,针对以上三个方面进行了充分的讨论,现将交流内容和精彩回答整理如下,以供大家学习交流。
建表时需要考虑表的容量,该表常用SQL以及字段类型选择,请结合银行业务系统改造案例,介绍下如何进行表容量规划,该表常用SQL的提取分析,以及字段类型选择的注意点(主要是字段长度较长的情况)等。
专家建议
hanfeng_twt 数据库架构师 , SphereEx
1.表容量的规划
这一问题本质是数据对象的生命周期管理,针对数据对象在生命周期内的创建、增、删、改及归档销毁等做到前期规划。根据数据访问特征,对表内数据量的变化做到预测评估,尽量在早期阶段对表做好分片、分区、归档策略等规划。
2.常用SQL提取分析
对数据对象的访问,SQL是主要的方式。需要在定期分析SQL,提升访问效率。对表的访问玩玩是比较多元的,需要区分业务与非业务、常规与非常规、定期与随机、高频与低频等SQL访问特征。优先处理业务、常规、定期、高频的SQL。提取方法是有很多,很多平台也都提供了相应工具完成提取和分析的工作。
3.字段类型选择
关于字段类型的选择上,可本着如下原则:
分布式数据库里有广播表(每个数据节点都有全量)、分片表(每个数据节点存储部分数据)以及普通表(仅存在于某个数据节点),请结合银行关键业务系统案例,介绍该系统表类型如何设计,重点表分别选择了什么类型的表?
专家建议:
lulihuan1987 数据库管理员 , 张家港行
广播表(每个数据节点都有全量) :小表广播,数据量不大,经常关联但更新较少的场景,比如参数表,像机构表、利率表、产品表等;
分片表(每个数据节点存储部分数据) :除小表广播以外的其他业务相关的表,建议均采用分片表,以确保分布式数据库的性能和扩展性,例如账户信息表、客户信息表、交易信息表等等;
普通表(仅存在于某个数据节点) :不具备可扩展性,所以业务表不建议使用,除非是一些特点场景,比如一些临时表,数据量也不少特别大的可以使用。
分片字段选择是分布式数据库适配的关键,关系到数据的分布,查询的效率,以及扩展性,请结合银行关键业务系统案例,介绍下分片字段选择的原则,重点表如何选取分片字段。可以和“表类型选择”问题联合进行介绍。
专家建议:
hanfeng_twt 数据库架构师 , SphereEx
分片字段的选择,需涉及的因素很多,可大致分为以下几个方面:
1.数据结构
主键或唯一索引字段是否要包含如分片字段。很多数据库丛唯一性校验,是必须要求包含分片键在其中,否则无法完成校验工作。
索引字段对分片字段的选择上,没有直接影响。对于全局索引的,可考虑通过二级索引表的方式解决;对于普通索引,则可以在分片基础上做本地索引。
字段类型,选择适合分片的字段作为分片键。常见的分片类型包括有数字、日期、文本等。
2.数据特征
表规模,是是否使用分片的关键因素之一。表做了分片后,势必后造成一定的“功能退化”,如能采取其他方式缩小表的大小,尽量采用。可通过表的全生命周期规划,如常规的数据归档、压缩、转储、清理策略,减少数据量。此外,数据库内置的如表分区、垂直分表等策略也可以有效减小表的大小。
数据离散度,按某个字段或字段组合后,表的数据是否足够分散。数据分片的初衷就是减少表的规模,尽量做到数据打散是其根本原则之一。这里需要统计数据拆分后离散程度,尽量选择能充分打散的字段作为分片键。这里需注意,如果选择字段是带有业务特征,还要关注未来业务变化对它的影响。
3.访问特征
可变化性,选择相对固定、不再变化的字段作为分片键。虽然有些数据库也支持分片键的修改,但毕竟修改后会涉及数据移动,成本代价很高;还是优选不变的字段为好。
事务隔离,尽量选择按字段拆分后的数据,对数据的变化处理可集中在分片内解决。这样大量的业务变化是可以通过Local的事务完成,开销比全局的要小很多,效率也高。
关联字段,如后续此表与其他关联表经常联合使用,优先那些参与到关联操作的字段为佳。尽量是数据在关联后,能在本地完成Join的动作,减少数据 Shuffle或上移汇聚类的操作
4.其他因素
如涉及到多个字段作为分片键的话,还需考虑如字段顺序等问题。
国产分布式数据库如何解决计算下沉的问题,是否有一些通用的规则。
专家建议:
专家建议:
数据迁移难题:这里的重点不讨论迁移工具,讨论落地迁移方案,确保数据迁移的准确性,尤其是在表结构,业务重构的情况下,如何进行数据迁移,确保安全准确。请结合银行关键业务系统案例,介绍下数据迁移的方案。
专家建议:
hanfeng_twt 数据库架构师 , SphereEx
数据迁移的方案,从大的分类上有三种:
1.基于数据的逻辑迁移
这种方式的适配范围更广,适配场景多,但迁移效率一般较差其对库表结构有要求。
2.基于日志的物理迁移
这种方式的实时性较高,但需做更多的适配性工作。
3.基于应用的数据迁移
这种方式属于定制方案,需要应用侧解决数据迁移问题。效率中等,可加入定制策略。
在保证数据安全方面,可通过数据校验完成。一般的迁移都支持离线的校验,原理是通过某种算法对部分或全部字段实现校验;或者通过采样统计的方式完成。
提供全局强一致性校验的分布式数据库,能够达到集中式数据库那样的强一致性需求,但是相应也会带来性能的损失,而有的业务系统为了确保性能,通过业务改造和数据库设计,弱化强一致性要求,即使全局最终一致性也能满足业务需求。那么,坚持开启全局强一致,还是关闭全局强一致,通过改造规避影响?结合银行核心、信用卡、互联网金融系统等关键业务系统改造案例,介绍该方面的问题是如何考虑的?
专家建议
自动化运维:自动化运维的关注点有哪些?运维工具选择与行内现有平台的结合?分布式实例一致性备份恢复如何实现?低效率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。
目前的应用都是使用集中式的数据库,需要进行应用改造,但是目前面临一个问题就是:如何比较准确、客观的评估改用分布式数据库时,应用的改造量?
专家建议:
应用层面优化:分布式事务由应用实现还是数据库实现?微服务业务场景拆分时和分布式数据库适配的注意点?高速缓存集群的引入减少数据库压力,如何设计?SQL改造方面如何优化?
专家建议:
通过本次交流达成交流共识如下以供参考:
首先在应用分布式数据库时,数据库表在设计时需要考虑业务场景、表容量、常用查询SQL等因素,尽可能避免和减少跨节点流动的原则,选择合适的表类型和进行表分区;
其次,数据迁移方面,专家也给出了基于数据的逻辑迁移、基于日志的物理迁移以及基于应用的数据迁移三种方式供参考;
再次,分布式数据库全局一致性是必要的,性能的损失可以通过其他方式弥补;
最后专家对应用改造难点做了建议,从分布式事务、微服务拆分、缓存与数据库、单元化设计等方面给出了相关建议参考。
苑华伟 某省农信社 分布式数据库专家
计算机硕士学历,从事生产运维10余年,被国际灾备协会授予大师级业务连续性管理专家(MBCP)认证。先后从事IBM主机系统管理员、灾备管理员、ESB管理员、中间件管理员、数据库管理员等工作。擅长灾备建设与演练、MQ中间件运维管理、国产数据库运维管理工作。目前是twt社区数据库自主可控课题组成员之一。
卢丽欢 江苏张家港农商银行金融科技总部运维中心主任
长期从事数据库尤其是分布式数据库应用实践工作,具备银行核心系统、互联网聚合支付系统、信贷系统、中间业务等银行关键业务系统采用国产分布式数据库落地实践经验。
韩锋 数据库专家
有着丰富的一线数据库架构、软件研发、产品设计、团队管理经验。曾担任多家公司首席DBA、数据库架构师等职。在云、电商、金融、互联网等行业均有涉猎,精通多种关系型数据库,对NoSQL及大数据相关技术也有涉足,实践经验丰富。曾著有数据库相关著作《SQL优化最佳实践》、《数据库高效优化》。
李建明 云南红塔银行信息科技部运维中心经理
擅长基础架构规划和管理,尤其擅长全栈式性能优化,将基于云计算+微服务+OceanBase技术栈的新一代分布式架构核心系统性能优化到8000tps,在数据库方面有丰富的经验(熟悉informix、oracle、elasticsearch、oceanbase等数据库)
夏茂宣 农商银行 资深DBA
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞14
添加新评论2 条评论
2023-07-12 13:19
2023-04-29 20:54