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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

                                                                                                         数据分析师