MongoDB循序漸進之[特性]面向文檔存儲

. 面向文檔存儲 JSON風格的文件與動態模式使mongodb簡單而強大。 Schema Design：模式設計 在MongoDB中Schema的設計是非常不同于傳統的DBMS。然而Schema是非常重要的，并且是建立應用程序的第一步。 在傳統的數據模型中，給一個實體關系模型一個獨立的用例在

?

.

面向文檔存儲

JSON風格的文件與動態模式使MongoDB簡單而強大。

?

Schema Design：模式設計

?? 在MongoDB中Schema的設計是非常不同于傳統的DBMS。然而Schema是非常重要的，并且是建立應用程序的第一步。

在傳統的數據模型中，給一個實體關系模型一個獨立的用例在概念上是正確的，這是一個很正常的第三范式，但這通常會偏離你處于性能方面的考慮。在MongoDB中，Schema的設計不僅僅是對數據進行建模的用例。根據最常見的用例，我們對Schema的設計進行了優化，這有利有弊——用例通常是高性能的。然而有一個偏見是說Schema可能使某些動態查詢相比于關系模型缺少一點優雅。

當我們要設計Schema時，需要考慮以下問題：

1.什么時候我們嵌入數據和鏈接(見下文)？我們在這里的決定講影響第二個問題的答案

2.我們有多少集合，它們是什么？

3.什么時候我們需要原子操作？這些操作可以執行范圍內的BSON文檔，但并不是所有文檔。???

4.我們將創建什么索引使查詢和更新快?

5.我們如何切分？什么是分片鍵?

? Embedding and Linking：嵌入和鏈接

?? 在設計一個MongoDB Schema時一個關鍵問題是什么時候嵌入，什么時候鏈接。嵌入是嵌套對象和數組到BSON文檔中，服務器空間，鏈接是文檔之間的引用。???

在MongoDB中沒有join——在1000服務器集群中做分布式join是很困難的。嵌入有點像“prejoined”(預連接)數據。

服務器處理在一個文檔里面的操作是很容易的，美國空間，這些操作可以相當豐富。鏈接相比之下必須處理客戶端應用程序，應用程序是通過發行一個后續查詢來處理文檔。

一般來說，實體之間有“包含”關系，則應該選擇嵌入。當不使用連接會導致重復的數據，那么就選擇使用鏈接。

? Collections：集合

?? 在MongoDB中集合類似于關系數據庫中的表，香港空間，每一個集合包含文檔，正如上面提到的這些文件可以相當豐富。在一個集合文檔內字段是沒有顯式聲明。然而來自于Schema設計師的一個關于那些字段將會是什么的概念，并且文檔在集合內是怎樣被結構化的。MongoDB不需要集合內的文檔有相同的結構，然而在實踐中大多數集合都是高度同質的。只要我們愿意我們就可以避免這些，例如當添加一個新字段，在這種情況一個“alter table”風格操作不是必要的。

? Atomic Operations：原子操作

?? 有些問題需要能夠執行原子操作。例如，簡單地增加計數器一個需要的原子性操作的案例。MongoDB還可以執行更復雜的操作,如下面所示的偽代碼:?

atomically { if( doc.credits > 5 ) { doc.credits -= 5; doc.debits += 5; } }