每日感悟

有些人说，活明白了就是在付出后，对于回报这件事不在执着，因果自有命运的抉择，从一开始认为都是真诚的，到后面认为都是假的，虚伪的，在到后面的，有真有假，到最后，真假无所谓。

2023-08-23号，我们邀请了阿里云PolarDB的基础架构负责人，陈宗志，陈老师做客直播间，回答了最近一段时间，大家总结的一些关于PolarDB的问题，这里进行了整理和总结。

另注意，基于个人的能力以及时间等因素，文字的转换过程比较辛苦，可能有遗漏或错误，望海涵，另以下文字，不代表任何商业性和商业责任，具体的产品已当时您访问的官方解释为准。

以下以实际直播时的人称来进行撰写，其中包括，陈宗志 陈老师， 胡老师，和我三个人，分别用  陈：胡：刘：来表示

————————————————————————————

胡：8点准时，欢迎大家来到由盘古云课堂和阿里云开源社区，以及PostgreSQL分会联合举办的公益直播课，基于上次分享中，关于PolarDB打败了谁，刘老师讲了什么？对PolarDB他不是一个数据库，他是一个方案，其中有一点是关键，他已经改变了MySQL开发者使用数据库的习惯，这里有些同学还有问题，我们也手机了一些问题和话题，本次邀请阿里云的PolarDB 基础架构负责人陈宗志，陈老师来给大家解答其中对于PolarDB的一些疑问，那麻烦刘老师介绍给大家介绍一下陈老师。

刘：今天咱们正式开始咱们Polardb第二季的活动，这个活动叫PolarDB有问必答，上次我仅仅是从使用的角度来讲解了PolarDB的一些使用中的特点，基于大家提出的问题都比较专业，所以本次请来PolarDB的基础架构的负责人陈老师，特别专业的问题就需要请特别专业的人来给大家解答。那么我们今天就要对这个火热的数据库产品，进行围追堵截和盘问，让大家了解为什么在国产数据库榜单，PolarDB可以排到比较靠前的排名的原因。

这里在数据库内核业界，陈老师是非常知名的开发专家，同时也主导过知名的数据库产品的PIKA，PIKA 为REDIS 的一个变化的版本，同时具有REDIS 不具有的一些功能，目前此项目还在蓬勃的发展。，今天我们就请来陈老师来讲讲PolarDB里面的一些详细的内容。同时陈老师，在MySQL 方面也是知名的“刺头”，给官方的MySQL经常提BUG，那么今天也让咱们得刺头，来讲讲PolarDB 是怎么一回事。

刘：咱们不来虚的，直接开始有问必答，来看第一个问题，在上次介绍中，就有同学提出，PolarDB的写入怎么就安全了，今天咱们让陈老师来讲讲，PolarDB 怎么就能安全的写入数据？

陈：大家好我叫陈宗志，花名暴跳，在PolarDB 5年多了，从PolarDB的项目从头内测到公测，到上线提供正式的产品，一直跟过来的，第一个问题PolarDB 是怎么通过PolarDB FS 来保证数据写入系统的安全性的问题，具体详细的内容是我们PolarDB 在2019年公开发布的，关于PolarDB FS 具体实现的文章，整个PolarDB 是跑在 Polar storage的系统，其中他的文件系统是Polar FS,你可以把他理解为阿里云上的盘古，提提供的文件系统接口的语义。

我们看一下图，这里图中体现的就是PolarDB的整体架构，这里的HOST我们可以理解为PolarDB的一个物理机。，可以部署多个PolarDB的节点，这里我们可以看到一个黑黑的部分，这个是PolarDB 的switch，PolarDB 通过chunk 连接到PolarSwitch,中间有一个 RDMA的网络连接到共享存储上，整个PolarDB 的高可用其实就是 Polar storage如何做的高可用，这里我们先讲一下PolarDB 存储的三个特点，请翻到下一页

这里我们的存储，包含三个部分，Bypass kernel ， ParalleRaft的协议，以及大量的新硬件。这里与高可用有关的事ParalleRaft 协议，但是我这里可以给大家讲一讲，存储系统整体是怎么形成的。

