我们对比了5款数据库，告诉你NewSQL的独到之处

译者 | Gokhan Simsek 翻译者 | 盖磊 撰稿 | Natalie AI 第一线编者按：

NewSQL 是一类新形式关系资料库，以图资源整合 RDBMS 所提供更多的 ACID 外交事务优点，及 NoSQL 提供更多的横向扩充性。责任撰稿透过对 VoltDB、TiDB、Cosmos DB、Citus、Vitess 等 NewSQL 资料库的如是说，得出了 NewSQL 的精辟考量。

对绝大多数开发者来说，SQL 和 MySQL、PostgreSQL 等关系资料库信息系统（即 RDBMS）并不孤单。RDBMS 的基本构架准则已历经了几十年的发展。而 MongoDB、Cassandra 等 NoSQL 软件系统，则是在七十年代为满足用户曲线拟合可扩充的市场需求而提出的。

但前段时间一两年他们看到，出现了一个称为 NewSQL 的新路径。

NewSQL 是一类新形式关系资料库，以图资源整合 RDBMS 所提供更多的 ACID 外交事务优点（即氢原子性、连续性、隔绝性和可无毒性），和 NoSQL 提供更多的横向扩充性。听上来 NewSQL 应该吸取了这三个路径各别的特长，像一类轻松的软件系统。那它为什么如今方以求面世呢？

资料库的面世，源于于上世纪七十年代分立标识符与统计数据的市场需求。资料库的起初结构设计如前所述如下表所示考量：

资料库的查阅使用者数非常有限。

查阅类别不受到限制，即开发者可以得出任何所需类别的查阅。

硬体的价格低廉。

在当时，开发者需要透过终端产品输出互动式查阅。有鉴于开发者是惟一能出访资料库的使用者，下面的考量是有象征意义，且有用的。精确性和连续性曾是户最倚重的两个测度，但如今人们更倚重的是操控性和易用性。继而，横向扩充可用于化解不断增加的统计数据市场需求，和考量在资料库迁移或恢复时需移动统计数据的情况下的可承受宕机时间。

下面快进几十年进入当前的互联网和云时代，统计数据库的市场需求已大为不同。统计数据的规模是海量的，而商业硬体比起上世纪要更为便宜。

随着统计数据规模的增长，和如前所述互联网的实时交互无处不在，使用者对资料库的基本市场需求呈现出三个主要的类别，即 OLAP（在线分析处理）和 OLTP（在线交易处理）。

OLAP 资料库通常称为统计数据仓库。它们用于存储供商业智能业务统计和分析历史记录。OLAP 资料库侧重于只读工作负载，其中包括用于批处理的即席查阅。OLAP 资料库的查阅使用者数相对较少，通常情况下只有企业员工可以出访历史记录。

OLTP 资料库用于高度并发的外交事务统计数据处理场景，该场景的特点是实时使用者提交预定义的短时查阅。外交事务处理的一个简单例子，就是普通使用者在电子商务网站上搜索并购买商品。相对于 OLAP 使用者，尽管 OLTP 使用者出访的统计数据集规模很小，但使用者的数量要庞大很多，并且查阅中可以包括读操作和写操作。OLTP 资料库主要考量的是高易用性、并发性和操控性。

在绝大多数 Web 站点上，任一时刻都可能会有成百上千的使用者并发执行有效的查阅。考量到这样的规模，系统必须具备高易用性，因为每宕机一分钟，都可能会导致企业损失数千甚至 上百万美元。

Web 站点上使用者提交的查阅是预定义的，因为使用者无法出访资料库终端产品并执行任意查阅。查阅是存在于应用逻辑中的，这使得他们可以针对高操控性做优化。

扩充性是这一新资料库生态系统中的一个重要测度，而高易用性则对企业的盈利至关重要。NoSQL 资料库得出了一类易于实现扩充性和更好操控性的软件系统，化解了 CAP 理论中的 A（易用性）和 P（分区容错性）上的结构设计考量。但这意味着，在很多 NoSQL 结构设计中实现为 最终连续性，摈弃了 RDBMS 提供更多的强连续性及外交事务的 ACID 属性。

NoSQL 资料库使用了不同于关系模型的模型，例如键值模型、文档模型、宽列模型和图模型等。采用这些模型的 NoSQL 资料库并不提供更多规范化，本身在结构设计上是无模式的。绝大多数 NoSQL 资料库支持自动分区，无需开发者干预即可轻松实现水平扩充。

