Speicher-Engine – ihre Rolle bei der Optimierung von DAX-Abfragen in LuckyTemplates

In diesem Tutorial werfen wir einen Blick auf die zweite Engine innerhalb der Analysedienste – die Speicher-Engine.

Wir haben die Top-Level-Engine, die Formel-Engine , in einem früheren Tutorial besprochen. Wenn Benutzer verstehen, wie diese beiden Engines funktionieren, ist es einfacher, die Leistung Ihrer DAX-Abfragen zu optimieren und zu verbessern.

Der Hauptzweck der Speicher-Engine besteht darin, direkt mit der Datenbank zu arbeiten.

Die Formel-Engine hat keinen direkten Zugriff auf die Datenbank und greift zu diesem Zweck normalerweise auf die Speicher-Engine zurück.

Die Speicher-Engine gibt es in zwei Ausführungen: Importmodus und DirectQuery . Sie können beide Typen im selben Datenmodell kombinieren und abgleichen, um ein zusammengesetztes Modell zu erstellen.

Inhaltsverzeichnis

• Arbeiten mit dem Importmodus in der Storage Engine
• Arbeiten mit DirectQuery in der Storage Engine
• Arbeiten mit zusammengesetzten Modellen
• Weitere kritische Punkte zur Storage Engine
• Arbeiten an komplizierten Abfragen
• Abschluss

Arbeiten mit dem Importmodus in der Storage Engine

Lassen Sie uns zunächst über den Importmodus sprechen. Dies ist auch häufiger als Vertipaq bekannt, wird aber auch xVelocity oder In Memory Columnar Database genannt.

Es gibt vier wichtige Dinge, die Sie bei der Funktionsweise des Importmodus verstehen sollten.

Zunächst erstellt Vertipaq eine Kopie der Daten direkt aus der Datenquelle und speichert sie im komprimierten Format im RAM .

Zweitens basieren die im Importmodus verarbeiteten Daten auf dem letzten Aktualisierungsvorgang . Das heißt, wenn Sie Ihre Daten zuletzt letzte Woche aktualisiert haben, handelt es sich bei den Daten, mit denen Sie es zu tun haben, immer noch um dieselben Daten der letzten Woche. Dies ist besonders wichtig, wenn Sie ein zusammengesetztes Setup verwenden, bei dem sich eine Tabelle im Importmodus und die andere Tabelle im DirectQuery-Modus befindet.

Nehmen wir an, Sie haben die Tabelle „Produkte“, die letzte Woche aktualisiert wurde, im Importmodus. Was die Sales-Tabelle betrifft, haben Sie sich aufgrund ihrer Größe dafür entschieden, sie über DirectQuery zu verarbeiten. Nehmen wir außerdem an, dass Sie Ihren Bericht auf der Grundlage beider Tabellen erstellen, indem Sie die Spalte „Marke“ einfügen und eine Gesamtumsatzkennzahl über derselben Umsatztabelle erstellen. Sie möchten auch den Verkaufsbetrag basierend auf der Marke visualisieren.

Sie müssten zuerst die aus dem Importmodus stammenden Daten aktualisieren, da Sie möglicherweise frische und aktualisierte Daten von DirectQuery und veraltete Daten von Vertipaq erhalten. Dadurch bleiben einige leere Zeilen in Ihrer Matrix und Ihrer Visualisierung übrig.

Das nächste, was Sie über Vertipaq wissen müssen, ist, dass nur grundlegende Operationen wie , , , oder nativ verfügbar sind . Das bedeutet, dass die Speicher-Engine die Formel-Engine aufrufen müsste, um diesen Teil des Codes aufzulösen, wenn der Abfrageplan weitere kompliziertere Vorgänge enthält.

Schließlich ist die Speicher-Engine aufgrund der Spaltenstruktur von Vertipaq eine hochoptimierte Datenbank . Das bedeutet, dass alle Daten spaltenweise und nicht zeilenweise gespeichert werden. Aufgrund dieser Struktur ist Vertipaq immer schneller als eine DirectQuery-Verbindung, selbst wenn Sie Indizes in Ihrem relationalen Datenmodell erstellen.