大家看下图，这里的新硬件这里包含了 Polar storage 和 盘古使用的存储，早在2017年，我们就已经大量的应用了我们NVME的SSD ，特能提供接近内存的访问性能，在稳态的情况下，他能达到 700MB/S，在非稳态他可以达到3GB/S，他的随机访问和顺序访问的差异不大。我们是国内大规模应用RDMA网络的，我们现在的数据从上层发到下层存储，通过RDMA网络现在差不多可以达到90微秒，线上再有数据较大压力的情况下是150微秒，在新硬件的加持下，相对以前提高了200微秒的速度。

在基于新硬件的使用给我们带来宏利后，我们也针对数据写入进行了优化，采用了bypass kernel的方式，这也是现在大部分高性能存储都在做的一个事情，在系统压力比较大的情况下，尤其是分布式系统如果你的线程数较多的情况下，用户态进入内核态，CPU时间片中线程切换到另一个线程，在有负载的情况下需要7微秒进行切换，那么本地盘以P4510一个IO的延迟在 30- 40微秒，我们认为7微秒的切换对性能的损耗较大，所以我们大量的系统都做了bypass kernel 的设计，

我们还看下面这张图，我来讲一下bypass kernel 的设计，这里无论是MySQL 还是 PostgreSQL,我们无论是一个read还是一个write调用会调用会调用GDBC里面响应的函数，函数包里面会切换触发系统调用，系统调用会切换到内核态，这里有有系统开销，在处理完后在切换到用户态，在系统的压力比较大的情况下有15us左右，在我们POLARDB里面很多都是bypass 设计，这里我们给大家看一下，我们的PolarDB libpfs 到用户层的一个包所以在libpfs这一层不会进入到GDBC，等于我们hock l了GDBC的接口，直接在libpfs这一层就进行系统调用，那么我们中间Polar的数据是通过中间的shared memory内存来进行交互的，这里我们有一个Polar模式的设计，这里我们写一个应用访问是通过多路复用，我们是需要等待网络的事件，IO的事件等等，有相应的事件我们从内涵态，切换到用户态，去处理这样一个相应的事件。那么这样的一个好处是我的CPU在没有任务到来的情况下，我们的任务状态是空闲的，这样的好处CPU你是独占的，但是在你有任务的情况下你是要切换到用户态的状态的，这里就有一个唤醒的过程，这就是我们刚才提到的7微妙左右。在纯Polar的模式中，我们也有一个任务队列，有任务我就做，但是最大的不同是，我没有任务我不进入内核态，我继续进行循环，不断的重试，所以在没有任何的任务的情况下，我的CPU 也不是待机的状态。这样的情况下我的CPU 就不存在上下文切换，把7微妙剩下了。那么从中间的数据到Polarstone低下，一个RDMA网络，这里也是一个纯Polar的一个设计在到低下的数据盘上我们采用的是并行Raft 的协议，我们到每个盘上是inter spk, 这里我们从山脉个的数据进入到处理，在到存储都没有内核态，都在用户态里面完成的。这里好处是极致的性能，不好的地方是我们为此设计了两个内核绑定，这两个核心是100的工作,同时基于我们采用inter spk，这里在进行一些操作系统认可的命令时是不可以的，我们单独需要开发对于一些文件操作的模块来进行对应的工作。大家可以看如果我们不这样设计，在很多地方都有相关的内核态和用户态的切换，等待等等。

关于PolarDB的高可用存储我们是通过，paralleraft 的协议，我们的底层数据层是有三副本，我在写入这些数据的时候是通过RAFT协议，早期测试时我们也发现问题，基于上图我们可以看基于RAFT 协议写日志我们是顺序性的，但是在我们写日志的时候，ABCDE ，如果我们写如 一部分日志，中间有一些还没有写如，后面有一些日志写入了，这里我们是无法进同步的，因为是要遵循append only的方式最大的问题是顺序性如果其中差一部分日志，后面的日志是无法进行同步的，这里我们进行了改进，我们的数据表是16kb,所以在写入数据的时候，我们带上我们前面或后面的数据包的一些内容，原来的方式是 A - B - C - D - E ，而现在的方式是 AB , ABC, BCD, CDE, DE 的方式，每个数据包都有相关的前后冗余的数据。通过这样的方式来保证在有网络抖动或者延迟的情况下，满足数据快速同步的需求，通过我们冗余数据发送的方式来解决问题。在Polardb 的上层还有一个standby的设置，除了底层写入的三个副本，我们还通过网络异步的将我的数据库的主节点，同步复制到standby节点，所以我们polardb是双副本。我们的主从节点的延迟在10毫秒以内。（在我们大量的使用中，基本认为是同步的）、

