Fakultät. Verfasser: Waldemar Braun. Betreuer : Magdeburg Germany

Transkript

1 Otto-von-Guericke-Universität Magdeburg Fakultät t für Informatik Masterarbeit Anfrageinterface für zeilenorientierte und spaltenorientierte Datenbanksysteme Verfasser: Waldemar Braun 19. Oktober, 2012 Betreuer : Prof. Dr. Gunter Saake (FIN/ITI) Dipl.-Inform. Andreas Lübcke (FIN/ITI) Dipl. -Inform. Martin Schäler (FIN/ITI) Institut für Technische und Betriebliche Informationssysteme Otto-von-Guericke-Universität Magdeburg Fakultät für Informatik Postfach 4120, D Magdeburg Germany

2 Braun, Waldemar: Anfrageinterface für zeilenorientierte und spaltenorientierte Datenbanksysteme Masterarbeit, Otto-von-Guericke-Universität Magdeburg, 2012.

3 Inhaltsverzeichnis I Inhaltsverzeichnis INHALTSVERZEICHNIS... I ABBILDUNGSVERZEICHNIS... V TABELLENVERZEICHNIS... VII QUELLTEXTVERZEICHNIS... IX ABKÜRZUNGSVERZEICHNIS... XI 1. EINFÜHRUNG MOTIVATION ZIELSETZUNG DER ARBEIT GLIEDERUNG GRUNDLAGEN DIE FÜNF-SCHICHTEN-ARCHITEKTUR SCHNITTSTELLEN DER ARCHITEKTUR SCHICHTEN DER ARCHITEKTUR ANWENDUNGSDOMÄNEN VON DATENBANKEN SPEICHERUNGSVARIANTEN VON DATENBANKEN ZEILENORIENTIERTE DATENBANKEN (ROW-STORES) SPALTENORIENTIERTE DATENBANKEN (COLUMN-STORES) ABGRENZUNG OLAP ZU OLTP KONZEPT IST-ZUSTAND NACH IMPLEMENTIERUNG EINES COLUMN-STORES ANFORDERUNGEN AN DAS HYBRIDE DBMS ÄNDERUNGEN AM SPEICHERSYSTEM CHUNKWEISES EINLESEN... 26

4 II Inhaltsverzeichnis ABLEGEN VON ZEILEN UND SPALTEN IM CACHE ÄNDERUNGEN AM ZUGRIFFSSYSTEM VERBINDUNG ZUM CACHE HERSTELLEN VERZWEIGUNG DES PROGRAMMFLUSSES BEI AGGREGATBERECHNUNG ZUGRIFF AUF SPALTEN SONSTIGE ÄNDERUNGEN - ZEITMESSUNG ZUSAMMENFASSUNG DER ÄNDERUNGEN IMPLEMENTIERUNG FUNKTIONSWEISE DES HSQLDB TABELLENTYPEN LESEN UND SCHREIBEN VON TEXT-TABELLEN ANFRAGEVERARBEITUNG ÄNDERUNGEN NACH [NGU12] ÄNDERUNGEN AM SPEICHERSYSTEM STRUKTUR ZUM SPEICHERN DER SPALTEN CHUNKWEISES EINLESEN UND SPEICHERN DER ZEILEN UND SPALTEN ÄNDERUNGEN AM ZUGRIFFSSYSTEM VERBINDUNG ZUM CACHE HERSTELLEN VERZWEIGUNG DES PROGRAMMFLUSSES BEI AGGREGATBERECHNUNG ZUGRIFF AUF SPALTEN FUNKTIONSTEST VERWANDTE ARBEITEN EVALUIERUNG BENCHMARK DBMBENCH TESTUMGEBUNG ERGEBNISSE ZUSAMMENFASSUNG UND AUSBLICK ZUSAMMENFASSUNG AUSBLICK A. ANHANG A.1 GETESTETE STATEMENTS BEIM FUNKTIONSTEST... 75

5 Inhaltsverzeichnis III A.2 EINIGE GEÄNDERTE METHODEN DES SPEICHERSYSTEMS A.3 EINIGE GEÄNDERTE METHODEN DES ZUGRIFFSSYSTEMS LITERATURVERZEICHNIS SELBSTSTÄNDIGKEITSERKLÄRUNG... 87

6

7 Abbildungsverzeichnis V Abbildungsverzeichnis ABBILDUNG 2.1: FUNKTIONSORIENTIERTE SICHT AUF DIE FÜNF-SCHICHTEN-ARCHITEKTUR (NACH [SSH08A])... 6 ABBILDUNG 2.2: TYPISCHE OBJEKTE UND OPERATIONEN DER SCHNITTSTELLEN DER FÜNF- SCHICHTEN-ARCHITEKTUR (NACH [SSH08A])... 8 ABBILDUNG 2.3: ZEILENWEISE SPEICHERUNG EINER DATENBANKTABELLE ABBILDUNG 2.4: SPALTENWEISE SPEICHERUNG EINER DATENBANKTABELLE ABBILDUNG 3.1: EINORDNUNG DER ÄNDERUNGEN VON NGUYEN IN DIE FÜNF-SCHICHTEN- ARCHITEKTUR ABBILDUNG 3.2: GROBE ÜBERSICHT DER ANFRAGEVERARBEITUNG IN HSQLDB ABBILDUNG 3.3: EINORDNUNG DER MODIFIKATIONEN IN DIE FÜNF-SCHICHTEN-ARCHITEKTUR ABBILDUNG 3.4: LADEPROZESS EINER TABELLE BEIM STARTEN DER DATENBANK ABBILDUNG 3.5: EINORDNUNG DER ÄNDERUNGEN AM ZUGRIFFSSYSTEM IN DIE FÜNF- SCHICHTEN-ARCHITEKTUR ABBILDUNG 3.6: ÜBERSICHT ÜBER DEN PROZESSFLUSS BEI DER ANFRAGEVERARBEITUNG IM HYBRIDEN DBMS ABBILDUNG 3.7: GROBER ABLAUF FÜR DIE BERECHNUNG VON AGGREGATFUNKTIONEN MIT BEDINGUNGEN ABBILDUNG 3.8: POSITION DER ZEITMESSUNG IM PROGRAMMFLUSS ABBILDUNG 3.9: GEÄNDERTE ANFRAGEVERARBEITUNG IM HYBRIDEN DBMS ABBILDUNG 4.1: LESEN UND SCHREIBEN VON TEXT-TABELLEN IN HSQLDB NACH [NGU12] 39 ABBILDUNG 4.2: GROBE ÜBERSICHT DER ANFRAGEVERARBEITUNG IN HSQLDB ABBILDUNG 4.3: MODIFIZIERTES LESEN UND SCHREIBEN VON TEXT-TABELLEN NACH [NGU12] ABBILDUNG 4.4: PROGRAMMABLAUF BEIM INITIALEN EINLESEN EINER TABELLE... 50

8 VI Abbildungsverzeichnis ABBILDUNG 4.5: MODIFIZIERTES LESEN UND SCHREIBEN VON TEXT-TABELLEN IM HYBRIDEN DBMS ABBILDUNG 4.6: ÜBERPRÜFUNG DER BEDINGUNGEN ABBILDUNG 4.7: GEÄNDERTE ANFRAGEVERARBEITUNG IM HYBRIDEN DBMS ABBILDUNG 4.8: ÜBERPRÜFUNG DER BEDINGUNGEN ABBILDUNG 5.1: ERGEBNISSE DER GETESTETEN ANFRAGEN MIT AGGREGATFUNKTIONEN ABBILDUNG 5.2: ERGEBNISSE DER GETESTETEN ANFRAGEN OHNE AGGREGATFUNKTIONEN ABBILDUNG 5.3: DURCHSCHNITTLICHE ANTWORTZEITEN DER GETESTETEN ANFRAGEN... 72

