宅男程序員給老婆的計算機課程之4:SQL vs NoSQL

時間 2020-04-07

原文原文鏈接

男主角：Wuvist（新浪微博），真名翁偉，自稱胖程序員一個，幸虧已婚。學習.NET出身，現經常使用Python作服務器端開發，曾任新加坡某創業公司主程。公司被Techcrunch blog事後，以爲新加坡生活太過安逸，終於在去年辭職隻身回家鄉汕頭創業，活躍於珠三角技術沙龍，熱衷於與其餘技術宅分享。前端

本文做者：Wuvistmysql

女主角：Katze，Wuvist的老婆，女程序員，在某跨國投行任Unix系統管理員，常被Wuvist嘲笑技術太差。程序員

【51CTO獨家特稿】在幾乎全部的web應用中，數據庫都是核心的一環。web

Web應用每每都是「Database driven」，業務、數據都是由數據庫完成，而前端頁面僅僅是演示、修改數據的一個「殼」。redis

所以不少web框架，都會標榜本身可以兼容多少多少數據庫，作CRUD多麼多麼容易。sql

通常上，提到數據庫的時候，指的都是關係型數據庫；但關係型數據庫並不是惟一的一種數據庫類型。數據庫

關係型數據庫，一開始即是設計爲通用，並有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系列：