MySQL它不香嗎，為什么還要NoSQL？
NoSQL 現在非常火，我看過的簡歷里面十個有九個都寫了熟悉 NoSQL，但是對于 NoSQL 背后的細節卻很少有人能講清楚，甚至連 NoSQL 里面的這個 No 是什么意思都很多人搞錯。
圖片來自 Pexels
這個 No 并不是 Not 的意思，而是 Not Only 的縮寫。不得不說這個縮寫實在是很坑爹，單從字面上應該沒人能猜出來它是這個意思。
而且即使解讀成 Not Only SQL，還是有點云里霧里，不是很能精準地 get 到它的點。
因為 SQL 的英文全寫是 Structured Query Language，也就是結構化查詢語言的意思。它可以認為是一門特殊的編程語言，但“不僅僅是 SQL”是啥意思?
的確令人費解，所以我們從字面意思上去理解是不行的，我們需要從實際應用場景去理解。
SQL 的應用場景是關系型數據庫，比如我們常用的 Oracle、MySQL，這些就是關系型數據庫。
我們理解數據庫的時候，往往會從表的結構入手去理解。數據庫當中存儲的是一張張的表，表呢是一行行數據組成的，而每一行數據都有固定的字段。
我想這點大家應該非常熟悉，即使沒有學過數據庫或者是像我這樣已經還給老師的，應該或多或少都有印象。
但是為什么它會被叫做關系型數據庫，而不是表結構數據庫呢?
因為在數據庫當中，關系要比表結構更重要。表結構只是一種形式，而數據庫當中核心的設計理念其實是關系。
這也是為什么我們學習數據庫的時候都需要從 ER 圖開始，而不是上來就講數據庫使用的方法，或者是 SQL 語言的細節。
如果你想不明白這句話的含義，也沒有關系，我們先放一放，最后再回到這個話題來。
問題來了，我們知道了常用的 SQL 數據庫是關系型數據庫，那么 NoSQL 代表的數據庫又是什么呢?
關于 NoSQL 概念我至少看到了兩種說法：
- 非關系型數據庫
- 文檔型數據庫
我個人在理解的時候覺得這兩種說法都不是非常完美，但相比之下顯然是第二種更好，因為第一種說法完全沒有給我們提供任何信息。
文檔型數據庫這里的文檔，并不是我們常規理解的一篇文檔的含義，而是指的數據存儲的結構和核心邏輯。
一個生動的例子
和大多數技術上的概念一樣，NoSQL 也比較晦澀，很難單純用語言將它描述清楚。
所以我決定舉一個生動活潑，大家都耳熟能詳的例子——就是萬能的 X 寶。
下面是一張 X 寶當中的商品詳情頁的圖(隨便選取，并非廣告，如有巧合，請付推廣費)：
這張圖大家應該都很熟悉了，在我們平時的網上購物的活動當中，一定見過了許多次。
它看起來有些眼花繚亂，我們把上面的內容做個抽象和精簡，畫成一張草圖，它大概是這樣的(的確有些草率)：
也就是說我們把一個商品詳情頁展示的內容大概分成了三個部分：
- 商品圖
- 商品的一些介紹說明
- 用戶的評論
各大電商公司商品詳情頁的設計大同小異，也許有些細節不太一樣，但是整體上的模塊都相差不大。
為了簡化問題，我們就假設商品詳情頁需要關聯圖片信息、文字說明和用戶評論這三張表。
其實這樣劃分不太科學，比如文字介紹和商品圖可以都存在商品詳情頁的表中。
比如除了這些信息之外，還有商品的售賣信息，比如庫存、價格、當前的優惠、活動等等，但是這些和我們最后的結論關系不大，可以簡單這么理解。
根據上面的劃分方式，我們應該根據 itemID 去查詢商品的圖片、文字以及評論信息，這從表面上看當然沒有問題。
但實際上這是有問題的，問題在于這些數據都不是一對一的關系，而是一對多的關系。
比如頭部展示的圖片往往不止一張，文字說明可能也不止一段，同樣用戶的評論可能也不止一條。這個問題怎么解決呢?
你可能會想出辦法來，這不難啊，我們在 img 和 text 以及 comment 的表里都加入 itemID 這個字段，在我們查詢的時候通過 itemID 進行關聯，不就 OK 了么?
這樣做當然可以，假設你是負責這個項目的程序員，你做出了這個更新，成功上線了之后，產品又給你提了一個新的需求。
她說我想要在文字介紹和用戶評論里面都展示圖片，雖然系統一開始不是這么設計的，但是我不管，我就是需要，立刻馬上。
你翻了好一會白眼，冷靜了許久，想了想，終于想到了兩種方案：
- 第一個方案是在目前的圖片表上加上字段，用來判斷圖片的用途是詳情頁展示還是評論頁展示，把之后要加的文本介紹和評論頁中的圖片依然存在這張表上。
- 第二個方案是重新建新的表，專表專用，專門負責存放評論頁和說明頁的圖片。
第一個方案的好處是我們不用建新的表，避免了表的冗余，如果每一個需求都需要建新的表，顯然對于后續的維護是一個巨大的負擔。
但是它的缺點是我們需要批量修正之前所有的數據，因為之前的數據里沒有來源這個字段。
當然你也可以不加這個字段，直接用 ID 區分，但是這是不符合規范的，而且必然會留下安全隱患。
第二個方案的優點是操作簡單，不需要變更之前的數據，安全風險較小，但問題是需要占用新的資源，利用率低。
因為有些詳情頁的圖片和頂部的圖片是可以共用的，這樣分開存儲的話就需要存儲多份。
這兩個方案各有優缺點，似乎都還不錯，但坑爹的是它們都有一個共同的缺點，就是都會增加目前系統和查詢的復雜度。
一個是要增加查詢時候傳入的字段，一個是要發起額外的查詢，不論選擇哪一個，都會讓系統越來越復雜。
到了后來，一個用戶請求傳來，會帶動數十個聯動請求，才能拼裝出完整的數據。
現在最新版本的 X 寶的詳情頁商品介紹的部分一律用圖片展示，沒有了文字，也許背后就是受到這個問題的驅動。
我們回顧一下這個例子，為什么我們的查詢會很復雜，其實就和數據庫的核心理念有關。
關系型數據庫存儲的數據是關系，在這個問題當中，我們一個詳情頁的查詢，需要查詢商品和圖片的關系，商品和說明的關系，商品和評論的關系，評論和圖片的關系等等。
也就是說我們最終看到的頁面，其實是這一系列關系擰在一起的結果，每一次查詢的背后都是一個關系分解再合并的過程，因此會非常復雜。
文檔型數據庫
我們剛才看了關系型數據庫在電商場景下的問題，我們再來看下文檔型數據庫在同樣場景下的表現。
和關系型數據庫不同，文檔型數據庫存儲的核心是文檔。當然這里的文檔指的不是我們通常意義上的文檔，而是 Json 或者是 XML 格式的數據。在目前的 NoSQL 數據庫當中，Json 類型的數據更加常用一些。
我們還用剛才詳情頁的例子來看下在 NoSQL 數據庫當中，這份數據是如何存儲的：
- {
- "itemID": 123,
- "itemName": "iPad Pro",
- "topImgs": ["imgs1.path", "imgs2.path"],
- "desc": [{"text": "iPad Pro", "img": ""}, {"text": "2020 new version", "img": "imgs1.path"}],
- "comments": [{"userName": "chengzhi", "comment": "good product", "imgs": ["imgs3.path", "img4.path"]}]
- }
你看，在文檔型數據庫當中剛才復雜的、需要經過多次查詢經過一系列處理才可以擰到一起的數據，我們通過 itemID 一次查詢就可以獲取到了。
單純從使用上來說，它比關系型數據庫要方便了許多，但是它也并不是沒有缺點的。
這其中一個很大的問題是，我們把所有數據都直接存儲在了文檔當中，這一方面造成了數據的冗余，另一方面也限制了拓展性。
比如說，同一個商家下類似的商品不能共享圖片，而必須存儲多份，這造成了空間的浪費。
再比如，假設我們希望支持用戶修改之前過去的評論會非常麻煩，因為我們必須要找到所有存儲了用戶評論的文檔進行修改(假設在其他場景下也用到了用戶評論)，這往往是跨系統并且非常不方便的。
這個問題也并不是不可解的，比如我們可以把文檔當中存儲的具體數據換成一個 ID。
比如 Comment 當中不再存儲具體的圖片和評論信息，而存儲一個評論的 ID，在使用的時候再去關聯。
由于文檔型數據庫由于架構的原因，對于關聯的支持并不好，往往需要我們手動根據 ID 再去查詢來模擬連接，這也會帶來額外的開銷。
另外一個小瑕疵是在文檔型數據庫當中我們訪問數據的路徑變長了，舉個例子，加入我們要獲取商品評論當中的第二條中的第一張圖片。
我們需要寫成 item['comments'][1]['imgs'][0]，而在關系型數據庫當中，由于圖片是通過關系直接查詢得到的，因此要方便一些。
除了這些之外，NoSQL 數據庫發展的年限和 MySQL 這些較成熟的關系型數據庫相比要短得多，因此支持的特性相對比較少。
總結
通過一個例子，我們很生動地對比了關系型數據庫和 NoSQL 數據庫之間的差別。
為什么我們在學習數據庫的時候需要先從 ER 圖開始，而不是直接學習數據庫的原理和它的使用方法呢?我想理解了上面的例子之后，再來看這個問題應該會簡單許多。
因為關系型數據庫的核心邏輯就是存儲關系，使用規范、各種技巧和特性，本質上都是圍繞這個核心展開的。
如果我們沒有 Get 到這一層就來使用數據庫很容易走偏，很多匪夷所思的操作就是這么來的。
比如有人在數據庫當中存儲前端頁面的代碼，比如把 ID 拼接成一個字符串來實現存儲多個值等等。
這也說明了經典教材上的內容沒有廢話，每一個章節都有它預期的作用，因此當我們覺得某些內容沒有用的時候，可能并不是教材錯了，只是我們沒有理解到位。
作者：梁唐
編輯：陶家龍
出處：轉載自微信公眾號 TechFlow(ID：techflow2019)
