
CDS - Performance
Wie sieht es eigentlich bei der Nutzung von Core Data Services mit der Performance bei den Zugriffen aus, kann man Fehler dabei machen?
Inhaltsverzeichnis
In diesem Artikel schauen wir uns einmal die Performance von CDS Views an und wie sie sich beim Zugriff auf die Daten verhalten. Die HANA Datenbank ist sehr schnell, doch nicht in jedem Fall. Diese Punkte schauen wir uns einmal etwas genauer an.
Non HANA System
Core Data Services können seit 7.40 SP5 genutzt werden, dazu zählen auch die "alten" ECC Systeme ohne HANA Datenbank. Wenn du auf so einem System arbeitest, solltest du vorsichtig sein mit der Performance, wenn du Datenmodelle auf CDS Basis baust. Ein Code-Pushdown sollte hier noch vermieden werden, ebenso sollte viel mit den Schlüsseln der Tabelle gearbeitet werden, egal ob Primärschlüssel oder Sekundärindex. Auf so einem System lohnt sich auch eine Performanceanalyse, da komplexe CDS Views schnell langsamer sein können als Tabellenzugriffe aus der Applikationsschicht.
Komplexität
Beim Design der Viewstruktur sollte die Komplexität im Auge behalten werden. Consumption Views sind meistens auf ihr Anwendung zugeschnitten und nicht für die Wiederverwendung in weiteren Anwendungen gedacht. In solchen Fällen sollte pro Anwendung ein neuer CDS View definiert werden, der genau die Anwendung darstellt.
Weiterhin sollte darauf geachtet werden, dass der Consumption View auf Interface Views basiert, die sauber implementiert wurden. Also auf möglichst einer Tabelle basieren und ihre Verknüpfungen per Assoziation zur Verfügung stellen. Basic Views mit Joins sollten vermieden werden, da hier unnötige Daten zur Laufzeit gelesen werden.
Berechnete Felder
Berechnete Felder können aus Berechnungen oder Funktionen bestehen und existieren nicht auf der Datenbank. Bei solchen Feldern solltest du vorsichtig sein, wenn darüber gefiltert werden soll, da hier viel Performance verloren geht, da erst alle Datensätze der Datenbnak berechnet werden müssen, bevor der Filter angewendet wird. Am besten sind Felder, die es auch auf der Datenbank gibt.
Einfachstes Beispiel ist der Geschäftspartner, bei dem Vor- und Nachname in zwei unterschiedlichen Feldern abgespeichert wird. Im View kann man nun ein kombiniertes Feld zur Verfügung stellen. welches die beiden Felder in einem vollständigen Namen zur Verfügung stellen. Wenn nun der Anwender in der Anwendung hingeht und über dieses berechnete Feld die Menge eingrenzt, weil er alle Nachname mit "*Schmidt" haben möchte, dann müssen alle Datensätze der Datenbank gelesen, verbunden und ausgewertet werden. Wenn der Filter "Schmidt" auf das Feld Nachname geht, dann können direkt die Zeilen mit der Übereinstimmung geliefert werden.
Berechtigung
In unserer Serie hatten wir bisher noch nicht das Berechtigungskonzept besprochen, doch dieses hat ebenfalls Auswirkungen auf die Performance beim Zugriff. Je komplexer und vielfältiger die Abfragen der Berechtigungsobjekte sind, um so langsamer kann auf die Datenbeschaffung werden. Auf das Berechtigungskonzept werden wir noch in einem späteren Artikel eingehen.
Schnelle Zugriffe
Wieso sind Zugriffe auf eine HANA Datenbank so schnell, obwohl wir vielleicht gar nicht den Schlüssel der Datenbank ansprechen? Dabei musst du wissen, dass auf der HANA Datenbank jede Spalte einer Tabelle ein Index ist, solange die Tabelle als "Column-Store" definiert ist. Damit geht jeder Zugriff gegen den Schlüssel und ist automatisch schnell. Dies ist der große Unterschied zur klassichen zeilenbasierten Datenbank, die nicht im Arbeitsspeicher läuft.
Fazit
Zugriffe auf eine Tabelle oder einen CDS View auf einer HANA Datenbank sind unheimlich schnell, allerdings solltest du dir als Entwickler trotzdem einiges an Gedanken machen, wenn du komplexe Viewstrukturen aufbaust. Ebenso wie die Anwender am Ende deine Anwendung nutzen.