分布式SQL深度挖掘：YugabyteDB的两层架构揭秘

2022年3月10日

YugabyteDB 是一个100%开源的分布式SQL数据库系统。这个短语表达了两个截然不同的概念：SQL数据库系统和分布式数据库系统。历史上，这些概念是相互排斥的。但是当前技术允许单个系统实现这两个概念。YugabyteDB通过其两层架构实现了这一点：可扩展的查询处理层和分布式文档存储。

在这篇博客文章中，我们将解释YugabyteDB的两层架构是如何工作的，并将其与其他流行数据库进行了比较。我们还研究了它给云原生应用程序带来的好处。

为什么是分布式SQL？

企业应用程序执行复杂的查询和事务，其功能远超通过唯一键简单存储和加载值或文档。这就是发明关系数据库和SQL的原因：提供企业信息系统的一致视图，即使在通过并发访问和复杂业务事务进行更新时也是如此。

如果有一个集中的单一事实点也就是单一数据库，事情就容易一些。然而，存在这样的需求：将(数据库功能)扩展到一台服务器之外，在服务器上的任何故障或维护期间确保数据的可用性，并提供web级别高性能。这就是为什么NoSQL数据库删除了许多(SQL)功能来将数据库分区，并跨越多个节点访问，这些节点不共享任何状态。

今天的数据库技术允许结合这些功能：将数据分发到多个服务器，并允许完全一致的跨节点事务。算法很早就有了（例如，兰波特时钟、Raft共识协议以及散列和范围分片）。但改变的是基础设施（即云、容器和自动化）和硬件（即SSD而不是具有更多核心的机械驱动器和处理器）。

探索YugabyteDB的分布式SQL体系结构

DocDB 作为存储层或YugabyteDB两层架构的底层。它分发所有内容，如存储和事务。内部API对一批键值的读/写请求进行操作。这类似于许多NoSQL数据库。但是，YugabtyeDB完全符合ACID，因此一致性通过附加数据进行处理，包括事务控制操作和临时记录（我们称之为意向）。

即使是单行操作也需要这个事务层来提供与全局二级索引的强一致性。一个单行事务需要多个读/写操作，具有所有ACID属性。该层对于SQL持久性是必需的，但对于键值访问也是完全ACID的。DocDB层是YugabyteDB的强一致性和高可用性分布式文档数据库。每个分片运行一个优化RocksDB版本，处理DocDB的底层存储。但Yugabyte的主要创新是DocDB提供的分布式持久性、事务和复制。

YugabyteDB的查询处理层，称为YSQL ，提供的不仅仅是API、协议、SQL语法和行为。由于DocDB处理所有分布式事务、持久性和可用性问题，因此该查询处理层的主要特征是其无状态性质。这允许更复杂的处理，不受跨多个节点同步状态和缓存的限制。

在接下来的部分中，我将比较YugabyteDB的两层架构与其他架构。我还将解释哪个层完成数据库中的操作。

比较YugabyteDB的查询处理层（YSQL）

YugabyteDB的SQL处理层的无状态属性允许所有当前和未来的功能，这些功能只有在这种架构下才可能实现。其他分布式SQL数据库可以添加复杂的SQL功能，但它们必须一次集成一个，具有固有的局限性。这是因为它们必须在有状态的分布式组件上运行。而单层分布式数据库上的每个新特性都具有更高的复杂性和更少的可伸缩性，因为有一个共享结构需要同步。

Oracle的RAC

我首先将YugabyteDB与Oracle RAC（Oracle数据库的扩展解决方案）进行比较。RAC是一种共享的一切架构。每个共享组件都带来了新的限制，例如主要版本无法滚动升级。

当然，RAC是一项令人敬畏的技术，但它可能复杂且昂贵。并且它只解决了部分问题（即，实例的高可用性而不是数据的高可用性）。要提供数据高可用,需要将其与Oracel最大可用性体系结构（MAA）组件相结合。

亚马逊Aurora

另一个例子是亚马逊Aurora。其存储层是分布式的，可以扩展，但事务层仍然与SQL层互连。这意味着写操作不能扩展，因此尽管它们很快，但只限于一台服务器。还有一个共享缓冲区缓存，查询处理层可以直接访问。这意味着扩展读取操作仍然需要与远程缓存进行一些同步。

受短距离和共享数据的单个活动写入器的限制，这两个数据库的扩展能力非常有限。在YugabyteDB中，存储和事务处理被下推到较低层，我们有一个无状态层，用于处理复杂的用户命令和查询。

查询处理兼容性

