為什么MYSQL更新的幅度越來越大?是因為原來的三NF設(shè)計完全不夠用了 又沒有大神提出新的標(biāo)準(zhǔn) 雖然暫時還是最熱門的數(shù)據(jù)庫 但是挑戰(zhàn)者已經(jīng)在敲門了 說說這問題 順便整理下思路 以觀后效

以一個簡單需求舉例 用戶發(fā)表文章?其它用戶可以點(diǎn)贊 前端頁面需要顯示哪些用戶點(diǎn)贊了此文章 本用戶點(diǎn)贊了哪些文章

開始數(shù)據(jù)庫設(shè)計?

1.用戶表 用戶名 密碼 UID

2. 文章表 UID 文章標(biāo)題 內(nèi)容 tid

3.點(diǎn)贊表 UID TID

通過聯(lián)表查詢?以TID為條件索引可查詢到點(diǎn)贊了本文章的用戶列表

以UID為條件索引可查詢到某用戶點(diǎn)贊了哪些文章?

需求搞定?如果數(shù)據(jù)量不大的話一點(diǎn)問題沒有 但是如果是新浪微博呢 問題就大大的來了

? ? ? ?首先從背景上來說 之前所有的系統(tǒng)基本都是以公司工廠為單位運(yùn)行的局域網(wǎng)環(huán)境中 90%以上了不起就三~三百臺電腦的規(guī)模 簡單說就是業(yè)務(wù)流程復(fù)雜 數(shù)據(jù)規(guī)模不大 并發(fā)性基本不用考慮 在此基礎(chǔ)上總結(jié)的數(shù)據(jù)庫設(shè)計規(guī)范 中心思想是一份數(shù)據(jù)只保存在一個地方 只在一個地方更新 表與表之間通過ID外鍵互聯(lián)即可 只要是接觸過由EXCEL建立的系統(tǒng)的人 都能理解這種設(shè)計的優(yōu)越性 徹底的解決了數(shù)據(jù)不一致的困擾。在此基礎(chǔ)上發(fā)展了外鍵 觸發(fā)器 存儲過程 索引等概念 將數(shù)據(jù)庫作為數(shù)據(jù)倉庫集中處理數(shù)據(jù)的作用發(fā)揮到了極致。

? ? ? 但是現(xiàn)在使用的環(huán)境已經(jīng)完全變了 隨便一個最簡單的帳本應(yīng)用都是面向互聯(lián)網(wǎng)公開的 并發(fā)量 數(shù)據(jù)量都不可同日而語 各種新的理論 工具層出不窮 ?分庫分表?Memcache??redis 還有MongoDB 都是為了解決一個問題 MYSQL不夠用了 性能不夠造成業(yè)務(wù)崩潰的例子每天都在發(fā)生 MYSQL有各種問題 我覺得其它問題什么修改表結(jié)構(gòu)慢之類那都不算事 最主要還是這個中心思想一份數(shù)據(jù)只保存在一個地方?到底還合不合時宜

? ? ?同樣以這個需求舉例 如果按照文檔數(shù)據(jù)庫的設(shè)計思路?例如MONGO 可能我會以文章建一個表 包含TID 標(biāo)題 內(nèi)容和一個點(diǎn)贊用戶列表

再以用戶建一個表 包含UID?用戶名 密碼和一個點(diǎn)贊文章的列表 這樣無需聯(lián)表 只需要一個主鍵查詢?就能獲取到需要的數(shù)據(jù) 但是寫入的時候比如某用戶點(diǎn)贊了某文章 就要在二個地方寫數(shù)據(jù) 有可能帶來數(shù)據(jù)不一致的問題 當(dāng)然使用一些手段可以避免或修復(fù) 但是這就引入了復(fù)雜度 有沒有必要？這里我覺得是有必要 大多數(shù)的系統(tǒng)讀比寫多 也比寫復(fù)雜 這樣改寫之后 應(yīng)該可以幾乎完全的避免MYSQL死鎖的問題 但是如果業(yè)務(wù)場景太復(fù)雜 可能會需要維護(hù)不止二份的數(shù)據(jù)

? ? 來點(diǎn)對比

? ??1.MongoDB在阿里云比MYSQL貴2倍不止?

? ? 2.?MongoDB與MYSQL語法完全不同 有不少坑要踩

? ? 基于以上在簡單系統(tǒng)上試用過一段時間的?MongoDB之后 還是沒敢切換 用回MYSQL了 但是這次更新支持JSON之后我就在想既然MYSQL成本明顯比MongoDB低 穩(wěn)定性成熟度又比MongoDB好 那能不能把文檔數(shù)據(jù)庫的設(shè)計思路用來用MYSQL來實(shí)現(xiàn)呢？？？或許是個路子。

? ? 總結(jié)一下 個人一點(diǎn)小建議：

? ?.應(yīng)用層可以無限制的擴(kuò)張 CPU 帶寬 內(nèi)存都不是個事（除了￥￥。。。）?所以系統(tǒng)瓶頸一般在數(shù)據(jù)庫?所以盡量不要使用外鍵 觸發(fā)器 存儲過程等任何需要占用數(shù)據(jù)庫鎖甚至是數(shù)據(jù)庫服務(wù)器CPU的東西 一切計算往前提 在應(yīng)用層組裝計算?甚至可以提到用戶端瀏覽器去

? ?.應(yīng)該可以改變一下傳統(tǒng)3NF的設(shè)計思路 采用文檔數(shù)據(jù)庫的思路 中心思想主要是按需求組織數(shù)據(jù)和保存數(shù)據(jù) 好處是可以一次獲取所有相關(guān)數(shù)據(jù) 至于寫數(shù)據(jù)的多處修改問題 正好可以使用MYSQL的事務(wù)機(jī)制 通過前面說的日志隊列的方式實(shí)現(xiàn)快速返回 隊列寫入

? ?.盡信書不如無書 透過現(xiàn)象看本質(zhì) 在現(xiàn)在這個SSD成本大降 存儲成本越來越低 數(shù)據(jù)卻越來越大 并發(fā)數(shù)越來越高的時代 我覺得犧牲點(diǎn)存儲空間 和寫入速度 換來瓶頸中心數(shù)據(jù)庫的可擴(kuò)展性 和讀取速度的提升 無論怎么算都是劃算的也必將會成為主流設(shè)計思路 相信一段時間之后必然有行業(yè)大牛出來推出新的設(shè)計標(biāo)準(zhǔn) MYSQL又將大行其道?

? ?.再次印證了?巨頭沒那么容易被打倒 屌絲永遠(yuǎn)還是屌絲。。。。殘念。。。

??回頭找個小應(yīng)用?實(shí)踐下看