MongoDB 是目前主流的 NoSQL 數據庫之一，與關系型數據庫和其它的 NoSQL 不同，MongoDB 使用了面向文檔的數據存儲方式，將數據以類似 JSON 的方式存儲在磁盤上，因為項目上的一些歷史遺留問題，作者在最近的工作中也不得不經常與 MongoDB 打交道，這也是這篇文章出現的原因。

雖然在之前也對 MongoDB 有所了解，但是真正在項目中大規模使用還是***次，使用過程中也暴露了大量的問題，不過在這里，我們主要對 MongoDB 中的一些重要概念的原理進行介紹，也會與 MySQL 這種傳統的關系型數據庫做一個對比，讓讀者自行判斷它們之間的優勢和劣勢。

概述

MongoDB 雖然也是數據庫，但是它與傳統的 RDBMS 相比有著巨大的不同，很多開發者都認為或者被灌輸了一種思想，MongoDB 這種無 Scheme 的數據庫相比 RDBMS 有著巨大的性能提升，這個判斷其實是一種誤解;因為數據庫的性能不止與數據庫本身的設計有關系，還與開發者對表結構和索引的設計、存儲引擎的選擇和業務有著巨大的關系，如果認為 僅進行了數據庫的替換就能得到數量級的性能提升 ，那還是太年輕了。

[[202745]]

架構

現有流行的數據庫其實都有著非常相似的架構，MongoDB 其實就與 MySQL 中的架構相差不多，底層都使用了『可插拔』的存儲引擎以滿足用戶的不同需要。

用戶可以根據表中的數據特征選擇不同的存儲引擎，它們可以在同一個 MongoDB 的實例中使用;在***版本的 MongoDB 中使用了 WiredTiger 作為默認的存儲引擎，WiredTiger 提供了不同粒度的并發控制和壓縮機制，能夠為不同種類的應用提供了***的性能和存儲效率。

在不同的存儲引擎上層的就是 MongoDB 的數據模型和查詢語言了，與關系型數據庫不同，由于 MongoDB 對數據的存儲與 RDBMS 有較大的差異，所以它創建了一套不同的查詢語言;雖然 MongoDB 查詢語言非常強大，支持的功能也很多，同時也是可編程的，不過其中包含的內容非常繁雜、API 設計也不是非常優雅，所以還是需要一些學習成本的，對于長時間使用 MySQL 的開發者肯定會有些不習慣。

db.collection.updateMany( 
   <filter>, 
   <update>, 
   { 
     upsert: <boolean>, 
     writeConcern: <document>, 
     collation: <document> 
   } 
) 

查詢語言的復雜是因為 MongoDB 支持了很多的數據類型，同時每一條數據記錄也就是文檔有著非常復雜的結構，這點是從設計上就沒有辦法避免的，所以還需要使用 MongoDB 的開發者花一些時間去學習各種各樣的 API。

RDBMS 與 MongoDB

MongoDB 使用面向文檔的的數據模型，導致很多概念都與 RDBMS 有一些差別，雖然從總體上來看兩者都有相對應的概念，不過概念之間細微的差別其實也會影響我們對 MongoDB 的理解：

傳統的 RDBMS 其實使用 Table 的格式將數據邏輯地存儲在一張二維的表中，其中不包括任何復雜的數據結構，但是由于 MongoDB 支持嵌入文檔、數組和哈希等多種復雜數據結構的使用，所以它最終將所有的數據以 BSON 的數據格式存儲起來。

RDBMS 和 MongoDB 中的概念都有著相互對應的關系，數據庫、表、行和索引的概念在兩中數據庫中都非常相似，唯獨***的 JOIN 和 Embedded Document 或者 Reference 有著巨大的差別。這一點差別其實也影響了在使用 MongoDB 時對集合(Collection)Schema 的設計，如果我們在 MongoDB 中遵循了與 RDBMS 中相同的思想對 Collection 進行設計，那么就不可避免的使用很多的 "JOIN" 語句，而 MongoDB 是不支持 "JOIN" 的，在應用內做這種查詢的性能非常非常差，在這時使用嵌入式的文檔其實就可以解決這種問題了，嵌入式的文檔雖然可能會造成很多的數據冗余導致我們在更新時會很痛苦，但是查詢時確實非常迅速。

{ 
  _id: <ObjectId1>, 
  name: "draveness", 
  books: [ 
    { 
      _id: <ObjectId2>, 
      name: "MongoDB: The Definitive Guide" 
    }, 
    { 
      _id: <ObjectId3>, 
      name: "High Performance MySQL" 
    } 
  ] 
} 

在 MongoDB 的使用時，我們一定要忘記很多 RDBMS 中對于表設計的規則，同時想清楚 MongoDB 的優勢，仔細思考如何對表進行設計才能利用 MongoDB 提供的諸多特性提升查詢的效率。

