這篇文章主要介紹“MongoDB是什么”，在日常操作中，相信很多人在MongoDB是什么問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”MongoDB是什么”的疑惑有所幫助！接下來，請跟著小編一起來學(xué)習(xí)吧！

我們提供的服務(wù)有：成都做網(wǎng)站、成都網(wǎng)站制作、微信公眾號開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認(rèn)證、港閘ssl等。為千余家企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務(wù)，是有科學(xué)管理、有技術(shù)的港閘網(wǎng)站制作公司

一、簡介

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

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

 · 第一層感受是”爽”，使用這個(gè)文檔數(shù)據(jù)庫的特點(diǎn)是幾乎不受什么限制，一方面Json文檔式的結(jié)構(gòu)更容易理解，而無Schema約束也讓DDL管理更加簡單，一切都可以很快速的進(jìn)行。

 · 第二層感受是“酸爽”，這點(diǎn)相信干運(yùn)維或是支撐性工作的兄弟感受會(huì)比較深刻，MongoDB 由于入門體驗(yàn)”太過于友好”，導(dǎo)致一些團(tuán)隊(duì)認(rèn)為用好這個(gè)數(shù)據(jù)庫是個(gè)很簡單的事情，所以開發(fā)兄弟在存量系統(tǒng)上埋一些坑也是正常的事情。所謂交付一時(shí)爽，維護(hù)火葬場.. 當(dāng)然了，這句話可能有些過。但這里的潛臺詞是：與傳統(tǒng)的RDBMS數(shù)據(jù)庫一樣，MongoDB 在使用上也需要認(rèn)真的考量和看護(hù)，不然的話，會(huì)遇到更多的坑。

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

圖-DBEngine排名

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

MongoDB 數(shù)據(jù)庫的一些特性：

 · 面向文檔存儲，基于JSON/BSON 可表示靈活的數(shù)據(jù)結(jié)構(gòu)

 · 動(dòng)態(tài) DDL能力，沒有強(qiáng)Schema約束，支持快速迭代

 · 高性能計(jì)算，提供基于內(nèi)存的快速數(shù)據(jù)查詢

 · 容易擴(kuò)展，利用數(shù)據(jù)分片可以支持海量數(shù)據(jù)存儲

 · 豐富的功能集，支持二級索引、強(qiáng)大的聚合管道功能，為開發(fā)者量身定做的功能，如數(shù)據(jù)自動(dòng)老化、固定集合等等。

 · 跨平臺版本、支持多語言SDK..

假定你是初次了解 MongoDB，下面的內(nèi)容將能幫助你對該數(shù)據(jù)庫技術(shù)的全貌產(chǎn)生一定的了解。

二、基本模型

數(shù)據(jù)結(jié)構(gòu)對于一個(gè)軟件來說是至關(guān)重要的，MongoDB 在概念模型上參考了 SQL數(shù)據(jù)庫，但并非完全相同。

關(guān)于這點(diǎn)，也有人說，MongoDB 是 NoSQL中最像SQL的數(shù)據(jù)庫..

如下表所示：

說明

 · database 數(shù)據(jù)庫，與SQL的數(shù)據(jù)庫(database)概念相同，一個(gè)數(shù)據(jù)庫包含多個(gè)集合(表)

 · collection 集合，相當(dāng)于SQL中的表(table)，一個(gè)集合可以存放多個(gè)文檔(行)。不同之處就在于集合的結(jié)構(gòu)(schema)是動(dòng)態(tài)的，不需要預(yù)先聲明一個(gè)嚴(yán)格的表結(jié)構(gòu)。更重要的是，默認(rèn)情況下 MongoDB 并不會(huì)對寫入的數(shù)據(jù)做任何schema的校驗(yàn)。

 · document 文檔，相當(dāng)于SQL中的行(row)，一個(gè)文檔由多個(gè)字段(列)組成，并采用bson(json)格式表示。

 · field 字段，相當(dāng)于SQL中的列(column)，相比普通column的差別在于field的類型可以更加靈活，比如支持嵌套的文檔、數(shù)組。此外，MongoDB中字段的類型是固定的、區(qū)分大小寫、并且文檔中的字段也是有序的。

