编者按：
本文作者系Scott（中文名陈晓辉），现任大连华信资深分析师 ，ORACLE数据库专家，曾就职于甲骨文中国。个人主页：segmentfault.com/u/db_perf ，经其本人授权发布。
【免责声明】本号文章仅代表个人观点，与任何公司无关。
今天聊一下数据库的另一个分支：云数据库。
伴随着计算机技术的高速发展和数据库的广泛运用，越来越多的大小企业都建立了自己数据库或数据中心。这些企业有的从事的是计算机相关的行业，对于他们来讲，因为本身具备相关的知识储备，建立和维护数据中心并不是什么难事，只不过是增加设备和人员而已。但是这类企业并不代表全部需要数据库的企业，绝大多数企业本身从事的主业并不是计算机相关的业务，也没有数据库相关的知识储备，所以必须建立相关的部门专门从事本企业数据库或数据中心的维护和升级。这也成为企业的一个重要的成本负担。
但是所有的付出都是有回报的，这两类企业的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在存储方面还做了以下优化：
代码语言：javascript复制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。
代码语言：javascript复制“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，以后有机会再继续聊，今天就到这里吧。
