阿里云云栖号 潜水
  • 9发帖数
  • 9主题数
  • 0关注数
  • 0粉丝
开启左侧

云原生演进趋势下传统数据库升级实践

[复制链接]
阿里云云栖号 发表于 2021-8-16 10:17:09 | 显示全部楼层 |阅读模式 打印 上一主题 下一主题
一、概述云原生数据库

[size=0.882em](一)云计算是数字化的基础设施

                               
登录/注册后可看大图

[size=0.882em]众所周知,目前云计算已经成为数字化的基础设施,整个社会也在数字化。数字化渗透进我们的日常生存中,除了衣食住行,还包括教育、医疗、游戏等。
[size=0.882em]以医疗领域为例,早些年去医院,不管是验血还是拍胸片,一定是要去取纸质陈诉,然后打一张塑料的胸片图。但是最近一两年,除了三甲医院,其他医院也根本是通过网上向患者提供无论是陈诉还是胸片之类的质料,医疗领域数字化现象十分明显。
[size=0.882em]而这些数据全部都数字化以后,面临一个非常大的标题,它在哪些平台承载,怎么样承载?阿里云是此中非常重要的一个环节,数据库在数字化进程中承载了数据的生产、集成、实时处置惩罚和分析的整套流程。在整个数据库周边,大概还有硬件、安全、弹性计算等能力,这些大大小小的东西终极组成阿里云这个平台。
[size=0.882em](二)什么是云原生数据库技术
[size=0.882em]云计算在重塑数据库技术与商业。
[size=0.882em]在数字化背景下,我们有许多思索。
[size=0.882em]数据库跟从前那有什么不一样呢?什么是所谓的云原生数据库呢?作为使用数据库的开发者,对数据库的需求有什么变化?如今使用数据库我们一般会提什么样的诉求?
[size=0.882em]如今,上层的业务变化非常快,包括从前阿里巴巴淘宝内部实在也有同样的标题。业务的快速变化让开发者面临一个非常大的挑战,就是要非常快速地顺应变化。在云遍及之前,这个过程实在还是比力慢的,从构建服务器,然后网络打好,安装操作系统和数据库等,整个流程非常长。
[size=0.882em]对数据库的诉求,总结起来大概有以下几个。

                               
登录/注册后可看大图

[size=0.882em]第一个就是我们盼望更专注在业务开发上,不要把太多时间放在底层的硬件、软件、机房、网络等设施的配置上。
[size=0.882em]第二个是开箱即用的,我们盼望数据库创建好了可以直接使用,不需要再去做配置、优化等非常繁琐耗时且专业性强的事情。
[size=0.882em]第三个是安全可信,把数据放在第三方平台上,安全可信是一个非常根本的要求。
[size=0.882em]第四个是开放兼容,我们不盼望被哪个云厂商锁定,盼望能非常自由地迁移进来和迁移出去。
[size=0.882em]第五个是海量扩展,随着业务发作式的增长,系统压力很快就会变成原来的数倍甚至数十倍。在这种情况下,如果没有一个很好的横向、纵向扩展的数据库系统,那么很难支撑业务正常运行,处置惩罚起来就会非常棘手。
[size=0.882em]第六个是全球化。中国很多游戏厂商在海外的拓展和推广做得非常不错,尤其是在东南亚一带,另外也有一些游戏在欧美日本获得了非常大的成功,以是现在有些开发者也面临着全球化的诉求,作为数据库的基础设施,应该思索如何提供全球化的能力。
[size=0.882em]第七个是持续可用,我们原来自己做一套数据库系统,持续可用也是核心考虑之一。
[size=0.882em]除此之外还有可靠性,要求不能发生数据丢失。
[size=0.882em]末了是低成本,当业务发展到比力成熟的阶段,我们会关注低成本。
[size=0.882em]在这些客户诉求下,我们思索下一代数据库或者说新的数据库要具备哪些特性,也就是云原生数据库它所具备的产品能力,如下所示。

                               
登录/注册后可看大图

