作者 | 吳守陽

審校 | 重樓

引言

在數據庫技術日新月異的今天，MongoDB作為領先的NoSQL數據庫之一，持續地推出新版本以滿足不斷變化的企業需求和技術挑戰。從MongoDB 4.4至7.0，每一版都融入了創新特性，旨在提升性能、擴展性、安全性和易用性，同時也反映了行業趨勢和用戶反饋。

本文旨在全面剖析這些版本中的關鍵新特性，不僅是為了記錄技術演進的歷史，更是為了賦能數據庫管理員、開發者和架構師，使他們能夠充分理解并利用這些新功能，從而優化數據管理和應用性能。

速覽

本文將從以下方面介紹數據庫 MongoDB 4.4、5.0、6.0、7.0版本：

1.MongoDB4.4 新特性

• 隱藏索引（Hidden Indexes）
• 重定義分片鍵（Refinable Shard Keys）
• 復合哈希分片鍵（Compound Hashed Shard Keys）
• 對沖讀（Hedged Reads）
• 同步建索引（Simultaneous Indexing）
• 復制讀請求（Mirrored Reads）
• 基于時間保留Oplog（Time-Based Oplog Retention）

2.MongoDB5.0 新特性

• 原生時間序列平臺
• 在線數據重新分片
• Write Concern默認Majority級別
• 連接管理優化
• 長時間運行的快照查詢
• 新版MongoDB Shell
• 可恢復的索引創建任務

3.MongoDB6.0 新特性

• 可查詢加密（Queryable Encryption）
• 集群同步（Cluster-to-Cluster Sync）
• 時序集合（Time Series Collection）
• 變更流（Change Streams）
• 聚合（Aggregation）
• 查詢（Query）
• 彈性
• 安全性

4.MongoDB7.0 版本新特性

• 支持分片元數據一致性校驗
• 支持采樣查詢與分析分片鍵（analyzeShardKey）
• 自動合并（AutoMerger）
• 分片（Sharding）
• 安全性
• 聚合（Aggregation）
• 時序集合（Time-Series Collection）
• 其他優化

目的

• 技術發展洞察：通過梳理MongoDB新特性，讀者可以洞察數據庫技術的前沿趨勢，了解數據庫管理系統如何適應大數據、云計算、AI等領域的挑戰。
• 決策支持：對于正在考慮數據庫升級或技術選型的團隊，了解各版本的特性可以幫助他們作出更明智的決策，評估新功能對現有架構和業務流程的潛在影響。
• 技能提升：對MongoDB新特性的深入學習，有助于讀者掌握數據庫管理的最佳實踐，提升在數據庫優化、查詢效率和數據安全等方面的技能。
• 社區貢獻：鼓勵讀者參與到MongoDB社區中，分享使用經驗，提出改進建議，甚至貢獻代碼，共同推動MongoDB及其生態的發展。

讀者獲益

• 技術領先：掌握MongoDB最新功能，保持技術競爭力，為項目引入前沿的數據庫管理技術。
• 性能優化：了解如何利用新特性提升查詢速度、數據存儲效率和系統穩定性，降低運營成本。
• 安全性增強：學習最新的安全措施，如可查詢加密，保護敏感數據免受未授權訪問和泄露。
• 擴展能力提升：掌握分片、復制和集群同步等技術，構建高度可擴展和可用的數據庫系統。
• 開發效率：利用新版本的改進，如優化的Shell和更豐富的聚合框架，提高開發和維護數據庫應用的速度。

MongoDB的每個版本發布新特性都是為了響應不斷變化的市場需求、技術進步以及用戶反饋，旨在提高數據庫的性能、可靠性、安全性、易用性和功能豐富度。以下是一些關鍵版本及其新特性的背景和帶來的好處：

一、MongoDB 4.4版本新特性

隱藏索引（Hidden Indexes）

MongoDB 4.4版本中新增了隱藏索引，眾所周知數據庫維護太多的索引會導致寫性能下降，但是往往業務上的復雜性導致了運維人員不敢輕易去刪除一個潛在的低效率索引，擔心誤刪除會帶來業務性能的抖動，而重建索引的代價也非常大。

