SQL/NoSQL两大阵营激辩：谁更适合大数据

　　英文原文：http://www.networkworld.com/article/2226514/tech-debates/what-s-better-for-your-big-data-application--sql-or-nosql-.html

　　企业在着手推动大数据项目的过程中，经常会遇到这样一个关键性的决策难题——到底该使用哪种数据库方案?经过综合考量，最终的选项往往只剩下 SQL 与 NoSQL 两种。SQL 具有骄人的业绩以及庞大的安装基础，但 NoSQL 却能够带来可观的收益并同样拥有不少支持者。在今天的辩论当中，我们将一同听听两大阵营中各位专家的意见。

　　Network World 网站主编 John Dix 专门组织了此次辩论并邀请到多位专家。其中两位参与专家分别是 VoltDB 公司 CTO Ryan Betts 和 Couchbase 公司 CEO Bob Wiederhold。Ryan Betts 认为 SQL 已经在大型企业当中赢得了稳定的生存空间，而大数据只不过是 SQL 需要支撑的另一项工作内容。Bob Wiederhold 则认为 NoSQL 是一套极具可行性的备选方案，事实上它也在多个领域中成为大数据的卓越配合手段——特别是在可扩展性方面。

　　观点一：SQL 已经通过时间考验，且仍蓬勃发展——VoltDB 公司 CTO Ryan Betts

　　结构化查询语言(简称 SQL)几十年来已经用累累战果以及赫赫声名证明了自身实力，而且目前仍在继续投身于多家大数据厂商及相关企业当中，其中包括谷歌、Facebook、Cloudera 以及 Apache。

　　虽然后起之秀 NoSQL 确实引起了一定反响，但 SQL 仍然在市场上保持着显著的份额优势并继续在大数据领域不断赢得投入与采纳。

　　一旦某种技术像 SQL 这样取得了主导地位，人们往往会忘记其最为核心的竞争优势。SQL 之所以能够胜出，主要在于它拥有以下一系列独特的优势组合：

　　1. SQL 能够加强与数据之间的互动，允许用户针对单一数据库设计提出内容广泛的问题。这正是 SQL 成功的关键所在——如果数据不具备互动性、则基本上将失去实用性。而持续增长的互动性又能为数据库的未来发展带来新的审视角度、相关问题以及实际意义。

　　2. SQL 具备标准化特性，允许用户自由运用源自各类系统的专业知识、同时支持第三方插件及工具。

　　3. SQL 具备扩展性、功能丰富且经过实际验证，能够解决各类难题——包括以写入为主导的快速事务处理以及涉及频繁扫描的深层分析。

　　4. SQL 能够与数据表现及存储机制顺畅对接。某些 SQL 系统还支持 JSON 以及其它结构化对象格式，从而带来优于 NoSQL 方案的性能表现及更多功能特性。

　　“NoSQL”这一表述其实并不准确，但在本次讨论中，我采用了 Rick Cattell 博士为 NoSQL 总结出的定义，即“指那些能够提供键/值存储或者简单记录与索引等操作的系统，旨在为这些简单操作提供垂直可扩展性。”

　　很明显，目前市面上的很多新型数据库彼此之间存在较大差异——准确掌握它们各自特性与深层机制给用户来的便利与局限是获得项目部署成功的关键所在。NoSQL 的核心特性使其更适合于解决特定问题。举例来说，图形数据库更适合处理那些将数据根据关系而非传统行或者文档形式加以组织的实例，而特定文本搜索系统则比较擅长处理以实时方式查询用户输入内容的情况。

　　在这里，我打算概括性阐述 SQL 系统与简单键/值乃至仅仅在存储格式及可扩展性方面有所创新的 JSON 对象存储系统相比，到底存在哪些差异与主要优势。

　　* SQL 带来交互特性。SQL 是一种声明性查询语言。用户说出自己想要的内容(例如显示出过去五年来，每年三月份购买量最大的客户分别来自哪些地区)，数据库则在内部组建出相关算法并根据要求提取对应结果。相比之下，NoSQL 孕育出的编码创新成果 MapReduce 则是一种规程化查询技术。MapReduce 要求用户不仅了解自己想要的结果，同时也需要提供获取结果的具体执行方式。

　　虽然听起来只是一种颇为枯燥的技术性差异，但这种特性仍然极为关键，原因有以下两点：首先，声明性 SQL 查询能够更为轻松地通过图形化工具以及对报告生成器的简单点击来创建。这种相对较低的使用门槛能够帮助分析师、运营者、管理者以及其他不了解软件编程知识的用户享受其核心功能及成效。第二，对数据库引擎使用内部信息并选择高效算法的方式进行抽象化处理。即使物理层或者数据库索引出现变动，优化算法仍然能够确切完成任务。相比之下，在过去的程序化系统当中、程序员需要重新审视现有处理方式并进行二次编程。这样既带来高昂成本，又很有可能导致意外错误。

