作者 | 吳守陽

審校 | 重樓

引言

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

本文旨在全面剖析這些版本中的關(guān)鍵新特性，不僅是為了記錄技術(shù)演進(jìn)的歷史，更是為了賦能數(shù)據(jù)庫管理員、開發(fā)者和架構(gòu)師，使他們能夠充分理解并利用這些新功能，從而優(yōu)化數(shù)據(jù)管理和應(yīng)用性能。

速覽

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

1.MongoDB4.4 新特性

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

2.MongoDB5.0 新特性

• 原生時間序列平臺
• 在線數(shù)據(jù)重新分片
• Write Concern默認(rèn)Majority級別
• 連接管理優(yōu)化
• 長時間運行的快照查詢
• 新版MongoDB Shell
• 可恢復(fù)的索引創(chuàng)建任務(wù)

3.MongoDB6.0 新特性

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

4.MongoDB7.0 版本新特性

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

目的

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

讀者獲益

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

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

一、MongoDB 4.4版本新特性

隱藏索引（Hidden Indexes）

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

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

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

重定義分片鍵（Refinable Shard Keys）

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

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

此外，Shard Key需要有對應(yīng)的Index來支撐，因此refineCollectionShardKey命令要求提前創(chuàng)建新Shard Key所對應(yīng)的Index。

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

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

復(fù)合哈希分片鍵（Compound Hashed Shard Keys）

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

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

對沖讀（Hedged Reads）

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

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

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

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

參考代碼：

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

同步建索引（Simultaneous Indexing）

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

但即使在4.2版本中統(tǒng)一了前后臺索引創(chuàng)建機制，使用了相當(dāng)細(xì)粒度的加鎖機制（只在索引創(chuàng)建的開始和結(jié)束階段對集合加獨占鎖），也會因為索引創(chuàng)建本身的CPU、IO性能開銷導(dǎo)致復(fù)制延遲，或是因為一些特殊操作，例如使用collMod命令修改集合元信息，而導(dǎo)致Oplog的應(yīng)用阻塞，甚至?xí)驗橹鲙鞖v史Oplog被覆蓋而進(jìn)入Recovering狀態(tài)。

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

此外，新的索引創(chuàng)建機制規(guī)定，只有在大多數(shù)具備投票權(quán)限節(jié)點返回成功后，索引才會真正生效。所以，也可以減輕在讀寫分離場景下因為索引不同而導(dǎo)致的性能差異。

復(fù)制讀請求（Mirrored Reads）

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

流量復(fù)制的比例是可動態(tài)配置的，通過mirrorReads參數(shù)設(shè)置，默認(rèn)復(fù)制1%的流量。

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

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

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

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

在4.4版本中，MongoDB支持通過storage.oplogMinRetentionHours參數(shù)定義需要保留的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允許創(chuàng)建高度優(yōu)化和壓縮的時間序列集合，自動存儲帶有時間戳的數(shù)據(jù)，減少存儲需求和I/O操作，提升性能和可擴展性。
2. 自動管理：時間序列集合能夠自動處理數(shù)據(jù)的動態(tài)時間分區(qū)，適應(yīng)不同的采集頻率，并能處理無序到達(dá)的測量值。
3. 簡化開發(fā)：時間序列集合的創(chuàng)建和管理簡化了開發(fā)流程，使開發(fā)者能夠快速構(gòu)建針對時間序列特性的高性能應(yīng)用模型。
4. 集成與流處理：通過MongoDB Connector for Apache Kafka，可以直接從Kafka主題中創(chuàng)建時間序列集合，實現(xiàn)數(shù)據(jù)的實時處理、聚合和寫入。
5. 智能索引與查詢：時間序列集合自動創(chuàng)建時間排序的聚集索引，減少查詢延遲，同時擴展了查詢API，支持窗口函數(shù)和時間運算符，如移動平均、累積總和、指數(shù)移動平均等。
6. 統(tǒng)一的數(shù)據(jù)平臺：時間序列集合可以與常規(guī)MongoDB集合共存于同一數(shù)據(jù)庫中，無需使用專用的時間序列數(shù)據(jù)庫，降低了維護(hù)多個數(shù)據(jù)庫的成本和復(fù)雜性。

創(chuàng)建時間序列數(shù)據(jù)集合的命令示例：

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

在線數(shù)據(jù)重新分片

Write Concern默認(rèn)Majority級別

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

說明

Write Concern是完全可調(diào)的，你可以自定義配置Write Concern，以平衡應(yīng)用程序?qū)?span>數(shù)據(jù)庫性能和數(shù)據(jù)持久性的要求

