Das Performance-Handbuch: Datenbanken und Performance

Um Datenbankanwendungen zu optimieren, bedarf es mehr als nur des Wissens, wie wir einen SQL-Befehl aufsetzen. Kenntnisse über die Umgebung der Datenbank und Designmöglichkeiten sollten ebenso zur Verfügung stehen, wie ein guter Datenbankadministrator.

Zunächst sollten Sie versuchen, Ihre Optimierungen so vorzunehmen, dass Sie keine Änderung Ihrer Anwendung oder der Datenstruktur (Datenbankschemata) vornehmen müssen. Andererseits haben Sie hoffentlich beim Design Ihrer Datenbank schon Performance-Überlegungen angestellt.

Treiber

Der richtige Treiber kann bereits viel helfen. Nutzen Sie möglichst stets einen direkten Datenbanktreiber. Der Zugriff per ODBC ist zwar schnell eingerichtet und kann für Prototypen hervorragend genutzt werden, erfordert jedoch mehrfaches Konvertieren der Datenbankabfrage und des Ergebnisses. Naturgemäß führt dies zu langsameren Ergebnissen beim Datenbankzugriff. Beachten Sie auch, dass je nach Programmiersprache unterschiedliche Treiber Verfügung stehen (Beispiel JDBC kennt 4 Treibertypen).

Netzanbindung

Datenbanken, die im Netz liegen, benötigen natürlich eine entsprechende Anbindung. Bei einer hohen Anzahl von Nutzern sollten Sie auch prüfen, ob ein Datenbankcluster zur Lastverteilung ein gangbarer Weg ist.

Im Notfall sollten Sie auch die MTU [Maximum Transfer Unit] des Netzwerk berücksichtigen. Hierdurch können Sie eine unnötige Fragmentation der Ergebnisse vermeiden und auch die Netzwerkbelastung senken. Dies ist jedoch sicher eine Maßnahme, die erst Berücksichtigung finden muss, wenn keine anderen Mittel mehr helfen.

Tablespace

Die richtige Größe des Tablespace ist ein wesentlicher Faktor. Berücksichtigen Sie hierbei auch den UNDO-Tablespace und den Temp-Tablespace. Daneben sollten Sie prüfen auf welchen Filesystemen Sie Ihren Tablespace hosten. Ein Temp-Tablespace gehört auf ein schnelles Filesystem und möglichste nicht auf ein Journaling-Filesystem.

Partionierung des Tablespace

Mit Hilfe von Partionierung von Tablespace können Sie den Zugriff weiter erhöhen. Einige Datenbanken können so schneller einen direkten Zugriff auf die gewünschten Ergebnisse realisieren. Sie müssen hierzu jedoch die relative Verteilung Ihrer Daten kennen.

Schlüssel und Indizes

Datenbanken leben davon, dass auf die Inhalte über (möglichst) eindeutige Schlüssel zugegriffen werden kann. Definieren Sie hier die richtigen Schlüssel für Ihre Abfragen und Sie können schnell einen vielfachen Geschwindigkeitsgewinn erreichen. Wichtig hierbei sind auch die richtigen Indexe für einen schnellen Zugriff. Der hierfür benötigte extra Platz in der Datenbank hält sich dagegen in Grenzen. Haben Sie den richtigen Schlüssel definiert? Nutzen Sie Ausführungspläne zur Prüfung...

Ausführungspläne

Sich Ausführungsplane darstellen zu lassen, ist ein gutes Mittel um Ihre Performance-Anstrengungen zu überprüfen. Diese zeigen z.B. an, ob die bereitgestellten Schlüssel für Ihre SQL-Performance überhaupt zum Einsatz kommen.

Sortierung von Daten

Eine häufige Aufgabe für Datenbanken ist die Ergebnisse zu sortieren. Der Luxus dies einfach im SQL zu integrieren kann uns jedoch teuer zu stehen kommen. Bei der Sortierung großer Datenmengen reicht meist der physikalische bzw. der Datenbank zugewiesenen Speicher nicht mehr aus. In diesem Moment wird auf den Temp-Tablespace/Festplatte ausgelagert bzw. dieser zur Sortierung verwendet. Damit ist es jedoch entscheidend, wie Sie Ihren Tablespace definiert haben.

Ergebnisumfang

