了解 MongoDB 看這一篇就夠了

一、簡介

MongoDB 是一款流行的開源文檔型數據庫，從它的命名來看，確實是有一定野心的。
MongoDB 的原名一開始來自于 英文單詞"Humongous", 中文含義是指"龐大"，即命名者的意圖是可以處理大規模的數據。

但筆者更喜歡稱呼它為 "芒果"數據庫，除了譯音更加相近之外，原因還來自于這幾年使用 MongoDB 的兩層感覺：

• 第一層感受是"爽"，使用這個文檔數據庫的特點是幾乎不受什么限制，一方面Json文檔式的結構更容易理解，而無Schema約束也讓DDL管理更加簡單，一切都可以很快速的進行。

• 第二層感受是"酸爽"，這點相信干運維或是支撐性工作的兄弟感受會比較深刻，MongoDB 由于入門體驗"太過于友好"，導致一些團隊認為用好這個數據庫是個很簡單的事情，所以開發兄弟在存量系統上埋一些坑也是正常的事情。
  所謂交付一時爽，維護火葬場.. 當然了，這句話可能有些過。 但這里的潛臺詞是：與傳統的RDBMS數據庫一樣，MongoDB 在使用上也需要認真的考量和看護，不然的化，會遇到更多的坑。

那么，盡管文檔數據庫在選型上會讓一些團隊望而卻步，仍然不阻礙該數據庫所獲得的一些支持，比如 DB-Engine 上的排名：

圖-DBEngine排名

在全部的排名中，MongoDB 長期排在第5位(文檔數據庫排名第1位)，同時也是最受歡迎的 NoSQL 數據庫。
另外，MongoDB 的社區一直比較活躍，加上商業上的驅動(MongoDB于2017年在納斯達克上市)，這些因素都推動了該開源數據庫的發展。

如果對于 MongoDB的發展史感興趣，可以參考下沒有一個技術天生完美，MongoDB 十年發展全紀錄這篇文章。

MongoDB 數據庫的一些特性：

• 面向文檔存儲，基于JSON/BSON 可表示靈活的數據結構
• 動態 DDL能力，沒有強Schema約束，支持快速迭代
• 高性能計算，提供基于內存的快速數據查詢
• 容易擴展，利用數據分片可以支持海量數據存儲
• 豐富的功能集，支持二級索引、強大的聚合管道功能，為開發者量身定做的功能，如數據自動老化、固定集合等等。
• 跨平臺版本、支持多語言SDK..

假定你是初次了解 MongoDB，下面的內容將能幫助你對該數據庫技術的全貌產生一定的了解。

二、基本模型

數據結構對于一個軟件來說是至關重要的，MongoDB 在概念模型上參考了 SQL數據庫，但并非完全相同。

關于這點，也有人說，MongoDB 是 NoSQL中最像SQL的數據庫..

如下表所示：

SQL概念	MongoDB概念
database	database
table	collection
row	document
column	field

• database 數據庫，與SQL的數據庫(database)概念相同，一個數據庫包含多個集合(表)
• collection 集合，相當于SQL中的表(table)，一個集合可以存放多個文檔(行)。 不同之處就在于集合的結構(schema)是動態的，不需要預先聲明一個嚴格的表結構。更重要的是，默認情況下 MongoDB 并不會對寫入的數據做任何schema的校驗。
• document 文檔，相當于SQL中的行(row)，一個文檔由多個字段(列)組成，并采用bson(json)格式表示。
• field 字段，相當于SQL中的列(column)，相比普通column的差別在于field的類型可以更加靈活，比如支持嵌套的文檔、數組。
  此外，MongoDB中字段的類型是固定的、區分大小寫、并且文檔中的字段也是有序的。

另外，SQL 還有一些其他的概念，對應關系如下：

SQL概念	MongoDB概念
primary key	_id
foreign key	reference
view	view
index	index
join	$lookup
transaction	trasaction
group by	aggregation