9 Tabellenverzeichnis VII Tabellenverzeichnis TABELLE 2.1: STRUKTUREN VERSCHIEDENER SCHICHTEN IN DER FÜNF-SCHICHTEN- ARCHITEKTUR (NACH [SSH08A]) TABELLE 2.2: ABGRENZUNG OLAP ZU OLTP (NACH [SSH08B]) TABELLE 3.1: VERSCHIEDENE ANFRAGETYPEN ALS ANFORDERUNG AN DAS HYBRIDE DBMS 25 TABELLE 3.2: SPEICHERSTRUKTUR FÜR TABELLENSPALTEN TABELLE 4.1: ERGEBNISSE DES FUNKTIONSTESTS... 62

10

11 Quelltextverzeichnis IX Quelltextverzeichnis LISTING 4.1: AUSSCHNITT AUS DER KLASSE MYCOLUMN LISTING 4.2: ÄNDERUNGEN AN DER VARIABLENDEFINITION DER KLASSE TEXTCACHE.JAVA. 45 LISTING 4.3: ORIGINALE METHODE TEXTTABLE.CONNECT() LISTING 4.4: GEÄNDERTE METHODE TEXTTABLE.CONNECT() LISTING 4.5: METHODE TEXTCACHE.GETFROMFILE() NACH NGUYEN LISTING 4.6: GEÄNDERTE METHODE TEXTCACHE.GETFROMFILE() LISTING 4.7: GEÄNDERTE METHODE ROWSTOREAVLDISKDATA.GET() LISTING 4.8: VARIABLENDEFINITION FÜR DIE VERBINDUNG ZUM CACHE IN QUERYSPESIFICATION.BUILDRESULT() LISTING 4.9: VERZWEIGUNG DES PROGRAMMFLUSSES IN QUERYSPESIFICATION.BUILDRESULT() LISTING 4.10: ORIGINALE SCHLEIFE ZUM AGGREGIEREN DER WERTE IN QUERYSPESIFICATION.BUILDRESULT() LISTING 4.11: GEÄNDERTE SCHLEIFE ZUM AGGREGIEREN DER WERTE IN QUERYSPESIFICATION.BUILDRESULT() LISTING 4.12: ORIGINALE METHODE EXPRESSIONAGGREGATE.UPDATEAGGREGATINGVALUE() LISTING 4.13: GEÄNDERTE METHODE EXPRESSIONAGGREGATE.UPDATEAGGREGATINGVALUE() LISTING 4.14: METHODE RANGEVARIABLE.MYNEXT() LISTING 4.15: ÄNDERUNGEN AN DER METHODE RANGEVARIABLE.MYFINDNEXT() LISTING 4.16: METHODE EXPRESSION.MYTESTCONDITION() LISTING 4.17: ÄNDERUNGEN AN DER METHODE EXPRESSIONLOGICAL.MYGETVALUE() LISTING 4.18: ÄNDERUNGEN AN DER METHODE EXPRESSIONCOLUMN.MYGETVALUE() LISTING 4.19: AUFRUF DER METHODE MYGETVALUE() IN QUERYSPECIFICATION.BUILDRESULT()... 60

12 X Quelltextverzeichnis LISTING 4.20: METHODE EXPRESSION.MYGETROWVALUE() LISTING 5.1: SCHEMA DES BENCHMARKS DBMBENCH LISTING 5.2: GETESTETE ANFRAGEN MIT AGGREGATFUNKTIONEN LISTING 5.3: GETESTETE ANFRAGEN OHNE AGGREGATFUNKTIONEN LISTING 6.1: GETESTETE DDL-ANFRAGEN LISTING 6.2: GETESTETE DML-ANFRAGEN LISTING 6.3: GETESTETE DQL-ANFRAGEN LISTING 6.4: GETESTETE DQL-ANFRAGEN MIT AGGREGATFUNKTIONEN LISTING 6.5: METHODEN MYREADOBJECT(INT) UND MYREADOBJECT(INT, INT) DER KLASSE TEXTCACHE.JAVA (TEIL 1) LISTING 6.6: METHODE MYREADOBJECT(INT, INT) DER KLASSE TEXTCACHE.JAVA (TEIL 2).. 78 LISTING 6.7: METHODE GET(ROWINPUTINTERFACE[]) DER KLASSE ROWSTOREAVLDISKDATA.JAVA LISTING 6.8: METHODE MYFINDNEXT(OBJECT, INT[], INT, INT) DER KLASSE RANGEVARIABLE.JAVA LISTING 6.9: METHODE MYGETVALUE(SESSION, OBJECT[], INT[], INT) DER KLASSE EXPRESSIONLOGICAL.JAVA (TEIL 1) LISTING 6.10: METHODE MYGETVALUE(SESSION, OBJECT[], INT[], INT) DER KLASSE EXPRESSIONLOGICAL.JAVA (TEIL 2)... 82

13 Abkürzungsverzeichnis XI Abkürzungsverzeichnis CSV DBMS DBS DDL DML DQL DS EDV GS HSQLDB IMDB ISS JVM MB MOS OLAP OLTP PB SEQUEL SOS SPS SQL TB TID TPC Comma-Separated Values Datenbankmanagementsystem Datenbanksystem Data Definition Language Data Manipulation Language Data Query Language Dateischnittstelle Elektronische Datenverarbeitung Geräteschnittstelle Hyper Structured Query Language Database In-Memory-Datenbank Interne Satzschnittstelle Java Virtual Maschine Megabyte Mengenorientierte Schnittstelle Online Analytical Processing Online Transaction Processing Petabyte Structured English Query Language Satzorientierte Schnittstelle Systempufferschnittstelle Structured Query Language Terabyte Tupel-Identifier Transaction Processing Performance Council

14

15 1. Einführung 1.1. Motivation Datenbanksysteme (DBS) sind heutzutage ein fester Bestandteil der Informatik und bilden oft den zentralen Teil von Unternehmenssoftware und sonstiger Softwaresysteme. Überall wo große Mengen von Daten gespeichert werden müssen, kommen Datenbanken zum Einsatz. Somit nehmen Datenbanken eine wichtige Rolle in der Elektronischen Datenverarbeitung (EDV) ein und sind aus Behörden und Unternehmen nicht mehr wegzudenken. Die meisten Daten eines Unternehmens wie z.b. Kunden, Lieferanten, sowie auch Produkte und Bestellungen sind in Datenbanken gespeichert. Unternehmen sind also auf die Verfügbarkeit, Vollständigkeit und Richtigkeit der Daten angewiesen, um auf dem Markt zu überleben. Ohne Datenbanken müssten Firmen ihre Kunden oder Produkte z.b. als Textdateien oder Tabellen speichern oder für jedes Szenario ein eigenes Programm entwickeln. Beim Einsatz vieler unterschiedlicher Programme, werden viele Daten redundant gespeichert und somit geht schnell der Überblick verloren. Die Speicherung in Textdateien mag bei einigen wenigen Datensätzen noch gehen. Aber denken wir nur an einen großen Supermarkt, in dem jeder Kaufprozess gespeichert wird. Ohne ein einheitliches Speicher- und Abfragesystem, kann niemand so leicht bzw. so schnell ermitteln, welche Stückzahl eines Produktes an einem bestimmten Tag verkauft wurde oder wie viel Gewinn der Supermarkt in einem Jahr erwirtschaftet. Mit einem Datenbanksystem ist das kein Problem. Es muss nur die richtige Anfrage gestellt werden und sofort liefert das System die entsprechende Antwort. Aus diesen Gründen wurden Datenbankensysteme entwickelt, nämlich um große Datenmengen effizient und dauerhaft zu speichern und diese Daten leicht wieder abzufragen. Ihren Anfang hatten Datenbanksysteme in den 1960er Jahren mit der Einführung des neuen Konzeptes, der Datenverwaltung in einer eigenen Schicht zwischen Betriebssystem und dem

