2020年现在的NewSQL是指的哪些东西？

2 年 ago

清, 扬

3 minutes

免责声明

该文章是个人根据NewSQL开发供应商的技术博客、各种论文以及其他新闻网站的内容进行总结的。因此，可能包含了因理解不足而引起的误解或错误识别。如果需要进一步了解，请直接参考所列的各种参考文献。如果可能，我们将尝试吸纳和修正技术指摘，但无法保证快速的回应。

对于NewSQL，解释分为两个部分。

本文是NewSQL的概述部分，这是前篇。
目录如下：

NewSQL组件详解

本文将解释第一章到第三章的内容。
第四章将进行更详细的技术解释，并在后续的“NewSQL的组件详解”中进行描述。

我也希望您一并阅读这部分内容。

1. 什么是NewSQL？

NewSQL是新形式的SQL数据库，经常被海外媒体提及，具有可扩展和分布式架构等RDBMS之前没有的特点。
其名称让人联想到以往流行的NoSQL(Not Only SQL)，其架构和事务处理方式旨在融合传统的RDBMS和NoSQL的优点。

在2011年4月的INFOQ文章《NoSQL，NewSQL以及其他》中，对当时的数据库管理系统进行了分类，如下图所示。

在这张图中，左侧大部分描绘了非关系型数据库，并且可以看出其中大部分是被称为NoSQL的软件。尽管像Redis、MongoDB和Cassandra这样的数据库仍然存在，但当时的热度已经有所平息的感觉。

然而，在图的右半部分绘制了一个关系型数据库，其中包括了NewSQL。然而，这与目前的情况有很大的不同，现在几乎看不到NewSQL的先驱（如Clustrix和VoltDB）或者仅仅是托管服务类型的NewSQL（如Amazon RDS和SQL Azure），它们混合存在。

1.1. 从Google Cloud Spanner的角度来看，NewSQL的一个完善形态

如果要在2020年目前提及一個代表性的NewSQL服務，那就是Google Cloud Spanner。

2012年发布了名为“Spanner：Google的全球分布式数据库”的论文，并在Google内部使用，但从2017年开始，一般用户也可以使用Google Cloud Spanner。

这篇文章并非针对Spanner的解说，因此请参考这篇文章以获取详细信息，其主要特点主要有以下三点。

トランザクションサポート

同时具备上述特点，通过数据的复制跨数据中心和地区，提高可用性，支持全球业务。

谷歌云Spanner的服务介绍中提到了，“适用于全球和区域应用数据的可扩展的全面托管关系型数据库服务”，虽然有很多英文缩写，但无疑传达了谷歌创建的最强大的关系型数据库服务。

据估计，Spanner在国内甚至在严苛的支付服务等应用案例中已经被使用，并且预计将有更多的企业和服务选择继续使用它。

为什么需要Spanner？

稍后会详细说明。

传统的关系型数据库现在已经达到了可扩展性的极限，往NoSQL上搭建复杂的应用程序比想象的更加困难。

这可能是主要的原因。

以前，人们通过在RDBMS中使用读写副本和类似Redis的内存KVS来提高读写性能的扩展性。然而，由于复制延迟和写入延迟等原因，存在着数据一致性无法保持的时机，对于复杂的配置是否值得付出的疑问依然存在。

因此，在需要更強的可擴展性（尤其是寫入壓力較大的）用例中，有時會使用像Cassandra等NoSQL的資料庫。然而，在這種情況下，一致性不再是資料庫的責任，而是需要在應用程序方面進行最大程度的考慮。

目前需要的是可以同时进行读写且具有可扩展性的数据库，同时确保数据的一致性，而最接近这一要求的是Spanner。

1.2个Spanner的克隆兴起

正如2011年INFOQ的文章中提到的那样，从那时起，NewSQL领域就已经存在，并且开发出了各种不同的产品。即使在现在，MySQL NDB Cluster也在架构上完全符合NewSQL的特征，此外还有一些其他产品，如VoltDB、FoundationDB和NuoDB等，从当时一直存在至今。

然而，在Spanner发布之后，出现了一些以与以前不同的方式实现NewSQL的产品。
在本文中，我们将介绍一些类似Spanner的数据库（可以称之为Spanner克隆）的三个产品。

YugaByteDB

这些数据库基于Spanner，采用了稍微不同的设计思想和技术要素，提供了具有强一致性和支持ACID事务的分布式SQL数据库（全球范围）。

