明天聊一下数据库的另一个分支：云数据库。
随同着计算机技术的高速倒退和数据库的宽泛使用，越来越多的大小企业都建设了本人数据库或数据中心。这些企业有的从事的是计算机相关的行业，对于他们来讲，因为自身具备相干的常识储备，建设和保护数据中心并不是什么难事，只不过是减少设施和人员而已。然而这类企业并不代表全副须要数据库的企业，绝大多数企业自身从事的主业并不是计算机相关的业务，也没有数据库相干的常识储备，所以必须建设相干的部门专门从事本企业数据库或数据中心的保护和降级。这也成为企业的一个重要的老本累赘。
然而所有的付出都是有回报的，这两类企业的 TOP 企业都在保护本人宏大的 IT 架构和各种各样的数据的同时，倒退出了本身的基础理论和全面的常识教训储备，并且利用这些常识和 IT 基础架构开发出了新的业务和经济增长点：云计算。
这个过程中呈现了一个乏味的景象是，无论国内还是国外，排名第一的都是电商类企业。这类企业自身有肯定的技术根底，又有因特网时代的商业思维和实践 / 实际根底，还有一个最大的劣势：就是有机会接触到海量数据，是最早触摸到现有技术的边界而不得不创始新思路，摸索新解决方案的一类企业，就如国外的 AWS 和国内的阿里云。
还有另外一类企业，如微软的 Azure 和谷歌的 Google Cloud。这类企业因为自身从事的就是计算机相关的业务，他们尽管不像第一类企业有足够的数据量率先遇到传统技术的天花板，率先开始云生态的构筑。但他们却有足够的技术储备和后发优势，帮忙他们在云计算这个大蛋糕里分一杯羹。
而在“云计算”这个简直颠覆现有技术架构的新生态的盛宴上，云数据库无疑是其中最让人垂涎三尺一块肥肉，引得泛滥大厂纷纷退出战团，推出本人的云数据库产品。
那到底啥是云数据库呢？
是简略的把数据库从本地机房移到云上吗？当然不是。
先不说云原生啥的浅近概念，起码也得是依据云上软件硬件和架构特点进行过改写优化的数据库。
咱们举几个例子来简略介绍一下云数据库。
首先是 AWS 的 Aurora 数据库。
Aurora 数据库是在开源数据库 Mysql 的根底上，针对 AWS 云上 I / O 特点的变动进行优化的分布式数据库。
咱们先来看看 AWS 上 Mysql 数据库架构的 I / O 流状况。
上图是 MYSQL 数据库的一主一副架构的 I / O 流。
咱们能够看到除去把 BINLOG 备份到 S3 上的 I / O 流，还有其余的 25 个 I / O 流须要在一个事务处理中实现，这无疑会拖慢 Mysql 的整体速度。
咱们再来看看 Aurora 数据库做了哪些改善。
是不是感觉世界登时喧扰了许多。
而且，Aurora 在存储方面还做了以下优化：
1. ORACLE 的 Exadata 一样，采纳了计算节点和存储节点拆散，计算节点和存储节点只有 LOG 数据流，实现了“Log 即数据”的设计理念。2. 6 个存储节点散布在 3 个可用区，外部采纳 quorum-based voting protocol 机制判断读写一致性（读 3 写 4），并且存储节点外部通过 Gossip 协定进行主动 Gap Fix（参照下图）。3. Replica Instance 能够依据 Workload 进行主动扩大到跨三个可用区最多 15 个低提早读取正本。
另外，从 2017 年 11 月开始，AWS 还推出了多主节点 Aurora 数据库。到 2020 年 5 月为止，Amazon Aurora Multi-Master 将服务的可用性扩大到 8 个 AWS 区域。
上面咱们再来看看阿里云的 PolarDB。
首先，PolarDB 和 Aurora 最后的设计思维是统一的，只不过在实现的细节以及重点优化的 bottleneck 有所不同。并且，因为 Aurora 的设计开发要早于 PolarDB，所以，Amazon 在 2017 年 5 月公开了 aurora-design-considerations-paper.pdf，并且推出了商业产品之后，阿里的 PolarDB 还在研发中，于是阿里就用了好几个月来学习消化 Amazon 的论文，从新评估了两者的区别和优缺点，至于是否采纳了 Aurora 的设计思路就不得而知了。
上面是 PolarDB 的架构图，让咱们来看看它和 Aurora 有啥不同。
依据阿里公布的 PolarDB 论文，PolarDB 是在 PolarFS（An Ultra-low Latency and Failure ResilientDistributed File System）的根底上实现的。
PolarFS 有上面两个层：File System Layer 和 Storage Layer。
File System Layer 次要是 ibpfs，一个轻量级的齐全运行在用户空间的文件系统。这个文件系统和 PolarDB 实例捆绑在一起，实现对存储在数据库实例中的 CHUNK 的读写解决。
Storage Layer 次要有 PolarSwitch，ChunkServers 和 PolarCtrl 几个组件。
PolarSwitch 是数据库服务器端的一个伺服过程（daemon process），负责 ibpfs 和存储节点 ChunkServers 之间的通信。
ChunkServers 是数据库的存储节点，由多个搭载了专用 CPU 和 NVMe SSD disk 的高性能服务器组成。ChunkServer 之间应用 ParallelRaft 协定进行 Gap fix。
PolarCtrl 是整个 PolarFS cluster 的控制器，提供例如节点治理，卷治理，资源定位，metadata 同步，和状态监督等性能，是提供高可用服务（high-available services）的重要组件。
另外，PolarFS 架构中的计算节点和存储节点之间，存储节点和存储节点之间的通信，并没有应用传统的 TCP/IP 协定，而是采纳了 RDMA（Remote Direct Memory Access）技术，极大的进步了节点之间的通信能力。应用硬件的晋升解决了 Aurora 论文中所提到的最大的 bottleneck。
“Instead, the bottleneck moves to the network between the database tier requesting I/Os and the storage tier that performs these I/Os.”
对于 RDMA，大家能够参照一下上面的图了解一下。
好了，对于云数据库，比拟有代表性的还有腾讯云的 CynosDB 和华为云的 TaurusDB，当前有机会再持续聊，明天就到这里吧。
2021/03/04 @ Dalian