NoSql數據庫 設計上面的一些心得

NoSql數據庫這個概念聽聞許久了，也陸續看到不少公司和產品都在使用，優缺點彷佛都被分析的清清楚楚。但我內心一直存有一個疑惑，它的出現到底是爲了解決什麼問題？

用戶信息表，書籍信息表，用戶爲書籍打分信息表，評論表。

如今假想要作一個顯示評論內容的頁面，上面會有用戶信息和相關書籍的信息，想必你們腦子裏已經出現各類select和join了吧。

若是用NoSql仍是一樣的設計的話，那你會驚喜的發現NoSql數據庫的性能簡直差到爆。性子火爆的估計當場就要掀桌。

什麼破爛數據庫，不是號稱性能一流的嗎！

好吧，性能問題也就不說了，居然連事務都不支持！？那我同時插入四張表的數據該怎麼保持一致？開玩笑的吧！

 

NoSql數據庫此時默默的淚流滿面，冤枉啊……你別說，還真是冤枉它了。

先從最基本的設計元素提及，幾乎全部的NoSql數據庫都沒有表（table）的概念，取而代之的是文檔（document）。文檔是個什麼東西？Mongodb的解釋，文檔是一個使用JSON格式以key-value方式存儲數據的結構，好比：

{ "item": "pencil", "qty": 500, "type": "no.2" }

看起來和表沒什麼不一樣嘛？咳咳，JSON是支持嵌套結構的，好比能夠把書籍信息和用戶打分的信息存到一塊兒：

{ 
  "id": "123zxcrweq2", 
  "title": "雪中悍刀行", 
  "author": "烽火戲諸侯", 
  "scores": [ 
    { 
      "userid": "454zxcfwer1", 
      "nickname": "Allen", 
      "score": 3, 
    }, 
    { 
      "userid": "678zxkiou1", 
      "nickname": "Judy", 
      "score": 4, 
    } 
  ], 
}

一堆document存儲到一塊兒就叫作collection，而同一個collection裏面的document能夠不同。注意，這裏也是重點概念。若是切換到關係型數據庫的話，至關於一張表裏每一行數據的列均可以不同。這不是亂套了嗎？用很差確實會亂套的。

概念說完了，來看看面對下面這種產品要求的時候應該怎麼辦。產品經理說了，要在書籍信息頁面看到全部評論，評論人的信息和打的分也要出現。

若是是關係數據庫，獲取數據的思路是這樣的：

1. 根據書籍Id取到書籍信息。

2. 根據書籍Id取到全部評論信息。

3. 根據評論信息中的用戶Id取到相關用戶的信息。

4. 根據書籍Id和用戶Id取到打分信息。

那在NoSql數據庫中若是咱們用以下結構存儲數據的話……

{ 
  "id": "123zxcrweq2", 
  "title": "雪中悍刀行", 
  "author": "烽火戲諸侯", 
  "comments": [ 
    { 
      "author": { 
        "id": "454zxcfwer1", 
        "nickname": "Allen", 
        "avatarurl": "頭像1.png", 
      }, 
      "score": 3, 
      "title": "書評1", 
      "content": "書評內容1", 
    }, 
    { 
      "author": { 
        "id": "454zxcfwer1", 
        "nickname": "Judy", 
        "avatarurl": "頭像2.png", 
      }, 
      "score": 4, 
      "title": "書評2", 
      "content": "書評內容2" 
    } 
  ], 
}

彷佛只要根據書籍Id查詢一次就能獲得結果了吧……明白爲何說NoSql數據庫效率高了嗎？一邊是從四個集合中查找數據，一邊是從一個集合中查找數據，這運行效率肉眼就能看出來差異了吧。

因此到這裏我獲得了一條設計心得，儘量把一次展現所需的必要數據都存儲到一塊兒。這是典型的空間換時間。所幸如今的科技條件下空間的價格很是低廉，因此很划算。

根據這個設計結構，彷佛也不須要事務的支持了，用戶爲一本書籍打分只須要在一個document裏面添加數據就夠了。

好，document特性的用處明白了，如今就來研究下NoSql數據庫另一條原則的用途了，還記得是什麼嗎？同一個collection裏面的document能夠不同。

仍是從實際應用中來看，某日，產品經理說，書籍詳細信息頁面上還要顯示書評的建立時間。

若是使用關係數據庫該怎麼辦？

1. 建立一個爲Review表增長」creationtime「列的sql腳本。

2. 到數據庫中運行。

3. 修改相關代碼和存儲過程。

NoSql呢？

1. 在Comment結構實體中增長CreationTime，增長賦值代碼。

沒了，不須要去修改歷史數據，由於？同一個collection裏面的document能夠不同。那若是取到歷史數據怎麼辦？Comment的CreationTime會被置爲空。挺合理的，也不會產生什麼危害。

大 家都知道，互聯網產品的更新速度是很是快的，常常根據用戶反饋和市場狀況調整產品形態，而數據結構也會常常發生變化。爲了適應這種環境，如何處理歷史數據 就成了老大難。還記得當年看到一個DBA在設計表的時候會留出幾個字段叫作」Reserved1，Reserved2……「，感受好無厘頭，浪費空間，後 來隨着產品功能的增長才明白這實際上是經驗豐富的表現。若是用NoSql就不用這麼糾結了。

總結一下，就我淺薄的使用經驗來看，NoSql的優勢是：1. 在精心的設計下查詢性能巨好。2. 數據結構彈性十足，特別適合快速發展中的產品。

另外須要提醒一下，Mongodb不支持事務，因此務必在設計的時候考慮到這一點。核心業務數據儘量經過結構設計作到數據插入的一致性。若是實在沒法達成，請當即轉回去用關係數據庫，不然或早或晚你必定會後悔的。

本文連接：http://www.cnblogs.com/AllenDang/p/3507821.html#!comments