MongoDB Data Models 資料結構設計

標籤：mongodb   model   concepts   結構   設計   

1 資料建模介紹

MongoDB的資料結構很靈活,不強制要求資料結構.但是通常一個集合內部使用相同的結構.

資料建模的關鍵是平衡應用的需求和資料庫執行和資料檢索模型的效能.設計資料模型時,要考慮資料的使用方式和資料自身的結構

1.1 文檔結構

設計MongoDB應用的資料模型的關鍵在於文檔結構和應用程式如何表示資料之間的關係,這有兩種工具允許應用程式來表示這些關係:引用和嵌入型文檔.

1.1.1 引用:

類似關係型資料庫中的外鍵的引用,通常不同的集合中互相引用_id欄位

1.1.2 內嵌資料:

某個欄位的值為BSON或者某個欄位值為數組,數組中的每個值為BSON

1.2 寫操作的原子性

MongoDB在文檔層級的寫操作是原子性的,沒有任何單個修改多條文檔,或者多個集合的操作是原子性的.包含嵌入型資料的非標準化資料將其所表示的實體的所有的相關資料在單個文檔中儲存,這使得對這個實體的操作變為對這個文檔的原子性操作.標準化資料的過程將資料跨多個集合儲存,這使得每次對實體的修改需要多次寫操作,並且多次寫操作不是原子性的.

然而,方便原子操作的結構也許會限制應用程式使用資料或者限制修改應用程式.

1.3 文檔增長

一些更新操作,比如向數組中追加元素或者向文檔中添加欄位,都會導致文檔大小增加.
如果文檔大小超過了分配給它的空間,MongoDB將重新在硬碟上為其分配空間.這種增長將影響你選擇使用標準化資料還是非標準化資料

1.4 資料的使用和效能

當設計資料模型的時候,考慮應用程式將怎樣使用你的資料庫.比如說:如果你的應用程式只是使用最近插入的文檔,考慮使用Capped Collections,或者你的應用程式主要是讀取操作,為常用的查詢添加索引來改善效能.

2 資料建模概念2.1 資料模型設計

高效的資料模型迎合應用程式的需求.文檔結構考慮的關鍵因素是使用嵌入型文檔還是使用引用

2.1.1嵌入型資料模型

嵌入型文檔允許一個文檔中儲存多條相關資訊應用程式可以執行更少的查詢和更新操作.

以下情況使用嵌入型文檔:
1.實體間有"包含"的關係
2.實體間有一對多的關係.在這種關係中,多的一方總是在一的一方作為上下文或者作為父文檔的時候出現.

嵌入型文檔讀操作效能較好,單一資料庫的時候檢索資料快.update相關資料的操作是原子性的.

缺點:嵌入型文檔導致文檔建立後大小的增長.進一步說,文檔必須小於BSON文檔的最大值限制

與嵌入型文檔進行互動,需要使用"."操作符來訪問嵌入型文檔

2.1.2標準化資料模型

標準化資料使用引用來描述文檔間的關係

以下情況使用標準化資料模型:
1.嵌入型文檔模型導致資料重複的同時,查詢效能優勢不能彌補資料重複帶來的不足的時候
2.用以表示更加複雜的多對多的關係
3.用以建模多層的資料集

引用比嵌入更加靈活.然而隨之而來的是應用程式需要查詢並解析相關的引用.換句話說,標準化資料模型會導致程式和MongoDB之間更多的通訊.

2.2 操作的因素和資料模型

需要權衡考慮資料自身和資料庫.

2.2.1 文檔增長

數組的push操作,和增加新的 欄位將會導致文檔大小的增長.超過文檔已指派的空間大小的時候,MongoDB將會為其重新分配空間,這將導致比原地更新花費更多的時間,同時也會導致片段化儲存.雖然MongoDB自動會在文檔之間添加空隙以減少類似的重新分配,建立模型的時候需要儘可能的避免文檔增長

2.2.2 原子操作

上面已有介紹,略

2.2.3 Sharding

MongoDB使用Sharding技術來提供水平的縮放.這些叢集支援大資料集的開發和高輸送量的操作.Sharding允許使用者將一個資料庫內的一個集合,通過mongod的執行個體或者shards的標號,分散到多個集合文檔中

2.2.4 索引

使用索引來改善查詢效能.在某些欄位上建立索引,通常是在這些欄位上的查詢返回排序的結果的時候.MongoDB自動在_id欄位上建立索引.

建立索引時要考慮以下內容:
1.每個索引需要至少8KB的空間
2.建立索引會對寫操作有負面影響,對於寫操作很多的集合來說,索引的所花費的代價很高因為每次插入的操作都必須更新所有的索引
3.對於讀操作較多的集合來說,索引通常是有益的.索引不影響沒有建立索引的讀操作.
4.當啟用的時候,每個索引都會消耗硬碟和記憶體空間.這些開銷對於容量計劃,特別是超過工作集的大小的考慮,是極為關鍵的,應該追蹤的.

2.2.5 大量的集合

在某些情況下,需要選擇將相關的資訊儲存字多個集合中而不是一個集合中,比如不同的log內容儲存在不同的log集合中

通常大量的集合沒有效能的減弱而是效能的最佳化.不同的集合對於高輸送量的批處理進程是非常重要的.

當使用有大量集合的資料模型的時候,考慮以下內容:
1.每個集合至少需要即k空間
2.每個索引,包括_id上的索引,需要至少8KB空間
3.對於資料庫來說,一個,命名空間檔案儲存體著該資料庫所有的中繼資料,每個索引和集合在這個命名空間檔案中有其自己的入口.
4.MongoDB對於命名空間的數量有限制.你也許想知道當前的命名空間數,以決定資料庫還可以支援多少額外的 命名空間,查詢當前命名空間的數量,在mongo的shell中運行:db.system.namespaces.count()

2.2.6 資料生命週期管理

資料建模的時候應該考慮資料的生命週期管理.
如果你的應用程式需要使用限定時間段內的資料,考慮使用TTL屬性.
另外,如果你的應用程式僅僅使用最近插入的文檔,考慮使用Capped Collections.它提供了對於文檔的FIFO(也就是隊列式)的管理,有效支援哪些依賴於插入順序的插入和讀取操作.

2.3 GridFS

GridFS是對於超過BSON文檔大小限制16M的文檔儲存和檢索的規範.
不是將檔案儲存體在單個文檔中,GridFS將檔案分割為多個部分,或者資料庫,將每個資料區塊作為單獨的文檔進行儲存.預設的GridFS限制資料區塊大小為255k.GridFS使用兩個集合來隱藏檔.一個結合隱藏檔的資料區塊,另一個隱藏檔的中繼資料資訊.

當你查詢GridFS儲存的檔案的時候,驅動,或者用戶端將重新組裝你需要的資料區塊.你可以對儲存在GridFS中的檔案執行多種查詢.你也可以擷取檔案的某一塊的資訊,這使得你可以跳到視頻或者音訊中間部分.

GridFS不僅僅對於儲存大小超過16M的檔案有用,它可以用於儲存任何你在訪問時不想將整個檔案載入到記憶體中的檔案



MongoDB Data Models 資料結構設計