NoSQL：一個帝國的崛起
- 2021 年 2 月 3 日
- 筆記
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趨勢，欣然接受。
從此，資料庫進入了混合存儲的時代！
公眾號碼農翻身