為了解決上述問題。該功能支持通過collMod命令隱藏現有的索引，保證該索引在后續的查詢中不會被使用。在觀察一段時間后，確定業務沒有異常即可以放心刪除該索引。

db.runCommand( {
 collMod: 'testcoll',
 index: {
 keyPattern: 'key_1',
 hidden: false
 }
} )

重定義分片鍵（Refinable Shard Keys）

MongoDB4.4版本中，你可以通過refineCollectionShardKey命令給現有的Shard Key增加一個或多個Suffix Field來改善現有的文檔在Chunk上的分布問題。例如在訂單業務場景中，通過refineCollectionShardKey命令把Shard key更改為{customer_id:1, order_id:1}，即可避免單一分片上的訪問熱點問題。

并且，refineCollectionShardKey命令的性能開銷非常低，僅更改Config Server節點上的元數據，不需要任何形式的數據遷移，數據的打散仍然在后續正常的Chunk自動分裂和遷移的流程中逐步進行。

此外，Shard Key需要有對應的Index來支撐，因此refineCollectionShardKey命令要求提前創建新Shard Key所對應的Index。

由于并不是所有的文檔都存在新增的Suffix Field，因此在4.4版本中隱式支持了Missing Shard Key功能，即新插入的文檔可以不包含指定的Shard Key Field。但是由于很容易產生Jumbo Chunk，因此并不建議使用。

db.adminCommand( {
 refineCollectionShardKey: "test.orders",
 key: { customer_id: 1, order_id: 1 }
} )

復合哈希分片鍵（Compound Hashed Shard Keys）

在最新的4.4版本中加入了復合哈希索引，即你可以在復合索引中指定單個哈希字段，位置不限，可以作為前綴，也可以作為后綴，進而也就提供了對復合哈希片鍵的支持。

