Performance-Optimierung für Datenbankanwendungen

… wenn mit den oben
genannten Tools bereits festgestellt wurde,
dass der Hauptspeicher oft nahezu voll
ausgelastet ist, sollte man seinem Datenbankserver
möglichst viel Hauptspeicher
gönnen, zumal dieser heutzutage nur noch
einen geringen Kostenfaktor darstellt.

Auch die Prozessorleistung kann in
Einzelfällen ein Engpass sein, der ebenfalls
mit den beschriebenen Tools aufgedeckt
werden kann. Generell ist es natürlich ratsam, für einen Datenbankserver
ein Mehrprozessorsystem mit beispielsweise
zwei oder vier CPUs zu nutzen.
Aber auch hier ist es vom verwendeten Betriebssystem
und der SQL Server Edition
abhängig, wie viele Prozessoren wirklich
genutzt werden können.

Wenn eine besonders performancekritische
Anwendung vorliegt, ist es unter
Umständen sinnvoll, alle anderen auf demselben
Server laufenden Anwendungen
und Datenbanken auf einen weiteren
Server zu verlagern. Wurde die Plattengeschwindigkeit
als kritischer Faktor entlarvt,
empfiehlt es sich, die am intensivsten
genutzten Dateien auf verschiedene Platten
zu verteilen, dass die Daten hier möglichst
parallel gelesen werden können. Das
betrifft im Wesentlichen die Windows-Systemdateien,
die Windows-Auslagerungsdatei,
die SQL Server TempDB sowie die
Daten- und Log-Dateien der beteiligten
Datenbanken. Das heißt natürlich nicht,
dass zwingend fünf oder mehr unabhängige
Festplatten zum Einsatz kommen
sollten, zumal in vielen Servern ohnehin
RAID-Systeme genutzt werden, wodurch
die Dateien ohnehin auf mehrere Platten
verteilt sind. Oft bringt es schon einen deutlichen
Performancegewinn, wenn jeweils
eine separate Systempartition für Betriebssystem
und Auslagerungsdatei eingeführt
wird und Daten- und Log-Dateien der
wichtigsten Datenbanken voneinander
trennt werden.

Im Extremfall lassen sich durch die
Nutzung von Filegroups die verschiedenen
Tabellen und Indizes auf unterschiedliche
Platten verteilen und bei der
Enterprise Edition des SQL Server sogar
Tabellen beziehungsweise Indizes selbst
noch einmal durch Partitionierung unterteilen,
doch dazu später mehr. Nach den
eher hardwarelastigen Aspekten muss natürlich
auch die Softwareumgebung unter
die Lupe genommen werden. Selbst wenn
die Entscheidung für den SQL Server 2005
bereits gefallen ist, gilt es, sich auch für die
richtige Variante des Produkts zu entscheiden.
Unabhängig von den Lizenzkosten
muss die größte Variante nicht zwingend
die beste für jedes Projekt sein, denn mit
den Möglichkeiten eines SQL Server steigen
auch seine Hardwareanforderungen.
So ist für eine relativ kleine Datenbank, die
auf einem Server läuft, vielleicht bereits die
Express Edition eine gute Wahl, während
die „große“ Enterprise Edition eigentlich
nur dann sinnvoll ist, wenn ein entsprechend
ausgestatteten Server mit mehreren
Prozessoren und großem Hauptspeicher
zur Verfügung steht und eventuell sogar
Funktionen wie die erwähnte Partitionierung
von Tabellen und Indizes genutzt
wird. Tabelle 1 zeigt die nutzbaren Speichergrößen
und CPUs der verschiedenen
SQL Server-Editionen:

Tabelle 1: Nutzbare Speichergrößen und CPUs der verschiedenen SQL Server-Editionen
Optimierung der Datenhaltung

Ein zentrales Thema des Datenbankdesigns
ist die Normalisierung von Daten.
Ihr Ziel ist es, Redundanzen zu vermeiden
und damit, neben der Sicherstellung der referentiellen
Integrität, auch Speicherplatz
zu sparen. Unter Performance-Gesichtspunkten
ist dies vor allem für Schreiboperationen
sinnvoll, da die Daten nur an einer
Stelle geändert werden müssen (wenn
sich zum Beispiel in einem CRM-System
eine Adresse ändert und dieser Adressdatensatz
mit mehreren Personen-Datensätzen
verknüpft ist). Bei der Normalisierung
werden die Daten daher spaltenweise auf
verschiedene Tabellen verteilt, bildlich gesprochen
findet eine vertikale Fragmentierung
statt.

Aber auch eine horizontale (zeilenweise)
Fragmentierung kann Vorteile bringen,
indem beispielsweise Archivdaten in
eine separate Tabelle derselben Struktur
auslagert werden. So kann eine Tabelle
überschaubarer Größe die vielverwendeten
aktuellen Daten (z.B. des aktuellen
Geschäftsjahres) enthalten, während die
Archivtabelle alle älteren Datensätze beinhaltet.
Ab der Enterprise Edition des SQL
Servers 2005 ist, wie bereits erwähnt, eine
Partitionierung der Daten anhand einer
Partitionierungsfunktion möglich. Damit
entfällt das Anlegen einer Archivtabelle
gleicher Struktur und das Verschieben der
alten Daten dorthin. Stattdessen verbleiben
die Daten logisch in derselben Tabelle, sie
werden aber in verschiedenen Partitionen
(und damit optimalerweise auch auf verschiedenen
Platten) abgelegt. Das „Einsortieren“
der Datensätze in die richtige
Partition geschieht dabei ganz automatisch
aufgrund der Partitionierungsfunktion.

Auch wenn die Normalisierung von
Daten ein wichtiger Grundsatz der allgemeinen
Datenbanktheorie ist, kann auch
eine gezielte Denormalisierung sinnvoll
sein. Hier werden bewusst Redundanzen
in Kauf genommen, um eine möglichst
schnelle Abfrage der Daten zu erreichen.
Dafür wird einerseits mehr Speicher benötigt
und andererseits werden die Schreiboperationen …

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.