做一個新業務，我該選擇SQL還是NoSQL?

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

如果這時候直接去看MySQL、Mongo、HBase、Redis等數據庫的用法、特點、區別，其實有點太著急了。

這時候，最好從「數據模型」開始討論。

1、SQL vs NoSQL

現在最著名的數據模型應該是SQL，它基于Edgar Codd在1970年提出的關系模型：

數據被組織成關系（relations），在SQL中稱為表（table），其中每個關系都是元組（tuples)的無序集合（在SQL中稱為行）。

那什么是NoSQL？

現在很多非關系型數據庫會被稱為NoSQL，其含義往往被解釋 “Not only SQL”。

采用NoSQL的驅動因素在于：

• 數據量。 比SQL更好的擴展性需求，包括支持超大數據集或超高寫入吞吐量
• 查詢方式。 關系模型不能很好支持的一些特定查詢操作
• 動態擴展。 對關系模式的一些限制表示沮喪，需要更加具有動態和表達力的數據模型

2、數據模型的差異

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

關系型模型的主要優勢在于：

• 聯結操作
• 多對一和多對多關系更簡潔的表達

注意，簡單的多對多適合關系型模型，復雜的多對多更適合圖模型

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

• 模式靈活性
• 局部性帶來的性能優勢

（1）模式靈活性

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

因為我們在讀取數據時，往往存在某種數據結構的隱式轉換，所以我們稱之為「讀時模式」更準確（數據結構是隱式的，只有讀取時才解釋）。

而傳統關系型數據庫，對應可以稱之為「寫時模式」（模式是顯示的，并且在寫入數據庫時被約束必須遵守）。

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

「模式靈活性」的優點在于：

• 避免了大表變更時的停機或者耗時
• 支持包含多種類似數據結構
• 可以隨時改變數據結構

「模式靈活性」帶來的損害則是需要應用層做好結構約束，并且保證對歷史數據的兼容性。
一般典型關系型場景，「模式靈活性」反而會導致難以維護。

（2）局部性的性能優勢

注意注意，局部性優勢僅適用于需要同時訪問文檔中大部分數據的場景。

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

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

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

3、數據模型分析原則

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

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

（1）數據對象關系

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

一對多的關系，可以考慮SQL或者NoSQL。

（2）查詢性能

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

（業務上，一般會通過整體結果緩存，對關系型join查詢加速）

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

（3）寫入吞吐量

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

（4）擴展性

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

（5）延遲選擇數據庫類型

數據模型分析主要是根據業務場景區分 關系型 還是 非關系型。

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

具體選擇可以結合 研發人員熟悉程度、數據規模、其他非功能性需求 來判斷。

一些例子：

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