这些供应商声称，通过使用这些产品，即使不是Google Cloud用户，也可以构建类似Spanner的数据库基础设施，从而实现更高效和灵活的应用程序开发。

这些NewSQL的共同之处或部分不同的架构将在第2章以后详述。

1.3 个扳手的缺点和改进方法

尽管Spanner作为一种可用的NewSQL方案在目前是理想的，但它当然也不是毫无缺点的。首先，在地理上分布的环境中，具备强一致性并支持事务本身就并不容易。

从学术角度来看，Calvin经常与Spanner进行比较。Calvin也在2012年发表了一篇名为《Calvin: Fast Distributed Transactions for Partitioned Database Systems》的论文。

我想要在另一篇文章中详细讨论事务，并减小Spanner和其克隆产品中的Paxos和Raft通信的开销，以实现保证一致性和性能的目的。
Calvin和其变种的研究正在持续进行中，可以说它已经成为分布式数据库的一个流派。

此外，FaunaDB是以Calvin为基础提供的数据库服务。由于它不是基于SQL，所以它不在本次的NewSQL范畴内，但它是一个非常有趣的服务。

1.4 到目前为止的总结

自2012年Spanner的发布以来，NewSQL的趋势发生了变化。

截至2020年，NewSQL的定义如下：
NewSQL是一种具有强一致性且支持ACID事务的(全球范围的)分布式SQL数据库。

2. 新SQL的架构

NewSQL将传统的关系数据库管理系统中的各个组件进行分割，为每个组件提供可扩展的配置。

此外，一个重要的特点是该系统采用了多主模式。这并不是说有一个服务器作为主服务器，其他服务器作为次要服务器或只读服务器，而是集群中的所有服务器都作为主服务器运行（确切地说，有一点不同，但会在第三章以后详细介绍）。

总体来说，它具有以下3个组件，并且每个产品在如何将它们部署到服务器上方面的设计理念都有些微差异。

ストレージエンジン(分散ストレージ)

2.1 Spanner的架构

这篇博客详细介绍了Spanner的架构。

Spanner是一个能够管理高达2TB数据的节点（Spanner Server）和分布式存储系统Colossus。客户端可以通过gRPC或REST API与节点进行连接，每个节点不保存实际数据，而是通过网络访问分布式存储系统来获取数据。根据论文，Spanner Server包含查询引擎和事务管理器，而Colossus负责分布式存储层（在论文中被称为Tablet，而不是Split）。

每个节点都有三个副本，节点之间的复制是通过Paxos算法来实现的。根据这篇博客的写作时间，目前只有美国地区可以进行读写操作，而亚洲地区等地只能进行只读操作（当前情况尚未调查）。

在关系数据库（RDB）中，表被分割成Sharding中称为shard的单元。这些shard由任一节点进行管理。

由于Split的分布情况对于Spanner的性能有着重要的影响，因此对于定义Split的设置成为了重要的设计要点。

（2020/3/2追記）
据文档记载，Spanner当然可以通过SQL操作，并且支持ANSI2011标准的扩展SQL。

2.2 YugabyteDB的Spanner克隆架构。

尽管YugaByteDB沿袭了Spanner的设计理念，但其组件布局与原始设计有所不同。

以下是YugaByteDB的体系结构图。虽然SQL查询引擎、分布式事务管理器和存储引擎在层面上是独立的，但它们在集群内的节点上均以统一的方式进行配置。

换句话说，与Compute节点通过网络访问分布式存储不同，每个节点都有本地存储引擎（称为基于RocksDB的DocDB），上层应用将访问这些引擎。

数据的复制是在节点之间进行的，因此从整体上看，它扮演着分布式存储的结构，但这种紧密度是与Spanner的最大不同之处。

对于那些不能像Google Cloud一样提供大规模分散存储的普通用户而言，这看起来是一种合适的方法，但也可能存在无法分别扩展计算和存储的问题。

(2020/3/2追記)
除了具备SQL查询引擎外，YugaByteDB还拥有键值查询引擎。SQL API被称为YSQL，目前与PostgreSQL11.2兼容。键值类型的API被称为YCQL，基于Cassandra查询语言（CQL）进行开发。

2.2.1 蟑螂数据库

CockroachDB采用与YugaByteDB相同的集群结构，将三个组件紧密耦合并部署在多个节点上。

CockroachDB与YugaByteDB的区别在于，CockroachDB通过将3个组件打包成一个二进制文件。这取决于设计思想，它可以是一个二进制文件（进程）或者是多个二进制文件，但两家供应商都声称它们的架构具有优势。