數據模型

MongoDB 與 RDBMS 之間***的不同，就是數據模型的設計有著非常明顯的差異，數據模型的不同決定了它有著非常不同的特性，存儲在 MongoDB 中的數據有著非常靈活的 Schema，我們不需要像 RDBMS 一樣，在插入數據之前就決定并且定義表中的數據結構，MongoDB 的結合不對 Collection 的數據結構進行任何限制，但是在實際使用中，同一個 Collection 中的大多數文檔都具有類似的結構。

在為 MongoDB 應用設計數據模型時，如何表示數據模型之間的關系其實是需要開發者需要仔細考慮的，MongoDB 為表示文檔之間的關系提供了兩種不同的方法：引用和嵌入。

標準化數據模型

引用(Reference)在 MongoDB 中被稱為標準化的數據模型，它與 MySQL 的外鍵非常相似，每一個文檔都可以通過一個 xx_id 的字段『鏈接』到其他的文檔：

但是 MongoDB 中的這種引用不像 MySQL 中可以直接通過 JOIN 進行查找，我們需要使用額外的查詢找到該引用對應的模型，這雖然提供了更多的靈活性，不過由于增加了客戶端和 MongoDB 之間的交互次數(Round-Trip)也會導致查詢變慢，甚至非常嚴重的性能問題。

MongoDB 中的引用并不會對引用對應的數據模型是否真正存在做出任何的約束，所以如果在應用層級沒有對文檔之間的關系有所約束，那么就可能會出現引用了指向不存在的文檔的問題：

雖然引用有著比較嚴重的性能問題并且在數據庫層面沒有對模型是否被刪除加上限制，不過它提供的一些特點是嵌入式的文檔無法給予了，當我們需要表示多對多關系或者更加龐大的數據集時，就可以考慮使用標準化的數據模型 — 引用了。

嵌入式數據模型

除了與 MySQL 中非常相似的引用，MongoDB 由于其獨特的數據存儲方式，還提供了嵌入式的數據模型，嵌入式的數據模型也被認為是不標準的數據模型：

因為 MongoDB 使用 BSON 的數據格式對數據進行存儲，而嵌入式數據模型中的子文檔其實就是父文檔中的另一個值，只是其中存儲的是一個對象：

{ 
  _id: <ObjectId1>, 
  username: "draveness", 
  age: 20, 
  contact: [ 
    { 
      _id: <ObjectId2>, 
      email: "i@draveness.me" 
    } 
  ] 
} 

嵌入式的數據模型允許我們將有相同的關系的信息存儲在同一個數據記錄中，這樣應用就可以更快地對相關的數據進行查詢和更新了;當我們的數據模型中有『包含』這樣的關系或者模型經常需要與其他模型一起出現(查詢)時，比如文章和評論，那么就可以考慮使用嵌入式的關系對數據模型進行設計。

總而言之，嵌入的使用讓我們在更少的請求中獲得更多的相關數據，能夠為讀操作提供更高的性能，也為在同一個寫請求中同時更新相關數據提供了支持。

MongoDB 底層的 WiredTiger 存儲引擎能夠保證對于同一個文檔的操作都是原子的，任意一個寫操作都不能原子性地影響多個文檔或者多個集合。

主鍵和索引

在這一節中，我們將主要介紹 MongoDB 中不同類型的索引，當然也包括每個文檔中非常重要的字段 _id ，可以 理解 為 MongoDB 的『主鍵』，除此之外還會介紹單字段索引、復合索引以及多鍵索引等類型的索引。

MongoDB 中索引的概念其實與 MySQL 中的索引相差不多，無論是底層的數據結構還是基本的索引類型都幾乎完全相同，兩者之間的區別就在于因為 MongoDB 支持了不同類型的數據結構，所以也理所應當地提供了更多的索引種類。

默認索引

MySQL 中的每一個數據行都具有一個主鍵，數據庫中的數據都是按照以主鍵作為鍵物理地存儲在文件中的;除了用于數據的存儲，主鍵由于其特性也能夠加速數據庫的查詢語句。

而 MongoDB 中所有的文檔也都有一個唯一的 _id 字段，在默認情況下所有的文檔都使用一個長 12 字節的 ObjectId 作為默認索引：

前四位代表當前 _id 生成時的 Unix 時間戳，在這之后是三位的機器標識符和兩位的處理器標識符，***是一個三位的計數器，初始值就是一個隨機數;通過這種方式代替遞增的 id 能夠解決分布式的 MongoDB 生成唯一標識符的問題，同時可以在一定程度上保證 id 的的增長是遞增的。

單字段索引(Single Field)

