有关NOSQL与SQL的对比外文翻译

SQL数据库与NoSQL数据库的对比

迈克尔·斯通布雷克考虑了几个支持NoSQL数据库的性能参数并且发现它们的不足之处

最近，出现了很多关于NoSQL数据库的声音。事实上，在2009年至少有两个关于这个主题的顶级会议，东西海岸各有一个。表面来看，这些声音来自以下技术的支持者：文档样式存储的数据库记录由键-值对的集合和一个负载组成。这类系统的例子有CouchDB 和MongoDB，为了简单起见,我们称这样的存储为系统文档存储。

键值存储的记录由key-payload对组成。通常,这些都是由分布式哈希表实现,为了简单起见,我们称它为键值存储。这类例子有MemcacheDB和Dynamo。

在这两种情况下，通常得到一个低级、一次一记录的数据库管理系统(DBMS)接口而不是SQL系统。因此,这群人将自己标识为NoSQL的追随者。

有这两种可能的原因倾向于这两种可交替的DBMS技术:性能和灵活性。

性能方面的争论大致如下：刚开始时我为了数据存储需求完全使用MySQL，随着时间的推移发现性能不合适。我的选择是：

1.将数据分区横跨多站点处理，但在应用程序上管理分布式数据十分困难。

2.狂热追求MySQL并向SQL数据库管理系统企业支付大额许可费或使用除了SQL数据库管理系统的平台。

弹性方面的争论大致如下:我的数据不符合严格的关系模式。因此,我不能受RDBMS的结构的约束,需要更高的灵活性。

这篇博文介绍了性能方面的争议，随后将详细说明在灵活性方面的争议。为简单起见，我们将重点讨论NoSQL数据库通常被认为的工作负载：更新，密集查找，在线事务处理，非密集查询，数据仓库的工作量。我们不考虑文档存储库或其他专门的NoSQL系统可能适合的工作负载。

有两种方法可以提高在线事务处理（OLTP）的性能;即,在无共享处理环境下提供自动分片处理和提高单台服务器的在线事务处理（OLTP）性能。

第一种情况，是通过向计算环境里添加节点提高扩展性来增加性能。第二种则是提高各个节点的性能。

每一个像Greenplum, Aster Data, Vertica,ParAccel的正式的SQL DBMS，如果不这样做的话在过去十年里就不会共享伸缩技术，任何新的进步也会变迟缓。因此,该组件的性能应该是DBMS的赌注。在我看来,没有人能够运行一个越过计算节点,不提供自动切分的数据库管理系统。

所以，该帖继续分析其他的组件。也就是，单节点OLTP的性能。在传统数据库中与OLTP数据库有关的总开销跟系统没有关系，这就是为什么说“NoSQL”这个词用的不当的原因。

相反，OLTP SQL DBMS的主要开销是通过使用ODBC或JDBC用在与DBMS进行通信上。基本上所有的性能敏感的应用都使用存储程序接口去运行DBMS内的逻辑，避免在应用程序和DBMS间来来回回交流带来的损失。别的替代方案是在一个相同的地址空间里像运行一个应用程序一样去运行DBMS，从而放弃了访问控制和安全的借口，这样的嵌入式数据库管理系统在一些环境中是合理的，但不是对主流的OLTP而言的，因为在那安全是个很热闹重要的事。

不论是使用存储程序还是嵌入方式，有效的负载成分只占OLTP数据库总的

事物成本的很少的一部分，它通常适合在内存里运行。另外，一个最近发表的论文计算出总的OLTP时间在以下四部分开销的分配几乎是相同的：

日志记录

传统的数据库把东西都写两遍，一次写到数据库，另一次写到日志。此外，日志必须写到磁盘上以保证事物的持久性。所以，日志记录是一个高花费的操作。

加锁

在接触记录前，一个事物必须在锁表里为它加一个锁。这也是一个开销集中的操作。

封锁

更新到共享的数据结构，像B树，锁表和资源表，在一个多线程的环境中一定要小心。典型的是，这里会有短时间的封锁，这是另外一个开销。

缓冲区管理

传统系统中的数据存储在固定大小的磁盘页中。一个缓冲池管理在内存中任何时刻的缓冲的磁盘页记录。另外，记录必须位于分页上，边界是确定的。

还有，这样的操作也是开销集中的。

如果能够消除以上的开销中的任何一种，DBMS能提速25%。消除三个DBMS 的速度会被两个因素中的一个限定。必须把这四个都消除才能更大幅度的提高速度。

尽管NoSQL系统有各种各样的与众不同的特征，但还是有一些常见的特性，第一，许多的NoSQL系统管理分布在多个站点的数据，提供上面提及的赌注。显然，一个设计好的多位点的系统，不管是不是基于SQL的，比单位点系统有更好的可扩展性。

第二，许多的NoSQL系统以磁盘为基础并保留了缓冲池和多线程的体系结构。这样就会使上面提到的四分之二的开销保持完整。

就事物而言，通常是支持单事物和最终一致性的系统，认定事物是可以交替的。为了效率，ACID黄金标准做出了牺牲。

然而，网络到网络是NoSQL单节点的性能表现，基于磁盘的，不遵循ACID，多线程是它比一个设计好的存储过程SQL OLTP快的原因。本质上，为了性能的提高，ACID事物被放弃，这个性能的提高和SQL没有关系。

但是，鱼与熊掌都可兼得。为了更快速，需要有一个链接到执行时系统存储过程，它能编译高级语言到低级语言代码。另外，还需要消除那四个开销。

最近的一个项目清楚地表明这是可行的，并且在TPG-G展示了很好的性能。期待会有商业的版本和开源的封装。所以，我期待高速，开源的能够提供自动分片功能的SQL引擎在不久的将来会出现。另外，将会随着编程生产率的提高继续提供ACID事物特性，SQL提供的低维护成本和更好的数据独立性。因此，获取高性能没必要抛弃SQL或ACID事物。

概括来说，好的性能依赖于消除开销。这样的开销与SQL无关，反而与传统的ACID事物的实现，多线程，和磁盘管理有关系。为了更快，必须消除上面提到的那四个开销。这在任意的一个SQL或是别的的配置指令中都可能会发生的。