(2020/3/2追記)
CockroachDB和YugaByteDB一样，也与PostgreSQL兼容。根据这篇文档，截至2020年2月，明确指出CockroachDB与PostgreSQL 9.6兼容。

2.3 Spanner克隆的架构: TiKV/TiDB

关于 TiDB，它与之前介绍的 CockroachDB 和 YugaByteDB 的结构有相当大的区别。
这是因为，前述的两个 Spanner 克隆是将 SQL 查询引擎和存储引擎紧密结合，并部署在集群中的节点上，而 TiDB 则采用了类似 Spanner 的结构，将计算节点和分布式存储分离。

这张图展示了TiDB的架构。从这张图中可以看出，TiDB只是TiKV分布式键值存储的生态系统的一部分。

TiKV几乎完全实现了作为分散数据库的功能，TiDB仅仅提供MySQL接口，并提供对底层分散存储引擎（即TiKV）的访问。

（2020/3/2附注）
关于SQL查询引擎，TiDB与前述的两个Spanner克隆不同，它是兼容MySQL的。
根据文档，目前它是兼容MySQL5.7的。

2.3.1 TiKV
2.3.1 TiKV

那么，让我们更详细地了解一下TiDB的组成部分之一，即TiKV。

TiKV本身不具备SQL接口。在下图中展示的TiKV架构中，若被用作TiDB的后端，图中的Client将是TiDB，并在此处向真正的客户端提供与MySQL兼容的SQL接口。

上述的TiKV节点具有事务管理器和存储引擎，可以在分布式的Raft Group内部对数据进行复制。
存储引擎类似于CockroachDB，使用RocksDB。

然後，在這張圖中，存在著其他Spanner克隆所沒有的PD（存放驅動程式）這個元件。這個PD是TiKV的叢集管理器，用於管理數據的配置。同時，在事務處理中，還有一個重要的時間戳Oracle（TSO）也存在於這裡（TSO本身的說明將在稍後的另一篇文章中提供）。

由于这个PD组件非常重要，所以它本身也采用了Raft冗余机制（这种架构在前面的TiDB架构中有详细描述）。

2.4 总结至此

Spannar及其克隆体通过将之前整合在单一数据库中的组件进行分割，并采用可扩展的架构。

Spanner使用SQL查询引擎和事务管理器，并将存储分散在网络上进行访问。
YugaByteDB和CockroachDB将三个组件放置在节点上，并通过组合它们来实现扩展性。
TiDB/TiKV与两者都不同，它通过组合无状态SQL查询引擎TiDB和分布式KVS TiKV实现了类似Spanner的架构。

3. 将NewSQL与传统数据库进行比较。

为了比较NewSQL与之前的数据库有什么不同，我们将整理单体式关系型数据库(RDBMS)和NoSQL(Cassandra)的特点。在整理的过程中，我们将使用Spanner的特点(在前述的3个特点之外还添加了可扩展性)。

分散可能性、スケーラビリティ

此外，(尽管已经成为陈词滥调) 有趣的一点是，我们希望达到CAP定理中的哪个条件。

3.1 原生RDBMS的特点

在这里，我们考虑的是Oracle Database等专有软件，或者像PostgreSQL和MySQL这样的开源RDBMS。基于历史原因，单体式的RDBMS具有以下优缺点。

【优点】

ノードローカルな環境下で”妥当な”整合性(RC、RR) を実現。

【缺点】

ネットワーク分断に弱い。低遅延・高信頼なネットワークを前提とする。

单一中心化的关系数据库管理系统（RDBMS）对于水平扩展性较弱，通常采用纵向扩展的方式进行扩展。此外，运维通常只考虑单个数据中心（或者单个机架），即使采用了高可用性（HA）结构，节点之间的互连也需使用低延迟、高可靠性的设备。

换句话说，通过限制可扩展性，可以在其范围内取得一种平衡，包括一致性、可用性和性能等。

从CAP定理来说，可以说单体式RDBMS是AC的。

3.1.1 关系数据库管理系统（RDBMS）是否没有可扩展性？

在讨论传统关系型数据库管理系统的缺点之前，为了公正起见，我认为我们也需要提及一下关系型数据库管理系统的水平扩展方法。

如果以多个地区或地理分散为前提，关系数据库管理系统(RDBMS)很难实现水平扩展，并且只在有限的条件下(过去通常存在的条件)才存在开发RDBMS扩展技术的可能性。

