【譯】MongoDB Shema 設計的6條經驗法則 3

6 Rules of Thumb for MongoDB Schema Design: Part 3mongodb

做者 William Zola, Lead Technical Support Engineer at MongoDB數據庫

這是在MongoDB 中對 1對N 關係建模的最後一站。在第一篇博文中,我談到了三個對 1對N 建模的基本方法。上一篇中,談到了這些基本方法的一些拓展:雙向引用反範式化數組

反範式化能能讓你避免那些 以高成本且複雜的更新爲代價的 應用級別的聯接。若是那些字段的讀取比更新更加頻繁,那對這一兩個這樣的字段作反範式化是有意義的。服務器

若是你忘記了,參看 第一部分第二部分post

看看這些選擇

回顧一下:優化

  • 你能夠 內嵌, 從 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 中結構化你的數據,從而令其輕鬆的適應變化,最大程度支持在你應用程序的進行你須要的查詢和更新。

相關文章
相關標籤/搜索