連接管理優(yōu)化

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

連接數(shù)較多或創(chuàng)建連接失控的情況稱為“連接風(fēng)暴”，產(chǎn)生該情況的原因可能是多方面的，且經(jīng)常是在服務(wù)已經(jīng)受到影響的情況下發(fā)生。

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

• 限制在任何時候驅(qū)動程序嘗試創(chuàng)建的連接數(shù)量，以簡單有效的方式防止數(shù)據(jù)庫服務(wù)器過載。
• 減少驅(qū)動程序監(jiān)控連接池時的檢查頻率，給無響應(yīng)或過載的服務(wù)器節(jié)點一個緩沖和恢復(fù)的機會。
• 驅(qū)動程序?qū)⒐ぷ髫?fù)載導(dǎo)向具有最健康連接池的更快的服務(wù)器，而不是從可用的服務(wù)器中隨機選擇。

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

長時間運行的快照查詢

長時間運行的快照查詢（Long-Running Snapshot Queries）增加了應(yīng)用程序的通用性和彈性。你可以通過該功能運行默認(rèn)時間為5分鐘的查詢（或?qū)⑵湔{(diào)整為自定義持續(xù)時間），同時保持與實時事務(wù)性數(shù)據(jù)庫一致的快照隔離，也可以在Secondary節(jié)點（從節(jié)點）上進(jìn)行快照查詢，從而在單個集群中運行不同的工作負(fù)載，并將其擴展到不同的分片上。

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

新版MongoDB Shell

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

可恢復(fù)的索引創(chuàng)建任務(wù)

MongoDB 5.0支持將正在進(jìn)行中的索引創(chuàng)建任務(wù)在節(jié)點重新啟動后自動恢復(fù)至原來的位置，減少計劃中維護(hù)動作對業(yè)務(wù)的影響。例如：重新啟動或升級數(shù)據(jù)庫節(jié)點時，你不需要擔(dān)心當(dāng)前正在進(jìn)行的大集合索引創(chuàng)建任務(wù)失效。

三、MongoDB 6.0版本新特性

可查詢加密（Queryable Encryption）

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

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

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

可查詢加密的特點如下：

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

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

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

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

時序集合（Time Series Collection）

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

• 引入二級和復(fù)合索引，以改善讀取性能。
• 引入針對時空數(shù)據(jù)的地理位置索引（Geo-Indexing），將地理信息添加到時序數(shù)據(jù)，有助于更好地分析涉及距離和位置的場景。場景示例：跟蹤夏日冷鏈運輸車的溫度變化情況、監(jiān)測特定航線上的貨運船燃料消耗。
• 優(yōu)化對時序數(shù)據(jù)的last point查詢，不再需要掃描整個集合后才能查詢到最后一個數(shù)據(jù)點。
• 優(yōu)化對時序數(shù)據(jù)的排序，通過時間以及元數(shù)據(jù)字段上的聚簇索引（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字段，時間戳支持多種轉(zhuǎn)換和展示算子（包括$toDate、$tsSeconds和tsIncrement）以方便業(yè)務(wù)消費。

聚合（Aggregation）

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

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

查詢（Query）

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

彈性

MongoDB 6.0在原有彈性的基礎(chǔ)上，推出了如下新特性以及優(yōu)化項：

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

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

安全性

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

四、MongoDB 7.0版本新特性

支持分片元數(shù)據(jù)一致性校驗

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

示例1：

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

示例2：

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

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

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

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

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

說明

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

更多信息請參考analyShardKey與configureQueryAnalyzer。

自動合并（AutoMerger）

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

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

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

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

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

分片（Sharding）

除了上文提到過的AutoMerger以外，還有以下優(yōu)化項：

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

Balancer不再依據(jù)分片間Chunks數(shù)量的差異，而是依據(jù)分片間數(shù)據(jù)量的差異進(jìn)行均衡。

將Chunk的邏輯概念轉(zhuǎn)為Range。

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

• 查看集合分片信息

下面的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）

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

時序集合（Time-Series Collection）

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

其他優(yōu)化

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

作者介紹

吳守陽，51CTO社區(qū)編輯，擁有8年DBA工作經(jīng)驗，熟練管理MySQL、Redis、MongoDB等開源數(shù)據(jù)庫。精通性能優(yōu)化、備份恢復(fù)和高可用性架構(gòu)設(shè)計。善于故障排除和自動化運維，保障系統(tǒng)穩(wěn)定可靠。具備良好的團(tuán)隊合作和溝通能力，致力于為企業(yè)提供高效可靠的數(shù)據(jù)庫解決方案。