Aggregation-Pipelines über mehrere Quellen ausführen

Eine Aggregation Pipeline über mehrere Quellen in Atlas Data Federation führt dieselben Aggregationsstufen aus, die Sie aus MongoDB kennen. Die Daten unter den einzelnen Stufen können jedoch aus verschiedenen physischen Systemen stammen – einem S3-Bucket, einem aktiven Atlas-Cluster oder beiden. Die föderierte Query Engine übernimmt Routing, Fan-out und das Zusammenführen der Ergebnisse transparent. Aus Sicht Ihrer Anwendung sieht dies wie eine Abfrage einer einzelnen MongoDB-Collection aus.

Die einfachste Abfrage über mehrere Quellen ist ein find() für eine virtuelle Collection, die von S3-Dateien unterstützt wird. Die Query Engine liest und analysiert die Dateien und wendet den Filter an. Felder im Filter, die Partitionsattributen im Pfad entsprechen, führen automatisch zum Überspringen nicht relevanter Dateien. Felder, die keinen Partitionsattributen entsprechen, werden nach dem Lesen als Filter angewendet.

Sie können jede Aggregationsstufe auf virtuelle Collections anwenden, die von S3 unterstützt werden: $match, $group, $project, $sort, $limit. Die Query Engine verlagert Stufen, sofern möglich, an die Datenquelle (insbesondere $match für Partition-Pruning und Spalten-Pruning in Parquet) und führt die übrigen Stufen nach dem Lesen der Daten in ihrer eigenen Compute-Schicht aus.

Das leistungsfähigste Muster über mehrere Quellen hinweg ist die Verwendung von $lookup, um eine aktive Atlas-Collection mit einer in S3 archivierten Collection zu verknüpfen. Starten Sie die Pipeline mit der aktiven Collection (dem „Treiber“) und führen Sie die Suche in der virtuellen, von S3 unterstützten Collection aus. Platzieren Sie frühzeitig ein $match, um die Anzahl der ausgeführten Lookups zu minimieren.

Wenn Ihre föderierte Instanz mehrere Atlas-Cluster-Stores enthält, können Sie Collections aus verschiedenen Atlas-Clustern in einer einzigen Pipeline verknüpfen. Das ist nützlich für mandantenfähige oder multiregionale Bereitstellungen, bei denen Daten auf separate Cluster verteilt sind und Sie clusterübergreifende Berichte benötigen, ohne Cluster zusammenzuführen oder eine separate Reporting-Datenbank aufzubauen.

Nach einer Aggregation über mehrere Quellen können Sie die Ergebnisse mit $out oder $merge zurück in eine aktive Atlas-Collection schreiben. Dies ist das ETL-Muster: historische Daten aus S3 lesen, mit aktiven Daten verknüpfen, Aggregate berechnen und die Ergebnisse in eine materialisierte View-Collection in Atlas schreiben, die Anwendungen anschließend kostengünstig und schnell abfragen können.

Bei Abfragen von Parquet-Dateien wendet Data Federation Spalten-Pruning an: Wenn Ihre $project-Stufe nur bestimmte Felder angibt, liest die Query Engine nur diese Spalten aus der Parquet-Datei, die Daten spaltenweise speichert. Dadurch kann sich die Anzahl der gelesenen Bytes gegenüber dem Lesen aller Spalten um mehr als 90 % verringern. Platzieren Sie $project so früh wie möglich in der Pipeline, um den größtmöglichen Nutzen aus dem Spalten-Pruning zu ziehen.

Atlas Data Federation protokolliert Details zur Abfrageausführung in der Atlas UI auf der Registerkarte Query History. Für jede Abfrage werden die verarbeiteten Bytes, die Ausführungszeit und die Anzahl der gescannten Dateien bzw. Partitionen angezeigt. Eine hohe Anzahl verarbeiteter Bytes deutet meist darauf hin, dass Partitionsattribute fehlen oder die Abfrage keinem Partitionsschlüssel entspricht. Verwenden Sie dieses Protokoll, um Ihre Speicherkonfiguration und Abfragemuster zu optimieren.

S3-Dateien aus unterschiedlichen Zeiträumen oder Systemen können verschiedene Schemas aufweisen (Feldnamen, Typen, Struktur). Data Federation behandelt dies problemlos: Fehlende Felder geben null zurück, zusätzliche Felder werden einbezogen. Mit $ifNull, $cond und $convert können Sie unterschiedliche Schemas in Ihrer Pipeline normalisieren, bevor Sie gruppieren oder Verknüpfungen durchführen.

Data Federation speichert Ergebnisse zwischen Abfragen nicht im Cache – jede Abfrage liest die zugrunde liegenden Quellen erneut. Verwenden Sie für Dashboards, die denselben Bericht wiederholt ausführen, das ETL-Muster: Planen Sie eine Aggregation, die Ergebnisse über $merge in eine Atlas-Collection schreibt, und lassen Sie Ihr Dashboard anschließend die schnelle Atlas-Collection abfragen. Atlas Triggers können diese Aktualisierung in jedem Cron-Intervall planen.

Beachten Sie die aktuellen Einschränkungen: 1) Transaktionen werden auf föderierten Instanzen nicht unterstützt. 2) Die Verwendung von Indizes gilt nur für von Atlas unterstützte Collections, nicht für S3-Dateien. 3) Sehr große Ergebnismengen können zu einem Timeout führen – verwenden Sie $out/$merge, um Ergebnisse zu schreiben, statt sie zurückzustreamen. 4) Die Latenz ist aufgrund der S3-E/A höher als bei einer aktiven Atlas-Abfrage; daher eignen sich solche Abfragen nicht für benutzerseitige Echtzeitabfragen.

In dieser Lektion haben Sie gelernt: Aggregationspipelines über mehrere Quellen verwenden dieselben MongoDB-Stufen für virtuelle Collections, die von S3 oder Atlas-Clustern unterstützt werden; $lookup ermöglicht die Verknüpfung aktiver Atlas-Daten mit S3-Archiven in einer einzigen Pipeline; und ein früh platziertes $project ermöglicht Spalten-Pruning in Parquet-Dateien und reduziert die Anzahl der gelesenen Bytes erheblich. Als Nächstes untersuchen wir die S3-Datenpartitionierung zur Verbesserung der Abfrageleistung.