16 2 Einführung Anwendungsprogramm. In den 1970er Jahren wurde dann das erste relationale Datenbanksystems System R und die Abfragesprache SEQUEL entwickelt. Ende der 1970er entwickelte Oracle eine eigene Datenbank unter gleichem Namen [SSH08b]. Diese Systeme haben sich schnell auf dem Markt etabliert und verdrängten die hierarchischen und die netzwerkartigen Systeme vom Markt. Später wurden noch viele weitere Datenbanksysteme entwickelt und aus SEQUEL wurde die Abfragespreche SQL. Von den zahlreichen Datenbanksystemen sind heute Oracle, IBM DB2 und Microsoft SQL Server die populärsten kommerziellen Systeme. Des Weiteren wurden seit den 1990er auch eine Vielzahl von Open-Source Datenbanksystemen, wie z.b. MySQL, PostgreSQL und HSQLDB entwickelt. Aber auch die großen kommerziellen Anbieter bieten inzwischen Open-Source Versionen ihrer Produkte an. Historisch gesehen wurden die meisten Datenbanksysteme als sogenannte Row-Stores entwickelt, die ihre Daten Zeile für Zeile speichern und verarbeiten. Allerdings gibt es noch den Ansatz der spaltenweisen Speicherung und Verarbeitung. Solche Datenbanken werden als Column-Store bezeichnet. Bekanntermaßen müssen zweidimensionale Tabellen erst linearisiert werden, um sie auf einem eindimensionalen Speichermedium zu speichern und das geht am einfachsten entweder Zeile für Zeile oder Spalte für Spalte. Historisch gesehen wurden Datenbanken für kurze Transaktionen (Online Transaction Processing, kurz: OLTP) entwickelt. Die Transaktionen können z.b. das Hinzufügen eines neuen Kunden, Löschen eines Kunden oder bearbeiten der Attribute eines Kunden sein. Somit wurden die Datenbanken zeilenweise gespeichert, um die Attribute einer Entität nah bei einander zu halten. Seit den 1990er Jahren rückte jedoch immer mehr der analytische Zweck der Datenbanken in den Vordergrund und es entstanden sogenannte Data-Warehouses. Ein Data-Warehouse dient vor allem der Analyse der gesammelten Daten, was als Online Analytical Processing (OLAP) bezeichnet wird. Für die Analyse der Daten greift das System meist gleich auf komplette Attributspalten zu und bildet Summen, Durchschnitte und sonstige Aggregate. Somit würde sich hierfür die spaltenweise Speicherung besser eignen. Allerdings wurden auch Data-Warehouse-Systeme historisch meist als Row-Stores implementiert, weil die Entwickler dafür bereits eine gute Basis hatten.

17 Zielsetzung der Arbeit Zielsetzung der Arbeit Diese Arbeit beschäftigt sie sich mit dem Thema der zeilenorientierten und spaltenorientierten Datenbanken und der Anfrageverarbeitung auf diesen unterschiedlichen Speicherungsvarianten. Dafür werden folgende Ziele definiert: Als erstes Ziel sollen die Vorteile und Nachteile von Row-Stores und Column-Stores für unterschiedliche Anwendungsdomänen diskutiert werden, wodurch die Unterschiede und Einsatzgebiete dieser beiden Speicherungsvarianten verdeutlicht werden sollen. Dies soll auch eine Motivation für die weiteren Ziele dieser Arbeit sein, die im Folgenden genannt werden. Ein weiteres Ziel, ist es ein Konzept für ein hybrides Datenbankmanagementsystem (DBMS) zu schaffen, welches sowohl die Vorteile der zeilenorientierten aus auch der spaltenorientierten Speicherung in sich vereinen soll. Dadurch soll das DBMS sowohl für OLTP-Anfragen als auch für OLAP-Anfragen geeignet sein und die Antwortzeiten für OLAP- Anfragen minimieren. Außerdem soll ein Prototyp des vorgestellten Konzepts implementiert werden, welcher auf dem Open-Source Datenbanksystem HSQLDB (Hyper Structured Query Language Database) basiert. Dazu wird eine bereits modifizierte Version von HSQLDB, die Texttabellen spaltenweise abspeichert, so erweitert, dass sie die Daten chunkweise einliest und die Tabellen anschließend sowohl als Zeilen als auch als Spalten im Arbeitsspeicher ablegt. Des Weiteren wird auch die Anfrageverarbeitung modifiziert, um die Vorteile der spaltenweisen Speicherung für analytische Anfragen auszunutzen. Diese Implementierung soll dann letztendlich als Grundlage für eine Evaluation des hybriden DBMS dienen Gliederung Die vorliegende Arbeit besteht aus sechs Kapiteln. Nach der kurzen Einführung in Kapitel 1 umfasst das 2. Kapitel die Grundlagen von Datenbanksystemen. Darauf basieren die weiteren Kapitel dieser Arbeit. Die Grundlagen sind notwendig, um die gesamte Arbeit besser zu verstehen und um nicht alles in anderen Quellen nachlesen zu müssen.

18 4 Einführung Kapitel 3 beschäftigt sich mit dem Konzept eines hybriden DBMS. Dabei werden als erstes die Anforderungen an das hybride System beschrieben und anschließend die Änderungen aufgeführt. In Kapitel 4 wird dem Leser eine Implementierung des hybriden Konzeptes vorgestellt, wobei ein bereits vorhandenes Datenbanksystem zu diesem Zweck erweitert bzw. geändert wird. Kapitel 5 beschäftigt sich anschließend mit der Evaluierung der Implementierung. Es wird also ein Benchmark durchgeführt und die Ergebnisse dieses Benchmarks werden vorgestellt. Dadurch können Schlussfolgerungen gezogen werden, ob die Ziele der Arbeit erreicht wurden oder nicht. Zum Abschluss wird in Kapitel 6 die Arbeit nochmal kurz zusammengefasst. Des Weiteren wird dort ein Ausblick gegeben und es werden Probleme angesprochen, die möglicherweise die Themen von weiteren Arbeiten sein können.

19 2. Grundlagen In diesem Kapitel werden die Grundlagen vorgestellt, auf denen die weitere Arbeit basiert. Somit ist dieses Wissen notwendig, um den technischen Hintergrund bzw. die Funktionsweise von Datenbanken und insbesondere den Unterschied zwischen zeilenorientierter und spaltenorientierter Speicherung und Verarbeitung der Daten besser zu verstehen. Hierzu wird als erstes die Fünf-Schichten-Architektur mit all ihren Komponenten, auf der die meisten relationale Datenbanksysteme heutzutage basieren, ausführlich beschrieben. Demzufolge ist dies wichtig, um die Funktionsweise von Datenbanken zu verstehen und um besser zu begreifen an welcher Stelle später etwas geändert wird. Danach werden unterschiedliche Domänen von Datenbanken beschrieben, wobei auch auf die Begriffe OLTP und OLAP eingegangen wird. Am Ende dieses Kapitels wird nochmal genauer auf die zeilenweise (engl. Row-Store) und spaltenweise Speicherung (engl. Column-Store) eingegangen und die Vorteile und Nachteile dieser Speicherungsarten für OLTP und OLAP deutlich gemacht Die Fünf-Schichten-Architektur Die Fünf-Schichten-Architektur ist eine wichtige Datenbankarchitektur, die besonders die Unabhängigkeit der Anwendung und der Datenbank voneinander betont. Diese sind also voneinander abgekoppelt und können somit eigenständig geändert werden, ohne Einfluss auf die jeweils andere Komponente zu haben. Die Grundlagen dafür wurden 1973 von Senko [Sen73] eingeführt. Später wurde diese Idee von Härder [Här87] weiterentwickelt und auf den aktuellen Stand gebracht. Die Aufgabe der Architektur ist die Beschreibung der Transformationskomponenten, welche die Anfragen höherer Datenbanksprachen (z.b. SQL) Schritt für Schritt bis hin zu den Zugriffen auf Speichermedien transformieren. Die

