Optimierung von SQL Queries, O/R Mapping und mehr
Auf Wunsch der Trainees und Partnerfirmen organisierte M&F einen Datenbank-Workshop für die Trainees. Hierzu wurde Christian Bohn als Referent eingeladen. Er arbeitet als Teamleiter bei unserer Partnerfirma Sowatec, betreut unter anderem unsere Trainees und kennt sich bestens mit dem Thema aus.
Der Datenbank-Workshop hatte zwei Schwerpunkte. Zum einen nahmen wir SQL-Datenbanken (hier MS SQL) genauer unter die Lupe, speziell was das Verstehen und Optimieren von Queries betrifft. Zum anderen sind wir auf die Thematik von O/R Mapper eingegangen.
SQL Queries
Basics
Eine Datenbank hat den Vorteil, dass man ihren Inhalt nach gewissen Kriterien durchsuchen kann. Damit dies schnell und effizient geschieht, gibt es verschiedene Mechanismen. Eine davon ist die Indexierung der Tabellen. Dabei gibt es grundsätzlich zwei Arten:
|
Clustered index
|
Non-clustered index
|
|---|---|
| Data rows are stored in order of index key | No influence on data row sorting |
| only one clustered index per table | Multiple non-clustered index |
| B-tree, leafs are data rows | B-tree, leafs are key value and a pointer to the data row that contains the key value |
Analyse
Damit man einen gewünschten Datensatz aus einer SQL-Datenbank bekommt, muss man die Anfrage in Form einer Query an die Datenbank senden. Zu diesem Ziel führen meistens sehr viele Wege die jeweils sehr unterschiedliche Performance bieten. Zum Analysieren dieser Queries wurden zwei Hilfsmittel für MS SQL gezeigt:
-
Activity monitor: Dieser zeigt an, was auf der Datenbank momentan alles los ist, inkl. der letzten grösseren Queries, gebrauchten Ressourcen und vieles mehr. Auch bei Datenbank-Zugriffen kann es zu Deadlock-Situationen kommen. Auch hier kann der Activity Monitor helfen, solche Situationen zu visualisieren.
-
Actual/Estimated execution plan: Dieser zeigt alle Aktionen an, die die SQL-Engine macht, damit das gewünschte Resultat zurückkommt. z.B. ob zuerst sortiert wird und dann die Reihenfolge bestimmt usw. Dabei wird unterschieden zwischen Estimated, welche eine Voraussage macht, die praktisch immer tatsächlich so ausgeführt wird. Die geschätzte Zeitdauer sollten jedoch mit Vorsicht genossen werden. Die Actual gibt im Nachhinein detaillierten Einblick was alles passiert ist.
O/R Mapping
Prinzipiell geht es hierbei um die Abbildung von Objekten einer objektorientierten Programmierung in eine relationalen Datenbank (Relational Database Management System - RDBMS) und zurück. Ein O/R Mapper kann diese Abbilden ganz oder teilweise übernehmen. Beispiele:
- Hibernate
- Cayenne
- JPA
- Entity Framework
O/R Mapper Beispiel: arregulo
Im Workshop wird näher auf eine eigene Entwicklung von Sowatec eingegangen, das sog. arregulo-Framework, welches unter anderem auch ein O/R Mapper beinhaltet.
Dieser funktioniert unter anderem indem Java-Klassen stark an die Datenbank gebunden werden. So können zur Runtime neue Klassen erstellt, kompiliert und eingebunden werden. Jedes Attribut einer solchen Klasse hat eine Datenbank-Representation und kann entsprechend jederzeit von oder zur Datenbank geladen werden.
Caching
Caching in O/R Mapper (oder anderen Applikationen) ist ein zweischneidiges Schwert. Zum einen sind Caches unerlässlich, wenn es um die Optimierung von O/R Mapper geht, zum anderen können sie Fehler beinhalten, welche durch die kurzlebige Natur von Caches sehr mühsam zum finden und korrigieren sind.
Dabei ist es wichtig, dass eine Balance gefunden wird zwischen Cache-Strategien, welche relativ einfach und dafür nicht sehr effizient sind und Strategien, welche sehr intelligent sind, aber ein hohes Fehlerpotential bergen.
Caching in arregulo
Zum bessern Verständnis wird ein Beispiel von arregulo gezeigt. Dabei wird zuerst die Objekt-Struktur eines Objekts vorgestellt:
|
Object |
Function |
|---|---|
| BrmObject | Lightweight wrapper that represent Arregulo object as defined by programmer or generated. |
| DataObject | Data object is a container for attributes, defined as static inner class in the wrapper. |
| DataObjectLink | “Technical” object containing cache-related information. DataObjectLink is created and managed by Arregulo. |
In einer Anwendung kann es sehr viele solcher Objekte geben, welche selber auch relativ gross werden können. Um dies zu optimieren verwendet man einen Cache, damit nur das leichtgewichtige BrmObject und dessen Link DataObjectLink pro User vorkommt und das eigentliche Objekt (DataObject) nur in einer einzigen Instanz. Siehe dazu das nächste Bild:
Dies funktioniert natürlich nur so lange, als das keiner der beide User sein Objekt verändert. Sobald dies der Fall ist, wird das DataObject kopiert und jeder User hat seine eigene Version, bis das Objekt zurückgeschrieben (oder gelesen) wird.
Kommentare