Spaltenorientiertes DBMS - Column-oriented DBMS
Eine Säule orientierte DBMS oder säulen DBMS ist ein Datenbankmanagementsystem (DBMS) , das Daten speichert Tabellen durch Spalte und nicht durch Zeile. Die praktische Verwendung eines Spaltenspeichers gegenüber einem Zeilenspeicher unterscheidet sich in der relationalen DBMS- Welt kaum . Sowohl Spalten- als auch Zeilendatenbanken können traditionelle Datenbankabfragesprachen wie SQL verwenden, um Daten zu laden und Abfragen durchzuführen. Sowohl Zeilen- als auch Spaltendatenbanken können zum Rückgrat eines Systems werden, um Daten für gängige Tools zum Extrahieren, Transformieren, Laden (ETL) und Datenvisualisierung bereitzustellen. Durch das Speichern von Daten in Spalten statt in Zeilen kann die Datenbank jedoch präziser auf die Daten zugreifen, die sie zum Beantworten einer Abfrage benötigt, anstatt unerwünschte Daten in Zeilen zu scannen und zu verwerfen.
Beschreibung
Hintergrund
Ein relationales Datenbankverwaltungssystem stellt Daten bereit, die eine zweidimensionale Tabelle mit Spalten und Zeilen darstellen. Eine Datenbank könnte beispielsweise diese Tabelle enthalten:
| Zeilen-ID | EmpId | Nachname | Vorname | Gehalt |
|---|---|---|---|---|
| 001 | 10 | Schmied | Joe | 60000 |
| 002 | 12 | Jones | Maria | 80000 |
| 003 | 11 | Johnson | Cathy | 94000 |
| 004 | 22 | Jones | Bob | 55000 |
Diese einfache Tabelle enthält eine Mitarbeiterkennung (EmpId), Namensfelder (Nachname und Vorname) und ein Gehalt (Gehalt). Dieses zweidimensionale Format ist eine Abstraktion. In einer tatsächlichen Implementierung erfordert die Speicherhardware, dass die Daten in die eine oder andere Form serialisiert werden.
Die teuersten Operationen mit Festplatten sind Suchvorgänge . Um die Gesamtleistung zu verbessern, sollten verwandte Daten so gespeichert werden, dass die Anzahl der Suchvorgänge minimiert wird. Dies wird als Referenzlokalität bezeichnet , und das Grundkonzept taucht in verschiedenen Kontexten auf. Festplatten sind in einer Reihe von Blöcken mit einer festen Größe organisiert, die normalerweise ausreicht, um mehrere Zeilen der Tabelle zu speichern. Indem die Daten der Tabelle so organisiert werden, dass die Zeilen in diese Blöcke passen, und indem verwandte Zeilen in sequentielle Blöcke gruppiert werden, wird in vielen Fällen die Anzahl der zu lesenden oder zu durchsuchenden Blöcke zusammen mit der Anzahl der Suchvorgänge minimiert.
Eine Umfrage von Pinnecke et al. umfasst Techniken zur Spalten-/Zeilenhybridisierung ab 2017.
Reihenorientierte Systeme
Eine übliche Methode zum Speichern einer Tabelle besteht darin, jede Datenzeile wie folgt zu serialisieren:
001:10,Smith,Joe,60000; 002:12,Jones,Mary,80000; 003:11,Johnson,Cathy,94000; 004:22,Jones,Bob,55000;
Beim Einfügen von Daten in die Tabelle wird dieser eine interne ID zugewiesen, die rowidintern im System verwendet wird, um auf Daten zu verweisen. In diesem Fall haben die Datensätze sequentielle rowids unabhängig von der vom Benutzer zugewiesenen empid. In diesem Beispiel verwendet das DBMS kurze Ganzzahlen zum Speichern von rowids. In der Praxis werden normalerweise größere Zahlen, 64-Bit oder 128-Bit, verwendet.
Zeilenorientierte Systeme sind darauf ausgelegt, Daten für eine ganze Zeile oder einen ganzen Datensatz in möglichst wenigen Vorgängen effizient zurückzugeben. Dies entspricht dem üblichen Anwendungsfall, bei dem das System versucht, Informationen über ein bestimmtes Objekt abzurufen, beispielsweise die Kontaktinformationen eines Benutzers in einem Rolodex- System oder Produktinformationen für ein Online-Shopping- System. Durch Speichern der Datensatzdaten in einem einzigen Block auf der Platte zusammen mit den zugehörigen Datensätzen kann das System Datensätze mit einem Minimum an Plattenoperationen schnell abrufen.
Zeilenorientierte Systeme sind nicht effizient bei der Ausführung mengenweiter Operationen für die gesamte Tabelle, im Gegensatz zu einer kleinen Anzahl spezifischer Datensätze. Um beispielsweise alle Datensätze in der Beispieltabelle mit Gehältern zwischen 40.000 und 50.000 zu finden, müsste das DBMS die gesamte Tabelle vollständig durchsuchen, um nach übereinstimmenden Datensätzen zu suchen. Während die oben gezeigte Beispieltabelle wahrscheinlich in einen einzelnen Plattenblock passt, würde eine Tabelle mit einigen hundert Zeilen nicht passen, und es wären mehrere Plattenoperationen erforderlich, um die Daten abzurufen und zu untersuchen.
Um die Leistung dieser Art von Operationen zu verbessern (die sehr verbreitet sind und im Allgemeinen der Sinn der Verwendung eines DBMS sind), unterstützen die meisten DBMS die Verwendung von Datenbankindizes , die alle Werte aus einem Satz von Spalten zusammen mit rowidZeigern zurück in die Datenbank speichern originaler Tisch. Ein Index für die Gehaltsspalte würde etwa so aussehen:
55000:004; 60000:001; 80000:002; 94000:003;
Da sie nur einzelne Daten und nicht ganze Zeilen speichern, sind Indizes im Allgemeinen viel kleiner als die Haupttabellenspeicher. Das Scannen dieses kleineren Datensatzes reduziert die Anzahl der Plattenvorgänge. Wenn der Index stark genutzt wird, kann er die Zeit für gängige Operationen drastisch verkürzen. Die Pflege von Indizes erhöht jedoch den Systemaufwand, insbesondere wenn neue Daten in die Datenbank geschrieben werden. Datensätze müssen nicht nur in der Haupttabelle gespeichert werden, sondern auch alle angehängten Indizes müssen aktualisiert werden.
Der Hauptgrund, warum Indizes die Leistung bei großen Datensätzen dramatisch verbessern, besteht darin, dass Datenbankindizes für eine oder mehrere Spalten normalerweise nach Werten sortiert werden, was Bereichsabfragen (wie das obige Beispiel „Alle Datensätze mit Gehältern zwischen 40.000 und 50.000 finden“ oben) sehr schnell macht (geringere Zeitkomplexität ).
Eine Reihe von zeilenorientierten Datenbanken sind so konzipiert, dass sie vollständig in RAM , eine In-Memory-Datenbank , passen . Diese Systeme sind nicht von Plattenvorgängen abhängig und haben zeitgleichen Zugriff auf den gesamten Datensatz. Dies reduziert den Bedarf an Indizes, da für typische Aggregationszwecke die gleiche Anzahl von Operationen erforderlich ist, um die Originaldaten vollständig zu scannen, wie ein vollständiger Index. Solche Systeme mögen daher einfacher und kleiner sein, können aber nur Datenbanken verwalten, die in den Speicher passen.
Säulenorientierte Systeme
Eine spaltenorientierte Datenbank serialisiert alle Werte einer Spalte zusammen, dann die Werte der nächsten Spalte usw. Für unsere Beispieltabelle würden die Daten auf diese Weise gespeichert:
10:001,12:002,11:003,22:004; Smith:001,Jones:002,Johnson:003,Jones:004; Joe:001,Mary:002,Cathy:003,Bob:004; 60000:001,80000:002,94000:003,55000:004;
In diesem Layout entspricht jede der Spalten besser der Struktur eines Index in einem zeilenorientierten System. Dies kann zu Verwirrung führen, die zu der irrigen Annahme führen kann, dass ein spaltenorientierter Speicher "eigentlich nur" ein Zeilenspeicher mit einem Index für jede Spalte ist. Es ist jedoch die Abbildung der Daten, die sich dramatisch unterscheidet. In einem zeilenorientierten indizierten System ist der Primärschlüssel die Zeilen-ID, die aus indizierten Daten abgebildet wird. Im spaltenorientierten System sind der Primärschlüssel die Daten, die aus Rowids abgebildet werden. Dies mag subtil erscheinen, aber der Unterschied kann in dieser gemeinsamen Modifikation zum selben Geschäft gesehen werden, in der die beiden oben genannten "Jones" -Artikel zu einem einzigen Artikel mit zwei Rowids komprimiert sind:
…;Smith:001;Jones:002,004;Johnson:003;…
Ob ein spaltenorientiertes System im Betrieb effizienter ist oder nicht, hängt stark von der zu automatisierenden Arbeitslast ab. Vorgänge, die alle Daten für ein bestimmtes Objekt (die gesamte Zeile) abrufen, sind langsamer. Ein zeilenorientiertes System kann die Zeile in einem einzigen Plattenlesevorgang abrufen, wohingegen zahlreiche Plattenoperationen zum Sammeln von Daten aus mehreren Spalten von einer spaltenförmigen Datenbank erforderlich sind. Diese ganzen Reihenoperationen sind jedoch im Allgemeinen selten. In den meisten Fällen wird nur eine begrenzte Teilmenge der Daten abgerufen. In einer Rolodex-Anwendung beispielsweise ist das Sammeln der Vor- und Nachnamen aus vielen Zeilen zum Erstellen einer Kontaktliste weitaus häufiger als das Lesen aller Daten für eine einzelne Adresse. Dies gilt umso mehr für das Schreiben von Daten in die Datenbank, insbesondere wenn die Daten mit vielen optionalen Spalten "sparse" sind. Aus diesem Grund haben Säulenspeicher trotz vieler theoretischer Nachteile eine hervorragende Leistung in der Praxis gezeigt.
Partitionierung , Indizierung , Caching, Ansichten, OLAP-Cubes und Transaktionssysteme wie Write-Ahead-Logging oder Multiversion-Parallelitätssteuerung wirken sich alle dramatisch auf die physische Organisation beider Systeme aus. Das sagte, Online - Transaktionsverarbeitung (OLTP) -focused RDBMS - Systeme sind zeilenorientierte, während Online Analytical Processing (OLAP) -focused Systeme ein Gleichgewicht der zeilenorientierte und spaltenorientierte sind.
Leistungen
Vergleiche zwischen zeilenorientierten und spaltenorientierten Datenbanken beziehen sich normalerweise auf die Effizienz des Festplattenzugriffs für eine bestimmte Arbeitslast, da die Suchzeit im Vergleich zu anderen Engpässen in Computern unglaublich lang ist. Eine typische Serial ATA (SATA)-Festplatte hat beispielsweise eine durchschnittliche Suchzeit zwischen 16 und 22 Millisekunden, während der DRAM-Zugriff auf einem Intel Core i7-Prozessor durchschnittlich 60 Nanosekunden dauert, fast 400.000 Mal so schnell. Der Festplattenzugriff ist eindeutig ein großer Engpass beim Umgang mit Big Data. Spaltendatenbanken steigern die Leistung, indem sie die Datenmenge reduzieren, die von der Festplatte gelesen werden muss, indem sowohl die ähnlichen Spaltendaten effizient komprimiert werden als auch nur die Daten gelesen werden, die zum Beantworten der Abfrage erforderlich sind.
In der Praxis eignen sich spaltenförmige Datenbanken gut für OLAP- ähnliche Workloads (zB Data Warehouses ), die typischerweise hochkomplexe Abfragen aller Daten (möglicherweise Petabytes ) beinhalten. Es muss jedoch einige Arbeit geleistet werden, um Daten in eine spaltenförmige Datenbank zu schreiben. Transaktionen (INSERTs) müssen beim Speichern in Spalten aufgeteilt und komprimiert werden, was sie für OLTP-Workloads weniger geeignet macht. Zeilenorientierte Datenbanken eignen sich gut für OLTP- ähnliche Workloads, die stärker mit interaktiven Transaktionen belastet sind. Das Abrufen aller Daten aus einer einzelnen Zeile ist beispielsweise effizienter, wenn sich diese Daten an einem einzigen Ort befinden (wodurch die Festplattensuche minimiert wird), wie in zeilenorientierten Architekturen. Spaltenorientierte Systeme wurden jedoch als Hybride entwickelt, die sowohl zu OLTP- als auch zu OLAP-Operationen fähig sind. Einige der OLTP-Einschränkungen, denen solche spaltenorientierten Systeme ausgesetzt sind, werden unter Verwendung (neben anderen Qualitäten) einer speicherinternen Datenspeicherung vermittelt. Spaltenorientierte Systeme, die sowohl für OLAP- als auch für OLTP-Rollen geeignet sind, reduzieren effektiv den Gesamtdatenbedarf, da separate Systeme überflüssig werden.
Kompression
Spaltendaten haben einen einheitlichen Typ; Daher gibt es in spaltenorientierten Daten einige Möglichkeiten zur Optimierung der Speichergröße, die in zeilenorientierten Daten nicht verfügbar sind. Beispielsweise nutzen viele gängige moderne Komprimierungsschemata, wie LZW oder Lauflängencodierung , die Ähnlichkeit benachbarter Daten zum Komprimieren. Fehlende Werte und wiederholte Werte, die in klinischen Daten häufig vorkommen, können durch einen 2-Bit-Marker dargestellt werden. Während die gleichen Techniken für zeilenorientierte Daten verwendet werden können, wird eine typische Implementierung weniger effektive Ergebnisse erzielen.
Um die Komprimierung zu verbessern, kann auch das Sortieren von Zeilen hilfreich sein. Bei Verwendung von Bitmap-Indizes kann die Sortierung beispielsweise die Komprimierung um eine Größenordnung verbessern. Um die Komprimierungsvorteile der lexikographischen Ordnung in Bezug auf die Lauflängencodierung zu maximieren , ist es am besten, Spalten mit niedriger Kardinalität als erste Sortierschlüssel zu verwenden. Bei einer Tabelle mit den Spalten Geschlecht, Alter, Name ist es beispielsweise am besten, zuerst nach dem Wert Geschlecht (Kardinalität zwei), dann nach Alter (Kardinalität <128) und dann nach Name zu sortieren.
Die spaltenförmige Komprimierung führt zu einer Reduzierung des Plattenspeicherplatzes auf Kosten der Effizienz des Abrufens. Je höher die erreichte benachbarte Komprimierung ist, desto schwieriger kann der Direktzugriff werden, da die Daten zum Lesen möglicherweise dekomprimiert werden müssen. Daher werden spaltenorientierte Architekturen manchmal durch zusätzliche Mechanismen bereichert, die darauf abzielen, die Notwendigkeit des Zugriffs auf komprimierte Daten zu minimieren.
Geschichte
Spaltenspeicher oder transponierte Dateien wurden seit den frühen Tagen der DBMS-Entwicklung implementiert. TAXIR war 1969 die erste Anwendung eines spaltenorientierten Datenbankspeichersystems mit Schwerpunkt auf der Informationsgewinnung in der Biologie. Klinische Daten aus Patientenakten mit viel mehr Attributen, als analysiert werden konnten, wurden ab 1975 von einem zeitorientierten Datenbanksystem verarbeitet (TODS). Statistics Canada implementierte das RAPID-System 1976 und nutzte es für die Verarbeitung und den Abruf der kanadischen Bevölkerungs- und Wohnungszählung sowie für mehrere andere statistische Anwendungen. RAPID wurde mit anderen statistischen Organisationen auf der ganzen Welt geteilt und in den 1980er Jahren weit verbreitet verwendet. Es wurde bis in die 1990er Jahre von Statistics Canada verwendet.
Eine andere spaltenorientierte Datenbank war SCSS.
Spätere spaltenorientierte Datenbankpakete enthalten:
Seit etwa 2004 gibt es weitere Open Source und kommerzielle Implementierungen. MonetDB wurde am 30. September 2004 unter einer Open-Source-Lizenz veröffentlicht , dicht gefolgt vom inzwischen nicht mehr existierenden C-Store .
C-Store war ein Universitätsprojekt, das schließlich, mit Teammitglied Michael Stonebraker , zu Vertica führte , das er 2005 mitbegründete.
Aus dem MonetDB-bezogenen X100-Projekt wurde VectorWise . Druid ist ein spaltenorientierter Datenspeicher, der Ende 2012 als Open Source veröffentlicht wurde und heute von zahlreichen Organisationen verwendet wird.
Das klassische relationale DBMS kann spaltenorientierte Strategien verwenden, indem zeilenorientierte und spaltenorientierte Tabellen gemischt werden. Trotz der Komplexität des DBMS hat sich dieser Ansatz seit den Jahren 2010 bis heute bewährt. Zum Beispiel führte Citusdata 2014 spaltenorientierte Tabellen für PostgreSQL ein und McObject fügte mit der Veröffentlichung der eXtremeDB Financial Edition im Jahr 2012 Unterstützung für spaltenförmigen Speicher hinzu, die dann verwendet wurde, um einen neuen Leistungsstandard für den unabhängig geprüften STAC-M3-Benchmark zu etablieren.