20 6 Grundlagen komplexen Datenbankanfragen werden somit schrittweise umgewandelt, bis hin zu einfachen Zugriffen auf einzelne Datenblöcke [Här87]. Insgesamt besteht diese Architektur aus fünf Schichten und sechs Schnittstellen. Diee Abbildung 2.1 zeigtt die Komponenten der Fünf- die Schichten-Architektur und deren Funktionen. In den folgenden Abschnitten werden Schichten und Schnittstellen ausführliche er beschrieben. Abbildung 2. 1: Funktionsorientiertee Sicht auf die Fünf-Schichten-Architektur (nach [SSH08a]) Schnittstellen der Architektur Wie im vorherigen Abschnitt bereits erwähnt, enthält die Fünf-Schichten-Architektur insgesamt sechs Schnittstellen, die im Folgenden kurz beschrieben werden.. Die oberste Schnittstelle, die am nächsten zu der Anwendungsebene liegt, ist die Mengenorientierte Schnittstelle (MOS). Über dieser Schnittstelle liegt nur die Datenbankanwendung, die die Anfragen an die Datenbank stellt. Diese Schnittstelle verbindet also die Anwendung und das Datensystem miteinander. Die MOS realisiert eine deklarative

21 Die Fünf-Schichten-Architektur 7 Datenmanipulationssprache (Data Manipulation Language, kurz DML) auf Tabellen, Sichten und Zeilen. Beispiele für DML sind Sprachen wie SQL und QBE, mit mengenorientiertem Zugriff auf Relationen. Als Nächstes werden die Anweisungen durch das Datensystem auf die Satzorientierte Schnittstellen (SOS) umgesetzt, wobei die SQL-Anfragen vom Datensystem dafür übersetzt und optimiert werden. Die SOS realisiert einen navigierenden Zugriff auf interne Darstellung der Relationen. Die durch diese Schnittstelle manipulierten Objekte sind typisierte Datensätze und interne Relationen, sowie auch logische Zugriffspfade (Indexe) und temporäre Zugriffsstrukturen (Scans). Danach werden die Anweisungen durch das Zugriffssystem auf die interne Satzschnittstelle (ISS) umgesetzt. Hier werden die internen Tupel einheitlich, also ohne Typisierung, verwaltet. Des Weiteren werden hier die Speicherstrukturen der Zugriffspfade realisiert, wie etwa B*-Bäume und Hash-Tabellen, um einen schnellen Zugriff auf die Datensätze zu gewährleisten. Außerdem wird hier der Mehrbenutzerbetrieb mit Transaktionen implementiert. Durch das Speichersystem werden Datenstrukturen und Operationen der ISS auf interne Seiten eines virtuellen linearen Adressraums umgesetzt. D.h. also dass die Tupel zur internen Verwaltung auf Seiten fester Größe gepackt werden. Für die Manipulation des Adressraums ist die Systempufferschnittstelle (SPS) verantwortlich. Typische Objekte sind hier z.b. interne Seiten und Seitenadressen, welche durch typische Operationen wie Freigeben und Bereitstellen von Seiten verwaltet werden. Als letzter Schritt werden die internen Seiten durch die Pufferverwaltung auf Blöcke der Dateischnittstelle (DS) abgebildet. Die restlichen Aufgaben übernimmt ab hier das Betriebssystem. So setzt es z.b. die DS-Operationen auf die Geräteschnittstelle um und verwaltet den externen Speicher. Um einen besseren Überblick über die Schnittstellen und ihren Zusammenhang zu haben, werden in der Abbildung 2.2 beispielhaft typische Objekte (links) und typische Operationen (rechts) dargestellt.

22 8 Grundlagen Schichten der Architektur Abbildung 2.2: Typische Objekte und Operationen der Schnittstellen derr Fünf-Schichten- Architektur (nach [SSH08a]) Nach vorheriger Beschreibung der Schnittstellen, werden nunn die einzelnen Schichten der Architektur genauer erklärt, wobei diesmal aber von unten nachh oben vorgegangen wird. Die Betriebssystemebene derr Fünf-Schichten-Architektur ist die d Grundlage für alle weiteren Schichten, ist aber kein Bestandteil des eigentlichenn DBMS [SSH08a]. Deshalb werden wir diese Ebene hier nur kurz erwähnen undd später nicht mehr darauf eingehen. Da diese Ebene für das Konzept bzw. für die Implementierung nicht weiter interessant ist, wurde sie in der Abbildung 2.2 ausgegraut. Abschließend wäre zur Betriebssystemebene nur noch zu erwähnen, dass sie die Speichermedienn verwaltet, auf denen die eigentliche Datenbank gespeichert wird. Außerdem werden auch Treiberprogramme zum Zugriff auf Daten dieser Medien bereitgestellt und um ein schnelles Lesen zu gewährleisten,, werden Caching- Mechanismen benutzt. Wobei der Cache des Betriebssystems nicht mit dem Puffer des DBMS zu verwechseln ist.

23 Die Fünf-Schichten-Architektur 9 Die Aufgabe der Pufferverwaltung ist Verwaltung der benötigten Blöcke des Sekundärspeichers (z.b. Festplatte) im Arbeitsspeicher. Dazu wird im Arbeitsspeicher ein begrenzter Speicherplatz zur Verfügung gestellt, der Puffer (engl. buffer) genannt wird. Je nach Arbeitsspeichergröße und Anwendung kann die Puffergröße stark variieren, häufig wird aber eine Größe von 25% des verfügbaren Arbeitsspeichers empfohlen [SSH08a]. Im Normalfall sind es aber trotzdem weniger als 1% der gesamten Datenbank [HR99]. Alle Leseund Schreibvorgänge von oder auf Seiten werden jedoch im Arbeitsspeicher durchgeführt. Somit muss jede zu bearbeitende Seite zuvor in den Arbeitsspeicher geladen werden, wodurch der Puffer leicht zum Flaschenhals werden kann [SSH08a]. Ist der Arbeitsspeicher jedoch groß genug, kann auch die gesamte Datenbank beim Start in den Puffer geladen werden, so dass beim Arbeiten nicht mehr auf die Festplatte zugegriffen werden muss und nur noch beim Beenden der Datenbankanwendung wieder auf die Festplatte ausgelagert wird. Diese Art von Datenbanken wird In-Memory-Datenbank (IMDB, engl. in-memory database) genannt und bietet einen wesentlich schnelleren Zugriff auf die Daten, als herkömmliche Datenbanken [PZ11]. Die Datenbank, die später bei der Evaluation verwendet wird, wird ebenfalls eine Art In-Memory-Datenbank sein, bei der die Tabellen zwar in Textform auf der Festplatte liegen, aber beim Start vollständig in der Arbeitsspeicher geladen werden. Der grundlegende Ablauf eines Zugriffs auf eine Seite läuft in der Art und Weise ab, dass die höhere Schicht (das Speichersystem) eine Seite bei der Pufferverwaltung anfordert und dabei folgende zwei Situationen auftreten können: Die angeforderte Seite befindet sich bereits im Puffer und wird somit direkt an das Speichersystem übergeben. Die angeforderte Seite befindet sich nicht im Puffer (engl. page fault). Somit muss die Seite bei der Betriebssystemebene angefordert und von der Festplatte in den Arbeitsspeicher geladen werden. Falls der Puffer vor dem Laden der neuen Seite bereits voll ist, muss eine Seite aus dem Puffer verdrängt werden, wobei die verdrängte Seite ggf. wieder auf die Festplatte zurückgeschrieben werden muss. Somit sind die wesentlichen Aufgaben der Pufferverwaltung, die Zuteilung von Speicherplatz für Seiten und das Suchen und Ersetzen von Seiten im Puffer, aber auch die Optimierung der Lastverteilung zwischen parallelen Transaktionen gehört mit dazu [SSH08a].

