NoSql數(shù)據(jù)庫(kù)使用半年后在設(shè)計(jì)上面的一些心得

wang290

NoSql數(shù)據(jù)庫(kù)這個(gè)概念聽聞許久了，也陸續(xù)看到很多公司和產(chǎn)品都在使用，優(yōu)缺點(diǎn)似乎都被分析的清清楚楚。但我心里一直存有一個(gè)疑惑，它的出現(xiàn)究竟是為了解決什么問(wèn)題？
這個(gè)疑惑非常大，為此我看了很多分析文章，但卻總感覺(jué)是隔靴搔癢。為了一探究竟，半年前我決定用Mongodb這個(gè)著名的NoSql數(shù)據(jù)庫(kù)做個(gè)產(chǎn)品試試。只有在真實(shí)的使用環(huán)境中才能得到最貼切的感受。
一晃眼，半年過(guò)去了，現(xiàn)在我能用親身的體會(huì)來(lái)談?wù)凬oSql數(shù)據(jù)庫(kù)存在的理由和試圖解決的問(wèn)題了。就像所有的哲學(xué)思考都來(lái)源于對(duì)日�；顒�(dòng)的觀察一樣，我們也從最基本的東西說(shuō)起吧。
來(lái)看這樣一個(gè)業(yè)務(wù)要求，用戶可以為一本書打分，并且寫評(píng)論。熟悉數(shù)據(jù)庫(kù)結(jié)構(gòu)設(shè)計(jì)的人看到這一句話腦子里應(yīng)該瞬間就會(huì)出現(xiàn)下面這樣的表結(jié)構(gòu)（我這里就不太講究了，大家意會(huì)即可）：

用戶信息表，書籍信息表，用戶為書籍打分信息表，評(píng)論表。
現(xiàn)在假想要做一個(gè)顯示評(píng)論內(nèi)容的頁(yè)面，上面會(huì)有用戶信息和相關(guān)書籍的信息，想必大家腦子里已經(jīng)出現(xiàn)各種select和join了吧。
如果用NoSql還是同樣的設(shè)計(jì)的話，那你會(huì)驚喜的發(fā)現(xiàn)NoSql數(shù)據(jù)庫(kù)的性能簡(jiǎn)直差到爆。性子火爆的估計(jì)當(dāng)場(chǎng)就要掀桌。
什么破爛數(shù)據(jù)庫(kù)，不是號(hào)稱性能一流的嗎！
好吧，性能問(wèn)題也就不說(shuō)了，竟然連事務(wù)都不支持�。磕俏彝瑫r(shí)插入四張表的數(shù)據(jù)該怎么保持一致？開玩笑的吧！

NoSql數(shù)據(jù)庫(kù)此時(shí)默默的淚流滿面，冤枉啊……你別說(shuō)，還真是冤枉它了。
先從最基本的設(shè)計(jì)元素說(shuō)起，幾乎所有的NoSql數(shù)據(jù)庫(kù)都沒(méi)有表（table）的概念，取而代之的是文檔（document）。文檔是個(gè)什么東西？Mongodb的解釋，文檔是一個(gè)使用JSON格式以key-value方式存儲(chǔ)數(shù)據(jù)的結(jié)構(gòu)，比如：

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

看起來(lái)和表沒(méi)什么不同嘛？咳咳，JSON是支持嵌套結(jié)構(gòu)的，比如可以把書籍信息和用戶打分的信息存到一起：

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

一堆document存儲(chǔ)到一起就叫做collection，而同一個(gè)collection里面的document可以不一樣。注意，這里也是重點(diǎn)概念。如果切換到關(guān)系型數(shù)據(jù)庫(kù)的話，相當(dāng)于一張表里每一行數(shù)據(jù)的列都可以不一樣。這不是亂套了嗎？用不好確實(shí)會(huì)亂套的。
概念說(shuō)完了，來(lái)看看面對(duì)下面這種產(chǎn)品要求的時(shí)候應(yīng)該怎么辦。產(chǎn)品經(jīng)理說(shuō)了，要在書籍信息頁(yè)面看到所有評(píng)論，評(píng)論人的信息和打的分也要出現(xiàn)。

如果是關(guān)系數(shù)據(jù)庫(kù)，獲取數(shù)據(jù)的思路是這樣的：
1. 根據(jù)書籍Id取到書籍信息。
2. 根據(jù)書籍Id取到所有評(píng)論信息。
3. 根據(jù)評(píng)論信息中的用戶Id取到相關(guān)用戶的信息。
4. 根據(jù)書籍Id和用戶Id取到打分信息。
那在NoSql數(shù)據(jù)庫(kù)中如果我們用如下結(jié)構(gòu)存儲(chǔ)數(shù)據(jù)的話……

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