另外，SQL 還有一些其他的概念，對應(yīng)關(guān)系如下：

說明

 · id 主鍵，MongoDB 默認(rèn)使用一個(gè)id 字段來保證文檔的唯一性。

 · reference 引用，勉強(qiáng)可以對應(yīng)于 外鍵(foreign key) 的概念，之所以是勉強(qiáng)是因?yàn)?reference 并沒有實(shí)現(xiàn)任何外鍵的約束，而只是由客戶端(driver)自動(dòng)進(jìn)行關(guān)聯(lián)查詢、轉(zhuǎn)換的一個(gè)特殊類型。

 · view 視圖，MongoDB 3.4 開始支持視圖，和 SQL 的視圖沒有什么差異，視圖是基于表/集合之上進(jìn)行動(dòng)態(tài)查詢的一層對象，可以是虛擬的，也可以是物理的(物化視圖)。

 · index 索引，與SQL 的索引相同。

 · $lookup，這是一個(gè)聚合操作符，可以用于實(shí)現(xiàn)類似 SQL-join 連接的功能

 · transaction 事務(wù)，從 MongoDB 4.0 版本開始，提供了對于事務(wù)的支持

 · aggregation 聚合，MongoDB 提供了強(qiáng)大的聚合計(jì)算框架，group by 是其中的一類聚合操作。

BSON 數(shù)據(jù)類型

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

一個(gè)典型的文檔如下：

{

  "_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"

    }

  ]

} 

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

BSON 所支持的數(shù)據(jù)類型包括：

圖-BSON類型

分布式ID

在單機(jī)時(shí)代，大多數(shù)應(yīng)用可以使用數(shù)據(jù)庫自增式ID 來作為主鍵。傳統(tǒng)的 RDBMS 也都支持這種方式，比如 MySQL 可以通過聲明 auto_increment來實(shí)現(xiàn)自增的主鍵。但一旦數(shù)據(jù)實(shí)現(xiàn)了分布式存儲，這種方式就不再適用了，原因就在于無法保證多個(gè)節(jié)點(diǎn)上的主鍵不出現(xiàn)重復(fù)。

為了實(shí)現(xiàn)分布式數(shù)據(jù)ID的唯一性保證，應(yīng)用開發(fā)者提出了自己的方案，而大多數(shù)方案中都會(huì)將ID分段生成，如著名的 snowflake 算法中就同時(shí)使用了時(shí)間戳、機(jī)器號、進(jìn)程號以及隨機(jī)數(shù)來保證唯一性。

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

圖-ObjecteID

其中包括：

 · 4-byte Unix 時(shí)間戳

 · 3-byte 機(jī)器 ID

 · 2-byte 進(jìn)程 ID

 · 3-byte 計(jì)數(shù)器(初始化隨機(jī))

值得一提的是 id 的生成實(shí)質(zhì)上是由客戶端(Driver)生成的，這樣可以獲得更好的隨機(jī)性，同時(shí)降低服務(wù)端的負(fù)載。當(dāng)然服務(wù)端也會(huì)檢測寫入的文檔是否包含id 字段，如果沒有就自動(dòng)生成。

三、操作語法

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

比如插入文檔的操作：

db.book.insert(

{

  title: "My first blog post",

  published: new Date(),

  tags: [ "NoSQL", "MongoDB" ],

  type: "Work",

  author : "James",

  viewCount: 25,

  commentCount: 2

}

) 

執(zhí)行文檔查找：

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

更新文檔的命令：

db.book.update(

   {"_id" : ObjectId("5c61301c15338f68639e6802")},

   {"$inc": {"viewCount": 3} }

) 

刪除文檔的命令：

db.book.remove({"_id":

     ObjectId("5c612b2f15338f68639e67d5")}) 

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

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

    {"_id": 1, "title": 1, "author": 1}) 

