Performance-Killer im VDM: 5 typische CDS-Anti-Patterns und wie diese systematisch erkannt werden können

Es gibt zwei Wege, um in CDS-Views Daten aus mehreren Entitäten zu verbinden: den klassischen Join und die Assoziation. Der entscheidende Unterschied liegt im Ausführungszeitpunkt: ein JOIN im SELECT … FROM wird standardmäßig immer ausgeführt, sobald die View gelesen wird – unabhängig davon, ob die Felder der verbundenen View in der Abfrage benötigt werden. Die Assoziation fungiert hingegen als „Join auf Vorrat“. Die Assoziation wird nur dann zum Join, wenn ein Feld in der Abfrage benötigt wird („Lazy Evaluation“). 

Insbesondere in wiederverwendbaren Interface-Views, die typischerweise mehrere Entitäten zusammenführen und viele Felder für die darauf aufsetzenden Views bereitstellen, können Joins schnell zum Flaschenhals werden.

Tipp: Alternativ dazu kann man auch im JOIN den Zusatz „TO ONE“ vergeben, wenn diese Kardinalität fachlich zutrifft. Der Unterschied zwischen einem LEFT OUTER JOIN TO ONE und einer Assoziation liegt technisch darin, zu welchem Zeitpunkt ungenutzte Felder wegoptimiert werden. Bei der Assoziation erfolgt dies komplett deterministisch, der Optimizer muss sich also nicht darum kümmern. Beim JOIN muss der Optimizer im Suchraum einen optimalen Plan finden, was jedoch je nach Komplexität nicht garantiert ist. 

Die Möglichkeit zur Wiederverwendung von Views ist eine der großen Stärken von CDS-Views und zugleich eine typische Quelle für schleichende Performance-Probleme. Auch wenn das Modell auf jeder Ebene modular und sauber aussieht, kann die Stapelung von zu vielen Views für den Optimizer zum Verhängnis werden.

Jede Ebene bringt eigene Joins, Berechnungen und Projektionen mit. Der Optimizer muss diesen Baum flach ziehen, um einen geeigneten Ausführungsplan zu erstellen – und je mehr Tabellen und Operatoren zusammenkommen, desto größer wird die Wahrscheinlichkeit, dass der Optimizer auf den Holzweg geführt wird und einen suboptimalen Plan nimmt. 

Tipp: Ab wann die View-Schachtelung zum Problem wird, kann nicht pauschal benannt werden. Als grober Richtwert kann aber gesagt werden, dass 100 zugrundliegende Datenbanktabellen in einer View niemals überschritten werden sollen. In einem konkreten Projekt sollte diese Grenze jedoch individuell geprüft und gegebenenfalls weiter eingeschränkt werden.

Berechnete Felder sind ein mächtiges Werkzeug bei der Modellierung von CDS-Views, da auf diesem Weg komplexe fachliche Logik virtuell berechnet werden kann, ohne von einer Persistenzschicht abhängig zu sein. Hier sollte man jedoch aufpassen, dass man dem Optimizer keine Steine in den Weg legt. Das Problem: Berechnungen sind für den Optimizer grundsätzlich opak. Eine Berechnung an der falschen Stelle schmälert den Handlungsspielraum des Optimizers und verhindert beispielsweise den Filter-Pushdown. Das tritt insbesondere an zwei Stellen auf: Bei der Filterung mittels WHERE und in der ON-Bedingung von JOINs.

Sobald ein WHERE auf einem berechneten Feld aufsetzt (auch CAST zählt dazu), muss die Berechnung zwangsläufig für die gesamte Datenmenge ausgeführt werden, bevor der Filter angewendet werden kann. Aus einer gut gemeinten Einschränkung, die im Idealfall entlastend wirken soll, wird so ein Full-Table-Durchlauf. Besser ist es, nur die Originalfelder der zugrundeliegenden Tabellen für die Filterung zu verwenden, da so der Filter früher angewendet werden kann.

Im ON-Teil eines JOINs sind Berechnungen noch fataler: Ein Join ist genau dann am effizientesten, wenn die Gleichheit zweier Spalten geprüft wird. Sobald eine Berechnung ins Spiel kommt, leidet sowohl die Effizienz des Joins, als auch die Filter-Propagierung, die bei JOINs über den ON-Teil erfolgt. Problematisch sind neben „echten“ Berechnungen zudem auch die Nicht-Gleichheitsoperatoren >, < und LIKE. Es sollte in diesen Fällen dringend geprüft werden, ob man Einschränkungen dieser Art wirklich im JOIN vornehmen muss oder gegebenenfalls auslagern kann. 

