做一個(gè)新業(yè)務(wù)，我該選擇SQL還是NoSQL?
很多時(shí)候我們都會(huì)有這樣的疑問(wèn)。
如果這時(shí)候直接去看MySQL、Mongo、HBase、redis等數(shù)據(jù)庫(kù)的用法、特點(diǎn)、區(qū)別，其實(shí)有點(diǎn)太著急了。
這時(shí)候，最好從「數(shù)據(jù)模型」開(kāi)始討論。
1、SQL vs NoSQL
現(xiàn)在最著名的數(shù)據(jù)模型應(yīng)該是SQL，它基于Edgar Codd在1970年提出的關(guān)系模型：
數(shù)據(jù)被組織成關(guān)系（relations），在SQL中稱為表（table），其中每個(gè)關(guān)系都是元組（tuples)的無(wú)序集合（在SQL中稱為行）。
那什么是NoSQL？
現(xiàn)在很多非關(guān)系型數(shù)據(jù)庫(kù)會(huì)被稱為NoSQL，其含義往往被解釋 “Not only SQL”。
采用NoSQL的驅(qū)動(dòng)因素在于：
- 數(shù)據(jù)量。 比SQL更好的擴(kuò)展性需求，包括支持超大數(shù)據(jù)集或超高寫(xiě)入吞吐量
- 查詢方式。 關(guān)系模型不能很好支持的一些特定查詢操作
- 動(dòng)態(tài)擴(kuò)展。 對(duì)關(guān)系模式的一些限制表示沮喪，需要更加具有動(dòng)態(tài)和表達(dá)力的數(shù)據(jù)模型
2、數(shù)據(jù)模型的差異
SQL 和 NoSQL數(shù)據(jù)庫(kù)的差異有很多，包括容錯(cuò)性和并發(fā)處理，我們這里暫時(shí)只討論數(shù)據(jù)模型的差異。
關(guān)系型模型的主要優(yōu)勢(shì)在于：
- 聯(lián)結(jié)操作
- 多對(duì)一和多對(duì)多關(guān)系更簡(jiǎn)潔的表達(dá)
注意，簡(jiǎn)單的多對(duì)多適合關(guān)系型模型，復(fù)雜的多對(duì)多更適合圖模型
我們以文檔型NoSQL為例，它和SQL對(duì)比的核心優(yōu)勢(shì)在于：
- 模式靈活性
- 局部性帶來(lái)的性能優(yōu)勢(shì)
（1）模式靈活性
「模式靈活性」的特點(diǎn)，往往被稱為「schema-fress模式」，但是我們并不能將它直接理解為“無(wú)模式”。
因?yàn)槲覀冊(cè)谧x取數(shù)據(jù)時(shí)，往往存在某種數(shù)據(jù)結(jié)構(gòu)的隱式轉(zhuǎn)換，所以我們稱之為「讀時(shí)模式」更準(zhǔn)確（數(shù)據(jù)結(jié)構(gòu)是隱式的，只有讀取時(shí)才解釋）。
而傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)，對(duì)應(yīng)可以稱之為「寫(xiě)時(shí)模式」（模式是顯示的，并且在寫(xiě)入數(shù)據(jù)庫(kù)時(shí)被約束必須遵守）。
這兩者差異跟編程語(yǔ)言中的動(dòng)態(tài)檢查（運(yùn)行時(shí)）和靜態(tài)檢查（編譯時(shí)）比較類似。
「模式靈活性」的優(yōu)點(diǎn)在于：
- 避免了大表變更時(shí)的停機(jī)或者耗時(shí)
- 支持包含多種類似數(shù)據(jù)結(jié)構(gòu)
- 可以隨時(shí)改變數(shù)據(jù)結(jié)構(gòu)
「模式靈活性」帶來(lái)的損害則是需要應(yīng)用層做好結(jié)構(gòu)約束，并且保證對(duì)歷史數(shù)據(jù)的兼容性。
一般典型關(guān)系型場(chǎng)景，「模式靈活性」反而會(huì)導(dǎo)致難以維護(hù)。
（2）局部性的性能優(yōu)勢(shì)
注意注意，局部性優(yōu)勢(shì)僅適用于需要同時(shí)訪問(wèn)文檔中大部分?jǐn)?shù)據(jù)的場(chǎng)景。
如果我們的查詢需要訪問(wèn)整個(gè)文檔，那么存儲(chǔ)局部性具備顯著的性能優(yōu)勢(shì)。
此時(shí)，如果數(shù)據(jù)被劃分到了多個(gè)表中，則需要訪問(wèn)多個(gè)表來(lái)檢索數(shù)據(jù)，會(huì)浪費(fèi)更多的磁盤(pán)IO并花費(fèi)更多的時(shí)間。
如果我們的訪問(wèn)只需要文檔中的一小部分?jǐn)?shù)據(jù)，那么對(duì)于大型文檔來(lái)說(shuō)就是一種浪費(fèi)。
3、數(shù)據(jù)模型分析原則
對(duì)于一份數(shù)據(jù)存儲(chǔ)，「數(shù)據(jù)模型」的建立， 就是考慮應(yīng)該通過(guò) SQL 還是 NoSQL 進(jìn)行 數(shù)據(jù)組織 。
那么，結(jié)合前面對(duì)SQL和NoSQL的介紹與對(duì)比，我們總結(jié)了以下幾個(gè)維度，來(lái)具體考慮如何建立「數(shù)據(jù)模型」。
（1）數(shù)據(jù)對(duì)象關(guān)系
多對(duì)一或者多對(duì)多，一般考慮SQL。
一對(duì)多的關(guān)系，可以考慮SQL或者NoSQL。
（2）查詢性能
如果我們的查詢通常需要訪問(wèn)整個(gè)文檔，那么存儲(chǔ)局部性具備顯著的性能優(yōu)勢(shì)，關(guān)系型的join性能較差，因此可以考慮NoSQL。
（業(yè)務(wù)上，一般會(huì)通過(guò)整體結(jié)果緩存，對(duì)關(guān)系型join查詢加速）
如果通常是局部數(shù)據(jù)對(duì)象、獨(dú)立實(shí)體查詢，考慮SQL。
（3）寫(xiě)入吞吐量
如果需要超高的寫(xiě)入吞吐量，考慮NoSQL。
（4）擴(kuò)展性
- 屬性擴(kuò)展：如果對(duì)象屬性不確定，且經(jīng)常變動(dòng)，NoSQL更靈活。
- 超大數(shù)據(jù)集擴(kuò)展：NoSQL通常更好。
- 單value大小：?jiǎn)蝪alue如果過(guò)大，可能導(dǎo)致數(shù)據(jù)庫(kù)寫(xiě)入失敗?？紤]拆分對(duì)象，或者分級(jí)存儲(chǔ)到對(duì)象存儲(chǔ)。一般單value不要超過(guò)100KB（壓縮后）。
（5）延遲選擇數(shù)據(jù)庫(kù)類型
數(shù)據(jù)模型分析主要是根據(jù)業(yè)務(wù)場(chǎng)景區(qū)分 關(guān)系型 還是 非關(guān)系型。
延遲考慮具體數(shù)據(jù)庫(kù)選型，用RDS還是Mongo還是其他數(shù)據(jù)庫(kù)，它們之間的功能性差異在逐漸變少。
具體選擇可以結(jié)合 研發(fā)人員熟悉程度、數(shù)據(jù)規(guī)模、其他非功能性需求 來(lái)判斷。
一些例子：
- Mongo 4.x支持事務(wù)
- MySQL 8.0支持JSON格式
- DB-engine上，mysql和mongo都從本身定位逐步擴(kuò)展為multi-model