實(shí)現(xiàn)簡單的分頁查詢：

db.book.find({})

    .sort({"viewCount" : -1})

    .skip(10).limit(5) 

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

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

那么，一個(gè)有趣的問題是 MongoDB 能不能用 SQL進(jìn)行查詢？

當(dāng)然是可以！

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

客戶端使用SQL，可以使用 mongobooster、studio3t 這樣的工具

服務(wù)端的話，可以看看 presto 之類的一些平臺..

四、索引

無疑，索引是一個(gè)數(shù)據(jù)庫的關(guān)鍵能力，MongoDB 支持非常豐富的索引類型。利用這些索引，可以實(shí)現(xiàn)快速的數(shù)據(jù)查找，而索引的類型和特性則是針對不同的應(yīng)用場景設(shè)計(jì)的。

索引的技術(shù)實(shí)現(xiàn)依賴于底層的存儲引擎，在當(dāng)前的版本中 MongoDB 使用 wiredTiger 作為默認(rèn)的引擎。在索引的實(shí)現(xiàn)上使用了 B+樹的結(jié)構(gòu)，這與其他的傳統(tǒng)數(shù)據(jù)庫并沒有什么不同。所以這是個(gè)好消息，大部分基于SQL數(shù)據(jù)庫的一些索引調(diào)優(yōu)技巧在 MongoDB 上仍然是可行的。

圖-B+樹

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

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

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

實(shí)現(xiàn)復(fù)合式(compound)的索引，如下：

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

只有對于復(fù)合式索引時(shí)，索引鍵的順序才變得有意義

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

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

MongoDB 可以在復(fù)合索引上包含數(shù)組的字段，但最多只能包含一個(gè)

索引特性

在聲明索引時(shí)，還可以通過一些參數(shù)化選項(xiàng)來為索引賦予一定的特性，包括：

 · unique=true，表示一個(gè)唯一性索引

 · expireAfterSeconds=3600，表示這是一個(gè)TTL索引，并且數(shù)據(jù)將在1小時(shí)后老化

 · sparse=true，表示稀疏的索引，僅索引非空(non-null)字段的文檔

 · partialFilterExpression: { rating: { $gt: 5 }，條件式索引，即滿足計(jì)算條件的文檔才進(jìn)行索引

索引分類

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

 · 哈希(HASH)索引，哈希是另一種快速檢索的數(shù)據(jù)結(jié)構(gòu)，MongoDB 的 HASH 類型分片鍵會(huì)使用哈希索引。

 · 地理空間索引，用于支持快速的地理空間查詢，如尋找附近1公里的商家。

 · 文本索引，用于支持快速的全文檢索

 · 模糊索引(Wildcard Index)，一種基于匹配規(guī)則的靈活式索引，在4.2版本開始引入。

索引評估、調(diào)優(yōu)

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

> 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]"]}

        }

    }},

   ...

} 

從結(jié)果 winningPlan 中可以看出執(zhí)行計(jì)劃是否高效，比如：

 · 未能命中索引的結(jié)果，會(huì)顯示COLLSCAN

 · 命中索引的結(jié)果，使用IXSCAN

 · 出現(xiàn)了內(nèi)存排序，顯示為 SORT

關(guān)于 explain 的結(jié)果說明，可以進(jìn)一步參考文檔：

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

五、集群

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

一個(gè)典型的MongoDB集群架構(gòu)會(huì)同時(shí)采用分片+副本集的方式，如下圖：

圖-MongoDB 分片集群(Shard Cluster)

架構(gòu)說明

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

 · 配置服務(wù)器（Config Servers） 保存集群的元數(shù)據(jù)（metadata），包含各個(gè)Shard的路由規(guī)則，配置服務(wù)器由一個(gè)副本集(ReplicaSet)組成。

 · 查詢路由（Query Routers） Mongos是 Sharded Cluster 的訪問入口，其本身并不持久化數(shù)據(jù) 。Mongos啟動(dòng)后，會(huì)從 Config Server 加載元數(shù)據(jù)，開始提供服務(wù)，并將用戶的請求正確路由到對應(yīng)的Shard。Sharding 集群可以部署多個(gè) Mongos 以分擔(dān)客戶端請求的壓力。

