“One Size Fits All”：一个过时的想法？| StoneDB 学术分享会 #8

审校：李浩、宇亭

设计：Yeekin

责编：宇亭
 

导语

本篇是StoneDB学术分享会专栏的第八篇，在上一期里，我们分享了SAP 发表的 《Efficient Transaction Processing in SAP HANA Database – The End of a Column Store Myth》，主要介绍了 SAP HANA 数据库如何通过列式存储实现同时在分析型和事务型工作负载环境中进行高效工作，从而号召大家终结对列式存储的偏见。

有心的同学可能会注意到，我们接连三期分享了 SAP 发布的论文，都是讲SAP 如何实现 HTAP 系统架构的，而且，似乎SAP 非常想向大家证明：我一个数据库是可以做到既能处理事务（OLTP）又能处理分析（OLAP）的，而且性能还挺好，几乎完美。

不过，这好像就是在说：咱们 SAP 的 HANA 是可以做到 “One Size Fits All” 的！看起来是和咱们今天的标题宣战呢~

没错，SAP 宣战的不是别人，正是数据库领域的祖师爷级别人物 Michael Stonebraker 先生（顺带一提，我们之所以叫 StoneDB 其实有一层含义就是为了致敬 Stonebraker 先生），在 2005 年的 ICDE 上，Stonebraker 发表了一篇名为《“One Size Fits All”: An Idea Whose Time Has Come and Gone》的文章，正式向学术界和工业界宣布：“One Size Fits All” 的理论过时了哈，一种类型一个数据库，才是常态，你看看，我OLAP搞了一个，OLTP搞了一个，内存数据库也搞了一个，总之，你得分门别类地每样搞一个！（这样大概就会很好卖）

后面的事情，熟悉数据库圈子的也都知道了，SAP 在 4 年之后的 SIGMOD 2009 年上当着 Stonebraker 的面介绍了他们研发出的的“One Size Fits All”—— SAP HANA，可以说是当众打了大佬的脸。

但是，大佬就不可以被打脸么？我倒觉得 SAP 还是挺有勇气的，如果没有像 SAP 这样的后起之秀扛起大旗来发出自己的声音，或许，十几年后的今天，数据库圈子都不敢再谈 HTAP 了。抛去商业界的竞争较量，我们回归到学术领域，仔细阅读 Stonebraker 先生的这篇文章，其实还是非常有理有据的，从狭隘的商业视角看，“One Size Cannot fit All”可能是为了某种商业营销，不过，从宏观的技术视角看，也正因为有了这个理论，我们如今的数据库产品种类才能如此繁荣多样。当然，此篇论文的观点仅供参考，读者应该有自己的判断，今天，就让我们来学习一下这篇经典论文吧~

摘要
 

过去25年间的商业数据库管理系统（database management system，DBMS）的发展可以用一个词来概括：“One Size Fits All”。“One Size Fits All”阐述了这样一个事实：传统的 DBMS 架构最初是为处理业务数据而设计和优化的，但如今却被用来支持许多以数据为中心的应用，这些应用在特征和要求上存在着巨大的差异。

本文论证了“One Size Fits All”的策略不再适用于数据库市场。数据库市场将被一系列的独立的数据库引擎切分成无数个细分市场。当然，在这些数据库引擎中，也许有一部分可以通过一个通用的前端解析器统一起来。本文使用流处理市场和数据仓库市场作为例证来支持我们的观点。在本文中，我们还简要讨论了传统架构在其他市场中存在的水土不服的情况，并指出应该对将系统服务考虑进产品中的做法进行批判性思考。

一、简介

关系型 DBMS 在20世纪70年代以 System R【10】和INGRES【27】作为产品原型出现。这两个原型的定位是在应用（即“业务数据处理”）上超越 IMS 对客户的价值。因此，这两个系统都是为联机事务处理（online transaction processing，OLTP）应用而设计的，它们的商业化产品 DB2 和 INGRES 在20世纪80年代得到了市场的认可。Sybase、Oracle、Informix 以及其他供应商也遵循了相同的基础 DBMS 模型。该模型逐行存储关系表，使用 B-tree 进行索引，使用基于成本的优化器，并提供 ACID 事务属性。

自20世纪80年代初以来，主要的 DBMS 供应商一直坚持“One Size Fits All”的策略，即所有的 DBMS 服务使用同一行代码。选择这种策略的原因很简单――使用多行代码会导致各种实际问题，包括:

• 成本问题：维护成本会随着代码行数线性增长，甚至增长得更快。

• 兼容性问题：所有的应用都必须能够支持每一行代码。

• 销售问题：销售人员不知道该向顾客推销哪种产品。

• 营销问题：如果使用多行代码，那么每一行代码必须有清晰、准确的市场定位。

为了避免这些问题，所有的主流 DBMS 供应商都遵循集中精力做一款产品的行业策略。本文我们主要论证这种策略在当下的数据库市场中早已行不通了，并且使用这种策略的缺点会逐渐全面地暴露出来。

本文的框架结构如下：第2章通过引用数据仓库市场的一些关键特征简要说明为什么一行代码闯天下的策略已经行不通了。第3章讨论流处理应用，并用一个案例来说明了流处理引擎比关系型 DBMS 在性能上高两个数量级。承接第3章，第4章讨论了造成这种性能差异的原因，并指出了传统 DBMS 技术缺乏市场竞争力这一事实。基于此，我们判断流处理引擎将成为 DBMS 市场发展的趋势。第5章讨论了一系列“One Size Fits All”策略可能不适用的市场。这些市场需要专门的数据库系统。DBMS 市场可能会被细化切分。第6章提供了一些我们关于将系统软件分解成产品的看法。最后，在第7章我们对我们的观点进行了总结。