24 10 Grundlagen Während wir bei der Pufferverwaltung von Seiten, im Sinne von reinen Byte-Containern, gesprochen haben, sprechen wir bei dem Speichersystem nun von internen Datensätzen. Im Gegensatz dazu werden die verwendeten Strukturen in den beiden folgenden Ebenen, logische Datensätze (oder auch interne Tupel) und schließlich Tupel genannt. Die Tabelle 2.1 bietet einen Überblick über die verschiedenen Strukturen auf den verschiedenen Schichten der Architektur. Struktur Tupel interne Tupel oder logischer Datensatz interner Datensatz Seite Systemkomponente Datensystem Zugriffssystem Speichersystem Pufferverwaltung Tabelle 2.1: Strukturen verschiedener Schichten in der Fünf-Schichten-Architektur (nach [SSH08a]) Die Aufgabe des Speichersystems ist die Abbildung dieser internen Datensätze auf Seiten. Die zwei Hauptprobleme des Speichersystems sind dabei die Adressierung der Tupel innerhalb der Seiten und die Abbildung von Tupel auf die Seiten [SSH08a]. Nur der Vollständigkeit halber ist hier zu erwähnen, dass die Adressierung der Tupel oft über das TID-Konzept (Tupel-Identifier) realisiert wird und bei der Abbildung der Tupel auf Seiten zwischen verschiedenen Satztypen unterschieden werden muss. Da dies aber für diese Masterarbeit nicht weiter von Interesse ist, wird es hier nicht näher betrachtet. Als vertiefende Literatur hierzu siehe [SSH08a]. Die Aufgabe des Zugriffssystems ist die Abbildung der konzeptuellen Relationen oder Tupel auf interne Relationen oder interne Tupel. Die internen Tupel können z.b. Elemente eines Zugriffspfads auf die konzeptuelle Relation oder Elemente einer Dateidarstellung der Relation sein. Allgemein bestehen die internen Tupel aus Feldern, die den Attributen der Tupel entsprechen [SSH08a]. Typische Operationen im Zugriffssystem sind sogenannte Scans, die als interner Cursor auf Dateien oder Zugriffspfaden arbeiten. Somit können mit Scans entweder alle Elemente der internen Relationen durchlaufen werden (full table scan) oder bestimmte Bereiche in Sortierreihenfolge ausgelesen werden (index scan). Es ist auch möglich, einen Zugriffspfad

25 Die Fünf-Schichten-Architektur 11 auf eine Datei selbst wieder als Datei zu speichern. In diesem Fall ist dann von einem Index oder einer Indexdatei die Rede. Der schnelle Zugriff auf Datensätze über einen Primärschlüssel wird meist durch einen B+- Baum oder eine Hash-Tabelle realisiert. Um einen schnellen Zugriff auch über einen Sekundärschlüssel zu gewährleisten, werden Indexdateien benutzt, denn ansonsten müssten alle Elemente durchgegangen werden, um einen Datensatz über einen Sekundärschlüssel zu finden. Das Datensystem ist die oberste Schicht der Architektur, welche die Anfragen der MOS übersetzt und sie weiter an die SOS leitet. Dabei hat das Datensystem im Wesentlichen die drei folgenden Aufgaben zu leisten [SSH08a]: Optimierung: Die an die Datenbank gestellten Anfragen sind für das DBMS nicht immer optimal und können durch das Datensystem oft in einen äquivalenten Ausdruck umgeformt werden, der aber schneller abgearbeitet werden kann. Die Umformung des Ausdrucks kann durch einfaches Query Rewriting und durch konzeptuelle oder logische Optimierung erfolgen. Wenn es viele äquivalente Anfragen gibt, wird der effizienteste Ausdruck nach Kostenschätzung ermittelt. Zugriffspfadwahl: Um eine effiziente Abarbeitung einer Anfrage zu gewährleisten, werden geeignete Strukturen und Operationen benötigt. Somit muss der Optimierer die am besten geeigneten Zugriffspfade bestimmen. Auswertung: Da Relationenalgebra-Operationen auf verschiedene Arten implementiert werden können, muss sich das Datensystem für einen Auswertungsalgorithmus entscheiden. Die Wahl des Algorithmus kann die Antwortzeit entscheidend beeinflussen und deshalb muss der beste Algorithmus für die entsprechende Anfrage ausgewählt werden. Allgemein wäre noch zu sagen, dass die Fünf-Schichten-Architektur nur ein Vorschlag für die Aufteilung der Transformationsschritte ist. Somit müssen sich Datenbanksysteme nicht daran halten, aber die meisten modernen Systeme wurden nach diesem Vorschlag umgesetzt. So auch das Open-Source Datenbanksystem HSQLDB, welches im Rahmen dieser Masterarbeit erweitert werden soll. Es werden später zwar nicht alle Schichten und Schnittstellen bei der Implementierung verändert, aber trotzdem sollten die einzelnen Schritte der Abarbeitung

26 12 Grundlagen immer klar sein. Aus diesem Grund wird an den entsprechenden Stellen in den nächsten Kapiteln immer wieder Bezug auf die Fünf-Schichten-Architektur genommen Anwendungsdomänen von Datenbanken Historisch haben sich Datenbanken hauptsächlich dahin entwickelt, operative Unternehmensdaten wie Produkte, Kunden, Lieferanten usw. zu speichern und zu verwalten [Far11]. Aber natürlich sind Datenbanken nicht nur darauf beschränkt, sondern können für unterschiedlichste Zwecke eingesetzt werden, solange es sinnvoll ist, diese in Relationen zu speichern, und besonders, wenn es auf strukturierte Datenverwaltung und effizienten Datenzugriff ankommt. Transaktionen, die unter anderem auch typisch für die Verwaltung von Kunden sind, wie z.b. Hinzufügen eines neuen Kunden, Löschen von Kunden, Bearbeiten der Kundendaten, werden unter dem Begriff OLTP (Online Transactional Processing) zusammengefasst [GR93, BN97]. Bei diesen Anfragen handelt es sich also meist um kurze Lese- oder Schreibtransaktionen, die nur auf wenigen Tupel arbeiten. Im Gegensatz dazu, wurde im Zusammenhang mit dem Begriff Data Warehouse, der Begriff OLAP (Online Analytical Processing) eingeführt [CD97, Inm96, HK08]. Wobei es sich hierbei meist um lange Lesetransaktionen handelt, die auf sehr vielen Datensätzen arbeiten und zu Analysezwecken eingesetzt werden. In den folgenden Abschnitten sollen die Unterschiede zwischen OLAP und OLTP nochmal genauer verdeutlicht werden. Um den Begriff OLAP genauer zu definieren, sollten wir zuerst auf das Data Warehouse eingehen, weil die Begriffe eng mit einander zusammenhängen. Der Begriff Data Warehouse wurde in den 1990er Jahren von W. H. Inmon geprägt und wird folgendermaßen definiert [Inm96]: Ein Data Warehouse ist eine fachorientierte, integrierte, nicht-flüchtige und zeitbezogene Ansammlung von Daten zur Unterstützung von Managemententscheidungen. Anders gesagt ist ein Data Warehouse eine für die Entscheidungsfindung optimierte Datenbank, die Informationen aus unterschiedlichen Quellen integriert [Far11]. Dabei arbeitet

