NoSQL:一個帝國的崛起

01關係數據庫帝國

如今是公元2009年,關係帝國已經統治了咱們30多年,實在是過久了。 程序員

1970年,科德提出關係模型,1974年張伯倫和博伊斯製造出了SQL ,帝國迅速創建起了統治。 redis

從北美到歐洲, 從歐洲到亞洲,  無數程序員臣服在他的腳下。 數據庫

帝國給咱們提供了良好的福利:編程

簡單而強大的關係模型瀏覽器

靈活的SQL緩存

還有咱們很是喜歡的事務和ACID,把咱們從底層併發的細節中解放出來。 網絡

使用這些福利,程序員們開發了無數的系統,每一個系統的核心都是關係數據庫。 session

時代在不斷地變遷,編程語言的城頭不斷變換大王旗,可是存儲在表格中的數據,一直巋然不動。 架構

數據永遠是一個企業最寶貴的資產。 併發

可是帝國也給咱們套上了沉重的枷鎖:模式和規範化。 

帝國規定:必須事先定義好模式(表結構)才能保存數據! 

全部的數據至少得知足第一範式,甚至第二範式、第三範式、BCNF範式!

 若是實現不了,就會被投進監獄,對於某些部落來說,即便是作一個簡單的冗餘字段,都會被別人恥笑。 

帝國宣稱的SQL移植性也欺騙了咱們,SQL雖然被標準化,可是每一個廠商DB2, Oracle, SQL Server都有本身的方言! 

尤爲是在計算日期和字符串操做。還有存儲過程,幾乎每一個廠商都會本身搞一套,根本沒法移植!

 

0危機

 

上世紀90年代,面向對象技術的流行給帝國帶來了一次嚴重的危機: 

對象-關係的阻抗不匹配。 

「對象(Object)」有繼承,子類,父類,關聯,聚合,多態; 

而關係數據庫就是簡單的表格! 

他們是如此的不一樣,簡直是水火不容,矛盾不可調和。

 

那個時候,帝國的東邊出現了一個叫面向對象數據庫OODB的部落, 號稱能夠把Java對象,C#對象,Ruby對象等等都一股腦地、直接存儲到OODB當中去。 

把對象直接保存到數據庫?這實在是一個美妙的特性。 

可是OODB實在是不爭氣,很快偃旗息鼓,在幾個小領地苟延殘喘。 

2001年,有個叫Gavin King的27歲小夥子,開發了一個叫作Hibernate 的東西,在對象和關係之間搭了一座橋,叫O/R Mapping。 

這一會兒贏得了Java 程序員的芳心。 

Hibernate再接再勵,又推出了NHibernate, 打入了.NET的領地。 

隨着iBatis, JPA等更多O/R Mapping工具和接口的出現,關係數據庫帝國成功地度過了這一次的危機。 

後來有個好事者Martin Fowler,竟然寫了一本書《企業應用架構模式》, 在裏邊一本正經地把各類O/R Mapping的模式都總結了一遍:「單表繼承」,「類表繼承」,「活動記錄」。。。。。。 

這一番騷操做又替關係數據庫帝國續命20年不止。 

 

0新但願

 

沒過多久,互聯網大潮來了,歷史再次給了咱們一個機會。 

互聯網的用戶數如此之多,併發數如此之高, 讓咱們始料未及。 

數據量是如此巨大,數據種類如此豐富,更讓咱們目瞪口呆。 

文字、圖片、連接、日誌、社交關係,大量的數據蜂擁而至,單臺機器上的數據庫很快就撐不住了。  

帝國先是拼命擴容,巴不得把一臺機器弄成1024G的內存,1024T的硬盤,還美名其曰垂直擴展。 

可是機器功能越強,價格就越貴,臣民們的稅負愈來愈重,很快就受不了了。 

沒辦法,帝國只好作水平擴展,把數據分佈在多臺機器上,這須要精心的規劃,還須要程序員和應用程序精確地記住每一份數據放在哪裏。 

更要命的是,這種辦法丟掉了帝國引覺得傲的福利:事務和一致性 

 

 

0反抗

 

我決定反抗這個龐大的帝國,  我偷偷地帶領着一幫志同道合的兄弟離開了,咱們要新建一塊清新自由的領地。  

咱們仔細地研究了關係帝國的缺點,派出了幾隻小分隊分頭出擊。 

誓師出征之時,咱們對這四隻小分隊都提出了一樣的要求:支持分佈式和集羣!!! 

第一支小分隊由redis擔任隊長,memcached 擔任副手,他們很快便取得了成功,由於他們打擊到了關係帝國最大的缺點:高併發下,數據庫IO很是緩慢。 

redis和memcached 作了一個大膽的決定,拋棄了硬盤,選擇了比硬盤快幾萬倍的內存, 把數據以key-value的方式放入其中。 

超快的速度讓程序員們很是喜歡,他們不只把session,配置信息,購物車的數據放入其中。 

後來乾脆把他倆當成了緩存來使用。 

 

第二支小分隊由Mongodb帶領,CouchDB輔佐,他們敏銳地瞄準了用關係數據表保存起來很彆扭的數據。

 

 

訂單到訂單項和支付, 訂單項到產品是典型的一對多關係,意味着數據是樹狀結構,那爲何不直接用一個JSON文檔來表示呢?

  {    "orderId":"1",   

       "userId":"123",   

  "lineItems":[       

    {"productId":"1356",            "qty":"1"        },       

             {  "productId":"2375",            "qty":"2"        }   

  ],   

        "shippingAddress":{        "type":"xxx",        "address":"xxx"    },   

        "payment":{        "type":"alipay",        "time":"xxxx"    }

}  

MongoDB還和JavaScript,Node.js勾勾搭搭,把瀏覽器發來的JSON數據直接存儲到MongoDB中,輕鬆又方便。 

第三支小分隊的頭領是Neo4j, 這傢伙很是擅長圖結構,對於社交網絡、推薦系統的數據,用它來表示很是合適。

 

第四支小分隊由HBase帶領, Cassandra殿後, 他們都是列式數據庫,百億行 * 百萬列的數據對於他倆來講稀鬆日常。

 

 這個小分隊也得到了巨大的成功,移動互聯網所產生的海量數據,如日誌、聊天記錄,監控數據,物聯網的數據,結構化並不強,很是適合用HBase這種列式數據庫來存放。

 

0新的帝國

 

幾年之後,四支小分隊順利班師,都帶回了大批的程序員擁躉,由於適合的纔是最好的。 

一個新的、能夠和關係數據庫抗衡的帝國悄然成型。 

通過一番激烈討論,咱們給帝國起了一個響亮的名稱:NoSQL。 

意思是不要SQL! 

可是,加入NoSQL帝國的程序員發現咱們也有很是明顯的弱點: 

缺少模式(如表結構)、數據完整性約束很弱、對事務的支持很弱,甚至乾脆沒有, 這引發了程序員的強烈不滿和抗議。 

有很多人短暫嚐鮮NoSQL之後,又拋棄了咱們,重回SQL的懷抱。 

咱們決定和關係數據庫帝國議和,告訴他們說NoSQL的意思是Not Only SQL, 咱們兩大帝國應該取長補短,和平共處。 

經歷了幾年戰火的關係數據帝國也看清楚了IT趨勢,欣然接受。 

今後,數據庫進入了混合存儲的時代! 

 

公衆號碼農翻身

 

相關文章
相關標籤/搜索