分片機(jī)制

下面的幾個(gè)細(xì)節(jié)，對于理解和應(yīng)用 MongoDB 的分片機(jī)制比較重要，所以有必要提及一下：

1. 數(shù)據(jù)如何切分

首先，基于分片切分后的數(shù)據(jù)塊稱為 chunk，一個(gè)分片后的集合會(huì)包含多個(gè) chunk，每個(gè) chunk 位于哪個(gè)分片(Shard) 則記錄在 Config Server(配置服務(wù)器)上。Mongos 在操作分片集合時(shí)，會(huì)自動(dòng)根據(jù)分片鍵找到對應(yīng)的 chunk，并向該 chunk 所在的分片發(fā)起操作請求。

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

MongoDB 支持兩種分片算法：

 · 范圍分片

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

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

 · 哈希分片

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

2. 如何保證均衡

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

 · A. 全預(yù)分配，chunk 的數(shù)量和 shard 都是預(yù)先定義好的，比如 10個(gè)shard，存儲1000個(gè)chunk，那么每個(gè)shard 分別擁有100個(gè)chunk。此時(shí)集群已經(jīng)是均衡的狀態(tài)(這里假定)

 · B. 非預(yù)分配，這種情況則比較復(fù)雜，一般當(dāng)一個(gè) chunk 太大時(shí)會(huì)產(chǎn)生分裂(split)，不斷分裂的結(jié)果會(huì)導(dǎo)致不均衡；或者動(dòng)態(tài)擴(kuò)容增加分片時(shí)，也會(huì)出現(xiàn)不均衡的狀態(tài)。這種不均衡的狀態(tài)由集群均衡器進(jìn)行檢測，一旦發(fā)現(xiàn)了不均衡則執(zhí)行 chunk數(shù)據(jù)的搬遷達(dá)到均衡。

MongoDB 的數(shù)據(jù)均衡器運(yùn)行于 Primary Config Server（配置服務(wù)器的主節(jié)點(diǎn)）上，而該節(jié)點(diǎn)也同時(shí)會(huì)控制 Chunk 數(shù)據(jù)的搬遷流程。

圖-數(shù)據(jù)自動(dòng)均衡

對于數(shù)據(jù)的不均衡是根據(jù)兩個(gè)分片上的 Chunk 個(gè)數(shù)差異來判定的，閾值對應(yīng)表如下：

MongoDB 的數(shù)據(jù)遷移對集群性能存在一定影響，這點(diǎn)無法避免，目前的規(guī)避手段只能是將均衡窗口對齊到業(yè)務(wù)閑時(shí)段。

https://docs.mongodb.com/manual/tutorial/manage-sharded-cluster-balancer/#sharding-schedule-balancing-window

3. 應(yīng)用高可用

應(yīng)用節(jié)點(diǎn)可以通過同時(shí)連接多個(gè) Mongos 來實(shí)現(xiàn)高可用，如下：

圖- mongos 高可用

當(dāng)然，連接高可用的功能是由 Driver 實(shí)現(xiàn)的。

副本集

副本集又是另一個(gè)話題，實(shí)質(zhì)上除了前面架構(gòu)圖所體現(xiàn)的，副本集可以作為 Shard Cluster 中的一個(gè)Shard(片)之外，對于規(guī)模較小的業(yè)務(wù)來說，也可以使用一個(gè)單副本集的方式進(jìn)行部署。MongoDB 的副本集采取了一主多從的結(jié)構(gòu)，即一個(gè) Primary Node + N* Secondary Node的方式，數(shù)據(jù)從主節(jié)點(diǎn)寫入，并復(fù)制到多個(gè)備節(jié)點(diǎn)。

