2021年12月18日，阿里云用户组（AUG）第四期活动在北京举行。现场，阿里云数据库PolarDB MySQL 内核研发负责人王晨向数十家北京企业分享了云原生数据库的技术架构，并对下一代云原生数据库进行了展望。王晨拥有十几年数据库内核研发经验，先后供职于IBM DB2 LUW(Linux/Unix/Windows) 数据库内核研发部门、电力行业分析型数据库内核研发部门、阿里云负责数据库内核研发团队。本文根据他的分享内容整理而成。
我也经常去拜访客户或参加一些客户大会，碰到有的客户会问什么是云原生，是不是你们又炒概念，或者说云原生数据库究竟是怎样的一个概念？我正好是从传统数据库厂商，又到了行业数据库，最后跑到云厂商去做云上数据库的内核研发，也值班处理RDS的问题，相当于说个人的职业经历就是按照数据库目前的发展轨迹去走的，所以我首先来回答“什么是云原生数据库”这个问题。
云原生数据库架构设计思路早期，从70年代到2000年的时候，也就是互联网没兴起之前，最常用的是传统厂商的数据库。用这样数据库的企业基本上都是大型企业，比如金融、政府或者说一些对数据库依赖比较重的一些企业。
到互联网时代，PC端互联网和手机端的互联网企业涌现，他们最大特点是业务有一个急速增长的过程。初期的话不可能说找一个特别完备的数据库就去购买。随着用户和业务的激增，整个数据量会非常大。以至于像Oracle、DB2这样的数据库，也不能够完全支持一个庞大的分布式这种形态的架构，或者说即便可以支持价格也非常昂贵。所以这时，正好LAMP这种便捷式的部署就出现了。很多人愿意去用开源的数据库，一是考虑到成本，这是最主要的；二是它简单易用，方便部署。大家更多得聚焦在业务上，而不是聚焦在如何使用数据库上。
当然，后面在发展的过程当中，大家会发现运维数据库，即使是运维这么简单的数据库其实也不是很容易。我们也要去考虑高可用来搭它的主备，也需要考虑它的负载，如果需要读写分离，还需要读节点来扩容，这些都是需要亲自去操刀的。这样的情况下，云上的数据库RDS就诞生了，它最重要的特点就是管控。有管控就能够帮企业自动化地去进行刚才我说的一些操作，包括备份，进行主备搭建，只读节点扩容和切换等等，这些都是由管控来做。
但是随着再往后发展，就会发现这些能力还是不够的。比如说可能发现单实例数据超过了2T，迁移各方面都是由这个单机去迁移，过程当中肯定是不容易的。另外比如说读节点的延迟，由于binlog逻辑复制是基于事务级别的，所以有大的DDL或者说有一些大事务的话，会导致复制延迟增加。
另外，以前RDS的部署，它其实是不能够很好地利用云上的弹性技术。而云上的弹性它是可以做到，比如存储的弹性，计算的弹性，以及网络的弹性等等。这些弹性其实在应用层都用得比较好，但是在软件层面、系统软件为什么用不了呢？因为它本质上是一个软件，不可分割。所以在这种基础上，所谓的云原生数据库就诞生了，就是云上产生的数据库。
那云原生数据库是怎么办的呢？第一点就是要把数据库进行拆分。比如说MySQL可以拆分成计算和存储模块部分，让存储的部分单独扩容，计算部分单独扩容，所以就出现了现在说的存计分离的架构。当然，我们后续还希望能够有在内存和CPU上也去解耦的这样一个弹性能力。思路就是将单一系统软件进行逐步拆分，然后形成这样每一层模块都能利用云上计算弹性的能力。
我再往下说一下云原生PolarDB数据库的一个架构。这块其实是PG，因为我主要是在MySQL，但是PostgreSQL的整个架构也是相同的，所以总架构一起介绍了，后面介绍的一些特性都是以MySQL为主。
最上层大家可以看到网络层，我们可以做到，用户自定义的这种访问方式。第二层代理层可以去进行一些读写的分离，还有那些流量的分离都可以做。第三层计算层我们可以进行计算能力的扩容。现在PolarDB的Share Storage架构适合一写多读的架构。我们可以达到分钟级的扩容，后面会讲一下弹性能力。最后还有存储层，因为它也是单独的存储集群，整个吞吐量是非常大，而且也可以按需去扩容。现在可以达到100T的规格，严格意义上，其实我们现在宣称是100T，实际上可以比这个更大。这样的话我们就比之前的像RDS这样的数据库，能够解决更多不同层级的扩容需求。
这里简单介绍一个主要技术，就是为了让只读节点能够复制延迟更低，我们采取了物理复制的模式，利用redo同步的机制来解决，这个就是一写多读降低延迟的技术。
PolarDB 云原生能力计算弹性 刚才我们说的分层弹性，这块儿正好列举了一下计算弹性。计算弹性是大家很关心的，随着用户现在需求越来越精细化，对我们的要求也非常高。所以我们从原来的Scale up，就是可以从一个节点比如8C32G往上弹，但是它是按规格来弹的。
除此之外，还可以不断增加RO或者缩减RO来进行Scale out和in的这样的一个能力。在这种基础上，要实现不同规格的RO这样的能力。还有正在内测的秒级弹性，就是对CPU的核数直接进行翻倍的弹性。这样的一些需求，包括我们未来最新的架构上，对内存和CPU分离的不同弹性，也都来自于我们客户的需求，我们也希望把它实现。
这是从弹性角度上说的，这个场景举个例子，比如说教育行业，它经常有这种峰值，所以我们就在这个基础上，做了适应他们应用场景的技术架构。
存储弹性 另外对于存储弹性的话，针对不同的存储类型，有不同的价格，对不同的业务场景。比如说电商这种高性能业务场景，历史账单实时推荐的在线分析报表业务，离线的分析业务，可以有不同的一种形式提供给大家，就是从存储的角度来也可以有不同的类型和使用量的弹性方式。
这一页是存储弹性应用的一个场景。现在也有客户因为PolarDB存储比较贵，希望有这种历史库，也希望有一些数据能导到OSS存储。其实我们也在做这些事情。历史库其实已经发布了商业化版本，它会针对一些数据进行压缩后去保存，那样节省了存储的成本。
备份与恢复 稍微介绍一下备份的方式，比如说场景有14天的快速恢复，有实例级别回收站方式，有这种恢复到任意时间点的方式，这个都是基于PolarDB本身redo的原生物理备份。同时也可以基于binlog去做备份，如可以利用DBS的一些能力来进行逻辑备份，就根据需求不同而做。当然我也听到很多其它需求，比如说我们有客户是希望秒级表级备份，我们提供了表级的备份，但是这个技术可能还需要去恢复实例后，才能把某个表恢复过来。我们还希望提供这个能力，比如通过闪回查询功能，可以基于行级的按时间点去恢复的能力等等。
我们希望能够根据云上客户需求多样化的特点，既能做到通用的基础性，也能做到多样化。所以这块也希望大家给我们一些时间，这些都在规划当中。
HTAP能力 刚才讲的云原生数据库，第一代我觉得是利用拆解数据库的不同模块，让它更能适配到云原生的云弹性和资源池化能力。下一代的云原生数据库，我觉得是企业级，也就是现在我们会接触越来越多的企业级用户。他希望能够有更多的能力，比如HTAP能力，HTAP跟AP是完全不一样的。HTAP是在TP的基础上，可以有一些只读节点进行SQL的分析，我们希望有实时业务报表的能力，这就是HTAP。但是AP一定是离线计算，更大量的数据进行扫描和计算等等。在最新的PolarDB MySQL 8.0里，我们其实已经有了HTAP的能力，包括一些在这个表上做列存索引及并行查询的能力。
全球数据库GDN解决方案 另外，我们有全球数据库的GDN，这种解决方案可以用于数据异地灾备，还有异地多活的场景。现在异地写还是有一定延迟，但是慢慢也在增强这样的能力。目前这样的场景主要是游戏客户在用，未来更多也希望用到金融行业里面。
多租户多写 这是最新提供公测的多租户多写能力。其实很多客户有这样的需求，因为一写多读还是不能够把写的资源隔离开，我们现在提供根据租户id和数据库schema、table进行绑定，可以在数据隔离的情况下，实现多写的一个场景，同时会提供一个全局一致性读节点的能力，方便把数据进行读取和聚合。
闪回特性 闪回特性其实刚才也说了，我们可以基于这个技术进行秒级恢复，它是基于undo去做的，所以他需要保存很多的回滚数据。场景基本上目前常见的就是游戏用户，比如做游戏回档对这个有强烈的需求，还有一些SaaS用户厂商，他们的数据可能会被误删，他们希望赶快就把某条记录给恢复，类似于这种场景。
分区表能力增强 最后介绍增强MySQL分区表的能力。分区表原来在MySQL里是非常弱的，客户其实对分区表的生命周期管理是非常关心的。所以我们做了大量的性能和功能上的一些改进，比如说去掉了表级锁，变成分区级锁。增删数据在某一个时间或者某一个按租户分的分区上，都可以直接去进行单独维护。后续会跟历史库和OSS这样的存储去结合，让整个数据的生命周期流转更平滑。
分层细化 最后一页再简单介绍，就是说我们觉得云原生数据库在未来肯定会更加细致。这个图画的比较复杂，实际上整体看来，其实我们更多的是进行更细化的分层，然后充分利用云技术，毕竟弹性和分布式是云原生数据库的核心。通过拆分得更细一点，在每一层做更好的弹性，有更好的Scale up和Scale out的扩展能力。
我今天分享的内容就是这些，谢谢大家。（正文完） 阿里云高级技术专家王晨：云原生数据库PolarDB技术解密
