共计 15501 个字符，预计需要花费 39 分钟才能阅读完成。
本文选自 Andrew Pavlo（卡内基梅隆大学计算机科学系副教授）和 Matthew Aslett（451 研究所副总裁）在 2016 年所发表的论文 What’s Really New with NewSQL。以下内容为伴鱼技术团队翻译，录信数软进行了二次整顿和编辑。
摘要
近年来呈现了一种称为 NewSQL 的新型数据库管理系统（DBMS），它们号称有能力扩大古代在线交易解决（on-line transaction processing,OLTP）零碎的工作负载，这对于以前的零碎来说是无奈做到的。
鉴于传统的 DBMS 曾经倒退了近 40 年，有必要认真斟酌一下 NewSQL 的劣势是真如他们所说，还是仅仅是一种商业宣传行为。如果真的能够取得更好的性能，那么下一个问题天然就是它们是真的有技术冲破，还是仅仅因为硬件方面的倒退使得原来的问题已不再是瓶颈？
为了探讨这些问题，咱们先探讨了数据库的倒退历史，以此了解 NewSQL 呈现的背景和起因。而后从一些细节方面深刻探讨了 NewSQL 的概念，特点，分类，以及在各个分类上面的 NewSQL 零碎。
一、数据库管理系统（DBMSS）的简要倒退历史
世界上第一个数据库系统，IBM IMS 诞生于 1966 年，它被用于存储土星五号 (Saturn V) 和阿波罗 (Apollo) 空间摸索我的项目所需的整机和供应商信息。IMS 的次要奉献在于展现了“利用程序逻辑与数据操作逻辑应该拆散”的理念，应用程序开发者只须要关注数据的逻辑变动，而无需关怀其具体实现。在 IMS 之后，呈现了第一批关系型数据库，其次要代表就是 IBM 的 System R 零碎以及加州大学的 INGRES，即 PostgreSQL 的前身。INGRES 迅速在其它大学的信息系统中流行起来，并于 70 年代末商业化。大概在雷同的期间，Oracle 采纳相似 System R 的设计，开发并公布其 DBMS 的第一个版本。在 80 年代初期又涌现了一批公司，它们也推出本人的商业化数据库产品，如 Sybase 和 Informix。在 System R 之后，IBM 在 1983 年公布了新的关系型数据库 DB2，后者复用了 System R 的局部代码，但二者至今未开源。
从 80 年代末到 90 年代初，面向对象的语言开始风行，这也催生了一批面向对象的 DBMS 诞生，以期磨平数据库模型与语言之间的隔膜。然而因为没有相似 SQL 一样的标准接口，这些面向对象的 DBMS 始终没有在市场上被宽泛承受，不过它们的一些设计理念逐步被交融进关系型数据库，许多风行的关系型数据库都减少了对 Object、XML 和 JSON 数据的反对。除此之外，面向文档 (document-oriented) 的 NoSQL 数据库也或多或少是面向对象的 DBMS 的延长。
90 年代的一个大事件就是两个开源关系型数据库的公布，MySQL 和 PostgreSQL。MySQL 于 1995 年在瑞士诞生，次要基于 ISAM 的 mSQL 零碎开发；PostgreSQL 于 1994 年启动，由两名伯克利的学生对 QUEL 的 Postgres 源码进行二次开发，减少 SQL 查询语言的反对。
从 2000 年后，互联网利用如雨后春笋般呈现，这些利用对各种资源的要求都远超传统的软件服务。互联网利用须要反对大量用户的并发拜访，且对可用性要求极高，最好永远在线。在实践中，数据库开始成为互联网利用的瓶颈。许多厂商尝试纵向扩容，进步单机硬件性能，但这种形式换来的晋升非常无限，体现出显著的边际收益递加。而且纵向扩容通常很不平滑，将数据从一台机器挪动到另一台机器须要长时间下线服务，这对于互联网用户来说无奈承受。为了解决这个问题，一些公司定制化开发中间件(middleware)，将数据分片到多个一般单机 DBMS 上：
对下层利用形象出一个逻辑数据库，而背地则将数据扩散到不同的物理数据库上。当利用发动申请时，这层中间件须要转发或重写这些申请，分发给背地数据库集群的一个或多个节点，待这些节点执行完申请返回数据后，前者再将数据聚合返回给下层利用。从这个思路登程构建的两个比拟驰名的零碎别离是 eBay 的 Oracle-based cluster 和 Google 的 MySQL-based cluster。起初 Facebook 也采纳相似的策略构建外部的 MySQL cluster 并沿用至今。只管利用中间件对数据分片的策略，能够解决简略的点读、点写操作，但如果要在一个事务中更新多条数据，或者多表 join 就变得十分困难。正因为如此，这些晚期的中间件都不反对这类操作，eBay 要求这些中间件的用户必须在应用层逻辑中实现 join 逻辑。显然这违反了“利用程序逻辑与数据操作逻辑应该拆散”的理念，将数据操作逻辑从新裸露给利用开发者。
最终基于中间件的分片计划被逐步摈弃，各个公司将精力转向自研分布式数据库。除中间件计划暴露出的问题之外，传统数据库解决方案还暴露出两个问题：
第一，传统数据库重视一致性和正确性，在可用性和性能上有所就义。但这种 trade-off 与重视并发和可用性的互联网利用的需要南辕北辙。
第二，传统关系型数据库的许多性能在互联网利用中并不实用，而反对这些性能却会耗费额定的资源，如果可能应用更轻量的数据库兴许能晋升整体性能。除此之外，关系模型兴许不是表白利用数据的最佳形式，应用残缺的 SQL 来实现简略查问仿佛是“杀鸡用牛刀”。
这些问题正是 2005-2010 年间 NoSQL 静止的起源。NoSQL 的拥趸普遍认为妨碍传统数据库横向扩容、进步可用性的起因在于 ACID 保障和关系模型，因而 NoSQL 静止的外围就是 放弃事务强一致性以及关系模型，拥抱最终一致性和其它数据模型 (如 key/value，graphs 和 Documents)。两个最驰名的 NoSQL 数据库就是 Google 的 BigTable 和 Amazon 的 Dynamo，因为二者都未开源，其它组织就开始推出相似的开源代替我的项目，包含 Facebook 的 Cassandra (基于 BigTable 和 Dynamo)、PowerSet 的 Hbase(基于 BigTable)。有一些守业公司也退出到这场 NoSQL 静止中，它们不肯定是受 BigTable 和 Dynamo 的启发，但都响应了 NoSQL 的哲学，其中最闻名的就是 MongoDB。
在 21 世纪 00 年代末，市面上曾经有许多供用户抉择的分布式数据库产品。应用 NoSQL 的劣势在于利用开发者能够更关注应用逻辑自身，而非数据库的扩展性问题；但与此同时许多利用，如金融零碎、订单解决零碎，因为无奈放弃事务的一致性要求被拒之门外。一些组织，如 Google，曾经发现他们的许多工程师将过多的精力放在解决数据一致性上，这既裸露了数据库的形象、又进步了代码的复杂度，这时候要么抉择回到传统 DBMS 时代，用更高的机器配置纵向扩容，要么抉择回到中间件时代，开发反对分布式事务的中间件。这两种计划老本都很高，于是 NewSQL 静止开始酝酿。
二、NewSQL 的衰亡
本文认为 NewSQL 是对一类古代关系型数据库的统称，这类数据库对于个别的 OLTP 读写申请提供可横向扩大的性能，同时反对事务的 ACID 保障。换句话说，这些零碎既领有 NoSQL 数据库的扩展性，又放弃传统数据库的事务个性。NewSQL 从新将“利用程序逻辑与数据操作逻辑应该拆散”的理念带回到古代数据库的世界，这也验证了历史的倒退总是呈现出螺旋回升的模式。
在 21 世纪 00 年代中，呈现了许多数据仓库零碎 (如 Vertica，Greeplum 和 AsterData)，这些以解决 OLAP 申请为设计指标的零碎并不在本文定义的 NewSQL 范畴内。OLAP 数据库更关注针对海量数据的大型、简单、只读的查问，查问工夫可能继续秒级、分钟级甚至更长。NewSQL 数据库设计针对的读写事务有以下特点：
- 耗时短
- 应用索引查问，波及大量数据 (非全表扫描或者大型分布式 Join)
- 反复度高，通常应用雷同的查问语句和不同的查问参数
也有一些学者认为 NewSQL 零碎是特指 实现上应用 Lock-free 并发控制技术和 share-nothing 架构的数据库。所有咱们认为是 NewSQL 的数据库系统的确都有这样的特点。
三、NewSQL 的分类
既然曾经定义 NewSQL，咱们就能够剖析一下现在整个 NewSQL 数据库的图景。现今市面上的 NewSQL 数据库大抵能够分为 3 类：
- 齐全应用新的架构从新设计开发的 NewSQL 数据库
- 在中间件层实现 NewSQL 个性的数据库
- 云计算平台提供的数据库即服务产品（DaaS），通常也是基于新的架构
在撰写本文之前，两位作者都将利用“替换单机数据库存储引擎”的计划划分到 NewSQL 中。这种计划的典型代表就是一些替换 MySQL、InnoDB 的计划，如 TokuDB，ScaleDB，Akiban，deepSQL，MyRocks 的等等。应用新存储引擎的益处在于对于利用来说这样的替换毫无感知。但当初，两位作者发出了之前的观点，他们认为通过替换存储引擎和应用插件的形式扩大单机数据库系统并不是 NewSQL 零碎的典型代表，不属于本文的议论范畴。通常，通过替换 MySQL 存储引擎来晋升数据库 OLTP 场景下性能的计划最终都难逃失败。
接下来咱们将别离探讨这 3 类 NewSQL 数据库。
1. 新型架构
从无到有搭建的 NewSQL 零碎最令人感兴趣，因为我的项目设计有最大的自由度而无需思考古老零碎在设计、架构方面的累赘。所有属于这类的数据库系统都是基于 shared-nothing 的分布式架构，同时蕴含以下模块：
- 多节点并发管制 (multi-node concurrency control)
- 多正本数据复制 (replication)
- 流量管制 (flow control)
- 分布式查询处理 (distributed query processing)
应用新的数据库系统的另一劣势在于各个组件都能够针对多节点环境作出优化，如查问优化器、节点之间的通信协议等等。一个具体的例子就是，大多数的 NewSQL 数据库都能够在节点之间间接传递同一查问 (intra-query) 外部的数据，而无需像一些基于中间件的计划须要通过核心节点路由数据。
除了 Google 的 Spanner 之外，属于这个类别的数据库通常都会本人治理存储模块，这意味着 这些 DBMS 也须要负责将数据分布到不同的节点上，而不是采纳开箱即用的分布式文件系统 (如 HDFS)，或 storage fabric (如 Apache Ignite)。这是很重要的设计决定，本人治理意味着“send the query to the Data”，而依赖三方存储则意味着“bring the Data to the query”，前者传递的是查问命令，后者传递的是数据自身，显然前者对于网络带宽资源耗费更加敌对。自行治理存储层也使得数据库系统可能应用更粗劣、高效的复制策略，而不局限于 block-based 的复制策略。总得来说，自行搭建存储层能够取得更高的性能晋升。
应用新的架构并非没有毛病，其最大的毛病就是它的技术过新导致用户放心这些技术背地还有许多坑尚未被填平，这也进一步意味着应用新零碎的用户群体过小，不利于产品自身的打磨。除此之外，一些曾经被宽泛承受的运维、监控、报警生态也须要从头做起。为了防止此类问题，一些数据库系统，如 Clustrix、MemSQL、TiDB，抉择兼容 MySQL 的通信协议；又如 CockroachDB 抉择兼容 PostgreSQL 通信协议。
例子：Clustrix、Cockroach DB、Google Spanner、H-Store、HyPer、MemSQL、NuoDB、SAP HANA、VoltDB、TiDB 等等。
Cockroach DB 架构
2. 通明的数据分片中间件
市面上也有一些产品提供与当年 eBay、Google、Facebook 以及其它公司相似的中间件解决方案，并反对 ACID。在中间件之下的每个数据库节点通常：
- 运行雷同的单机版数据库系统
- 只蕴含整体数据的一部分
- 不用于独自接管读写申请
这些中心化的中间件次要负责路由申请，协调事务执行、散布数据、复制数据以及划分数据到多节点。通常在每个数据库节点中还有一层薄薄的通信模块，负责与中间件通信、代替中间件执行申请并返回数据。所有这些模块合起来独特向外界提供一个逻辑单体数据库。
应用中间件的益处在于其替换现存数据库系统非常简略，利用开发者无感知。在中间件计划中最常见的单机数据库就是 MySQL，这意味着为了兼容 MySQL，中间件层须要反对 MySQL 通信协议。只管 Oracle 提供了 MySQL Proxy 和 Fabric 工具帮忙大家兼容，但为了防止 GPL license 的潜在问题，大部分公司都抉择自行实现协定层的兼容。
基于中间件计划的毛病在于其依赖了传统数据库。传统数据库广泛采纳以磁盘为核心 (disk-oriented) 的设计架构，它们诞生于 20 世纪 70 年代，因而这类计划无奈应用一些 NewSQL 零碎应用的以内存为核心 (memory-oriented）的设计架构，从而也就无奈无效利用其更高效的存储管理模块和并发管制模块。之前的一些钻研曾经表明，以磁盘为核心的架构设计在某种程度上限度了传统数据库更高效地利用更多的 CPU 核以及更大的内存空间。同时，对于简单的查问，中间件计划有可能会引入冗余的查问打算和优化 (中间件一次、数据库节点一次)，只管这种做法也能够看成是查问的局部优化。
例子：AgilData Scalable Cluster、MariaDB MaxScale、ScaleArc 以及 ScaleBase。
Mariadb 逻辑架构
3. Database-as-a-Service（DaaS）
许多云计算供应商提供了 NewSQL 的数据库即服务产品。应用这类服务，开发团队就没有必要在公有的硬件或者从云服务商处购买的虚拟机上保护数据库系统，而是由云服务商接管数据库的配置、调优、复制、备份等等。云服务商的用户只须要通过给定的 URL 拜访数据库系统，或者利用控制面板和 API 来管理系统。
DBaaS 的消费者依据其资源利用状况来领取。因为不同的数据库查问应用的计算资源可能天壤之别，因而 DBaaS 供应商通常不会像采纳块存储服务一样依据查问次数的计费形式，而是让消费者确定其最大的资源应用限度 (如存储空间、计算资源和内存应用等) 来提供服务保障。比拟闻名的属于 DBaaS 的 NewSQL 零碎是 Amazon 的 Aurora，它既兼容 MySQL 的通信协议又兼容 PostgreSQL 的通信协议，其背地应用基于 Log-structureD 的存储管理模块来进步 I/ O 的并行效率。
也有一些公司依靠于大型云服务商提供的云平台服务构建 DBaaS 解决方案，如 ClearDB，它们能够被部署在各大云服务商的基础设施之上。这种计划的益处是能够在同一区域将数据库散布在不同的提供商上，来缩小故障危险。
例子：Amazon Aurora、ClearDB。
Amazon Aurora 云上部署架构
四、NewSQL 的现状
本节咱们探讨 NewSQL 数据库系统各模块的设计思路，来看看它们在实际和实践上是否有翻新之处。
1. 主内存存储（MainMemory Storage）
传统 DBMS 应用的是 disk-oriented 存储设计，数据次要存储在块存储设备，如 SSD 或 HDD。因为在块存储设备上读写速度慢，这些 DBMS 会将读入的数据块缓存在内存中，也将待写出的数据缓存在内存中，通过批量写出提高效率。因为内存与磁盘相比，容量更小，价格更低廉，这种设计极大地升高计算机的老本。几十年后的当初，内存的价格和容量都失去了改善，除了一些极大的 OLTP 数据库，绝大多数数据库都能够被齐全装入内存中，这使得 DBMS 能够疾速地从内存中读出数据，甚至不再须要像缓存治理 (buffer pool manager)、重量级并发管制机制这些模块。从 disk-oriented 转向 memory-oriented 赋予 DBMS 性能优化新的可能性。
许多 NewSQL 数据库都采纳基于内存的存储架构，不论是学术界的实验性数据库，如 H-Store，HyPer；还是业界的商用数据库，如 MemSQL、SAP HANA 和 VoltDB。这些零碎的性能在 OLTP 负载下的性能体现都要优于基于外存的存储架构。
实际上，将整个数据库装进内存的观点并不陈腐，威斯康星大学麦迪逊分校在 20 世纪 80 年代就曾经在内存数据库畛域打下了根底，笼罩了索引、查询处理、数据恢复等各个方面。在同一年代，第一个分布式内存数据库，PRISMA/DB 实现开发。到了 90 年代，第一批商用内存数据库问世，包含 Altibase、Oracle TimesTen 以及 AT&TDataBlitz。
Altibase 内存数据库架构
memory-oriented 的 NewSQL 数据库中的翻新点在于尝试将数据库中比拟不沉闷的数据清出内存，从而缩小内存应用，这使得这些 NewSQL 数据库可能存储比它内存空间更大的数据而无需回到 Disk-oriented 的存储架构。广义地说，这类做法都须要建设一个外部跟踪机制来发现内存中不沉闷的记录，在必要时将其清出到外存。以 H-Store 为例，它的 anti-caching 模块会将不沉闷的记录清出，并在其原来的地位搁置一个 tombstone 记录，当某个事务想要拜访这条记录时，就将事务停止，而后起一个独立的线程去异步加载记录放回内存中。当然间接应用操作系统的虚拟内存的 paging 机制也能达到雷同的目标，如 VoltDB。为了防止在利用索引查找时产生误判 (false negative)，所有的二级索引都须要保留被清出记录的 key，如果利用所用的数据表有较多的二级索引，那么即使记录被清出，仍然会造成内存节约。Microsoft 的 Siberia 我的项目，在解决这个问题时利用了 bloom filter 来判断指标记录是否存在，以此来缩小内存耗费。只管 Siberia 不是 NewSQL 数据库，但这种做法值得参考。
MemSQL，另一个 NewSQL 数据库，没有跟踪记录的元信息，而是采纳了不同的计划来解决数据量比内存大的问题。MemSQL 将数据按 log-structured 的模式组织，使得数据写入的性能晋升。除此以外，管理员能够手动地通知数据库将某个表按列 (columnar format) 存储。
总体来看，基于内存的存储计划并没有显著翻新，能够看作是以前计划的延长。
2. 分区 / 分片（Partitioning/Sharding）
所有 NewSQL 数据库都是通过将整个数据库划分成不同的子集，即 partitions 或 shards，来实现横向扩容。
在分布式数据库上操作数据并不是一件新鲜事，PhiL Bernstein 和他的共事早在 70 年代末期就曾经在这方面有所建树，他们的 SDD- 1 我的项目在分布式事务处理上做出了许多根底奉献。80 年代晚期，System R 和 INGRES 的开发团队就各自构建了相应的分布式数据库系统：IBM 的 R* 采纳了相似 SDD- 1 的 share-nothing 和 disk-oriented 的设计。INGRES 的分布式版本中提出了一种查问优化算法，能够递归地将查问动静拆分成更小的查问，为世人所铭刻。起初 Wisconsin-Madison 大学的 GAMMA 我的项目摸索了不同的分片策略。
然而，这些晚期的分布式数据库系统都没有失去久远倒退，次要有两个起因：
第一，20 世纪的计算机硬件价格昂贵，绝大多数公司无奈累赘。
第二，高性能、高可用的互联网利用在 20 世纪并不存在，那时候数据库的 QPS 广泛在几十到几百之间
但现在，这两个假如都不再成立，在各种云基础设施的平民化，开源分布式系统、工具的帮忙下，搭建一个数据密集型的利用变得比过来简略很多，也使得分布式数据库回到历史舞台。
在分布式数据库中，数据表会被依照某个字段或某组字段 (partitioning attributes)，横向切分成多个分段 (segments)，可能通过哈希函数来切分，也可能基于范畴进行切分。多个数据表的相关联的数据分段经常会被合并起来放到同一个分片 (节点) 中，该节点负责执行任何须要拜访该分片外部数据的申请。不过 DBaaS(Amazon Aurora，ClearDB) 并不反对这种分片策略。现实状况下，分布式数据库应该可能主动将查问散布到多个分片上执行，而后将后果合并，除了 ScaleArc，其它 NewSQL 数据库都提供这样的反对。
许多 OLTP 利用的数据库 schemas 都能够被转化成一个树状构造：
依照 root table 的主键散列，能够使得每个查问波及到的数据都在一个分片中。比方有一张客户表，数据库按客户 id 分片，那么这个客户的所有订单记录、账号信息都存储在同一个分片上，这样简直所有事务都可能在同一个分片上执行，缩小数据库系统外部节点间的交换，也不须要承当如两部提交 (2PC) 的老本，进步整体性能。
有一部分 NewSQL 数据库中的节点并不是等价的，如 NuoDB 和 MemSQL。NuoDB 会应用集群中的一个或多个节点负责存储管理 (storage manager, SM)，每个 SM 存储着一个数据分片，在 SM 外部，数据被进一步划分成 Blocks。集群中的其它节点负责执行事务 (transaction engine,Te)，每个 TE 节点中缓存事务波及到的 Blocks。这是一个典型的计算、存储拆散的设计。执行事务时，一个 Te 节点须要从 SM 或其它 Te 节点中获取事务波及的所有 Blocks，而后 TE 须要获取待批改数据的写锁，在本地批改完数据后将其播送给对应的 SM 和其它 TE 节点。为了缩小 Blocks 在各 TE 节点间来回传递的景象，NuoDB 在负载平衡策略上作了文章，使得具备局部性的 Blocks 尽量散布到雷同的 Te 上，这种思路使得 NuoDB 既可能将数据正当分片，又不须要对数据表有任何假如 (如上文中的树状构造)。MemSQL 也采纳了与 NuoDB 相似的计算、存储拆散的设计，但与 NuoDB 不同的是，MemSQL 的计算节点 (aggregator) 并不缓存任何数据，而是将残缺的查问拆成小查问让各个存储节点 (leafNode) 执行，即计算节点是无状态的。NuoDB 和 MemSQL 的计算和存储都具备独立横向扩大的能力。异构节点架构是否在性能、运维复杂度等各个方面上优于同构节点架构，目前尚未有定论。
NewSQL 数据库的一个重要个性就是反对数据的线上迁徙 (live migration)，它容许数据库在不同的物理节点上重均衡 (rebalance) 数据，缓解热点，以及扩容的同时，不影响数据库自身的服务。相较于 NoSQL，NewSQL 要做到这点难度更大，因为后者还须要保障 ACID 的个性不被毁坏。总体上看，NewSQL 有两种计划来反对数据的线上迁徙：
一是将数据组织成粗粒度的逻辑分片，散列到物理节点上。须要重均衡时，就在这些节点之间挪动这些逻辑分片。这种计划在 Clustrix、AgilData、Cassandra 和 DynamoDB 中都有利用。
二是在更细的粒度上，如记录 (tuple) 或一组记录 (groups of tuple) 上，通过取值范畴来重排数据。MongoDB、ScaleBase、H-Store 采纳了这种计划。
3. 并发管制（Concurrency Control）
并发管制机制是数据库系统处理事务最外围、最重要的局部，因为它波及到简直整个零碎的方方面面。并发管制让不同的用户拜访数据库时如同是独自占有一样，它提供了事务的原子性和隔离性保障，影响着零碎的整体行为。
除了应用哪种并发管制机制，分布式数据库系统的另一设计关键点在于 应用中心化还是去中心化的事务协调协定 (transaction coordination protocol)。在中心化协定下，所有事务操作的终点都是中心化的协调器 (coordinator)，由后者来决定是否批准操作；在去中心化协定下，每个节点都维持着拜访本身数据的事务状态信息，这些节点须要与其它节点互相通信、协调来确定是否有并发抵触。一个去中心化的协调器对于扩展性更加敌对，但通常要求不同节点的墙上时钟高度同步，以便于确定事务的全序。
首批分布式数据库系统诞生于 20 世纪 70 年代，它们广泛应用了两部加锁 (two phase locking,2PL) 机制。SDD- 1 是第一个在 share-nothing 集群下反对分布式事务的数据库，它应用了中心化的协调器。IBM 的 R* 相似 SDD-1，不过它采纳的是去中心化的协调机制，分布式 2PL，每个事务都会将其拜访的数据加锁。INGRES 数据库的分布式版本也是应用分布式 2PL，但它依赖于中心化的死锁检测机制。
因为解决死锁问题过于简单，简直所有 NewSQL 数据库都摈弃了 2PL。以后的风行的是 timestamp ordering(TO) 并发管制机制的不同变体，在该机制中数据库假如：不会按可能造成违反 serializable ordering 的操作程序来执行并发事务。在 NewSQL 零碎中最风行的并发控制协议是去中心化的 MVCC，当更新操作产生时，数据库会为每条记录创立新版本。放弃一条记录的多个版本能够让读事务不阻塞写事务、写事务也不阻塞读事务。应用去中心化 MVCC 机制的 NewSQL 数据库包含 MemSQL、HyPer、HANA 及 Cockroach DB，只管它们都或多或少地依据须要做出定制化的改变，但这种计划的外围概念并不算翻新。早在 1979 年，MIT 的一篇 PhD 毕业论文中就曾经提到 MVCC，而在 80 年代晚期，第一批应用 MVCC 的商用数据库随即问世，它们包含 DigitaL 的 VAX Rdb 和 Jim Starkey 研发的 InterBase，后者也是 NuoDB 和 MySQLFalcon 存储引擎的作者。
常见并发机制的分类
其它数据库系统 应用的则是 2PL 和 MVCC 的交融计划，在这种计划中，写事务依然须要依照 2PL 机制去获取数据的锁，每当事务批改一条记录，数据库也会依照 MVCC 的形式为该记录创立新版本；读事务则无需获取锁，因而也不会阻塞写事务。这种计划最驰名的实现就是 MySQL 的 InnoDB，但它也被 Google Spanner、NuoDB 以及 Clustrix 采纳。NuoDB 在原始的 MVCC 根底上通过节点间的 Gossip 协定来播送记录的版本信息，改善性能。所有中间件和 DBaaS 计划都继承了其背地单机数据库的并发管制机制，因为它们中的大部分应用的是 MySQL，因而它们自然而然地也采纳了 2PL 和 MVCC 混合的机制。
本文认为 GoogleSpanner(蕴含其后辈 F1 和 SpannerSQL) 实现的并发管制机制是所有 NewSQL 零碎中最新鲜的，只管它是基于 2PL 与 MVCC 的混合机制，但不同凡响的是 Spanner 通过硬件设施 (GPS、原子钟) 取得了高精度的时钟同步个性，并利用这些高度同步的时钟来为事务产生工夫戳，取得事务的程序，从而在广域网上实现多版本数据库的数据一致性。CockroachDB 也反对雷同的事务一致性，但它没有应用这些硬件设施，而是依赖于基于低同步的时钟和逻辑计数器的混合时钟协定来实现。
到论文发表为止，惟一一个未应用 MVCC 变体的商用 NewSQL 数据库就是 VoltDB，它依然应用的是 TO 并发管制，其中每个分片上的事务依照一次只能执行一个的形式调度，而非像 MVCC 那样将事务中的操作交错在一起。在 VoltDB 中，单分片事务以去中心化的形式调度，跨分片事务则依照中心化的形式调度。VoltDB 将事务依照逻辑工夫戳排序，而后在分片上顺次执行，当一个事务在某个分片上执行时，它独占整个分片的所有数据，因而该零碎无需解决更细粒度的加锁逻辑。这种基于分片并发机制的毛病在于，如果事务波及多个分片，而协调器与这些分片之间的网络呈现提早，那么这些分片都将空转而无奈解决其余申请。基于分片的并发管制机制也不是新思路，Hector Garcia-Molina 在 1992 年的一篇论文中曾经提出相似的变体计划，并在 90 年代末的 kdb 以及 H -Store(VoltDB 的学术前身) 中失去实现。
总体来看，NewSQL 数据库应用的外围并发管制机制没有显著的翻新，次要是老办法在古代硬件和分布式环境中的工程化。
4. 次级索引（Secondary Indexes）
反对二级索引对于单机数据库来说并非难事，因为数据都在一个节点上，然而对于分布式数据库来说并非易事。例如：假如有一张客户表，依照客户 iD 分片到不同的物理节点上。当有查问想要依据客户的邮箱地址来查时，就须要去每个节点上都查一遍，能力失去正确后果。
一个分布式数据库要反对二级索引，须要思考两个设计决定：
- 将二级索引寄存在哪里
- 如何在事务中保护二级索引
如果一个零碎中存在中心化的协调器，如中间件计划，那么能够将二级索引寄存在协调器节点和分片节点上，这种计划的益处就是全局只有一个版本的索引数据须要保护。
应用新架构的 NewSQL 数据库通常应用分片二级索引计划，即每个节点都存储索引的一部分，而不是整个索引寄存在独自的一个节点上，在须要时复制到其它节点。这里的衡量很好了解：
Clustrix 将上述两种计划联合：将二级索引按范畴分片，每个节点都存着范畴与分片的对应关系。遇到查问、更新申请时，都先将申请路由给适合的节点，再由后者执行相应的操作。这种两层的设计联合了两个计划的长处。
如果 NewSQL 数据库不反对二级索引，开发者的常见做法就是本人构建二级索引，并放在分布式缓存零碎中，但依赖内部零碎将使得索引与数据之间的行为没有一致性保障，开发者须要审慎看待。
5. 复制（Replication）
想要确保利用的可用性、数据的持久性，最好的办法就是在数据库层面实现复制。所有的古代数据库，包含 NewSQL 零碎，都提供某种模式的数据复制机制。
在数据库复制上，有两个重要的设计决定：
如何保障跨节点的数据一致性？在一个强统一 (strongly consistent) 的数据库系统中，新写入的数据必须被相应的所有复制节点长久化之后，事务能力被认为曾经提交。这样所有的读申请都能被发送到任意复制节点上，他们接管到的数据能够认为是最新的数据。强统一的数据库系统诚然很好，但 DBMS 维持这样的同步状态须要应用像 2PC 这样的原子提交协定 (atomic commitment protocol) 来保证数据同步，如果在这个过程中有一个节点故障或者呈现网络分区，数据库服务就会没有响应。这也是为什么 NoSQL 零碎通常应用弱一致性 (weekly consistent) 或最终一致性 (eventual consistent) 模型，在弱一致性保障下，通常 Master 节点无需期待所有复制节点长久化数据就能够通知认为事务以及提交。所有咱们所晓得的 NewSQL 零碎都反对强一致性数据复制，但这些零碎如何实现强一致性并没有什么新意，数据库系统的 state machine replication 早在 20 世纪 70 年代就曾经存在根底钻研，在 80 年代问世的 NonStop SQL 就是第一个应用强统一复制的分布式数据库系统。
如何执行跨节点数据流传？次要有两种执行模式。第一种被称为 Active-active 复制，即让每个复制节点都执行雷同的申请。例如，接管到一个新申请，数据库系统会在所有复制节点上执行雷同的申请；第二种是 Active-passive 复制，即申请先在一个节点上执行，再将状态传递给其它复制节点。大多数 NewSQL 数据库系统采纳 active-passive 复制，这次要是因为每个申请达到不同节点的程序不同，如果间接应用 active-active 复制，很容易导致数据不统一呈现。相较之下，deterministic DBMSs，如 H-Store、VoltDB、ClearDB，都应用 Active-active 复制，因为在 deterministic DBMS 中，事务在不同节点上的执行程序可能保障统一。
NewSQL 与之前的数据库系统在工程上不同的一点在于，前者还思考了广域网 (wide-area network) 的复制。在云服务风行的时代，多地多核心的利用部署曾经不是难事，只管 NewSQL 能反对广域网数据同步，但这须要使用者自行保障 DC 之间的网络品质。Spanner 和 CockroachDB 论文发表截止前提供广域网数据同步一致性优化唯二的两个数据库。Spanner 采纳了原子钟与 GPS 硬件时钟的组合计划，CockroachDB 则采纳混合时钟的计划。
6. 解体复原（Crash Recovery）
NewSQL 数据库系统的另一个重要个性就是故障复原机制。个别传统数据库的容错能力次要强调的是保证数据长久化，而 NewSQL 在此之上，还须要提供更高的可用性，即产生故障还能保障数据库服务的失常应用。
在传统数据库中，故障复原的实现通常是基于 WAL，即在故障后重启零碎，载入最初一个 checkpoint 后回放 WAL，使得零碎可能回到故障前的正确的状态。这种计划被称为 ARIES，最早由 IBM 的数据库钻研人员与 1990 年前后创造，现在简直所有数据库系统都采纳 ARIES 计划或其变种。
在存在复制节点 (replicas) 的分布式数据库中，传统的故障复原计划并不能间接应用，其起因在于：master 节点解体后，零碎将抉择一个 replica 作为新的 Master 节点，当老的 Master 节点回到线上，因为线上集群曾经写入许多新数据，仅靠 checkpoint 和 WAL 来复原无奈跟上集群，它须要从新的 Master 节点上同步所有新的改变。目前，次要有两种实现计划：
第一，利用本地 checkpoint 和 WAL 先复原数据，而后从 Master 或其它复制节点拉取新的 Logs。只有故障复原后的节点解决 Logs 的速度比数据写入的速度快，最终必定可能跟上整个集群。对于应用物理日志 (physical/physiological logging) 的数据库来说跟上整个集群是可能的，因为间接将数据的更新同步到本地比执行 SQL 速度要快很多。
第二。放弃本地的 checkpoint 和 WAL 机制，间接从集群中的某个节点全量拉取数据，这种计划的益处在于同样的机制能够用于扩容集群节点。
通常基于中间件和 DBaaS 的 NewSQL 零碎会基于单机数据库的故障复原机制，减少额定的基础设施，如 Leader 选举等，来实现其所需的治理能力。而基于新架构的 NewSQL 零碎会抉择摈弃单机数据库的故障复原机制，应用开箱即用的日志复制组件，如 ZooKeeper、Etcd，或本人实现背地的算法，如 Paxos、Raft。
以上所述的计划和技术组件早在 90 年代之后就曾经存在。
五、将来趋势
将来的数据库系统应该要可能在新产生的数据上执行剖析型查问和机器学习算法，这种 workload 通常被称为 real-time analytics 或 hybri dtransaction-analytical processing(HTAP)，可能同时从历史数据和新数据中夺取洞见和常识。传统的商业剖析和商业智能通常只能在历史数据上剖析，但数据的价值通常在产生时最高，并逐步随着工夫的推移而缩小，因而如果可能将数据生产和剖析的距离减小，将可能产生更大的价值。
目前有 3 种反对 HTAP workload 的办法：
最常见的办法是部署两套独立的数据库，一套用于解决 OLTP workload，称为前端数据库；另一套用于解决 OLAP workload，称为后端数据库。前端数据库解决新事务产生的数据，而在后盾，系统管理用 ETL 工具将数据从 OLTP 数据库导入后端数据库，通常会是一个数据仓库。利用在后端数据库上执行 OLAP 查问，防止拖慢前端 OLTP 零碎，而在 OLAP 零碎产生的新数据则会反向推给前端 OLTP 数据库，造成闭环。
另一种流行的设计方案是 lambda architecture。即应用另一套批处理零碎，如 Hadoop、Spark，在历史数据上计算复合的视图，同时应用一套流式解决零碎，如 Storm、Spark Streaming 等在新产生的数据上计算准实时的视图。批处理零碎通常须要周期性的从新扫描数据汇合，将计算结果通过流式解决零碎再反馈给线上服务。
上述两种计划的一个独特特点就是将数据导向异构零碎，这也带来了许多问题。首先，将数据批改流传到另一个零碎须要工夫，且时长通常以分钟或小时计，这就间接导致数据的计算无奈实时；其次，部署和保护两套零碎的运维老本也很高，通常这种人力老本能占到总成本约 50%；开发人员如果想要同时依据两套零碎中的数据分析，则须要写两套数据获取逻辑。只管同样应用异构零碎，也有一些计划尝试向外暗藏两套零碎的事实，只裸露一套接口，但这通常须要在背地将数据从 OLTP 零碎 (如 Hbase) 复制到 OLAP 零碎 (如 Spark) 上。
第三种计划就是应用一个 HTAP 数据库，即反对高吞吐、低时延的 OLTP workload，同时反对在历史 (冷) 数据和新 (热) 数据上运行逻辑简单、工夫长的 OLAP workload。OHAP 零碎与过来通用数据库的次要不同点在于，前者将一些非凡的 OLTP 实现计划 (in-memory storage、lock-free execution) 和 OLAP (columnar storage、vectorized execution) 计划联合。
SAP HANA 和 MemSQL 是第一批声称本人是反对 HTAP workload 的 NewSQL 数据库。HANA 通过在外部应用不同的执行引擎来实现，一个引擎用于行存储数据，实用于 OLTP workload，一个引擎用于列存储数据，实用于 OLAP workload；MemSQL 应用不同的存储管理器 (SM) 存储数据，一种用于行存储，一种用于列存储，在执行引擎层将二者联合在一起。HyPer 从应用与 H-Store 相似的并发管制、行存储数据计划转型成应用 MVCC、列存储计划，以便反对更简单的 OLAP 查问。VoltDB 也将它们的市场策略从纯 OLTP 转向反对流式计算。相似地，S-Store 则尝试基于 H -Store 架构减少流式解决能力。甚至一些在 21 世纪 00 年代的以 OLAP 为指标的零碎 (如 Greenplum)，也开始减少对 OLTP 的反对。
只管 HTAP 数据库的衰亡意味着单体大型 OLAP 数据仓库的终结，但短期内这并不会产生，因为目前这些数据仓库还是目前大部分公司的通用后端数据库，寄存着公司所有的历史数据，但总有一天，满足 OLAP workload 将不再须要通过挪动数据来实现。
END
更多干货内容请关注微信公众号“录信数软”~