27 Speicherungsvarianten von Datenbanken 13 das Data Warehouse nicht auf operativen Daten, also Daten, die für die Arbeitsabläufe im Unternehmen benötigt werden, sondern auf Kopien der Daten. Die für die Analyse benötigten Daten werden aus anderen Quellen in Abständen in das Data Warehouse geladen und in der Regel nicht mehr gelöscht. Somit wachsen diese Datenbanken immer weiter und können Größen von mehreren Terabyte (TB) oder sogar Petabyte (PB) erreichen. Die bekanntesten Data Warehouses, deren Datenbanken riesige Dimensionen erreicht haben, sind z.b. Walmart und Amazon. So war im Jahre 2004 das Data Warehouse von Walmart 480 TB groß und wird heute auf mehrere PB geschätzt [SSK11] Speicherungsvarianten von Datenbanken Wie bereits erwähnt, haben die Daten von relationalen Datenbanken eine zweidimensionale Struktur, weil eine Relation eine zweidimensionale Tabelle darstellt. In diesen Tabellen werden zusammengehörende Werte (also Tupel) jeweils in einer Zeile gespeichert. Demzufolge enthalten Spalten einer Tabelle die gleichen Attribute aller Tupel. Bedingt durch den eindimensionalen Speicher, z.b. Festplatte, müssen zweidimensionale Tabellen zuerst linealisiert werden, um sie zu speichern. Somit gibt es zwei offensichtliche Arten diese Relationen zu speichern. Die erste Art ist die Tabellen Zeile für Zeile zu speichern. Solche Datenbanken werden zeilenorientierte Datenbanken oder Row-Stores genannt. Die zweite Art, die Tabellen auf einem eindimensionalen Speicher abzulegen, ist sie Spalte für Spalte zu speichern. Diese Art von Datenbanken werden spaltenorientierte Datenbanken oder Column- Stores genannt. Historisch wurden Datenbanken meist als Row-Store implementiert. Denn bei OLTP- Anfragen kommt es auf die Nähe der Attribute eines Tupels an, weil diese meist auf nur wenigen Datensätzen arbeiten. Somit werden bei OLTP-Anfragen meist ganze Tupel geladen bzw. bearbeitet und damit dies möglichst schnell vonstattengehen kann, ist die sequenzielle Speicherung der Tupel von Vorteil. Auch die späteren OLAP-Systeme (bzw. Data Warehouses) wurden von den großen Datenbankunternehmen als Row-Stores implementiert. Das geschah meist aber nur, weil die Entwickler der Data Warehouses bereits eine solide Grundlage für einen Row-Store hatten [Dbm09]. Bei analytischen Anfragen kommt es aber meist auf die Nähe der gleichen Attribute aller Tupel an, worüber Summen und andere Aggregate berechnet werden. Aus diesem Grund ist eine spaltenweise Speicherung und

28 14 Grundlagen Verarbeitung der Daten hierfür sinnvoller, weil dann wirklich nur die benötigten Spalten geladen werden müssen und der Zugriff f auf die Spalten sequenziell erfolgen kann. Dadurch entstehen nämlich weniger Ein- und Ausgaben beim Lesen und Schreiben und auch die Prozessorauslastung sinkt, weshalb mit schnelleren Antwortzeit ten zu rechnen ist Zeilenorientierte Datenbanken (Row-Stores) Die zeilenweise Speicherung von Daten in einer Datenbank bedeutet, dass die Zeilen fortlaufend nacheinander gespeichert werden und somit immer ganze Zeilen gelesen oder geschrieben werden. Diese Art ist die heutzutage am meisten verbreitete Form und wird unter anderem in den drei populärsten Datenbanksystemen (Oracle, IBM I DB2 und Microsoft SQL Server) eingesetztt [Aba08]. Die zeilenweise Speicherung einer Datenbanktabelle wird beispielhaft in der Abbildung 2.3 dargestellt. Abbildung 2.3: : Zeilenweise Speicherung einer DatenbanktaD abelle Diese Art der Speicherung ist historisch entstanden. Dadurch, dass diee Tupel sequenziell gespeichert werden, könnenn sie ebenfalls sequenziell wieder eingelesen werden, was logischerweise schneller ist, als die Attribute aus unterschiedlichen Stellen zusammenzusuchenn und daraus die Tupel zu konstruieren. Dadurch ist die zeilenweise Speicherung gut für OLTP-Systeme geeignet, aber für OLAP-Systeme Tupell arbeiten, ermöglichen Row- eher ungeeignet. Bei Transaktionen, die auf wenigen oder sogar nur einem Stores schnelles Lesen, Schreiben und Bearbeiten dieser Tupel. Dahingegen bei Transaktionen, die nur auf wenigen Attributen von sehr vielen Tupel arbeiten, verursacht Row-Store einen großen Overhead. Der Overhead kommt dadurch zustande, dass beim Lesen,

29 Speicherungsvarianten von Datenbanken 15 Speichern und Bearbeiten immer die gesamte Zeile verarbeitet werden muss, obwohll nur ein kleiner Teil davon benötigt wird. Somit dauern OLAP-Anfragen auf einemm Row-Store länger als eigentlich notwendig Spaltenorientierte Datenbanken (Column-Stores) Die spaltenweise Speicherung von Daten in einer Datenbankk bedeutet, dass die Tupel in einzelnee Attribute aufgeteiltt werden und die Spalten sequenziell gespeichert werden. Ebenfalls bedeutett es, dass unterschiedl liche Spalten in unterschiedlichenn Dateien bzw. auf unterschiedlichen Datenbankseiten abgelegt werden. Die Elemente E einer Zeile werden demzufolge zerstreut und müssen wieder zusammengesetzt werden, w falls komplette Tupel angefragt werden. Diese Tupelrekonstruktion wir auch Materialisierung genannt. Column-Stores kamen geschichtlich erst später als Row-Stores auf und rückten besonders mit dem Aufkommen von Data Warehouses s in den Fokus von DatenbankenD ntwicklern, weil sie dafür voraussichtlich einen Geschwindig gkeitsvorteil darstelltenn [Aba08]. Die Abbildung 2.4 stellt beispielhaft die spaltenweise Speicherung einer Datenbanktabelle dar. Abbildung 2.4: Spaltenweise Speicherung einer DatenbanktaD abelle Diese Form der Speicherung ist somit besser für OLAP geeignet, dennn ein Column-Store verursacht bei richtiger Implementierung keinen Overhead mehr, berechnungen nur die tatsächlich benötigten Spalten eingelesen bzw. da bei Aggregat- verarbeitet werden müssen. Dies bedeutet wiederum schnelleres Lesen der Daten und u schnelleres Berechnen der Aggregate, wodurch die Antwortzeiten minimiert werden. Ein Nachteil N vonn Column-Stores ist das Hinzufügen neuer Tupel, weil diese Tupel erst aufgeteilt werden müssen und jedes