　　市场对于这种本质差异倒是非常了然。早在 2010 年，谷歌就宣布引入一套 SQL 方案以强化 MapReduce，从而满足内部用户的实际需求。最近，Facebook 则发布了自己的 SQL 方案 Presto，意在对其 PB 级别 HDFS 集群数据进行查询。根据 Facebook 方面的说法：“由于我们的数据仓库规模已经增长至 PB 级别、业务需求也逐步发展，我们显然需要一套经过优化的交互式系统以实现更低的查询延迟。”除此之外，Cloudera 正在 HDFS 以上建立自己的 SQL 方案 Impala。前面提到的这一系列发展都立足于 Hive——一套面向 Hadoop、长期存在且得到广泛采用的 SQL 外壳。

　　* SQL 具备标准化特性。虽然供应商有时候会对自己的 SQL 接口进行特殊调整与定制，但从本质上讲 SQL 内核仍然是一套标准化程度很高的方案，以 ODBC 以及 JDBC 为代表的其它规范同样提供广泛可用的、面向 SQL 系统的稳定接口。由此衍生出的管理及操作工具生态系统能够帮助大家以 SQL 系统为基础，实现应用程序的设计、监控、检查、探索以及开发。

　　SQL 用户及程序员也因此得以重新使用自己积累自多种后端系统的 API 以及用户界面知识，从而缩减应用程序开发时间。标准化特性还允许拥有声明许可的第三方打造提取、转换以及加载(简称 ETL)工具，旨在帮助企业以流程化方式处理不同数据库及系统之间的数据流。

　　* SQL 具备可扩展性。有些朋友可能误以为 SQL 必须通过牺牲性能的方式来获得可扩展性，这其实是完全错误的。如上所述，Facebook 打造了一款 SQL 接口对 PB 级别的数据加以查询。SQL 在运行 ACID 事务处理任务时同样具备极快的速度表现。SQL 为数据存储及检索机制提供的抽象化手段允许用户以统一化方式完成处理工作，而且无需考虑具体任务类型以及数据规模;这使得 SQL 能够高效运行在各类集群化副本数据存储体系之间。将 SQL 作为接口的作法不涉及云创建、具体规模或者 HA 系统，而且 SQL 当中也没有任何固有因素会对容错性、高可用性以及复制能力产生限制。事实上，目前所有现代化 SQL 系统都能够很好地支持云体系中的横向可扩展性、复制能力以及容错性。

　　* SQL 支持 JSON。几年之前，很多 SQL 系统开始将 XML 文档支持能力纳入自身设计思路。时至今日，随着 JSON 逐步成为主流数据交换格式之一，各 SQL 厂商也在积极为 JSON 提供支持。鉴于当下敏捷化编程流程以及对互联网接入基础设施正常运行时间的要求，结构化数据类型的支持能力已经成为不可或缺的重要一环。Oracle 12c、PostgreSQL 9.2、VoltDB 以及其它各类数据库方案都开始支持 JSON——其性能基准水平普遍优于“原生”JSON NoSQL 方案。

　　SQL 将继续在市场份额的争夺战中占据主动，也将继续吸引到更多投资方与采纳者的支持。NoSQL 数据库在提供专有查询语言或者简单键-值语义的同时，却无法从深入的技术层面带来差异性，这无疑严重影响了其挑战市场统治者的能力。现代 SQL 系统能够在保持甚至超越原有可扩展性的同时，支持丰富的查询语义、建立并培养用户基础、拓展生态系统集成效果并在企业环境内深化采纳程度。

　　观点二：NoSQL 更适合大数据应用程序——Couchbase 公司 CEO Bob Wiederhold

　　目前已经有越来越多的企业开始将 NoSQL 视为关系型数据库的一种可行性替代方案;特别是在大数据应用程序领域，很多企业用户意识到规模化操作的实际表现要优于标准化集群与商用服务器所带来的效果。除此之外，采用无模式化数据模型往往更适合当下各类不同数据的捕捉与处理工作。

　　在 NoSQL 领域讨论大数据话题时，我们主要针对的是操作型数据库当中的读取与写入流程——也就是指人们在日常在线事务处理过程中所涉及的交互任务(例如利用大数据指导在线航班预定)。操作型数据库与分析型数据库有所不同，前者一般需要打理大量数据并收集数据当中所蕴含的分析结论(例如利用大数据分析特定某一天会有多少乘客预定某次航班)。

