MongoDB：資料模型介紹，mongodb資料模型

MongoDB：資料模型介紹，mongodb資料模型

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

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

文檔結構

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

• 引用

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

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

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

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

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

• 嵌入資料

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

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

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

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

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

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

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

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

寫操作的原子性

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

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

文檔增長

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

資料使用和效能

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

MongoDB是否適合資料倉儲

今天花點時間瀏覽了一下MongoDB的權威指南。MongoDB幾個推薦的亮點：豐富的資料模型擴充性好豐富的弄能速度快易於管理上面這幾個亮點對於資料倉儲而言優勢不是很明顯。 對於資料倉儲來說可以分為兩層來看，一層是做ETL運算伺服器，主要要求是大資料量計算，並發要求並不是很高；另外一層就是BI的前端報表展現，雖然說前端報表的資料都是經過ETL加工處理過成品，但是有時候主要業務表的資料時不時也會有個幾百萬的，當然也可以在這個幾百萬的基礎上再做一次匯總，但是就犧牲了模型的靈活性。所以這個時候就需要就需要前端展現報表伺服器既有一定的計算能力，又要有一定的並發能力。 MongoDB對於ETL伺服器而言顯然不是很合適，它的計算能力還無法跟hadoop、Greenplum媲美，估計計算能力一般（沒有測試過）。 對於前端報表展現貌似可以，速度快，支援一定計算能力，並發好。仔細想想也有很多不足，最要命的就是不能join，而且報表展現中很多情況會用到分析函數，資料分析師在分析資料時也會經常用到，這就是一個比較頭大的問題，否則為了報表就要多做很多ETL工作，分析師的工作量也會增加很多。MongoDB的shell 指令碼目前還無法跟sql的靈活性和易用性相提並論。 還有一點比較困難的是，現在技術人員都是學的關係型資料庫，突然轉變成NOsql資料庫，是一個很大的成本，如果僅僅是一兩個人轉型還好，如果要一個團隊轉型難度會很大。
 
一串連mongodb資料庫的用戶端工具，可以用的來

JMongoBrowser,MonvoVUE,windows內建的命令列也可以用。

不過最好下個增強cmd工具，比如powercmd，因為在命令列裡顯示不出來的，在用戶端工具裡也不一定顯示的出來。學mongo，最好學會敲命令，而不是“點啊點”