Tipps zur Optimierung von Aggregation-Pipelines

Aggregationspipelines können teuer sein – sie können Millionen von Dokumenten durchsuchen, große Strukturen im Arbeitsspeicher aufbauen und für mehrere Sekunden blockieren. Der Schlüssel zu schnellen Pipelines besteht darin, datenreduzierende Stufen so früh wie möglich anzuwenden, damit spätere Stufen mit einem möglichst kleinen Datensatz arbeiten. MongoDB verfügt außerdem über einen internen Optimierer, der bestimmte Stufen automatisch neu anordnet. Wenn Sie manuelle Optimierungen verstehen, haben Sie jedoch die größte Kontrolle.

$match ist die Filterstufe von MongoDB. Wenn Sie sie so früh wie möglich in der Pipeline platzieren, verringern Sie die Anzahl der Dokumente, die in jede nachfolgende Stufe gelangen. Kann $match einen Index verwenden, wird es zu einem äußerst schnellen ersten Schritt. Selbst ein frühes $match ohne Index ist besser als ein spätes – so vermeiden Sie die Verarbeitung von Dokumenten, die ohnehin verworfen werden.

Verwenden Sie $project früh, um Felder zu entfernen, die Sie in späteren Stufen nicht benötigen. Weniger Felder pro Dokument bedeuten kleinere Darstellungen im Arbeitsspeicher, die durch die Pipeline fließen, und reduzieren dadurch den Speicherbedarf und die CPU-Zeit. Entfernen Sie nur Felder, bei denen Sie sicher sind, dass sie nicht benötigt werden – ein zu aggressives frühes $project, das ein in einer späteren Stufe verwendetes Feld entfernt, führt zu einem Fehler.

Der Aggregationsoptimierer von MongoDB wendet vor der Ausführung Ihrer Pipeline automatisch mehrere Neuschreibungen an. Wichtige automatische Neuschreibungen: 1) Führt aufeinanderfolgende $match-Stufen zu einer einzigen zusammen. 2) Verschiebt $match nach Möglichkeit vor $skip und $limit. 3) Führt aufeinanderfolgende $limit-Stufen zusammen. 4) Verschiebt $match vor $lookup, um vor dem Join zu filtern. Verwenden Sie explain(), um die optimierte Pipeline anzuzeigen.

$unwind zerlegt ein Array in mehrere Dokumente – eines pro Array-Element. Wenn Sie $match nach $unwind platzieren, tragen Sie zunächst die vollständigen Kosten der Erweiterung, bevor gefiltert wird. Filtern Sie nach Möglichkeit vor $unwind, um die Anzahl der Array-Elemente zu reduzieren, die erweitert werden müssen. Bei großen Arrays kann dies die Dokumentanzahl um eine Größenordnung verringern.

Die erste $match-Stufe einer Pipeline kann genau wie eine find()-Abfrage einen Index der Collection verwenden. Auch die erste $sort-Stufe kann einen Index verwenden, um eine Sortierung im Arbeitsspeicher zu vermeiden – allerdings nur, wenn sie vor jeder Stufe steht, die die Dokumentstruktur verändert, etwa $project oder $group. Strukturieren Sie Ihre Pipelines so, dass frühe $match- und $sort-Stufen von Indexen profitieren.

Standardmäßig ist jede Aggregationsstufe auf 100 MB Arbeitsspeicher begrenzt. Überschreitet eine $sort-, $group- oder $bucket-Stufe dieses Limit, schlägt die Pipeline mit einem Fehler fehl. Wenn Sie allowDiskUse: true setzen, kann die Pipeline Daten auf die Festplatte auslagern und dadurch beliebig große Sortierungen ermöglichen – allerdings auf Kosten langsamerer E/A-Vorgänge. Die richtige Lösung besteht meist darin, einen Index hinzuzufügen oder vor der Sortierung aggressiver zu filtern.

$lookup entspricht in der Aggregation einem SQL-JOIN und ist eine der teuersten Stufen. So minimieren Sie die Kosten: 1) Platzieren Sie $match vor $lookup, damit weniger Dokumente verknüpft werden müssen. 2) Stellen Sie sicher, dass die verknüpfte Collection einen Index für foreignField besitzt. 3) Verwenden Sie die Pipeline-Form von $lookup mit einem darin enthaltenen $match, um die verknüpften Ergebnisse sofort zu filtern.

Wenn Sie Endpunkte für paginierte Listen erstellen, verschieben Sie $limit nach dem Filtern und Sortieren so früh wie möglich nach vorne. Eine Pipeline, die 100.000 Dokumente durch $lookup und $addFields verarbeitet, bevor sie auf 20 begrenzt wird, ist 5.000-mal teurer als eine Pipeline, die zuerst begrenzt. Bei der Keyset-Paginierung macht ein Bereichsfilter $skip häufig vollständig überflüssig.

Für teure Aggregationen, die Dashboards oder Berichte versorgen, sollten Sie materialisierte Sichten mit $merge oder $out in Betracht ziehen. Führen Sie die aufwendige Aggregation nach einem Zeitplan aus, beispielsweise jede Stunde, und schreiben Sie die Ergebnisse in eine eigene Collection. Abfragen der materialisierten Sicht sind kostengünstige Punktabfragen statt teurer Pipeline-Scans. Atlas unterstützt über Trigger auch On-Demand Materialised Views.

Verwenden Sie bei einer Aggregation .explain('executionStats'), um zu sehen, wie viele Dokumente jede Stufe ausgegeben hat. Achten Sie auf Stufen, bei denen nReturned stark abnimmt – dort findet die eigentliche Arbeit statt. Wenn eine Stufe weiterhin Millionen von Dokumenten verarbeitet, fügen Sie davor ein $match hinzu oder verbessern Sie den Index. Für Atlas zeigt der Query Profiler außerdem die Leistung von Aggregationspipelines im Zeitverlauf.

In dieser Lektion haben Sie gelernt: $match und $project so früh wie möglich einzusetzen, um das Dokumentvolumen in späteren Stufen zu minimieren, sicherzustellen, dass das erste $match und $sort Indexe verwenden, um Collection-Scans und Sortierungen im Arbeitsspeicher zu vermeiden und allowDiskUse für unvermeidbar große Sortierungen zu verwenden, aber bessere Indexe oder frühere Filter als dauerhafte Lösung zu bevorzugen. Als Nächstes sehen wir uns Atlas Data Federation an.