MongoDB 系列 - 數據查詢游標你用對了嗎？
本文轉載自微信公眾號「編程界」，作者五月君 。轉載本文請聯系編程界公眾號。
幾個話題
本文會根據以下幾個話題進行討論與講解，文中的目錄不完全和這幾個話題一致，但當你閱讀完本文后，相信這些答案應該也有了，都在文中。
- 為什么要使用游標、什么時候使用?
- 關注服務器內存，游標什么時候關閉?
- 需要注意的游標超時與容錯處理
- 為什么不要隨意調整 batchSize 數量?
- 使用時需注意 Mongoose 與原生 Node.js MongoDB 驅動程序的不同之處
- 解答群友問題時發現的一個關于游標的 Bug
- 擴展 - 為什么可以使用 for await of 遍歷游標對象?
為什么要使用游標?
這樣的寫法 collection.find().toArray()，大家在學習 MongoDB 時應該見的也不少，它的原理是客戶端驅動程序會自動把返回的所有數據一次性加載到應用程序內存中，理解起來相對簡單些，如果數據量小是沒問題的，在一些數據處理的場景中，具體有多少數據也許是未知的，有可能返回大量的數據，如果全部 hold 在內存，在服務端內存寸土寸金的地方，白白消耗服務內存不說，內存占用過高還可能造成服務 OOM。
MongoDB 里面的游標，有點類似于在 Node.js 里使用 Stream 處理文件數據，相比把整個文件讀入內存在處理這種模式，Stream 帶來的收益是很大的。
很形象的一個圖，來源：https://www.cnblogs.com/vajoy/p/6349817.html[1]
游標基本工作原理
當我們使用 collection.find() 或 collection.aggregate() 返回的是一個指向該集合的指針，也稱為游標(cursor)，是不能直接訪問數據的，只有當循環迭代這個游標時才會真正的從數據庫集合讀取數據。
在 Node.js 中使用很簡單，只要支持 for await of 語法，即可遍歷游標返回的數據集，和正常使用 for of 遍歷數組很相似，區別是 for await of 遍歷的數據源是異步的。當循環迭代開始時驅動程序會使用 getMore() 命令批量從數據庫集合中獲取一批數據先緩存起來，例如 Node.js MongoDB 驅動程序每次默認批量獲取 1000 條(注意，第一次 getMore() 時實際請求是 101 條)，取決于 batchSize[2] 參數設置，待這批數據處理完成之后，在向 MongoDB Server 執行 getMore() 繼續請求直到游標耗盡。
以下為 Node.js 中的兩種使用示例，個人比較推薦 for await of 這種寫法。方法二 while 循環這種寫法在一個 MongoDB Node.js 驅動程序版本中存在一個 Bug 下文會介紹。
- const userCursor = await collection.find();
- // 如果沒有返回數據，需要做一些特殊處理的，可以使用 userCursor.count() 或 userCursor.hasNext()
- if (!await userCursor.count()) {
- // TODO: 提前結束，做一些其它操作
- return;
- }
- // 方法一：
- for await (const user of userCursor) {
- }
- // 方法二：
- while (await userCursor.hasNext()) {
- const doc = userCursor.next();
- }
例如，數據庫集合有 10000 條數據，每次批量獲取 1000 條，I/O 消耗應該也為 10 次。終端鏈接至 MongoDB Server 設置 db.setProfilingLevel(0, { slowms: 0 })記錄所有的操作日志，之后在打開 MongoDB Server 控制臺日志，執行應用程序之后會看到如下日志信息，每次 getMore 都指向了同一個游標 ID getMore: 5098682199385946244。
游標讀取結果.png
如果需要修改 batchSize 結果的，通過 options 指定 batchSize 屬性或調用 batchSize 方法都可以。
- collection.find().batchSize(1100)
- // 或以下方法
- collection.find({}, {
- batchSize: 1100
- })
切記不要將 batchSize 設置為 1，例如，10000 條數據每獲取一條數據，客戶端都將連接服務器讀取，這將會產生 10000 次網絡 IO，下圖使用 mongostat 監控，展示了每秒查詢游標時的 getMore 次數。
游標超時
如果一個游標在一定時間內無人訪問，超時之后會被回收，防止產生內存泄漏，啟動時可通過 mongod --setParameter cursorTimeoutMillis=300000 參數設置，默認超時為 10 分鐘，參見文檔 cursorTimeoutMillis#Default: 600000 (10 minutes)[3]。
例如，總共查詢 10000 條數據，第一次 getmore() 默認批量獲取 1000 條數據，如果在默認的 10 分鐘內沒有處理完成這 1000 條數據，游標會被關閉，待下次執行 getmore() 就會報錯 cursor id 4011961159809892672 not found，一般稱之為游標超時。
如有遇到游標超時，可通過調整 cursorTimeoutMillis 參數或減少 batchSize 數量選擇適合于自己的程序配置，通常默認配置是不需要調整的。例如，在遍歷游標數據時調了一個外部接口，由于接口超時導致的游標超時這種外部業務原因的，應先去優化業務本身，再考慮調整配置。
為了解決游標超時，你可能還見到過 cursor.addCursorFlag('noCursorTimeout', true) 這樣的配置，這會禁用掉游標的超時限制，只有等到游標耗盡或手動關閉 cursor.close() 游標才可能被釋放，禁用超時時間這種做法，很不推薦使用，每個游標都存在額外的內存占用消耗，如果因為疏忽忘記手動關閉游標導致的 MongoDB Server 內存泄漏就得不償失了。
游標狀態
登陸 MongoDB 客戶端，執行 db.serverStatus().metrics.cursor 命令，查看當前游標使用狀態。如果真的出現游標導致的 MongoDB 服務器內存泄漏，以下幾個數據指標，做為運維人員在排查問題時，會有幫助。
- timedOut：指 MongoDB Server 進程啟動到現在所有的游標超時數量，此指標反映了應用程序因為處理耗時任務 或 游標打開后因為報錯沒有顯示關閉游標 這兩種情況導致的游標超時數量。
- open.noTimeout：為了防止游標超時，MongoDB 提供了一個配置 DBQuery.Option.noTimeout[4] 設置永不超時，但如果處理完畢忘記顯示關閉游標，會導致游標常駐內存，數量越大內存泄漏的風險也越大，建議是盡量不要設置 noTimeout。
- open.pinned：“固定” 打開游標的數量。
- open.total：MongoDB Server 當前為客戶端打開的游標數量，當有游標耗盡，total 的數量也會不斷的減少。
- {
- "timedOut" : NumberLong(4),
- "open" : {
- "noTimeout" : NumberLong(0),
- "pinned" : NumberLong(0),
- "total" : NumberLong(0)
- }
- }
游標與異步迭代器
JavaScript 在 ES6 語法提供了一個功能叫迭代器，定義了一套統一的接口，只要實現了該接口的數據類型，都可使用 for of 關鍵詞遍歷，例如數組、Map、Set 類型等，這些類型上有一個方法 Symbol.iterator 返回的就是一個迭代器對象，迭代器對象的 next() 方法返回值包含了 vlaue、done 兩個屬性，如果 done 為 true 表示數據已遍歷完成，但 Symbol.iterator 只支持同步的數據源。
而我們從數據庫集合獲取數據涉及到網絡 I/O，這是一個異步的操作，Symbol.iterator 就無法支持了，在ECMAScript 2018 標準中提供了一個新的屬性 Symbol.asyncIterator，這是一個異步迭代器，與 Symbol.iterator 不同的是 Symbol.asyncIterator 的 next() 方法返回的是一個包含 { value, done } 的 Promise 對象，如果一個對象設置了該屬性，它就是異步可迭代對象，相應的我們可使用 for await...of 循環遍歷數據。
下面看下 MonogoDB Node.js 驅動程序在 v4.2.2 版本中的實現，同樣也提供了 Symbol.asyncIterator 接口，這也就是為什么我們可以使用 for await...of 循環遍歷。
- // mongodb/lib/cursor/abstract_cursor.js
- class AbstractCursor extends mongo_types_1.TypedEventEmitter {
- [Symbol.asyncIterator]( "Symbol.asyncIterator") {
- return {
- next: () => this.next().then(value => value != null ? { value, done: false }: { value: undefined, done: true })
- };
- }
- }
容錯處理
在遍歷游標的過程中，for 循環體內如果出現一些錯誤導致循環提前終止，這個時候游標并不會被立刻銷毀，可以選擇手動關閉游標或等待超過默認的游標超時時間后，游標也會被銷毀。
如果設置了 noCursorTimeout 屬性為永不超時，這個時候就一定記得要關閉游標，因此在上面也建議盡量不要做這個設置。
- const userCursor = await collection.find();
- try {
- for await (const user of userCursor) {
- // 可能拋出錯誤 throw new Error('124')
- }
- } catch (e) {
- // 處理錯誤
- } finally {
- userCursor.close();
- }
Mongoose 需要注意的地方
使用 mongoose 和原生支持的 mongodb 模塊還是有很多差異的，mongoose 的 find() 方法默認不會返回游標對象，需要在 find 后顯示調用 cursor() 方法，且沒有 cursor.count()、cursor.hasNext() 方法支持，對于一些想判斷如果游標沒有數據做一些特殊處理，處理起來不是很友好。
- const userCursor = await User.find({}).cursor();
- for await (const user of userCursor) {
- }
一個關于游標的 Bug
在 Node.js 群里，一個群友發來消息使用游標遇到了問題，后來也對這個問題做了一些查找和驗證，下文會介紹，基于一個特定版本和特定的應用場景才會出現這個問題，放在這里也是希望用到的朋友能少踩一個坑。
MongoDB Node.js 驅動程序在 3.5.4 版本基于游標迭代查詢數據時，如果用了 limit 限制返回的數據條目，并且使用 hasNext()，存在一個 Bug，首先是從返回的游標對象取出的 count 數不對，其次是遍歷出的數據條目與實際 limit count 數對不上，如果 limit 為奇數還會收到 MongoError: Cursor is closed 錯誤。
如果需要調整每一次的 getMore() 數量，游標可以結合 batchSize 使用。為什么用了游標還要使用 limit?這個也可以思考下。
- const userCursor = await collection.find({}).limit(5);
- console.log('cursor count: ', await userCursor.count());
- try {
- while (await userCursor.hasNext()) {
- const doc = await userCursor.next();
- console.log(doc);
- }
- } catch (err) {
- console.error(err.stack);
- }
- userCursor.close();
mongodb@^3.5.4 版本輸出結果：
- cursor count: 10000
- { _id: 61d6590b92058ddefbac6a14, userID: 0 }
- { _id: 61d6590b92058ddefbac6a15, userID: 1 }
- null
- MongoError: Cursor is closed
- at Function.create (/test/node_modules/mongodb/lib/core/error.js:43:12)
- at Cursor.hasNext (/test/node_modules/mongodb/lib/cursor.js:197:24)
- at file:///test/index.mjs:42:27
- at processTicksAndRejections (internal/process/task_queues.js:93:5)
NPM 包 mongodb 受影響版本為 3.5.4 參見 issue jira.mongodb.org/browse/NODE-2483[5]NPM 包 mongoose 受影響版本為 5.9.4 參見 issue github.com/Automattic/mongoose/issues/8664[6]
參考資料
[1]https://www.cnblogs.com/vajoy/p/6349817.html: https://www.cnblogs.com/vajoy/p/6349817.html
[2]batchSize: https://docs.mongodb.com/manual/tutorial/iterate-a-cursor/#cursor-batches
[3]cursorTimeoutMillis#Default: 600000 (10 minutes): https://docs.mongodb.com/manual/reference/parameters/#mongodb-parameter-param.cursorTimeoutMillis
[4]DBQuery.Option.noTimeout: https://docs.mongodb.com/manual/reference/method/cursor.addOption/#mongodb-data-DBQuery.Option.noTimeout
[5]NPM 包 mongodb 受影響版本為 3.5.4 參見 issue jira.mongodb.org/browse/NODE-2483: https://jira.mongodb.org/browse/NODE-2483
[6]NPM 包 mongoose 受影響版本為 5.9.4 參見 issue github.com/Automattic/mongoose/issues/8664: https://github.com/Automattic/mongoose/issues/8664