3.1.1.1 复制

最常用的RDBMS的扩展方法应该是复制。它已经集成到许多DBMS中，并且使用起来也很容易。

以下是显示了PostgreSQL的流复制配置的图表，如此通过从主节点（图中的M）向多个从节点（S）传输日志（WAL）以实现数据同步。

上图中的Master节点可以处理Read和Write操作，而Slave节点只能处理Read操作。
换句话说，这种复制形式只能实现Read查询的可扩展性。

在同期模式下，访问Slave节点时所见的数据会有差异，完全同步（即Master的Commit需要等待Slave的数据Commit）会影响可用性和性能，因此往往采用准同步（即Master的Commit需要等待将日志传输到Slave完毕）的方式。

除了通过物理日志传输（如重做日志或WAL）进行复制外，许多数据库管理系统还支持通过SQL级别实现的逻辑复制来实现同步，但是这种方法也会导致与上述相似的数据同步滞后。

此外，就可用性而言，当Master节点发生故障时，会出现Slave节点的晋升（即所谓的FailOver），但也有人对此时的停机时间表示担忧。作为解决方案，后文中提到的多主节点方案也被采用。

3.1.1.2 分片

另一种古老的扩展关系数据库管理系统（RDBMS）的方法是分片。

这是一种在NewSQL中采用的技术，它将数据分散到许多节点上，并通过连接它们来展示一个逻辑上巨大的数据库。最近，它被应用于CNCF的Graduated Project，如Vitess和Azure HyperScale（Citus），再次引起了关注。

下图展示了Vitess的架构图，其中Sharding中存在一个接受所有SQL请求的协调节点（图中的V）。通常的数据库实例位于该节点下方从属，并且每个实例只保存分配给自己范围内的数据。

只有与读/写相关的实例才会被发送，通过将数据范围细分并增加实例数量，可以实现水平扩展的可扩展性。

在中国的本土意思里，你可以这样表达：

在一个方面，问题在于Coordinator部分的可用性和扩展性。
在图表中，这是一个单点故障（SPOF），因此在实际运营中经常使用高可用性（HA）配置，但仍然会发生故障转移，就像复制一样。
实际的数据处理由下层实例负责，但是协调器负责处理多个实例数据的聚合等处理，因此在性能方面可能成为瓶颈。

此外，Sharding的最大問題可能在於數據設計的複雜性。要根據應用程序的訪問模式適當地分割和配置數據，以提高性能，最理想的情況是將所有操作限制在單個實例中，並封閉在事務範圍內。這一點說起來容易，但實際執行起來非常困難。

3.1.1.3 多主控制

与复制和Sharding相比，构建和运维难度较高的是多主数据库集群。

作为个人观点，目前最为流行的多主数据库集群应该是Oracle的RAC（Real Application Cluster）。尽管有很多异议。

以下是Oracle RAC的配置图像，通常来说，RAC是被称为”共享磁盘型数据库集群”的。

这篇文章不会提供Oracle RAC的详细技术解释，但是作为构成的一部分，用于持久化数据的存储只有一个（在逻辑上），并且在较高级别的节点之间采用同步数据库缓冲区（即内存）的方式。这样一来，任何节点都可以处理读/写操作，并且通过增加节点可以实现横向扩展。

然而，需要注意的是，为了实现缓冲区同步，需要快速稳定的互连，并且在扩展到大约10台服务器之后，无法实现分布式SQL数据库在超过100台规模上的技术。

同样，在可用性方面，当节点发生故障时，会进行称为RAC重构的处理，这将花费相当长的时间。共享存储目前也使用了诸如ASM等技术，不再是单一故障点，但这也是一个引起可扩展性担忧的方面。

MySQL也支持被称为Group Replication的功能，它允许多主模式。然而，与RAC相比，这个功能更加受限，重点不是性能方面，而是用于避免在故障转移时的可用性降低的技术（由于我的MySQL知识有限，故详细情况不做赘述）。

3.2 NoSQL的特点

由于我缺乏关于NoSQL的全面解释知识，因此在这里我将以Cassandra为例，回顾其特性。同时，由于我对于Cassandra的解释可能基于一些过时的知识，所以如果有最新的情况，请在评论中指出。

3.2.1 卡桑德拉

【优势】

ネットワーク分断があっても何らかの形で動き続ける、高い可用性を持つ。

【缺点】

整合性はEventual Consistencyと言われるもので、ほぼ何も保証ができないに等しい。