30 16 Grundlagen Attribut an einer anderen Stelle, also nicht sequenziell, abgelegt wird. Somit dauern Updates beim Column-Store länger als beim Row-Store. Da aber bei OLAP bzw. Data Warehouses die Daten nur periodisch zur Datenbank hinzugefügt werden und bei den eigentlichen Anfragen nur das Lesen der Daten im Vordergrund steht, stellen die längeren Updates kein Problem dar, weil sie die Antwortzeiten nicht beeinflussen [SSK12]. Nur der Vollständigkeit halber ist noch zu erwähnen, dass Column-Stores noch weitere Optimierungsmöglichkeiten bieten, wie z.b. Kompression. Da die Daten einer Spalte immer vom selben Datentyp sind und somit sehr ähnlich zu einander sind, können sie viel besser komprimiert werden. Durch Kompression müssen weniger Daten von der Festplatte gelesen werden und ggf. kann auch gleich auf den komprimierten Daten gearbeitet werden ohne sie zu dekomprimieren. Dies würde zu einer schnelleren Verarbeitung und somit zu schnelleren Antwortzeiten führen [AMF06, DT02, SAB+05] Abgrenzung OLAP zu OLTP OLAP-Anfragen an eine Datenbank, sind Anfragen, die rein zur Analyse der vorliegenden Daten bestimmt sind und somit dem Management eines Unternehmens bei der Entscheidungsfindung helfen sollen. OLTP-Anfragen sind jedoch Transaktionen, die auf operativen Daten arbeiten und nicht nur dem Management überlassen sind, sondern von jedem Angestellten durchgeführt werden können. Die Struktur von OLTP-Anfragen ist meistens ziemlich einfach, wogegen die Struktur der OLAP-Anfragen komplexer ist. Weiterhin arbeiten OLTP-Systeme auf aktuellen Daten und für OLAP-Systeme sind eher die historischen Daten interessant, um daraus zu lernen und einen Nutzen zu ziehen. Die Daten einer Datenbank, die zu OLTP Zwecken eingesetzt wird, kommen meist aus einer Quelle und haben in der Regel ein Datenvolumen von mehreren Megabyte bis Gigabyte. Ein Data Warehouse, welches zu analytischen Zwecken eingesetzt wird, hat in der Regel jedoch ein Datenvolumen von mehreren Gigabyte bis Terabyte. Wie allerdings zuvor am Beispiel von Walmart gezeigt würde, können Data Warehouses in Extremfällen noch viel größer werden. Das kommt dadurch, dass in einem Data Warehouse nicht nur die aktuellen Daten gespeichert werden, sondern auch alle historischen Daten. Außerdem kommen diese Daten meist aus mehreren Quellen, werden nur periodisch hinzugefügt und in der Regel nicht mehr gelöscht.

31 Abgrenzung OLAP zu OLTP 17 OLAP-Anfragen stellen meist lange Lesetransaktionen dar, die über einen großen Teil der Datensätze gehen. Deswegen steigen auch die Antwortzeiten im Vergleich zu OLTP- Anfragen, die meist nur kurze Lese- oder Schreibtransaktionen darstellen, rapide an. Um aber trotzdem zeitnahe Antworten auf die analytischen Anfragen zu erhalten, wird versucht, die Abarbeitung dieser zu beschleunigen. Einen guten Ansatz hierfür bieten spaltenorientiere Datenbanken (siehe Abschnitt 2.3.2), da analytische Anfragen oft den Fokus auf einzelne Attribute und nicht auf komplette Tupel haben, wie es bei OLTP-Anfragen der Fall ist. Spaltenorientierte Datenbanken sind also theoretisch besser für OLAP-Systeme geeignet als zeilenorientierte Datenbanken und für OLTP-Systeme gilt das genau umgekehrt. Ein Überblick über die Unterschiede zwischen OLTP und OLAP (bzw. Data Warehouse) ist in der Tabelle 2.2 zu finden. Anfrage transaktional (OLTP) analytisch (OLAP) Fokus auf Lesen, Schreiben, Löschen, Modifizieren Lesen, periodisches Hinzufügen Transaktionsdauer und kurze Lese- und Schreibtransaktionen lange Lesetransaktionen -typ Anfragestruktur einfache Struktur komplexe Struktur Datenvolumen einer wenige Datensätze viele Datensätze Anfrage Datenmodell anfrageflexibel analysebezogen Datenquellen meist eine mehrere Eigenschaften nicht abgeleitet, zeitaktuell, autonom, dynamisch abgeleitet/konsolidiert, nicht zeitaktuell, integriert, stabil Datenvolumen Megabyte bis Gigabyte Gigabyte bis Terabyte Zugriffe Einzeltupelzugriff Tabellenzugriff Anwendertyp Ein-/Ausgabe durch Angestellte Manager, Controller, Analyst oder Applikationssoftware Anwenderzahl sehr viele wenige (bis einige hundert) Antwortzeit Millisekunden bis Sekunden Sekunden bis Minuten Tabelle 2.2: Abgrenzung OLAP zu OLTP (nach [SSH08b]) Somit scheint es, dass die Grenzen zwischen OLAP und OLTP klar definiert sind und diese Begriffe zwei unterschiedliche Welten darstellen. Allerdings dringen heutige OLTP-Systeme

32 18 Grundlagen immer mehr in den analytischen Aufgabenbereich vor und deshalb verschwimmen die Grenzen zwischen normalen Datenbanksystemen und Data Warehouses immer mehr [GG00, Gro03]. Das heißt, dass nicht nur Data Warehouses sondern auch immer mehr OLTP-Systeme für die Entscheidungsfindung eingesetzt werden. Aus diesem Grund ist das hybride Datenbankmanagementsystem, das im Rahmen dieser Arbeit implementiert werden soll und das für OLTP- und OLAP-Funktionalität optimiert ist, genau der richtige Ansatz für diesen Trend.

33 3. Konzept In dem vorherigen Kapitel wurden die technischen Grundlagen von Datenbanken genauer beschrieben. Auf diesen Grundlagen bauen die weiteren Kapitel dieser Arbeit auf. In diesem Kapitel wird ein Konzept vorgestellt, das ein hybrides DBMS beschreibt, welches sowohl für OLAP als auch für OLTP optimiert ist. Dies ist notwendig, um das beschriebene System später nach diesem Plan zu entwickeln. Im Einzelnen wird in diesem Kapitel als erstes der Ist-Zustand des Systems beschrieben, von dem wir ausgehen. Anschließend wird der Soll-Zustand beschrieben, also die Anforderungen die das System am Ende erfüllen soll. Danach werden Schritt für Schritt die einzelnen Änderungen dargestellt, um das iterative Vorgehen, das vom Anfangszustand in den Endzustand führt, für den Leser verständlicher zu machen. Allerdings ist das Konzept abstrakt gehalten und die konkreten Änderungen am Code von HSQLDB sind im Implementierungskapitel zu finden Ist-Zustand nach Implementierung eines Column- Stores Da bereits eine spaltenweise Speicherung auf der Grundlage von HSQLDB implementiert wurde, werden wir diesen Ansatz aufgreifen und fortsetzen. Die genauen Details seines Vorgehens sowie die konkreten Änderungen am Quellcode von HSQLDB, welches ein vollständig zeilenorientiertes DBMS und ein Open-Source Projekt ist, beschreibt Nguyen in seiner Bachelorarbeit [Ngu12]. Wir werden grob auf diese Änderungen eingehen, damit verständlich wird, wie genau der Ist-Zustand aussieht von dem wir ausgehen.

