MongoDB：資料模型介紹

標籤：mongodb

在MongoDB的資料有靈活的模式。不像SQL資料庫，（SQL資料庫）要求你必須在插入資料之前決定和聲明一個表的模式，MongoDB的集合不強制文檔的結構。這個靈活性有利於文檔到實體或對象的映射。每個文檔可以匹配所要表示實體的資料欄位，即使資料的變化很顯著。但在實際操作中，一個集合的文檔共用一個相似的結構。

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

文檔結構

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

• 引用

引用通過包括串連或一個文檔到另一個文檔間的引用儲存著資料間的關係。應用能夠解析這些引用來訪問到相關資料。廣義上說，這些都是歸一化的資料模型(normalized data models).

的資料模型使用引用來聯絡文檔。contract文檔和access文檔都保護著user文檔的引用。

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

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

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

引用比嵌入式文檔的靈活性更大。但用戶端應用必須處理引用帶來的查詢問題。總之，歸一化資料模型需要更多的往返伺服器。

• 嵌入資料

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

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

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

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

嵌入資料模型允許應用在相同的資料庫記錄裡儲存相關片段資訊。因此，應用在完成一個常規操作時，只需處理很少的查詢或更新。

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

1. 實體間有“內含項目關聯性”
2. 實體間有一對多的關係。在這些關係裡，“多“或子文檔經常被看做"一"或父文檔的上下文裡

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

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

寫操作的原子性

在MongoDB，寫操作在文檔這一級是原子的，並且沒有單一的寫操作能原子性的影響多個文檔或集合。一個有嵌入資料的非正常化資料模型在一個單一文檔裡包含了能表示一個實體的相關資料。這有利於寫操作的原子性，因為單一的寫操作能直接對一個實體插入或更新資料。正常化資料會在多個集合裡分散了資料，這會要求多次寫操作，因此不是原子性的。

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

文檔增長

有的更新，比如向數組添加元素或添加新的欄位，會增大文檔的大小。如果文檔的大小超過了給該文檔分配的空間，MongoDB會重新置放這個文檔。文檔的增長會影響正常化和非正常化資料的選擇。

資料使用和效能

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