做一個新業務，我該選擇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大小：單value如果過大，可能導致數據庫寫入失敗?？紤]拆分對象，或者分級存儲到對象存儲。一般單value不要超過100KB（壓縮后）。
（5）延遲選擇數據庫類型
數據模型分析主要是根據業務場景區分 關系型 還是 非關系型。
延遲考慮具體數據庫選型，用RDS還是Mongo還是其他數據庫，它們之間的功能性差異在逐漸變少。
具體選擇可以結合 研發人員熟悉程度、數據規模、其他非功能性需求 來判斷。
一些例子：
- Mongo 4.x支持事務
- MySQL 8.0支持JSON格式
- DB-engine上，mysql和mongo都從本身定位逐步擴展為multi-model