典型的架構(gòu)如下：

 · 利用副本集，我們可以實(shí)現(xiàn)：：

 · 數(shù)據(jù)庫高可用，主節(jié)點(diǎn)宕機(jī)后，由備節(jié)點(diǎn)自動(dòng)選舉成為新的主節(jié)點(diǎn)。

讀寫分離，讀請求可以分流到備節(jié)點(diǎn)，減輕主節(jié)點(diǎn)的單點(diǎn)壓力。

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

選舉

MongoDB 副本集通過 Raft 算法來完成主節(jié)點(diǎn)的選舉，這個(gè)環(huán)節(jié)在初始化的時(shí)候會(huì)自動(dòng)完成，如下面的命令：

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 命令用于實(shí)現(xiàn)副本集的初始化，在選舉完成后，通過 isMaster()命令就可以看到選舉的結(jié)果：

> 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算法的影響，主節(jié)點(diǎn)的選舉需要滿足”大多數(shù)”原則，可以參考下表：

因此，為了避免出現(xiàn)平票的情況，副本集的部署一般采用是基數(shù)個(gè)節(jié)點(diǎn)，比如3個(gè)，正所謂三人行必有我?guī)?.

心跳

在高可用的實(shí)現(xiàn)機(jī)制中，心跳(heartbeat)是非常關(guān)鍵的，判斷一個(gè)節(jié)點(diǎn)是否宕機(jī)就取決于這個(gè)節(jié)點(diǎn)的心跳是否還是正常的。副本集中的每個(gè)節(jié)點(diǎn)上都會(huì)定時(shí)向其他節(jié)點(diǎn)發(fā)送心跳，以此來感知其他節(jié)點(diǎn)的變化，比如是否失效、或者角色發(fā)生了變化。利用心跳，MongoDB 副本集實(shí)現(xiàn)了自動(dòng)故障轉(zhuǎn)移的功能，如下圖：

默認(rèn)情況下，節(jié)點(diǎn)會(huì)每2秒向其他節(jié)點(diǎn)發(fā)出心跳，這其中包括了主節(jié)點(diǎn)。如果備節(jié)點(diǎn)在10秒內(nèi)沒有收到主節(jié)點(diǎn)的響應(yīng)就會(huì)主動(dòng)發(fā)起選舉。此時(shí)新一輪選舉開始，新的主節(jié)點(diǎn)會(huì)產(chǎn)生并接管原來主節(jié)點(diǎn)的業(yè)務(wù)。整個(gè)過程對于上層是透明的，應(yīng)用并不需要感知，因?yàn)?Mongos 會(huì)自動(dòng)發(fā)現(xiàn)這些變化。如果應(yīng)用僅僅使用了單個(gè)副本集，那么就會(huì)由 Driver 層來自動(dòng)完成處理。

復(fù)制

主節(jié)點(diǎn)和備節(jié)點(diǎn)的數(shù)據(jù)是通過日志(oplog)復(fù)制來實(shí)現(xiàn)的，這很類似于 mysql 的 binlog。在每一個(gè)副本集的節(jié)點(diǎn)中，都會(huì)存在一個(gè)名為local.oplog.rs的特殊集合。當(dāng) Primary 上的寫操作完成后，會(huì)向該集合中寫入一條oplog， 而 Secondary 則持續(xù)從 Primary 拉取新的 oplog 并在本地進(jìn)行回放以達(dá)到同步的目的。

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

{

"ts" : Timestamp(1446011584, 2),

"h" : NumberLong("1687359108795812092"),

"v" : 2,

"op" : "i",

"ns" : "test.nosql",

"o" : { "_id" : ObjectId("563062c0b085733f34ab4129"), "name" : "mongodb", "score" : "100" }

}

