Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.


11.12.2008

Die Kunst der Datenbankoptimierung

Sascha Alexander ist Manager Marketing & Kommunikation bei der QUNIS GmbH, Neubeuern, die auf Beratung und Projekte in der Business Intelligence, Big Data und Advanced Analytics spezialisiert ist. Zuvor war der Autor als Director Communications bei den Marktforschungs- und Beratungsunternehmen BARC und PAC tätig. Als ehemaliger Redakteur der COMPUTERWOCHE sowie Gründer und Chefredakteur des Portals und Magazins für Finanzvorstände CFOWORLD verbindet ihn zudem eine lange gemeinsame Zeit mit IDG.
Seine Themenschwerpunkte sind: Business Intelligence, Data Warehousing, Datenmanagement, Big Data, Advanced Analytics und BI Organisation.
Wenn sie zu viele Daten aufnehmen müssen, stoßen Datenbanken an ihre Leistungsgrenzen. Anbieter und Forschung suchen seit Jahren nach Auswegen.

Datenbanken sind traditionell "Record-orientiert". Die Eigenschaften einer Entität oder eines Objekts werden gemeinsam mit ihren identifizierenden Merkmalen erfasst und gespeichert. In relationalen Datenbank-Management-Systemen (RDBMS) führte dies zu zeilenorientierten Tabellen, in denen Spalten die einzelnen Attribute und Zeilen die Objekte (oder deren Beziehungen) repräsentieren. Auf technischer Ebene werden dadurch zusammengehörige Records in gleichen oder angrenzenden Blöcken abgelegt. Zugriffsmechanismen, Indexstrukturen sowie Anfrageoptimierer sind darauf ausgelegt, mit dieser Speicherungsform und darauf auszuführenden Schreiboperationen möglichst effizient umzugehen.

Columnstores gehört die Zukunft

Zahlreiche heutige Dateninfrastrukturen, darunter Data Warehouses, CRM-Systeme, Archivlösungen oder elektronische Kataloge, werden demgegenüber initial mit einer großen Datenmenge geladen (mit Bulk-Uploads), danach aber überwiegend lesend abgefragt. Anders als ein operatives transaktionales System, das nur einen oder wenige Tupel ausliest, sind es hier vor allem komplexe (übergreifende) Anfragen auf den Datenbestand, die für Performance-Probleme sorgen.

In der letzten Zeit wird nun intensiver darüber diskutiert, welche Speicher- und Optimierungsverfahren die geeigneten seien, um insbesondere die hohen Anforderungen an Data Warehousing und Business Intelligence (Datenvolumen, Ad-hoc-Anfragen in "Echtzeit") erfüllen zu können. Dies hat laut Kai-Uwe Sattler, Professor an der Fakultät für Informatik und Automatisierung an der Technischen Universität Ilmenau, zur Entwicklung einer Reihe neuer Techniken geführt. Diese zielen auf zwei Bereiche: die analytische Verarbeitung großer Datenmengen (Optimierung für Lesezugriffe, replizierte Datenhaltung, Pre-Aggregation) einerseits sowie die bestmögliche Ausnutzung neuester Hardware (Multi-Core, großer Hauptspeicher) und kostengünstiger Commodity-Server für den Aufbau großer Cluster andererseits.

Stärkerer Fokus auf die Hardware

Auf Ersteres zielen eigentlich schon seit Jahren spezielle Datenbank-Server für Online Analytical Processing (Olap) ab. Das Überdenken der Architektur von DBMS auf Basis neuer Hardware-Features ist jedoch ein neuer Trend, der sich in der vergleichsweise großen Zahl neuer Produkte und Firmen in diesem Umfeld widerspiegelt, erklärt Sattler. Konkret sind vor allem so genannte Columnstores, die auf einer vertikalen Partitionierung der Tabellen, das heißt auf einer spaltenweisen Speicherung basieren, im Kommen. Sie sollen teure Lesezugriffe auf den Externspeicher auf die tatsächlich benötigten Spalten reduzieren helfen beziehungsweise die Daten komplett im Hauptspeicher halten können.

Umgekehrt sind Datenbankanwendungen mit häufigen Änderungen und hohen Konsistenzanforderungen weniger für solche Techniken geeignet, da sich durch die notwendigen Schreibzugriffe auf den Externspeicher zum Sichern der Daten der Vorteil der Hauptspeicherverarbeitung verringert. Zudem erfordern Updates in Columnstores die Nutzung von Delta-Tabellen beziehungsweise sogar eine Reorganisation und die Gewährleistung der Konsistenz in einem Cluster, was zusätzlichen Aufwand bedeutet.

