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

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
简介: 在数字化背景下,我们有许多思考。数据库跟以前那有什么不一样呢?什么是所谓的云原生数据库呢?作为使用数据库的开发者,对数据库的需求有什么变化?如今使用数据库我们一般会提什么样的诉求?本文将一一为大家解答。

一、概述云原生数据库


(一)云计算是数字化的基础设施


1.jpg


众所周知,目前云计算已经成为数字化的基础设施,整个社会也在数字化。数字化渗透进我们的日常生活中,除了衣食住行,还包括教育、医疗、游戏等。


以医疗领域为例,早些年去医院,不管是验血还是拍胸片,一定是要去取纸质报告,然后打一张塑料的胸片图。但是最近一两年,除了三甲医院,其他医院也基本是通过网上向患者提供无论是报告还是胸片之类的材料,医疗领域数字化现象十分明显。


而这些数据全部都数字化以后,面临一个非常大的问题,它在哪些平台承载,怎么样承载?阿里云是其中非常重要的一个环节,数据库在数字化进程中承载了数据的生产、集成、实时处理和分析的整套流程。在整个数据库周边,可能还有硬件、安全、弹性计算等能力,这些大大小小的东西最终组成阿里云这个平台。


(二)什么是云原生数据库技术


云计算在重塑数据库技术与商业。


在数字化背景下,我们有许多思考。


数据库跟以前那有什么不一样呢?什么是所谓的云原生数据库呢?作为使用数据库的开发者,对数据库的需求有什么变化?如今使用数据库我们一般会提什么样的诉求?


如今,上层的业务变化非常快,包括以前阿里巴巴淘宝内部其实也有同样的问题。业务的快速变化让开发者面临一个非常大的挑战,就是要非常快速地适应变化。在云普及之前,这个过程其实还是比较慢的,从构建服务器,然后网络打好,安装操作系统和数据库等,整个流程非常长。


对数据库的诉求,总结起来可能有以下几个。


2.jpg


第一个就是我们希望更专注在业务开发上,不要把太多时间放在底层的硬件、软件、机房、网络等设施的配置上。


第二个是开箱即用的,我们希望数据库创建好了可以直接使用,不需要再去做配置、优化等非常繁琐耗时且专业性强的事情。


第三个是安全可信,把数据放在第三方平台上,安全可信是一个非常基本的要求。


第四个是开放兼容,我们不希望被哪个云厂商锁定,希望能非常自由地迁移进来和迁移出去。


第五个是海量扩展,随着业务爆发式的增长,系统压力很快就会变成原来的数倍甚至数十倍。在这种情况下,如果没有一个很好的横向、纵向扩展的数据库系统,那么很难支撑业务正常运行,处理起来就会非常棘手。


第六个是全球化。中国很多游戏厂商在海外的拓展和推广做得非常不错,尤其是在东南亚一带,另外也有一些游戏在欧美日本获得了非常大的成功,所以现在有些开发者也面临着全球化的诉求,作为数据库的基础设施,应该思考如何提供全球化的能力。


第七个是持续可用,我们原来自己做一套数据库系统,持续可用也是核心考虑之一。


除此之外还有可靠性,要求不能发生数据丢失。


最后是低成本,当业务发展到比较成熟的阶段,我们会关注低成本。


在这些客户诉求下,我们思考下一代数据库或者说新的数据库要具备哪些特性,也就是云原生数据库它所具备的产品能力,如下所示。


3.jpg


第一个是全面托管,用户不再需要去关注安装、备份、部署、监控、高可用等,可以一键创建实例,创建出来的实例具备以上东西。


第二个是按量付费,按量付费可以让业务起步的成本变得非常低,否则机房、硬件、网络等一整套设施配置下来,成本非常高昂。


第三个是按需弹性,它分为两个方面,一方面是要具备往上弹的能力,当业务在快速发展的过程中,数据库也要能够快速往上弹。另一方面是往下弹,当业务高峰过去了,需要很快地把资源使用量降下来,达到降低成本的目的。


第四个是生态兼容,无论用户目前使用的是MySQL,还是Oracle,或者是其他数据库,我们能迁移进来,也能迁移出去。


上方是我们认为云原生数据库它所具备的产品能力。


在这些产品能力底下,还是有很多的技术在支持。


4.jpg


六大核心技术分别是智能化、多模、软硬件一体化、安全可信、HTAP:大数据库数据库一体化、云原生+分布式。这六大核心技术支撑了上文的产品能力,解决开发者诉求。


