ADMIN Magazin Gestapelt - Schneller und sicherer mit RAID (Vorschau)

Basics
Ausführungspläne
Bei einem Indexzugriff können Filterprädikate
auch ein Zeichen für eine falsche
Spaltenreihenfolge sein (Beispiel 2).
Nur wenn als Zugriffsprädikat die Werte
»access« oder »seek predicate« angezeigt
werden, nutzt die Abfrage den Index optimal
aus.
Beispiel 3: Ausführungsplan einer PostgreSQL-Datenbank
01 postgres=# EXPLAIN 1
02 postgres‐# SELECT *
03 postgres‐# FROM sales s
04 postgres‐# JOIN employees e ON (s.employee_id = e.employee_id)
Filter- und Zugriffsprädikate können
sinngemäß auch bei der Suche in einem
gedruckten Telefonbuch vorkommen,
wenn man zum Beispiel nur den Nachnamen
und die Anschrift der gesuchten
Person kennt. Dabei ist der erste Schritt,
etwa alle Einträge für „Müller“ zu finden,
05 postgres‐# WHERE s.sale_date > CURRENT_DATE ‐ INTERVAL '6' MONTH
06 postgres‐# AND s.eur_value >= 10;
07
Beispiel 2: SQL Server-Ausführungsplan erklärt
Hier kann man sich über die Schaltfläche »Display
Estimated Execution Plan« den Ausführungsplan
anzeigen lassen. Bewegt man den
Mauszeiger über eine Operation, öffnet sich
ein Tool-Tip mit zusätzlichen Informationen. Der
Cost-Wert der einzelnen Operation wird gleich
dreimal angezeigt: zuerst aufgeteilt nach I/​
O- und CPU-Cost, dann die Gesamtkosten. Zuletzt
wird auch der Cost-Wert des gesamten
08 QUERY PLAN
09 ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐
10 Hash Join ( 2 cost=3091.01..13119.07 rows=59654 width=1286)
11 Hash Cond: (s.employee_id = e.employee_id)
12 ‐> Index Scan using sale_date on sales s (cost=0.01..3893.82 rows=59654 width=251)
13 Index Cond: (sale_date > (('now'::text)::date ‐ '6 mons'::interval month))
14 3 Filter: (eur_value >= 10::numeric)
15 ‐> Hash (cost=1672.00..1672.00 4 rows=10000 width=1035)
Teil-Baumes angezeigt. Die Gesamtkosten findet
man im Tool-Tip auf oberster Ebene. Das
Filterprädikat (»Predicate«) ist ein Hinweis,
dass die Spalte »EUR_VALUE« nicht an einer
geeigneten Index-Position für eine effiziente
Nutzung steht. Das Zugriffsprädikat (»YSeek
Predicate«) beim Indexzugriff zeigt, dass der
Index nur für die Bedingung auf »SALE_DATE«
effizient genutzt wird.
16 ‐> Seq Scan on employees e (cost=0.00..1672.00 rows=10000 width=1035)
1 Durch das Voranstellen von explain vor die SQL-Abfrage wird der Ausführungsplan angezeigt.
2 Die Cost-Werte werden für jeden Teil-Baum des Ausführungsplanes angezeigt. PostgreSQL zeigt
dabei jeweils zwei Werte an: zuerst die Setupkosten, dann die Gesamtkosten.
3 Das Filterprädikat beim Indexzugriff ist bei PostgreSQL ein Hinweis, dass die Spalte EUR_VALUE
nicht im Index SALE_DATE vorhanden ist.
4 Durch die rows- und width-Werte beim Hash-Zweig der Join-Operation kann man auf den Speicherbedarf
schließen. Dadurch wird auch deutlich, dass der Speicherbedarf nicht nur von den Zeilen,
sondern auch von den selektierten Spalten – der Zeilenlänge – abhängig ist. Selektiert man
weniger Spalten, reduziert sich der Speicherbedarf.
sehr rasch erledigt. Aufgrund der Sortierung
des Telefonbuches kann man sich
durch Vor- und Zurückblättern schnell
an „Müller“ annähern. Genau genommen
führt man dabei eine binäre Suche durch,
deren Aufwand nur logarithmisch mit der
Größe des Telefonbuches wächst. Anders
gesagt, wenn das Telefonbuch zehnmal
so groß ist, dauert die Suche deswegen
nicht auch gleich zehnmal so lange.
In einer Datenbank wäre die Bedingung
NACHNAME=’MÜLLER’ daher ein Zugriffsprädikat.
Hat man die „Müllers“
gefunden, bleibt noch die Eingrenzung
mit der bekannten Adresse. Ohne den
Vornamen zu kennen, kann man aber
die Sortierung des Telefonbuches nicht
weiter nutzen. Es bleibt einem also nichts
anderes übrig, als alle „Müllers“ durchzugehen.
In einer Datenbank wäre diese
Bedingung daher ein Filterprädikat. Die
Suchdauer steigt linear mit der Anzahl
der „Müllers.“
Filtern dauert viel länger
Der Unterschied zwischen Zugriffs- und
Filterprädikaten wird häufig unterschätzt,
kann aber durchaus beachtlich sein. Abbildung
2 stellt den Performance-Unterschied
dar. Im Idealfall – wenn zum
Beispiel nur Zugriffsprädikate verwendet
werden – kann die Geschwindigkeit auch
bei einer stark wachsenden Tabelle nahezu
konstant bleiben (grün dargestellt).
Je mehr Filterprädikate verwendet werden,
desto größer wird der Einfluss der
Tabellengröße auf die Geschwindigkeit
(rot dargestellt). Anders ausgedrückt
kann man durch die Filter- und Zugriffsprädikate
eine Prognose über die Geschwindigkeit
bei wachsendem Datenvolumen
anstellen und dadurch Probleme
im Vorhinein erkennen. Die Ursache des
eklatanten Performance-Unterschiedes
in der Abbildung ist übrigens, dass die
zweite und dritte Spalte im Index vertauscht
wurden.
Bei der Indizierung einer Datenbank
muss man aber unbedingt ganzheitlich
vorgehen. Insbesondere das Ändern der
Spaltenreihenfolge ist gefährlich, weil
es den Index für andere Abfragen unbrauchbar
machen kann. Indexänderungen
muss man daher ausgiebig testen,
sorgfältig planen und natürlich mit dem
Applikationshersteller abklären.
90 Ausgabe 06-2012 Admin www.admin-magazin.de