NewSQL是伪命题还是真突破？NewSQL系统综述

本文选自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 数据库更关注针对海量数据的大型、复杂、