刘：好的谢谢陈老师，这边我们的群里有一些同学问第二个问题，PolarDB的设计是不是照抄AWS Aurora 的数据库设计 ？然后部分人认为我们就是抄，所以我这里想了解一下，到底我们是不是抄作业了？还有Aurora 和 Polardb 之间有没有关系 ？提出这样问题的原因也是由于AWS 的 Aurora 云原生数据库是早于我们的POLARDB 的，今天请陈老师给回答一下

陈：其实在回答这个问题之前，我想从另一个角度来说说，在我们现在市面上大量的国产数据库中，NEWSQL或者分布式数据库，我想从数据库选型的角度来说说这个事情，也帮助大家在未来的数据库选型中做一个借鉴。

实际上PolarDB 和我们市面的一些数据库都要受到单机容量限制，在大容量数据的情况下，都需要分片，这也是不同数据库解决方案中最大的不同，这里我把主流的解决方案分为三类，我将通过两个维度，兼容度和数据扩展两个维度，来对我们大部分的数据库的选型进行一个评估，以后大家在遇到真实的业务，可以来进行数据库选型的工作。

陈：上面我们可以看到是一个单机的MySQL,早期的分库分表我们的方案有MyCAT ,Atlas 分库分表的中间件，他的分库分表的方式是，下面该是一个MySQL 就是一个MySQL 该是一个PG 还是一个PG，上层是有一个中间件 proxy 层，还是一个JAVA包放到 libraray 里面等等，中间的这些proxy,或JAVA 包这层包含了分片信息，那么这里在分布式数据库出来之前的一个分库分表的方案。有点是扩展性特别好，包含淘宝的购物车在双11  也是提前给通过客户的ID 来做维度进行拆分到MySQL的实例里面。但这样做的问题是兼容性不好，在淘宝内部，我们要求这样的方案里面二级索引是不能多建的，还有你的查询是不能带上你的二级索引的，通过定义好的分库分表的方案来写你的SQL ，这里如果业务团队和你配合的特别好，你的扩展性就会做的非常好。反过来你的兼容性就较差，你的很多操作就的按照规范来写。

刘：陈老师我插一句，分库分表中间件的问题，还有一个事情比较烦人，就是两阶段提交的问题，甚至有三阶段提交，基于水桶的原理这里基于分库分表的设计的不同，一个低性能的节点将整体带慢，这也是我们不是太喜欢用中间件的一个原因。

陈：是的这里还有要求你的这样的方案中，你的一个事务里面的语句尽量要简单，要少。我们下面从两个维度来看一个是兼容，另一个是易扩展性上，来对这些数据库方案进行评估。通过实际的业务的情况来进行相应的数据库方案的选择，比如在单机MySQL 或 PolarDB for MySQL 性能不能满足应用的时候，如何对这些NewSQL 进行选型，我们看上面一页，其中最早google spanner中在 SERVER 层进行分片，我们熟悉的一些分布式数据库产品都在走这样的分片形成的方式。这类解决方案的典型形式为上面是一个Server 层，下面是一个事务的接口的形式，这类系统的有点事扩展性好，这类产品无论你在上层还是下层都可以做分片，好处是如果写压力在下面我对下层进行扩展，SQL 层有压力我可以扩展我的SQL层，但这样的产品在兼容性上，例如一些产品声称99%的兼容，但在使用中发现SQL语句的行为不一样，兼容性也分3个层面，1是语法的兼容性 2 事务的默认行为的兼容 3 生态环境的兼容， 这类产品仅仅是做到语法兼容的等级，我们管这类产品叫shard nothing 的产品。

