Datenbanken und Performance
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 Indexe
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 ein paar hundert Prozent Geschwindigkeitsgewinn erreichen. Wichtig hierbei sind auch dir 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
Ausführungsplane sich darstellen zu lassen, ist ein gutes Mittel um Ihre Performanceanstrengungen 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 Hintegrundprozessen / -threads, welche die folgenden Ergebnissmengen 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 Ergebiss 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 Befehlt häufig durchgeführt werden sollen.
Connectionanzahl und Wiederverwendung
Die Verwaltung von Connections benötigt nicht unerhebliche Resourcen. 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. Leider unterstützt nicht jeder Programmiersprache gleich Connection Pooling, aber da hilft manchmal auch die Datenbank (siehe Datenbankinternas)
Sortierung - der order by
Die Sortierung von Datenbanksätzen benötigt bei einem großen Resultset nicht unerhebliche Zeit. Hier ist ein Blick auf den Datenbankserver / -rechner uns einen wertvollen Hinweis geben. Wenn der temp-tablespace hier genutzt wird ist es immer sinnvoll den der Datenbank zugewiesenen Arbeitsspeicher zu betrachten. Auch sollte geprüft werden ob die Sortierung gerade für Batchläufe notwendig ist. Hierbei müssen wir berücksichtigen, dass unsere Fachanwendungen erst dann die ersten Daten zur Bearbeitung bekommen (ResultSet), wenn die Sortierung abgeschlossen ist. Benötigen wir keine Sortierung erfolgt die Datenbankrückgabe somit wesentlich schneller.
Die Verdoppelung auf 8 GB Arbeitsspeicher brachte so bei einer Sortiermenge von ca. 90 Millionen Datensätzen mit einem Index rund 50% Geschwindigkeitsgewinn für diese Sortierung.
Datenbankinternas
Einige Datenbankspezifika ermöglichen uns durch deren Nutzung die Performance zu erhöhen. Natürlich ist es so, dass wir damit ein bisschen - oder auch ein bisschen mehr die Abhängigkeit zur Datenbank erhöhen.
So ist es nicht verkehrt zu wissen, wie SQL Befehle durch die verwendete Datenbank ausgewertet werden. Durch die Auslagerung der SQL Befehle können wir hier tatsächlich unsere Datenbankunabhängigkeit bewahren.
Oracle
Einige Möglichkeiten für Oracle...
SQL Befehlsaufbau
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 ’1.1.2000’ and ’31.1.2000 23:59’ and Name= ’Anton’ and K.kdkey = B.kdkey
rowid für UPDATE nutzen
Nicht immer ist es möglich einen eindeutigen Schlüssel zu verwenden um seine Daten abzulegen. In solchen Fällen lässt sich mit Hilfe der rowid ein schneller Zugriff scheinbar nur über die genaue Angabe der Felder ermöglichen. Gerade bei umfangreichen Update Anweisungen kann dies schon mal etwas länger dauern. Hier hilft uns die rowid als eindeutiger Schlüssel / Index für unsere Tabelle.
So können gerade umfangreiche Pflegearbeiten sehr schnell realisiert werden. (M)Ein guter Datenbankadministrator hat durch diesen Tipp die hochgerechnete Laufzeit von 70 Jahren für eine Zeichenbereinigung von etwa 92.000.000 Datenbankeinträgen und rund 70 zu prüfenden Spalten auf gute 4 Stunden reduziert ohne dass die Fachlichkeit der zugrundeliegenden Java Anwendung angepasst werden musste.
SELECT a, b, rowid FROM myTable;
Connection Pooling durch die Datenbank (11g+)
Mit Version 11g hat Oracle das "Database Resident Connection Pooling" eingeführt. Damit können wir das Connection Pooling direkt durch die Datenbank bereitstellen unabhängig von der nutzenden Anwendung.
In der Datenbank wird zunächst der Connection Pool eingeschaltet.
EXECUTE DBMS_CONNECTION_POOL.START_POOL
Die Anwendungen selbst müssen beim Aufbau der Verbindung nun nur entsprechend die Nutzung des Feature anweisen.
scott/tiger@127.0.0.1:31000/servicename:POOLED
Sofern die tnsnames.ora verwender wird, kann auch hier die Aktivierung erfolgen.
ORA11G_EXT = (
DESCRIPTION = (
ADDRESS =
(PROTOCOL = TCP)
(HOST = schneller.meinedomain)
(PORT = 1521)
)
(CONNECT_DATA =
(SERVICE_NAME = ORA11G.SRV)
(SERVER = POOLED)
)
)
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?