[size=0.882em]第一个是全面托管,用户不再需要去关注安装、备份、部署、监控、高可用等,可以一键创建实例,创建出来的实例具备以上东西。
[size=0.882em]第二个是按量付费,按量付费可以让业务起步的成本变得非常低,否则机房、硬件、网络等一整套设施配置下来,成本非常高昂。
[size=0.882em]第三个是按需弹性,它分为两个方面,一方面是要具备往上弹的能力,当业务在快速发展的过程中,数据库也要可以或许快速往上弹。另一方面是往下弹,当业务高峰已往了,需要很快地把资源使用量降下来,达到降低成本的目的。
[size=0.882em]第四个是生态兼容,无论用户目前使用的是MySQL,还是Oracle,或者是其他数据库,我们能迁移进来,也能迁移出去。
[size=0.882em]上方是我们认为云原生数据库它所具备的产品能力。
[size=0.882em]在这些产品能力底下,还是有很多的技术在支持。

                               
登录/注册后可看大图

[size=0.882em]六大核心技术分别是智能化、多模、软硬件一体化、安全可信、HTAP:大数据库数据库一体化、云原生+分布式。这六大核心技术支撑了上文的产品能力,办理开发者诉求。
[size=0.882em](三)云原生关系型数据库 PolarDB
[size=0.882em]PolarDB是阿里巴巴自研的新一代云原生数据库,在存储计算分离架构下,利用了软硬件结合的优势,为用户提供具备极致弹性、高性能、海量 存储、安全可靠的数据库服务。100%兼容MySQL 5.6/5.7/8.0,PostgreSQL 11,高度兼容Oracle。
[size=0.882em]PolarDB-X为PolarDB分布式版本,融合分布式SQL引擎与分布式自研存储X-DB,专注办理海量数据存储、超高并发吞吐、复杂计算与分析等标题。

                               
登录/注册后可看大图

[size=0.882em](四)云原生关系型数据库PolarDB产品架构

                               
登录/注册后可看大图
PolarDB产品架构图
[size=0.882em]PolarDB产品有以下特性:

  • [size=0.882em]存储计算分离
[size=0.882em]1)分钟级弹性升降级
[size=0.882em]2)分钟级新增/删除只读节点

  • [size=0.882em]智能代理转发
[size=0.882em]1)实现数据库透明扩容
[size=0.882em]2)多种一致性级别
[size=0.882em]3)自定义Endpoint

  • [size=0.882em]分布式存储
[size=0.882em]1)支持100TB
[size=0.882em]2)快速备份与恢复
[size=0.882em]3)更高单实例IO能力

  • [size=0.882em]libpfs+rdma+optane
[size=0.882em]1)高性能透明实现三副本 RPO=0
[size=0.882em]2)高性能写入:实现高并发的写入

  • [size=0.882em]基于redo复制
[size=0.882em]1)只读实例毫秒级延迟
[size=0.882em]2)办理binlog/redo双日志一致性与性能标题

  • [size=0.882em]并行执行
[size=0.882em]1)部门场景下的查询与分析
[size=0.882em]2)可以自由控制的并行度,保障性能与稳固性
[size=0.882em]这里主要讲一个和开发者使用过程中关系比力大的特性:智能代理转发。
[size=0.882em]在数据库中有一个非常难的点,它跟应用服务器不一样,当应用服务器系统压力特殊大的时候,还是比力容易做扩展的,可以加一组应用服务器,把干系的流量扩展到新的应用服务器上就可以了。
[size=0.882em]但数据库通常做不到,由于数据在查询和使用上都是相互关联的,数据不能简单地做拆分。PolarDB在上层有一个智能代理层叫Proxy,它为开发者办理了这个标题。当数据库系统压力特殊大的时候,通过智能代理可以主动把一些查询的Query分发到别的只读节点上。比如原来是一主一备,可以变成一主三备,就可以把流量主动分发到三个节点。
[size=0.882em]大家大概想,这个不就跟原来数据库加几个备库是一样的原理吗?
[size=0.882em]PolarDB通过智能代理办理了一个非常关键的标题,那就是加了这些只读节点以后,应用服务器上的连接配置是不需要做任何改动,可以随时加上去,智能代理收到Query以后会主动转发已往。
[size=0.882em]以现实业务场景举例,比如某天前端的业务系统告诉我们,明天早上10点要做一个促销运动,请做好数据库的扩容。
[size=0.882em]从前如果加了只读节点,大概碰到的标题是前端应用服务器根本就访问不到这个只读节点,或者可以访问到只读节点,但要对应用服务器的配置做一些改变,大概导致应用要把应用服务器重启。现在通过PolarDB的智能代理可以有效办理这个标题,方便快捷地做容量扩展。
二、传统关系型数据库向云原生环境迁移