除了 MongoDB 提供的默認 _id 字段之外，我們還可以建立其它的單鍵索引，而且其中不止支持順序的索引，還支持對索引倒排：

db.users.createIndex( { age: -1 } ) 

MySQL8.0 之前的索引都只能是正序排列的，在 8.0 之后才引入了逆序的索引，單一字段索引可以說是 MySQL 中的輔助(Secondary)索引的一個子集，它只是對除了 _id 外的任意單一字段建立起正序或者逆序的索引樹。

復合索引(Compound)

除了單一字段索引這種非常簡單的索引類型之外，MongoDB 還支持多個不同字段組成的復合索引(Compound Index)，由于 MongoDB 中支持對同一字段的正逆序排列，所以相比于 MySQL 中的輔助索引就會出現更多的情況：

db.users.createIndex( { username: 1, age: -1 } )  
db.users.createIndex( { username: 1, age: 1 } ) 

上面的兩個索引是完全不同的，在磁盤上的 B+ 樹其實也按照了完全不同的順序進行存儲，雖然 username 字段都是升序排列的，但是對于 age 來說，兩個索引的處理是完全相反的：

這也就造成了在使用查詢語句對集合中數據進行查找時，如果約定了正逆序，那么其實是會使用不同的索引的，所以在索引創建時一定要考慮好使用的場景，避免創建無用的索引。

多鍵索引(Multikey)

由于 MongoDB 支持了類似數組的數據結構，所以也提供了名為多鍵索引的功能，可以將數組中的每一個元素進行索引，索引的創建其實與單字段索引沒有太多的區別：

db.collection.createIndex( { address: 1 } ) 

如果一個字段是值是數組，那么在使用上述代碼時會自動為這個字段創建一個多鍵索引，能夠加速對數組中元素的查找。

文本索引(Text)

文本索引是 MongoDB 為我們提供的另一個比較實用的功能，不過在這里也只是對這種類型的索引提一下，也不打算深入去談談這東西的性能如何，如果真的要做全文索引的話，還是推薦使用 Elasticsearch 這種更專業的東西來做，而不是使用 MongoDB 提供的這項功能。

存儲

如何存儲數據就是一個比較重要的問題，在前面我們已經提到了 MongoDB 與 MySQL 一樣都提供了插件化的存儲引擎支持，作為 MongoDB 的主要組件之一，存儲引擎全權負責了 MongoDB 對數據的管理。

WiredTiger

MongoDB3.2 之后 WiredTiger 就是默認的存儲引擎了，如果對各個存儲引擎并不了解，那么還是不要改變 MongoDB 的默認存儲引擎;它有著非常多的優點，比如擁有效率非常高的緩存機制：

WiredTiger 還支持在內存中和磁盤上對索引進行壓縮，在壓縮時也使用了前綴壓縮的方式以減少 RAM 的使用，在后面的文章中我們會詳細介紹和分析 WiredTiger 存儲引擎是如何對各種數據進行存儲的。

Journaling

為了在數據庫宕機保證 MongoDB 中數據的持久性，MongoDB 使用了 Write Ahead Logging 向磁盤上的 journal 文件預先進行寫入;除了 journal 日志，MongoDB 還使用檢查點(Checkpoint)來保證數據的一致性，當數據庫發生宕機時，我們就需要 Checkpoint 和 journal 文件協作完成數據的恢復工作：

• 在數據文件中查找上一個檢查點的標識符;
• 在 journal 文件中查找標識符對應的記錄;
• 重做對應記錄之后的全部操作;

MongoDB 會每隔 60s 或者在 journal 數據的寫入達到 2GB 時設置一次檢查點，當然我們也可以通過在寫入時傳入 j: true 的參數強制 journal 文件的同步。

這篇文章并不會介紹 Journal 文件的格式以及相關的內容，作者可能會在之后介紹分析 WiredTiger 的文章中簡單分析其存儲格式以及一些其它特性。

總結

這篇文章中只是對 MongoDB 的一些基本特性以及數據模型做了簡單的介紹，雖然『***』擴展是 MongoDB 非常重要的特性，但是由于篇幅所限，我們并沒有介紹任何跟 MongoDB 集群相關的信息，不過會在之后的文章中專門介紹多實例的 MongoDB 是如何協同工作的。

在這里，我想說的是，如果各位讀者接收到了類似 MongoDB 比 MySQL 性能好很多的斷言，但是在使用 MongoDB 的過程中仍然遵循以往 RDBMS 對數據庫的設計方式，那么我相信性能在最終也不會有太大的提升，反而可能會不升反降;只有真正理解 MongoDB 的數據模型，并且根據業務的需要進行設計才能很好地利用類似嵌入式文檔等特性并提升 MongoDB 的性能。