这里我们回答第二个问题，PolarDB 和 Aurora 都可以成为shared storage的架构，但是我们和Aurora 是有根本性的不同的，Aurora是以page 接口来访问底层的page server,这点我们是不同的，但我们这类产品的在支持MySQL 方面的兼容性是100%的，并且底层的存储是可扩展的，支持一写多读的架构。（目前PolarDB 已经支持多节点写），在业务中尽显分库分表的主要原因 1 是存储超过了单盘承载力 2 一个节点无法满足数据的写入的压力 ，第一种业务可能随着订单的增长，历史数据的增长，需要进行分表操作 ，在云上我们看到的大多是第一种问题。目前云上接触到第二个问题的比较少，我们支持的写入量可以到达4GB/S，我们遇到的大部分问题都是第一个问题,PolarDB可以很好的解决这个问题，但实话实说，如果你的单节点写入量超过了单点可以承载的能力，那么传统的分库分表，或spanner的解决方案可能更好。我们与MySQL的差别很小，仅仅可能是一些周边工具使用的方式不同。

所以我们认为如spanner 的分布式方案中，是牺牲了兼容性获得更好的扩展性，而PolarDB 和 Aurora 是要保证100%的兼容性，这也是为客户迁移后，不需要做应用的改变考虑的。比如一些业务从MySQL 迁移到PolarDB 很多的这样的客户的应用程序原有的开发者已经不在继续为这个应用或单位工作了，或者根本不知道这个应用程序的维护厂商是谁？

这个时候你说我要改变这个应用程序的代码或SQL，或对这个任务进行兼容性的处理，基本上可能性很小，本着为客户服务，我们云厂商的兼容性是第一位的。

刘：是的我们在实际的场景下切换MySQL TO PolarDB,在一些项目中，如果你提出你需要修改一些代码，马上的反馈是，有没有其他的方案。在工作中，修改代码是困难的事情，尤其修改了一部分代码后，发现与其相关的一些代码由于这块代码的改变后，也需要修改，就变成大面积的修改代码的工作了。

陈：实际上我们可以通过我们的阿里的工具来跑相关的兼容性，但是实际当中很多客户还是不放心，关于比如错误处理的部分，以及事务在不同隔离级别中的处理问题的是否与之前的数据库产品有不同等等， 这里我继续回答 PolarDB与Aurora的区别，我们都是shared storage的解决方案，但细微的部分是有区别的，Aurora 是在2012年做的，2016年发表论文，Aurora截止目前还是走TCP/IP的网络，PolarDB是走RDMA网络，这里主从节点的数据传输就是瓶颈，所以Aurora为了避免数据写放大导致的数据传输在网络是瓶颈的导致的数据延迟的问题，提出只通过REDO进行数据传输，不需要发送具体数据页面的改动，所以AWS 称之为这样的方式是 LOG AS DATABASE，底下的服务称之为 page server,通过日志来产生新的页面，PolarDB 在进行研发的时候已经有了 RDMA，现在我们的总体的传输可以达到120GB/S，网络已经不是瓶颈，这里的瓶颈转换为机-存分离的架构导致的IO延迟的开销，所以我们努力的方向转换为bypass kernel，对于不同硬件之间的数据传输减少之间的延迟和开销，基于这个原因，我们的产品可以兼容更多的硬件产品。

刘：打断您一下，我是否可以认为PolarDB 享受了新硬件的宏利，我可以认为是硬件起到的决定的作用吗？

陈：云厂商是拥抱新硬件的，云厂商也是可以让这些新硬件大规模落地的最好的一个场景，以前硬件厂商的硬件需要多个小客户来进行消化，现在云厂商大面积的应用，积极的反馈产品的问题，让硬件厂商得到快速的发展。所以我们是基于新的硬件的基础上，我们的软件为大家提供服务。同时我们也是验证硬件厂商最新产品的能力的试金石。但是基于这些硬件都是基于我们bypass kernel的设计，才能发挥出他硬件的能力，这是基于我们目前的存算分离的硬件结构，我们写入数据要通过网络，我们的数据写要三副本，基于这些消耗，是需要进行优化设计的与相关的工作的，因为这里有大量的额外的操作，我们的性能接近本地盘的性能.

刘：这里我再次打断一下，提到本地盘，我们在云上使用云主机最不喜欢的是本地盘，本地盘的扩展是一个问题，我们在RDS 的一些本地盘的扩展上遇到过一些问题，可以说无法忍受。在扩展本地盘的情况下，可能会导致业务的中断，数据库节点的切换等等，我们这边目前使用PolarDB 的一个原因是，PolarDB 在磁盘的扩展上是透明的，磁盘的扩展我们是没有任何中断或业务的影响的，或者说不需要扩展的动作。

