簡要介紹MongoDB的資料模型

簡要介紹MongoDB的資料模型

MongoDB資料是特別靈活的，與SQL資料庫相比，它不需要在插入資料前先定義表的結構。MongoDB的集合不強調固定的文檔結構。這種靈活性使它能夠輕鬆映射文檔結構。每一個文檔都可以映射它要表達的對象，即使這些資料有實質性的不同。其實在實際中，同一集合下的文檔通常採用相似的結構。

MongoDB資料建模的主要問題時在應用程式的需求，資料庫引擎的效能特性和資料檢索模型之間做一個平衡。設計資料模型是，總是要考慮應用程式使用到的資料（查詢、更新以及需要處理的資料等等）以及資料結構本身。

文檔結構

設計MongoDB資料模型的關鍵是考慮好文檔結構和應用程式表示的資料之間的關係。有兩種方式可以表達這種關係：引用（references）和嵌入文檔（embedded documents）。

引用（References）

引用（References）儲存資料之間的關係，包括從一個文檔連結或引用到另外一個文檔。這樣應用程式就解決了訪問關聯資料的問題，一般來說，這些都是規範資料的資料模型。

Embedded Data

嵌入式文檔通過儲存相關的資料在一個文檔結構中來捕獲資料之間的關係。MongoDB文檔可以在當前文檔的欄位或數組中嵌入文檔作為子文檔。這些非正常化資料模型允許應用程式檢索和操作相關的資料在一個單一的資料庫操作。

寫操作的原子性

在MongoDB中，寫操作的原子性限制在文檔層級，沒有一個寫操作可以自動影響到多個文檔或多個集合。正常化的嵌入式資料模型整合了所有的關聯資料在一個文檔中來展現實體。這有助於原子寫操作在一個寫操作中插入和更新實體的資料。正常化資料能夠分隔多個集合的資料並且需要在非原子性操作中需要多個寫操作。

然後，促進原子寫的模式可能限制應用程式使用資料，也可能限制修改應用程式的方法。原子性考慮設計模式的挑戰，平衡靈活性和原子性。

文檔增加

像添加元素到數組或者增加新欄位這樣的更新，會增加文檔的大小。如果文檔的大小超過了為該文檔分配空間，MongoDB會重新分配磁碟空間。考慮到空間的增加，應該正常化或使用規範的資料。

資料使用和效能

當設計資料模型的時候，應考慮應用程式如何使用資料庫。比如，如果應用程式僅使用最近插入的文檔，考慮使用頂端集合（Capped Collections）。如果應用程式需要頻繁的讀取集合，添加索引能夠提高資料查詢效率。

CentOS編譯安裝MongoDB

CentOS 編譯安裝 MongoDB與mongoDB的php擴充

CentOS 6 使用 yum 安裝MongoDB及伺服器端配置

Ubuntu 13.04下安裝MongoDB2.4.3

MongoDB入門必讀(概念與實戰並重)

《MongoDB 權威指南》(MongoDB: The Definitive Guide)英文文字版[PDF]

MongoDB 的詳細介紹：請點這裡
MongoDB 的：請點這裡

 本文永久更新連結地址：