Vielfach ist es gar nicht notwendig, alle Ergebnisse zusammen dem abfragenden System/Anwender zu Verfügung zu stellen. Denken Sie einfach an die Suchmaschinen - keine dieser übermittelt sofort alle Ergebnisse bei großen Datenmengen. Dem Nutzer werden hingegen nach definierten Regeln bestimmte Ergebnisse zunächst bereitgestellt. Das Prinzip der Ergebniseinschränkung zusammen mit Hintergrundprozessen/-threads, welche die folgenden Ergebnismengen vorhalten, können eine enorme subjektive Performance bereitstellen - denn überlegen Sie selbst: wie häufig betrachten Sie tatsächlich alle Ergebnisse einer Suche.

Offline- und Onlineabfragen

Für uns als 'normale' Nutzer ist es selbstverständlich, dass wir das Ergebins einer Datenbankabfrage sofort sehen (wollen)^[1]. Aber bei Datawarehouse-Anwendungen, statistischen Auswertungen u.ä. ist dies nicht notwendig. Wir sollten daher auch immer prüfen, ob einige Abfragen überhaupt sofort ein Ergebnis liefern müssen. Vielleicht reicht es ja aus, die eine oder andere Abfrage im Offline Betrieb durchzuführen. Dies kann bei einem geschickten zeitversetzten Auftragsbeginn zudem auch noch die Datenbank entlasten, da diese Abfragen nicht während des normalen Nutzerbetrieb stattfinden müssen (vielleicht laufen diese dann Nachts).

Wo liegt der SQL Befehl?

Geschwindigkeitsvorteile lassen sich auch erreichen, indem die SQL-Abfragen in die Datenbank verlagert werden (Prozeduren). Hier kennt die Datenbank bereits vor dem Aufruf den Befehl und kann entsprechende Optimierungen vornehmen.

Neben der direkten Ablage können auch Storage-Prozeduren zum Einsatz kommen. Hierbei wird der Datenbank ein SQL-Befehl durch die Anwendung zur Optimierung bereitgestellt. Dies lohnt sich insbesondere, wenn diese SQL-Befehle häufig durchgeführt werden sollen.

Connectionanzahl und Wiederverwendung

Die Verwaltung von Connections benötigt nicht unerhebliche Ressourcen. Stellen Sie sich nur vor, für jede Anfrage würden Suchmaschinen eine eigene Verbindung zu Datenbanken auf- und abbauen. Prüfen Sie daher, wieviele Verbindungen zur Datenbank tatsächlich benötigt werden.

Daneben sollten Sie die Verbindungen zur Datenbank wieder verwenden - Connection Pooling. Dies spart unnötigen Overhead, da die Verbindung zur Datenbank nicht ständig neu aufgebaut werden muss.

Datenbankinterna

Reihenfolge der SQL-Auswertung

Es ist nicht verkehrt zu wissen, wie SQL-Befehle durch die verwendete Datenbank ausgewertet werden. Da dies jedoch je Datenbank spezifisch ist, sollten Sie die SQL-Befehle dann auslagern, um eine größere Flexibilität Ihrer Anwendung zu erreichen.

Oracle

Oracle-Datenbanken werten die where-Klausel von rechts nach links aus. Bei Verknüpfen von zwei Tabellen sollten größere Einschränkungen stets zuerst verarbeitet werden. Daher sollte bei Oracle-Datenbanken die größerer Einschränkung rechts stehen. Zum Beispiel:

select * from Kunde K, Bestellung B
 where Datum between ‘1.1.2000’ and ’31.1.2000 23:59’ and Name= ‘Anton’
   and K.kdkey = B.kdkey

Interbase

Interbase wertet die where-Klausel von links nach rechts aus. Bei Verknüpfen von zwei Tabellen sollten größere Einschränkungen stets zuerst verarbeitet werden. Daher sollte bei Interbase die größerer Einschränkung links stehen. Zum Beispiel:

select * from Kunde K, join Bestellung B on K.kdkey=B.kdkey
 where “Anton” 
   and Datum between “1.1.2000” and “31.1.2000 23:59”

↑ Was sofort ist, wurde hoffentlich im Lastenheft definiert?

Zurück zu Implementierung |

Hoch zu Inhaltsverzeichnis |

Vor zu Implementierung mit Java

[1] Was sofort ist, wurde hoffentlich im Lastenheft definiert?

[1]