陈：但是实事求是的，本地盘的性能还是最好的，我们的磁盘系统和本地盘相比还是有延迟的，这是他的一个缺点，这是不可避免的我的给大家提示一下。

刘：第三个问题是线下PolarDB有没有线下的产品，上次我们在分享中我们PolarDB是有体系的，开源的产品我们可以找 德哥，他能给解决这个问题无论是shared storage 还是 shared nothing 他能给你解决方案，这里我想问的是，或者说曾经有人DISS PolarDB你上完云就下不来了，因为产品的易用性较高，但使用习惯了，线下没有可以在承接的产品，使用习惯了PolarDB ,MySQL 就感觉很难用了，然后下来这个应用程序就是死，我现在就是想问，商业版本的PolarDB 有没有可能下云 ？比如我们可以私有化部署，私有云这样的产品。

陈：大家了解MySQL 是GPL协议，这个协议要求线下的部署，需要将相关的改动进行开源，这就涉及我们是否将PolarDB for MySQL开源，目前我们在讨论当中。实际上大家都比较怕被厂商锁定，PolarDB在数据库兼容性上是没有问题的，怎么使用PolarDB ,就可以怎么使用MySQL,如果不使用PolarDB 可以在用回MySQL.

刘：第四个问题，在去年曾经和一个MySQL业界的大佬进行沟通，人家提出PolarDB 到底对于开源MySQL有什么贡献的问题，所以就引出了版本的问题，比如我在使用PolarDB的时候，我们想和MySQL的社区保持同步，我想使用MySQL 8.030的一些特性，那么分支合并的问题怎么办？

陈：对我先回答一下我们对MySQL社区的贡献，在2019年我是当时华人提交MySQL BUG 数的第一名，全球排名第四。在当时8.0 没有大规模的使用之前我们已经对8.0进行了研究和大规模的使用，并提交了大量的BUG。我们团队持续最近几年提交BUG，并对一些性能的问题进行代码的修改的提交，MySQL 官方rewrite后，在合并到MySQL源代码中，并且我们也有关于MySQL 的一些布道等活动，比如MySQL内核月报，包括一些MySQL的工具，innospace，可以支持8.0的数据页面错误，进行修改。PolarDB 实际上被设计成一个乐高架构，我们有一个MySQL 下有过来一个AP，或ES 之类的分析性的数据产品，我们希望是乐高的原因是，我们下面是分布式存储，有不同的节点做不同的事情，PolarDB 最早要解决的就是MySQL中的大表查询的问题，其他的解决方案中，那么你需要通过ETL 将数据进行迁移到数据处理产品上在进行数据分析的工作。这里PolarDB 有IMCI的节点可以直接对列式数据进行存储和处理，基于低下做一个列索引进行分析。后续我们也会推出一个类似ES的搜索的节点。我们的目的并不是要代替所有的数据库，我们的目的是在你的数据量不是超级大，同时你不想付出过高的成本，通过PolarDB 是否可以解决 TP AP 以及一些数据分析的工作。

刘：你这样干，你让你的同行怎么想你，太恨人了，太霸道了,你这样把所有的数据库类型都融合到PolarDB,你让别人怎么活。

陈：实际上数据库的易用性是非常重要的，我们很多产品在组件的时候需要非常多的数据链路，这里面的开销是非常大的，那么一个数据库如果将这些功能都集中在一起，那么易用性肯性是很高的。

刘：之前我们没有这样的需求，但最近我们的开发有一个新的需求，他在设计程序的时候，发现数据库访问的速度达不到要求，但是基于架构的复杂性和项目的大小，他不想付出REDIS的成本。他希望买一个PolarDB ，然后能实现 REDIS的功能，咱们这个在PolarDB上能实现吗？

陈：这个功能实际上不用等，我在做这方面的工作了，之前在PIKA的产品经验，现在很多大厂在微博等产品都在用PIKA，这里的解决方案是类似与PIKA，我们在上层封装REDIS 的接口，低下对接INNODB，通过 磁盘来换内存，以一个更节省成本的形式出现，这也是最终用户希望看到的。

刘：8.01 是对标咱们的8.013 8.02是对标咱们的8.018的MySQL，那我们会跟我们的MySQL一样，现在最新的MySQL已经到了 8.1了怎么会跟吗？

