【前沿】NoSQL很重要，为何SQL也依然重要?

人们在谈到“数据库人员”时，通常会在前面加上“坏脾气、上年纪”的修饰语。的确，我们监管的许多系统已运行了二三十年。如果你看一下MapReduce ――在任何并行数据库系统里，比如Teradata、IBM的并行版本、甲骨文的RAC，里面都有MapReduce引擎。那些技术成名已好多年。所以，坏脾气、上年纪的数据库人员确实在过去搞定了许多问题。

话虽如此，作为一名数据库人员，我认为情况确实已经发生了根本性的变化。也许，早在上世纪80年代采用关系模型以来，发生的变化大。从许多方面来看，大数据生态系统其实与传统数据管理根本不一样。尤其是现在人们喜欢谈论可扩展性，因为大数据中的“大”意味着你有大量数据。

但同样，横向扩展技术成名已有好长一段时间了。由于一些不同的系统假设等因素，现在它们有点不一样。可能之前有人认为1000个节点的系统是个大系统，而现在动辄谈论10000个节点。

加州大学伯克利分校教授、AMPLab联席主任迈克尔·富兰克林(Michael Franklin)

在我看来，新一代数据管理根本上的不同其实并不仅仅体现在可扩展性上，其实还体现在灵活性上。如果你看一下先存储数据，然后为数据赋予结构的功能――有时这名为读取模式(schema on read)或需求模式(schema on need)，这确实完全改变了行业规则。

如果你想搞数据管理项目，你会说“OK，步，搞清楚想要存储在系统里的每一个部分的数据，它是什么样子，它是如何组织的，然后它与你可能想要存储到数据库系统里的其他所有数据有何关系；第二步，收集一些实际的数据；第三步是试图让实际数据遵循你在步中创建的这种模式。

但实际许多项目根本走不到这么远。早在人们开始搞数据仓库之类的东西时，坊间到处是失败案例：人们往这些系统投入了巨资，却根本无法让系统运行起来。

在这个新环境下，你先存储数据，然后搞清楚如何处理数据，情况完全变了。现在，你可以收集想要收集的所有技术数据；你在使用数据时，要做一些额外的工作；你在性能方面可能会受到一点点影响，因为存储没有完全优化；你也会有一些一致性问题需要了解。但总的来说，现在将你的数据管理系统组装起来面临的阻力已大大减小。

“关系模型的真正突破在于，将你对数据拥有的逻辑视图、想怎样处理数据与数据如何实际存储起来的物理现状分离开来。”

如果你看一下弹性计算，现在的云计算，Hadoop MapReduce中的一些机制，以及Spark之类的技术，就会发现添加更多的资源、让系统优雅地利用那些资源这种功能在之前根本就没有。现在不仅仅能够扩展系统，还能够在需要时扩展系统，不再需要时又可以缩减系统。

这同样完全减小了阻力。过去，你不得不为你预料的需要解决的大问题构建数据中心或系统，而现在再也没必要这么做。现在，可以为你认为将来需要的东西构建系统，然后当你需要增加资源时，可以借助云资源或者你一开始就可以在云端做全部的工作。这从根本上改变了现状。

然后是这种功能：可以在SQL等查询语言、R等统计处理语言和图形处理语言之间轻松自如地切换――这些在Spark中可以轻松做到。这完全不一样，所以你再也不必死守某种模式来处理数据。可以将数据存储在系统中，然后可以使用图形系统来处理很合理的任务，使用关键查询语言处理很合理的任务，使用统计处理语言来处理很合理的任务。你还可以将它们混合搭配起来。

所以相比你可能交谈的许多坏脾气、上年纪的数据库人员，我认为情况已发生了根本性的变化，它们不会变回来，我们其实处于新时代的开端。当然，就像关系数据库革命的开端那样，要做许多工作让系统更稳健，提高系统的性能，让系统更易于使用。但是我们刚处于这趟旅程的开端。

我认为，尽管Hadoop变得更流行，人们为此变得更激动，但我和我的许多同事就在等待人们认识到，直接编写MapReduce程序确实很麻烦;有一些语言是专门为解决许多这些问题而开发的，尤其是SQL。SQL会在这些系统中扮演重大角色。

你可能会看到它出现在Hive这么久远的系统中。这正是数据库系统在许多方面流行起来的原因。因为直接编写程序太难了。此外，你不想要这么做，因为许多人对于关系模型和SQL之类的系统没有认识到这点：真正的突破并不在于语言。语言只是某种工件。

真正的突破在于你对数据拥有的逻辑视图、想怎样处理数据与数据如何实际存储起来的物理现状分离开来。而做入到关系模型中的是愿景，那就是数据依赖(data independence)。这让你可以改变数据的布局，并改变数据、所使用的系统、所使用机器的组织，没必要每当有所改变就要重写应用程序。

同样，它让你可以编写程序，不用过于担心数据时时刻刻是如何组织的。这种灵活性对面向数据的系统来说至关重要，因为一旦你收集数据，往往保留数据，你编写的应用程序不会消失。你需要能够扩展数据的物理布局，需要能够保护开发人员(尽管他们可能不想要受到保护)不必操心那些种类的变化。

凡是处理过数据库系统的人都会看到这一幕，因为Hadoop基本上打破了所有那些规则，而这个教训在几十年之前就已汲取了。

NoSQL潮流表明有一系列重要的应用并不需要传统数据库竭力试图做到的东西：一致性、并发性控制和恢复，诸如此类的东西。你根本不会丢失一个数据，你的数据库中根本没有一个数据不遵守模式的。落实所有这一切其实是为了保护数据库远离程序员。

在许多应用领域，那些东西其实不需要，从性能、可扩展性和易用性方面来看，为那些保证付出的代价实在太高了。这其实是NoSQL潮流所要表明的，在一些重要的应用场合，你不需要那些保证。如果摈弃那些保证，就能构建一种极其灵活、极其易于使用的系统。

NoSQL因为分布式架构，扩展性，高可用以及灵活的数据类型，满足了大数据时代众多的新需求。但是对于企业级用户，NoSQL+SQL支持才是能满足他们的数据库需求的组合。

SQL早已经成为企业级应用访问数据库的标准接口，基于SQL业界也提供了无数类似Spring等扩展组件，用于为应用程序的开发者提供更加方便易用的访问数据库的模块封装。

在如今的大数据时代，分布式数据存储架构一般被分为存储层与计算层两部分。由于针对的应用类型不同，OLAP和OLTP类型的应用很难共用同一套存储和计算框架。

我们以SequoiaDB实际应用为例进行介绍。对于纯分析类场景，使用Spark或者MapReduce是一种很好的选择；但是当在进行交互式高并发处理时，SeqouiaSQL或Impala等其他计算引擎则是更好的选择。因此，不同的计算引擎和存储系统相互搭配结合，以适用于不同的应用场景，是当今大数据基础框架体系的基本设计思路。

结合这种设计方式，SequoiaDB提供的底层数据库以JSON存储为基础，结合上层的SequoiaSQL和SparkSQL两种SQL解析引擎，分别适用于高并发交互式业务与低并发分析类场景。

  一般来说，当涉及到直接面向客户的查询、事务操作，或需要在秒级毫秒级响应的数据操作，用户应当使用SequoiaSQL作为短查询SQL引擎。

本文内容部分引用自 :Database expert on why NoSQL mattered — and SQL still matters ，作者:Derrick Harris

点击“阅读原文”了解更多