34 20 Konzept Nguyen hatte in seiner Bachelorarbeit zwar nicht das gleiche Ziel wie diese Arbeit, aber es ist trotzdem eine gute Grundlage für unser Vorhaben. Das Ziel von Nguyen war die Implementierung eines spaltenorientierten Datenbankmanagementsystems und unser Ziel ist die Implementierung eines hybriden DBMS, das je nach Art der Anfragen entweder auf Zeilen oder Spalten zugreift. Wie zuvor bereits erwähnt ist das originale HSQLDB ein zeilenorientiertes DBMS. Es speichert relationale Tabellen zeilenweise ab und liest sie auch zeilenweise wieder ein. Ebenfalls werden die Daten zeilenweise im Cache gehalten und auch zeilenweise verarbeitet. Also immer, wenn eine Anfrage an eine Tabelle gestellt wird, müssen komplette Zeilen verarbeitet werden, auch wenn nur wenige Spalten davon gebraucht werden. Sogar wenn nur ein einziges Attribut gebraucht wird, muss die ganze Zeile aus dem Cache oder von der Festplatte geladen werden. Um diesen Nachteil zu vermeiden, hat Nguyen begonnen einen Column-Store zu implementiert. Ein Column-Store speichert und verarbeitet seine Daten spaltenweise, was vor allem für OLAP-Systeme einen großen Vorteil bedeutet. Nguyen hat in seiner Implementierung allerdings nur die physische Speicherung modifiziert, so dass die Tabellen spaltenweise auf der Festplatte abgelegt werden. Die Verarbeitung der Daten, sowie auch Lesen und Schreiben der Daten, erfolgt somit immer noch Zeile für Zeile. Obwohl die Tabellen spaltenweise auf der Festplatte liegen (jede Spalte in einer eigenen Datei), hat sich an der Verarbeitung der Daten nicht geändert. Die Aufteilung der Zeilen in Spalten findet erst beim Speichervorgang statt, und in umgekehrter Richtung werden die Zeilen unmittelbar nach dem Lesen wieder zusammengefügt. Somit werden durch die Änderungen von Nguyen keine zeitlichen Verbesserungen bei der Anfrageverarbeitung erreicht. Dies zeigt auch der Benchmark aus [Ngu12], wonach die Antwortzeiten seiner Implementierung etwas langsamer sind als die der Originalversion. Trotzdem können wir diese Änderungen als Ausgangsbasis für das hybride DBMS verwenden. Denn auch bei unserer Implementierung soll die physische Speicherung der Tabellen spaltenweise erfolgen. Des Weiteren wird durch die Vorarbeit von Nguyen klar, an welcher Stelle im Programmcode wir für das weitere Vorhaben ansetzen können. Die Einordnung der Änderungen aus [Ngu12] in die Fünf-Schichten-Architektur wird in Abbildung 3.1 dargestellt.

35 Ist-Zustand nach Implementierung eines Column-Stores 21 Abbildung 3.1: Einordnung der Änderungen von Nguyen in die Fünf-Schichten-Architektur Wie in der oberen Abbildung zu sehen ist, hat sich durch die Änderungen Ä von Nguyen nichts am Zugriffssystem geändert. Somit ist auch die Anfrageverarbeitung immer noch dieselbe wie in der Originalversion. Im Folgenden wird die Anfrageverarbeitung grob beschrieben. Die genauenn Details finden sich bei der Beschreibung der Funktionsweisee von HSQLDB in Abschnitt 4.1. Nachdem eine Anfrage gestellt wurde, wird sie als erstes durch das Datensystem von der Mengenorientiertenn Schnittstellen auf die Satzorientierte Schnittstelle umgesetzt. Dabei analysiert das Datensystem die Anfrage und optimiert sie gegebenenfalls. Nachdem die Anfrage an das Zugriffssystem weitergeleitet wurde, wird überprüft ob es sich hierbei um eine einfachee Count-Anfrage handelt, wobei nur die Anzahl der Zeilen Z einerr Tabelle angefragt wird. Wenn das der Fall ist, wird das Ergebnis sofort zurückgegeben, weil die Größen der Tabellen bereits bekannt sind. Ist dass aber nicht der Fall, muss diee gesamte Tabelle durchgegangen werden, um die Anfragee zu verarbeiten. Dabei wird immer eine Zeile der Tabelle geholt und anschließend überprüft, ob die Elemente der d Zeile den Bedingungen der Anfrage entsprechen. Ist das nicht der Fall, wird sofort die nächste Zeile geholt und überprüft. Andererseits wird das Zeilen-Objekt verarbeitet, wobei z.b. die benötigten Attribute extrahiert

36 22 Konzept und dem Ergebnis hinzugefügt werden oder die angefragten n Attribute aggregiert werden. Nachdem eine Zeile verarbeitet wurde, wird die nächste Zeile geholt. Das geschiehtt solange bis alle Zeilen der Tabelle durchgegangen und überprüft wurden. Anschießend werden ggf. noch letzte Bearbeitungsschritte am Ergebnis vorgenommen, wie z.b. das Hinzufügen der berechneten Aggregate oder die Sortierung des Ergebnisses. Nachdem auchh das geschehen ist, wird das Ergebnis ausgegeben. Falls mehrere Tabellen angefragt werden, also JOIN- Operationen durchzuführen sind, werden die Tabellen in einer geschachtelten Schleife durchgegangen. Dabei wird wiederum überprüft, ob die Bedingungen erfüllt sind und ob die Zeilen unterschiedlicher Tabellen verbunden werden sollen. Somit setzt sich das zu Verarbeitende Zeilen-Objekt in diesem Fall aus mehreren Zeilen zusammen. Im Anschluss wird die Anfrage wie zuvorr abgearbeitet. Abbildung 3.2 zeigt eine grobe Übersicht der Anfrageverarbeitung, wobei aber übersichtshalber nur eine einfache Schleife und keine geschachtelte Schleife gezeigtt wird. Abbildung 3.2: Grobe Übersicht der Anfrageverarbeitung in HSQLDB

37 Anforderungen an das hybride DBMS Anforderungen an das hybride DBMS Um ein System zu entwickeln, müssen als erstes die Anforderungen festgelegt werden, die das System am Ende erfüllen muss und worauf das ganze Konzept aufbaut. Diese Anforderungen werden im Folgenden beschrieben. Im Rahmen dieser Masterarbeit soll ein hybrides Datenbankmanagementsystem entwickelt werden, das sowohl die Vorteile der zeilenweisen Speicherung als auch die der spaltenweisen Speicherung ausnutzt. Wie zuvor im Grundlagenkapitel gezeigt wurde, eignen sich Row- Stores besser für OLTP-Anfragen und Column-Stores besser für OLAP-Anfragen. Da heutzutage der Trend in die Richtung geht, dass einfache DBMS, die früher nur für die OLTP- Verarbeitung eingesetzt wurden, immer weiter in den analytischen Bereich vordringen [GG00, Gro03], ist ein hybrides DBMS genau der richtige Ansatz, um die OLAP- Verarbeitung zu beschleunigen. Des Weiteren liegen Data Warehouses und OLAP schon lange im Trend [BG09, BS97, KMU04]. Allerdings können sich kleine Unternehmen nicht immer ein zusätzliches Data Warehouse leisten. Mit dem hybriden DBMS hätten sie also eine gute Möglichkeit sowohl die Analysen als auch sonstige OLTP-Verarbeitung auf einem einzigen Datenbanksystem ausführen. Das hybride DBMS wird als Erweiterung des bestehenden Datenbanksystems HSQLDB (siehe 4.1 Funktionsweise HSQLDB bzw. [Hyp12] oder [ST12]) implementiert. Dabei wird die OLTP-Funktionalität beibehalten, aber zusätzlich werden die Vorteile des Column-Stores für OLAP-Anfragen ausgenutzt. Das zu entwickelnde DBMS soll nach dem Laden die Daten sowohl in Zeilenform als auch in Spaltenform im Speicher halten und je nach Anfragetyp entweder auf Zeilen oder Spalten zugreifen. Genauer gesagt sollen analytische Anfragen, also alle Anfragen, die Aggregate enthalten, auf Spalten arbeiten und alle anderen Anfragen sollen nach wie vor die Zeilen benutzen. Dadurch sollen die analytischen Anfragen, die normalerweise länger dauern als sonstige OLTP-Anfragen, beschleunigt werden. Dies soll später im Kapitel 5 genauer getestet und evaluiert werden. Somit wird das Zugriffssystem der Fünf-Schichten-Architektur oder genauer gesagt der Query Executor verändert, also der Teil des DBMS der die Anfragen verarbeitet. Zusätzlich werden auch Änderungen an dem Speichersystem vorgenommen, so dass die Spalten nicht mehr zeilenweise sondern chunkweise, also in Stücken von z.b. 100 Werten, eingelesen werden. Die Abbildung 3.3 zeigt die Einordnung der genannten Modifikationen in die Fünf-Schichten-Architektur.