6 Rules of Thumb for MongoDB Schema Design: Part 3mongodb
做者 William Zola, Lead Technical Support Engineer at MongoDB數據庫
這是在MongoDB 中對 1對N
關係建模的最後一站。在第一篇博文中,我談到了三個對 1對N
建模的基本方法。上一篇中,談到了這些基本方法的一些拓展:雙向引用 和 反範式化。數組
反範式化能能讓你避免那些 以高成本且複雜的更新爲代價的 應用級別的聯接。若是那些字段的讀取比更新更加頻繁,那對這一兩個這樣的字段作反範式化是有意義的。服務器
回顧一下:優化
你能夠 內嵌, 從 1端
引用,或者從 N端
引用, 又或者結合這些技巧中的某兩種。設計
你能夠任意反範式化任意多個字段到 1端
或者 N端
code
特別是 反範式化,它給了你不少選擇: 若是有關係中 8個選項能夠反範式化,就有 28 種不一樣的方式去作反範式化(包括徹底不作反範式化)。在將三種不一樣的引用方法組合到一塊兒,你能夠有超過3000種方法來創建關係模型。對象
你猜會怎麼樣?你陷入了 「 選擇悖論 」 —— 由於你有這麼多潛在的方式來創建 1對N
關係模型,如今如何建模的時候將更加困難。blog
這裏是經驗法則能夠指引你經過這無數的選擇。
一,使用 內嵌,除非有一個明確的緣由。
二,須要訪問對象自己,能夠是一個明確的不使用內嵌的理由。
三, 數組不該該無限的增加。若是 不少
一端種 有超過幾百個文檔,那就不要使用內嵌。若是 不少
一段中有超過幾千個文檔,那就不要使用 ObjectID 引用數組。高基數數組
是一個明顯的不使用內嵌的理由。
四,不要懼怕應用程序級別的聯接:若是正確索引並使用投影操做(見 [第二部分](at the expense of having more complex and expensive update)),那麼 應用程序級別聯接 並不會比 關係數據庫中服務器端聯接 的成本高。
五,考慮 非範式化 的 讀/寫 比率。一個常常讀取且不多更新的字段是很好的反範式化的選項。若是你範
六,MongoDB 中,如何對你的數據建模大致上取決於 你的特定應用程序中數據的訪問模式。你能夠過調整你的數據的結構,從而使之匹配 你的應用程序的查詢和更新數據的方式。
在 MongoDB 中建模 1對N
關係是,你有多種不一樣的選擇,所以你必須仔細考慮你的數據的結構。
你須要考慮的主要準則有:
這個關係的基數是什麼:是 1對多
, 1對不少
,仍是 一對很是多
?
你是否是須要單獨訪問 N端
對象,仍是隻是須要在父對象的上下文中進行訪問?
這個特定字段的讀取與更新的比率是多少?
構建數據的的主要選擇有:
對與 1對少
, 你可使用一組內嵌式的文檔。
對於 1對不少
或者當 N端
必須單獨使用的狀況中,你應該使用 引用數組
的方式。你也能夠 用在N端
使用 父引用
的方法 若是這樣作能夠優化的你數據訪問模式。
對於 1對很是
, 你應當使用在存放 N端
的文檔中 使用 父引用
。
一旦你決定了數據的總體結構,那你就能夠選擇在不一樣文檔間進行反範式化,經過 將 1端
的數據 範式化到 N端
或者 從 N端
反範式化 到 1端
。
這些操做只合適對常常讀取,讀取比更新頻繁,而且對一致性沒有強烈的要求的字段,由於更新 被反範式化的值很慢,成本較高 而且 不是原子性的。
綜上結果,MongoDB 能讓你讓你設計數據看來匹配你的應用程序的需求。你能夠在 MongoDB 中結構化你的數據,從而令其輕鬆的適應變化,最大程度支持在你應用程序的進行你須要的查詢和更新。