• _id 主鍵，MongoDB 默認使用一個_id 字段來保證文檔的唯一性。
• reference 引用，勉強可以對應于 外鍵(foreign key) 的概念，之所以是勉強是因為 reference 并沒有實現任何外鍵的約束，而只是由客戶端(driver)自動進行關聯查詢、轉換的一個特殊類型。
• view 視圖，MongoDB 3.4 開始支持視圖，和 SQL 的視圖沒有什么差異，視圖是基于表/集合之上進行動態查詢的一層對象，可以是虛擬的，也可以是物理的(物化視圖)。
• index 索引，與SQL 的索引相同。
• $lookup，這是一個聚合操作符，可以用于實現類似 SQL-join 連接的功能
• transaction 事務，從 MongoDB 4.0 版本開始，提供了對于事務的支持
• aggregation 聚合，MongoDB 提供了強大的聚合計算框架，group by 是其中的一類聚合操作。

BSON 數據類型

MongoDB 文檔可以使用 Javascript 對象表示，從格式上講，是基于 JSON 的。

一個典型的文檔如下：

{
  "_id": 1,
  "name" : { "first" : "John", "last" : "Backus" },
  "contribs" : [ "Fortran", "ALGOL", "Backus-Naur Form", "FP" ],
  "awards" : [
    {
      "award" : "W.W. McDowell Award",
      "year" : 1967,
      "by" : "IEEE Computer Society"
    }, {
      "award" : "Draper Prize",
      "year" : 1993,
      "by" : "National Academy of Engineering"
    }
  ]
}

曾經，JSON 的出現及流行讓 Web 2.0 的數據傳輸變得非常簡單，所以使用 JSON 語法是非常容易讓開發者接受的。
但是 JSON 也有自己的短板，比如無法支持像日期這樣的特定數據類型，因此 MongoDB 實際上使用的是一種擴展式的JSON，叫 BSON(Binary JSON)。

BSON 所支持的數據類型包括：

圖-BSON類型

分布式ID

在單機時代，大多數應用可以使用數據庫自增式ID 來作為主鍵。 傳統的 RDBMS 也都支持這種方式，比如 mysql 可以通過聲明 auto_increment來實現自增的主鍵。 但一旦數據實現了分布式存儲，這種方式就不再適用了，原因就在于無法保證多個節點上的主鍵不出現重復。

為了實現分布式數據ID的唯一性保證，應用開發者提出了自己的方案，而大多數方案中都會將ID分段生成，如著名的 snowflake 算法中就同時使用了時間戳、機器號、進程號以及隨機數來保證唯一性。

MongoDB 采用 ObjectId 來表示主鍵的類型，數據庫中每個文檔都擁有一個_id 字段表示主鍵。
_id 的生成規則如下：

圖-ObjecteID

其中包括：

• 4-byte Unix 時間戳
• 3-byte 機器 ID
• 2-byte 進程 ID
• 3-byte 計數器(初始化隨機)

值得一提的是 _id 的生成實質上是由客戶端(Driver)生成的，這樣可以獲得更好的隨機性，同時降低服務端的負載。
當然服務端也會檢測寫入的文檔是否包含_id 字段，如果沒有就生成一個。

三、操作語法

除了文檔模型本身，對于數據的操作命令也是基于JSON/BSON 格式的語法。

比如插入文檔的操作：

db.book.insert(
{
  title: "My first blog post",
  published: new Date(),
  tags: [ "NoSQL", "MongoDB" ],
  type: "Work",
  author : "James",
  viewCount: 25,
  commentCount: 2
}
)

執行文檔查找：

db.book.find({author : "James"})

更新文檔的命令：

db.book.update(
   {"_id" : ObjectId("5c61301c15338f68639e6802")},
   {"$inc": {"viewCount": 3} }
)

刪除文檔的命令：

db.book.remove({"_id":
     ObjectId("5c612b2f15338f68639e67d5")})

在傳統的SQL語法中，可以限定返回的字段，MongoDB可以使用Projection來表示：

db.book.find({"author": "James"}, 
    {"_id": 1, "title": 1, "author": 1})

實現簡單的分頁查詢：

db.book.find({})
    .sort({"viewCount" : -1})
    .skip(10).limit(5)

這種基于BSON/JSON 的語法格式并不復雜，它的表達能力或許要比SQL更加強大。
與 MongoDB 做法類似的還有 ElasticSearch，后者是搜索數據庫的佼佼者。

