ACM通信
DBMS时代的终结(可能就在我们身上)
关系数据库管理系统(DBMS)在占领DBMS市场方面取得了显著的成功。粗略地说，他们是“城里唯一的游戏”，主要的供应商(IBM、Oracle和微软)享有压倒性的市场份额。他们销售的是“一刀切”;例如，适合所有DBMS需求的单一关系引擎。此外，所有主要供应商的代码行都相当古老，在所有情况下都可以追溯到20世纪80年代。因此，主要的供应商销售的软件是四分之一个世纪以前的，并且已经扩展和变形以满足今天的需求。在我看来，这些遗留系统的使用寿命已经到头了。他们应该被送到“老软件之家”。
这是为什么。
如果我们考察一下规模不小的DBMS市场，就会发现在我能想到的大多数市场中，当前的关系型DBMS都可能被击败大约50倍。下面是一些例子。
在数据仓库市场中，在典型的业务智能查询中，列存储比行存储大约高出50倍。这是因为列存储只读取查询感兴趣的列，而不是所有列。此外，在列存储中压缩更有效。由于遗留系统都是行存储，它们很容易受到来自较新的列存储的竞争。感兴趣的读者可以从“C-Store:一个面向列的DBMS”开始进一步探索这个主题。
在在线事务处理(OLTP)市场上，轻量级的主存DBMS比行存储高出50倍。利用主内存和没有DBMS应用程序会在事务中间向人类用户发送消息这一事实，允许OLTP DBMS在没有资源争用或锁定开销的情况下运行事务直到完成。感兴趣的读者可以从“一个架构时代的终结(是时候彻底重写了)”开始进一步探索这个话题。
在科学DBMS市场上，用户从来都不喜欢关系型DBMS，他们想要一个非关系型模型和查询工具。这是我上一篇ACM博客的主题，科学应用的dbms:一种可能的解决方案。
如果您正在存储资源描述框架(Resource Description Framework, RDF)数据，这在生物社区和其他地方很流行，那么“使用垂直分区的可伸缩语义Web数据管理”指出，列存储非常适合于某些RDF工作负载。此外，其他想法，如“RDF- 3x: RDF的risc风格引擎”，在其他情况下将击败传统的dbms。最后，原生RDF引擎(例如，Virtuoso、Sesame和Jena)很可能获得支持。关键是，在这个市场上，其他东西将击败传统的行商店。
文本应用程序从未使用过关系dbms。Eric Brewer在大约15年前的Inktomi早期向我明确指出了这一点。他想使用关系DBMS来存储Web抓取的结果，但发现RDBMS比自制系统慢两个数量级。所有主要的网络搜索引擎都使用自制文本软件为我们提供搜索结果。没有使用关系dbms。
根据Dave Kellogg的私人通信，即使是在当前主要供应商花费大量精力扩展其引擎的XML中，据说像Mark Logic或Tamino这样的专门引擎也会绕过主要供应商。
总而言之，至少可以利用以下思想来获得更好的性能:
非关系数据模型。如果用户的数据自然不是表，并且在表上模拟他的自然数据模型很尴尬，那么自然数据模型的本机实现很有可能大大优于传统的RDBMS。这在科学数据中当然是正确的。
表的不同实现。如果行存储以外的东西加速了用户的查询，那么使用非行存储技术的关系模型的直接实现将绕过传统的RDBMS。这在数据仓库市场中是正确的。
事务的不同实现。当前行存储为您提供了“一刀切”的事务实现。如果用户的需求较少，或者系统可以利用特定于工作负载的特性，那么这种情况可能会被彻底打破。这在OLTP市场中是正确的。
其中一个特点适用于我能想到的所有市场。因此，在我看来，“一刀切”的单一DBMS时代已经结束了。取而代之的将是一系列垂直市场专用发动机，具有更高的性能。
您可能会问:“如果我不关心性能呢?”答案是:运行一个开放源码关系dbms。他们成熟、可靠，最重要的是，他们是自由的。
你也可以这样问:“我和现在的供应商关系很好。我该怎么办?”答案是:从DBMS预算中拿出一部分，分配给新的解决方案。随着时间的推移，你会转向更好的技术。
参考文献
Michael Stonebraker等人，“C-Store:面向列的数据库管理系统”，Proc 2005 VLDB会议，挪威特隆赫姆，2005年9月。
Michael Stonebraker等人，“建筑时代的终结(是时候彻底重写了)”2007年VLDB会议Proc，维也纳，奥地利，2007年9月。
Dan Abadi等人，“使用垂直分区的可扩展语义Web数据管理”，2007年VLDB会议，维也纳，奥地利，2007年9月。
Thomas Neumann等人，“RDF- 3x:用于RDF的risc风格引擎”，Proc VLDB Endowment, 1(1): 647-659 (2008)
披露:Michael Stonebraker与四家创业公司有关联，这四家公司要么是数据库技术的生产者，要么是消费者。因此，他的意见应该从这个角度来考虑。
评论
布拉德福德斯蒂芬斯
本文很好地总结了许多关于为什么RDBMS不再是那些数据需求确实必须扩展的人的可行解决方案的争论。我个人没有深入研究过RDF，但我同意数据存储需要反映数据的性质……而不仅仅是一堆表和行。
我也写了一篇关于它的文章，我鼓励你去看看，题为“社交媒体杀死数据库”，这是关于瑞士陆军RDBMS和它即将结束的。你可以在http://www.roadtofailure.com上查看
托尼·贝恩
当然，我们在某种程度上让自己走上了垄断数据管理单一技术的道路，并在很大程度上垄断了少数供应商。与此同时，多年来，RDBMS的替代方案在很大程度上遭到了质疑，而且从未真正得到接受，即使在RDBMS和需求之间明显存在脱节的情况下(尽管RDBMS供应商在试图改造他们的平台时，将一些糟糕的扩展捆绑在了一起)。
这种情况显然正在改变。传统形式的RDBMS(例如大规模可伸缩性)无法轻松解决一些困难但紧迫的挑战，这为新的方法和想法打开了大门。传统的关系型数据库管理系统当然会继续存在，但会在一个由替代数据管理策略组成的生态系统中存在。
孔雀舞雅苒
是的。多年来，RDBMS确实因为一些不太合理的原因而被过度炒作。当前的趋势还表明，有可行的替代RDBMS的方法，也可以在自己的游戏中击败它们。此外，分布式键值存储(如Cassandra、Voldemort)的出现证明了其方法的效率和成本效益。
最近结束的“NoSQL”会议还详细讨论了分布式非关系数据库的工作方式，并概述了该领域的新兴替代方案。
亚历山大Simonelis
dbms的一个主要好处是提高了程序员的工作效率，因为它将应用程序程序员从学习专门文件/系统及其内部结构的重要要求中隔离出来。无论这种好处实际上是多么有价值，当用专门的系统取代dbms时，它将完全失去。
安德鲁•沃尔夫
Michael Stonebraker完全有权表达他的观点，但是作为ACM的一名成员，我想根据我在8或9个(可能更多)商业关系数据库产品上25年的成功业务部署经验，表达一些相反的观点。
对于Stonebraker来说，在文本的关系存储的实用性以及当“声称”专门的XML引擎优于rdbms时我们如何解释它方面与我有不同意见是完全合理的。
类似地，他可能会说列存储与元组存储不同，而我可能会说唯一的区别是数据建模的选择。
他强调性能的好处，同时淡化或重新定义现在广泛使用的事务完整性的概念，这也是完全公平的。
但是，当Stonebraker声称用户的数据“自然不是表”，从而错误地描述了关系模型时，他从根本上错误地描述了关系数据分析。关系数据模型不称为“表格式”，关系的抽象也不是简单的数据输入形式。你只需要阅读Codd和Date就可以理解这一点。他们的整个供应商-部分-仓库示例展示了如何必须解构粗糙的表格表示，以获得良好的关系数据模型。Codd获得了图灵奖，因为关系抽象能够表示任何结构化数据。
在所有对模型或技术的有效批评中，“老”和“累”比无用更糟糕。我们相信技术建立在以前的发现之上，还是新技术抛弃了旧的发现?按照这样的标准，我们将停止教授布尔逻辑、图灵机和所有其他先于我们的东西。
计算机科学为我们提供了两种分析和管理数据复杂性的神奇工具:关系模型和语言理论。编译器技术几十年来一直是无懈可击的，因为有非常棒的底层抽象，比如与上下文无关的语法。关系模型的长寿源于其强大抽象的相似基础。我想说的是，至少在我们看到编译器的时候，我们会看到关系dbms。
为了充分披露，我是甲骨文公司的一名骄傲的员工，但我不以任何官方或非官方的身份代表甲骨文发言。
相反，令人失望的是，Stonebraker和ACM都没有通知我们ACM的其他成员他是Vertica Systems的首席技术官，Vertica Systems是一家“专栏商店”数据库供应商，其定位是优于关系技术的技术。
与所有的尊重,
小安德鲁·d·沃尔夫
CACM管理员
沃尔夫在他的帖子中似乎提出了三个主要观点:
1)关系模型是数据建模的最佳方法
2)列存储与行存储没有区别
3)老年软件不差。
我愿简要地回答每一点。
Wolfe先生在他的帖子中使用了商业数据处理的例子。人们普遍认为关系模型可能最适合大多数业务数据处理数据。事实上，Ted Codd、Chris Date和其他人(包括我)使用的所有早期示例都来自这个领域(例如，供应商、部件、员工、部门等)。在20世纪70年代和80年代，这是唯一重要的数据库市场。然而，我试图说明的一点是，现在有其他具有不同需求的大市场。
在科学领域，表很少是自然的数据模型，数组是更好的选择。科普包(例如MATLAB和S+)使用数组而不是表作为它们的用户模型。一旦离开了业务数据处理，关系模型的自然性就必须受到质疑。
列存储是关系模型的一种不同于主要商业供应商使用的行存储的实现。因为它们在查询处理、压缩和存储格式方面的体系结构选择与行存储不同，所以它们具有与行存储不同的性能信封。在典型的数据仓库工作负载中，列存储(专门为这个市场设计的)远远优于行存储。参见[1,2,3]了解这方面的一些详细说明。或者让您最喜欢的Web浏览器搜索列存储与行存储，以访问关于此主题的大量文献。
第三，我总是会想起航空管制计划(ACP)， IBM改名为TPF。它是很久以前用IBM汇编程序编写的，使用非常小的磁盘块，这是30多年前做出的架构决策，目的是优化当时的IBM磁盘驱动器(但现在显然已经过时了)上的处理。直到最近，这个架构决策才发生改变。因此，遗留代码的问题是，有些东西很难更改，并且在老代码行中存在。
我想到了另外两个例子。一个主要的数据库供应商想要将他的复制系统从active-passive更改为active-active。然而，他没有这样做，因为这太麻烦了。另一个DBMS供应商采用共享磁盘架构，因为实现无共享架构实在太难了。
除了技术问题，还有政治和商业问题需要处理。任何技术专家都会被建议去读Clayton christensen关于这个话题的书[4]。
——迈克尔·斯通布雷克，2009年9月4日
Mike Stonebraker等人，“C-Store:面向列的DBMS”，Proc. 2005年VLDB会议，挪威特隆赫姆，2005年9月。
[2] en.wikipedia.org/wiki/Column-oriented_DBMS。
Dan Abadi等人，“柱式商店与行式商店:它们到底有何不同”，2008年SIGMOD会议，加拿大温哥华，2008年6月。
[4]克莱顿·m·克里斯滕森:《创新者的困境》，《柯林斯商业精华》，1997年。
匿名
是的。多年来，RDBMS确实因为一些不太合理的原因而被过度炒作。当前的趋势还表明，有可行的替代RDBMS的方法，也可以在自己的游戏中击败它们。
显示所有7评论