[size=0.882em](一)传统商业数据库替换的挑战
[size=0.882em]如今,如果要从别的商业数据库迁移到 PolarDB上,比如从Oracle数据库,一般来说有几个比力大的挑战。

                               
登录/注册后可看大图

[size=0.882em]第一个挑战是应用耦合度高。通常情况下,数据库跟应用的耦合度非常高,如果要对数据库做一个动作的话,应用前端的应用要配合着一起做,大概会影响前端的可用性,由于通常情况下数据库底下承载的业务都是比力关键的,动数据库往往意味着动前端应用。
[size=0.882em]第二个挑战是稳固性要求高。数据库一出标题,前端的业务就会出标题,以是数据库的变更和动作常常会在晚上执行。
[size=0.882em]第三个挑战是数据量大。由于现在业务都比力大,因此核心数据库的数据量通常会比力大。
[size=0.882em]第四个挑战是语法兼容要求高。固然大家使用的都是 SQL,但是不同数据库的SQL还是不一样的。如果从Oracle数据库迁移到PolarDB,SQL要做太多的改造的话,就意味着前端业务系统的改造要非常大,情况也很复杂。
[size=0.882em](二)使用云原生数据库PolarDB替换传统商业数据库
[size=0.882em]是一个科学的尺度化、产品化的过程。

                               
登录/注册后可看大图
迁移流程图
[size=0.882em]在阿里云上,我们会提供一套尺度化流程和产品资助用户从原始数据库移到PolarDB数据库。
[size=0.882em]起首,我们会给用户一个工具或者脚本,到用户的系统内里运行一下,它可以采集到用户数据库的一些特性,这个特性包括有哪些 SQL、函数、存储过程跟目标数据库写法不匹配,原始的数据库的特点,比如它是一个系统压力特殊大的数据库,还是一个热门数据特殊明显的数据库。探测到这些点后,会告诉用户在后期的改造中要留意什么标题。

                               
登录/注册后可看大图

[size=0.882em]上方表格就是在实际的业务过程中通过脚本跑出来的。
[size=0.882em]通过这个表格,我们可以看到原始数据库如果要迁移到PolarDB的时候,它整体的兼容性还是比力高的。我们一共探测了6029个对象,这个对象大概包括存储过程、数据表、索引序列,还有一些同义词等干系的东西,此中不兼容的对象只有两个,实在是比力少的。报表里会指出具体是哪两个表,内里也有一些比力具体的修改建议,然后就可以迁移过来了。
[size=0.882em]下图是一个比力具体的过程,此处不详细睁开论述。

                               
登录/注册后可看大图

[size=0.882em]目前,阿里云已经把这一套尺度化、产品化的流程和中国信通院一起做成了数据库迁移的尺度指南,开发者可以到网上查阅,遵照指南做数据库迁移。
三、管理PolarDB O引擎(兼容Oracle语法)

[size=0.882em](一)PolarDB提供面向Oracle的全栈兼容性

                               
登录/注册后可看大图

[size=0.882em]PolarDB提供的Oracle兼容性是包括多个方面的,除了语法层的兼容,还有物理存储层、逻辑层和接口层。
[size=0.882em](二)管理PolarDB O引擎(兼容Oracle语法):常用工具
[size=0.882em]如果用户从Oracle迁移过来,在使用或者管理PolarDB的时候,和原来有哪些不一样?
[size=0.882em]在管理工具方面,用户可以使用阿里云云端的数据管理平台DMS,在控制台上找到叫登录数据库的入口,就可以登录到DMS上,如下所示。

                               
登录/注册后可看大图

[size=0.882em]第二个是用开源的数据管理平台叫pgAdmin,在这个平台上可以做根本的数据管理操作,包括基础信息的查看,数据查询,看一些执行操持、表、对象等,如下所示。

                               
登录/注册后可看大图



