MongoDB 走馬觀花(全面解讀篇)

MongoDB 走馬觀花(全面解讀篇)

Java高級互聯網架構 2019-10-15 16:04:11

目錄

• 一、簡介
• 二、基本模型
• BSON 數據類型
• 分佈式ID
• 三、操作語法
• 四、索引
• 索引特性
• 索引分類
• 索引評估、調優
• 五、集羣
• 分片機制
• 副本集
• 六、事務與一致性
• 一致性
• 小結

一、簡介

MongoDB 是一款流行的開源文檔型數據庫，從它的命名來看，確實是有一定野心的。

MongoDB 的原名一開始來自於 英文單詞"Humongous", 中文含義是指"龐大"，即命名者的意圖是可以處理大規模的數據。

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

• 第一層感受是"爽"，使用這個文檔數據庫的特點是幾乎不受什麼限制，一方面Json文檔式的結構更容易理解，而無Schema約束也讓DDL管理更加簡單，一切都可以很快速的進行。
• 第二層感受是"酸爽"，這點相信幹運維或是支撐性工作的兄弟感受會比較深刻，MongoDB 由於入門體驗"太過於友好"，導致一些團隊認爲用好這個數據庫是個很簡單的事情，所以開發兄弟在存量系統上埋一些坑也是正常的事情。
• 所謂交付一時爽，維護火葬場.. 當然了，這句話可能有些過。 但這裏的潛臺詞是：與傳統的RDBMS數據庫一樣，MongoDB 在使用上也需要認真的考量和看護，不然的化，會遇到更多的坑。

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

 

圖-DBEngine排名

在全部的排名中，MongoDB 長期排在第5位(文檔數據庫排名第1位)，同時也是最受歡迎的 NoSQL 數據庫。

另外，MongoDB 的社區一直比較活躍，加上商業上的驅動(MongoDB於2017年在納斯達克上市)，這些因素都推動了該開源數據庫的發展。

MongoDB 數據庫的一些特性：

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

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

二、基本模型

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

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

如下表所示：

 

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

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

 

• _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，後者是搜索數據庫的佼佼者。

那麼，一個有趣的問題是 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 個數差異來判定的，閾值對應表如下：

 

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算法的影響，主節點的選舉需要滿足"大多數"原則，可以參考下表：

 

因此，爲了避免出現平票的情況，副本集的部署一般採用是基數個節點，比如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 本質上也貌似在以"模仿的方式"彌補這些缺陷。

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

作者： 美碼師(zale)

出處： http://www.cnblogs.com/littleatp/, 如果喜歡我的文章