了解 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 本質上也貌似在以"模仿的方式"彌補這些缺陷。

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

posted @ 2019-10-15 07:40  美碼師  閱讀(...)  評論(... 編輯 收藏
ag二分彩