数据库简史与NewSQL核心技术
// 本文为 (https://db.cs.cmu.edu/papers/2016/pavlo-newsql-sigmodrec2016.pdf) 翻译稿，本文主要阐述了数据库发展史，和近些年来数据库技术发展的本质，分享给大家，以便把握数据库技术未来趋势，如您发现翻译错误或其他问题，请联系微信号sunny4715进行修订。
摘要：
一类名为NewSQL的新型数据库管理系统（DBMS）宣称，针对现代OLTP系统的工作负载，它们具有传统数据库系统无法实现的扩展性。 本文的其中一位作者在2011年的商业分析报告中首次使用了NewSQL这个术语，该报告讨论了作为数据库老牌供应商（Oracle，IBM，Microsoft）挑战者的新型数据库系统的兴起。本文另一位作者一直为第一个 NewSQL系统而工作。 从那以后很多公司和研究项目就使用NewSQL这个术语（正确和错误地）来描述他们的系统。
鉴于关系型数据库管理系统已经存在了四十多年，因此可以毫不犹豫地询问NewSQL的优势是否真实存在，或者仅仅是出于营销考虑。 如果它们确实能够获得更好的性能，那么接下来的问题是这些目标的达成是否是由于某些符合科学的新发现新发明，又或者仅仅只是因为硬件性能提升得如此之快以至于早年数据库系统的瓶颈已经不再。
为此我们首先讨论了数据库的历史以了解NewSQL系统是如何产生的。 然后我们详细解释了NewSQL这个术语的含义以及属于这个定义下不同类别的系统。
DBMSs简史
第一代DBMS系统是在20世纪60年代中期运行上线的， 其中之一是IBM的IMS系统，它被用于跟踪土星V和阿波罗太空探索项目的供应商和零件库存信息。 数据库系统的引入有助于实现将应用程序代码和被操作的数据进行解耦的想法。 它允许开发人员仅关注数据访问和操作的应用程序的代码编写，而不再需要考虑这些操作背后如何实现涉及的并发和开销问题。 紧跟IMS之后，20世纪70年代早期开启了第一代关系型DBMS的开创性工作，IBM的System R和加州大学INGRES系统都是其中代表。 INGRES很快被其他大学用于其信息系统，并随后在20世纪70年代后期商业化。 大约在同一时间，Oracle发布了他们的DBMS的第一个版本，类似于System R的设计。 其他成立于20世纪80年代早期的公司，旨在重复第一批商业DBMS的成功，包括Sybase和Informix。 虽然IBM从未向公众提供System R，但后来在1983年发布了一个新的关系型DBMS（DB2），它使用了部分System R代码。
20世纪80年代末和90年代初期引入了一类新的DBMS，旨在克服关系模型和面向对象编程语言之间引人注目的阻抗不匹配[65]，但是这些面向对象DBMS从未被市场广泛采用，因为他们缺乏像SQL这样的标准接口。 而当主要DBMS供应商在十年之后添加对象和XML支持时，对象数据库的许多想法最终被纳入其中，二十年后面向文档的NoSQL系统又重复了一遍类似的历史（指NoSQL缺少标准SQL接口，最终被传统DBMS吸收新特征）。
20世纪90年代的另一个值得注意的事件是如今两个主要的开源DBMS项目。MySQL最早的版本是基于1995年在瑞典启动的以ISAM为存储引擎的mSQL系统。 PostgreSQL则始于1994年，当时两名伯克利研究生为20世纪80年代出现的基于QUEL引擎的Postgres代码增加了对SQL的支持而诞生PostgresSQL。
随着2000年以后互联网应用时代的到来，数据库对更高配置的硬件资源需求的挑战比起之前几十年来都要更大。 他们需要扩展以支持大量并发用户，并且必须保障数据库系统每时每刻都处于在线状态。但对于这些新型互联网应用程序而言，其后的数据库系统一直被认为是最大的瓶颈，因为资源的需求远远大于DBMS和硬件当时可以支持的范围。 许多人尝试通过将数据库部署到具有更高配置的硬件机器上来纵向扩展DBMS的能力。 然而这只会有限地提高性能并且降低了投入收益比。 此外将数据库从一台机器移动到另一台机器是一个复杂的过程，通常需要大量的停机时间，这对于基于WEB的互联网应用是不可接受的。为了解决这个问题，一些公司定制开发了中间件产品用来将单节点DBMS分散到一组较便宜的机器上。 这样的中间件向应用程序提供单个逻辑数据库，该数据库存储在多个物理节点上。 当应用程序针对此数据库发出查询时，中间件会重定向和/或重写它们，以便在集群中的一个或多个节点上分发并执行这些SQL。 节点执行这些查询并将结果发送回中间件，然后中间件将它们合并为对应用程序的单个响应。 这个中间件方法有两个典型的例子是eBay公司基于Oracle的集群 [53]和Google基于MySQL的集群[54]。 这种方法后来被FaceBook采用，用于他们自己的MySQL集群，至今仍在使用。
分片中间件适用于简单的操作，如读取或更新单个记录。 但是执行更新事务中涉及多个记录或连接表的查询就会非常困难，这样早期的中间件系统是不支持这类操作的。 例如在2002年eBay的中间件系统就需要他们的开发人员编写所有的连接操作相关的应用层代码。
最终，其中一些公司不再使用中间件，而是开发了自己的分布式DBMS。 这样做的动机有三重考虑。最重要的是传统DBMS主要关注一致性和正确性，但却牺牲了可用性和性能。 但这种折中对于需要持续在线并支撑大量并发操作的Web应用程序来说是不合适的。 其次人们认为使用像MySQL这样的全功能DBMS作为“哑”数据存储有太多的开销。 同样也有人认为关系模型不是表示应用程序数据的最佳方式，并且使用SQL进行简单lookup查询有点过重了。
这些问题最终成为21世纪00年代中后期NoSQL运动兴起的起源[22]。 这些NoSQL系统的关键特征是它们放弃了强大的事务保证和传统DBMS的关系模型，转而支持最终一致性和替代模型（例如键/值，图形，文档等数据模型)。 这是因为人们认为现有DBMS的这些方面会抑制其扩展能力并能实现支持WEB应用所需的高可用性特性。 最知名有两个系统，首先遵循这一信条的是谷歌的BigTable [23]和亚马逊的Dynamo [26]。 这两个系统中的任何一个系统都不对外开放（尽管它们现在已经提供相关云服务），因此其他企业则创建了他们自己的开源克隆。 其中包括Facebook的Cassandra（基于BigTable和Dynamo）和PowerSet的Hbase（基于BigTable）。 其他创业公司则创建了他们自己的系统，这些系统不一定是谷歌或亚马逊系统的拷贝版，但仍遵循了NoSQL哲学的原则; 最知名的则是MongoDB。
到2000年代末，现在有各种各样的可扩展和更实惠的分布式DBMS可用。 使用NoSQL系统（或者人们认为）的优势在于开发人员可以专注于他们的应用程序（应用领域能给企业或组织带来更多效益），而不必担心如何对DB系统进行扩展。 但是许多应用程序无法使用这些NoSQL系统，因为它们无法放弃事务和数据的强一致性要求。 这对于商业企业那些处理财务数据的系统来说很常见（比如金融和订单处理系统）。 一些企业，最负盛名的谷歌[24]，已经发现NoSQL DBMS导致他们的开发人员花费太多时间编写代码来处理不一致的数据，并且使用事务使他们更有效率，因为它们提供了更有用的抽象，更容易供人类推理。 因此这些企业唯一可行的选择是购买配置更强大的单节点机器以纵向扩展DBMS处理能力，或者自己定制开发的支持事务的分布式数据库中间件。 这两种方法都非常昂贵，因此对许多企业来说都不是个好选择。 正是在这种环境下带来了NewSQL系统。（备注：NoSQL社区争辩说，NoSQL的绰号现在应该被解释为“Not Only SQL”，因为其中一些系统已经支持SQL的一些方言。）
NewSQL的兴起
我们对NewSQL的定义如下，NewSQL是一类现代关系型数据库管理系统，旨在为OLTP系统的读写操作提供与NoSQL系统相似的可扩展处理能力，同时它还保留了事务的ACID特性。 换句话说，这些系统希望具备与2000年兴起的NoSQL DBMS类似的可扩展性，但仍然保留了上世纪七八十年代流行的传统DBMS关系模型（使用SQL）和事务支持。这使得应用程序能够针对新数据执行大量并发事务并使用SQL（而不是专有API）来修改数据库的状态。如果应用程序使用NewSQL DBMS，那么开发人员就不必像NoSQL系统那样编写逻辑来处理最终一致性相关的逻辑。 正如我们在下面讨论的那样，这种解释涵盖了许多学术和商业系统。
我们注意到在2000年代中期出现了数据仓库DBMS系统，有些人认为符合此标准（如Vertica，Greenplum，Aster Data）。这些DBMS的目标是在线分析处理工作负荷（OLAP），并不应被视为NewSQL系统。 OLAP系统专注于执行复杂的只读查询（即聚合、多路连接等）需要很长时间来处理大型数据集（例如，数秒或甚至几分钟）。这些查询中的每一个都可能与之前的查询明显不同，与之不同的是，NewSQL DBMS所针对的应用程序被设定为那些执行的读-写操作且属于短连接的事务（即没有用户占用长连接事务），（2）使用索引进行查询（即没有全表扫描或大型分布式事务操作），只会涉及一小部分数据，（3）并且该类型的查询是重复的（即，使用不同的输入执行相同的查询语句）。 其他人则主张更为狭隘的定义，NewSQL系统的实现必须使用无锁并发框架和（2）share nothing的分布式架构[57]。 我们在第3节中将讨论被归类为NewSQL的所有DBMS确实也都具有这些属性，因此我们同意这个设定。
NewSQL的分类
基于上述定义，我们这里研究下当今NewSQL DBMS领域的情况。 为了简化分析，我们将根据系统技术实现的最显著特征对其进行分组。 我们认为最能代表NewSQL系统的是三类数据库：（1）底层完全创新的技术架构；（2）与谷歌和其他公司在2000年代开发的分布式中间件基础设施类似，用于数据分片的数据库中间件产品，以及（3）云计算提供商提供的DBaaS产品，这类数据库也基于新架构。
两位作者以前都为现存的NewSQL系统分类中单节点数据库产品添加过替代存储引擎。 最常见的例子是替代MySQL默认的InnoDB存储引擎（例如，TokuDB，ScaleDB，Akiban，deepSQL）。 使用新引擎的优势在于，企业可以获得更好的性能而无需更改其应用程序中的任何内容，仍然可以利用DBMS现有的生态系统（例如，工具，API）。 其中最有趣的是ScaleDB，因为它通过在存储引擎之间重新分配执行而在系统下方提供透明分片而不使用中间件; 然而该公司已经转向另一个问题领域。对于除MySQL以外的系统，还有其他类似的扩展。 微软的内存Hekaton OLTP引擎，用于SQL Server的OLTP引擎几乎可以与传统磁盘驻留表无缝集成。 其他人使用Postgres的外部数据包装器和API钩子来实现相同类型的集成，但是其工作目标却是OLAP工作负载（例如，Vitesse，CitusDB）。
我们这里声称这些存储引擎替换工作来扩展单节点DBMS，并不代表他们属于NewSQL系统，这些引擎要从我们的NewSQL分类中排除它们。MySQL的InnoDB引擎在可靠性和性能方面有了显著提升，因此切换MySQL存储引擎的好处并不明显。我们也承认将行级InnoDB存储引擎替换为列级存储引擎，以用于OLAP工作负载的效果会更为显著（例如Infobright，InfiniDB等）。但总体来看，为OLTP工作负载进行MySQL存储引擎替换的工作是失败项目的坟场（暗指有大量类似失败的项目，XXXX/XXX 就是其中之一）。
3.1 新架构类型的NewSQL
此类别包含了最有趣的NewSQL系统，因为它们是从头开始构建的全新DBMS， 也就是说它们不是扩展现有系统（例如，微软的Hekaton for SQL Server），而是采用全新的代码库设计，而没有传统系统的任何架构包袱。 此类别中的所有DBMS都是基于对资源share-nothing的分布式架构，还包含支持多节点并发控制，replication模式的容错机制，流控和分布式查询处理的组件。 使用为分布式执行而构建的新DBMS的优势在于可以在多节点环境下优化系统的所有模块。这包括查询优化器和节点间通信协议的优化。 例如大多数NewSQL DBMS都能够直接在节点之间互相发送内部查询数据，而不是像一些中间件系统那样需要将所有数据路由到中心位置。
此类别中的每个DBMS（除了Google Spanner）都自己管理系统的主存储，要么在内存中要么在磁盘上。这意味着DBMS使用自研存储引擎将资源在多节点间分发，而不是依赖已有的分布式文件系统（例如HDFS）或存储架构（例如Apache Ignite）。 这是NewSQL的一个重要特征，因为它允许DBMS“将查询语句发送到数据处”而不是“将数据传输到查询节点中”，这会导致网络流量显著减少，因为传输查询语句的网络开销通常较小，而传输数据则需要将大量数据（不仅仅是元组，还有索引和物化视图）传输到计算节点。
管理自己的存储使得NewSQL系统能够采用比基于块复制的HDFS方案更复杂的replication方案。 通常这些NewSQL比建构在已有分布式存储系统之上的其他系统拥有更高的性能; 建构在其他已有分布式存储系统方面的例子包括像Trafodion [4]和Splice Machine [16]等这样的“SQL on Hadoop”系统，它们是在Hbase之上提供交易服务。 因此，我们认为不应将此类系统视为NewSQL。
但是使用基于新架构的DBMS存在缺点。 最主要的一点是许多企业都对采用过于新颖且未经过大规模部署验证的新架构技术持谨慎态度。 部署案例少也意味着与广受欢迎的传统数据库厂商相比，该类系统有丰富运维经验的人数也要少很多。 这同时也意味着企业可能会对已有的数据库管理工具和报表工具失去没法使用。所以某些DBMS（如Clustrix和MemSQL）通过保持与MySQL协议的兼容性来解决该类问题。
示例：Clustrix [6]，CockroachDB [7]，Google Spanner [24]， H-Store [8]，HyPer [39]，MemSQL [11]，NuoDB [14]，SAP HANA [55]，VoltDB [17]
3.2 透明分片中间件
现在业内有很多与eBay，Google，Facebook和其他公司在2000年代开发的相同类型的分片中间件产品。这些中间件可以将企业的数据库拆分为多个分片，这些分片存储在由许多单点DBMS实例构成的DB集群中。 与20世纪90年代的数据库联合技术不同，因为：（1）每个节点运行相同的DBMS，（2）单节点实例承载的数据只是整个数据库的一部分，（3）但分片并不意味着会被单独的应用所访问或更新。
中心化的中间件组件包含查询路由，协调事务，以及管理跨节点的数据分布、复制和分片。 通常在每个DBMS节点上安装一个与中间件通信的介入层，该组件负责代表中间件在其本地DBMS实例上执行查询并返回结果。 总之，中间件产品向应用程序提供单个逻辑数据库，而无需修改底层DBMS。
使用sharding中间件的关键优势在于它们通常是已经使用现有单节点DBMS的应用程序的直接替代品。 开发人员无需对其应用程序进行任何更改即可使用新的分片数据库。 中间件系统最常见的目标是MySQL。 这意味着为了与MySQL兼容，中间件必须支持MySQL网络协议。 Oracle提供了MySQL Proxy [13]和Fabric [12]工具包来完成这项工作，但是其他人已经编写了自己的协议处理程序库来避免GPL许可问题。
虽然中间件使得企业可以轻松地跨多个节点扩展数据库，但是这样的系统仍然必须在每个节点上使用传统的DBMS（例如，MySQL，Postgres，Oracle）。 这些DBMS是基于20世纪70年代开发的面向磁盘的体系架构，因此它们不能使用针对面向内存的存储进行优化的存储管理器或并发控制方案，就像在一些构建在新体系结构上的NewSQL系统一样。 之前的研究表明，面向磁盘的体系结构的遗留组件是一个重要的障碍，阻碍了这些传统的DBMS纵向扩展以利用更高的CPU核心数和更大的内存容量[38]。 对于复杂查询中间件的方式还会触发在多个分片节点上查询规划和优化器优化工作的冗余（即在中间件上一次，在单个DBMS节点上还会再来一次），但这确实允许每个节点根据自己的本地优化器优化每个查询。
示例：AgilData Scalable Cluster 2 [1]，MariaDB MaxScale [10]，ScaleArc [15]，ScaleBase3。
3.3 DBaaS 数据库云服务
最后还有一些云计算提供商提供数据库即服务（DBaaS）类型的NewSQL产品。 通过这些云服务，企业无需在物理机或云托管虚拟机（VM）上维护DBMS。 相反DBaaS供应商负责维护数据库的物理配置，包括系统调优（例如buffer_pool_size），数据复制和备份。云供应商向客户提供DBMS的URL供客户连接使用，同时提供一个前端运维仪表板或控制DBMS系统的API给客户。
DBaaS客户根据他们预期的应用程序的资源利用率进行付费。 由于数据库查询在使用计算资源的方式有很大差异，所以DBaaS提供商通常不会像在面向块的存储服务（例如，亚马逊的S3，Google的云存储）中计量每次操作那样根据查询调用统计进行计费。 相反客户根据价格清单进行付费，该定价清单指定提供商将保证的最大资源利用率的阈值（例如，存储大小，CPU能力，内存大小等）。
与云计算的大多数方面一样，由于规模效应，DBaaS领域的主要玩家还是那些云计算大公司， 但几乎所有的DBaaS都只提供传统单节点DBMS（例如MySQL）的托管实例，知名的例子包括Google Cloud SQL，Microsoft Azure SQL，Rackspace Cloud Database和Sales-force Heroku。 我们不认为这些是NewSQL系统，因为它们使用的底层技术还是20世纪70年代的面向磁盘的技术架构。 像微软的一些供应商则改进了他们的DBMS，以便为多租户部署提供更好的支持[21]。
我们只将那些基于新架构的DBaaS产品视为NewSQL。 最知名的例子是亚马逊的Aurora，用在他们自己的MySQL RDS服务中。 它与InnoDB的核心区别在于它使用结构化日志的存储管理器来改善I/O并行性能力。
还有一些公司不维护自己的数据中心，而是销售在公有云平台上运行的DBaaS软件。 ClearDB提供了自己的定制化DBaaS，可以部署在所有主要的公有云平台上。 这具有以下优点：它可以在相同地理区域中的不同提供商之间分发数据库，以避免由于服务中断而导致的停机。
截至2016年，Aurora和ClearDB是NewSQL这个类别中唯一可用的两种产品。我们注意到这个领域的几家公司都失败了（例如，GenieDB，Xeround），迫使他们的客户争相寻找新的提供商并将他们的数据迁出在他们关闭之前的那些DBaaS。 我们将其失败归因于产品过于领先市场需求以及主要供应商的价格过高。
如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！
赞3
添加新评论0 条评论