(三)云原生关系型数据库 PolarDB


PolarDB是阿里巴巴自研的新一代云原生数据库,在存储计算分离架构下,利用了软硬件结合的优势,为用户提供具备极致弹性、高性能、海量 存储、安全可靠的数据库服务。100%兼容MySQL 5.6/5.7/8.0,PostgreSQL 11,高度兼容Oracle。


PolarDB-X为PolarDB分布式版本,融合分布式SQL引擎与分布式自研存储X-DB,专注解决海量数据存储、超高并发吞吐、复杂计算与分析等问题。


5.jpg


(四)云原生关系型数据库PolarDB产品架构


6.jpgPolarDB产品架构图


PolarDB产品有以下特性:


  • 存储计算分离

1)分钟级弹性升降级

2)分钟级新增/删除只读节点


  • 智能代理转发

1)实现数据库透明扩容

2)多种一致性级别

3)自定义Endpoint


  • 分布式存储

1)支持100TB

2)快速备份与恢复

3)更高单实例IO能力


  • libpfs+rdma+optane

1)高性能透明实现三副本 RPO=0

2)高性能写入:实现高并发的写入


  • 基于redo复制

1)只读实例毫秒级延迟

2)解决binlog/redo双日志一致性与性能问题


  • 并行执行

1)部分场景下的查询与分析

2)可以自由控制的并行度,保障性能与稳定性


这里主要讲一个和开发者使用过程中关系比较大的特性:智能代理转发。


在数据库中有一个非常难的点,它跟应用服务器不一样,当应用服务器系统压力特别大的时候,还是比较容易做扩展的,可以加一组应用服务器,把相关的流量扩展到新的应用服务器上就可以了。


但数据库通常做不到,因为数据在查询和使用上都是相互关联的,数据不能简单地做拆分。PolarDB在上层有一个智能代理层叫Proxy,它为开发者解决了这个问题。当数据库系统压力特别大的时候,通过智能代理可以自动把一些查询的Query分发到别的只读节点上。比如原来是一主一备,可以变成一主三备,就可以把流量自动分发到三个节点。


大家可能想,这个不就跟原来数据库加几个备库是一样的道理吗?


PolarDB通过智能代理解决了一个非常关键的问题,那就是加了这些只读节点以后,应用服务器上的连接配置是不需要做任何改动,可以随时加上去,智能代理收到Query以后会自动转发过去。


以现实业务场景举例,比如某天前端的业务系统告诉我们,明天早上10点要做一个促销活动,请做好数据库的扩容。


以前如果加了只读节点,可能遇到的问题是前端应用服务器根本就访问不到这个只读节点,或者可以访问到只读节点,但要对应用服务器的配置做一些改变,可能导致应用要把应用服务器重启。现在通过PolarDB的智能代理可以有效解决这个问题,方便快捷地做容量扩展。



二、传统关系型数据库向云原生环境迁移


(一)传统商业数据库替换的挑战


如今,如果要从别的商业数据库迁移到 PolarDB上,比如从Oracle数据库,一般来说有几个比较大的挑战。


1.jpg


第一个挑战是应用耦合度高。通常情况下,数据库跟应用的耦合度非常高,如果要对数据库做一个动作的话,应用前端的应用要配合着一起做,可能会影响前端的可用性,因为通常情况下数据库底下承载的业务都是比较关键的,动数据库往往意味着动前端应用。


第二个挑战是稳定性要求高。数据库一出问题,前端的业务就会出问题,所以数据库的变更和动作经常会在晚上执行。


第三个挑战是数据量大。由于现在业务都比较大,因此核心数据库的数据量通常会比较大。


第四个挑战是语法兼容要求高。虽然大家使用的都是 SQL,但是不同数据库的SQL还是不一样的。如果从Oracle数据库迁移到PolarDB,SQL要做太多的改造的话,就意味着前端业务系统的改造要非常大,情况也很复杂。


(二)使用云原生数据库PolarDB替换传统商业数据库


是一个科学的标准化、产品化的过程。


2.jpg迁移流程图


在阿里云上,我们会提供一套标准化流程和产品帮助用户从原始数据库移到PolarDB数据库。


首先,我们会给用户一个工具或者脚本,到用户的系统里面运行一下,它可以采集到用户数据库的一些特征,这个特征包括有哪些 SQL、函数、存储过程跟目标数据库写法不匹配,原始的数据库的特点,比如它是一个系统压力特别大的数据库,还是一个热点数据特别明显的数据库。探测到这些点后,会告诉用户在后期的改造中要注意什么问题。