Arbeiten mit DirectQuery in der Storage Engine

Die nächste Option, die uns innerhalb der LuckyTemplates-Analysedienste zur Verfügung steht, ist DirectQuery. Wenn Sie die DirectQuery-Verbindung verwenden, fungieren die Analysedienste nur als Durchleitung für die Abfragen, die von der Formel-Engine gesendet werden.

Nehmen wir also an, Sie schreiben eine Abfrage. Die Formel-Engine generiert einen Abfrageplan. Anschließend wird die Abfrage an die Speicher-Engine weitergeleitet, bereits übersetzt in die Muttersprache der Datenbank. Meistens erfolgen diese Abfragen in SQL.

Wenn die Abfrage DirectQuery verwendet, müssen Sie davon ausgehen, dass sie jederzeit aktuell ist. Sie müssen sich keine Gedanken darüber machen, wann Sie die Daten zuletzt aktualisiert haben.

Der Prozess der Optimierung des DAX-Codes und des Datenmodells hängt auch davon ab, wie die relationale Datenbank erstellt wurde. Wenn Ihre Spalten Indizes enthalten, werden Ihre Abfragen immer optimiert. Wenn Ihre Datenbank jedoch nicht für die Erstellung von Berichten mithilfe von Analysediensten oder LuckyTemplates optimiert ist, kann es zu einigen Leistungsproblemen kommen. Seien Sie daher bei der Erstellung Ihrer Datenbanken für die Berichtsentwicklung bewusst.

Arbeiten mit zusammengesetzten Modellen

Die dritte Möglichkeit besteht darin, ein zusammengesetztes Modell zu erstellen, sodass Sie eine Tabelle im Importmodus und eine andere Tabelle in DirectQuery haben können.

Wenn Sie zwei Tabellen aus unterschiedlichen Quellen verwenden, sendet die Formel-Engine eine Anfrage an Vertipaq und eine weitere Anfrage an die DirectQuery-Datenquelle. In beiden Fällen rufen Analysedienste auch den Datencache sowohl von Vertipaq als auch von DirectQuery ab. Die Formel-Engine verwendet dann JOIN, oder eine beliebige Iteration für beide Datencaches, bevor sie die Ergebnisse dem Endbenutzer bereitstellt.

Angenommen, Sie möchten in Ihrem Bericht den Umsatz nach Produktmarke visualisieren. Die Formel-Engine sendet eine Anfrage an Vertipaq, wo sie das Produkt, die Marke und den Produktschlüssel abruft. Anschließend wird versucht, über DirectQuery den Umsatz, den Nettopreis, die Verkaufsmenge und den Produktschlüssel für den Verkauf abzurufen.

Sobald die beiden Daten-Caches auf der Grundlage des Produktschlüssels vorhanden sind, werden die beiden Daten-Caches zusammengeführt und der Gesamtumsatz berechnet. Anschließend werden die Ergebnisse dem Endbenutzer präsentiert.

Weitere kritische Punkte zur Storage Engine

Nachdem wir uns nun mit den verschiedenen Typen befasst haben, gibt es noch einige weitere wichtige Faktoren, die Sie über die Speicher-Engine wissen müssen, um Ihre DAX-Abfragen zu optimieren.

Wie ich bereits erwähnt habe, stellt die Speicher-Engine den Datencache in Form eines unkomprimierten Datencaches an die Formel-Engine zurück. Wenn Sie sich im Importmodus befinden, wird die Anforderung, die dabei an Vertipaq zurückgesendet wird, in einer xmSQL-Sprache ausgeführt.

Die xmSQL-Sprache ähnelt in gewisser Weise SQL, ist aber nicht völlig identisch. Wir werden xmSWL im Detail besprechen, wenn wir in einem anderen Tutorial über Abfragepläne sprechen.

Denken Sie auch daran, dass die Speicher-Engine alle in Ihrer CPU verfügbaren Kerne nutzt. Die Möglichkeit, mehrere Kerne zu verwenden, ist vorteilhaft, wenn Ihr Datenmodell mehrere Segmente enthält.