　　不过对于操作型数据库中的大数据而言，其设计主旨并非围绕分析性工作所展开;操作型数据库通常需要为无数用户提供庞大的数据集，帮助他们进行持续性数据访问并进行实时事务处理。用于操作并管理大数据内容的此类数据库都具备庞大的规模，这也解释了 NoSQL 特性的重要意义及其在大数据应用程序中扮演核心角色的原因。

　　* NoSQL 是实现可扩展性的关键所在

　　技术行业在每一次迎来硬件发展的根本性转变时，都必然经历过渡拐点。在数据库领域，这种由向上扩展转为向外扩展架构的转变也成为推动 NoSQL 快速成长的主要因素。关系型数据库，其中包括由甲骨文及 IBM 等巨头所打造的具体方案，专注于解决向上扩展难题。也就是说，它们采取集中式、全局共享技术，只能通过添加价格更为昂贵的硬件设备满足扩展需求。

　　与之相反，NoSQL 数据库从设计思路上就考虑到了分布式特性，属于彻头彻尾声的向外扩展技术。它们利用一系列分布式节点(构成一套整体集群)来提供具备卓越弹性的扩展能力，从而帮助用户随意添加更多节点以应对持续增加的工作负载。

　　分布式向外扩展方案往往还会带来低于向上扩展机制的使用成本。后者属于一整套庞大、复杂、具备容错性机制的服务器体系，因此无论是设计、建造还是后期支持都会带来高昂的成本支出。商用关系型数据库的许可成本同样不容忽视，因为其计费策略以单一服务器为基本单位。在另一方面，NoSQL 数据库则通常属于开源项目，以服务器集群为整体计费单位、价格也相比较低。

　　* NoSQL 是实现灵活性的关键所在

　　关系型与 NoSQL 数据模型可谓完全不同。关系型模型需要将数据拆分成包含行与列的多个关联性表，这些表通过同样保存在列中的外键实现相互引用。

　　当用户需要对一组数据进行查询时，所需信息必须由多个表中收集获得——通常涉及数百种当下常用的企业应用程序——并将其加以整合，而后才能交付终端应用。与之相似，在写入数据时、写入流程需要加以协调并在执行过程中面向多个表。当数据量相对较小、向数据库内导入的速度并不太快的情况下，关系型数据库通常具备捕捉并存储信息的能力。不过目前的应用程序通常需要处理海量数据的读取与写入操作、且要求以近实时方式完成，这就超出了操作型数据库的能力范围。

　　NoSQL 数据库采取的模式则完全不同。从核心角度看，NoSQL 数据库真正实现了“NoREL”、也就是非关系型，也就是说此类方案在保存并整理信息的过程中并不依赖于表以及各个表之间的关系。举例来说，一套面向文档的 NoSQL 数据库会首先获取到我们需要的数据，而后将其整合成采用 JSON 格式的文档。每个 JSON 文档都可以被视为能供应用程序使用的对象。JSON 文档可以把原本需要 25 个关系型数据库表才能存放的数据保存在同一行当中，并将其整理为单一文档/对象。

　　信息汇总工作可能导致信息内容出现重复，不过由于目前存储资源已经不再属于主要成本来源，因此这类数据模型能够带来更出色的灵活性、便于高效分配由此产生的文档并改进读取与写入操作的性能表现、从而提升 Web 应用程序的替代性效果。

　　* NoSQL 是支撑大数据应用的关键所在

　　时至今日，我们已经能够愈发便捷地通过第三方环境、包括社交媒体网站对数据进行捕捉与访问。个人用户信息、地理位置数据、用户产生的内容、设备登录数据以及传感器数据等只是这股风潮当中的少数典型代表，数据来源清单正在不断拓展。同时，企业也越来越依赖大数据技术的力量、旨在驱动其关键性业务应用。总体而言，各企业已经开始向 NoSQL 伸出橄榄枝，因为这类方案是惟一能够适应当前新兴数据类型的处理手段。

　　开发人员需要一套更为灵活、能够轻松适应最新数据类型的数据库方案，从而避免破坏第三方数据供应商所提供的内容结构调整。大部分新型数据属于非结构化或者半结构化类型，因此开发人员还需要自己的数据库有能力高效对其加以保存。遗憾的是，关系型数据库所采取的严格定义、以模式为基础的设计思路令我们无法快速接纳全新数据类型，自然也难以适应非结构化及半结构化数据。NoSQL 带来的数据模型则能够更好地与其实际需求加以映射。

　　总体来说，随着 Web 与移动应用程序的不断普及、新兴趋势的推波助澜外加面向在线消费者行为与新型数据类别的转变，业界中的各类流程方案都渴望着一种能够为数据的管理及访问带来可扩展性与灵活性的数据库技术。在这样的背景下，NoSQL 技术正是能够有效满足上述需求的惟一解决方案。