sh.shardCollection(
 "examples.compoundHashedCollection",
 { "region_id" : 1, "city_id": 1, field1" : "hashed" }
)
sh.shardCollection(
 "examples.compoundHashedCollection",
 { "_id" : "hashed", "fieldA" : 1}
)

對沖讀（Hedged Reads）

頁面的響應速度和經濟損失直接掛鉤。Google有一個研究報告表明，如果網頁的加載時間超過3秒，用戶的跳出率會增加50%。針對這個問題，MongoDB在4.4版本中提供了Hedged Reads功能，即在分片集群場景下，mongos節點會把一個讀請求同時發送給某個分片的兩個副本集成員，然后選擇最快的返回結果回復客戶端，來減少業務上的P95（指過去十秒內95%的請求延遲均在規定范圍內）和P99延遲（指過去十秒內99%的請求延遲均在規定范圍內）。

Hedged Reads功能作為Read Preference參數的一部分來提供，因此可以在Operation粒度上進行配置。當Read Preference指定為nearest時，系統默認啟用Hedged Reads功能；當指定為primary時，不支持Hedged Reads功能；當指定為其他時，需要顯式地指定hedgeOptions才可以啟用Hedged Reads。如下所示：

db.collection.find({ }).readPref(
 "secondary", // mode
 [ { "datacenter": "B" }, { } ], // tag set
 { enabled: true } // hedge options
)

此外，Hedged Reads也需要mongos開啟支持，配置readHedgingMode參數為on，使mongos開啟該功能支持。

參考代碼：

db.adminCommand( { setParameter: 1, readHedgingMode: "on" } )

同步建索引（Simultaneous Indexing）

4.4 之前的版本中，索引的創建需要在主庫中完成之后，才會到備庫上執行。備庫上的創建動作在不同的版本中，因為創建機制和創建方式的不同，對備庫Oplog的影響也大有不同。

但即使在4.2版本中統一了前后臺索引創建機制，使用了相當細粒度的加鎖機制（只在索引創建的開始和結束階段對集合加獨占鎖），也會因為索引創建本身的CPU、IO性能開銷導致復制延遲，或是因為一些特殊操作，例如使用collMod命令修改集合元信息，而導致Oplog的應用阻塞，甚至會因為主庫歷史Oplog被覆蓋而進入Recovering狀態。

在4.4版本中，主庫和備庫上的索引創建操作是同時進行的，這樣可以大幅減少上述情況所帶來的主備延遲，即使在索引創建過程中，也可以保證備庫訪問到最新的數據。

此外，新的索引創建機制規定，只有在大多數具備投票權限節點返回成功后，索引才會真正生效。所以，也可以減輕在讀寫分離場景下因為索引不同而導致的性能差異。

復制讀請求（Mirrored Reads）

在4.4版本中，MongoDB針對上述問題實現了Mirrored Reads功能，即主節點會按一定的比例把讀流量復制到備庫上執行，來幫助備庫預熱緩存。這是一個非阻塞執行（Fire and Forgot）的行為，不會對主庫的性能產生任何實質性的影響，但是備庫負載會有一定程度的上升。

流量復制的比例是可動態配置的，通過mirrorReads參數設置，默認復制1%的流量。

db.adminCommand( { setParameter: 1, mirrorReads: { samplingRate: 0.10 } } )

此外，還可以通過db.serverStatus( { mirroredReads: 1 } )來查看Mirrored Reads相關的統計信息，如下所示：

SECONDARY> db.serverStatus( { mirroredReads: 1 } ).mirroredReads
{ "seen" : NumberLong(2), "sent" : NumberLong(0) }

基于時間保留Oplog（Time-Based Oplog Retention）

在4.4版本中，MongoDB支持通過storage.oplogMinRetentionHours參數定義需要保留的Oplog時長，也可以通過replSetResizeOplog命令在線修改這個值。參考代碼如下：

// First, show current configured value
db.getSiblingDB("admin").serverStatus().oplogTruncation.oplogMinRetentionHours
// Modify
db.adminCommand({
 "replSetResizeOplog" : 1,
 "minRetentionHours" : 2
})

二、MongoDB 5.0版本新特性

原生時間序列平臺

1. 時間序列集合：MongoDB 5.0允許創建高度優化和壓縮的時間序列集合，自動存儲帶有時間戳的數據，減少存儲需求和I/O操作，提升性能和可擴展性。
2. 自動管理：時間序列集合能夠自動處理數據的動態時間分區，適應不同的采集頻率，并能處理無序到達的測量值。
3. 簡化開發：時間序列集合的創建和管理簡化了開發流程，使開發者能夠快速構建針對時間序列特性的高性能應用模型。
4. 集成與流處理：通過MongoDB Connector for Apache Kafka，可以直接從Kafka主題中創建時間序列集合，實現數據的實時處理、聚合和寫入。
5. 智能索引與查詢：時間序列集合自動創建時間排序的聚集索引，減少查詢延遲，同時擴展了查詢API，支持窗口函數和時間運算符，如移動平均、累積總和、指數移動平均等。
6. 統一的數據平臺：時間序列集合可以與常規MongoDB集合共存于同一數據庫中，無需使用專用的時間序列數據庫，降低了維護多個數據庫的成本和復雜性。

創建時間序列數據集合的命令示例：

db.createCollection("collection_name",{ timeseries: { timeField: "timestamp" } } )

在線數據重新分片

Write Concern默認Majority級別

從MongoDB 5.0開始，Write Concern默認級別為majority，僅當寫入操作被應用到Primary節點（主節點）且被持久化到大多數副本節點的日志中的時候，才會提交并返回成功，“開箱即用”地提供了更強的數據可靠性保障。

說明

Write Concern是完全可調的，你可以自定義配置Write Concern，以平衡應用程序對數據庫性能和數據持久性的要求

連接管理優化

默認情況下，一個客戶端連接對應后端MongoDB服務器上的一個線程（net.serviceExecutor配置為synchronous）。創建、切換和銷毀線程都是消耗較大的操作，當連接數過多時，線程會占用MongoDB服務器較多的資源。

連接數較多或創建連接失控的情況稱為“連接風暴”，產生該情況的原因可能是多方面的，且經常是在服務已經受到影響的情況下發生。

針對這些情況，MongoDB 5.0采取了以下措施：

• 限制在任何時候驅動程序嘗試創建的連接數量，以簡單有效的方式防止數據庫服務器過載。
• 減少驅動程序監控連接池時的檢查頻率，給無響應或過載的服務器節點一個緩沖和恢復的機會。
• 驅動程序將工作負載導向具有最健康連接池的更快的服務器，而不是從可用的服務器中隨機選擇。

以上措施，加上之前版本在mongos查詢路由層的改進，進一步提升了MongoDB承受高并發負載的能力。

長時間運行的快照查詢

長時間運行的快照查詢（Long-Running Snapshot Queries）增加了應用程序的通用性和彈性。你可以通過該功能運行默認時間為5分鐘的查詢（或將其調整為自定義持續時間），同時保持與實時事務性數據庫一致的快照隔離，也可以在Secondary節點（從節點）上進行快照查詢，從而在單個集群中運行不同的工作負載，并將其擴展到不同的分片上。

MongoDB通過底層存儲引擎中一個名為Durable history的項目實現了長期運行的快照查詢，該項目早在MongoDB 4.4中就已實現。Durable history將存儲自查詢開始以來所有變化的字段值的快照。通過使用Durable history，查詢可以保持快照隔離，即使在數據發生變化的情況下，Durable history也有助于降低存儲引擎的緩存壓力，使得業務可以在高寫入負載的場景下實現更高的查詢吞吐量。

新版MongoDB Shell

為了提供更好的用戶體驗，MongoDB 5.0從頭開始重新設計了MongoDB Shell（mongosh），以提供一個更現代化的命令行體驗，以及增強可用性的功能和強大的腳本環境。新版MongoDB Shell已經成為MongoDB平臺的默認Shell。新版MongoDB Shell引入了語法高亮、智能自動完成、上下文幫助和有用的錯誤信息，為你創造一個直觀、互動的體驗。

可恢復的索引創建任務

MongoDB 5.0支持將正在進行中的索引創建任務在節點重新啟動后自動恢復至原來的位置，減少計劃中維護動作對業務的影響。例如：重新啟動或升級數據庫節點時，你不需要擔心當前正在進行的大集合索引創建任務失效。

三、MongoDB 6.0版本新特性

可查詢加密（Queryable Encryption）

可查詢加密功能目前是預覽（Preview）版本，不建議直接在生產環境使用。預覽（Preview）版本的更多信息，請參見MongoDB Releases Queryable Encryption Preview。

MongoDB 6.0新推出可查詢加密功能，允許用戶從客戶端加密敏感數據，將其作為完全隨機的加密數據存儲在數據庫服務器端，并對加密數據進行豐富的查詢。

可查詢加密只允許在客戶端查看敏感數據的明文，在查詢到達服務器端時會同時包含從KMS獲取的加密密鑰，然后在服務器端以密文進行查詢并返回，最后在客戶端利用密鑰解密后以明文呈現。

可查詢加密的特點如下：

• 從客戶端加密敏感數據，只有客戶端擁有加密密鑰。
• 數據在整個生命周期（傳輸、存儲、使用、審計和備份）中都是加密的。
• 客戶端可以直接對加密數據進行豐富的查詢（包括等值匹配、范圍、前后綴或子字符串等查詢類型）。
• 強大的數據隱私保護能力，只有能訪問客戶端的應用程序和加密密鑰的授權用戶才能看到明文數據。
• 更輕量化的應用程序開發，涉及敏感數據的開發者無需考慮太多安全、合規的事情，數據庫會直接提供綜合加密解決方案。
• 降低敏感數據上云的安全顧慮。

集群同步（Cluster-to-Cluster Sync）

無論是數據的同構同步（Mongo-to-Mongo）還是異構同步（Others-to-Mongo & Mongo-to-Others）都是MongoDB生態中的一部分，開源MongoDB推出了多種工具，比如mongoimport、mongoexport、mongodump和mongorestore等，但是這些工具并沒有很好的規劃數據同步。

MongoDB 6.0推出了新的同步工具mongosync，它能支持跨實例數據同步（兩個MongoDB實例間連續且單向的數據同步）。用戶還可以實時控制和監控整個同步過程，按需啟動、停止、恢復甚至反轉同步。

時序集合（Time Series Collection）

分別從索引、查詢以及排序多個方面增強了時序集合。

• 引入二級和復合索引，以改善讀取性能。
• 引入針對時空數據的地理位置索引（Geo-Indexing），將地理信息添加到時序數據，有助于更好地分析涉及距離和位置的場景。場景示例：跟蹤夏日冷鏈運輸車的溫度變化情況、監測特定航線上的貨運船燃料消耗。
• 優化對時序數據的last point查詢，不再需要掃描整個集合后才能查詢到最后一個數據點。
• 優化對時序數據的排序，通過時間以及元數據字段上的聚簇索引（Clustered Index）和二級索引（Secondary Index）更高效地完成排序操作。

變更流（Change Streams）

• 支持查看變更前的視圖（Pre-image）。說明
  MongoDB 6.0之前的版本僅支持查看變更后的視圖，從MongoDB 6.0版本開始，支持查看變更前后的視圖。前后視圖的更多信息，請參見Change Streams with Document Pre- and Post-Images。
• 支持create、createIndexes、modify和shardCollection等DDL語句，更多信息，請參見Change Events。
• Change Events新增wallTime字段，時間戳支持多種轉換和展示算子（包括$toDate、$tsSeconds和tsIncrement）以方便業務消費。

聚合（Aggregation）

聚合功能允許用戶處理多個文檔并返回計算結果。通過將多個操作符組合到聚合管道中，用戶可以構建出足夠復雜的數據處理管道以提取數據并進行分析。MongoDB 6.0在原有聚合功能的基礎上，推出了如下新特性以及優化項：

• 分片集群實例支持$lookup和$graphLookup。
• 改進$lookup對JOINS的支持。
• 改進$graphLookup對圖遍歷的支持。
• 提升$lookup性能，部分場景中性能提升可達百倍。

查詢（Query）

新增$maxN、$topN、$minN、$bottomN、$lastN和$sortArray等操作符。通過操作符可以將更多的計算從業務層下沉到數據庫中，使得業務層更加輕量化。

彈性

MongoDB 6.0在原有彈性的基礎上，推出了如下新特性以及優化項：

• 將數據塊（Chunk）規格的默認值從64 MB調整為128 MB，有效降低了數據遷移頻率以及網絡和路由層的開銷。
• 支持configureCollectionBalancing命令，此命令支持的功能如下：
• 支持為不同的分片表設置不同的數據塊規格。示例：數據規模特別大的分片表，將數據塊規格調整到256 MB。數據規模相對較小但希望在分片上分布更均勻的分片表，將數據塊規格調整到64 MB或32 MB。
• 支持自動整理分片集合的磁盤空間碎片。

你可以通過configureCollectionBalancing命令設置自動整理磁盤碎片，設置自動整理后你無需再主動使用compact命令來整理磁盤空間碎片，即可有效控制磁盤空間使用率

安全性

MongoDB 6.0在原有安全性的基礎上，對客戶端字段級加密（CSFLE, Client-Side Field-Level Encryption）功能進行了優化。CSFLE將支持任何符合密鑰管理互通協議（KMIP，Key Management Interoperability Protocol）的密鑰管理提供商，即除了基于KeyFile的本地密鑰管理外，MongoDB支持通過KMIP與第三方密鑰管理設備集成，為用戶提供更安全的保障。

四、MongoDB 7.0版本新特性

支持分片元數據一致性校驗

MongoDB 7.0版本中新增了checkMetadataConsistency命令，以檢查不同分片中元數據不一致的情況，示例如下。

示例1：

// Command
db.runCommand( {
 checkMetadataConsistency: 1,
 checkIndexes: true
} )

示例2：

//mongosh
db.checkMetadataConsistency()
db.collection.checkMetadataConsistency()
sh.checkMetadataConsistency() 

你可以在日常運維中增加該巡檢項，盡早發現可能不一致的風險。更多信息請參見checkMetadataConsistency。

支持采樣查詢與分析分片鍵（analyzeShardKey）

支持基于采樣查詢（Sampled queries）的結果來分析集合的分片鍵是否合理，可以幫助你更好地設計Schema以及分片鍵、更合理使用分片架構。核心命令analyzeShardKey的語法如下：

db.adminCommand(
 {
 analyzeShardKey: <string>,
 key: <shardKey>,
 keyCharacteristics: <bool>,
 readWriteDistribution: <bool>,
 sampleRate: <double>,
 sampleSize: <int>
 }
 )

說明

盡管該命令并不會阻塞集合上的讀寫操作，但為了降低對業務的影響，建議配套使用secondary或secondaryPreferred模式的Read preference執行。mongos默認為secondaryPreferred模式。

更多信息請參考analyShardKey與configureQueryAnalyzer。

自動合并（AutoMerger）

MongoDB 7.0為自動均衡器（Balancer）實現了一個新的自動合并器（AutoMerger），當數據或索引分布不均衡、存在過多分片或進行數據遷移時，自動合并器會合并Chunks，以均衡數據并提高性能。MongoDB 7.0默認開啟該功能，你也可以通過Balancer活動窗口控制該功能。

之前版本引入用于單個集合數據均衡的configureCollectionBalancing命令也支持了AutoMerge：

db.adminCommand(
  {
  configureCollectionBalancing: "<db>.<collection>",
  chunkSize: <num>,
  defragmentCollection: <bool>,
  enableAutoMerger: <bool>
  }
)

除此之外，你也可以通過mergeAllChunksOnShard命令將一個分片上所有可合并的Chunk（或Range）進行手動合并：

db.adminCommand( { mergeAllChunksOnShard: "db.coll", shard: "Shard0" } )

分片（Sharding）

除了上文提到過的AutoMerger以外，還有以下優化項：

• 支持通過參數rangeDeleterHighPriority設置刪除孤兒文檔是否具備更高的優先級。通常業務的刪除往往具有更高的優先級，所以該參數默認為false。
• 不再支持用于記錄目錄緩存刷新行為的operationsBlockedByRefresh監控指標，原因是基于mongos每個利用集合路由信息的操作都會增加該計數器的次數。
• 新增關于Resharding的監控指標。
• addShard命令不再支持maxSize選項。
• 調整config.settings集合的chunksize時，增加了合理性校驗，將值限制在[1,1024]。
• MongoDB在6.0.3版本后對Balancer策略進行若干調整：

Balancer不再依據分片間Chunks數量的差異，而是依據分片間數據量的差異進行均衡。

將Chunk的邏輯概念轉為Range。

自動分裂（auto-splitting）只會在跨分片移動時發生。

• 查看集合分片信息

下面的SQL將"myDB"更換為所需要查詢的DB名稱即可。

var dbName = "myDB";
db.getSiblingDB(dbName).getCollectionNames().forEach(function(collName) {
 print("————————————————————————");
 print("Collection: " + collName);
 db.getSiblingDB(dbName).getCollection(collName).getShardDistribution();
});

安全性

• 支持KMIP 1.0和1.1。
• 支持OpenSSL 3.0以及OpenSSL FIPS。

聚合（Aggregation）

新增了以下操作符，支持位計算和百分位數：

時序集合（Time-Series Collection）

• 移除了之前版本對于時序集合DELETE命令的操作限制。除了不能在多文檔事務中使用相關刪除命令外，當前DELETE命令再無其他限制。
• COMPACT命令支持時序集合。

其他優化

• 慢日志新增了catalogCacheIndexLookupDurationMillis等字段，更多信息請參見log messages for slow queries。
• 支持動態調整存儲引擎事務并發度，之前默認是128，從MongoDB 7.0起，MongoDB會自動動態調整該并發度，更多信息請參見Concurrent Storage Engine Transactions。
• currentOp新增了關于query sampling的全新字段，更多信息請參見currentop-metrics。
• 支持復合通配符索引，更多信息請參見Compound Wildcard Indexes。
• 新增$changeStreamSplitLargeEvent算子支持對超過16 MB的超大變更事件（change events）進行切分，更多信息請參見Large Change Stream Events。
• 優化基于Slot查詢執行引擎的性能。
• 新增Chunk遷移的指標，更多信息請參見New Sharding Statistics for Chunk Migrations。
• 支持通過USER_ROLES系統變量來獲取當前User的角色。
• 新增analyzeShardKey、balancer、queryAnalyzers相關的全局參數。
• serverStatus的返回結果新增更多字段，更多信息請參見serverStatus Output Change。

作者介紹

吳守陽，51CTO社區編輯，擁有8年DBA工作經驗，熟練管理MySQL、Redis、MongoDB等開源數據庫。精通性能優化、備份恢復和高可用性架構設計。善于故障排除和自動化運維，保障系統穩定可靠。具備良好的團隊合作和溝通能力，致力于為企業提供高效可靠的數據庫解決方案。