开发者学习笔记【阿里云云数据库助理工程师（ACA）认证：云原生关系型数据库Polar DB MySQL版（二）】
课程地址：https://edu.aliyun.com/course/3112080/lesson/19082
云原生关系型数据库Polar DB MySQL版（二）
二、阿里云PolarDB MySQL 主要功能特性和技术原理
首先从架构方面展开，PolarDB架构切分成三个部分，第一是数据库的代理，是核心提供连接地址，SQL转发和事务一致性保障三个能力，连接地址是通过提供一个字符串，通过字符串的连接可以访问后端的不同的节点，不同的业务可以设置访问不同的地址，不同的业务之间通过地址的方式实现业务资源之间的隔离，比如核心业务需要访问主节点，既要读也要写，后台分析的业务需要访问只读节点，为了避免后台分析的业务影响核心业务，可能只需要额外地址访问到单独的只读节点实现业务资源的隔离。
SQL的转发核心基于两个问题，第一是读写的分离，读节点和写节点分开，可以把业务分负载进行一个分担。第二个是自动负载均衡，当某些只读节点的访问热点过高的时候，可以自动的把一些业务的负载均衡到不同节点上去。事物的一致性是当某一个写不下去后，确保在另外一个节点上读取的时候，它的数据本身是一致的，在数据库代理本身提供的一些能力。
第二个部分是数据库的DB节点，DP节点传统意义上是SQL的解析执行优化，库表的管理，事物一致性的保障，包括缓存加速的一些能力。这里面支持一个写节点和15个只读节点，而且所有的节点数据都是共享的，成本也达到一个比较优的状态，因为基于共享存储，所以它的物理复制延迟的效率延迟也是比较低的，是毫秒级的延迟，也提供一些并行查询的能力，充分利用多核的CPU的一些能力，具体DB的能力比较有效的一些优化，在后面的部分也会做一些介绍，共享存储是第三个部分，单可用区是三个副本，通常来讲提供的是双可用区的部署架构，一共有六个副本。
是通过ParallelRaft共识算法来实现不同副本之间的强一致，是通过25GB的I/O网络的方式来保障，简单来讲，PolarDB的架构是分成这三个部分。
1.PolarDB的连接访问和一致性保障
简单拆开来讲一下访问这个访问proxy这一部分。独创集权地址，是多个地址可以提供给不同的业务。这里面有一个主地址的概念，主地址是永远连接在主节点，同时支持读和写，当主节点出现故障的时候，它是可以切换到其他的节点，在这种情况下，是可以去把核心业务，后台分析业务，非核心业务去做业务隔离，相互之间不受影响，这是集群地址的一个概念
第二是访问数据的一致性级别的概念，里面有三种类型，一种是最终一致性，第二个是会话一致性，三是全局一致性。最终一致性的意思是并不实时保证读到的是最新的数据，它有一定的延迟，但最终保证它的一致性，会话一致性是在会话内部。会话内部一定能够查询到最新的数据。全局一致性是在有些应用场景下，不同的会话之间，所有的应用当写入完成以后，希望所有的连接、所有的业务能获取到最新的数据。这是三种一致性的级别，这里面最终一致性，因为它并不需要实时保证这个数据的一致性，所以它的性能是最好的，从一次性保证的级别来讲，全局性是最高的，这里面的技术原理
简单画图做一个说明，每一次写入都会记录一个LSN的号码，当去查询的时候，一定会访问种SLN的号码大于35，转换过来是已经完成数据同步和复制的节点，读写这个数据。它就可以保证最终的读写结果的一致。
2. PolarDB 主从节点毫秒级低延迟复制(共享存储+物理日志)
数据文件和物理日志均实时写入共享存储
添加只读节点，无需拷贝数据，5分钟快速提供服务
主备故障切换( Failover )，只读节点均可以从存储中获取最新的物理日志，确保RPO=0
传统的共享存储的DB架构主备库之间的不同的存储设备，当主库的数据负责备库，要做完整的逻辑日志的同步，时间会非常高，日志取决于网络是时延，PolarDB的共享存储，数据文件和物理日志首先是存储在共享存储的，写下之后，其他的只读节点可以直接访问数据文件。
通过物理日志获取最新数据，有两个好处：
一是不需要考虑数据，新的只读实例，五分钟可以快速提供服务，拉起新的节点的只读效率高。
二是出现故障需要做切换的时候，新的节点从存储中获取最新的数据，时间效率高，通过共享存储物理日志的方式，可以实现只读节点延迟是毫秒级别。
3. PolarDB FAST DDL介绍
Fast DDL
传统单线程DDL:大表上的DDL操作往往需要数小时甚至数天的时间，严重堵塞其它相关操作
Fast DDL:利用并行Scan/build lndex，和高度优化的并行merge sort,可以将DDL延迟降低到原来的1/13
在DB层面做了优化，在发送DDL很多大表的操作上，操作会非常退时，有些是小时，甚至是天数，有几天是可能有，在DDL操作时会被堵塞，在扫描、排序、构建各个层面都做了并行处理的能力
上图是做的实测，2G、20G以及180G的表格，表的容量越大，性能提升的倍数越好，实测的情况下最好DDL延迟可以降低到原来的1/13，这是效果的一个情况。
4.PolarDB MySQL 8.0并行查询
PolarDB并行查询:
当查询数据量较大时，会自动启动并行查询框架;
并行查询会充分利用多核CPU的并行处理能力，在存储层将数据分片到不同线程，多线程并行计算;
并行查询可有效提升大表查询、多表连接查询等复杂查询的效率;
在TPC-H测试模型下，开启32并发线程执行，平均性能提升10倍以上;
建议不同的业务使用不同的连接地址，使用不同的数据库节点，避免互相影响，如右图，非核心业务并行查询不影响核心在线业务。
二是DB的8.0提供了并行查询，MySQL官方版本SQL的执行与核是绑定的，PolarDB的优化查询，数据量非常大的情况下，会自动启动后台的并行查询的框架，可以充分利用多核的并行处理能力，在存储层面将数据进行分片，分到不同线程，多线程并行提供计算，在大表查询或者多表连接等复杂查询的效率结果会非常好。
也做了一些实测，在TPC-H测试模型下，开启32并发线程执行，平均性能提升10倍以上，在具体的业务部署情况下，希望不同的连接地址，把核心业务核后台的请求的地址隔离开，避免互相影响。
5.PolarDB Hash Join优化
Hash join优化
1.用直方图更精确地估算Join Cardinality ,优化器生成更优的Join Order。从算法层面显著提升Hash join性能（ MySQL社区案例提升137倍, bug#99244)。
2.支持基于共享hash表的Hash Join并行执行，利用多核计算能力加速。和JoinOrder 优化叠加，实现多达千倍的性能提升。
3.实现基于行存的batch 化执行框架。支持Hashjoin 执行流程batch处理，通过优化单核指令效率提升性能。
Hash join在三个维度做了优化，一是在算法层面，生成了更优的Join Cardinality。相对MySQL社区也做了一些实际的测试，结果表现非常好，第二个是基于共享hash表的Hash Join并行执行，相当于充分的多核的并行计算的能力调动起来，实现了整体的加速，效果也非常好，第三个实现基于行存的批处理的批量执行框架。里面具体实现的一些细节不具体的展开，简单来说是这三个方面的一些优化，确实从实际的这个测量效果来讲是非常的好。
6. PolarDB 独立缓冲池
（1）计算节点和Buffer Pool (BP)分离
Buffer Pool的逻辑比计算节点更简单更可靠，通过单独的进程维护Buffer Pool，使得其中的数据不受计算节点的影响，提升了数据库整体的可靠性，减少了RTO
（2）极速的实例重启/崩溃恢复速度
在计算节点升级时，可以保留数据库的主要运行数据和状态,将实例重启/崩溃恢复的速度提升4倍，同时保证重启/崩溃后的性能无衰减
（3）动态实时的warm buffer pool
Buffer Pool可以进行跨物理机复制，提供动态实时的warm buffer pool功能，明显降低实例升降级时对用户的影响
DB把DB的计算和Buffer放在一起共同部署，形成了管理和维护，PolarDB做了一个分离，计算DB的节点和buffer pool的节点进行了分离，用不同的进程管理和维护，当数据库的处理逻辑比较复杂，当DB层出现重启或崩溃时，buffer pool不受到任何影响，出现重启或崩溃时效率会非常高，恢复的速度提升了四倍，当恢复后，不会有buffer pool预热的过程，性能可以马上恢复。
7. PolarDB FAST Query Cache 介绍
MySQL原生Query Cache存在的问题:
并发处理较差，在多核情况下，可能并发越高性能降低越严重。
内存管理较差，内存利用率低且回收不及时，造成内存浪费。
当缓存命中率较低时，性能无提升甚至严重降低。
PolarDB对Query Cache的优化∶
优化并发控制︰取消全局锁同步机制，采用无锁机制，重新设计并发场景下的同步问题，能够充分利用多核的处理能力，保证高并发场景下的性能。
优化内存管理︰取消内存预分配机制，采用更加灵活的动态内存分配机制，及时回收无效的内存，保证内存的真实利用率。
优化缓存机制︰动态检测缓存利用率，实时调整缓存策略，解决命中率偏低或读写混合等场景下的性能降低问题。
FAST Query Cache ，原生版的MySQL，具体的实现存在不少的问题，比如并发处理能力比较弱，没有多核的处理能力，管理相对比较落后预分配的机制，内存效率不高，缓存命中率较低时，性能无提升甚至严重降低。
PolarDB对Query Cache产品做优化，一是并发控制能力，取消全局锁同步机制，采用无锁机制，可以充分利用多核的处理能力，提供高并发场景下的性能。
二是采用更加灵活的动态内存分配机制，对于无效的内存，及时回收内存，保证内存的真实利用率。
三是优化缓存机制，适时调整缓存的策略，包括各种预取，根据当前业务类型智能化的调节，Query Cache在实际应用场景下，发挥的效率效果比较好。
8. PolarDB 部署架构
支持多可用区部署:
可抵御机房级故障
默认双可用区部署
主可用区故障时，备可用区可自动快速完成切换
也可手工进行主备可用区切换
数据6副本
每个可用区3副本，两个可用区共6副本
部署架构相对比较简单，目前支持多可用区部署，默认是多可用区部署，可抵御机房级故障，当一个机房出现故障，另外一个机房业务可以快速拉起，快速完成切换，默认双可用区部署，故障切换支持被动，当某个主可用区故障时，可自动快速完成切换，也支持手工主备之间的切换，可包括因为引用的场景，也包括因为业务本身的原因做一些主备切换的原因，都是支持的
从数据的角度讲，支持每个可用区三个副本，两个可用区共6副本
9. PolarDB 备份与恢复体系
备份与恢复体系，PolarDB提供原生备份的能力，里面分成两类，一级备份和二级备份，一级备份在DB的本地集群通过快照的方式快速实现本地备份，快照数量也可以很多，通过快照，结合Redo日志，被分到OSS上，可以恢复到任何一个时间节点，一级备份快照方式支持7-14天，第二种是二级备份，二级备份需要把数据转储到OSS存储中，OSS对象存储的价格回更低廉，在备份归档更适用，二级备份每天一次备份，数据至少可以恢复到每一天，期望数据恢复到一个时刻，也可以结合加上Redo日志，选择把Redo日志一起备份，可以恢复到任何一个时间节点。同时结合DBS逻辑备份的能力，把数据保存到云下的本地存储和本地数据库也是可以的。
10.PolarDB一级备份(秒级备份/快照Snapshot)
采用Redirect-on-Write机制，每次创建快照并没有真正Copy数据，只有建立快照索引，当数据块后期有修改(Write )时才把历史版本保留给Snapshot，然后生成新的数据块，被原数据引用( Redirect ) 。
一级备份的备份和恢复速度快，但使用PolarDB分布式共享存储，保存成本较高。(二级备份和日志备份存储在OSS上，成本较低)为确保数据安全，一级备份默认开启，最短保留时间为7天，最长保留时间为14天。
PolarDB一级备份从计算来讲，是秒级备份，是Redirect-on-Write机制，要备份的对象，现在是一个集群，集群原本有一个索引，所有的数据块对应一个索引，建立秒级备份时，会新生成一个索引，指向所有的数据块，当数据发生改变时，数据块会重新复制到新的地方，新的数据块把原来的对象的数据的所有做一个修改，这就是Redirect-on-Write机制的索引，是非常快的，只需要建立一个索引，一个秒级备份的速度是不超过30秒，与容量大小没有关系，只跟建立索引的时间效率有关系，这是秒级备份的原理，秒级备份存在本地，本地存储成本相对更高，通常结合二次备份，二级备份和日志备份存储在OSS上，降低成本，数据恢复与容量有关，把数据复制到新的集群，把集群拉起来，这个效率受容量大小影响，速度是40分钟/TB。
10. PolarDB 历史库
历史归档数据的挑战:
历史数据和最新数据存储在同一数据库系统中，导致磁盘空间不足。
大量数据共享数据库系统的内存、缓存空间、磁盘IOPS等，导致性能
问题。
数据量太大导致数据备份时间过长甚至备份失败;同时如何存放备份
数据也是一个问题。
传统解决方案∶对历史数据做存储归档，将长期不使用的数据迁移至以文件形式存储的廉价存储设备
传统方案存在的问题:
在实际业务中，历史数据并不完全是静态的，针对几个月甚至几年前的历史数据，依旧可能存在实时地、低频地查询甚至更新需求。例如，在阿里巴巴内部，对淘宝或天猫历史订单的查询、对企业级办公软件钉钉历史聊天记录的查询或对菜鸟海量历史物流订单的查询等。
历史库是历史的很多的信息和数据,是需要转储到另外空间重新去做工程管理的，在本地可能空间是不够的，也有可能会影响到当前的在线业务。所以传统的解决方案是通过存储归档的方式来实现的，把数据转储到更低成本的其他的充值设备上去，当这个方式带来的问题是很多的实际应用场景下，它并不是对故障数据完全是一个冷数据，它是一个低频访问数据。
比如淘宝天猫的历史订单，比如钉钉的历史聊天记录，它是一个冷数据，但是它会有低频访问的需求，但是以存储归档的方式备份到其他地方，访问效率会非常的低下。所以在这个背景下，提出PolarDB的历史库的这样一个能力，它是一个归档的数据库，在归档库同样可以访问。只是访问的效率会相对低一点。为了解决这个成本的问题，历史库同时还提供压缩算法，把数据进行压缩，最多可以节省70%的存储空间，这是历史库一个功能特性
12.PolarDB 全球数据库（Global Database）
（1）全球部署Global Deployment
数据跨地域同步，提供全球跨地域的容灾能力。
RPO=0SLA为99.99%
（2）就近读加速
Accelerate by Reading the Nearest Node
读操作就近读取数据，适合不同地域读多写少的场景
（3）多通道物理复制
Multi-Channel Physical Replication
提供数据跨地域的高速同步，大压力场景下全球同步延迟确保在2秒以内
（4）多点跨地域写
Write to Multi Zones and Regions
提供多点跨地域写功能，提供业务的多地部署能力
全球数据库对于很多全球化的企业，都是有全球部署数据库的诉求，所以也提供了全球数据库部署的能力，简单介绍几点，首先第一个从任何一个地域都是可以就近去访问。
比如在张北、美国硅谷和香港部署了全球数据库，在香港这个地方，读取就是就近访问香港本地的节点，所以读取的效率是非常高的。在不同节点之间，张北、美西和香港之间的，数据的复制是基于阿里云的全球高速网络实现的，可以保障不同地区之间数据复制的延迟在2秒钟以内，也是基于高速网络实现的。多点的跨地域写任何一个地域都是可以去写的，会转发到主节点完成，会有2秒钟以内的时延，各个地区可以去操作
13. PolarDB全球数据库解决方案
两地三中心架构:
北京的双可用区集群，覆盖AZ1和AZ2。
上海的单可用区集群
应用在北京，对AZ1的数据库进行本地读写。
当北京AZ1故障时，优先切换到北京Az2。
当北京AZ1和AZ2均故障时，切换到上海AZ3。
有两种典型的应用场景，一是异地灾备，以上图为例，北京有两个AZ，AZ1和AZ2，上海有灾备地域AZ3，当AZ1故障的时候，AZ2就可以接管业务，AZ1和AZ2都故障的时候，AZ3就可以接管业务，是一个典型的两地三中心架构
每个PolarDB都可读可写;
不用一步到位，可以从单Region单集群架构，平滑升级为全球部署架构︰应用程序只需配置一个连接串地址，无需修改代码;
上海、新加坡的规格配置无需与北京保持一致,可以灵活选择;
还有全球部署的架构，比如在北京、上海和新加坡三地部署。同样可以实现相互之间的容灾联动，每个PolarDB都是可读可写的，而且整个部署也并不需要一步到位。
原来只在北京有业务，就在北京部署一个站点提供数据库服务就好，在上海提供业务，在上海再扩一个业务，在新加坡再提供一个业务，再去支持全球数据库，这是可以平滑的升级部署。而且整个应用程序，它的整个配置也是比较简单，它只要填一个数据库的代码并不需要做任何修改。而且不同地域之间，规格是可以不一样的，所以规格的配置也相对比较灵活。
14. PolarDB 拥有丰富且免费的性能诊断套件（DAS）
从后台的运维管理这角度来讲，PolarDB也是提供了非常丰富的管理套件，简单罗列了12个管理套件，包括一键诊断、自治中心、锁分析和慢SQL分析等等很多，无法一一做介绍，可以登录到PolarDB的控制台，自己去实际操作。
这里面只是简单举几个例子，比如会话管理，可以去看这个当前一共有多少会话，有多少个活跃会话，每个会话的实际的时延情况等等可以去做分析，实时性能是每个会话或者每个连接当前的时延灯的实际情况，针对一些实时的问题可以快速去诊断，新的洞察可以看一下整个系统的整体的吞吐量。
慢SQL有没有出现某个连接，它CPU的占率非常高等等，这些情况都可以这个做整体的分析，这是一个事后的分析，SQL的洞察可能有些SQL语句的查询，是比较慢的，比如慢SQL的识别、诊断，以及给出相关的改进的分析建议，相当于在这个维度提供了一些智能化的能力，可以实际去使用一下。
15. PolarDB 支持完整的数据迁移和同步功能
关于数据迁移和同步的能力，PolarDB应该是比较完整的，在官方文档中心可以看到有非常详细的明，无论是从RDS或者是EC上的自建数据库，还是本地自建的数据库，把数据如何同步到PolarDB上来，还是把PolarDB里面的数据同步到的数据仓库，或者是大数据分析的平台和软件上去，都提供了非常丰富的软件套件，也提供了一些咨询的能力，这个功能是非常完整的，具体问题可以咨询DA。
16. PolarDB的快速发展
17.
PolarDB 5.6- 2018.4上线发布
PolarDB 8.0- 2019.9上线发布PolarDB 5.7 -2020.8上线发布
PolarDB经过2年多的线上客户验证，得到广大用户的信任,PolarDB是阿里云已经规模化运营的产品中成长最快的
PolarDB主要的功能特性和一些简单的技术原理没有展开，只是一个简单的介绍，PolarDB从18年发布到现在差不都三年左右的时间，目前已经有很多客户，而且得到了基本的增长，已经快速的获得了客户的认可，期望越来越多得到大家都认可和支持，有任何发展建议都可以基于反馈。
