Datensilos für den Schrebergarten

Welche Datenbank darf's denn sein: MySQL [1] oder doch besser PostgreSQL [2]? Ist Firebird [3] das Nonplusultra oder SQLite [4]? In der Diskussion darüber tauchen nicht selten eine Fülle von Begriffen auf, die nur Datenbank-Profis verstehen, Einsteigern aber lediglich die Stirn runzeln lassen. Dabei ist die Sache ganz einfach: Für den Hausgebrauch sind wenigstens zwei Drittel der klangvollen Features ohne Bedeutung.

Warum baut man sie dann aber erst ein? Ganz einfach: Das Adressbuch oder der CD-Katalog auf dem Einzelplatzrechner stellen für eine Datenbank eher Ausnahmeanwendungen dar – typischerweise bedient sie viele Anwender, verwaltet deutlich größere Datenmengen, läuft auf einem speziellen Server und spielt eine verantwortungsvolle Schlüsselrolle in einer geschäftskritischen Applikation. Daraus resultieren besondere Anforderungen an Verfügbarkeit und Performance, an Skalierbarkeit und die Administration, an die Organisation und Integrität der Daten und nicht zuletzt an den Support.

Doch alles, was die Datenbank tut, um sich diesen Forderungen gewachsen zu zeigen, ist für den Heimanwender irrelevant. Er greift auf eine für ihre Verhältnisse lächerliche Datenportion nur gelegentlich und exklusiv zu und verkraftet wahrscheinlich selbst einen Ausfall ohne ernsthaften Schaden. Seine Bedürfnisse lasen sich mit einer kleinen Untermenge der Datenbank-Features befriedigen – und nur wenige Eigenschaften sind für ihn wirklich wichtig.

Ganz oder gar nicht

Getrost weghören kann der Alleinanwender beispielsweise bei all den komplizierten Vorkehrungen, mit denen die Datenbank die Integrität ihrer Inhalte angesichts zahlreicher paralleler Zugriffe sichert. Ob sie ihre Tabellen für jeweils einen Nutzer nur komplett oder auch zeilenweise reservieren kann, das spielt für den Einzelnutzer ebenso wenig eine Rolle wie Two-Phase-Commit, MVCC oder die Frage, ob sich durch Tablespaces oder Tabellenpartitionierung die Festplattenzugriffe gezielt auf mehrere Disks oder logische Laufwerke verteilen lassen. All das sind wichtige Fragen im Unternehmenseinsatz – sie stellen sich aber gar nicht erst, wenn es nur einen Anwender gibt.

Auch als Datenbank-Neuling sollte man dagegen wissen, dass die Datenbank hinter den Kulissen mittels so genannter Transaktionen dafür sorgt, dass eine Operation entweder nur komplett oder aber gar nicht ausgeführt wird. Dazu ein Beispiel: Stürzte etwa der Bankserver bei einer Überweisung zwischen Abbuchung und Gutschrift ab und könnte anschließend nicht erkennen, dass er diesen Arbeitsschritt erst zur Hälfte erledigt hat, wären zwei unzufriedene Kunden die Folge. Das verhindern Transaktionen nach dem ACID-Prinzip.

Geschickte Fragen

Mit einem persönlichen Adressbuch oder dem Katalog der eigenen Briefmarkensammlung hat eine Datenbank keine Performanceprobleme – es sei denn, der Anwender vergewaltigt sie mit sinnlosen oder ineffizienten Operationen. Deshalb kümmert den Einzelplatznutzer auch das Thema Performance nicht in der selben Weise wie den Profi. Weder die komplizierte Konfiguration für bestimmte Tuning-Ziele noch das Multithreading oder Load Balancing noch die Unterstützung mehrerer CPUs müssen ihn beschäftigen. Auch Skalierbarkeit wird erst bei steigender Nutzerzahl und Datenmenge relevant. Ebenfalls keine Themen für Heimanwender stellen Clusterfähigkeit, Replikationen, Point-In-Time-Recovery oder Online-Backups dar. Eine Offline-Sicherung steht allerdings auch ihm gut zu Gesicht.

Dagegen ist es nützlich zu wissen, dass die Datenbank Abfragen nie blindlings übernimmt, sondern immer in eine interne Form wandelt und dabei die einzelnen Schritte optimiert. Dabei kann der Anwender durch geschicktes Formulieren der Abfrage und durch die Anlage nützlicher Indizes helfen. Was man dabei verschenkt, lässt sich durch andere Tuning-Bemühungen in der Regel nicht mehr aufholen.