3.jpg


上方表格就是在实际的业务过程中通过脚本跑出来的。


通过这个表格,我们可以看到原始数据库如果要迁移到PolarDB的时候,它整体的兼容性还是比较高的。我们一共探测了6029个对象,这个对象可能包括存储过程、数据表、索引序列,还有一些同义词等相关的东西,其中不兼容的对象只有两个,其实是比较少的。报表里会指出具体是哪两个表,里面也有一些比较具体的修改建议,然后就可以迁移过来了。


下图是一个比较具体的过程,此处不详细展开阐述。


4.jpg


目前,阿里云已经把这一套标准化、产品化的流程和中国信通院一起做成了数据库迁移的标准指南,开发者可以到网上查阅,遵照指南做数据库迁移。



三、管理PolarDB O引擎(兼容Oracle语法)


(一)PolarDB提供面向Oracle的全栈兼容性


5.jpg


PolarDB提供的Oracle兼容性是包括多个方面的,除了语法层的兼容,还有物理存储层、逻辑层和接口层。


(二)管理PolarDB O引擎(兼容Oracle语法):常用工具


如果用户从Oracle迁移过来,在使用或者管理PolarDB的时候,和原来有哪些不一样?


在管理工具方面,用户可以使用阿里云云端的数据管理平台DMS,在控制台上找到叫登录数据库的入口,就可以登录到DMS上,如下所示。


6.jpg


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


1.jpg



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


管理PolarDB O引擎(兼容Oracle语法):开发规范(1)

另外,阿里云有一些常用的开发规范,开发规范是阿里云内部探索出来的,也称为规约,在阿里巴巴内部是比较严格遵守执行的,未来会发布在开发者社区和阿里云的文档体系中。开发规范分成几个方面,有些地方和开发者在具体使用PolarDB的时候关系会比较大,下面简单阐述一下。


规范中有一些是我们内部要求强制执行,有一些则是推荐执行,用户可以根据自己的实际情况进行取舍。


2.jpg


上方为建表规约。比如有一个对字段名的规范,要求必须要用小写字母和数字,不能用关键字,为什么会有这样的规范?因为字段名的修改是一个代价比较大的事情,通常不能“预发”。


我们发现,在实际的生产过程中改一个字段名是非常麻烦的。因为前面的业务已经在运行,如果改一个字段名,就意味着业务系统不能正常运行。所以以前大多数的做法就是加新的字段,因此我们对字段名提了一些规范,比如只能用小写字母,不能用关键字等。


第二个是表名和字段名,我们要求加create_time和 update_time。这会带来几个好处,第一个就是如果数据发生错误的时候,你可以很快知道字段的修改情况和时间。第二个是在上下游系统里面,如果要拉取一些变化数据的时候,它也可以非常快地找到哪些数据发生了变化,然后去做对应的处理。


另外,表必须有主键。这里有几个原因,第一个是查询性能会非常好,第二个是在下游的系统拉取一些变化的数据的时候,它通过主键可以比较快速地拿到。


3.jpg


此外还有一系列的索引规约,如上图所示。


规约中提到,索引的建立要有顺序,这个顺序的考虑可能会去关注where条件里面有哪些字段,要注意order by条件里面字段的顺序,这个顺序可能要影响索引建立的字段顺序,只有它们两个比较匹配的时候,整个的性能才会比较好。


另外,如果可以用覆盖索引查询的时候,尽量用覆盖查索引查询,会大大增加效率。


规约中还有一个推荐项:利用延迟关联或者子查询优化超多分页场景。这也是我们在数据库的索引优化里面的经验。当做分页查询的时候,比如说当你翻到了第1000页,或者是第500页这样靠后的页面时,这时候建议的做法是,比如说翻页要查出10页的内容,最好先把这10页内容的主键ID先查出来,查出来之后再回表一次,把所有的数据查出来,这是一个比较常见的推荐做法。


另外索引规约里面还提到一条,就是要注意不同字段类型,尽可能少或者不要发生隐式转换,因为隐式转换会导致整个索引失效。


管理PolarDB O引擎(兼容Oracle语法):开发规范(2)

4.jpg

5.jpg


SQL和运维也有许多规约,这里主要讲一下运维方面其中几个点。


首先是数据订正,开发者如果要去做一些修改数据的话,一定要先把这些数据查询出来,先看一遍再去做删除,要不然的话很容易出现误删除。


