我有一個 mongo 聚合管道，同時運行如下內容
{
$match: {
"cohortId": payload.cohortId, "template": req.query.template
},
}, {
$lookup: {
from: "messages", localField: "messageId", foreignField: "metaData.messageId", as: "message"
}
}, {
$lookup: {
from: "webhook", localField: "messageId", foreignField: "messageId", as: "webhook"
}
}, {
$unwind: {
path: "$webhook"
}
}, {
$unwind: {
path: "$message"
}
},
{
$project: {
"_id": 0,
"messageId": 1,
"cohortId": 1,
"template": 1,
"origin": 1,
"WBA_AccountId": 1,
"WBA_PhoneId": 1,
"clientPhone": "$phone",
"messageDirection": "$message.metaData.direction",
"messageTime": "$message.metaData.time",
"messageSent": "$webhook.status.sentFlag",
"messageDelivered": "$webhook.status.deliveredFlag",
"messageRead": "$webhook.status.readFlag",
"messageFailed": "$webhook.status.failedFlag",
"messageFailedReason": "$webhook.status.failedReason",
"messageSentTime": "$webhook.status.sentTimestamp",
"messageDeliveredTime": "$webhook.status.deliveredTimestamp",
"messageReadTime": "$webhook.status.readTimestamp",
"messageFailedTime": "$webhook.status.failedTimestamp"
}
},
Web 掛鉤中的資料在哪里
{
"_id": {
"$oid": "6374d59618bff45fa34f08f5"
},
"messageId": "<Message ID as String>",
"conversationExpiry": 1668687660,
"conversationId": "<Conversation ID as String>",
"billableFlag": "true",
"WBA_PhoneId": 1234567890, //masked
"WBA_AccountId": 1234567890, //masked
"WBA_DisplayPhone": 1234567890, //masked
"phone": 1234567890, //masked
"status": {
"sentFlag": true,
"sentTimestamp": 1668601237,
"deliveredFlag": true,
"readFlag": true,
"failedFlag": false,
"deliveredTimestamp": 1668601238,
"readTimestamp": 1668601250,
"failedTimestamp": 0,
"errorMessage": "",
"errorCode": ""
},
"createdAt": {
"$date": {
"$numberLong": "1668601238086"
}
},
"updatedAt": {
"$date": {
"$numberLong": "1668601250918"
}
}
}
和觀眾資料看起來像
{
"_id": {
"$oid": "635a840b97405992d3cb794d"
},
"WBA_AccountId": 1234567890, //masked
"WBA_PhoneId": 1234567890, //masked
"messageId": "<Message ID as String>",
"phone": 1234567890, //masked
"cohortId": "<String Value, I refer this in Aggregation Pipeline to trigger it>",
"createdAt": {
"$date": {
"$numberLong": "1666876427333"
}
},
"end": "2022-10-27",
"origin": "Clevertap_API_Campaigns",
"start": "2022-10-27",
"template": "<String Value, I refer this in Aggregation Pipeline to trigger it>",
"updatedAt": {
"$date": {
"$numberLong": "1666876427333"
}
}
}
問題
當我使用佇列和模板點擊控制器觸發管道時，迭代 6000 多個檔案需要 3 分鐘，網路呼叫超時。
可以做些什么來優化流水線？
我正在使用 M10 Atlas Cluster
編輯：添加實時指標 集群使用情況的螢屏截圖
uj5u.com熱心網友回復：
在這個聚合管道中有3次使用索引的機會，目前資料庫根本無法使用。
第一個機會是收藏中的首$match字母audiances。有兩個欄位被過濾，cohortId和template。兩者都有相等謂詞，因此索引鍵可以按任意順序排列：
db.getSiblingDB('Production').audiances.createIndex({ cohortId:1, template:1 })
同樣，資料庫可以嘗試為這兩個$lookup操作使用索引。目前它正在對每個集合進行大約 10,000 次完整掃描：
{
"$lookup":
...
"totalDocsExamined": 97236382,
"collectionScans": 9908,
"indexesUsed": [],
},
{
"$lookup":
...
"totalDocsExamined": 95408871,
"collectionScans": 9906,
"indexesUsed": [],
},
你在評論中提到你“在系統中有一個這樣的索引”并且你“嘗試創建一個text索引metaData.messageId”。后一個索引不合適，因為您沒有執行$text 搜索，因此無法使用它。螢屏截圖中顯示的第一個索引是{ phone: 1, metadata.messageid: 1 }. 也不能使用該索引，因為第一個鍵 ( phone) 不是您的查詢 ( $lookup) 的一部分。
作為$lookup直接比較，以下兩個索引將（極大地）提高操作的性能和效率：
db.getSiblingDB('Production').messages.createIndex({ "metaData.messageId": 1 })
db.getSiblingDB('Production').webhook.createIndex ({ "messageId": 1 })
轉載請註明出處，本文鏈接：https://www.uj5u.com/qianduan/534928.html
標籤：数据库猫鼬