【关系型数据库】PolarDB

写在前面

个人比较喜欢在大家都休息的时候，研究一些自己感兴趣的东西，比如这篇文章，只是做到了对PolarDB的一个认识，先写在这里，等以后用到了再来细究。
在当下，关系型数据库仍然占据主导地位，最主要的原因之一就是关系型数据库采用了SQL标准，这种高级的非过程化编程接口语言，将计算机科学和易于人类理解认知的数据管理方式完美的衔接在了一起，目前还难以超越

PolarDB是什么及其由来

PolarDB是阿里云自主研发的新一代云托管关系型数据库。
云计算时代：在IT时代，传统的计算力（例如用关系型数据库来处理结构化数据等）是服务于系统硬件隔离环境下的多用户使用场景的。而云计算时代是多客户Self-Service租用环境，各种计算负载场景更加复杂，在这种计算负载变迁的环境下，如何解决IT时代的技术产物和云计算时代应用场景的适配矛盾，是云计算自我进化的内在推动力。但是当前云计算时代还远远没有到达鼎盛时期，除非它通过自身进化演变，在不断保持性价比优势的同时，在具有快速灵活弹性的内在属性基础上，拥有超过传统 IT计算力的能力之后，云计算才会真正进入它所主宰的时代，这只是个时间问题。
所以所有的云计算厂商都不可避免要经历这样一个阶段。只不过阿里云相对别的厂商走在了前面。

PolarDB关键技术点

先来看看PolarDB的产品架构：

我们可以看到，PolarDB 产品是一个分布式集群架构的设计，计算节点和存储节点之间采用高速网络互联，并通过 RDMA 协议进行数据传输，使得I/O 性能不再成为瓶颈。DB 的数据文件、redolog等通过 User-Space 用户态文件系统，经过块设备数据管理路由，依靠高速网络和RDMA 协议传输到远端的 Chunk Server，同时 DB Server 之间仅需同步 Redo log 相关的元数据信息。Chunk Server的数据采用多副本确保数据的可靠性，并通过 Parallel-Raft 协议保证数据的一致性。

Shared Disk架构

分布式系统的精髓就在于分分合合，有时候为了并发性能进行数据切分，而有时候为了数据状态的一致性而不得不合，或者由于分布式锁而不得不同步等待。
PolarDB 采用 Shared Disk 架构，逻辑上 DB 数据都放在所有 DB server 都能够共享访问的数据 chunk 存储服务器上。而在存储服务内部，实际上数据被切块成 chunk 来达到通过多个服务器并发访问 I/O 的目的。

物理 Replication

由于单个数据库实例的计算和网络带宽有限，一种典型的做法是通过搭建多个只读实例分担读负载来实现 Scale out。PolarDB 通过将数据库文件以及Redolog 等存放在共享存储设备上，解决了只读节点和主节点的数据Replication 问题。
由于数据共享，只读节点的增加无需再进行数据的完全复制，共用一份全量数据和 Redo log，使得系统在主节点发生故障进行 Failover 时候，切换到只读节点的故障恢复时间能缩短到 30 秒以内。

总结

有时候转换一种思维，就有可能引发一场革命。就像PolarDB 采用的 Shared Disk 架构，将逻辑上 DB 数据都放在所有 DB server 都能够共享访问的数据 chunk 存储服务器上，这是一种尝试，但也是另一种思维。
越是底层的规律，越需要耐心去钻研。事务必须服从的四个原则：A（原子性）C（一致性）I（隔离性）D（持久性）。在《数据库系统原理》中就接触过，在对PolarDB研究查找资料的过程中，这四个原则会出现出现再出现。大道至简大概就是这样。
所处位置不同，导致需要思考的内容也会不同。所以，如果可能，要尽量把自己的思维放在一个较高的位置上。
感谢您的阅读~