做一個(gè)新業(yè)務(wù)，我該選擇SQL還是NoSQL?

很多時(shí)候我們都會(huì)有這樣的疑問。

如果這時(shí)候直接去看MySQL、Mongo、HBase、Redis等數(shù)據(jù)庫的用法、特點(diǎn)、區(qū)別，其實(shí)有點(diǎn)太著急了。

這時(shí)候，最好從「數(shù)據(jù)模型」開始討論。

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)的無序集合（在SQL中稱為行）。

那什么是NoSQL？

現(xiàn)在很多非關(guān)系型數(shù)據(jù)庫會(huì)被稱為NoSQL，其含義往往被解釋 “Not only SQL”。

采用NoSQL的驅(qū)動(dòng)因素在于：

• 數(shù)據(jù)量。 比SQL更好的擴(kuò)展性需求，包括支持超大數(shù)據(jù)集或超高寫入吞吐量
• 查詢方式。 關(guān)系模型不能很好支持的一些特定查詢操作
• 動(dòng)態(tài)擴(kuò)展。 對(duì)關(guān)系模式的一些限制表示沮喪，需要更加具有動(dòng)態(tài)和表達(dá)力的數(shù)據(jù)模型

2、數(shù)據(jù)模型的差異

SQL 和 NoSQL數(shù)據(jù)庫的差異有很多，包括容錯(cuò)性和并發(fā)處理，我們這里暫時(shí)只討論數(shù)據(jù)模型的差異。

關(guān)系型模型的主要優(yōu)勢在于：

• 聯(lián)結(jié)操作
• 多對(duì)一和多對(duì)多關(guān)系更簡潔的表達(dá)

注意，簡單的多對(duì)多適合關(guān)系型模型，復(fù)雜的多對(duì)多更適合圖模型

我們以文檔型NoSQL為例，它和SQL對(duì)比的核心優(yōu)勢在于：

• 模式靈活性
• 局部性帶來的性能優(yōu)勢

（1）模式靈活性

「模式靈活性」的特點(diǎn)，往往被稱為「schema-fress模式」，但是我們并不能將它直接理解為“無模式”。

因?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ù)庫，對(duì)應(yīng)可以稱之為「寫時(shí)模式」（模式是顯示的，并且在寫入數(shù)據(jù)庫時(shí)被約束必須遵守）。

這兩者差異跟編程語言中的動(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)

「模式靈活性」帶來的損害則是需要應(yīng)用層做好結(jié)構(gòu)約束，并且保證對(duì)歷史數(shù)據(jù)的兼容性。
一般典型關(guān)系型場景，「模式靈活性」反而會(huì)導(dǎo)致難以維護(hù)。

（2）局部性的性能優(yōu)勢

注意注意，局部性優(yōu)勢僅適用于需要同時(shí)訪問文檔中大部分?jǐn)?shù)據(jù)的場景。

如果我們的查詢需要訪問整個(gè)文檔，那么存儲(chǔ)局部性具備顯著的性能優(yōu)勢。

此時(shí)，如果數(shù)據(jù)被劃分到了多個(gè)表中，則需要訪問多個(gè)表來檢索數(shù)據(jù)，會(huì)浪費(fèi)更多的磁盤IO并花費(fèi)更多的時(shí)間。

如果我們的訪問只需要文檔中的一小部分?jǐn)?shù)據(jù)，那么對(duì)于大型文檔來說就是一種浪費(fèi)。

3、數(shù)據(jù)模型分析原則

對(duì)于一份數(shù)據(jù)存儲(chǔ)，「數(shù)據(jù)模型」的建立， 就是考慮應(yīng)該通過 SQL 還是 NoSQL 進(jìn)行 數(shù)據(jù)組織 。

那么，結(jié)合前面對(duì)SQL和NoSQL的介紹與對(duì)比，我們總結(jié)了以下幾個(gè)維度，來具體考慮如何建立「數(shù)據(jù)模型」。

（1）數(shù)據(jù)對(duì)象關(guān)系

多對(duì)一或者多對(duì)多，一般考慮SQL。

一對(duì)多的關(guān)系，可以考慮SQL或者NoSQL。

（2）查詢性能

如果我們的查詢通常需要訪問整個(gè)文檔，那么存儲(chǔ)局部性具備顯著的性能優(yōu)勢，關(guān)系型的join性能較差，因此可以考慮NoSQL。

（業(yè)務(wù)上，一般會(huì)通過整體結(jié)果緩存，對(duì)關(guān)系型join查詢加速）

如果通常是局部數(shù)據(jù)對(duì)象、獨(dú)立實(shí)體查詢，考慮SQL。

（3）寫入吞吐量

如果需要超高的寫入吞吐量，考慮NoSQL。

（4）擴(kuò)展性

• 屬性擴(kuò)展：如果對(duì)象屬性不確定，且經(jīng)常變動(dòng)，NoSQL更靈活。
• 超大數(shù)據(jù)集擴(kuò)展：NoSQL通常更好。
• 單value大?。簡蝪alue如果過大，可能導(dǎo)致數(shù)據(jù)庫寫入失敗?？紤]拆分對(duì)象，或者分級(jí)存儲(chǔ)到對(duì)象存儲(chǔ)。一般單value不要超過100KB（壓縮后）。

（5）延遲選擇數(shù)據(jù)庫類型

數(shù)據(jù)模型分析主要是根據(jù)業(yè)務(wù)場景區(qū)分 關(guān)系型 還是 非關(guān)系型。

延遲考慮具體數(shù)據(jù)庫選型，用RDS還是Mongo還是其他數(shù)據(jù)庫，它們之間的功能性差異在逐漸變少。

具體選擇可以結(jié)合 研發(fā)人員熟悉程度、數(shù)據(jù)規(guī)模、其他非功能性需求 來判斷。

一些例子：

• Mongo 4.x支持事務(wù)
• MySQL 8.0支持JSON格式
• DB-engine上，mysql和mongo都從本身定位逐步擴(kuò)展為multi-model