陈：暂时不会，因为官方提到过8.1是一个innovation的版本，他是一个不稳定的版本，各种新的东西会加入，官方稳定的版本要到8.2。我们并不是固定在8.013 或 8.018 我们会将官方的新的东西branch 到我们的版本上，持续更新。

刘：那我可以理解为我们虽然使用的是 8.01 PolarDB,但他上面有MySQL 8.025的一些新功能，对吗？

陈：对的，甚至我们会发现一些问题，我们先在我们的版本上把BUG改掉，MySQL官方在后面在修他们自己的MySQL.我们对于BUG 的FIX速度非常快，在发现BUG后 24小时就可以产生新的解决问题的版本，并推上线。我们希望我们和官方密切合作，我们希望官方来维护这些系统的BUG FIX。

刘：第五个问题刚才提过了，咱们就跳过，直接到第六个问题，咱们时间的问题，一会儿胡老师下班了。在并发中MySQL 在8.025 支持了并发，他已经支持了多CPU在单SQL并行计算的功能，在并发方面PG在开源里面早就支持了这个功能，那么我特别想知道咱们的PolarDB 的并发和 MySQL的并发之间的关系是什么？是咱们 PolarDB 抄人家MySQL的还是怎么样？

陈：事情是这样的，MySQL在做并行，我们PolarDB的并行实际上是在MySQL 之前，在数据的写入我们都是串行，但是在数据查询PolarDB做了并行，我来解释一下，熟悉MySQL源代码的都说MySQL的源代码有四座大山

1 Index lock 官方是标准的B+TREE， PG是BLINK TREE，每一个表中的每个索引在数据写入中都有锁，在大并发的写入中是有性能的问题，在MySQL 5.6是一把大index的X锁， 57 80 把这个锁改为SX锁，写入时可以读，但是在高并发的情况下还是有性能的抖动。在进行范围查询中加的是行锁，所有的锁都要加lock sys 这里是一个瓶颈，还有一个transation sys lock，我们去做mvcc ，活跃事务判断的情况下，我们做活跃事务拷贝的情况下 transaction sys是一把大锁，写入REDO LOG 这里也有一把大锁，8.0对于这块进行了无锁化设计。

这里我们讲一下我们怎么优化的INDEX LOCK，这里我们将B TREE 改为BLINK TREE，下图的上面是一个典型的BTREE的结构，下面是BLINK TREE的结构，Btree的分裂都是自上而下，从左往右的加锁，这样是没有冲突的，如果要在节点中插入新的节点，那么就需要先对下面的叶子节点进行加锁，在对上面的节点进行加锁在插入新的节点，但这里你不知道你是几层的，所以在上面的根节点加大锁，所有这样在页面分裂的时候是一个性能的问题。

所以我们采用了blink tree，在插入节点的时候，我在叶子节点中添加节点通过节点和节点之间的链接进行，在BTREE 这是非法的，但是在BLINK TREE 是合法的，如果我查一个PAGE 在左边的PAGE中没有我会往他右面的节点去找。这样就把一个大锁，拆分成小锁，进行两次的操作。

这是一篇2022年的论文，在PolarDB 和 MySQL我们有很大的不同是MySQL 是为本地盘设计的这一套引擎，PolarDB 是针对云盘设计的优化的一套存储引擎，在云盘上可以提供更好的带宽。这里我们一直努力将随机的IO转换成顺序的IO，尤其在LSM TREE 里合并，一般在传统磁盘上随机的IO可能在2-3MB/s 而顺序的速度在，顺序写入可以达到100-200MB/s,这里基本上大部分数据库都是基于wal ， write ahead log 的方式来进行日志写入，这样的设计对于本地盘是友好的，但是对于云盘并不是最好的，写入到云盘是需要进行切片的，你一个单线程往下下在同一个时刻，只能利用一个存储节点的IO能力，你不能把下面分布式存储的能力发挥出来提供一个更高的带宽，你的数据库用不上，他把自建的ECS的MySQL 跑到云盘上，给了更高的带宽，但是这些带宽是用不起来的。云盘希望的是你100个线程，写下面100个文件，而传统数据库是无法做到这样的模式，真实的场景是他要写REDO ，然后多个线程，往一个表里面写数据，也就是往同一个文件里面写。这也是为什么传统数据库在云厂商这边无法利用带宽的原因。

