ACM通信
“无SQL”的讨论与SQL无关
最近，有很多关于“无SQL”数据库的讨论。事实上，2009年至少有两场关于这一主题的会议，每个海岸都有一次。似乎这种说法来自于以下人士:
•文档风格的存储，其中一个数据库记录由(键，值)对的集合和一个有效载荷组成。这类系统的例子包括CouchDB和MongoDB，我们称之为这类系统文档存储为简单起见
•键-值存储，其记录由(键，负载)对组成。通常，这些都是通过分布式哈希表(dht)实现的，我们称之为dht键值存储为了简单起见。例如Memcachedb和Dynamo。
在这两种情况下，人们通常得到一个低级的DBMS接口，而不是SQL。因此，这个团体认为自己提倡“无SQL”。
使用这两种DBMS技术可能有两个原因:性能和灵活性。
关于性能的争论大致如下。我开始使用MySQL来满足我的数据存储需求，随着时间的推移，我发现它的性能不够好。我的选择是:
1.“碎片”我的数据，把它划分到几个站点，让我在我的应用程序中管理分布式数据非常头疼
或
2.放弃MySQL，为企业SQL DBMS支付大笔许可费用，或者转移到SQL DBMS以外的东西。
关于灵活性的论点如下所示。我的数据不符合严格的关系模式。因此，我不能被RDBMS的结构所束缚，而需要一些更灵活的东西。
这篇博文考虑了性能方面的争论;后续的帖子将讨论灵活性的问题。
为了简单起见，我们将重点讨论NoSQL数据库最常考虑的工作负载:更新和查找密集的OLTP工作负载，而不是查询密集的数据仓库工作负载。我们不考虑NoSQL系统可能非常适合的文档存储库或其他专门的工作负载。
有两种方法可以提高OLTP性能;即，在无共享处理环境上提供自动“分片”，并提高每台服务器的OLTP性能。
在第一种情况下，当节点被添加到计算环境中时，可以通过提供可伸缩性来提高性能;在第二种情况下，可以提高单个节点的性能。过去10年里编写的所有严肃的SQL DBMS(例如Greenplum、Asterdata、Vertica、Paraccel等)都没有提供任何共享的可伸缩性，如果没有提供类似的可伸缩性，那么任何新的努力都将是疏忽。因此，对于任何DBMS来说，这一性能组成部分都应该是“表赌注”。在我看来，任何人都不应该运行一个没有在计算节点上提供自动分片的DBMS。
因此，这种发布将继续使用其他组件，即单节点OLTP性能。在传统SQL系统中，与OLTP数据库相关的开销与SQL几乎没有关系，这就是为什么“NoSQL”是一个错误的称呼。
相反，OLTP SQL DBMS中的主要开销是使用ODBC或JDBC与DBMS通信。本质上所有对性能敏感的应用程序使用存储过程接口在DBMS内部运行应用程序逻辑，并避免应用程序和DBMS之间来回通信的严重开销。另一种选择是在与应用程序相同的地址空间中运行DBMS，从而放弃任何访问控制或安全性的伪装。这样的可嵌入dbms在某些环境中是合理的，但不适合主流OLTP，因为在主流OLTP中安全性是一个大问题。
使用存储过程或嵌入，有用的工作组件只占总事务成本的很小百分比，对于今天的OLTP数据库来说，它通常可以放在主存中。相反，最近的一篇论文[1]计算出，OLTP总时间几乎平均分配给以下四个开销组件:
日志记录:传统数据库将所有内容写两次;一次到数据库，一次到日志。此外，必须将日志强制存储到磁盘上，以保证事务的持久性。因此，日志记录是一项开销很大的操作。
锁定:在接触一条记录之前，事务必须在锁表中对它设置一个锁。这是一项开销很大的行动。
自锁:对共享数据结构(b -树、锁表、资源表等)的更新必须在多线程环境中小心完成。通常，这是通过持续时间较短的锁存来完成的，这是另一个相当大的开销来源。
缓冲区管理:传统系统中的数据存储在固定大小的磁盘页面上。缓冲池管理在任何给定时间缓存到内存中的磁盘页集。此外，记录必须位于页面上，并确定字段边界。同样，这些操作开销很大。
如果消除了上述任何一个开销组件，DBMS的速度就会提高25%。排除3个，你的加速将受到2个因素的限制。你必须摆脱这四种，才能跑得更快。
尽管No SQL系统具有各种不同的特性，但仍有一些共同的主题。首先，许多管理跨多个站点分布的数据，并提供上面提到的“表桩”。显然，一个设计良好的多站点系统，无论是基于SQL还是其他的，都比单站点系统更具可伸缩性。
其次，许多No SQL系统都是基于磁盘的，并且保留缓冲池和多线程体系结构。这将使上述四个开销来源中的两个保持不变。
关于事务，通常只支持单个记录事务和最终的一致性复制系统，这假定事务是可交换的。实际上，ACID事务的“黄金标准”是为了性能而牺牲的。
然而，一个NoSQL的、基于磁盘的、非acid的多线程系统的单节点性能被限制在比一个设计良好的存储过程SQL OLTP引擎快一个适度的因素。从本质上说，放弃ACID事务是为了获得适度的性能提升，而这种性能提升与SQL无关。
然而，鱼与熊掌是可以兼得的。要想加快速度，需要有一个到运行时系统的存储过程接口，该接口将高级语言(例如SQL)编译为低级代码。此外，你必须摆脱以上四种开销来源。
最近的一个项目[2]明确表明这是可行的，并在TPC-C上显示了出色的性能。注意使用开源包装的这些商业版本和类似想法。因此，我完全期待在不久的将来能够提供自动分片的非常高速、开源的SQL引擎。此外，它们将继续提供ACID事务，同时提高了SQL提供的程序员生产力、更低的维护和更好的数据独立性。因此，高性能不需要抛弃SQL或ACID事务。
总之，盲的性能取决于减少开销。这种开销与SQL无关，而是围绕着ACID事务、多线程和磁盘管理的传统实现。要想更快，就必须消除上面讨论的所有四种开销来源。这在SQL上下文中或其他上下文中都是可能的。
参考文献
[1] S. Harizopoulos等人，“透过镜子，我们在那里发现了什么”，2008年SIGMOD会议，温哥华，bc省，2008年6月
[2] M. Stonebraker等人，“一个建筑时代的终结(是时候彻底重写了)”，2007年VLDB会议，维也纳，奥地利，2007年9月
披露:Michael Stonebraker与四家创业公司有关联，这四家公司要么是数据库技术的生产者，要么是消费者。因此，他的意见应该从这个角度来考虑。
评论
约翰内斯·恩斯特
在您的讨论中，您似乎遗漏了NoSQL运动的其他几个子类。例如:谷歌的BigTable(及其克隆)以及图形数据库。考虑到其他因素，这会改变你的观点吗?
Dwight Merriman
迈克尔,
在我看来，面向文档数据库的典型使用中出现的反规范化改进了性能:一个具有嵌套对象和/或数组的复杂文档可能在rdbms中有10行，而不是一个连续的数据块。你同意吗?
CACM管理员
Dwight Merriman的评论是:
我在我的博客中谨慎地指出，NoSQL数据库可能在文档存储库中具有优势。这种可能性有多种原因，包括去规范化(您的讨论)、关键字检索和语义标记。
——迈克尔Stonebraker
CACM管理员
关于Johannes Ernst的评论:
我是“一刀切”的忠实粉丝。SQL引擎的几种实现具有非常不同的性能特征，还有大量其他引擎。除了您提到的这些存储之外，还有数组存储(如Rasdaman)和RDF存储(如Freebase)。我赞赏构建面向特定市场需求的dbms的努力。
这篇博客文章的目的是讨论NoSQL运动中的主要参与者(在我看来)，因为他们与基本事务处理(OLTP)有关。我的结论是，“NoSQL”实际上意味着“无磁盘”或“无ACID”或“无线程”，也就是说，OLTP市场的速度并不来自于放弃SQL。你所描述的努力以及上面段落中的努力都不是针对OLTP的。我的博客评论仅限于OLTP，我想我已经说得很清楚了。
——迈克尔Stonebraker
约翰Ousterhout
你声称可伸缩的性能在“过去10年里编写的所有严肃的SQL DBMS”中都是可用的，这意味着我可以增加更多的服务器来扩展数据集的总大小和oltp风格事务的速率(即大量的小事务，而不是少数的不断增加的大事务)。
但是，我还没有找到一个大型Web应用程序的例子，它能够通过一个一致的rms系统来满足它的需求。另一方面，有许多站点声称已耗尽可伸缩性，最终将数据划分到独立的rms实例或构建NoSQL系统(Amazon、Facebook、谷歌、Yahoo和Ebay，仅举几例)。你能给我们举出几个成功的例子来反驳人们普遍认为RDMBS系统无法扩展的观点吗?
CACM管理员
我的评论特别提到了数据仓库市场，Greenplum、Asterdata、Paraccel和Vertica都是线性扩展的。此外，包括Teradata、Netezza和DB2在内的老系统也是线性扩展的。微软今年将推出他们的DataAllegro与SQLServer的集成。它被称为线性扩展。参见Andy Pavlo等人在SIGMOD 2009上的论文，获得Vertica和一个未命名的主要RDBMS供应商的一些示例数字。
但是，您问的是OLTP市场，而不是数据仓库市场。这里有两个考虑因素:可切分性和碰撞频率。一个应用程序是可分片的，如果有一种方法来分区你的数据，使大多数事务是本地的单个节点。冲突频率是指并行事务接触相同数据项的频率。简并的情况是一个记录数据库，它将具有100%的碰撞频率。
如果您的数据是可分片的，并且冲突频率很低，那么DB2应该是线性扩展的。同样，在MySQL和Postgres之上的无数层，例如EnterpriseDB，也应该做同样的事情。如果你的数据是可分片的，不管碰撞频率如何，voldb(现在在beta中;下个月投入生产)已经被证明是线性扩展的。
如果您的数据不可分片，那么每个人处理分布式事务的速度都会变慢。有些系统不支持分布式事务，这只会把问题推到应用程序逻辑中，从而导致性能下降。我认识的大多数人处理这个问题的方法是找到一种方法来重新调整他们的应用程序，使其可分片。EBay(你在帖子中提到的)就是采用这种方法的一个很好的例子。
迈克尔·斯通布雷克，2010年4月19日
约翰Ousterhout
谢谢你的回复;我还有几点看法:
*我很困惑:你说你的评论提到了数据仓库市场，但我的理解是整个博客帖子实际上是关于OLTP的。引用文中的内容:“我们将重点讨论NoSQL数据库最常被考虑的工作负载:更新和查找密集型的在线事务处理工作负载(OLTP)，而不是查询密集型的数据仓库工作负载。”博客中对Greenplum、Aster Data等的引用是否与OLTP相关?
*你的回复给出了一些关于为什么RDBMS可以扩展到OLTP的一般性论点，这些论点似乎是合理的，但我真正想看到的是一个成功的故事(不是供应商的声明，而是有人会站出来描述他们的OLTP应用程序是如何使用跨越多个节点的单一RDBMS系统实现高规模的)。如果RDMSes可以扩展(在任何合理的条件下)，那么肯定会有一个我们都可以参考的例子，而且我猜您是最有可能听说过它的人之一。你能告诉我们什么吗?在缺乏一个令人信服的成功故事的情况下，许多人会相信那些声称RDBMS不能为OLTP扩展的反对者，特别是考虑到许多站点不能扩展他们的RDBMS系统而转向NoSQL的例子。
顺便说一下，我不认为eBay有资格成为我定义下的一个成功故事:他们将数据分割成多个独立的非伸缩RDBMS，而不是单一的伸缩RDBMS，对吗?
约翰·拉辛
我看到的SQL的主要问题是，它通常是一个从服务器到客户端的批数据传输系统，需要锁定许多记录以确保数据完整性，这也增加了锁定其他记录的可能性，这些记录甚至可能在那个时刻没有被更新。我想这会违反原子性。为了解决这个问题，许多SQL数据库在编程时没有更新锁，这在当时看起来是ok的，因为他们认为其他人试图在同一时间访问相同信息的可能性很低，然而，现实是有许多类型的记录被重复更新。这违反了持久性，因为一个人的更新会被另一个人删除，至少会留下无子记录的父记录和无父记录的子记录。将数据分解为标题记录和详细记录进一步违反了原子性，因为像销售订单记录这样属于一个整体的项目被分成许多部分，然后分布在磁盘驱动器上，必须重新组装才能重新创建销售订单这样的简单内容。关联数组可以在一个记录中保存一个销售订单，尽管其中包含到客户信息(如客户名称、地址等)的关系链接。
与关联数组看起来一样复杂，多表连接可能更复杂，它们的输出甚至更难解释，因为数据的关系不是透明的。NoSQL关系数据库仍然可以提供关系链接和真正的数据库设计，而不需要总是将数据分离出来，或者实际上总是将数据放在关联数组中。它提供了设计的自由度，同时提供了更高级别的数据完整性，因为它能够只锁定需要锁定的单个记录。它提倡一般使用锁定策略，因为这样的策略变得实用。
注意，我指的是Pick的NoSQL类型。还要注意，现在大多数Pick系统都有用于查询的SQL接口。然而，如果可以选择的话，大多数人更喜欢TCL接口。这些新的NoSQL系统的另一个特点是哈希表。Pick/MultiValue一直都有这些，它们比索引有了很大的改进。现在大多数Pick系统都有索引，但这不是它们的主要访问方法，使用次数可能是常规SQL系统的1/100或1/1000。考虑到文件索引臭名昭著的易错性，这是一个很大的优势。它还改进了原子性，因为在记录更新时索引不必更新，至少不像SQL系统中那样频繁。
在我的头脑中，我看不出SQL和NoSQL在一致性和隔离方面有什么主要的区别。我不太确定它们在这种情况下是什么意思。在关系型NoSQL (Pick是，而不是全部是)中，可以像SQL一样，根据不同的表/文件共享和访问数据。主要的区别是必须的约束，这是SQL的约束，而Pick/MultiValue没有。
我发现关联数组是一种比数据头/细节排列更真实的数据模型。多值比SQL用户让您相信的要常见得多，在某些应用程序中，多值和关联是常态，而不是例外。
性能是NoSQL和Pick经常声称的一件事，我们发现它是正确的，但差异并不总是那么重要。与SQL相比，MultiValue/Pick/NoSQL数据库在数据完整性方面得到了改进，并发问题少得多，查询更容易，数据结果更容易理解，数据模型与现实世界之间的关系更密切，以及拥有更灵活和更有想象力的数据库设计的能力。
SQL在市场上已经超过MultiValue，这主要是由于SQL系统通常具有的用户界面优势。这为SQL带来了更大的投资、系统知名度和市场竞争力。UI的优势正在消失，但是SQL享有这样的领先优势，特别是在名称识别方面，多值系统面临着一场艰难的战斗。尽管为MultiValue编写的应用程序比世界上任何其他数据库都要多(有些应用程序早在20世纪60年代就存在了，至今仍在使用)，但大多数应用程序都有古老的UI，而且重新创建UI的成本太高，以至于许多应用程序正在慢慢被抛弃。我们中那些能够提供UI解决方案的人，比如AccuTerm和我的BB4GL，每次有人看到我们的产品时都很享受关注。我无法按照自己的意愿来销售我的产品。有几次，我发布了新闻稿，很快就收到了询问，如果当前的市场能够维持新的企业，我就会有客户，那些忙着让自己的脑袋不被当前的经济飓风所淹没的客户，他们无法接受新的企业。我经常收到来自世界各地的人们的询问，他们只是碰巧看到了我很少访问的网站，我无法在网络目录中推广它，尽管它很少访问，但受到了关注。
今晚晚些时候我会读Stonebraker的文章。我只是想向您介绍一个在SQL和NoSQL系统上工作了很多年的人(我)的观点。对我来说，NoSQL意味着不仅仅是SQL，而不仅仅是没有SQL。在Pick中，我们有允许访问和处理关联数组数据的SQL短语，所以并不一定是非此即彼的情况。
日志记录:由于必须记录更多的记录和更多的数据页，因为头记录和详细记录相对于具有关联数组的组合记录是分开的，所以在SQL中必须发生更多的日志记录事务。
锁定:正如我已经提到的，当存在独立的详细记录和头记录时，必须锁定更多的记录，特别是当详细记录分布在多个磁盘页面上时。
锁存:同样，由于SQL中涉及更多的单独记录，必须进行更多的锁存来管理这些记录。
缓冲区管理:必须从磁盘驱动器读取更多的数据，以便为相同的网络记录集提取相同数量的数据(使用我的一个简单销售订单的示例;关联数组中有20行详细信息的销售订单需要一次或两次磁盘访问，而在SQL环境中检索一个订单至少需要21次。
最后，性能不是MultiValue系统的主要优势:数据完整性、更好的并发性、更容易理解的查询、更少的复杂表连接，以及创建更灵活和更有想象力的数据库设计的能力，这些在MultiValue系统中更重要，也更好。然而，MultiValue的性能优势是存在的，而且并不糟糕，如果你原谅我的法语!
约翰·拉辛
此外，SQL对原子性的看法是将原子分解为电子、中子和质子，这违反了原子的同一性。使用我前面的例子，销售订单的MultiValue关联数组将销售订单的原子保持在一起。SQL会将其分解成电子等，而不是原子，从而失去其身份。原子根据它们的组成有不同的特性，而电子没有。一个销售订单在组合在一起时意义重大，但是当它的细节行与标题和其他细节行(以及它们的和)分离时意义不大。这些细节行对于系统上的任何其他数据都没有任何意义，除非与该头文件相关联，而MultiValue提供了在出现这种罕见情况时非常容易且有用的提取细节数据的方法。
约翰·拉辛
注:如果你不了解Pick/MultiValue，它是当今世界上使用最广泛的数据库之一，它有许多不同的名称，包括Sequoia(容错系统的先驱)，D3, mvBase, mvententerprise, AP, General Automation, Mentor, Ultimate, Revelation, OpenInsight, Reality, Microdata (McDonnell Douglas)， Applied Digital Data systems(也是一个流行的终端制造商)，NCR, IBM U2 (UniVerse & UniData)， Rocket Software, Intersystems Cache, NorthGate, jBase, OpenQM，Maverick, ONWare, Prime信息系统和UniVision。美国一半的大学和学院使用数据表应用程序，这是一个多价值系统，来运行他们的行政，学术，日程安排，账单等。英国的主要银行使用Pick作为他们的主要系统。美国最大的工业供应公司休斯供应(Hughes Supply)使用Pick来运营其业务。