Effektive Komprimierung

Neben wegweisenden Forschungssystemen wie C-Store und Monet DB haben Columnstores inzwischen Einzug in die kommerzielle Welt gehalten. Beispiele sind Vertica, Sybase IQ, Illuminate Solutions, Infobright, Paraccel, Sand Technology und der "SAP Netweaver BI Accelerator". Solche Produkte bieten neben den genannten Vorteilen eine einfache, aber effektive Komprimierung, durch die sich sowohl der I/O-Aufwand als auch der benötigte Hauptspeicherbedarf weiter reduzieren lässt, erläutert Sattler. Bei einzelnen Operationen sei nicht einmal eine Dekomprimierung notwendig. Schließlich setzen sie auf Cluster-Systeme beziehungsweise Shared-Nothing-Architekturen auf, die eine massiv-parallele Verarbeitung der Anfragen auf vergleichsweise günstiger Standardhardware ermöglichen.

Schluss mit Stückwerk

Holger Günzel, Professor an der Fakultät für Betriebswirtschaft an der Hochschule München und Data-Warehouse-Experte, empfiehlt Unternehmen, das Thema Datenanalyse und Datenbankoptimierung möglichst ganzheitlich zu betrachten. Lange Zeit hätten Anwender versucht, Probleme reaktiv, punktuell und einseitig durch den Aufbau unterschiedlicher Indexstrukturen im Datenbanksystem oder durch immer neue Investitionen in Infrastruktur zu lösen. Eine Optimierung müsse aber immer verschiedenen Grundprinzipien Rechnung tragen wie beispielsweise dem bewussten Aufbau von Redundanz, der Daten- und Aufgabenverteilung und damit der Möglichkeit von Parallelität, der Verkleinerung des Daten- oder Anfragevolumens und natürlich durch Infrastrukturmaßnahmen.

Bei der Datenanalyse sind laut Günzel folgende Mittel für ein "Tuning" denkbar:

- Physische Architekturen wie MPP (Massive Parallel Processing), Investition in Hauptspeicher und schnelle Netzwerke;

- logische Architekturansätze wie Data-Warehouse-Systeme als konsolidierter Single-Point-of-Truth und geeignete Prozesse;

- Optimierungsmöglichkeiten im DBMS selbst: Anfrageoptimierung, Indexerstellung, Partitionierung, anfrageoptimierte Datenmodelle, materialisierte Sichten oder die Übernahme von rechenintensiven Operationen in das DBMS anstatt im Analysewerkzeug;

- Kombinationen aus mehreren Ansätzen, wie es bei dem multidimensionalen Cluster-Verfahren aus Partitionierungs- und MPP-Ansätzen erfolgt, oder durch Appliances.

Mapreduce, Pig, Hadoop, Dryad

Für Torsten Grust, Professor für Datenbanksysteme am Wilhelm-Schickard-Institut für Informatik der Universität Tübingen, liegt der Schlüssel zu einer effizienten Auswertung "sehr großer" Datenmengen auch darin, wie Anwender die Art der Anfragen kontrollieren können: "Wenn das Datenvolumen stark wächst, ist die Formulierung beliebiger Operationen mit signifikanten Kosten verbunden." Hier könne die Verwendung einer Abfragesprache sinnvoll sein, deren Operationen eine skalierbare Verarbeitung garantieren.

Ein vielsprechender Ansatz in dieser Richtung sei das "Mapreduce"-Framework. Es beschreibt Anfragen in einer Form, die deren effiziente Parallelisierbarkeit auf Shared-Nothing-MPP-Architekturen garantiert. Die Ideen hierzu stammen aus der Welt der funktionalen Programmierung. Bekannt wurde Mapreduce aber durch den Einsatz bei Google. Andere Frameworks entwickeln beispielsweise Yahoo mit "Pig" und "Hadoop" oder Microsoft mit "Dryad".

Parallele Operationen

