【51CTO.com快译】加州大学伯克利分校的教授、AMPLab联席主任迈克尔·富兰克林(Michael Franklin)的大部分职业生涯都在主攻数据库技术领域。除研究和教授数据库外，富兰克林还开过一家名为Truviso的数据库公司，后来在2012年被思科收购。本文将分享他在这一领域的所思所想。
我们在分布式数据库和数据管理系统这条道路上走得有多远?
人们在谈到“数据库人员”时，通常会在前面加上“坏脾气、上年纪”的修饰语。的确，我们监管的许多系统已运行了二三十年。如果你看一下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和Spark流行起来，SQL还会是那些系统上备受关注的焦点吗?
我认为，尽管Hadoop变得更流行，人们为此变得更激动，但我和我的许多同事就在等待人们认识到，直接编写MapReduce程序确实很麻烦;有一些语言是专门为解决许多这些问题而开发的，尤其是SQL。SQL会在这些系统中扮演重大角色。
你可能会看到它出现在Hive这么久远的系统中。这正是数据库系统在许多方面流行起来的原因。因为直接编写程序太难了。此外，你不想要这么做，因为许多人对于关系模型和SQL之类的系统没有认识到这点：真正的突破并不在于语言。语言只是某种工件。
真正的突破在于你对数据拥有的逻辑视图、想怎样处理数据与数据如何实际存储起来的物理现状分离开来。而做入到关系模型中的是愿景，那就是数据依赖(data independence)。这让你可以改变数据的布局，并改变数据、所使用的系统、所使用机器的组织，没必要每当有所改变就要重写应用程序。
同样，它让你可以编写程序，不用过于担心数据时时刻刻是如何组织的。这种灵活性对面向数据的系统来说绝对至关重要，因为一旦你收集数据，往往保留数据，你编写的应用程序不会消失。你需要能够扩展数据的物理布局，需要能够保护开发人员(尽管他们可能不想要受到保护)不必操心那些种类的变化。
凡是处理过数据库系统的人都会看到这一幕，因为Hadoop基本上打破了所有那些规则，而这个教训在几十年之前就已汲取了。
我认为NoSQL潮流言过其实了，但也许核心功能(比如需求模式)比名称来得更重要?
NoSQL潮流表明有一系列重要的应用不需要传统数据库竭力试图做到的保证：一致性、并发性控制和恢复，诸如此类的东西。你根本不会丢失一个数据，你的数据库中根本没有一个数据不遵守模式的。落实所有这一切其实是为了保护数据库远离程序员。
在许多应用领域，那些东西其实不需要，从性能、可扩展性和易用性方面来看，为那些保证付出的代价实在太高了。这其实是NoSQL潮流所要表明的，在一些重要的应用场合，你不需要那些保证。如果摈弃那些保证，就能构建一种极其灵活、极其易于使用的系统。
坦率说，要不是NoSQL潮流，我认为传统数据库标准不会那样发展。
对传统数据库厂商而言，未来形势如何?那些软件许可证仍有大量的生意。
有许多应用场合表明，传统系统仍是非常好的解决方案。当然是这种场合：需要它成为记录系统，绝不能丢失任何数据，绝不能根据受到某种损坏的信息来做决定。那些问题不会消失。传统厂商在这方面仍有一席之地。
至于在数据分析领域，传统数据库厂商的日子要难过一点：一方面，这个世界已走开源道路，所以它们的传统商业模式行不通，它们不得不重新考虑合适的商业模式应该是怎样。另一方面，你得转变观念;那些传统老牌厂商能不能吸引足够多的人才，这些人才拥有能够在这些新领域下竞争的新观念，还需拭目以待。
“像大数据分析和科学计算等某些重要领域，开源绝对会是大势所趋，因为你可以让众多的人员处理一个问题。但是我并不确信开源适合一切。”
开源领域的优点之一就是，系统可以迅速变化，你可以迅速发展、引入新功能。这也给需要某种稳定性的人员带来了一些挑战。当然，大数据分析对开源开发和开源系统来说就是“***典范”，一方面使用系统的人精通技术，而且足够自信，可以处理其中一些问题，比如要确保你拥有合适的版本;某一个底层部件/组件变化后，要改变系统的一部分。
你能想起过去十年流行起来，却不是开源的许多数据库吗?我也许只能想起一个。
眼下，发展势头无疑对开源有利，但答案取决于商业模式。这可能会对开源模式***会不会取而代之有巨大的影响。因为最终人们不得不获得收入或支持这些系统，以便确保它们很稳健，很安全，它们能处理需要处理的一切任务。
不过，现在市场上有许多令人关注的针对开源的商业模式。而且软件和商业模式也都会出现许多创新。
***的挑战也许是让使用优秀免费产品的用户变成付费客户。
我过去处理工作的方式，以及我所在行当的所有人过去处理工作的方式是，我们会捣鼓出一种新算法，一种新的连接方法，一种新的索引，一种新的任何技术，之后会做一些原型工作，证明它是个好想法。然后，我们会跑到甲骨文、IBM和微软这些公司，告诉对方我们搞出了这种新玩意。那些人不是忽视它，就是把它做入到产品中，有时候你根本不知道。
但是我们总是离实际用户相差一大步。开源完全克服了这道障碍。现在，我们实验室的一个学生有好想法后，可以编写代码，要是看起来不赖，他们就进一步完善，那样别人就能明白它的用途并使用它，***他们把它放在GitHub上，突然之间，它切实应用于现实世界。
我们其实最近遇到过这种情况：实验室的一个学生Evan Sparks在我们的研究交流会上作了发言，赞助商也参与了交流会。许多学生踊跃发言，说“这是我在开发的某个组件。它的功能是这样的。”***，他们会说“这个月底这个产品会推出测试版，或者我们上周对这个产品搞了一个测试版。”
Evan起身谈论了Keystone ML，这是我们的机器学习管道系统。他说“马上就会推出系统的测试版。”他当着200人的面打开了他的GitHub页面，从私有代码库一下子切换到公共代码库。这就为真正的好想法消除了阻力，并证明它切实可行，然后构建一个工件来证明切实可行，真正让人们开始使用它，试用它，可能采用它。那种阻力完全消失了。
作为一名研究人员和学术人员，让我感到兴奋的是，现实世界中的人们愿意尝试、使用、采用和部署开源软件，因为开源软件给我们带来了直接的影响力。你可以透过AMPLab带来的影响看到这一幕。
原文标题:Database expert on why NoSQL mattered — and SQL still matters ，作者:Derrick Harris
【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】