另外推荐使用数据管理产品DMS。如果在DMS上做数据订正的话,它有一个好处是可以勾选备份,当做数据订正的时候,它会自动把所有要订正的数据全部做一个备份。如果发现数据订正出了问题的时候,可以找到DMS自动备份下来的数据,重新再把这个数据恢复起来。


其他的这些这里不做过多阐述,未来会发布在开发者社区和阿里云的文档体系中。



五、PolarDB O引擎(兼容Oracle语法)的开发实践:常见的SQL优化


(一)管理 PolarDB O引擎(兼容Oracle语法):SQL优化案例一 并行查询


当查一些带复杂计算的Query,用并行查询可以大大加速查询效率。


6.jpg

7.jpg

8.jpg


上方是一个简单的例子,在GROUP BY的时候有一个非常简单的计算,当这个Query要扫描的数据非常多的时候,开一个并行查询可以让耗时从原来的100多秒到10秒时间,速度翻了10倍,这是用户在使用PolarDB的一个小技巧。


(二)管理PolarDB O引擎(兼容Oracle语法):SQL优化案例二 选择合适的JOIN方式


9.jpg


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


10.jpg


可以看到,在上面这个案例中,选择nest-loop join是最快的。



六、案例与认可


(一)完整的数据库生态


1.jpg


虽然PolarDB是一个单独的产品,但是它有非常完善的产品生态,包括数据管理DMS,数据自治服务DAS,数据传输DTS,数据库备份DBS,数据与应用迁移ADAM等,可以满足用户各种场景,带来全方位的服务。


(二)案例:PolarDB助力PrestoMall平滑从Oracle迁移上云


2.jpg


PrestoMall 是一家成立于2014年的东南亚电商企业,为了应对业务的快速增长,阿里云数据库PolarDB助力PrestoMall平滑从Oracle迁移上云。


迁移上云主要面临以下业务挑战:

  1. 业务快速发展,IT 费用也随之水涨船高,Oracle成本高昂;
  2. 业务的快速增长,应对双十一大促乏力,应用具备水平扩展的能力,但是数据库弹性不足;
  3. 去O复杂度太高,缺乏经验,希望有专业评估指导;
  4. 最优迁移成本,控制风险成为难题。


根据客户业务需求,我们制定了迁移至PolarDB O(兼容Oracle语法)的方案,原因是:

  1. PolarDB O引擎(兼容Oracle语法) 作为云数据库,没有昂贵的license费用;
  2. PolarDB O引擎(兼容Oracle语法)云原生弹性,解决客户数据库弹性不足的问题;
  3. ADAM为客户提供专业的数据库/应用兼容性评估报告,制定完善的迁移计划;结合PolarDB O引擎(兼容Oracle语法)对Oracle的高兼容性,大幅提升改造效率;
  4. DTS实时迁移/回流的功能,配合专家服务,大幅缩短割接时间并降低风险。


迁移到PolarDB O引擎(兼容Oracle语法)后,通过最终实现了以下客户价值:

  1. PolarDB O引擎(兼容Oracle语法)在成功支撑客户业务的同时,公司整体IT成本降低40%;
  2. 双十二大促PolarDB O引擎(兼容Oracle语法)弹性升级,应对自如;
  3. ADAM + PolarDB O引擎(兼容Oracle语法)帮助客户代码改造成本降低93%;
  4. 在计划内顺利平稳完成割接,业务稳定运行。


(三)被广泛认可的云原生关系型数据库PolarDB


3.jpg


目前,PolarDB在业界受到非常广泛的认可,顶级学会的论文已经超过了10篇了,获得了今年中国电子学会的科技进步一等奖,还有一些其他权威荣誉。



相关阅读:

删库跑路?别怕!PolarDB-X 轻松拯救误删数据的你

阿里13篇论文入选数据库顶会 PolarDB创新技术架构获认可

上海ACE同城会演讲实录|云原生分布式数据库PolarDB-X

PolarDB-X 是如何用15M内存跑1G的TPCH

顶会点赞!PolarDB Serverless实现了哪些突破?

云原生分布式数据库PolarDB技术深度解密

