MongoDB：資料模型介紹

標籤：映射   ext   gridfs   term   span   多個   請求   集合   歸一化   

在MongoDB的資料有靈活的模式。不像SQL資料庫，（SQL資料庫）要求你必須在插入資料之前決定和聲明一個表的模式。MongoDB的集合不強制文檔的結構。這個靈活性有利於文檔到實體或對象的映射。

每一個文檔能夠匹配所要表示實體的資料欄位，即使資料的變化非常顯著。但在實際操作中，一個集合的文檔共用一個相似的結構。

資料模型的關鍵挑戰在於平衡應用的須要，資料庫引擎的效能和資料存模數式。當設計資料模型時，要考慮資料在應用裡的使用方式（如。查詢、更新和處理資料），以及資料本身的內在結構。

文檔結構

在為MongoDB應用設計資料模型時的關鍵是環繞文檔的結構和應用時怎樣表示資料間的聯絡。有兩個工具來同意應用來表示這些關係：引用和嵌入文檔( references and embedded documents)。

• 引用

引用通過包含串連或一個文檔到還有一個文檔間的引用儲存著資料間的關係。應用可以解析這些引用來訪問到相關資料。

廣義上說，這些都是歸一化的資料模型(normalized data models).

的資料模型使用引用來聯絡文檔。

contract文檔和access文檔都保護著user文檔的引用。

以下介紹歸一化資料模型在使用引用的優缺點：

歸一化模型使用引用描寫敘述文檔間的關係。一般地。使用歸一化模型的情況有。

1. 當嵌入會導致資料反覆且不會提供有效讀效能。
2. 表示更複雜的多對多的關係
3. 對大型分級資料建模

引用比嵌入式文檔的靈活性更大。但client應用必須處理引用帶來的查詢問題。總之，歸一化資料模型須要很多其它的往返server。

• 嵌入資料

嵌入式文檔通過在一個單一文檔結構裡儲存相關資料來捕獲資料間的關係。MongoDB的文檔使在一個文檔裡的一個欄位或欄位資料嵌入一個文檔作為子文檔詳細可能性。這些非正常化資料使得應用能夠在一個單一資料庫操作力擷取和操縱資料。

的資料模型就是嵌入式欄位保護全部的相關資訊。

以下討論嵌入子文檔的資料模型的優缺點：

使用MongoDB，你能夠在一個單一結構或文檔嵌入相關資料。這個模型是著名的“非正常化”模型，利用了MongoDB豐富文檔的優勢。

嵌入資料模型同意應用在同樣的資料庫記錄裡儲存相關片段資訊。

因此。應用在完畢一個常規操作時，僅僅需處理非常少的查詢或更新。

一般，當以下情形時可使用嵌入資料模型：

1. 實體間有“包括關係”
2. 實體間有一對多的關係。在這些關係裡。“多“或子文檔常常被看做"一"或父文檔的上下文裡

一般來說，嵌入提供了更好的讀效能，以及在單一資料庫操作裡請求和擷取相關資料的能力。嵌入資料模型使得在哪一個原子操作裡更新相關資料成為可能。

然而，在一個文檔的嵌入資料模型可能導致文檔建立後的增長。

文檔的增長會影響寫效能並導致資料片段問題。而且，在MongoDB裡的文檔大小必須小於最大的BSON文檔大小。對大型位元據，考慮GridFS。

寫操作的原子性

在MongoDB，寫操作在文檔這一級是原子的，而且沒有單一的寫操作能原子性的影響多個文檔或集合。

一個有嵌入資料的非正常化資料模型在一個單一文檔裡包括了能表示一個實體的相關資料。

這有利於寫操作的原子性，由於單一的寫操作能直接對一個實體插入或更新資料。正常化資料會在多個集合裡分散了資料，這會要求多次寫操作。因此不是原子性的。

然而，有利於原子性寫的模式會限制一個應用使用資料的方法或改動資料的方法。因此須要平衡原子性和平衡性。

文檔增長

有的更新，比方向數組加入元素或加入新的欄位，會增大文檔的大小。

假設文檔的大小超過了給該文檔分配的空間，MongoDB會又一次定位這個文檔。文檔的增長會影響正常化和非正常化資料的選擇。

資料使用和效能

當設計一個文檔模型，要考慮應用將怎樣使用你的資料庫。比方。假設你的應用僅使用近期插入的資料，考慮使用 Capped Collections.或者，你的應用須要總是讀操作。加入索引是常見的提升效能的辦法。

MongoDB：資料模型介紹