什么是分布式SQL？

什么是分布式SQL？

Hudson 译 原文

近四十年来，SQL一直是关系数据库（又称RDBMS）的事实上的语言。因此，关系数据库也称为SQL数据库。然而，从体系结构的角度来看，原始的SQL数据库，如Oracle、PostgreSQL和MySQL是单体结构的。它们无法在多个实例之间自动分发数据和查询。NewSQL数据库的出现使SQL具有可伸缩性。然而，它们也不得不引入一些痛苦的妥协。

自2015年出现Docker容器和Kubernetes编排以创建灵活、可组合的基础设施以来，基于微服务的应用程序一直在上升。内置扩展、弹性和地理分布的云原生原则是这一架构转变的核心。引入称为“分布式SQL”的新数据库类的时机已经成熟。分布式SQL数据库的定义特征是，整个数据库集群（不管其中节点的数量）对应用程序而言是单个逻辑SQL数据库

数据库体系结构

分布式SQL数据库具有三层体系结构。

1.SQL API

从名称可以明显看出，分布式SQL数据库必须具有SQL API，以便应用程序对关系数据建模，并执行涉及这些关系的查询。这些数据库特有的典型数据建模结构是索引、外键约束、连接查询和多行ACID事务。

2.分布式查询执行

查询应该自动分布在集群的多个节点上，这样就不会有单个节点成为查询处理的瓶颈。集群中的任何节点都应接受查询请求，然后请求其他节点以最小化延迟处理其部分查询，这包括通过网络在节点之间传输的数据量。然后，接受请求的原始节点应将聚合结果发送回客户端应用程序。

3.分布式数据存储

包括索引在内的数据应自动分布（也称为分区）在集群的多个节点上，这样就不会有单个节点成为瓶颈，确保高性能和高可用性。此外，数据库集群应支持强一致性复制和多行（即分布式）ACID事务，以确保单一逻辑数据库概念。

强一致复制

支持强大的SQL API层本质上要求底层存储层建立在跨数据库集群节点的强一致性复制之上。这意味着对数据库的写入将在多个节点上同步提交，以保证故障期间的可用性。读取应服务于最后提交的写入或错误。该特性通常称为线性化能力. 根据著名的CAP定理，可以将分布式SQL数据库分为两类：一致和分区容忍。

分布式ACID事务

数据库存储层还应支持分布式ACID事务，其中需要跨位于多个节点上的多行进行事务协调。通常，这需要使用二阶段提交（2PC）协议。隔离级别代表ACID中的I，表示数据库对于并发数据访问的严格程度。分布式SQL数据库应支持可串行化作为最严格的隔离级别以及其它较弱隔离级别，例如快照。

商业利益

上述架构带来了四个关键好处。

1.开发人员对SQL和事务的敏捷性

尽管像Amazon DynamoDB、MongoDB和FaunaDB这样的NoSQL数据库开始使一些操作具有事务性，但应用程序开发人员仍然将SQL数据库放在他们的核心位置。这种密切关系的原因之一是SQL作为一种数据建模语言的固有能力，它可以轻松地建模关系和多行操作。例如，SQL超越了传统的键值NoSQL，允许隐式（使用二级索引、外键和连接查询）和显式（使用BEGIN始和END TRANSACTION语法）声明多行事务。更重要的是，开发人员喜欢利用SQL只对数据建模（和存储）一次，然后在业务变动时通过简单地更改连接来更改查询。

2.具有本地故障切换/修复功能的超弹性

现代分布式系统通常依赖于Paxos或Raft分布式共识，以确保在遇到随机故障时的恢复能力。“基于共识的复制如何在分布式数据库中工作？” 揭示了这种复制算法在实践中的工作方式。分布式SQL数据库在每个分区别应用分布式共识，以确保每个分区（而不仅仅是每个实例）在出现故障时保持高度可用。基础设施故障总是只影响数据的一个子集（只影响那些领导者被分区的数据），而不会影响整个集群。而且，考虑到剩余分片副本能够在几秒钟内自动选择新的领导者，集群会自我修复，从而在出现故障时表现出自愈特性。应用程序对这些群集配置更改保持透明，并继续正常工作，不会出现中断或性能下降。

3.具有水平写入可伸缩，按需扩展

探索分布式SQL数据库如何实现自动数据分片. 当添加新节点或删除现有节点时，分片在所有可用节点之间保持自动平衡。需要写可伸缩性的事务性应用程序实现的微服务现在可以直接依赖于数据库，而不是添加新的基础设施，如内存缓存（将读取请求从数据库中卸载，以便可以保留来处理写请求）或者一个NoSQL数据库（写可伸缩但放弃ACID保证）。

4.地理数据分布的低用户延迟

正如“构建低延迟、云原生、地理分布的SQL应用程序的9种技术”文章中揭示的那样，分布式SQL数据库可以提供广泛的技术来构建地理分布的应用程序，这些应用程序不仅有助于自动容忍区域故障，而且通过使数据更接近本地区域，降低最终用户延迟。

YugabyteDB独特之处

YugabyteDB遵循前面描述的总体分布式SQL体系结构，因此也具有如上揭示的优势。此外，与其他分布式SQL类别不同， YugabyteDB具有以下三个优势。

1.低总体拥有成本，高性能