似乎只要根據(jù)書籍Id查詢一次就能得到結(jié)果了吧……明白為什么說(shuō)NoSql數(shù)據(jù)庫(kù)效率高了嗎？一邊是從四個(gè)集合中查找數(shù)據(jù)，一邊是從一個(gè)集合中查找數(shù)據(jù)，這運(yùn)行效率肉眼就能看出來(lái)差別了吧。
所以到這里我得到了一條設(shè)計(jì)心得，盡可能把一次展示所需的必要數(shù)據(jù)都存儲(chǔ)到一起。這是典型的空間換時(shí)間。所幸現(xiàn)在的科技條件下空間的價(jià)格非常低廉，所以很劃算。
根據(jù)這個(gè)設(shè)計(jì)結(jié)構(gòu)，似乎也不需要事務(wù)的支持了，用戶為一本書籍打分只需要在一個(gè)document里面添加數(shù)據(jù)就夠了。
好，document特性的用處明白了，現(xiàn)在就來(lái)研究下NoSql數(shù)據(jù)庫(kù)另外一條原則的用途了，還記得是什么嗎？同一個(gè)collection里面的document可以不一樣。
還是從實(shí)際應(yīng)用中來(lái)看，某日，產(chǎn)品經(jīng)理說(shuō)，書籍詳細(xì)信息頁(yè)面上還要顯示書評(píng)的創(chuàng)建時(shí)間。
如果使用關(guān)系數(shù)據(jù)庫(kù)該怎么辦？
1. 創(chuàng)建一個(gè)為Review表增加”creationtime“列的sql腳本。
2. 到數(shù)據(jù)庫(kù)中運(yùn)行。
3. 修改相關(guān)代碼和存儲(chǔ)過(guò)程。
NoSql呢？
1. 在Comment結(jié)構(gòu)實(shí)體中增加CreationTime，增加賦值代碼。
沒(méi)了，不需要去修改歷史數(shù)據(jù)，因?yàn)椋?strong>同一個(gè)collection里面的document可以不一樣。那如果取到歷史數(shù)據(jù)怎么辦？Comment的CreationTime會(huì)被置為空。挺合理的，也不會(huì)產(chǎn)生什么危害。
大家都知道，互聯(lián)網(wǎng)產(chǎn)品的更新速度是非�？斓模�經(jīng)常根據(jù)用戶反饋和市場(chǎng)情況調(diào)整產(chǎn)品形態(tài)，而數(shù)據(jù)結(jié)構(gòu)也會(huì)經(jīng)常發(fā)生變化。為了適應(yīng)這種環(huán)境，如何處理歷史數(shù)據(jù)就成了老大難。還記得當(dāng)年看到一個(gè)DBA在設(shè)計(jì)表的時(shí)候會(huì)留出幾個(gè)字段叫做”Reserved1，Reserved2……“，感覺(jué)好無(wú)厘頭，浪費(fèi)空間，后來(lái)隨著產(chǎn)品功能的增加才明白這其實(shí)是經(jīng)驗(yàn)豐富的表現(xiàn)。如果用NoSql就不用這么糾結(jié)了。
總結(jié)一下，就我淺薄的使用經(jīng)驗(yàn)來(lái)看，NoSql的優(yōu)點(diǎn)是：1. 在精心的設(shè)計(jì)下查詢性能巨好。2. 數(shù)據(jù)結(jié)構(gòu)彈性十足，特別適合快速發(fā)展中的產(chǎn)品。
另外需要提醒一下，Mongodb不支持事務(wù)，所以務(wù)必在設(shè)計(jì)的時(shí)候考慮到這一點(diǎn)。核心業(yè)務(wù)數(shù)據(jù)盡可能通過(guò)結(jié)構(gòu)設(shè)計(jì)做到數(shù)據(jù)插入的一致性。如果實(shí)在無(wú)法達(dá)成，請(qǐng)立即轉(zhuǎn)回去用關(guān)系數(shù)據(jù)庫(kù)，否則或早或晚你一定會(huì)后悔的。

346279055

學(xué)習(xí)了，頂一下

wang290

346279055 發(fā)表于 2015-01-28 14:51
學(xué)習(xí)了，頂一下

兄弟可以給我積分啊，評(píng)分

renxiao2003

謝謝樓主分享。