开发者学堂课程【PolarDB for PostgreSQL 开源人才初级认证培训课程：开源 PolarDBPG 架构介绍】学习笔记，与课程紧密连接，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1077/detail/15870
开源 PolarDBPG 架构介绍
内容介绍：
一、 PolarDB 总体架构设计
二、 PolarDB 企业级架构设计
三、 PolarDB 开源社区
本次课堂分为三部分，第一部分是 PolarDBPG 的总体架构设计，第二个部分是PolarDBPG 的企业级特性，第三个部分是 PolarDBPG 的开源的情况。
一、 PolarDB 总体架构设计
1. 云原生架构
（1）传统数据库中的痛点：首先看在传统的数据库的问题，看下图右侧是传统的 PolarDBPG 数据库的部署方式，有主库，备库和 Standby 。
主备库之间通过流复制来做同步，做节点的扩展时，需要将一个数据全部复制出来，它的扩展加节点是非常慢的；主备库之间的复制一般是使用异步复制，就有可能丢数据；第三个问题是它的可用性较差，因为主备之间有延迟；第四个问题是成本高，随着将副本数的增加，存储的成本呈线性增加。
（2）计算存储分离：针对以上的问题 PolarDBPG 实现了计算存储分离的一个架构，上图中的右侧就是 Polar DBPG 的架构，有三个节点，一个是读写节点，两个是只读节点，在将存储数据时，通过网络储到后端的存储池里。
①第一个好处是：扩展性较好，当发现计算能力不足时，只需要简单的去增加计算节点，由于数据存储在共享存储上，数据没有必要再做一次复制，计算节点对由于是这种状态的扩展的速度非常快，同样的道理，发现不需要太多的计算资源，那么可以将三个节点迅速扩展成两个节点。
②第二个好处是；多个计算节点共享一份数，存储成本降低，比如在传统的数据库里，有 n 个备库，数据就要负责一份，存储计算分离，数据只需要在公屏上存储上存出一份就可以了。
③第三个好处是；易用性，由于采用了存储计算分离，存储池的技术是相对比较成熟的，保证了数据不会丢失，在计算侧每一个节点都能看到完整的数据库状态，用户的使用体感就是在用一个单机的数据库。
④第四个好处是：可靠性，由于共享存储具备三副本以及秒级备份这些特性，它的可靠性有保障。
（3）PolarDB 计算存储分离的模块栈
①第一个模块栈是事务层，在事务层除了原生的事物，还实现了 CSN 的扩张。
②第二个模块栈是日制程，日志层由于采用了共享存储，那么主库将 WAL 写到供应存储上，备库的时候就没有必要去再做一次流复制，只需要从共享存储上去读取日志，此外，还实现了 Lazy 的回放、并行回放和 LogIndex 核心的数据结构。③第三个模块栈是缓存层，缓存层实现了常驻 BufferPool ，是用来解决当节点重启时， Buffer 数据不需要去重新预热，另外，实现了多版本的页面，解决了 Full Page 的问题。④第四个是存储层，可以实现 DirectIO 数据预读预扩展和出现了一个 PolarVFS 的文件系统的接口。
2.HTAP 架构
（1）传统解决方案的痛点
PolarDB 除了实现计算存储分离的架构，还实现了 HTAP 的架构，上图中再 PolarDB 1.0里的计算存储分离的时候，可以通过读写分离将 TP 的高频发的事物查询均匀地打散到不同的节点上，这是一个好处，这个架构在处理像 IP 型查询这样大的风险性产品时，能力是有问题的，因为一个查询只能在一个计算节点上处理，就没有办法发挥多个计算节点的一个能力。
（2）基于共享存储的分布式计算引擎 – 业界首创
针对这个问题， PolarDB 在存储计算分离的架构上进一步实现了 HTAP 的架构，如图中所示。
在计算层实现了分布式并行计算引擎，任何一个计算节点，既支持单机的查询引擎，也支持分布式并行计算的查询引擎，在图中可以看到最左侧的一个节点，可以用来处理单机的 TP 型查询，用户可以将业务中的所有的 TP 查询，点查点写，可以全部发送到最左侧的节点，同样的业务层可以将一些分析型查询，比如某些业务在业里需要做报表，那么报表通常是在业务的低分区域跑，就可以利用多个计算节点。
图中所配置的是四个只读节点来跑报表的分析，这四个只读节点使用了一个 MPP 的工作原理，这样在一套系统里既可以做单机的点查点写，也可以做多机的并行计算引擎，再去处理 IP 的分析。
①第一个好处，首先是一体化的存储用户 TP 数据写到共享存储里， IP再去做分析时，可以实现一个毫秒级的数据新鲜度，在传统的解决方案里， TP 库到 IP 库之间的复制一般的延迟非常长,这取决于业务的负担，一体化存储时， TP 和 IP 共享一份数据，数据新鲜度就可以做到毫秒级。
②第二个好处，使用一份存储，存储成本就减少了，传统的解决方案，至少需要 TP 集群一份数据，然后同步到 IP 集群，是另外一份数据。可以做到将 TP 和 IP 做物理隔离，可以将部分节点配置成处理 TP 查询，在执行时是执行了单机的执行，同理，可以将其他的节点部署成 分布式的 MPP 执行，从计算节点来看到 TP 和 IP 直接可以做到物理隔离，甚至是可以做到不同的业务域跑在不同的计算节点上，就避免了 IP 查询对 TP 查询的影响。
③第三个好处是，具备了 Serverless 的弹性扩展，任何一个 RO 节点都可以去发起 MPP 的查询，原理就是像传统的 MPP 产品里有一个协调节点，这个协调节点是一个单点， PolarDB 里，由于每个节点能看到所有数据，以及所有的元数据，所有的节点本质上是对等的，也就意味着可以支持任何一个节点，都可以作为整个 MPP 里的协调节点。可以做到 Scale 的级别来调整单机的执行的并行度。可以做 Scale 级别的调整 MPP 的一个执行节点的范围，意思是当发现四个节点在处理一个分期业务时，如果计算能力不足，就可以迅速地增加更多的计算节点到这个集群中，在此过程中，由于新增的节点可以直接访问共享存储，那么在对计算能力做扩展时，无需对数据做重分布，在这个过程和传统的 MPP 系统相比一般的传统 MPP 系统在做节点增加时需要对数据做分布，过程十分漫长。
由于 PolarDB 的计算节点没有状态，在增加计算节点时，几乎可以认为是秒级别就可以把计算节点生效，通过分布式并行计算引擎，可以把新增的节点加入到这样一个分布式并行计算的集群里，可以实现秒级别让整个分布式的计算的资源做扩容，同样的道理，当在传统的 MPP 系统里，如果发现存储容量不足，同样的去需要增加机器，增加机器的过程需要对数据再做重分布， PolarDB 就无需再做扩充，因为 PolaDB 的存储是分布式的存储，那么存储池化后，它的容量可以按需去分配，可以被认为是无限大的，使用 PolarDB 的 HTAP 时就无需去担心存储容量不足的问题。
（3）PolarDB 的 HTAP 在模块的架构
主要分成一个分布式的优化器，在优化器这一层有两个优化器，一个是传统的内置的净化器，这一个优化器是专门用来处理单击的查询，同理，引入了叫 Adam 的优化器，这个是用来处理分布式的查询。
在执行器这一层，引入了大量的算子，除了单机的执行引擎所需要的算子之外，需要对算子做并行化的改造，比如需要支持 ShaderGraph 节点，需要支持对数据扫描节点的并行化操作。在事务层， PolarDB 的 HTAP 是完整的兼容事物，有些部分的 MPP 系统不支持事物， PolarDB 的 HTAP 在执行 MPP 时可以完备的去兼容事物的可见性的级别。在第四块做了大量的工作，是 SQL 的全兼容，也就是在 PolarDB 的 MPP 是全兼容 SQL 的特性,，在这方面做了大量的工作，去实现 SQL 的各个特性。
3.三节点高可用架构
除了支持存储计算分离和 HTAP 的架构， PolarDB 还支持三节点高可用的架构，这套架构是基于 x-Paxos 来做流复制，同时可以将 PolarDB 部署在本地盘上，可以在可用区的内部，通过 x-Paxos 来实现 D 延迟的系统，由于接入了 x-Paxos 协议，可以做到当某个节点宕机时可以自动选择 Leader 节点，自动的做恢复和集群节点的变更，同时借助 Delta Max 可以既支持日志加存储的部署方式，同时还支持仅仅去部署日志的方式，可以通过这种方式来实现两地三中心的部署。
如上图所示，可以将 Region 1 中的日志，通过异步和同步的方式去复制到 Log Syncer 的方式，在本地盘上存储了日志并步存储数据，同时会将表象下有许多复制到另外一个可用区里，那么既保证了可用性，在成本上进一步控制。总结， PolarDB 支持三种架构，第一个存储计算分离架构，第二是 HTAP 架构，第三个是三节点的高可用架构，三种架构在 PolarDB 只需要一套二进制，可以通过不同的配置文件来部署成不同的方式。
4.PolarDB 总体架构 – 架构之间的关系
这三个架构是正交的关系。
在上图的左侧可以看到，可以部署云原生架构和 HTAP 这样一个混合使用的方式，前面提到业务可以根据自己的需求去把 TP 和 AP 流量分别发送到不同的计算机里，而且它的存储是一份陈述。在图中的右侧，可以实现 X-Paxos 以本地盘的方式部署起来，这时候就有一个 Leader 和两个 Follower ，这样可以做到高可用的方式，同时在本地盘的方式，也可以支持 HTAP 的业务负载，比如可以将 TP 的查询发送到 Leader 节点上，同时将 IP 的查询的产品发送到 Follower 上，同时多个 Follower 和 Leader 节点，也可以组成分布式的查询，这样就解决了传统 DB 数据库的这种方式，在做分析时它的计算能力的扩展的问题。
二、PolarDB 企业级架构设计
除了上述三种架构之外，还实现了一些企业级特性。
1.架构
第一是从架构上，前面总结过云原生的架构有 HTAP 架构，X-Paxos 高可用架构和三节点可用架构，
2. 高性能
第一个是在性能上实现了 CSN 的扩展是用来解决在单核随着核数的增加，它的性能的线性扩展的问题；第二个是实现了 WAL Pipeline 的功能，来加速 WAL写入提高 WAL 写入的吞吐量；第三个是实现了预读和预扩展的功能，在做分析的查询时，需要大量的做扫描，这个时候预读会尽可能的去发挥在共享存储的大的带宽的特性；第四个在功能上是实现了 RelSizeCache ，开始在做计划查询，首先需要得到文件的大小，就需要对文件大小的云数据做缓存；下面是 CLOG 的优化，以及 FullPage 优化，这两个优化通过 Logidex以及多页面（ MAP ）的来彻底的避免掉 FullPage 的问题， FullPage 实际上在 PolarDB 上有两种解法，第一个解法是如果共享存储提供了8K 或者 8K 以上的原子写，那么就可以直接将 FullPage 给关闭掉，因为共享存储是一个软件定义的存储，它的原子写可以大于硬件的页面的单位；第二个解法，如果共享存储的原子写没有做到8K 及 8K 以上，这时候可以使用的页面 redo 版本将 FullPage的内从 WAL 日志剥离出来，这样就可以大大减少 WAL 日志的容量。
3.高可用
首先实现了 DataMax ，DataMax指一个 Loger 节点，这种部署方式可以通过 Page 文件将 PolarDB 部署成只存储 WAL 日志，不存储数据页面，这样再配合 X-Paxos 就可以做到两地三中心的部署架构。
第二个功能是 Online Promote 在做 HI 切换时，云原生需要重启，PolarDB 做到了可以在线立即将备库切换成只读写的主库，没有必要重启。
另外实现了延迟回放和并行回放，这两个功能用来加速主备之间的复制延迟，经过测试在 TBCB 和 的 RelSizeCache 的高压情况下延迟可以做到毫秒的级别
另外实现了常驻 BufferPool ，意思是数据库的 BufferPool 在做重启时BufferPool是丢失的，而 BufferPool 中大量的内容是缓存，存储的页面的内容，如果丢失了数据块重启的很长一段时间都需要预热，常驻 BufferPool 是将 BufferPool 的内容剥离了出来放到了共享存储里，随着进程的重启 BufferPool 不会被销毁，这样就尽可能地去维护了 Buffer 的可用性，。
第二实现了 Rwplication Slot 持久化的功能，这样就防止备库变成主库之后 Rwplication Slot 的丢失
第三还实现了算子级内存控制，在执行分析性查询时，某些算子使用大量的内存导致内存膨胀，最终导致 OM ，算子级别的内存控制，就是可以精细地控制每个算子使用内存的上限。
4.安全
PolarDB 实现了 TDE 透明加底的功能，支持 AES 128位， AES 256位以及国密 SM4 的算法 。
三、PolarDB 开源社区开源策略
PolarDB 在去年的云栖大会之前，对所有的内核代码都做了开源，在开源时，PolarDB 始终要坚持百分之百兼容社区的 PostgreSQL ，第二个是在将三个核心代码全部开源，第一个代码是 PolarDB 的内核代码，第二个是 PolarDB 分布式文件系统的代码，第三个是PolarDB 的云管控代码，在开源时，开源的代码和公有云的代码是一样的，是经过了云上客户以及内部测试同学大量的验证，开源代码的代码质量是很高的，用户和新趋者可以直接拿 PolarDB 部署在自己的生长环境里去使用。
PolarDB 在开源的同时还提供了丰富的文档和视频资料，比如，整体架构文档、核心功能的原理进行解析、快速入门文档。
