我想知道:
- 雨量總和 (mm)
- 日照總和(小時)
- 周末降雨量超過 0.5 毫米的概率 (%)
在過去 17 年的第 20 周到第 40 周之間的周末(sa so)。
我在 10 分鐘內有 820k 個檔案。該請求有時需要 38 秒,但有時超過 1 分鐘。
你有一個想法如何提高性能?
資料模型:
[
'datum',
'regen',
'tempAussen',
'sonnenSchein',
and more...
]
架構:
[
{
$project: {
jahr: {
$year: {
date: '$datum',
timezone: 'Europe/Berlin',
},
},
woche: {
$week: {
date: '$datum',
timezone: 'Europe/Berlin',
},
},
day: {
$isoDayOfWeek: {
date: '$datum',
timezone: 'Europe/Berlin',
},
},
stunde: {
$hour: {
date: '$datum',
timezone: 'Europe/Berlin',
},
},
tagjahr: {
$dayOfYear: {
date: '$datum',
timezone: 'Europe/Berlin',
},
},
tempAussen: 1,
regen: 1,
sonnenSchein: 1,
},
},
{
$match: {
$and: [
{
woche: {
$gte: 20,
},
},
{
woche: {
$lte: 40,
},
},
{
day: {
$gte: 6,
},
},
],
},
},
{
$group: {
_id: ['$tagjahr', '$jahr'],
woche: {
$first: '$woche',
},
regen_sum: {
$sum: '$regen',
},
sonnenSchein_sum: {
$sum: '$sonnenSchein',
},
},
},
{
$project: {
_id: '$_id',
regenTage: {
$sum: {
$cond: {
if: {
$gte: ['$regen_sum', 0.5],
},
then: 1,
else: 0,
},
},
},
woche: 1,
regen_sum: 1,
sonnenSchein_sum: 1,
},
},
{
$group: {
_id: '$woche',
regen_sum: {
$sum: '$regen_sum',
},
sonnenSchein_sum: {
$sum: '$sonnenSchein_sum',
},
regenTage: {
$sum: '$regenTage',
},
},
},
{
$project: {
regenTage: 1,
regen_sum: {
$divide: ['$regen_sum', 34],
},
sonnenSchein_sum: {
$divide: ['$sonnenSchein_sum', 2040],
},
probability: {
$divide: ['$regenTage', 0.34],
},
},
},
{
$project: {
regen_sum: {
$round: ['$regen_sum', 1],
},
sonnenSchein_sum: {
$round: ['$sonnenSchein_sum', 1],
},
wahrscheinlich: {
$round: ['$probability', 0],
},
},
},
{
$sort: {
_id: 1,
},
},
]
這個結果是第 20 周的一個例子:在日歷第 20 周的周末,我的平均降雨量為 2.3 毫米,日照時間為 11.9 小時,并且有 35% 的概率至少在周末的某一天會下雨
_id:20
regen_sum:2.3
sonnenSchein_sum:11.9
probability:35
uj5u.com熱心網友回復:
如果沒有詳細的解釋輸出 ( .explain("allPlansExecution")),就很難確定。以下是僅查看提供的聚合管道的一些觀察結果(在“模式:”下方)。
在進行觀察之前,我必須詢問您的具體目標是什么。您會經常運行此類操作嗎?是否可以接受超過 38 秒的速度,或者是否有您正在尋找的特定運行時間?如下所述,可能沒有太多直接改進的機會。因此,研究解決該問題的其他方法可能會有所幫助,我將在最后概述一種。
第一個觀察結果是此聚合將執行完整的集合掃描。即使datum欄位上存在索引,也無法使用它,因為 中的過濾$match是在從 計算的新欄位上完成的datum。我們可以進行一些更改以允許使用索引,但這可能無濟于事。您正在處理約 38% 的資料(每年20的52幾周),因此執行索引掃描和隨機獲取大部分資料的開銷可能不僅僅是直接掃描整個集合。
其次,您目前正在$grouping 兩次。這樣做的唯一原因似乎是您可以確定一天是否首先被視為“下雨”(多于0.5mm下雨)。但是“下雨天”指標隨后有效地組合成第二組中的“下雨周末”指標。盡管由于在 24 小時基礎上進行四舍五入,它在技術上可能會稍微改變結果,但也許這個微小的改變值得$group完全消除其中一個階段?
如果這是我的系統,我會考慮預先匯總其中的一些資料。具體來說,每天匯總而不是 10 分鐘間隔的原始資料,在減少生成此類匯總所需的處理量方面確實有很長的路要走。每天的詳細資訊(不會更改)將包含在單個檔案中,而不是144單獨的檔案中。這肯定會允許邏輯上等同于上述聚合的聚合處理速度比您當前觀察到的要快得多。
轉載請註明出處,本文鏈接:https://www.uj5u.com/shujuku/514359.html
標籤:mongodb表现
上一篇:同時應用兩個條件時查詢變慢
下一篇:R,用周圍數字替換0的演算法
