对于大数据应用程序，SQL和NoSQL哪个更好?

在大数据项目中，企业面临的一个关键决策是使用哪个数据库，而这个决策常常在SQL和NoSQL之间摇摆。SQL拥有令人印象深刻的跟踪记录，庞大的安装基础，但NoSQL正在取得令人印象深刻的进展，并有许多支持者。我们向两个阵营的专家提出了这个问题。

结构化查询语言(SQL)已被证明是一个赢家，它已经统治了几十年，目前正被谷歌、Facebook、Cloudera和Apache等大数据公司和组织积极投资。

一旦一项技术变得像SQL一样占主导地位，它占主导地位的原因有时就会被遗忘。SQL胜出是因为其独特的优势组合:

1. SQL支持增加与数据的交互，并允许针对单个数据库设计提出广泛的问题集。这是关键，因为不交互的数据本质上是无用的，而增加的交互会带来新的见解、新的问题和更有意义的未来交互。
2. SQL是标准化的，允许用户跨系统应用他们的知识，并为第三方插件和工具提供支持。
3. SQL可以扩展，而且是通用的，经过验证的，可以解决从快速的面向写的事务到扫描密集型的深度分析等一系列问题。
4. SQL与数据表示和存储是正交的。一些SQL系统支持JSON和其他结构化对象格式，比NoSQL实现具有更好的性能和更多的特性。

尽管最近NoSQL产生了一些噪音，但SQL继续在市场中获胜，并继续在大数据问题领域获得投资和采用。

术语“NoSQL”有歧义，但在本文中我使用它Dr. Rick catell的NoSQL定义指“提供简单操作的系统，如键/值存储或简单记录和索引，并关注这些简单操作的水平可伸缩性。”

很明显许多可用的新数据库并不都是相同的——认识到每个人背后的基因是如何帮助和阻碍问题解决者的，是成功的关键。NoSQL的关键特性使它更适合在特定的问题集中使用。例如，与按行或文档组织数据的情况相比，图形数据库更适合于这些情况，而专门的文本搜索系统应该被认为适合于在用户输入术语时需要实时搜索的情况。

在这里，我将阐述SQL系统与简单的键/值和JSON对象存储的重要优势和区别，这些存储除了存储格式和可伸缩性之外没有任何创新。

* SQL启用交互。SQL是一种声明性查询语言。用户陈述他们想要什么(例如，显示过去5年3月份的顶级客户的地理位置)，然后数据库在内部组装一个算法，并提取所需的结果。相比之下，NoSQL编程的创新MapReduce是一种过程查询技术。MapReduce不仅要求用户知道他们想要什么，而且还要求他们说明如何生成答案。

这听起来似乎是一个乏味的技术差异，但它是关键的原因有两个:首先，声明性SQL查询更容易通过图形工具和指向单击报表构建器构建。这就为分析师、操作员、经理和其他软件编程之外具有核心竞争力的人打开了数据库查询的大门。其次，从“如何”中提取内容允许数据库引擎使用内部信息来选择最高效的算法。改变数据库的物理布局或索引，仍然会计算出最佳算法。在过程式系统中，程序员需要重新编写原程序。这是昂贵和容易出错的。

市场理解这一关键区别。2010年，谷歌在内部用户需求的驱动下，宣布了一个SQL实现来补充MapReduce。最近,Facebook很快发布，一个SQL实现来查询它的petabyte HDFS集群。根据Facebook的说法:“随着我们的数据仓库增长到pb的规模，我们的需求也在不断发展，很明显，我们需要一个为低查询延迟而优化的交互系统。”此外，Cloudera正在构建Impala，这是另一个基于HDFS的SQL实现。所有这些都是对Hive的进步，Hive是一个长期存在并被广泛采用的Hadoop SQL façade。

SQL是标准化的。尽管供应商有时会对其SQL接口进行专门化和引入方言，但SQL的核心是很好的标准化的，其他规范(如ODBC和JDBC)为SQL存储提供了广泛可用的稳定接口。这使得一个管理和操作工具生态系统能够帮助设计、监控、检查、探索和构建SQL系统之上的应用程序。

因此，SQL用户和程序员可以跨多个后端系统重用他们的API和UI知识，从而减少应用程序开发时间。标准化还允许声明的第三方Extract、Transform、Load (ETL)工具，这些工具使企业能够在数据库之间和跨系统之间流动数据。

* SQL鳞片。认为必须牺牲SQL来获得可伸缩性是完全错误的。如上所述，Facebook创建了一个SQL接口来查询pb级的数据。SQL在运行异常快速的ACID事务时同样有效。SQL提供的数据存储和索引抽象允许跨问题和数据集大小统一使用，从而允许SQL在集群复制的数据存储之间高效运行。使用SQL作为接口独立于构建云、规模或高可用性系统，并且SQL中没有任何固有的禁止或限制容错、高可用性和复制的东西。事实上，所有现代SQL系统都支持云友好的水平可伸缩性、复制和容错。