Cassandra以多主结构实现，并能在每个节点上处理读写操作。通过添加节点可以线性提升性能，并具备良好的可伸缩性。
然而，其一致性保证相对较弱，不支持事务处理，因此可能会出现无法读取最新写入数据的情况。使用基于Quoram的读取可以提高一致性，但这会牺牲延迟。

数据会使用一种被称为一致性哈希（Consistent Hashing）的方法在集群内进行分散，同时还会创建多个副本。

总结Cassandra的特点，可以说它符合所谓的CAP定理，即以妥协C为目标构建的AP系统。

3.3 NewSQL的定位

回顾到目前为止的讨论，可以总结如下。

NoSQL(Cassandra)はAP 、整合性を妥協し、可用性とネットワーク分断耐性を高めている。

然而，我们要讨论的是A（可用性）的含义。正如涉及系统的工程师所知道的那样，无论我们多么注意，可用性都无法完全保证。

即使在云盛行的时代，即使建立了Multi-AZ、Multi-Region、甚至Multi-Cloud的架构，也无法避免不可避的故障（即可用性下降）的发生。

因此，在NewSQL中，人们采取了一种在可用性下妥协而不追求完美的态度，追求一致性（Consistency）和分区容错性（Partition-tolerance）。

换句话说，可以说” NewSQL是一个既具备一致性（CP），又具备折中可用性（A）”的设计目标。

3.3.1 NewSQL立足于巨人的肩膀上

在NewSQL中，除了具有传统的单体式关系数据库管理系统（RDBMS）和NoSQL的特点外，还利用了新的技术来支持强一致性和事务。

【优点】

スケーラビリティを高めるためにデータを分散配置: ShardingやNoSQLと同じ考え方

为了进一步提高可用性，我们采取了分片数据的副本，以及类似于多主或Cassandra描述中所见的配置，以消除故障转移的影响。

当A达成妥协时，意味着当超过一半以上的节点宕机时，更新将停止（但Read操作可能仍可继续）。尽管这种情况很少发生，比如数据中心故障或整个区域发生故障，但并非完全没有出现的可能。

3.3.2 NewSQL是否是多主模式？

尽管我们已经提到NewSQL是多主节点的，但我们希望对这一点进行更深入的思考。

以上图表所示的是YugaByteDB对数据进行分片，将每个分片的副本复制到不同的节点上的配置。(有关分片的详细信息，请参考后续的4.2部分)

尽管详细内容将在另一篇稿件中解释，但基本上使用Raft的NewSQL中，只有Raft Group内的Leader（在图中被标为tablet1并列的副本与Raft Group同义）能够处理读取和写入操作。
换句话说，从单个Raft Group的角度来看，NewSQL不能被称为多主策略。

然而，在NewSQL中，由于Shard=Raft Group的设定，存在着多个被分割为固定大小的Raft Group，并且这些Raft Group的Leader分散在各个节点上。换句话说，从多Raft Group的角度来看，它是多主模式的。

在理解NewSQL的过程中，这个Raft Group内的Leader能够进行Read和Write操作，而Follower可以在一些特定条件下进行Read操作，这一特征非常重要。

以下为摘要:

这是摘要的内容。

在本篇文章中，我试图解释NewSQL的起源、发展历程以及现在兴盛的Spanner和其克隆品。

要理解这些NewSQL是为了解决什么问题，就需要理解关系型数据库管理系统（RDBMS）和非关系型数据库（NoSQL）的问题，并在后半部分概括个人的看法。

我认为通过上述内容，清楚地阐明了分布式SQL数据库具有强大的一致性和支持ACID事务的意义，但没有提及具体的实现方法。

在”NewSQL的组件详解”的后半部分，涉及以下内容并进行了更深入的解释。

4. NewSQL组件详解
4.1 存储引擎
4.2 分片
4.3 Raft
4.4 分布式事务

请阅读以下内容：

关于将数据持久化到节点本地（存储引擎），在集群内进行分布式部署（Sharding），并保证冗余性和可用性（Raft），同时保持一致性和同步更新（分布式事务）的分散式SQL数据库的描述。

在这个背景下，我本来应该提到Google BigTable、AWS DynamoDB、Azure CosmosDB、HBase和Kudu等等，但是对于这些我并没有经验，完全没有提及。希望能谅解这一点。

修改历史

2020/3/15 後編「NewSQLのコンポーネント詳解」へのリンクを追加、まとめの内容も後編の目次に更新。