Das kann schon mal passieren: Da wird eine Datenbank eingesetzt, um Kunden glücklich zu machen, und dann sind sie es doch nicht: Ein System, das alles tut, was es soll, macht dennoch nicht zufrieden, wenn es zu lange dafür braucht. Was man in der Situation tun kann, heißt Performance-Optimierung. Wie geht das, so ein System zu beschleunigen? Mit dieser Frage darf ich mich aktuell beschäftigen.
Profiling
Es ist so wie in der Medizin: Bevor man behandelt, ist es sinnvoll, zu diagnostizieren. Sonst steckt man leicht zu viel Aufwand in Bereiche, die nur selten gebraucht werden. Profiling heißt diese Diagnose, wenn man sie für eine Datenbank durchführt. Dazu braucht man die Information, welche Datenbankabfragen durchgeführt werden und wie lange die Datenbank jeweils braucht, um sie durchzuführen.
Hier kann es auch sinnvoll sein, zu messen, wie lange eine Benutzerabfrage insgesamt dauert. Schließlich braucht die Datenbank nicht die gesamte Zeit der Abfrage, der Seitenaufbau ringsherum braucht auch noch seinen Anteil.
Wenn ein Kunde 30 Sekunden auf eine Antwort wartet, die Datenbank aber nur 5 Sekunden beschäftigt ist, bringt die Optimierung der Datenbankabfrage kaum eine Verbesserung. In dem Fall ist es sinnvoller, das „Ringsherum“ zu beschleunigen.
Wenn man sämtliche Datenbankabfragen und Abfragezeiten hat – und da kommen schon mal Millionen Datenbankabfragen zusammen – geht es ans Zählen. Man will wissen, wie oft Datenbankabfragen aufgerufen wurden und wie lange sie durchschnittlich gedauert haben. Dabei hilft wieder eine Datenbank, weil es einfach zu viele sind, um das mit dem Taschenrechner zu machen. Skripte erledigen diesen Job.
Schließlich kann es sein, dass eine Abfrage zwar lange dauert, aber nur alle paar Wochen einmal aufgerufen wird. Eine andere Abfrage dauert vielleicht nur halb so lange, wird aber im selben Zeitraum eine Million mal aufgerufen. Wenn man die Zeiten für jede Abfrage aufsummiert und sich die Daten dann sortiert nach der Gesamtzeit anschaut, bekommt man die “Hot Spots”, mit denen die Datenbank überwiegend beschäftigt ist. Wenn man die kennt, kann man sich an die eigentliche Optimierung machen.
Der Index – auf die Reihenfolge kommt es an
Der wichtigste Ansatzpunkt, um Datenbankabfragen zu beschleunigen, sind die Indizes. Bei Datenbanken ist die Sortierung entscheidend dafür, wie lange eine Abfrage dauert. Den Unterschied können Sie an der Datenbank in Ihrem Gehirn ganz einfach nachvollziehen. Sagen Sie in Gedanken einmal die Monate auf! …..
Das werden Sie zeitlich sortiert gemacht haben – Januar, Februar, März, … – und das geht recht schnell. Versuchen Sie es nun nochmal, aber diesmal alphabetisch 🙂
Sie haben es gemerkt: April, August, Dezember, Februar…., in dieser Reihenfolge dauert es viel, viel länger.
Bei einer Datenbank ist es genauso. Wenn sie die Daten in der entsprechenden Reihenfolge parat hat – bei Datenbanken heißt das Index – gehen Abfragen schnell. Wenn sie das nicht kann, muss sie alle Daten anschauen, und das kann bei großen Datenmengen sehr lange dauern. Aber Vorsicht: Die Daten in allen möglichen Reihenfolgen abzulegen, hilft nicht unbedingt. Dadurch wird zwar das Lesen beschleunigt, aber es braucht natürlich auch Zeit, einen Index anzulegen und bei Änderungen aktuell zu halten. Einen Index wird man also dann anlegen, wenn es um große Tabellen geht und wenn man die Daten in der entsprechenden Reihenfolge auch wirklich braucht. Sonst kostet ein Index die Anwendung nur unnötige Zeit.
Locks – sind nötig, aber kosten Zeit
Außer dem Index gibt es natürlich noch ein paar weitere Dinge, auf die man bei der Performance-Optimierung achten sollte: So kann die Datenbank zum Beispiel, während Daten geschrieben werden, diese Daten nicht anderen Kunden zur Verfügung stellen. Sie würden ja je nach Abfragezeitpunkt nur die halben Daten bekommen. Dieser Mechanismus heißt “Locking”. Und wenn eine Datenbank oft in dieser Situation ist, kann es sich lohnen, die Datenbank strukturell so zu ändern, dass das seltener passiert.
Auch große Ergebnismengen bei Datenbankabfragen können auf Performance-Flaschenhälse deuten. Will der Kunde wirklich eine Tabelle mit 600.000 Zeilen lesen oder kann man die Abfrage geschickter machen, so dass es doch nur 600 Zeilen sind?
Benchmarks
Wenn die akuten Probleme gelöst sind, kann man noch einen Blick in die Zukunft werfen. Wie viele parallel arbeitende Benutzer verträgt das System und wie viele gibt es aktuell? Wächst die Anzahl der Benutzer vielleicht? Es ist sinnvoll, die Grenzen seines Systems zu kennen, damit man rechtzeitig größere und schnellere Rechner bereit hat, ehe das vorhandene System überlastet ist. Mit einem Programm kann man die Benutzer simulieren und weiß dann schon vorher, mit welcher Last das System noch zurechtkommt und ab wann es das nicht mehr kann.
So ermöglichen Benchmarks ein entspannteres Arbeiten.
Schließlich ist es keine angenehme Aufgabe, unter Zeitdruck ein System auf stärkere Rechner “umzuziehen”, während verärgerte Benutzer anrufen, weil sie mit dem überlasteten System nicht mehr arbeiten können.