Spaltenorientierte Datenbank

Grundidee und Einsatzbereich

Eine spaltenorientierte Datenbank speichert die Inhalte einer Tabelle physisch spaltenweise und nicht zeilenweise. Datenbanken stellen Daten meist als zweidimensionale Tabellen aus Zeilen und Spalten dar, müssen diese Struktur aber im Arbeitsspeicher und auf der Festplatte als eindimensionale Folge von Bytes ablegen. Die spaltenorientierte Speicherung löst diese Aufgabe, indem zuerst alle Werte einer Spalte gespeichert werden, dann alle Werte der nächsten Spalte usw.

Der Ansatz ist besonders wichtig für Anwendungen wie Data Warehouses und analytische Informationssysteme, in denen häufig Aggregate, also zusammenfassende Berechnungen über viele Datensätze, gebildet werden. Er steht im Gegensatz zur zeilenorientierten Speicherung, die viele bekannte Datenbanksysteme verwenden. In der Praxis sind OLTP-Systeme, also Systeme für viele interaktive Transaktionen wie Buchhaltungssysteme, eher zeilenorientiert. OLAP-Systeme, also Systeme für komplexe analytische Abfragen über große Datenmengen, streben häufig eine Balance aus Zeilen- und Spaltenorientierung an oder nutzen spaltenorientierte Ansätze.

Speicherung von Tabellen

Bei einer Tabelle mit den Spalten Personalnr, Nachname, Vorname und Gehalt würde eine zeilenorientierte Datenbank alle Werte einer Zeile hintereinander speichern und danach mit der nächsten Zeile fortfahren, etwa: 1,Schmidt,Josef,40000;2,Müller,Maria,50000;3,Meier,Julia,44000;

Eine spaltenorientierte Datenbank speichert dagegen zuerst alle Werte der Spalte Personalnr, dann alle Werte der Spalte Nachname, dann Vorname und schließlich Gehalt, etwa: 1,2,3;Schmidt,Müller,Meier;Josef,Maria,Julia;40000,50000,44000;

Die tatsächliche physische Organisation einer Datenbank wird zusätzlich durch Partitionierung, Indizes, Caching, Views, OLAP-Würfel und transaktionale Aspekte wie Write-Ahead-Logging beeinflusst. Deshalb ist die Einteilung in zeilen- oder spaltenorientiert in der Praxis oft Teil einer größeren Architekturentscheidung.

Vorteile und Nachteile

Vergleiche zwischen zeilenorientierten und spaltenorientierten Systemen betreffen vor allem die Effizienz des Festplattenzugriffs, weil dieser im Vergleich zu vielen anderen Computeroperationen viel Zeit benötigt. Das Lesen eines Megabytes sequentiell gespeicherter Daten kann ungefähr so lange dauern wie ein einziger Direktzugriff. Da sich Festplattenzugriffszeiten langsamer verbessern als CPU-Geschwindigkeiten, bleibt dieser Punkt wichtig, solange Daten auf Festplatten gespeichert werden.

Spaltenorientierte Systeme sind effizient, wenn ein Aggregat über viele Zeilen, aber nur wenige Spalten berechnet wird. Dann müssen nur die benötigten Spalten gelesen werden. Ein typisches Beispiel ist: SELECT SUM(Gehalt) FROM tabelle;

Sie sind auch effizient, wenn eine Spalte für alle Zeilen gleichzeitig einen neuen Wert erhält, weil die Daten dieser Spalte zusammenhängend geschrieben werden können. Ein Beispiel ist eine Gehaltserhöhung: UPDATE tabelle SET Gehalt = Gehalt * 1.03;

Zeilenorientierte Systeme sind effizienter, wenn viele Spalten einer einzelnen Zeile gleichzeitig benötigt werden und die Zeilenbreite groß ist. Dann kann die ganze Zeile mit einem Plattenzugriff gelesen werden. Ein Beispiel ist: SELECT * FROM tabelle WHERE Personalnr = 1;

Auch beim Einfügen einer neuen Zeile sind zeilenorientierte Systeme günstig, wenn alle Werte der Zeile auf einmal vorliegen. Ein Beispiel ist: INSERT INTO tabelle (Personalnr, Nachname, Vorname, Gehalt) VALUES (4, 'Maier', 'Karl-Heinz', 45000);

