开发者学堂课程【数据库开源校企合作“数据库内核从入门到精通 ”系列课：数据库内核教学课程-数据库系统概述】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1239/detail/18418
数据库内核教学课程-数据库系统概述
七、SQL引擎-优化器
通过逻辑计划生成了Query Tree 经过优化器的优化改为一个物理的置换，之后再去执行。之后可以看到 Polar DB-X 相关优化器的一个情况，包括它很多个算子的下推，包括 Join 顺序的一个选择，以及一些算法的实现，算子交换。
在这个模块里面，它会依赖表的行数、Null值，计算各个路径的代价模型，然后选择一个最优路径，来做相关的一个查询，这个系统，像吞没式系统里面会有类似于 Gather 算子进行一个聚合。
八、执行引擎
执行引擎就是相当于你先有一个SQL，经过优化器的优化之后，形成了执行计划，这个计划用关系代数的方法表示，就是类似于这种方式，这两张表经过一个选择，值大于100，两边都选择过后选择一个连接，进行一个等值的判断，之后再进行一个投影，来得到最终的结果。这个图说明每个算子都在进行循环，循环读取算子里面的信息，之后把它返回给上层的节点，我们的向量化执行，我返回多个算子，整个系统看起来就像一个循环，去驱动去读取下面节点的数据，就会去做连接、投影的操作，返回用户最终想要的结果。
九、事务引擎-分布式事务的两阶段提交
在做分布式事物的时候，两阶段提交是必须有的，两阶段和三阶段提交，三阶段交互的更多，可靠性更高，但是，没有必要，交互的多，性能肯定就不行了，所以，大家现在在用的都是两阶段提交的方式，这个是Polar DB-X的一个图，首先会有一个Coordinator 节点，相当于获得一个查询、处理，我去跟多个 DN 节点，一起来执行这个事情，当我要做一个修改和提交的时候，我们首先会做prepare的预提交，查看每一个参与者是否都满足提交的条件，如果都满满足的话，它会给大家发一个正式提交的指令，这个时候各个节点才会正式提交。
在准备提交的时候，在系统包括 PG 它的日志已经落盘了，需要提前做好很多的准备工作，最终提交的时候写一个结束日志它就结束了，所以它把最后提交的阶段做的更简单，不易出错，即使是这样，你在这个阶段达成了这样一个日志，工作已经执行完了，但是再次发消息的时候它是有一个时间差的，在这个时间差里面如果某个节点挂掉了，它是没有办法给它发送提交消息的，或者发给它它也没有处理，这个时候它也没有提交成功，这种情况下，系统会采用认为它提交了，需要在系统启动之后会有一个 Clean 把这些有问题的来进行一个辅助的提交。
十、事务引擎-分布式事务处理技术
分布式事务：分布式数据库的扩展性必须需要数据分区，随之而来的后果就是必须处理跨数据分区的分布式事务。
述：
An Evaluation of Distributed Concurrency Control ( VLDB '2017).
The End of a Myth : Distributed Transactions Can Scale ( VLDB '2017)
Percolator : Google 在分布式 Key - value store ( Big Table ）上利用 TSO 和行原子性操作实现分布式事务处理协议． Large - scale Incremental Processing Using Distributed Transactions and Notipcations ( OSDI '2010)
Spanner ：利用原子钟和 Commit Wait 机制实现分布式事务，保证外部一致性。
Spanner : Google ' s Globally Distributed Database ( TOCS '2013)
Calvin :确定性事务排序批量执行机制。 Calvin : Fast Distributed Transactions for Partitioned Database Systems ( SIGMOD '2012)
HLC ：使用 TSO （全局时间戳）对分布式事务进行定序， TSO 会成为局部单点，影响扩展性，混合逻辑时钟根据事务相关性生成时间戳，解决扩展性问题。
Logical Physical Clocks and Consistent Snapshots in Globally Distributed Databases CockroachDB : The Resilient Geo - Distributed SQL Database ( SIGMOD '2020)
也会提到事物的算法，包括 MACC 的一些算法，另外就是一些分布式事物的算法，包括 Percolator 中 TSO 的算法，TSO它是中心的时钟，有一个中心节点的作用，和 PSXC 很像，ID式从中心节点，用中心时钟的时候，不需要 PSXC，对大数据的传递性更好，这种事类似于 TSO 的方式.
Spanner最早使用的中心时钟是原子钟，是利用了硬件实习了通讯，保证了误差非常小，利用了 Commit Wait 机制，在使用 Commit 的时候 Wait 一个误差范围内的时间，保证提交是有序的，保证了提交范围内时间的有序性，所有的时钟在分布式系统里都是有序的，当所有节点是有序时，提交就是有效的。
Calvin是对事物进行一个排序处理，来保证时间是有序的，保证事物的有序性。
HLC是逻辑物理时钟，由物理和逻辑两部分组成，PG也运用到 HLC 的算法里面。
十一、实战优化-资源解耦与池化
主要讲Polar DB一些的特点包括自选的解耦和池化，会把SQL引擎和存储引擎进行一个解耦，分层扩展，内存也进行解耦，最新的文献里，内存也进行了解耦，阿里云的文献里讲了分层解耦带来的机遇和挑战。
云数据库和传统的数据库的差别。做分层解耦之后会做 serverless 技术。
十二、实战优化-存储计算分离 ，Log AS DB
介绍了在存储计算的时候如何做到分日志的同步，这篇文献里主要讲了数据放大的问题，传统的系统它的计算节点和共享存储节点传递的是它的数据页，但它的数据页是比较大的，在节点之间，存在小放大的问题，特别是在云上，网络的开销是很重要的一个开销，在网上传输和么大的数据是不容乐观的，而Log AS DB传输的是日志，这个日志在其他节点，包括存储上进行一个回放，回放会产生一个新的数据，在这种情况下，它的Redolog 模块进行了一个交互，它会和最下层交互一个最小的L层，相当于大家读到的 LSN 之后的一个数据，比L层更小的数据都能读到，在节点之间大家也会维护一个 RW ，这个RW 就是当前我可以提交的可以独到的SN,你拿到SN 去读配置的时候，数据页不会直接传过来，我对应修改的SN 传输过来了，我在读这个数据页的时候，我要知道数据页是比较新的数据页，我要观察它的 SN跟RW 的SN 它之间的一个关系，查看是否为最新，用这种方式保证各节点的数据为最新。
十三、战优化-共享存储系统高可用与延迟优化
最重要的就是在计算节点通过 Polar访问存储PolarFS和PolarStore 相关存储提供的一些性能，特点是使用用户态的I/O，保证了它的性能很高，并且它不会利用操作系统的存储，包括零拷贝和低延迟，以及硬件的优化，从而实现共享存储的系统。
十四、实战优化-分布式 MVCC 事务
可以看到有一个中央奏时 GMS，是TSO 的方法，GMS 为了保证可靠性，做了三个副本，保证可用性，一个节点挂掉了，其他节点会运作起来，GMS 它负责奏时，在启动事物的时候要一个事物 ID ，事物ID 在事物提交的时候会有一个时间戳，这个时间戳就又一个可鉴性的一个判断。
十五、战优化-高可用
高可用：
CAP 理论证明了分布式系统不可能同时满足 Consistency , Availability , Partition Tolerance ,实际应用领域中， Partition 一定会发生， C / A 是不可兼得的，但这不意味着我们需要放弃其中一个，因为实际系统并不追求同时保证100％一致性和可用性， TP 数据库对数据强一致性的要求是无法妥协的，因此在保证强一致的前提下，能够保证多大程度的可用性便是分布式数据库需要着重思考的问题。
综述：
如何在分布式数据库系统中对一致性进行取舍： Consistency Tradeoffs in Modern Distributed Database System Design ( DJ Abadi , Computer ,2012)
Paxos :分布式一致性协议是保证分布式数据库系统数据强一致的关键，而每种分布式一致性协议或是算法最终都是 Paxos 及其变体，（原始论文： The Part - Time Parliament , ACM Transactions on
Computer Systems 1998), Paxosl 以其晦涩著称，不易理解，所以 Leslie Lamport 后来又写了简单版本（ Paxos Made Simple )；即便如此，工程实现也殊为不易，为此 David Mazi ' eres 写了（ Paxos Made Practical ）探索了工程实现。还有其他的一些一致性算法比如（ Viewstamped Replication , ZooKeeper 的 zab 协议）实际上都可以视为 Paxos 变体，可以选读。
Raft : Paxos 由于其难于理解在实际工业系统中落地的并不多， Diego Ongaro 设计了一套等价于 Paxos 但是通过一些增强约束大大提升了 Paxos 的可理解性，把 Paxos 工业应用向前推进了一大步， Search of an Understandable Consensus Algorithm , USENIX ATC '2014)
从Paxos 应用来看，相对来说真正应用是比较少的，就谷歌用的这个，其他公司大部分用的还是Raft ,在工业实现方面更容易一些，所以在 GTM 和 DN 节点，也都是利用了 Raft实现三副本或多副本的一个高可用。