四、PolarDB O引擎(兼容Oracle语法)的开发实践:数据库根本规范

[size=0.882em]管理PolarDB O引擎(兼容Oracle语法):开发规范(1)
[size=0.882em]另外,阿里云有一些常用的开发规范,开发规范是阿里云内部探索出来的,也称为规约,在阿里巴巴内部是比力严格遵守执行的,将来会发布在开发者社区和阿里云的文档体系中。开发规范分成几个方面,有些地方和开发者在具体使用PolarDB的时候关系会比力大,下面简单论述一下。
[size=0.882em]规范中有一些是我们内部要求强制执行,有一些则是推荐执行,用户可以根据自己的实际情况进行取舍。

                               
登录/注册后可看大图

[size=0.882em]上方为建表规约。比如有一个对字段名的规范,要求必须要用小写字母和数字,不能用关键字,为什么会有这样的规范?由于字段名的修改是一个代价比力大的事情,通常不能“预发”。
[size=0.882em]我们发现,在实际的生产过程中改一个字段名是非常麻烦的。由于前面的业务已经在运行,如果改一个字段名,就意味着业务系统不能正常运行。以是从前大多数的做法就是加新的字段,因此我们对字段名提了一些规范,比如只能用小写字母,不能用关键字等。
[size=0.882em]第二个是表名和字段名,我们要求加create_time和 update_time。这会带来几个好处,第一个就是如果数据发生错误的时候,你可以很快知道字段的修改情况和时间。第二个是在上下游系统内里,如果要拉取一些变化数据的时候,它也可以非常快地找到哪些数据发生了变化,然后去做对应的处置惩罚。
[size=0.882em]另外,表必须有主键。这里有几个原因,第一个是查询性能会非常好,第二个是在下游的系统拉取一些变化的数据的时候,它通过主键可以比力快速地拿到。

                               
登录/注册后可看大图

[size=0.882em]此外还有一系列的索引规约,如上图所示。
[size=0.882em]规约中提到,索引的建立要有顺序,这个顺序的考虑大概会去关注where条件内里有哪些字段,要留意order by条件内里字段的顺序,这个顺序大概要影响索引建立的字段顺序,只有它们两个比力匹配的时候,整个的性能才会比力好。
[size=0.882em]另外,如果可以用覆盖索引查询的时候,尽量用覆盖查索引查询,会大大增加效率。
[size=0.882em]规约中还有一个推荐项:利用延迟关联或者子查询优化超多分页场景。这也是我们在数据库的索引优化内里的经验。当做分页查询的时候,比如说当你翻到了第1000页,或者是第500页这样靠后的页面时,这时候建议的做法是,比如说翻页要查出10页的内容,最好先把这10页内容的主键ID先查出来,查出来之后再回表一次,把所有的数据查出来,这是一个比力常见的推荐做法。
[size=0.882em]另外索引规约内里还提到一条,就是要留意不同字段范例,尽大概少或者不要发生隐式转换,由于隐式转换会导致整个索引失效。
[size=0.882em]管理PolarDB O引擎(兼容Oracle语法):开发规范(2)

                               
登录/注册后可看大图


                               
登录/注册后可看大图

[size=0.882em]SQL和运维也有许多规约,这里主要讲一下运维方面此中几个点。
[size=0.882em]起首是数据订正,开发者如果要去做一些修改数据的话,一定要先把这些数据查询出来,先看一遍再去做删除,要不然的话很容易出现误删除。
[size=0.882em]另外推荐使用数据管理产品DMS。如果在DMS上做数据订正的话,它有一个好处是可以勾选备份,当做数据订正的时候,它会主动把所有要订正的数据全部做一个备份。如果发现数据订正出了标题的时候,可以找到DMS主动备份下来的数据,重新再把这个数据恢复起来。
[size=0.882em]其他的这些这里不做过多论述,将来会发布在开发者社区和阿里云的文档体系中。
五、PolarDB O引擎(兼容Oracle语法)的开发实践:常见的SQL优化

[size=0.882em](一)管理 PolarDB O引擎(兼容Oracle语法):SQL优化案例一 并行查询
[size=0.882em]当查一些带复杂计算的Query,用并行查询可以大大加速查询效率。

                               
登录/注册后可看大图


                               
登录/注册后可看大图


                               
登录/注册后可看大图

