如同拉里.埃里森的豪華游艇一樣,關系型數據庫正駛向日薄西山之處。但對NoSQL而言,標準的查詢語言和應用程序接口亟待建立標準。
Oracle已稱霸數據庫世界多年,但在未來,霸權的衰落不可避免的。在NoSQL和大數據浪潮的沖擊下,基于邏輯范式設計的RDBMS已然搖搖欲墜。雖然Oracle及其盟友已經做出了快速的反映,并推出了自己的NoSQL數據庫,但是Oracle所面對的尷尬情形就如同當年的Novell一樣。
關系型數據庫不會立刻消亡,它是一種影響深遠的技術,在數據庫領域曾獨領風騷。關系型數據庫有著嚴密的數學背景,其事務處理具有著名的ACID屬性:原子性(Atomicity)、一致性(Consistency)、隔離性(Isolation)、持久性(Durability)。
但我并不認為事務處理是關系型數據庫的優勢。事務處理跨越多個請求和響應周期,保證數據一致性的能力往往被夸大了。除了事務處理機制,我們還有其它方法保證數據一致性。
關系型數據庫最大的優勢其實是標準化。關系型數據庫自身的發展史也證明,即便是最基本的標準化也比漫無章法更能占據市場。事實上,標準化也成為數據庫融合、收購的極大障礙。
從關系型數據庫到NoSQL的過渡是不可避免的。關系型數據庫早在硬盤只有10MB的時代就被創造出來,而在現在,存儲已經非常便宜,我們對性能和擴展性的期望也變得非常高。另一方面,隨著互聯網信息的膨脹,我們對數據分析和數據挖掘的要求也與日俱增。毫無疑問,在互聯網時代,NoSQL才是數據庫的未來。
許多公司并不具備能力極強的IT部門,也有許多公司通過外包的方式維持IT的運營。以Oracle數據庫為例,在許多公司可能很缺乏具備專業知識的DBA,甚至其職責往往由系統管理員代理。傳統數據庫的復雜度成為阻礙公司發展的瓶頸。
所有的一切都意味著,我們不必使用結構化的數據,我們追求數據庫的分布式、低延遲,以及快速處理海量數據的能力。
然而,這種轉變困難重重。NoSQL缺乏一種主導力量。以關系型數據庫為例,不管你選擇哪種數據庫產品(例如,DB2、Oracle或者SQL Server),它們都會遵循ANSI SQL標準,這讓我們有所依賴。對于新的數據庫,Pig、Hive等查詢語言,也讓我們覺得有共通之處。關系型數據庫為我們提供了標準的訪問接口,即便是最古老的ODBC。而對于NoSQL,你必須使用特定的數據庫連接器。
大家都知道,NoSQL并不是為所有人設計的,但是標準的設計有助于市場的拓展。不論是對于可能成為潛在客戶的大型機構,還是對于獨立的風險投資商,標準化的產品、供應商、長期的技術支持都是吸引其注意力的籌碼。當今,幾乎沒有人樂意采購昂貴的軟件,但標準化仍然可以為技術的發展提供良好的空間。
為什么NoSQL要與傳統的關系型數據庫一決雌雄?原因就在于爭奪數據庫驅動SPI(服務編程接口)和API對主要編程語言平臺的支持,這和構建標準化的查詢語言別無二致。
不必追求完美的標準。關系型數據庫供應商也沒有在標準化方面做到盡善盡美,NoSQL只要將標準化做到足夠好,足夠吸引人,以至于人們樂意遷移到NoSQL平臺就可以了。另一方面,我們要考慮到如何為不同類型的NoSQL數據庫制定標準,比如文檔類型的MongoDB,圖形數據庫Neo4j。
對圖形數據庫設計的查詢語言不一定適用于文檔數據庫或鍵值結構數據庫。當然,在常規情況下,我們的查詢都很簡單,非常容易得到支持。這些非關系型數據庫也有許多共通之處,例如,它們都支持層次化查詢(hierarchical query)。我認為,一種標準不是一種強制,而是一種建議。
微軟的一些研究人員也曾提出NoSQL的標準化問題。他們曾試圖使MongoDB支持UnQL和LINQ。在Java的世界里,Spring Data是通用的CRUD接口,但一切還沒有眉目。
NoSQL供應商及所有NoSQL支持者是時候走到一起了!乘風破浪,共同制定NoSQL的標準,迎接NoSQL的未來!(張志平/編譯)
bitsCN.com聲明:本網頁內容旨在傳播知識,若有侵權等問題請及時與本網聯系,我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com