在查询处理层，“兼容”是一个弱词：YSQL实际上是在重用PostgreSQL，将这个流行的开源关系数据库插入到分布式存储层的顶部。重用PostgreSQL可以访问其所有功能以及生态系统中的应用程序、工具和框架。但这在有状态层中是不可能的，其中每个模块必须跨节点同步。

例如，PostgreSQL读写通过其（本地）共享缓冲区缓存。这不能照搬扩展到分布式情形。但YugabyteDB的查询处理层并不需要它：元组进入DocDB，而不是共享缓冲区缓存。

这种架构选择不仅与当前功能有关。它允许YugabyteDB与新版本的PostgreSQL一起发展，包括新的API、协议和语言。简言之，这种两层架构每天都有回报。

因为PostgreSQL是最受欢迎的开源数据库，接近SQL标准，所以许多数据库都以PostgreSQL兼容性为目标。但使用PostgreSQL作为查询处理层，所有功能都具有相同的行为。主要工作是优化它们，使查询优化器感知分布，并下推一些操作以减少移动来回数据。这对于开源数据库来说也是必须的，因为它允许PostgreSQL贡献者添加特性，而无需了解分布式协议的最深层细节。

比较YugabyteDB的分布式SQL文档存储（DocDB）

DocDB将读取操作作为对一个键（对于“点查”，在SQL世界中称为唯一键查找）或一组范围内一系列键（用于查找和读取）的查询。键的更改向量发送写入操作。这些操作的目标是“tablet”，它是表和索引的拆分（在DocDB中是相同的结构）。

CitusDB

tablet的分布看起来像一个分片数据库，您可能会看到与CitusDB的一些相似之处。如果这样认为，重要的是要理解YugabyteDB分片位于不同的层。使用CitusDB，分片在SQL处理的早期完成。这意味着，一旦SQL语句被协调器拆分为子查询，子查询就会在小型单体数据库上运行。没有跨分片的外键，没有全局索引，也没有高性能跨分片事务。这对于SQL数据仓库或具有少量独立租户的多租户非常有用。

但是为了运行分布式SQL，即使是最简单的一行插入也是跨分片事务。这就是为什么YugabyteDB分片在DocDB级别。从复杂SQL到键值对操作的转换提前完成，允许所有复杂SQL功能。这些键值对操作在其事务一致性完好无损的情况下进行分发。如果没有这个DocDB层，就不可能同时获得所有SQL特性，也不会有这种无任何共享结构的可伸缩性。

在这个DocDB级别上还发生了其他事情，这可能是高可用性最重要的一个级别：复制。同步复制提高了集群的容错能力，不会丢失数据。这反过来提高了节点故障时的可用性。在单体数据库中，数据库管理员在逻辑复制和物理复制之间犹豫不决。

其他比较

例如，Amazon RDS将磁盘块更改流式传输到备用站点。Oracle Data Guard将重做向量与文件和块更改一起流化。PostgreSQL发送WAL，通常作为完整块。这有许多优点：在复制副本中接收到相同的数据库，在故障转移到该数据库时具有相同的性能。然而，它缺乏我们在云原生环境中所需要的灵活性。

逻辑复制提供了所有灵活性：跨不同平台、不同区域，甚至可以只过滤数据库的一部分。您还可以梦想双向复制。这是pos

逻辑复制提供了所有灵活性：跨不同平台、不同区域，甚至可以只过滤数据库的一部分。您还可以梦想双向复制。这是可能的，因为您复制逻辑操作，并在拥有相同的逻辑模式时应用它们。然而，当应用于查询处理层时，您复制的语句非常复杂，涉及多个表、索引和事务。这给复制软件和数据库管理带来了巨大的复杂性。这是因为多行和多表操作将存在冲突，并且不会与源中的操作同时应用。

象Oracle GoldenGate这样的解决方案可以处理这些冲突，但这始终是一个复杂的项目。这就是YugabyteDB找到正确平衡的地方。在DocDB级别，存在复制到运行不同版本软件的节点的逻辑操作。但没有冲突，因为分片已经在上游完成，每个tablet在不同节点上有其对等的tablet。SQL查询和事务的所有复杂性已经被查询处理层分解为更简单的操作。这使得逻辑复制更简单、自主、安全，与物理复制一样可靠，也与逻辑复制（数据库层面）一样灵活。

结论

YugabyteDB的两层架构是分布式SQL数据库的真正创新。因为它们是单节点的，所以传统数据库的SQL执行器以存储在硬盘上的相同格式读取和写入数据块。然后，通过复制这些块增加了高可用性。