01關聯式資料庫帝國
現在是公元2009年，關係帝國已經統治了我們30多年，實在是太久了。
1970年，科德提出關係模型，1974年張伯倫和博伊斯製造出了SQL ，帝國迅速建立起了統治。
從北美到歐洲， 從歐洲到亞洲， 無數程式設計師臣服在他的腳下。
帝國給我們提供了良好的福利：
簡單而強大的關係模型
靈活的SQL
還有我們非常喜歡的事務和ACID，把我們從底層併發的細節中解放出來。
使用這些福利，程式設計師們開發了無數的系統，每個系統的核心都是關聯式資料庫。
時代在不斷地變遷，程式語言的城頭不斷變換大王旗，但是儲存在表格中的資料，一直巋然不動。
資料永遠是一個企業最寶貴的資產。
但是帝國也給我們套上了沉重的枷鎖：模式和規範化。
帝國規定：必須事先定義好模式（表結構）才能儲存資料！
所有的資料至少得滿足第一正規化，甚至第二正規化、第三正規化、BCNF正規化！
如果實現不了，就會被投進監獄，對於某些部落來講，即使是做一個簡單的冗餘欄位，都會被別人恥笑。
帝國宣稱的SQL移植性也欺騙了我們，SQL雖然被標準化，但是每個廠商DB2, Oracle, SQL Server都有自己的方言！
尤其是在計算日期和字串操作。還有儲存過程，幾乎每個廠商都會自己搞一套，根本無法移植！
02 危機
上世紀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年不止。
03 新希望
沒過多久，網際網路大潮來了，歷史再次給了我們一個機會。
網際網路的使用者數如此之多，併發數如此之高， 讓我們始料未及。
資料量是如此巨大，資料種類如此豐富，更讓我們目瞪口呆。
文字、圖片、連結、日誌、社交關係，大量的資料蜂擁而至，單臺機器上的資料庫很快就撐不住了。
帝國先是拼命擴容，恨不得把一臺機器弄成1024G的記憶體，1024T的硬碟，還美名其曰垂直擴充套件。
但是機器功能越強，價格就越貴，臣民們的稅負越來越重，很快就受不了了。
沒辦法，帝國只好做水平擴充套件，把資料分佈在多臺機器上，這需要精心的規劃，還需要程式設計師和應用程式精確地記住每一份資料放在哪裡。
更要命的是，這種辦法丟掉了帝國引以為傲的福利：事務和一致性
04 反抗
我決定反抗這個龐大的帝國， 我偷偷地帶領著一幫志同道合的兄弟離開了，我們要新建一塊清新自由的領地。
我們仔細地研究了關係帝國的缺點，派出了幾隻小分隊分頭出擊。
誓師出征之時，我們對這四隻小分隊都提出了同樣的要求：支援分散式和叢集!!!
第一支小分隊由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這種列式資料庫來存放。
05 新的帝國
幾年以後，四支小分隊順利班師，都帶回了大批的程式設計師擁躉，因為適合的才是最好的。
一個新的、可以和關聯式資料庫抗衡的帝國悄然成型。
經過一番激烈討論，我們給帝國起了一個響亮的名稱：NoSQL。
意思是不要SQL！
但是，加入NoSQL帝國的程式設計師發現我們也有非常明顯的弱點：
缺乏模式（如表結構）、資料完整性約束很弱、對事務的支援很弱，甚至乾脆沒有， 這引起了程式設計師的強烈不滿和抗議。
有不少人短暫嚐鮮NoSQL以後，又拋棄了我們，重回SQL的懷抱。
我們決定和關聯式資料庫帝國議和，告訴他們說NoSQL的意思是Not Only SQL， 我們兩大帝國應該取長補短，和平共處。
經歷了幾年戰火的關係資料帝國也看清楚了IT趨勢，欣然接受。
從此，資料庫進入了混合儲存的時代！
公眾號碼農翻身