關于文檔操作與 SQL方式完整的對比，官方的文檔描述得比較詳細：
https://docs.mongodb.com/manual/reference/sql-comparison/

那么，一個有趣的問題是 MongoDB 能不能用 SQL進行查詢？

當然是可以！

但需要注意這些功能并不是 MongoDB 原生自帶的，而需要借由第三方工具平臺實現：

• 客戶端使用SQL，可以使用 mongobooster、studio3t 這樣的工具
• 服務端的話，可以看看 presto 之類的一些平臺..

四、索引

無疑，索引是一個數據庫的關鍵能力，MongoDB 支持非常豐富的索引類型。
利用這些索引，可以實現快速的數據查找，而索引的類型和特性則是針對不同的應用場景設計的。

索引的技術實現依賴于底層的存儲引擎，在當前的版本中 MongoDB 使用 wiredTiger 作為默認的引擎。
在索引的實現上使用了 B+樹的結構，這與其他的傳統數據庫并沒有什么不同。
所以這是個好消息，大部分基于SQL數據庫的一些索引調優技巧在 MongoDB 上仍然是可行的。

圖-B+樹

使用 ensureIndexes 可以為集合聲明一個普通的索引：

db.book.ensureIndex({author: 1})

author后面的數字 1 代表升序，如果是降序則是 -1

實現復合式(compound)的索引，如下：

db.book.ensureIndex({type: 1, published: 1})

只有對于復合式索引時，索引鍵的順序才變得有意義

如果索引的字段是數組類型，該索引就自動成為數組(multikey)索引：

db.book.ensureIndex({tags: 1})

MongoDB 可以在復合索引上包含數組的字段，但最多只能包含一個

索引特性

在聲明索引時，還可以通過一些參數化選項來為索引賦予一定的特性，包括：

