SQL數據庫即將萬劫不復？霸王也有別姬時
對于NoSQL的興起，51CTO數據庫頻道之前曾報道過《云計算時代NoSQL當道 關系數據庫日薄西山》，我們認為這是數據庫技術進步的體現。無論多么輝煌的數據庫技術，也有被淘汰的時候，我們不免要經歷一次“霸王別姬”。
SQL 的發展起始于 E.F.Codd 博士1970年六月發表于計算機協會的“通信”上的一篇論文， “大型共享數據庫的關系模型“。當時他和他的在IBM工作的同事 Donald Chamberlin 和 Raymond Boyce正在研究一種查詢語言(最初叫做SQUARE, Specifying Queries As RelationalExpressions的首字母縮寫)，并于1974年以論文”SEQUEL:A Structured English Query Language“將此成就推向頂峰。從此以后，SQL就成了關系數據庫系統的最主要的語言。近些年，軟件開發業內出現了一些體系框架和架構，主要目的是試圖隱藏（或完全放棄）直接使用SQL和關系數據庫，讓開發人員能夠在應用開發中專注于用戶界面，業務邏輯和平臺支持上。同時出現了一批被認為是關系型數替代品，稱之為”NoSQL”的數據庫。難道我們能夠成為 SQL和關系型數據庫終結的見證人嗎？
在一個由Mike Riley主持的十二月 DDJ podcast 訪談中，我被問到：“隨著ORMs(Object Relational Mapping對象關系映射)的流行，有些軟件開發者們認為SQL已經失去其價值了。你對這種觀點有什么看法？”我整個新年假期都在想這個問題，思考這個問題所隱含的意義已及ORM的未來，我花一段時間研究了一下像 Ruby on Rails Active Record 和 Hibernate 這樣的框架。這些框架仍然需要開發人員掌握關系數據的設計、開發和維護等知識。 Microsoft所開發的LINQ(.NET Language Integrated Query)也只是減少了編程語言和數據庫語言之間的不兼容問題。
“NoSQL運動”和分布式數據存儲（Cloud based data stores）都是致力于徹底的將開發人員和SQL語言和關系數據庫之間的依存斬斷。一些程序員認為 NoSQL 運動是一種全新的感念。面向對象式數據庫（Object databases）最早出現于19世紀80年代， Ray Ozzie 于19世紀90年代最早將它商用于Lotus Notes的文檔數據存儲業務。
Charlie Caro, 資深軟件工程師，在美國 Embarcadero 開發 InterBase SQL 數據庫引擎，他告訴我：“在以前，人們普遍認為，不對數據的并發操作進行控制的數據庫基本不可能被大家廣泛接受。但Ozzie認識到，分布式、可復制性和易于安裝的特征所帶來的好處遠勝于在管理文檔數據和消息時很少能遇到的并發更新沖突控制所帶來的好處。而且，如果文檔數據如果需要確保被正確的修改、不能丟失數據，我們可以把配置切換到并發控制狀態上，這是可選擇的。但缺省狀態是不考慮更新沖突控制的。”
NoSQL, 根據WikiPedia上的解釋，是 “一種泛稱（umbrella term），指那些非關系性的、定義不是很明確的數據存儲倉庫。“這個術語最早是 Rackspace 公司 的員工 Eric Evans 發明的。在他上年十月發表的博客里出現了NoSQL (現在普遍認為是 Not Only SQL 的意思) 這個詞。這篇博客里真正的閃光點是”我們之所以要尋找一個其它類型的數據庫的根本原因是想解決關系型數據庫存在的各種弊端。“Adam Keys 在他的博客The Real Adam blog post提供了另一個相似的術語：”Post-Relational”。一些 NoSQL數據庫還把消除那種關系型數據庫對計算機資源、內存占用的問題作為一個目標。NoSQL的其他目標還包括：弱化與編程語言的關系，使用Web技術和RPC調用方式可訪問，以及可切換的數據查詢方式。
在最近的一篇博客“關于NoSQL的討論其實與SQL無關”里 Michael Stonebraker 教授將 SQL 和NoSQL 數據庫進行了對比。SQL 和 NoSQL 數據庫可以通過下面的幾個特性和性能進行部分或全面比較 (注意：應該有更多的特征可以添加到下面的列表里。歡迎在評論里追加你認為能夠區別這兩種數據庫的特征)：
橫向和縱向擴展能力 – 關系型數據庫(傳統的數據庫)通常部署在一臺服務器上，通過增加處理器、內存和硬盤來進行升級。部署在多臺服務器上的關系型數據庫通常是依賴相互復制來保持數據同步。NoSQL 數據庫可以部署在單服務器上，但更多的是部署成云狀分布式 (NoSQL:分布式和可擴展的非關系型數據庫系統)。
列，key/value存儲，數組(Tuples)存儲 – 關系型數據庫通常是有表或視圖里的字段構成(固定的結構，用各種操作相互關聯)。NoSQL 數據庫通常存儲的是一對鍵值或 數組式(Tuples) (結構不固定，只是一個有順序的數據隊列)。 數據的內存和硬盤使用 – 關系型數據庫通常是駐留在一個硬盤內或一個網絡存儲空間里。SQL查詢或存儲過程操作會把數據集提取到內存空間里。一些 (并不是全部) NoSQL 數據庫可以直接在硬盤上操作，也可以通過內存來加快速度。
面向文檔型（Document-Oriented）, 面向集合型（Collection-Oriented）, 面向列型（Column-Oriented）；
面向對象型（Object-Oriented）, 面向有序集合型（Set-Oriented）, 面向行型（Row-Oriented）。
面向文檔型數據庫存儲的是文檔、屬性和XML。面向集合型的數據集提供了更適合面向對象編程語言的特性。關系型數據庫的特性是用表，行，列（面向列型）來組織數據。SQL查詢操作通常返回的是指向包含特定列的某行或某些行的集合的指針。面向對象的數據庫之所以出現是由于面向對象的編程的流行，但目前為止（以及將來很多年里）關系型數據庫仍是數據存儲模式里占有霸主地位。面向對象型數據庫也是 NoSQL 數據庫嗎? 對象關系映射(ORM)框架的興起將面向對象編程和大多數關系型數據緊緊的綁到了一起。 NoSQL 數據庫里的數據通常是存儲成對象、key/value、或數組（tuples）形式。 NoSQL 數據庫的查詢操作通常由編程代碼或一個接口完成。
在一次郵件交流里，Charlie Caro 對我說了下面的話：”如果 Facebook 需要去管理 100,000,000個用戶的個人信息，一個分布式的、不依賴于環境的，key-value形式的存儲模式是最適合不過了。在這樣大數量的用戶里查詢會沒有問題，但只要一個用戶的更新操作就可能讓傳統的數據庫過載宕機。多用戶讀數據時一個用戶更新數據，這需要并發控制。在多數情況下，NoSQL方案之所以能吸引它的用戶群的原因是它的易于安裝和使用的特征，SQL數據庫需要較多的運行條件(schema 等)，但正是這些schema方案給了并行關系型數據系統的高性能。易使用的好處更多的是體現在編程開發的時候。今天的許多程序員都更傾向于使用腳本語言，而不是相同功能的更安全的靜態類型檢查的編譯型語言。腳本型語言只是容錯性強和易于上手，有些軟件能把這些腳本程序編譯成.NET/Java字節碼來提高運行性能。” 我和他都認為，所有的這一切都是為了讓我們在工作中有更好的工具使用，而且從來都是這樣！當有螺絲刀時誰還用錘子去釘螺絲釘。
在“SQL數據庫的終結– 第二篇(共三篇)”中，我們以同樣的視角來看一看目前已經出現的一些開源的或非開源的NoSQL數據庫。之后在”SQL 數據庫的終結 – 第三篇” 中，我將會告訴大家一些因特網上關于NoSQL的資料，過去和將要發生的事件，以及一些相關指導。
數年以后，我估計我們大多數還是要依賴于關系數據庫和SQL。我當然有愿望，我將會不斷的研究尋找更好的方式去弱化和封裝數據訪問操作。一直以來，任何工程決策都是跟用戶和業務需求相適應的。對于以后的軟件工程來說，我相信，我們一定會找到一個合適的非關系型數據存儲產品。你是否正在使用非關系型數據庫呢？你是否已經放棄了SQL和關系型數據庫呢？你是否正在把你的數據轉移到一個公共的或私有的云數據庫里呢？請發表評論。
編程就是人生！
相關閱讀
NoSQL，意即反SQL運動，是一項全新的數據庫革命性運動，早期就有人提出，發展至2009年趨勢越發高漲。NoSQL的擁護者們提倡運用非關系型的數據存儲，相對于目前鋪天蓋地的關系型數據庫運用，這一概念無疑是一種全新的思維的注入。
現今的計算機體系結構在數據存儲方面要求具備龐大的水平擴展性，而NoSQL致力于改變這一現狀。目前Google的 BigTable 和Amazon 的Dynamo使用的就是NoSQL型數據庫。
NoSQL項目的名字上看不出什么相同之處，但是，它們通常在某些方面相同：它們可以處理超大量的數據。
這場革命目前仍然需要等待。的確，NoSQL對大型企業來說還不是主流，但是，一兩年之后很可能就會變個樣子。在NoSQL運動的***一次聚會中，來自世界各地的150人擠滿了CBS Interactive的一間會議室。分享他們如何推翻緩慢而昂貴的關系數據庫的暴政，怎樣使用更有效和更便宜的方法來管理數據。
“關系型數據庫給你強加了太多東西。它們要你強行修改對象數據，以滿足RDBMS （relational database management system，關系型數據庫管理系統）的需要，”在NoSQL擁護者們看來，基于NoSQL的替代方案“只是給你所需要的”。
原文標題：SQL數據庫的終結?
鏈接：http://news.cnblogs.com/n/59905/
【更多關于數據庫發展的趨勢性報道】