Tipp: Bei sehr komplexen Berechnungen, die zwangsläufig auf großen Datenmengen laufen, sollte evaluiert werden, ob die Logik nicht eher ein Kandidat für die Persistierung ist, um wiederholte Laufzeitberechnungen zu vermeiden.

Ein verbreiteter, gut gemeinter Reflex bei der Modellierung ist es, leere Felder „aufzuhübschen": Statt einen NULL-Wert stehen zu lassen, ersetzt man ihn über ein CASE mit konstantem ELSE (etwa ELSE '' oder ELSE 0) durch einen festen Standardwert. Fachlich sieht das sauberer aus – für den Optimizer wird es jedoch zum Bremsklotz.

Der Hintergrund: Bei einem LEFT OUTER JOIN liefert die rechte Seite NULL, wenn kein Partnersatz existiert. Genau diese NULL-Semantik nutzt der Optimizer, um überflüssige Joins zu eliminieren und die Reihenfolge von Join und Berechnung frei zu wählen. Kapselt man ein Feld aus dem Outer Join aber in ein CASE, das dank konstantem ELSE nie NULL zurückgibt, ist die Berechnung nicht mehr „NULL-erhaltend". Der Optimizer darf die Ausführungsreihenfolge von Join und Berechnung dann nicht mehr vertauschen – und verliert die Möglichkeit, den Join wegzuoptimieren.

Besonders teuer wird das in wiederverwendbaren Views, die selbst als rechte Seite eines Joins in darüberliegenden Views dienen: Ein einziges konstantes ELSE kann dort den zugehörigen Join für alle Konsumenten festnageln – auch für jene, die das Feld nie abfragen. 

Tipp: NULL-Werte überall zulassen, wo es fachlich vertretbar ist. Ist ein Standardwert unverzichtbar, gehört er in eine höhere View-Ebene oberhalb des Joins.

Eine Aggregation, also GROUP BY in Verbindung mit SUM, COUNT, MAX oder MIN, bereits weit unten im Modell einzubauen, kann dem Optimizer in vielen Fällen Probleme bereiten. 

Intuitiv fühlt es sich richtig an, da auf diese Weise bereits früh wichtige Transformationen der Daten erfolgen können. Für den HANA-Optimizer ist ein GROUP BY aber grundsätzlich eine Barriere im Ausführungsplan. Filter, die im Datenmodell „oberhalb“ der Aggregation angesiedelt sind, können nur dann durch diese Barriere geschoben werden, wenn der Filter sich auf einen Gruppierungsschlüssel bezieht.

Kritischer ist der Fall, wenn durch einen (INNER) JOIN eine Einschränkung eingeführt wird. Angenommen wir haben ein Modellierungsszenario mit Sales- und Kundendaten, und es werden auf Kundenebene alle Verkäufe aggregiert. Wenn jetzt durch einen Join nachträglich eine Einschränkung bspw. nach Region der Kunden erfolgt, muss standardmäßig zuerst die Aggregation & Berechnung erfolgen und erst im Anschluss die Einschränkung der Kundenanzahl, was jedoch alles andere als effizient ist. In Fällen wie diesem kann der Optimizer im Idealfall durch eine Semi-Join-Reduktion bzw. Group-By-Pushdown jedoch die Ausführung so verändern, dass statt des skizzierten naiven Plans ein deutlich effizienterer Plan gewählt wird, da das Merkmal „Kunde“ Join- und Gruppierungsschlüssel ist. Es ist jedoch nicht garantiert, dass der Optimizer diesen idealen Plan ableiten kann. Daher ist es sinnvoll, durch geschickte Modellierung diese Unsicherheit zu vermeiden.

Tipp: Filter, die sich auf die Kennzahlen einer Aggregation beziehen, sind deutlich problematischer und erfordern prinzipiell immer, dass die Aggregation zuerst stattfindet. Hier sollte dringend evaluiert werden, ob der Filter nötig ist und möglicherweise dem Optimizer Lösungsräume versperrt.