到统计数据的状态更新、发推文等，强连续性也并非必要的。但，NoSQL 资料库不宜用于对连续性要求高的系统，例如电子商务平台。

NewSQL 系统的提出，正是为了满足用户资源整合 NoSQL 和 RDBMS 优点的市场需求。其中，NoSQL 提供更多了扩充性和高易用性，传统 RDBMS 提供更多了关系模型、ACID 外交事务支持和 SQL。使用者已不再考量一招能化解所有问题（one-size-fits-all）的方案，逐渐转向针对 OLTP 等不同工作负载得出特定资料库。绝大多数 NewSQL 资料库做了全新的结构设计，或是主要聚焦于 OLTP，或是采用了 OLTP/OLAP 的混合构架载的全新结构设计。

传统的 RDBMS 构架从一开始结构设计时并未考量分布式系统，而是在分布式市场需求出现后，才考量在起初的结构设计之添加支持分布式的结构设计。由于 RDBMS 实现了规范化模式，而非 NoSQL 那样的聚合表单，因此 RDBMS 中必须引入一些复杂的概念，才能在支持可扩充的同时保持连续性市场需求。继而，为支持 RDBMS 中的横向扩充，人们提出了手动分片和主从构架。

但，RDBMS 为实现横向扩充而在操控性上做出了很大让步。这是因为连接运算中需要在各个节点间移动统计数据以实现聚合，运算实现代价增大。另外，统计数据维护开销变得更为耗时。为保持 RDBMS 的操控性，一些企业面世了复杂的系统和产品。但当前，人们依然并不认为传统 RDBMS 本身支持可扩充。

NewSQL 资料库为云时代而生，因此它从一开始就考量了分布式构架。

那么 NewSQL 软件系统提供更多了那些精辟优点？

相对于易用性来说，NewSQL 更重视连续性，即侧重 CAP 中的 C 和 P。很多 NewSQL 资料库为提供更多强连续性而牺牲了部分易用性。这些资料库为达成分布式连续性，在全局系统或本地分区层面使用了 Paxos 或 Raft 共识协议。MemSQL 等一些软件系统还提供更多了一致性和易用性之间的权衡调优，支持不同用例的各种配置。

传统 RDBMS 依赖二级存储（即磁盘）作为统计数据存储的介质。常用的二级存储包括 SSD 或 HDD。有鉴于 OLTP 工作负载可将历史统计数据归档到统计数据仓库中，因此并不需要大量的统计数据，只需要最新的统计数据。一些 NewSQL 软件系统使用内存（RAM）作为存储介质。内存出访要比磁盘出访快很多，具体来说，可比 SSD 快百倍，比 HDD 快万倍。

内存软件系统提供更多了更好的操控性提升，因为内存的使用消除或简化了 缓存管理 和重度并发系统。有鉴于内存中保持了全部统计数据（或是大部分统计数据），因此完全没有必要做缓存管理。对于并发来说，不同的实现有不同的软件系统，例如序列化等。

那么如何化解无毒性问题？RAM 本身是非持久介质。一旦掉电，需要持久化的统计数据就会丢失。内存资料库采用了多种形式化解该问题。常用方法包括组合使用如前所述磁盘的非频繁备份、保存状态的日志以实现可恢复性，和对关键统计数据使用非易失 RAM 介质。

下面得出内存资料库的三个重要例子，VoltDB 和 MemSQL。

VoltDB 是一类符合 ACID 优点的内存关系资料库。VoltDB 的架构如前所述 Michael Stonebraker 等提出的 H-Store，一类结构设计用于 OLTP 工作负载的内存资料库。

，例如贸易应用、在线游戏、物联网传感器等 应用场景。为实现高操控性，VoltDB 如前所述 OLTP 准则做了全新的结构设计。

VoltDB 明确以支持存储过程为指导思想，让存储过程更接近于统计数据，因此 VoltDB 支持执行序列化外交事务。为实现序列化外交事务处理，一个外交事务会被切分为一些氢原子外交事务，然后做序列化，并在队列中依次执行。序列化外交事务模式消除了管理并发的开销，进而提高了操控性。VoltDB 还支持即席查阅，操控性优化可受益于存储过程。这非常适合 OLTP 工作负载，因为终端产品使用者并不能执行即席查阅。