* SQL支持JSON。几年前，许多SQL系统添加了XML文档支持。现在，随着JSON成为一种流行的数据交换格式，SQL供应商也在添加JSON类型的支持。考虑到当今的敏捷编程过程和web基础设施的正常运行时间要求，支持结构化数据类型有很好的理由。Oracle 12c、PostgreSQL 9.2、VoltDB等都支持JSON——通常性能基准优于“原生”JSON NoSQL存储。

SQL将继续赢得市场份额，并将继续看到新的投资和实施。NoSQL数据库提供专有的查询语言或简单的键值语义，而没有更深的技术差异，这是一个具有挑战性的位置。现代SQL系统匹配或超越了它们的可伸缩性，同时支持更丰富的查询语义、建立和训练有素的用户基础、广泛的生态系统集成和深入的企业采用。

NoSQL越来越被认为是关系数据库的可行替代方案，特别是对于大数据应用，因为越来越多的企业认识到，在标准的商用服务器集群上可以更好地实现规模化运行。此外，对于目前捕获和处理的数据的多样性和类型，无模式数据模型通常更好。

当我们谈到NoSQL空间中的大数据时，我们指的是从运行数据库中读取和写入数据——也就是说，人们每天与之交互并参与的在线事务处理(例如，拥有在线预订机票所需的大数据)。不要将运营数据库与分析数据库混为一谈，后者通常会查看大量数据，并从这些数据中收集见解(例如，获取某一天有多少人会预订机票所需的大数据)。

虽然从表面上看，运营数据库的大数据可能看起来不那么具有分析性，但运营数据库通常承载超大数量的大数据集，这些用户不断访问数据，以实时执行事务。数据库管理大数据所需的操作规模说明了NoSQL的关键性质，也解释了为什么NoSQL是大数据应用的关键。

NoSQL对于可伸缩性至关重要

每当科技行业在硬件发展方面经历根本性转变时，就会出现拐点。在数据库空间中，从扩展体系结构到向外扩展体系结构的转变推动了NoSQL运动。关系型数据库，包括来自Oracle和IBM的数据库，都在扩大规模。也就是说，它们是集中的、共享一切的技术，只能通过增加更昂贵的硬件来扩展。

相反，NoSQL数据库是通过分布式、可扩展的技术从头构建的。它们使用一组分布式节点(称为集群)来提供高度弹性的伸缩能力，允许用户添加节点来动态处理负载。

分布式扩展方法通常也比扩展方法更便宜。这是大型、复杂、容错服务器的设计、构建和支持成本高昂的结果。商业关系数据库的许可成本也可能令人望而却步，因为它们的定价考虑到了单个服务器。另一方面，NoSQL数据库通常是开源的，价格是在服务器集群上运行的，而且相对便宜。

NoSQL对于灵活性至关重要

关系数据模型和NoSQL数据模型非常不同。关系模型获取数据并将其分离到许多包含行和列的相关表中。这些表也通过存储在列中的外键相互引用。

当用户需要对一组数据运行查询时，需要从许多表(在今天的企业应用程序中通常有数百个表)收集所需的信息，并将其组合起来，然后才能提供给应用程序。类似地，当写入数据时，需要协调并在许多表上执行。当数据量相对较小，并且以较低的速度流入数据库时，关系数据库通常能够捕获并存储信息。但是今天的应用程序通常是建立在这样的期望之上的，即大量的数据可以以接近实时的速度写入(和读取)。

NoSQL数据库有一个非常不同的模型。在核心上，NoSQL数据库实际上是“NoREL”，即非关系数据库，这意味着它们不依赖表和表之间的链接来存储和组织信息。例如，面向文档的NoSQL数据库获取您想要存储的数据，并使用JSON格式将其聚合到文档中。可以将每个JSON文档视为应用程序使用的对象。一个JSON文档可以获取存储在一行中的所有数据(该行横跨关系数据库的25个表)，并将其聚合为一个文档/对象。

聚合这些信息可能会导致信息的重复，但是由于存储不再是一个成本问题，因此数据模型的灵活性、有效分发结果文档的便捷性以及读写性能的改进使得基于web的应用程序很容易进行权衡。

NoSQL对于大数据应用至关重要

通过包括社交媒体网站在内的第三方获取和访问数据变得越来越容易。个人用户信息、地理位置数据、用户生成的内容、机器记录数据和传感器生成的数据只是正在被捕获的不断扩大的阵列中的几个例子。企业也依赖大数据来驱动关键任务应用。各个组织都在转向NoSQL数据库，因为它们特别适合今天出现的这些新类型的数据。