宅男程序員給老婆的計算機課程之4:SQL vs NoSQL
原創男主角：Wuvist（新浪微博），真名翁偉，自稱胖程序員一個，幸好已婚。學習.NET
本文作者：Wuvist
女主角：Katze，Wuvist的老婆，女程序員，
【51CTO獨家特稿】查看全部課程請訪問《宅男程序員給老婆的計算機課程》
在幾乎所有的web應用中，數據庫都是核心的一環。
Web應用往往都是“Database driven”，業務、數據都是由數據庫完成，而前端頁面僅僅是演示、修改數據的一個“殼”。
因此很多web框架，都會標榜自己能夠兼容多少多少數據庫，做CRUD多么多么容易。
一般上，提到數據庫的時候，指的都是關系型數據庫；但關系型數據庫并非唯一的一種數據庫類型。
關系型數據庫，一開始便是設計為通用，并有ACID支持的。
Atomicity 原子性、 Consistency 一致性、Isolation 隔絕性、Durability 持久性
殺手歐陽盆栽說：“每件事都有它的代價”。上述四個特性，都是有代價的。
對于嚴謹的商業應用，如銀行、交易系統；為求業務的安全，他們不得不，或者說，能夠并且愿意付出這些代價。
回到12306，后端數據庫傳說使用的是Oracle，而站出來說吐槽12306的行家往往都會提到 redis \ mysql 這樣的替代。
有些菜鳥“ED”看到這些吐槽就出來噴了，說這些行家不懂神馬業務安全性的重要，這幫做互聯網的弱爆了，票務是必須使用 Oracle才能搞定云云。
好像還有人專門去噴了Fenng，這實在是太諷刺了。Fenng實際上是Orcale ACE Director http://www.hudong.com/wiki/%E5%86%AF%E5%A4%A7%E8%BE%89，國內屈指可數的Oracle專家。
很多人，特別是弱“ED”、“專家教授”，沉寂在自己所在的領域，然后就以為“悟”了；實際上，僅是把自己變成了井底之蛙。
知識的廣博、全面性非常重要。
在某個領域，通用的東西成熟之后，往往就會有專用的解決方案出現。而專用的解決方案多了之后，又會有新的通用解決方案出現。
天下大勢，分久必合，合久必分。
計算機，最早有很多專用系統，如王安打字機；個人電腦通用之后，這些專用設備就湮滅了；而iPad、手機的涌現，則又是專用系統。
是的，傳統上需要去購買 Orcale、DB2 等巨貴無比的數據庫系統，去滿足業務需求；不是因為它們把問題解決到了極致，而是因為沒有別的選擇。時代已經變了，井底之蛙若把Oracle當成是王道，那只能被時代淘汰。
關系型數據庫作為通用解決方案，是非常非常好的；它是一把神刀。
但是，它有以下問題：
===== ED總是要寫爛SQL ====
首先. 還是那句話，有的人縱然神刀在手，亦無法成為刀中之神。關系型數據庫提供的SQL能力，是高度抽象的，封裝了無數層的。寫SQL的人，太多太多根本不了解SQL背后所執行的事情；爛“ED”都是如此。
這甚至造就了一個職業：DBA。DBA去負責數據庫微調、優化，聽起來很高級，但實質上，就是給濫用SQL的“ED”擦屁股而已。
對于龐大的企業來說，管理者是知道大部分ED都弱爆了，他不期望也不需要ED去了解數據庫，他只需要ED去完成最基本的業務功能，然后讓DBA去給ED擦屁股。
大部分的ED，并沒有意識到這一點；他們拼命去追求方便快捷的“搞定”；濫用SQL的各種高級功能；甚至，他們把分享SQL的復雜使用當成是樂事。
ED所努力的，是把自己變笨，把活盡可能的都交給神奇的數據庫去解決；數據庫怎么解決的，他們不關心；這實質上，是在削弱自己工作的技術含量，自我貶值而已。
工程師如果能夠把數據庫給用好了，哪里還有DBA什么事？
DBA所謂的數據庫優化，往往就是把工程師不負責任寫下的2B SQL查詢找出來，然后改寫為文藝方式罷了。
不要濫用數據庫，一點都不難。
===== 通用數據庫性能有極限 =====
其次，關系型數據庫作為通用解決方案，它提供了太多的東西，它做了太多的事，而所有的事情，都有它的代價，直接而言，就是犧牲性能了。
所以，DBA的另一個職責，則是把數據庫的各種參數調配好，讓其能夠發揮最高的性能。
從這個意義上去說，DBA的工作就不僅僅是給ED擦屁股了。
但，這樣的微調，是有極限的。DBA拚了命去把雞蛋豎立起來，考慮了桌面摩擦、空氣流動、手指顫抖等等因素，雞蛋雖然可以豎立一會，但終究還是會倒下去；這也就是微調的極限。
在某些場景下，是可以用手的：把業務中沒有用到的數據庫功能都去掉；甚至，去掉完整的ACID支持。
這樣一來，數據庫的性能就可以有數量級的改善了。
===== 關鍵在于靈活性 ====
最后，上面兩點，其實都是跟性能相關的；關系型數據庫即便作為通用方案，它的性能有極限，但也能夠滿足絕大多數應用場景了。關系型數據庫的軟肋，是在靈活性上。
數據庫有表、而表有結構；而表的結構，在應用上線之后，很難修改。
這同樣造就了一些專業學問：嚴密的業務分析、設計數據庫結構、如何在數據庫上線之后修改結構等等。
這些問題或者說學問之所以存在，是植根于關系型數據庫表結構不靈活的前提之上。
再次”Think out of the box“，如果數據庫可以做到靈活、隨時修改的表結構呢？
====== NoSQL ======
關系型數據庫的三個問題，被NoSQL全部解決了。
（同樣的，所有事情都有它的代價；NoSQL在解決SQL固有問題的同時，也引入了新的問題；另一方面，NoSQL解決的也不僅僅是SQL的這三個問題。）
ED要寫爛SQL？沒有關系，徹底不讓他們寫SQL好了。
數據庫支持功能太多？砍功能還不容易么？
Schema不靈活？那就schema-less好了。
目前，NoSQL的實現方案很多，MongoDB、Redis、Carssendra等等等等；每一個都可以非常不同，是專用解決方案：有自己獨有的特性，去解決特定場景的特定問題。
（當然，像MongoDB，已經很有NoSQL通用解決方案的意味了。）
普通程序員用SQL，文藝程序員用NoSQL，2B程序員把NoSQL當SQL用。
普通程序員在從SQL切換去NoSQL時，會受固有的SQL知識限制，總有把NoSQL當成SQL去用的沖動，但這是非常2B的行為。
從微觀的角度講，原來SQL查詢中所支持的各種神奇joining / groupby都不見了；拼命的想要去找在NoSQL數據庫環境下同樣的神奇工具。
這徹底違背了使用NoSQL的初衷：為了就是不讓你濫用SQL的這些神奇功能。
濫用SQL會造成嚴重的性能問題，而在性能問題浮現之后，需要耗費更大的力氣去糾正。
是的，信用卡透支購物很方便；但付賬單的時候就傻逼了；所以，換成無法透支的借記卡。
固然沒有了透支的便利，會有不方便，但徹底杜絕了還不起賬單，被收取高額利息的問題。
要透支的便利？ED，請先去掌握好理財技能，徹底了解透支的影響，然后我們再來談便利。
從宏觀的角度講，會有人企圖去給NoSQL做封裝，讓NoSQL表現得跟SQL一樣；甚至，去把NoSQL去掉的那些SQL功能加回去。
SQL已經是一個非常非常成熟的方案，它所能夠解決的問題范疇里面，幾乎沒有辦法做得比SQL更好。
在NoSQL的基礎上，去試圖模擬SQL，只能成為SQL的蹩腳模擬；還不如直接用回SQL。
在網路編程里面也有類似的例子，TCP跟UDP。可以把SQL看成是TCP，它是可靠、神奇的。UDP雖然不可靠，但是會比TCP更快。要做視頻、語音通訊，UDP是更好的選擇。但要去做“不丟包、不失幀”的可靠視頻通訊，選擇在UDP的基礎上添加確認、重發機制模擬TCP，那就是2B了。不是天才，沒法做得比TCP更好，直接用TCP就好。
作業：
1. NoSQL的方案，如MongoDB還解決了SQL的什么問題？
2. NoSQL的應用場景有啥米？
51CTO系列：
- 宅男程序員給老婆的計算機課程之0：認清本質
- 宅男程序員給老婆的計算機課程之1：認清實際
- 宅男程序員給老婆的計算機課程之2:怎么看待牛人
- 宅男程序員給老婆的計算機課程之3:架構比較
- 宅男程序員給老婆的計算機課程之4:SQL vs NoSQL
【編輯推薦】
- PHP+MySQL應用中使用XOR運算加密算法
- 保證你從來沒見過的算法的舞蹈（視頻）
- 淺談PHP 5中垃圾回收算法的演化
- JavaScript版幾種常見排序算法分享
- 程序員須知的二十世紀最偉大10大算法
