简介： 在数字化背景下，我们有许多思考。数据库跟以前那有什么不一样呢？什么是所谓的云原生数据库呢？作为使用数据库的开发者，对数据库的需求有什么变化？如今使用数据库我们一般会提什么样的诉求？本文将一一为大家解答。

一、概述云原生数据库

（一）云计算是数字化的基础设施

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

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

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

（二）什么是云原生数据库技术

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（三）云原生关系型数据库 PolarDB

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

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

（四）云原生关系型数据库PolarDB产品架构

PolarDB产品架构图

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数据库，一般来说有几个比较大的挑战。

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

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

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

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

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

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

迁移流程图

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

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

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

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

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

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

三、管理PolarDB O引擎（兼容Oracle语法）

（一）PolarDB提供面向Oracle的全栈兼容性

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

（二）管理PolarDB O引擎（兼容Oracle语法）：常用工具

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

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

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

四、PolarDB O引擎（兼容Oracle语法）的开发实践：数据库基本规范

管理PolarDB O引擎（兼容Oracle语法）：开发规范（1）

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

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

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

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

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

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

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

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

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

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

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

管理PolarDB O引擎（兼容Oracle语法）：开发规范（2）

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

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

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

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

五、PolarDB O引擎（兼容Oracle语法）的开发实践：常见的SQL优化

（一）管理 PolarDB O引擎（兼容Oracle语法）：SQL优化案例一并行查询

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

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

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

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

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

六、案例与认可

（一）完整的数据库生态

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

（二）案例：PolarDB助力PrestoMall平滑从Oracle迁移上云

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

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

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

根据客户业务需求，我们制定了迁移至PolarDB O（兼容Oracle语法）的方案，原因是：

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

迁移到PolarDB O引擎（兼容Oracle语法）后，通过最终实现了以下客户价值：