[size=0.882em]上方是一个简单的例子,在GROUP BY的时候有一个非常简单的计算,当这个Query要扫描的数据非常多的时候,开一个并行查询可以让耗时从原来的100多秒到10秒时间,速率翻了10倍,这是用户在使用PolarDB的一个小本领。
[size=0.882em](二)管理PolarDB O引擎(兼容Oracle语法):SQL优化案例二 选择合适的JOIN方式

                               
登录/注册后可看大图

[size=0.882em]我们支持hash join,merge join和nest-loop join,用户可以根据不同的场景选择合适的Join方式。

                               
登录/注册后可看大图

[size=0.882em]可以看到,在上面这个案例中,选择nest-loop join是最快的。
六、案例与认可

[size=0.882em](一)完整的数据库生态

                               
登录/注册后可看大图

[size=0.882em]固然PolarDB是一个单独的产品,但是它有非常完善的产品生态,包括数据管理DMS,数据自治服务DAS,数据传输DTS,数据库备份DBS,数据与应用迁移ADAM等,可以满足用户各种场景,带来全方位的服务。
[size=0.882em](二)案例:PolarDB助力PrestoMall平滑从Oracle迁移上云

                               
登录/注册后可看大图

[size=0.882em]PrestoMall 是一家成立于2014年的东南亚电商企业,为了应对业务的快速增长,阿里云数据库PolarDB助力PrestoMall平滑从Oracle迁移上云。
[size=0.882em]迁移上云主要面临以下业务挑战:

  • [size=0.882em]业务快速发展,IT 费用也随之水涨船高,Oracle成本高昂;
  • [size=0.882em]业务的快速增长,应对双十一大促乏力,应用具备水平扩展的能力,但是数据库弹性不足;
  • [size=0.882em]去O复杂度太高,缺乏经验,盼望有专业评估引导;
  • [size=0.882em]最优迁移成本,控制风险成为难题。
[size=0.882em]根据客户业务需求,我们制定了迁移至PolarDB O(兼容Oracle语法)的方案,原因是:

  • [size=0.882em]PolarDB O引擎(兼容Oracle语法) 作为云数据库,没有昂贵的license费用;
  • [size=0.882em]PolarDB O引擎(兼容Oracle语法)云原生弹性,办理客户数据库弹性不足的标题;
  • [size=0.882em]ADAM为客户提供专业的数据库/应用兼容性评估陈诉,制定完善的迁移操持;结合PolarDB O引擎(兼容Oracle语法)对Oracle的高兼容性,大幅提升改造效率;
  • [size=0.882em]DTS实时迁移/回流的功能,配合专家服务,大幅缩短割接时间并降低风险。
[size=0.882em]迁移到PolarDB O引擎(兼容Oracle语法)后,通过终极实现了以下客户代价:

  • [size=0.882em]PolarDB O引擎(兼容Oracle语法)在成功支撑客户业务的同时,公司整体IT成本降低40%;
  • [size=0.882em]双十二大促PolarDB O引擎(兼容Oracle语法)弹性升级,应对自如;
  • [size=0.882em]ADAM + PolarDB O引擎(兼容Oracle语法)资助客户代码改造成本降低93%;
  • [size=0.882em]在操持内顺遂平稳完成割接,业务稳固运行。
[size=0.882em](三)被广泛认可的云原生关系型数据库PolarDB

                               
登录/注册后可看大图

[size=0.882em]目前,PolarDB在业界受到非常广泛的认可,顶级学会的论文已经超过了10篇了,获得了今年中国电子学会的科技进步一等奖,还有一些其他权威荣誉。
[size=0.882em]原文链接:http://click.aliyun.com/m/1000289488/
[size=0.882em]本文为阿里云原创内容,未经答应不得转载。

精彩评论1

周刚66577011 发表于 2021-8-18 12:23:48 | 显示全部楼层
转发了
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

猜你喜欢
在线客服邮箱
wxcy#wkgb.net

邮箱地址#换为@

Powered by 创意电子 ©2018-现在 专注资源实战分享源码下载站联盟商城