其中的一些關(guān)鍵字段有：

 · ts 操作的 optime，該字段不僅僅包含了操作的時(shí)間戳(timestamp)，還包含一個(gè)自增的計(jì)數(shù)器值。

 · h 操作的全局唯一表示

 · v oplog 的版本信息

 · op 操作類型，比如 i=insert,u=update..

 · ns 操作集合，形式為 database.collection

 · o 指具體的操作內(nèi)容，對于一個(gè) insert 操作，則包含了整個(gè)文檔的內(nèi)容

 · MongoDB 對于 oplog 的設(shè)計(jì)是比較仔細(xì)的，比如：

 · oplog 必須保證有序，通過 optime 來保證。

 · oplog 必須包含能夠進(jìn)行數(shù)據(jù)回放的完整信息。

 · oplog 必須是冪等的，即多次回放同一條日志產(chǎn)生的結(jié)果相同。

 · oplog 集合是固定大小的，為了避免對空間占用太大，舊的 oplog 記錄會(huì)被滾動(dòng)式的清理。

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

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

六、事務(wù)與一致性

一直以來，“不支持事務(wù)” 是 MongoDB 一直被詬病的問題，當(dāng)然也可以說這是 NoSQL 數(shù)據(jù)庫的一種權(quán)衡(放棄事務(wù)，追求高性能、高可擴(kuò)展) 但實(shí)質(zhì)上，MongoDB 很早就有事務(wù)的概念，但是這個(gè)事務(wù)只能是針對單文檔的，即單個(gè)文檔的操作是有原子性保證的。在4.0 版本之后，MongoDB 開始支持多文檔的事務(wù)：

 · 4.0 版本支持副本集范圍的多文檔事務(wù)。

 · 4.2 版本支持跨分片的多文檔事務(wù)(基于兩階段提交)。

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

一致性

一致性是一個(gè)復(fù)雜的話題，而一致性更多從應(yīng)用角度上提出的，比如：

向系統(tǒng)寫入一條數(shù)據(jù)，應(yīng)該能夠馬上讀到寫入的這個(gè)數(shù)據(jù)。

在分布式架構(gòu)的CAP理論以及許多延續(xù)的觀點(diǎn)中提到，由于網(wǎng)絡(luò)分區(qū)的存在，要求系統(tǒng)在一致性和可用性之間做出選擇，而不能兩者兼得。

圖 -CAP理論

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

 · read preference 讀取偏好，可指定讀主節(jié)點(diǎn)、讀備節(jié)點(diǎn)，或者是優(yōu)先讀主、優(yōu)先讀備、取最近的節(jié)點(diǎn)

 · write concern 寫關(guān)注，指定寫入結(jié)果達(dá)到什么狀態(tài)時(shí)才返回，可以為無應(yīng)答(none)、應(yīng)答(ack)，或者是大多數(shù)節(jié)點(diǎn)完成了數(shù)據(jù)復(fù)制等等

 · read concern 讀關(guān)注，指定讀取的數(shù)據(jù)版本處于怎樣的狀態(tài)，可以為讀本地、讀大多數(shù)節(jié)點(diǎn)寫入，或者是線性讀(linearizable)等等。

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

 · 將讀偏好設(shè)置為 primary，此時(shí)讀寫都在主節(jié)點(diǎn)上。這保證了數(shù)據(jù)的一致性，但一旦主節(jié)點(diǎn)宕機(jī)會(huì)導(dǎo)致失敗(可用性降低)

 · 將讀偏好設(shè)置為 secondaryPrefered，此時(shí)寫主，優(yōu)先讀備，可用性提高了，但數(shù)據(jù)存在延遲(出現(xiàn)不一致)

 · 將讀寫關(guān)注都設(shè)置為 majority(大多數(shù))，一致性提升了，但可用性也同時(shí)降低了(節(jié)點(diǎn)失效會(huì)導(dǎo)致大多數(shù)寫失敗)

關(guān)于這種權(quán)衡的討論會(huì)一直存在，而 MongoDB 除了提供多樣化的選擇之外，其主要是通過復(fù)制、基于心跳的自動(dòng)failover等機(jī)制來降低系統(tǒng)發(fā)生故障時(shí)產(chǎn)生的影響，從而提升整體的可用性。

到此，關(guān)于“MongoDB是什么”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識，請繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)砀鄬?shí)用的文章！