相关实践学习
MySQL基础-学生管理系统数据库设计
本场景介绍如何使用DMS工具连接RDS,并使用DMS图形化工具创建数据库表。
相关文章
|
24天前
|
Cloud Native 持续交付 开发者
云原生技术在现代企业中的应用与实践####
本文深入探讨了云原生技术的核心概念及其在现代企业IT架构转型中的关键作用,通过具体案例分析展示了云原生如何促进企业的敏捷开发、高效运维及成本优化。不同于传统摘要仅概述内容,本部分旨在激发读者对云原生领域的兴趣,强调其在加速数字化转型过程中的不可或缺性,为后续详细论述奠定基础。 ####
|
14天前
|
Cloud Native 安全 Java
铭师堂的云原生升级实践
铭师堂完整经历了云计算应用的四个关键阶段:从”启动上云”到”全量上云”,再到”全栈用云”,最终达到”精益用云”。通过 MSE 云原生网关的落地,为我们的组织带来了诸多收益,SLA 提升至100%,财务成本降低67%,算力成本降低75%,每次请求 RT 减少5ms。
铭师堂的云原生升级实践
|
27天前
|
弹性计算 安全 关系型数据库
活动实践 | 自建数据库迁移到云数据库
通过阿里云RDS,用户可获得稳定、安全的企业级数据库服务,无需担心数据库管理与维护。该方案使用RDS确保数据库的可靠性、可用性和安全性,结合ECS和DTS服务,实现自建数据库平滑迁移到云端,支持WordPress等应用的快速部署与运行。通过一键部署模板,用户能迅速搭建ECS和RDS实例,完成数据迁移及应用上线,显著提升业务灵活性和效率。
|
13天前
|
Cloud Native 安全 Java
杭州铭师堂的云原生升级实践
在短短 2-3 年间,杭州铭师堂完整经历了云计算应用的四个关键阶段:从“启动上云”到“全量上云”,再到“全栈用云”,最终达到“精益用云”。也从云计算的第一次浪潮,迈过了第二次浪潮,顺利的进入到了 第三次浪潮 AI + 云。
|
13天前
|
Cloud Native
邀您参加云原生高可用技术沙龙丨云上高可用体系构建:从理论到实践
云原生高可用技术专场,邀您从理论到实践一起交流,探索云上高可用体系构建!
|
24天前
|
Kubernetes Cloud Native API
云原生入门:从理论到实践的探索之旅
本文旨在为初学者提供一个关于云原生技术的全面介绍,包括其定义、核心原则、关键技术组件以及如何将这些概念应用于实际项目中。我们将通过一个简易的代码示例,展示如何在云原生环境下部署一个简单的应用,从而帮助读者更好地理解云原生技术的实践意义和应用价值。
|
26天前
|
运维 Cloud Native 开发者
云原生技术入门与实践
在云计算的浪潮中,云原生技术以其独特的优势和魅力吸引了越来越多的开发者和企业。本文将从云原生技术的基本概念、核心组件以及实际应用三个方面进行详细介绍,帮助读者更好地理解和掌握这一新兴技术。同时,文章还将分享一些实际案例和经验教训,让读者能够更深入地了解云原生技术的应用场景和发展趋势。
39 5
|
24天前
|
Cloud Native API 持续交付
云原生架构下的微服务治理策略与实践####
本文旨在探讨云原生环境下微服务架构的治理策略,通过分析当前面临的挑战,提出一系列实用的解决方案。我们将深入讨论如何利用容器化、服务网格(Service Mesh)等先进技术手段,提升微服务系统的可管理性、可扩展性和容错能力。此外,还将分享一些来自一线项目的经验教训,帮助读者更好地理解和应用这些理论到实际工作中去。 ####
37 0
|
1月前
|
Cloud Native 持续交付 云计算
云计算的转型之路:探索云原生架构的崛起与实践####
随着企业数字化转型加速,云原生架构以其高效性、灵活性和可扩展性成为现代IT基础设施的核心。本文深入探讨了云原生技术的关键要素,包括容器化、微服务、持续集成/持续部署(CI/CD)及无服务器架构等,并通过案例分析展示了这些技术如何助力企业实现敏捷开发、快速迭代和资源优化。通过剖析典型企业的转型经历,揭示云原生架构在应对市场变化、提升业务竞争力方面的巨大潜力。 ####
37 0
|
26天前
|
运维 Cloud Native 持续交付
深入理解云原生架构及其在现代企业中的应用
随着数字化转型的浪潮席卷全球,企业正面临着前所未有的挑战与机遇。云计算技术的迅猛发展,特别是云原生架构的兴起,正在重塑企业的IT基础设施和软件开发模式。本文将深入探讨云原生的核心概念、关键技术以及如何在企业中实施云原生策略,以实现更高效的资源利用和更快的市场响应速度。通过分析云原生架构的优势和面临的挑战,我们将揭示它如何助力企业在激烈的市场竞争中保持领先地位。