Im Einzelnen beschreibt Mapreduce Berechnungsmuster, die große Datenmengen zunächst in Partitionen aufteilen ("map), auf denen dann parallel Operationen wie Datenselektionen, statische Auswertungen oder die Datenbereinigung laufen können. Am Ende werden die für die einzelnen Partitionen erzielten Teilergebnisse wieder zusammengeführt ("reduce). Allerdings lassen sich nicht alle Anfragen in dieses Muster pressen. Mit Hilfe entsprechender Compiler können Anwender aber zum Beispiel eine komplexere Anfrage in (Sequenzen von) Mapreduce-Jobs zerteilen.

FGPA und Grafikprozessoren

Ein anderer Ansatz zur Anfragenformulierung sind "Field Programmable Gate Arrays" (FPGA), mit denen sich "Auswerter" für datenstrombasierende Anfragen konstruieren lassen, die einen erheblichen Geschwindigkeitsvorteil versprechen. Allerdings ist die Integration von FPGAs in eine existierende DBMS-Architektur insbesondere hinsichtlich der effizienten Kommunikation mit dem FGPA-Subsystem derzeit noch nicht einfach.

Enger als FPGAs sind hingegen Grafikprozessoren in Systemarchitekturen eingebunden. Schon seit Jahren bemüht sich die Datenbankgemeinde, für immer mehr typische Operationen eines Datenbankanfrageprozessors Algorithmen zu finden, die sich auf den Pipelines von Grafikprozessoren ausführen lassen. Hier ist der kreative Einsatz der SIMD-Pipelines (Single Instruction Multiple Data ist eine Rechnerarchitektur mit Vektorprozessoren) gefragt, um Selektionen, Range-Queries, Joins oder Sortierungen parallel auswerten zu können.

Technische Vielfalt oder Konsolidierung?

Die derzeit entstehende Vielfalt an DBMS-Produkten wird nach Ansicht mancher Experten nicht lange anhalten. Sie argumentieren, dass Datenbanken momentan noch getrennt betrachtete technische Anforderungen künftig übergreifend abdecken müssen (zum Beispiel bei der Kombination von Data-Warehouse-Umgebungen mit operativen Anwendungen).

Schon heute unterstützen zum Beispiel RDBMS neben streng relationalen Konzepten auch Objekte, Multimedia, Geodaten, unstrukturierte Texte oder XML-Dokumente (seit Jahren gibt es beispielsweise XML-, XPath- und XQuery-Prozessoren, die das relationale Format nutzen). Wichtiger noch ist aber, dass Anwender nicht gewillt sind, Wissen über unterschiedliche Produkte aufzubauen und mehrere DBMS pflegen zu müssen.

Dennoch wird es immer Nischenmärkte geben, auch weil die marktführenden Produkte sich zu teuren, komplexen Alleskönnern entwickelt haben. Dies führt nach Ansicht von Experten dazu, dass eine ganze Reihe von Anwendern ihre Daten eben nicht mehr in Datenbanksystemen verwalten, weil sie den Preis für die nicht benötigten Features (ACID-Transaktionen, Anfrageoptimierung etc.) nicht zahlen wollen.

Gerade der Markt für Data Warehousing zeigt zudem, dass spezialisierte Lösungen manche Anforderungen besser erfüllen. Ferner eignen sich beispielsweise nichtrelationale Datenmodelle teilweise deutlich besser für Web-basierende Datenbankservices, wie sie in letzter Zeit als Teil von "Google Storage" oder "Amazon S3" entstanden sind.

H-Store

Trotz der laufenden Weiterentwicklung der DBMS gibt es auch Ansätze, die einen radikalen Neuanfang propagieren. Ein solches Forschungsprojekt ist der "H-Store" am MIT unter Leitung des Datenbankexperten Michael Stonebraker. Folgende Charakteristika soll die Datenbank einmal aufweisen:

  • Keine persistente Speicherung: Die "Disk Rotation" ist heute immer noch der größte Flaschenhals bei der Datenbankverwaltung und hat sich in den letzten Jahren im Vergleich zu anderen Techniken nur langsam weiterentwickelt. Stattdessen arbeitet der H-Store mit multiplen Datenkopien im Arbeitsspeicher. Ein magnetischer oder optischer Speicher lässt sich aber hinzufügen.

  • Kein Multi-Threading, da laut Stonebraker lang laufende Transaktionen (und damit auch ein Locking in der Datenbank) der Vergangenheit angehören.

  • Alle Transaktionen werden als eine Art Stored Procedure implementiert.

  • Ruby on Rails soll SQL als Abfragesprache ersetzen.

  • Statt des relationalen Datenmodells soll H-Store eher hierarchisch organisiert sein.