ACID 准则中的无毒性，对内存资料库是一个重要问题。VoltDB 采用多种技术实现无毒性，包括 快照、命令日志、K-safety 机制和资料库复制等。这些方法确保 VoltDB 实现统计数据冗余，进而支持统计数据持久化。

如需进一步了解 VoltDB 及其构架，可查看他们前期对 John Hugg 和 Ryan Betts 访谈的播客。

前文曾提及，很多 NewSQL 资料库是完全重新结构设计的。正因为重新结构设计，一些项目希望实现统一支持外交事务处理和工作负载分析的资料库。HTAP（混合外交事务 / 分析处理，Hybrid Transactional/Analytical Processing）一词 由 Gartner 提出。支持 HTAP 功能的资料库提供更多对高级实时分析，进而支持实时业务决策和智能外交事务处理。VoltDB 也提供更多 HTAP 能力，它更侧重于外交事务负载。其他主流 HTAP 资料库还包括 TiDB 和 Google 的 Spanner。

TiDB 是一款来自中国的开源软件系统，它得出了一类兼容 MySQL 的 HTAP 资料库，支持强连续性，并且分布式可扩充。TiDB 实现为分层构架，其中 TiDB 服务器作为无状态计算层出于顶层。底层存储层实现为支持外交事务的键值资料库，称为 TiKV。TiKV 的结构设计受到了 Google Spanner 的启发。

TiDB 层实现监听 SQL 查阅、解析查阅并创建执行计划。查阅进而将按需切分为各个子查阅，并发送给相应的 TiKV 存储。有鉴于 TiDB 层是无状态的，因此该层易于实现扩充。

TiKV 层实现了底层存储层，它是一类使用 RocksDB 作为物理存储的键值资料库。TikV 按区域组织统计数据，各个区域将被存储和复制。为如前所述复制模式实现无毒性和高易用性，TiKV 使用 Raft 共识算法提供更多强连续性。TiKV 的分布本质提供更多了对分布式查阅的支持。

这一计算层与存储层的分立解耦构架，使得 TiDB 可同时提供更多对 OLTP 和 OLAP 强大支持。有鉴于 TiDB 同时支持处理 OLTP 和基本 OLAP 负载，TiSpark 作为一类在 TiKV 上直接运行 Spark SQL 的 OLAP 软件系统，可轻易实现如前所述 TiDB/TiKV 构架的运行。TiDB 本身就具有代价优化器和分布式执行器，可处理 80% 的即席 OLAP 查阅。

TiSpark 针对复杂 OLAP 查阅做了一些优化。和 TiDB 层类似，TiSpark 也是一类无状态计算层，并与 TiKV 层交互。TiSpark 在结构设计上就是透过与 Spark SQL 的交互去处理复杂 OLAP 查阅。因此，同时部署 TiDB 和 TiSpark 可消除 ETL 的代价，得出一类同时支持分析和外交事务市场需求的统一软件系统。

要了解 TiDB 及其构架的更多信息，可查看 他们近期对 Kevin Xu 关于 TiDB 的访谈。要进一步了解支持 TiKV/TiDB 的统计数据物理存储 RockDB，可查看 他们对 Dhruba Borthakur 和 Igor Canadi 关于 RocksDB 的访谈。要深入了解 TiKV，可查看 他们对中国开源项目的报道。

微软的 Azure Cosmos DB 提供更多了多种可调优优点，是一类高度灵活的软件系统，可透过调整适合多类用例。他们认为 Cosmos DB 也是 NewSQL 资料库。

Cosmos DB 是一类分布于全球的 多模型统计数据库 服务。作为多模型服务，它的底层存储模型支持键值、列存储、文档和图资料库，并支持透过 SQL 和 NoSQL API 提供更多统计数据。

就全球分布来说，Cosmos DB 在位于全球的多个统计数据中心保存统计数据备份，确保了可靠性和高易用性。开发者可以创建备份，并透过几个基本的 API 调用实现统计数据的横向扩充。

Cosmos DB 在结构设计上考量了降低资料库管理的代价。它无需开发者操心索引或模式管理，自动维护索引以确保操控性。

