SQL還是NoSQL？架構(gòu)師必備選型技能-魔扣目錄

SQL還是NoSQL？架構(gòu)師必備選型技能

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

很多時候我們都會有這樣的疑問。

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

這時候，最好從「數(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），其中每個關(guān)系都是元組（tuples)的無序集合（在SQL中稱為行）。

那什么是NoSQL？

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

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

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

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

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

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

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

因為我們在讀取數(shù)據(jù)時，往往存在某種數(shù)據(jù)結(jié)構(gòu)的隱式轉(zhuǎn)換，所以我們稱之為「讀時模式」更準確（數(shù)據(jù)結(jié)構(gòu)是隱式的，只有讀取時才解釋）。

而傳統(tǒng)關(guān)系型數(shù)據(jù)庫，對應(yīng)可以稱之為「寫時模式」（模式是顯示的，并且在寫入數(shù)據(jù)庫時被約束必須遵守）。

這兩者差異跟編程語言中的動態(tài)檢查（運行時）和靜態(tài)檢查（編譯時）比較類似。

「模式靈活性」的優(yōu)點在于：

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

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

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

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

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

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

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

多對一或者多對多，一般考慮SQL。

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

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

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

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

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

屬性擴展：如果對象屬性不確定，且經(jīng)常變動，NoSQL更靈活。
超大數(shù)據(jù)集擴展：NoSQL通常更好。
單value大小：單value如果過大，可能導(dǎo)致數(shù)據(jù)庫寫入失敗。考慮拆分對象，或者分級存儲到對象存儲。一般單value不要超過100KB（壓縮后）。