【51CTO.com快譯】加州大學伯克利分校的教授、AMPLab聯席主任邁克爾·富蘭克林(Michael Franklin)的大部分職業生涯都在主攻數據庫技術領域。除研究和教授數據庫外，富蘭克林還開過一家名為Truviso的數據庫公司，后來在2012年被思科收購。本文將分享他在這一領域的所思所想。

我們在分布式數據庫和數據管理系統這條道路上走得有多遠?

人們在談到“數據庫人員”時，通常會在前面加上“壞脾氣、上年紀”的修飾語。的確，我們監管的許多系統已運行了二三十年。如果你看一下MapReduce ――在任何并行數據庫系統里，比如Teradata、IBM的并行版本、甲骨文的RAC，里面都有MapReduce引擎。那些技術成名已好多年。所以，壞脾氣、上年紀的數據庫人員確實在過去搞定了許多問題。

話雖如此，作為一名數據庫人員，我認為情況確實已經發生了根本性的變化。也許，早在上世紀80年代采用關系模型以來，發生的變化***。從許多方面來看，大數據生態系統其實與傳統數據管理根本不一樣。尤其是現在人們喜歡談論可擴展性，因為大數據中的“大”意味著你有大量數據。

但同樣，橫向擴展技術成名已有好長一段時間了。由于一些不同的系統假設等因素，現在它們有點不一樣。可能之前有人認為1000個節點的系統是個大系統，而現在動輒談論10000個節點。

[[176339]]

加州大學伯克利分校教授、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】