Cosmos DB 提供更多 多个连续性层级，支持开发者在确定所需的适用 SLA 上做出权衡。除了两种极端的强连续性情况和最终连续性之外，Cosmos DB 还一并提供更多了另外五个良好定义的连续性层级。每个连续性层级提供更多单独的 SLA，确保达到特定的可用和操控性层级。

作为微软这样的技术和云巨头所提供更多的产品，Cosmos DB 易于开发者使用，对操控性、易用性和连续性提供更多了全面的保证。

NewSQL 也可以透过增强现有的 RDBMS 实现扩充的功能，无需完全重新结构设计资料库。这样的软件系统实现在经实战验证的 SQL 资料库之上，增强了现有资料库的功能。该理念对于那些现有系统运行良好而不愿意迁移到新资料库软件系统的大型企业是非常有用的。

一个很好的例子，就是构建于 PostgreSQL 上的 Citus。

Citus 由近期被 微软并购 的 Citus Data 开发维护。它是一款开源 PostgreSQL 扩充，透过透明分布式表和查阅支持横向扩充，进而支持分布式 PostgreSQL。

在 Citus 集群中，资料库表是分布式的。资料库表被水平分区到不同的工作节点上，在使用者看来与常规资料库表并无二致。Citus 使用一类维护了资料库表元统计数据的协调器掌握 PostgreSQL 节点的工作情况，处理查阅，并将查阅并行化到适当的表分区。

Citus 为 PostgreSQL 添加了查阅路由、分布式表、分布式外交事务和存储过程等优点，管理了大量的底层细节，进而实现了水平可扩充、高操控性的 PostgreSQL。

要了解 Cirus 的更多细节，可查看 他们就 PostgreSQL 扩充对 Ozgun Erdogan 的访谈，和 就 Postgres 分片对 Marco Slot 的访谈。

相对于 Citus 是如前所述 PostgreSQL 构建的，Vitess 在结构设计上考量对 MySQL 做出改进，满足用户 MySQL 适用于云时代的市场需求。

Vitess 起初是由 Youtube 在 2011 年为适应自身扩充市场需求而构建的。随着使用者和统计数据的增长，Youtube 必须要进行水平扩充和分片，继而创建了 Vitess 化解透明扩充的问题。现在 Vitess 已经开源，由 CNCF 管理。Vitess 被认可为是一类云原生技术，提供更多了 多处 MySQL 改进。

首要改进就是引入了多种分片模式。使用者可以创建自己的分片模式，Vitess 负责依模式组织分片和统计数据。Vitess 也支持自动分片，无需手工运行标识符，并支持只读宕机时间最小化的实时重分片。

分片是透过 V 索引（Vindex）和键空间（keyspace）技术实现的。其中，主 V 索引（Primary Vindex）类似于资料库索引模式中的主键索引。使用者可以指定需要建立主 V 索引的属性，和如前所述 V 索引的统计数据分片数量。在对资料库分片后，如前所述键空间的查阅可被导向到相应的分片。

Vitess 的构架 使用 vtgate 提供更多负载均衡和查阅路由。vtgate 是一类无状态层，可轻易地上下扩充。vtgate 将查阅路由至为分片提供更多代理的 vtable，并返回聚合结果给 vtgates。

当部署到 Kubernetes 等集群编排工具上时，Vitess 依然提供更多上述优点。由于 vtgates 是一类无状态代理，因此适合于部署到容器集群上。这时 Vitess 使用 lockserver 或 etcd 作为元统计数据存储，处理模式定义等管理工作。

Vitess 用 Go 语言实现。利用 Go 对并发的良好支持，它支持对数千连接的处理。

NewSQL 生态系统正在持续增长和演进。他们无法得出一个能描述全部 NewSQL 资料库的通用定义，或是提出一些通用的特征。但在 NewSQL 概念下提出的多种资料库结构设计，为开发者提供更多了针对不同用例的多种选项。人们不再寄希望于得出适用于所有用例的单一构架，NewSQL 推动了创新和专业资料库结构设计的发展。

Gokhan 是一名计算机科学研究生，目前就读于埃因霍温技术大学统计数据科学专业。他的兴趣包括大统计数据、NLP 和机器学习。

查看英文原文：

What Is New About NewSQL?

https://softwareengineeringdaily.com/2019/02/24/what-is-new-about-newsql/

你也「在看」吗？👇