所以我们并不光把INSERT,UPDATE 的优化在Btree 里面做，也在append only 的底层来做, SSD 对于物理磁盘的变化，相对于云盘对于SSD的磁盘，云盘对于数据库变化要更大，把对数据库顺序的写入的优化方式又打破了,可以把云盘看成一个新的硬件。那么当WAL 是非顺序写的情况下，你的CRASH RECOVER 就的做一个大量的改变，我们所有的CRASH REOVER都是基于他是顺序的，相当于把数据库最基础的WAL都做了变化。

这也是我们一些客户把数据库放到云上，资源无法完全利用的问题一个原因。下图是我们具体的IO优化路径。我们可以看到在优化后的结果。

下面的图就是我们测试的结果，MySQL 安装在云盘上和单机相比，单机的性能是要优于在云盘上安装数据库的方式的，这也是我们的论文Cloud jump中指出如果对于传统数据库不进行优化，则在云上的性能是不如本地的方式的，在PolarDB 对这块优化后，我们可以看到在一些需要带宽的部分，我们可以跑的比本地的MySQL更好。

刘：这点还真是以前不了解，不知道。

陈：对，这不仅仅是针对MySQL ,对于其他的数据库PostgreSQL 也是一样的，但是对于其他的数据库优于时间的问题，我们没有进行测试如MongoDB , Clickhouse等，但在我们看来，传统的数据库产品wal的设计都违反了使用云存储的基本原理。

刘：好的明白了，我们还有最后一个问题，实际上这个问题非常重要，在我们使用传统的数据库中，我们的传统数据库在清理了数据后，是不会把表空间释放回给操作系统的，但在我们使用PolarDB的情况下发现他没有磁盘的概念，然后在删除数据后，费用就会降低，我知道这是因为计费的方式便于客户进行成本的节约，但他是怎么实现的？

陈：实际上在计费上，如果使用的是PolarDB for MySQL 我们会把undo log truncate 打开，在大量的UPDATE 操作后，我们后面会开启undo tuncate 在系统负载压力下降后，把这些表空间清理，使用新的表空间。另外如果你有100G的数据删除了90G ，就剩10G，后面你不进行数据的写入，这里也会有表空间的浪费。在之前MySQL删除大表下面删除大文件的时候会有抖动，因为这些都是数据块，在EXT4在早期3.X的情况下删除大文件还是会有抖动的，我们在我们的系统中做了一个lazy purage的文件删除后，我们是慢慢的释放尽可能来避免抖动。

刘：那这个Lazy purage 是在我的业务不繁忙的情况下去做吗？

陈：我们的lazy purage 不是在用户的层面，而是在底层，我们的底层不是分布式系统吗，在你删除后，我们会给poalrfs 发送一个任务，任务进入任务队列，后台删除，所以这里和你的业务系统繁忙程度没有关系，他和后台的文件系统的繁忙程度有关。

刘：好了今天讲了那么多，很多之前都不知道，这里我的消化消化，这里我们将之前的7个大家关心的问题都进行了解答，胡老师您看看有没有同学有新的问题。

胡：这里在我们刚开始进行问题回答的时候，有一个同学问，物理距离性能与TCP/IP是否有优势？

陈：对的RDMA网络的确和物理距离有关，相当于距离和光速之间的比，距离近比距离远有快100到200毫秒，比如从北京到郑州 ，和北京到洛杉矶是有差距的。但是我们的RDMA 是在内部，跨机房也无法实现RDMA，实际上RDMA是部署在同一个POD ，同一个机架。

胡：这里还有一个同学问，多节点写的功能在PolarDB中有吗？

陈：对我们正在推出

刘：我们对这个功能也在看，实际上我们在测试，这个功能如果推出那么你们就更该，遭恨了，把ORACLE 的活都抢了，开始多租户了。

——————————————————————————————

后面还有一些问题，关于硬件的，这里就不进行撰写了，可以去盘古云课堂，去看相关的视频,也再次感谢胡老师提供相关的资源。

这里在此抱歉，由于工作繁忙和最近比较懒，所以今天才把这些撰写成文字，也是我第一次写一篇文章 10000多字。