DocDB 是YugabyteDB基于RocksDB的分布式文档存储，用C++编写。感谢DocDB背后的性能工程，YugabyteDB非常适合需要低延迟查询（如零售产品目录等分布式OLTP应用程序）或高容量数据摄取（如物联网分析平台）的应用程序。YugabyteDB使用比其他分布式SQL数据库更小的集群为此类应用程序提供服务。此外，每个YugabyteDB节点都可以存储数TB的数据，而不会牺牲整个数据库集群的水平写可伸缩性的核心承诺。“比较分布式SQL性能——YugabyteDB与Amazon Aurora PostgreSQL和CockroachDB”测试了YugabyteDB的性能特性，与分布式SQL类别中的其他两个数据库进行了比较。

2.云中立，Kubernetes原生

今天的软件组织将云中立和多云设计模式视为以无与伦比的速度构建和管理应用程序的自由。Kubernetes驱动的容器化应用程序编排是实现这种设计模式的一种行之有效的方法。然而，有状态事务性数据库（应用）是Kubernetes中运行的最复杂的工作负载之一。Kubernetes Pod的短暂特性以及不断需要将它们重新调度到新的Kubernete主机上要求底层数据库层也变得同样灵活。否则，应用程序将出现中断、性能下降，最糟糕的是，数据丢失和错误结果。YB Master，YugabyteDB内置的配置管理服务，通过不断监控并重新平衡可用节点上的数据分片，即使在高度动态的环境（如Kubernetes集群）中，也保证应用程序不会遇到这种情况。

3.开源的高发布速度

今天的数据库项目越来越多地转向专有软件,从而打破了社区的信任，而YugabyteDB却自豪地走上了完全相反的道路，YugabyteDB在Apache 2.0宽松的开源许可下发布了整个数据库。“为什么我们将YugabyteDB许可更改为100%开源” （这篇文章）揭示了这种哲学背后的原因。最终结果是，用户可以利用高级数据库功能（如分布式备份、更改数据捕获、双区域部署、静态加密等）更快地更自由地构建和发布业务关键型应用程序。 而且如果（用户）需要自我管理(的数据库）或者完全管理的数据库即服务来进一步简化企业操作，可以考虑商业产品Yugabyte平台和Yugabyte云。

比较分布式SQL数据库

现在，我们已经明确了用户应该从他们选择的分布式SQL数据库中需要获得的七个好处，让我们比较五个这样的数据库与这些期望的好处的表现。我们选择了五个数据库进行比较：亚马逊Aurora、谷歌云Spanner、PingCap的TiDB、CockroachDB和YugabyteDB。前两个是专有的托管数据库服务，而后三个是云中立项目。

亚马逊Aurora

亚马孙 Aurora自2015年开始正式提供，它基于专有的分布式存储引擎，可跨3个可用性区域自动复制6份数据副本，以实现高可用性。从API的角度来看，Aurora与PostgreSQL和MySQL在协议层都是兼容的。正如“亚马逊Aurora揭秘：quorums和相关故障”一文中所述，Aurora 基于6个副本的仲裁写入方法比传统的主从复制具有更好的可用性和耐用性。默认情况下，Aurora运行在一个单主配置中，其中只有一个节点可以处理写请求，所有其他节点都是只读副本。如果写入器节点不可用，则故障转移机制将其中一个只读节点提升为新写入器。

多主配置最近添加到Aurora MySQL（在Aurora PostgreSQL上还不可用）中，用于将写操作扩展到第二个节点。然而，由于所有数据现在都存在于两个节点中，因此对两个节点上相同数据的并发写入可能导致 写入冲突和死锁,应用程序必须处理的这类错误。一长串限制包括无法扩展最初两节点写入(至更多节点)，以及缺乏跨多个区域的地理分布写入。

谷歌云Spanner

Spanner是谷歌的全球分布式SQL数据库，为其许多关键业务属性提供支持，如AdWords、Apps、Gmail等。谷歌从2007年开始构建Spanner，首先是作为一个事务性的键值存储，然后是一个SQL数据库。Spanner系统的一个子集于2017年在谷歌云平台上公开，也就是Google Cloud Spanner的专有托管服务。Cloud Spanner提供了一个专有的SQL API，它既不与任何其他开源SQL数据库兼容，也不支持传统的关系数据建模结构，如外键约束。然而，使用谷歌专有的TrueTime原子钟，Spanner能够保证一个称为外部一致性的隔离级别,该隔离级别甚至比标准的串行性隔离级别更严格。

TiDB

PingCap的TiDB是一个基于TiKV的MySQL兼容分布式数据库，其设计灵感来自Google Spanner和Apache HBase。虽然它的分片和复制架构类似于Spanner，但对于多分片事务，它遵循了非常不同的设计。如 “以Google方式实现分布式事务：Percolator vs. Spanner” 文中所述，TiDB使用Google Percolator作为其多分片事务设计的灵感。这一选择基本上使TiDB不适合地理分布式写入的部署，因为随机访问OLTP工作负载中的大多数事务在从全局的授时机制获取时间戳时需要经历较高的WAN延迟，因为这些授时机制运行在不同的区域。此外 ，TiDB缺乏对关键关系数据建模结构的支持，如外键约束和串行化的隔离级别。

CockroachDB

CockroachDB是一个与PostgreSQL兼容的分布式数据库，使用Raft和RocksDB构建，在分片、复制和分布式事务方面受到了Google Spanner的启发。API层是PostgreSQL查询层的重新实现，导致功能深度损失。例如，不支持部分索引、存储过程和触发器。此外，CockroachDB最近放弃了其开源原则，其核心数据库需要在专有源代码 BSL 1.0许可证下重新授权， 限制了其自由使用。最后但并非不重要的一点是，免费版不包括一些高级功能如分布式备份和变更数据捕获等，需要商业许可。