In der Praxis eignen sich spaltenorientierte Systeme gut für OLAP-Aufgaben mit wenigen, aber sehr komplexen Abfragen über alle Datensätze. Es gibt jedoch auch bewährte zeilenorientierte relationale OLAP-Datenbanken, die Terabytes oder Petabytes verarbeiten können, zum Beispiel Teradata und IBM PureData System for Analytics (IBM Netezza).

Kompression

Spaltendaten haben einen einheitlichen Datentyp. Dadurch bieten spaltenorientierte Systeme besondere Möglichkeiten zur Plattenplatzoptimierung. Kompressionsverfahren wie der Lempel-Ziv-Welch-Algorithmus (LZW) oder die Lauflängenkodierung nutzen die Ähnlichkeit benachbarter Daten. Solche Verfahren können zwar auch bei zeilenorientierten Daten eingesetzt werden, erreichen dort aber in typischen Implementierungen weniger effektive Ergebnisse.

Einige Implementierungen, zum Beispiel Vertica, sortieren Spalten, um die Kompression zu verbessern. Zusammen mit Bitmap-Indizes kann Sortieren die Kompression um eine Größenordnung verbessern. Bei der Lauflängenkodierung ist es günstig, zuerst nach Spalten mit kleiner Kardinalität zu sortieren. Kardinalität bezeichnet hier die Anzahl verschiedener Werte einer Spalte. Bei einer Tabelle mit Name, Geschlecht und Alter wäre es daher günstig, zuerst nach Geschlecht (Kardinalität 3), dann nach Alter (Kardinalität < 150) und dann nach Name zu sortieren.

In einer spaltenorientierten Datenbank kann jede Spalte einzeln komprimiert werden, sodass die Reihenfolge der Spalten in der Tabelle die Komprimierung nicht beeinflusst. Bei zusammengesetzten Indizes kann die Reihenfolge aber bessere Kompressionsraten ermöglichen. Wenn ein Index über Name und Werk nach Werk und Name umsortiert wird, kann die Kompression steigen; für eine Suche nur nach Name ist der Index danach aber üblicherweise nicht mehr brauchbar.

Spaltenkompression reduziert den Plattenplatzverbrauch, kann aber den Zugriff auf einzelne Daten erschweren, weil große Datenmengen dekomprimiert werden müssen, um einen einzelnen Satz zu lesen. Deshalb werden spaltenorientierte Architekturen oft durch zusätzliche Mechanismen ergänzt, die Zugriffe auf komprimierte Daten möglichst vermeiden. Seit Mitte der 2000er Jahre gilt jedoch nicht mehr unbedingt, dass Komprimierung insgesamt langsamer ist: Mit mehr Rechenleistung ist es oft schneller, kleinere Datenmengen von der Platte zu lesen und danach zu dekomprimieren, statt große unkomprimierte Datenmengen zu lesen. Das gilt auch für Schreibzugriffe. Auch Hersteller zeilenorientierter Datenbanken wie Oracle setzen Komprimierung ein und empfehlen sie auf geeigneten Servern zur Geschwindigkeitssteigerung.

Implementierungen

Spaltenspeicherung gab es in Form invertierter Dateien schon früh in der Geschichte der Datenbanksysteme, beginnend in den 1970er Jahren. Statistics Canada implementierte 1976 das RAPID-System und nutzte es für die kanadische Volkszählung und andere statistische Anwendungen. RAPID wurde bis in die 1980er Jahre weltweit von anderen statistischen Organisationen genutzt, von Statistics Canada sogar bis in die 1990er Jahre.

Für viele Jahre war Sybase IQ das einzige marktverfügbare Produkt im Bereich spaltenorientierter Datenbanksysteme. Später kamen viele proprietäre und freie Systeme hinzu. Zu den im Artikel genannten proprietären Beispielen gehören unter anderem ParStream, Oracle 12c Enterprise Edition mit kostenpflichtiger In-Memory Option, SAP HANA, Sybase IQ, Vertica, KDB, Db2 mit BLU Acceleration, Exasol, InfiniDB Enterprise Edition, Infobright Enterprise Edition, Microsoft SQL Server 2012 mit Column Store Index sowie weitere Produkte.

Als freie oder Open-Source-Beispiele nennt der Artikel unter anderem RC21, Calpont InfiniDB Community Edition, Apache Cassandra, Apache Parquet für cloud-native Datenanalyse, Apache Arrow als In-Memory-Format, C-Store, DuckDB, FastBit, Infobright Community Edition, MonetDB, Apache Druid und ClickHouse.