NoSQL ：一個(gè)帝國的崛起
01關(guān)系數(shù)據(jù)庫帝國
現(xiàn)在是公元2009年，關(guān)系帝國已經(jīng)統(tǒng)治了我們30多年，實(shí)在是太久了。
1970年，科德提出關(guān)系模型，1974年張伯倫和博伊斯制造出了SQL ，帝國迅速建立起了統(tǒng)治。
從北美到歐洲， 從歐洲到亞洲， 無數(shù)程序員臣服在他的腳下。
帝國給我們提供了良好的福利：
簡單而強(qiáng)大的關(guān)系模型
靈活的SQL
還有我們非常喜歡的事務(wù)和ACID，把我們從底層并發(fā)的細(xì)節(jié)中解放出來。
使用這些福利，程序員們開發(fā)了無數(shù)的系統(tǒng)，每個(gè)系統(tǒng)的核心都是關(guān)系數(shù)據(jù)庫。
時(shí)代在不斷地變遷，編程語言的城頭不斷變換大王旗，但是存儲在表格中的數(shù)據(jù)，一直巋然不動(dòng)。
數(shù)據(jù)永遠(yuǎn)是一個(gè)企業(yè)最寶貴的資產(chǎn)。
但是帝國也給我們套上了沉重的枷鎖：模式和規(guī)范化。
帝國規(guī)定：必須事先定義好模式(表結(jié)構(gòu))才能保存數(shù)據(jù)!
所有的數(shù)據(jù)至少得滿足第一范式，甚至第二范式、第三范式、BCNF范式!
如果實(shí)現(xiàn)不了，就會(huì)被投進(jìn)監(jiān)獄，對于某些部落來講，即使是做一個(gè)簡單的冗余字段，都會(huì)被別人恥笑。
帝國宣稱的SQL移植性也欺騙了我們，SQL雖然被標(biāo)準(zhǔn)化，但是每個(gè)廠商DB2, Oracle, SQL Server都有自己的方言!
尤其是在計(jì)算日期和字符串操作。還有存儲過程，幾乎每個(gè)廠商都會(huì)自己搞一套，根本無法移植!
02危機(jī)
上世紀(jì)90年代，面向?qū)ο蠹夹g(shù)的流行給帝國帶來了一次嚴(yán)重的危機(jī)：
對象-關(guān)系的阻抗不匹配。
“對象(Object)”有繼承，子類，父類，關(guān)聯(lián)，聚合，多態(tài);
而關(guān)系數(shù)據(jù)庫就是簡單的表格!
他們是如此的不同，簡直是水火不容，矛盾不可調(diào)和。
那個(gè)時(shí)候，帝國的東邊出現(xiàn)了一個(gè)叫面向?qū)ο髷?shù)據(jù)庫OODB的部落， 號稱可以把Java對象，C#對象，Ruby對象等等都一股腦地、直接存儲到OODB當(dāng)中去。
把對象直接保存到數(shù)據(jù)庫?這實(shí)在是一個(gè)美妙的特性。
但是OODB實(shí)在是不爭氣，很快偃旗息鼓，在幾個(gè)小領(lǐng)地茍延殘喘。
2001年，有個(gè)叫Gavin King的27歲小伙子，開發(fā)了一個(gè)叫做Hibernate 的東西，在對象和關(guān)系之間搭了一座橋，叫O/R Mapping。
這一下子贏得了Java 程序員的芳心。
Hibernate再接再勵(lì)，又推出了NHibernate， 打入了.NET的領(lǐng)地。
隨著iBatis, JPA等更多O/R Mapping工具和接口的出現(xiàn)，關(guān)系數(shù)據(jù)庫帝國成功地度過了這一次的危機(jī)。
后來有個(gè)好事者M(jìn)artin Fowler，居然寫了一本書《企業(yè)應(yīng)用架構(gòu)模式》， 在里邊一本正經(jīng)地把各種O/R Mapping的模式都總結(jié)了一遍：“單表繼承”，“類表繼承”，“活動(dòng)記錄”。。。。。。
這一番騷操作又替關(guān)系數(shù)據(jù)庫帝國續(xù)命20年不止。
03新希望
沒過多久，互聯(lián)網(wǎng)大潮來了，歷史再次給了我們一個(gè)機(jī)會(huì)。
互聯(lián)網(wǎng)的用戶數(shù)如此之多，并發(fā)數(shù)如此之高， 讓我們始料未及。
數(shù)據(jù)量是如此巨大，數(shù)據(jù)種類如此豐富，更讓我們目瞪口呆。
文字、圖片、鏈接、日志、社交關(guān)系，大量的數(shù)據(jù)蜂擁而至，單臺機(jī)器上的數(shù)據(jù)庫很快就撐不住了。
帝國先是拼命擴(kuò)容，恨不得把一臺機(jī)器弄成1024G的內(nèi)存，1024T的硬盤，還美名其曰垂直擴(kuò)展。
但是機(jī)器功能越強(qiáng)，價(jià)格就越貴，臣民們的稅負(fù)越來越重，很快就受不了了。
沒辦法，帝國只好做水平擴(kuò)展，把數(shù)據(jù)分布在多臺機(jī)器上，這需要精心的規(guī)劃，還需要程序員和應(yīng)用程序精確地記住每一份數(shù)據(jù)放在哪里。
更要命的是，這種辦法丟掉了帝國引以為傲的福利：事務(wù)和一致性
04反抗
我決定反抗這個(gè)龐大的帝國， 我偷偷地帶領(lǐng)著一幫志同道合的兄弟離開了，我們要新建一塊清新自由的領(lǐng)地。
我們仔細(xì)地研究了關(guān)系帝國的缺點(diǎn)，派出了幾只小分隊(duì)分頭出擊。
誓師出征之時(shí)，我們對這四只小分隊(duì)都提出了同樣的要求：支持分布式和集群!!!
第一支小分隊(duì)由redis擔(dān)任隊(duì)長，memcached 擔(dān)任副手，他們很快便取得了成功，因?yàn)樗麄兇驌舻搅岁P(guān)系帝國最大的缺點(diǎn)：高并發(fā)下，數(shù)據(jù)庫IO非常緩慢。
redis和memcached 做了一個(gè)大膽的決定，拋棄了硬盤，選擇了比硬盤快幾萬倍的內(nèi)存， 把數(shù)據(jù)以key-value的方式放入其中。
超快的速度讓程序員們非常喜歡，他們不僅把session，配置信息，購物車的數(shù)據(jù)放入其中。
后來干脆把他倆當(dāng)成了緩存來使用。
第二支小分隊(duì)由Mongodb帶領(lǐng)，CouchDB輔佐，他們敏銳地瞄準(zhǔn)了用關(guān)系數(shù)據(jù)表保存起來很別扭的數(shù)據(jù)。
訂單到訂單項(xiàng)和支付， 訂單項(xiàng)到產(chǎn)品是典型的一對多關(guān)系，意味著數(shù)據(jù)是樹狀結(jié)構(gòu)，那為什么不直接用一個(gè)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勾勾搭搭，把瀏覽器發(fā)來的JSON數(shù)據(jù)直接存儲到MongoDB中，輕松又方便。
第三支小分隊(duì)的頭領(lǐng)是Neo4j， 這家伙非常擅長圖結(jié)構(gòu)，對于社交網(wǎng)絡(luò)、推薦系統(tǒng)的數(shù)據(jù)，用它來表示非常合適。
第四支小分隊(duì)由HBase帶領(lǐng)， Cassandra殿后， 他們都是列式數(shù)據(jù)庫，百億行 * 百萬列的數(shù)據(jù)對于他倆來說稀松平常。
這個(gè)小分隊(duì)也獲得了巨大的成功，移動(dòng)互聯(lián)網(wǎng)所產(chǎn)生的海量數(shù)據(jù)，如日志、聊天記錄，監(jiān)控?cái)?shù)據(jù)，物聯(lián)網(wǎng)的數(shù)據(jù)，結(jié)構(gòu)化并不強(qiáng)，非常適合用HBase這種列式數(shù)據(jù)庫來存放。
05新的帝國
幾年以后，四支小分隊(duì)順利班師，都帶回了大批的程序員擁躉，因?yàn)檫m合的才是最好的。
一個(gè)新的、可以和關(guān)系數(shù)據(jù)庫抗衡的帝國悄然成型。
經(jīng)過一番激烈討論，我們給帝國起了一個(gè)響亮的名稱：NoSQL。
意思是不要SQL!
但是，加入NoSQL帝國的程序員發(fā)現(xiàn)我們也有非常明顯的弱點(diǎn)：
缺乏模式(如表結(jié)構(gòu))、數(shù)據(jù)完整性約束很弱、對事務(wù)的支持很弱，甚至干脆沒有， 這引起了程序員的強(qiáng)烈不滿和抗議。
有不少人短暫嘗鮮NoSQL以后，又拋棄了我們，重回SQL的懷抱。
我們決定和關(guān)系數(shù)據(jù)庫帝國議和，告訴他們說NoSQL的意思是Not Only SQL， 我們兩大帝國應(yīng)該取長補(bǔ)短，和平共處。
經(jīng)歷了幾年戰(zhàn)火的關(guān)系數(shù)據(jù)帝國也看清楚了IT趨勢，欣然接受。
從此，數(shù)據(jù)庫進(jìn)入了混合存儲的時(shí)代!