Nehmen wir an, Sie haben eine Tabelle in LuckyTemplates mit 12 Millionen Zeilen. Diese Tabelle wird dann in 12 Segmente unterteilt, da in Power Pivot und LuckyTemplates jedes Segment 1 Million Zeilen umfasst. Dies unterscheidet sich von Analysediensten im Allgemeinen, bei denen ein Segment 8 Millionen Zeilen umfasst.

Wenn ich also sechs Kerne in meiner CPU habe, scannen alle sechs Kerne gleichzeitig die ersten sechs der 12 Segmente. Sobald sie fertig sind, werden sie mit den nächsten sechs Segmenten fortfahren.

Wenn ich jedoch mit Analysediensten arbeite, bei denen das Standardsegment 8 Millionen Zeilen enthält, werden nur zwei meiner sechs Kerne verwendet – ein Segment verarbeitet 8 Millionen Zeilen, während das andere 4 Millionen verarbeitet.

Arbeiten an komplizierten Abfragen

Zuvor habe ich erwähnt, dass der Importmodus nur grundlegende Operationen wie MIN, MAX, SUM, COUNT und GROUPBY unterstützt. Was passiert also, wenn Sie an komplizierteren Abfragen arbeiten?

Nehmen wir an, Sie entscheiden sich dafür, eine IF-Anweisung im Zeilenkontext oder eine verschachtelte Iteration wie SUMX über die Tabellen „Products“ und „Sales“ zu verwenden.

In diesem Fall ist die Speicher-Engine nicht in der Lage, die Abfrage selbst aufzulösen. Anschließend wird die Formel-Engine aufgerufen, die mit der Lösung der komplexen Berechnung Zeile für Zeile innerhalb der Speicher-Engine beginnt. Manche denken vielleicht, dass dies ein günstiges Szenario ist, wenn beide Motoren zusammenarbeiten – aber das ist weit von der Wahrheit entfernt.

Wenn dies geschieht, kann der von der Speicher-Engine erzeugte Datencache nicht zwischengespeichert werden, falls in dieser bestimmten Abfrage eine CallbackdataID vorhanden ist. Wenn Sie also das Visual aktualisieren, muss die gleiche Berechnung sowohl von der Formel-Engine als auch von der Speicher-Engine durchgeführt werden, auch wenn Sie die gleiche Abfrage erst vor ein paar Sekunden ausgeführt haben. Dies führt zu Leistungsverzögerungen und einer schlechten Benutzererfahrung.

Beachten Sie außerdem, dass die Speicher-Engine nicht weiß, ob Abfragen mit DAX oder MDX ausgeführt wurden. Wie bereits erwähnt, ist es die Aufgabe der Formel-Engine, die Abfragen in die richtige Sprache zu konvertieren, bevor sie den Abfrageplan weitergibt.

Schließlich sendet die Formel-Engine nacheinander Abfragen an die Speicher-Engine. Das bedeutet, dass es wirklich besser ist, mehrere Segmente zu haben, sodass die gesamte Scanzeit in Vertipaq reduziert werden kann, da mehrere Segmente gleichzeitig gescannt werden.

DAX für LuckyTemplates: Optimierung mithilfe von Formel-Engines in DAX Studio,
Techniken und Lektionen zur DAX-Abfrageoptimierung,
Abfrageleistung und DAX Studio-Setup

Abschluss

Das Verständnis der Besonderheiten der Speicher-Engine hilft wirklich bei der Optimierung Ihrer DAX-Abfragen, insbesondere wenn Sie DAX Studio verwenden. Wenn Sie auch das Tutorial zur Erläuterung der Formel-Engine durchgearbeitet haben, können Sie bessere Entscheidungen zum Erstellen leistungsfähigerer Abfragen treffen.

Obwohl die Formel-Engine als Top-Level-Engine fungiert, besteht kein Zweifel daran, dass sie nicht so gut funktionieren kann, wie sie kann, wenn wir nicht beide Engines maximieren.

Alles Gute,