数据库架构杂谈（1）云数据库架构

百補园的张和

《数据库架构杂谈》是一系列关于“理念”的文章，表达了我们在“分布式数据库”这个新兴技术上的观点和思考。系统设计永远是一个充满着取舍的问题，这些所谓观点并无谁对谁错之分，仅仅代表我们的思考。如果你有任何想说的，也欢迎在评论区与我讨论。
本文是此系列的第一篇文章，介绍了云原生数据库的两大类架构：shared-storage （共享存储）架构和 shared-nothing （无共享）架构，并提出我们的愿景：将 NewSQL 思想与共享存储结合，打造新一代的云原生数据库。
云数据库的现在

在放眼未来之前，我们先看看云数据库近几年的现状。AWS 作为云计算的开拓者，并未止步于直接售卖开源版本的 MySQL（也就是 RDS），而是在 MySQL 基础上研发了 Aurora，硬是把 MySQL 改造成了一个横跨 3 个可用区、拥有 6 份 replica 的高可用分布式数据库。



Amazon Aurora 架构

对 Aurora 有兴趣的同学可以直接阅读 SIGMOD'17 的那篇论文 [1]，网上也有很多资料，这里就不再展开了。Aurora 的设计理念和许多 AWS 产品一脉相承——基于开源项目，用云的方式去改造，保持最大的兼容性。Aurora 站在 MySQL 这个巨人的肩膀上，通过改造 IO path 提升性能的同时又做到高可用，可以说是非常精巧的设计。
有了先驱者探路，其他云厂商也纷纷跟进。腾讯云的 CynosDB 以及华为的 TaurusDBhttps://zhuanlan.zhihu.com/%5B%E4%BA%91%E5%8E%9F%E7%94%9F%E6%95%B0%E6%8D%AE%E5%BA%93%E4%B8%89%E9%A9%BE%E9%A9%AC%E8%BD%A6%E4%B9%8BTaurusDB%5D(https://bbs.huaweicloud.com/blogs/151227)直接照搬了这套设计。阿里云 PolarDB 则略有一些区别，PolarDB 同样是改造自 MySQL，不过动手术的地方更底层一些，简单来说是将文件系统层替换成了分布式存储。这种架构常被称为 shared-storage（共享存储），意为将本地盘存储换成了分布式共享存储。

PolarDB 除了共享存储以外还做了许多其他改进，例如锁管理器、buffer pool 等，官方有时会将其称为 shared-everything 架构。

共享存储架构很好的解决了数据库存储容量的 scale out，几乎可以无限扩展。甚至更进一步，云厂商可以将磁盘资源池化，实现按实际使用量付费（pay-as-you-go），大大降低用户使用成本。但该架构也存在明显的瓶颈：尽管存储方面全面拥抱了分布式，但 MySQL Server 这一层还保留着单机数据库的一切，尤其是并发事务处理能力（写入吞吐量），受单个节点的性能上限制约。好在对于大多数用户来说这已经足够了。
NewSQL 的崛起

云计算曾经的另一个流派—— Google，时常走在 Amazon 的对立面。在云数据库这个主题上，Google 拿出的解决方案是 Spanner，它 2012 年的这篇论文 [2][3] 可谓是惊艳了众人，在 scale out 和高可用性上都无可挑剔，尤其是依靠原子钟实现全球级的外部一致性。
Spanner 支撑了 Google 内部巨无霸级的广告业务，但是作为一款云数据库，在商业上几乎是失败的。与开源生态不兼容就意味着 vendor lock-in（厂商绑定），而这是企业 CTO 们不愿承担的。
大约从 2014 年开始出现了一些 Spanner 的开源模仿者（是不是很像 Hadoop 的故事？），其中的代表包括 CockroachDB 以及国人研发的 TiDB。CockroachDB 的设计理念与 Spanner 如出一辙，不过把原子钟换成了更亲民的 NTP 协议，并设计了精巧的协议来保证事务一致性；TiDB 则干脆放弃了全球部署，仅保留了最关键的 scale out 特性。


NewSQL 系统的架构大多可以分为两层：底层的分布式存储层和上层的 SQL 计算层。分布式存储层可以类比成 HBase，往往通过 Paxos 之类的一致性协议保证高可用；SQL 计算层负责解析用户的查询，然后从存储层访问相应的数据。我们常将 NewSQL 的这一套架构称为 shared-nothing（无共享），意为每个节点都是独立的进程，不存在任何共享资源。
这样的架构中，无论计算层还是存储层都很容易 scale out，只需添加更多的节点即可。对于无状态的计算层，依靠容器技术，不难做到秒级启动新节点。而存储层的 scale out 则略显麻烦一些，新节点需要从原来的节点中复制数据，等数据达到同步后即可对外提供服务。
NewSQL 是云数据库的终态吗？

我们很高兴的看到，近几年 NewSQL 的开源社区一直在蓬勃发展，NewSQL 这一概念也为更多开发者所接受。但俗话说“没有银弹”，在云数据库这个战场上，NewSQL 仍有明显的缺点：
其一是成本偏高。我们知道 RPC 的代价是远高于进程内调用的，这种低耦合的架构中，每次查询往往包含数次内部 RPC，导致单个查询消耗的资源大幅上升。另一方面，为了实现数据存储的高可用，需要将每份数据保持至少 3 份拷贝，这又进一步抬高了单位成本。
其二是存储层的弹性不足。新加入的存储节点需要从原有的节点上同步大量数据，这一过程必然会耗费较长的时间，而且会挤占现有存储节点的 IO 带宽。因此实际生产中往往还是需要预先规划好容量，做不到 Aurora 那样极致的弹性伸缩。
这两点恰好也是“云原生”（cloud-native）的优势所在。云原生的分布式存储本身已经解决了高可用和弹性伸缩问题，而且作为基础设施组件，云厂商通常都在软件、硬件层面做了大量优化，再加上云计算的规模效应，单位性能的成本往往都要比自建划算的多。


这也是我们设计 PolarDB-X 的理念：把 shared-nothing 和 shared-storage 两种主流架构融合、统一起来，取长补短。一方面，像 share-nothing 架构一样具有接近无限的 scale out 能力，不受单个读写节点的限制；另一方面，利用容器技术以及云存储的优势，做到随时扩容缩容，用户只需为实际使用的资源付费。
引用来源

• Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases
  
• Spanner: Google's Globally-Distributed Database
  
• F1: A Distributed SQL Database That Scales
  

啸月残狼

对于成本那里有两个问题，第一个RPC调用那里有成本降低吗？感觉RPC调用并没有减少。第二个问题，底层共享存储也是多副本存了多份，所以也没有降低存储成本？

荆山一郎

第一个问题：shared-storage 架构中由于没有分区的概念，不需要汇总多个远程节点的数据，这是它相比 NewSQL 系统的优势。PolarDB-X 设计中也对外暴露了分区键的概念，通过合理选取分区键，可以做到大部分查询都仅仅涉及单个数据节点。这个会在未来的文章中展开。

档下灬很忧郁

第二个问题：云厂商提供的分布式存储的确也有多个副本，云厂商的成本优势主要体现在规模化上，集群总存储容量越高，边际成本越低，这一点对于所有云产品都是一样的