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.