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

从事大数据项目的公司面临的关键决策之一是使用哪种数据库，通常在SQL和NoSQL之间摇摆不定。SQL有着令人印象深刻的跟踪记录和庞大的安装基数，但是NoSQL正在取得令人印象深刻的进步，并且有许多支持者。我们向两个阵营的专家提出了这个问题。

结构化查询语言(Structured Query Language, SQL)是一个已经主导了几十年的赢家，目前正被谷歌、Facebook、Cloudera和Apache等大数据公司和组织大举投资。

一旦一种技术变得像SQL一样占主导地位，其优势的原因有时就会被遗忘。SQL的优势在于其独特的优势组合:

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

虽然NoSQL最近产生了一些噪音，但SQL在市场上继续获胜，并在整个大数据问题领域继续赢得投资和采用。

术语“NoSQL”是不明确的，但是在这里我使用Rick Cattell博士的NoSQL定义意思是“提供键/值存储或简单记录和索引等简单操作的系统，并关注这些简单操作的水平可伸缩性。”

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

在这里，我将介绍SQL系统与简单的键/值和JSON对象存储之间的重要优势和区别，后者在存储格式和可伸缩性方面没有创新。

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

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

市场理解这个关键的区别。2010年谷歌宣布了一个SQL实现来补充MapReduce，这是由内部用户需求驱动的。最近,Facebook很快发布，用于查询其pb HDFS集群的SQL实现。Facebook表示:“随着我们的仓库规模增长到pb级，我们的需求也在不断发展，很明显，我们需要一个针对低查询延迟进行优化的交互式系统。此外，Cloudera正在构建基于HDFS之上的另一个SQL实现Impala。所有这些都是对Hive的改进，Hive是一种长期存在并被广泛采用的Hadoop SQL facade。

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

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

* SQL鳞片。认为必须牺牲SQL来获得可伸缩性是绝对错误的。如前所述，Facebook创建了一个SQL接口来查询pb级的数据。SQL在运行快得惊人的ACID事务方面同样有效。SQL提供的对数据存储和索引的抽象允许在问题和数据集大小之间统一使用，从而允许SQL在集群复制的数据存储之间高效运行。使用SQL作为接口独立于构建云、伸缩或HA系统，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的发展。关系数据库，包括来自甲骨文和IBM巨头的数据库，规模不断扩大。也就是说，它们是集中的、共享一切的技术，只能通过增加更昂贵的硬件来扩展。

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

分布式略微脱模方法通常也会比扩展替代品更便宜。这是设计，构建和支持昂贵的大型复杂，容错服务器的结果。商业关系数据库的许可费用也可能是令人禁止的，因为它们的价格是单一服务器的定价。另一方面，NoSQL数据库通常是开源的，价格为在一组服务器上运行，并且相对便宜。

NoSQL对于灵活性至关重要

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

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

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

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

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

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