• unique=true，表示一個唯一性索引
• expireAfterSeconds=3600，表示這是一個TTL索引，并且數據將在1小時后老化
• sparse=true，表示稀疏的索引，僅索引非空(non-null)字段的文檔
• partialFilterExpression: { rating: { $gt: 5 }，條件式索引，即滿足計算條件的文檔才進行索引

索引分類

除了普通索引之外，MongoDB 支持的類型還包括：

• 哈希(HASH)索引，哈希是另一種快速檢索的數據結構，MongoDB 的 HASH 類型分片鍵會使用哈希索引。
• 地理空間索引，用于支持快速的地理空間查詢，如尋找附近1公里的商家。
• 文本索引，用于支持快速的全文檢索
• 模糊索引(Wildcard Index)，一種基于匹配規則的靈活式索引，在4.2版本開始引入。

索引評估、調優

使用 explain() 命令可以用于查詢計劃分析，進一步評估索引的效果。
如下：

> db.test.explain().find( { a : 5 } )

{
  "queryPlanner" : {
    ...
    "winningPlan" : {
      "stage" : "FETCH",
      "inputStage" : {
        "stage" : "IXSCAN",
        "keyPattern" : {
            "a" : 5
        },
        "indexName" : "a_1",
        "isMultiKey" : false,
        "direction" : "forward",
        "indexBounds" : {"a" : ["[5.0, 5.0]"]}
        }
    }},
   ...
}

從結果 winningPlan 中可以看出執行計劃是否高效，比如：

• 未能命中索引的結果，會顯示COLLSCAN
• 命中索引的結果，使用IXSCAN
• 出現了內存排序，顯示為 SORT

關于 explain 的結果說明，可以進一步參考文檔：

https://docs.mongodb.com/manual/reference/explain-results/index.html

五、集群

在大數據領域常常提到的4V特征中，Volume(數據量大)是首當其沖被提及的。
由于單機垂直擴展能力的局限，水平擴展的方式則顯得更加的靠譜。 MongoDB 自帶了這種能力，可以將數據存儲到多個機器上以提供更大的容量和負載能力。
此外，同時為了保證數據的高可用，MongoDB 采用副本集的方式來實現數據復制。

一個典型的MongoDB集群架構會同時采用分片+副本集的方式，如下圖：

圖-MongoDB 分片集群(Shard Cluster)

架構說明

• 數據分片（Shards）
  分片用于存儲真正的集群數據，可以是一個單獨的 Mongod實例，也可以是一個副本集。 生產環境下Shard一般是一個 Replica Set，以防止該數據片的單點故障。
  對于分片集合(sharded collection)來說，每個分片上都存儲了集合的一部分數據(按照分片鍵切分)，如果集合沒有分片，那么該集合的數據都存儲在數據庫的 Primary Shard中。

• 配置服務器（Config Servers）
  保存集群的元數據（metadata），包含各個Shard的路由規則，配置服務器由一個副本集(ReplicaSet)組成。

• 查詢路由（Query Routers）
  Mongos是 Sharded Cluster 的訪問入口，其本身并不持久化數據 。Mongos啟動后，會從 Config Server 加載元數據，開始提供服務，并將用戶的請求正確路由到對應的Shard。
  Sharding 集群可以部署多個 Mongos 以分擔客戶端請求的壓力。

分片機制

下面的幾個細節，對于理解和應用 MongoDB 的分片機制比較重要，所以有必要提及一下：

1. 數據如何切分

首先，基于分片切分后的數據塊稱為 chunk，一個分片后的集合會包含多個 chunk，每個 chunk 位于哪個分片(Shard) 則記錄在 Config Server(配置服務器)上。
Mongos 在操作分片集合時，會自動根據分片鍵找到對應的 chunk，并向該 chunk 所在的分片發起操作請求。

數據是根據分片策略來進行切分的，而分片策略則由 分片鍵(ShardKey)+分片算法(ShardStrategy)組成。

MongoDB 支持兩種分片算法：

• 范圍分片

如上圖所示，假設集合根據x字段來分片，x的取值范圍為[minKey, maxKey]（x為整型，這里的minKey、maxKey為整型的最小值和最大值），將整個取值范圍劃分為多個chunk，每個chunk（默認配置為64MB）包含其中一小段的數據：
如Chunk1包含x的取值在[minKey, -75)的所有文檔，而Chunk2包含x取值在[-75, 25)之間的所有文檔...

范圍分片能很好的滿足范圍查詢的需求，比如想查詢x的值在[-30, 10]之間的所有文檔，這時 Mongos 直接能將請求路由到 Chunk2，就能查詢出所有符合條件的文檔。 范圍分片的缺點在于，如果 ShardKey 有明顯遞增（或者遞減）趨勢，則新插入的文檔多會分布到同一個chunk，無法擴展寫的能力，比如使用_id作為 ShardKey，而MongoDB自動生成的id高位是時間戳，是持續遞增的。

• 哈希分片

Hash分片是根據用戶的 ShardKey 先計算出hash值（64bit整型），再根據hash值按照范圍分片的策略將文檔分布到不同的 chunk。
由于 hash值的計算是隨機的，因此 Hash 分片具有很好的離散性，可以將數據隨機分發到不同的 chunk 上。 Hash 分片可以充分的擴展寫能力，彌補了范圍分片的不足，但不能高效的服務范圍查詢，所有的范圍查詢要查詢多個 chunk 才能找出滿足條件的文檔。

2. 如何保證均衡

如前面的說明中，數據是分布在不同的 chunk上的，而 chunk 則會分配到不同的分片上，那么如何保證分片上的 數據(chunk) 是均衡的呢？
在真實的場景中，會存在下面兩種情況：

• A. 全預分配，chunk 的數量和 shard 都是預先定義好的，比如 10個shard，存儲1000個chunk，那么每個shard 分別擁有100個chunk。
  此時集群已經是均衡的狀態(這里假定)

• B. 非預分配，這種情況則比較復雜，一般當一個 chunk 太大時會產生分裂(split)，不斷分裂的結果會導致不均衡；或者動態擴容增加分片時，也會出現不均衡的狀態。 這種不均衡的狀態由集群均衡器進行檢測，一旦發現了不均衡則執行 chunk數據的搬遷達到均衡。

MongoDB 的數據均衡器運行于 Primary Config Server(配置服務器的主節點)上，而該節點也同時會控制 Chunk 數據的搬遷流程。

圖-數據自動均衡

對于數據的不均衡是根據兩個分片上的 Chunk 個數差異來判定的，閾值對應表如下：

Number of Chunks	Migration Threshold
Fewer than 20	2
20-79	4
80 and greater	8

MongoDB 的數據遷移對集群性能存在一定影響，這點無法避免，目前的規避手段只能是將均衡窗口對齊到業務閑時段。

3. 應用高可用

應用節點可以通過同時連接多個 Mongos 來實現高可用，如下：

圖- mongos 高可用

當然，連接高可用的功能是由 Driver 實現的。

副本集

副本集又是另一個話題，實質上除了前面架構圖所體現的，副本集可以作為 Shard Cluster 中的一個Shard(片)之外，對于規模較小的業務來說，也可以使用一個單副本集的方式進行部署。
MongoDB 的副本集采取了一主多從的結構，即一個Primary Node + N* Secondary Node的方式，數據從主節點寫入，并復制到多個備節點。

典型的架構如下：

利用副本集，我們可以實現：：

• 數據庫高可用，主節點宕機后，由備節點自動選舉成為新的主節點；
• 讀寫分離，讀請求可以分流到備節點，減輕主節點的單點壓力。

請注意，讀寫分離只能增加集群"讀"的能力，對于寫負載非常高的情況卻無能為力。
對此需求，使用分片集群并增加分片，或者提升數據庫節點的磁盤IO、CPU能力可以取得一定效果。

選舉

MongoDB 副本集通過 Raft 算法來完成主節點的選舉，這個環節在初始化的時候會自動完成，如下面的命令：

config = {
    _id : "my_replica_set",
    members : [
        {_id : 0, host : "rs1.example.net:27017"},
        {_id : 1, host : "rs2.example.net:27017"},
        {_id : 2, host : "rs3.example.net:27017"},
  ]
}
rs.initiate(config)

initiate 命令用于實現副本集的初始化，在選舉完成后，通過 isMaster()命令就可以看到選舉的結果：

> db.isMaster()

{
    "hosts" : [
    "192.168.100.1:27030",
    "192.168.100.2:27030",
    "192.168.100.3:27030"
    ],
    "setName" : "myReplSet",
    "setVersion" : 1,
    "ismaster" : true,
    "secondary" : false,
    "primary" : "192.168.100.1:27030",
    "me" : "192.168.100.1:27030",
    "electionId" : ObjectId("7fffffff0000000000000001"),
    "ok" : 1
}

受 Raft算法的影響，主節點的選舉需要滿足"大多數"原則，可以參考下表：

投票成員數	大多數
1	1
2	2
3	2
4	3
5	3

因此，為了避免出現平票的情況，副本集的部署一般采用是基數個節點，比如3個，正所謂三人行必有我師..

心跳

在高可用的實現機制中，心跳(heartbeat)是非常關鍵的，判斷一個節點是否宕機就取決于這個節點的心跳是否還是正常的。
副本集中的每個節點上都會定時向其他節點發送心跳，以此來感知其他節點的變化，比如是否失效、或者角色發生了變化。
利用心跳，MongoDB 副本集實現了自動故障轉移的功能，如下圖：

默認情況下，節點會每2秒向其他節點發出心跳，這其中包括了主節點。 如果備節點在10秒內沒有收到主節點的響應就會主動發起選舉。
此時新一輪選舉開始，新的主節點會產生并接管原來主節點的業務。 整個過程對于上層是透明的，應用并不需要感知，因為 Mongos 會自動發現這些變化。
如果應用僅僅使用了單個副本集，那么就會由 Driver 層來自動完成處理。

復制

主節點和備節點的數據是通過日志(oplog)復制來實現的，這很類似于 mysql 的 binlog。
在每一個副本集的節點中，都會存在一個名為local.oplog.rs的特殊集合。 當 Primary 上的寫操作完成后，會向該集合中寫入一條oplog，
而 Secondary 則持續從 Primary 拉取新的 oplog 并在本地進行回放以達到同步的目的。

下面，看看一條 oplog 的具體形式：

{
"ts" : Timestamp(1446011584, 2),
"h" : NumberLong("1687359108795812092"),
"v" : 2,
"op" : "i",
"ns" : "test.nosql",
"o" : { "_id" : ObjectId("563062c0b085733f34ab4129"), "name" : "mongodb", "score" : "100" }
}

其中的一些關鍵字段有：

• ts 操作的 optime，該字段不僅僅包含了操作的時間戳(timestamp)，還包含一個自增的計數器值。
• h 操作的全局唯一表示
• v oplog 的版本信息
• op 操作類型，比如 i=insert,u=update..
• ns 操作集合，形式為 database.collection
• o 指具體的操作內容，對于一個 insert 操作，則包含了整個文檔的內容

MongoDB 對于 oplog 的設計是比較仔細的，比如：

• oplog 必須保證有序，通過 optime 來保證。
• oplog 必須包含能夠進行數據回放的完整信息。
• oplog 必須是冪等的，即多次回放同一條日志產生的結果相同。
• oplog 集合是固定大小的，為了避免對空間占用太大，舊的 oplog 記錄會被滾動式的清理。

有興趣的讀者，可以參考官方文檔：

https://docs.mongodb.com/manual/core/replica-set-oplog/index.html

六、事務與一致性

一直以來，"不支持事務" 是 MongoDB 一直被詬病的問題，當然也可以說這是 NoSQL 數據庫的一種權衡(放棄事務，追求高性能、高可擴展)
但實質上，MongoDB 很早就有事務的概念，但是這個事務只能是針對單文檔的，即單個文檔的操作是有原子性保證的。
在4.0 版本之后，MongoDB 開始支持多文檔的事務：

• 4.0 版本支持副本集范圍的多文檔事務。
• 4.2 版本支持跨分片的多文檔事務(基于兩階段提交)。

在事務的隔離性上，MongoDB 支持快照(snapshot)的隔離級別，可以避免臟讀、不可重復讀和幻讀。
盡管有了真正意義上的事務功能，但多文檔事務對于性能有一定的影響，應用應該在充分評估后再做選用。

一致性

一致性是一個復雜的話題，而一致性更多從應用角度上提出的，比如：

向系統寫入一條數據，應該能夠馬上讀到寫入的這個數據。

在分布式架構的CAP理論以及許多延續的觀點中提到，由于網絡分區的存在，要求系統在一致性和可用性之間做出選擇，而不能兩者兼得。

圖 -CAP理論

在 MongoDB 中，這個選擇是可以由開發者來定的。 MongoDB 允許客戶端為其操作設定一定的級別或者偏好，包括：

• read preference
  讀取偏好，可指定讀主節點、讀備節點，或者是優先讀主、優先讀備、取最近的節點
• write concern
  寫關注，指定寫入結果達到什么狀態時才返回，可以為無應答(none)、應答(ack)，或者是大多數節點完成了數據復制等等
• read concern
  讀關注，指定讀取的數據版本處于怎樣的狀態，可以為讀本地、讀大多數節點寫入，或者是線性讀(linearizable)等等。

使用不同的設定將會產生對于C(一致性)、A(可用性)的不同的抉擇，比如：

• 將讀偏好設置為 primary，此時讀寫都在主節點上。 這保證了數據的一致性，但一旦主節點宕機會導致失敗(可用性降低)
• 將讀偏好設置為 secondaryPrefered，此時寫主，優先讀備，可用性提高了，但數據存在延遲(出現不一致)
• 將讀寫關注都設置為 majority(大多數)，一致性提升了，但可用性也同時降低了(節點失效會導致大多數寫失敗)

關于這種權衡的討論會一直存在，而 MongoDB 除了提供多樣化的選擇之外，其主要是通過復制、基于心跳的自動failover等機制來降低系統發生故障時產生的影響，從而提升整體的可用性。

小結

本文主要揭示了 MongoDB 多個方面的細節，同時在使用體驗上也借助 SQL 的概念做了一些對比。
從筆者的角度看，MongoDB 的發展性是很強的，其靈活快速的開發模式、天生自帶分布式等能力彌補了傳統型SQL數據庫的缺陷。當然，目前的 NewSQL 本質上也貌似在以"模仿的方式"彌補這些缺陷。

希望本文的內容對你能有些參考。