Neue Datenbanken für BI - wie gut sind sie?

White Paper

In letzter Zeit tauchen bemerkenswert viele neue Datenbanksys-teme am Markt auf, was vor allem auf die Verfügbarkeit billiger 64-Bit Systeme mit grossem RAM zurückzuführen sein dürfte. Ein praxisorientierter Test zeigt, wie gut sie im Vergleich zu bekannten Systemen wie Oracle oder Mysql abschneiden.

Abstract

Die Dinosaurier bekommen Konkurrenz Seit geraumer Zeit teilen sich IBM, Oracle und Microsoft den Markt für Datenbanksysteme (genauer: Database Manage-ment Systems = DBMS) praktisch ohne ernstzunehmende Konkurrenz. Dies trifft sowohl auf Data Warehouses als auch auf Transaktionssysteme zu, wobei in beiden Bereichen typischerweise die gleiche Technologie zum Einsatz kommt, nämlich zeilenbasierte relationale Systeme mit optimiertem Plattenzugriff.

Auch Teradata, ein DBMS das vor allem bei Anwendungen mit sehr grossen Datenmengen einen wesentlichen Marktan-teil hat, fällt in diese Kategorie. Alle diese Systeme sind mehrere Jahrzehnte alt.

In den letzten Jahren drängten vermehrt neue Ansätze auf den Markt, welche die erst jetzt verfügbaren riesigen Haupt-speicher optimal ausnutzen (siehe [1]). Ausserdem versuchen manche davon, durch Spezialisierung auf ent-weder Data Warehousing oder Transaktionsverarbeitung weitere Performance-Verbesserungen zu erzielen.

Im Bereich Business Intelligence — grob gesprochen jede Art Berichte, die mit aggregierten Zahlen und Konsolidierung zu tun haben — hat man praktisch immer ein Data Warehouse als Basis. Dies ist auch der Bereich, wo die meisten neuen Player zu finden sind, sowohl kommerziell als auch unter diversen Open Source oder Shareware Lizenzen. Einige der prominentesten neuen Player sind, ohne Anspruch auf Voll-ständigkeit, in alphabetischer Reihenfolge:

Exasol:Eine kommerzielle Lösung, die bisher vor allem in Deutsch-land im Einsatz ist. Die technischen Schlagworte sind wie bei MonetDB Spaltenorientierung und In-Memory Verarbeitung, sowie einfache Wartung und Administration. Exasol wird auf 64 Bit Intel Standard-Hardware installiert, mit einem proprie-tären Betriebssystem. Entwickelt in Nürnberg in Deutsch-land. Bekannt als Sieger im TPC-H Benchmark in den Kategorien 100 GB, 300 GB und 3000 GB (siehe [2]).

LucidDB: Laut eigenen Angaben das erste und einzige Open Source Datenbanksystem, das speziell für Data Warehousing und Business Intelligence Zwecke entworfen wurde. Technische Stichwörter sind unter anderem Spaltenorientierung und Bit-map Indexing. Entwickelt von LucidEra in Kalifornien.

MonetDB:Ein Open Source Datenbanksystem für High-Performance Anwendungen für Data Mining, OLAP, GIS, XML Query, Text und Multimedia-Anwendungen. Technische Stichwörter sind Spaltenorientierung und In-Memory Verarbeitung. Entwickelt am CWI in den Niederlanden. Eine bekannte Publikation ist [3].

Netezza:Kommerziell, mit eigener Hardware. Schlagwörter sind ‚Field Programmable Gate Array‘, ‚Processing at Disk Level‘ und ‚Fast Full Table Scans‘. Die Firma ist in Massachusetts, USA ansässig und hat in den USA bereits eine Vielzahl prominen-ter Kunden.

Vertica:Kommerziell, mit de facto den gleichen Merkmalen wie Exasol: Spaltenorientierung, In-Memory Verarbeitung, Standard-Hardware, spezialisiert auf Data Warehousing. Interessant ist hier, dass Virtualisierung mit VMWare aus-drücklich unterstützt wird, was für High-Performance Anwendungen sehr ungewöhnlich erscheint. Vor allem in den USA präsent. Wie Netezza in Massachusetts, USA ansässig.

Um mit den Tests im Rahmen zu bleiben, muss man hier eine Vorauswahl treffen. Da es naturgemäss schwierig ist, Tests auf Netezza durchzuführen, weil man Zugang zu spezieller Netezza-Hardware benötigt, und weil Vertica in Europa weitgehend unbekannt ist, beschränkten sich die Tests auf LucidDB, MonetDB und Exasol. Als Vergleichssysteme werden Oracle, MS SQL Server und MySQL herangezogen.

Ein Performance-Benchmark aus der Praxis Es war einmal eine Firma, die wollte ihren Managern ein Performance-Cockpit anbieten, wo jeder Verantwortliche den summierten Umsatz aller seiner Mitarbeiter sieht. Und das natürlich pro Monat und aufgeschlüsselt nach Kunden-gruppe und nach mehreren anderen Dimensionen, deren genaue Definition hier keine Rolle spielt. Daraus folgt, dass es pro Manager eine eigene Query geben muss, die genau seine Mitarbeiter betrachtet, und sonst keine.

Wenn die Firma gross ist, und sie hat hunderte Manager, dann müssen täglich mehrere hundert Queries laufen. Pikan-terweise werden diese Abfragen langsamer, je höher die Po-sition des Abnehmers ist, da es mehr Zahlen zu summieren gilt. Am längsten wartet der CEO.

Leider ist diese Geschichte kein Märchen. In der Tat kommen solche Situationen so oft vor, dass es sich lohnt, einen Benchmark zu entwerfen, der das Problem mit syntheti-schen, generierten Daten nachbildet.

Figure 1: Synthetisch erzeugtes Datenmodell

Man sieht auf der linke Seite die Tabelle dim_org, die den Organisationsbaum der Firma enthält, in einer ParentChild Struktur. Wer schon einmal mit dem Schema scott gearbeitet hat, das in jeder Oracle-Installation vorhanden ist, kennt so etwas aus der Tabelle scott.emp, wo die Spalte mgr auf den jeweilgen Chef verweist.Rechts davon ist die Tabelle dim_org_flat, die zu jedem

White Paper Neue Datenbanken für BI

Manager alle Mitarbeiter enthält, die für ihn arbeiten. Durch einen Join zur Fakttabelle t_facts, welche die Zahlen pro Mitarbeiter und Transaktion enthält, kann man die gewünsch-ten Summen als in sich geschlossenes SQL-Statement hinschreiben. Summen entlang solcher Hierarchien zu bilden ist mit SQL normalerweise keine einfache Angelegenheit. Häufig werden Schleifen programmiert, die mit Hilfe eines Cursors durch den Baum navigieren, was zwangsläufig zu vielen kleinen Queries und unakzeptabler Performance führt.

Ein weiterer Nachteil dieses Ansatzes ist, dass man derarti-gen Code auf keinen Fall von BI-Tools erzeugen lassen kann. Durch die Bridge-Tabelle dim_org_flat wird das Problem jedoch so elegant vereinfacht, dass sogar automatisch erzeugtes SQL aus Reporting-Werkzeugen die Konsolidie-rungsaufgabe lösen kann.

Rechts von der Fakttabelle sind die Dimensionstabellen angeordnet, die Zusatzinformation zu den Gruppierungskri-terien enthalten, also z.B. dim_client.id = 4711 => client_name = Meier. Man könnte theoretisch all diese Spalten direkt in die Fakttabelle mit aufnehmen, was aber zu einer gigantischen Aufblähung der Datenmenge durch endlose Wiederholungen der Zusatzinformation führen würde.

Die Testquery zur Bestimmung der Summe über alle Mitar-beiter, gruppiert nach allen Dimensionen, sieht folgender-massen aus:

Wie man schon an den phantasielosen Aliasen für die Tabellen erkennen kann, ist dies eine von einem Business-Intelligence Werkzeug automtisch erzeugte Abfrage. Damit wird nebenbei mitgetestet, ob ein DBMS das erzeugte SQL unverändert akzeptiert, oder ob noch Anpassungen gemacht werden müssen.

Das count(*) wurde von Hand hinzugefügt, damit die Übertra-gungszeit für Daten nicht das Messergebniss für die Abfrage-dauer verzerrt. Ausserdem ist das ganze in einem with-State-ment verpackt, weil man nur dann gut lesbares SQL schreiben kann, wenn diese Syntax unterstützt wird.

Wie weiter oben schon bemerkt, ist die Komplexität der Abfrage abhängig von der Position des Managers in der Firmenhierarchie. In der Query ist dies in der Zeile AL2.ID= $member_org zu sehen, wo $member_org die Werte 0,23 und 7717 annimmt, je nachdem, ob man es mit dem CEO (0), einem mittleren Manager (23), oder jemandem ganz unten zu tun hat, der selbst arbeiten muss (7717).

Die andere einfache Möglichkeit, an der Laufzeit zu drehen, liegt in der Grösse der Fakttabelle. Hier entspricht eine Grösse von 80 Spalten und 16 Mio Zeilen der realen Situation im Projekt. Wenn damit nur kurze Laufzeiten auftreten und alles stabil ist, kann man sukzessive grössere Fakttabellen erzeugen lassen.

Das Datenvolumen mit 16 Mio Rows ist erstaunlich gering, bei unter 7 Gigabyte. Man möchte meinen, dass ein bewähr-tes DBMS mit solchen Trivialitäten keine Schwierigkeiten hat,

White Paper Neue Datenbanken für BI

with t as (

SELECT

AL2.ID,

SUM ( AL1.FACT_1 ) fact_1,

SUM ( AL1.FACT_2 ) fact_2,

SUM ( AL1.FACT_3 ) fact_3,

AL9.TIME01,

AL6.CLIENT_T_01,

AL8.PRODUCT_T_01,

AL11.UNIT_T_01,

AL4.ACCOUNTING_T_01,

AL5.BUSINESSTYPE_T_01,

AL7.MEASURE_T_01,

AL10.TRANS_T_01

FROM

T_FACTS AL1,

DIM_ORG AL2,

DIM_ORG_FLAT AL3,

DIM_ACCOUNTING AL4,

DIM_BUSINESSTYPE AL5,

DIM_CLIENT AL6,

DIM_MEASURE AL7,

DIM_PRODUCT AL8,

DIM_TIME AL9,

DIM_TRANS AL10,

DIM_UNIT AL11

WHERE

(AL3.ID=AL1.DIM_ORG

AND AL2.ID=AL3.PARENT

AND AL1.DIM_TIME=AL9.ID

AND AL1.DIM_CLIENT=AL6.ID

AND AL1.DIM_PRODUCT=AL8.ID

AND AL1.DIM_UNIT=AL11.ID

AND AL1.DIM_ACCOUNTING=AL4.ID

AND AL1.DIM_BUSINESSTYPE=AL5.ID

AND AL1.DIM_MEASURE=AL7.ID

AND AL1.DIM_TRANS=AL10.ID)

AND (AL2.ID= $member_org)

GROUP BY

AL2.ID,

AL9.TIME01,

AL6.CLIENT_T_01,

AL8.PRODUCT_T_01,

AL11.UNIT_T_01,

AL4.ACCOUNTING_T_01,

AL5.BUSINESSTYPE_T_01,

AL7.MEASURE_T_01,

AL10.TRANS_T_01

)

select count(*) from t ;

aber weit gefehlt. Eine typische Laufzeit dieses Tests liegt bei ca 20 Minuten. Das bedeutet, dass schon bei 30 wichtigen Managern das Abarbeiten der Queries nicht mehr innerhalb einer Nacht möglich ist!

Bezeichnung mem

ber

_org

Ag

gre

gie

rte

Zei

len

in

der

Fak

t-Ta

bel

le

Ag

gre

gie

rte

Z

eile

n in

Pro

zen

t

An

zah

l Zei

len

im

Res

ult

at

Assistent 7717 3700 0.02 20

Abteilungsleiter 23 1 Mio 6.25 5800

CEO 0 16 Mio 100 90000

Einfluss der Hardware Man würde vermuten, dass neben dem verwendeten DBMS selbst auch der Hardware wesentliche Bedeutung zukommt, auf der es installiert ist. Angesichts der Tatsache, dass das Test-Datenset unter 7 GB gross ist, sollte man auch einen starken Einfluss der RAM-Grösse erwarten.

Wenn mehr RAM zur Verfügung steht, als es Daten gibt, könnte theoretisch jedes System ohne Kompression oder Tricks alles in den Hauptspeicher holen.

Die Testplattformen sind: • Produktionsplattform:

IBM 9117-570 mit 8 GB RAM 4 CPUS 1.9 GHz AIX mit Oracle 10G

• Heim-PC mit Oracle: Dell Dimension E521 4 GB RAM CPU 2.2 GHz Windows 2003 Server mit Oracle 10G

• Heim-PC mit MS-SQL Server: Dell Dimension E521 4 GB RAM CPU 2.2 GHz Windows 2003 Server MS SQL Server 2005

• Linux-Server mit zu wenig RAM und Oracle: HP DL380 Proliant 0.5 GB RAM CPU 3.2 GHz Red Hat Linux

• Exasol Testserver: 2 Quad Core Intel CPUs, 32 GB RAM, 2 Server, Linux Microkernel

Die Resultate (Abfragezeit in Sekunden) sind doch einiger-massen bemerkenswert:

Plattform CE

O

Ab

teilu

ng

slei

ter

Ass

iste

nt

Produktionsplattform (PO) 1200 168 167

Heim-PC mit Oracle (HO) 1023 205 159

Heim-PC mit MS-SQL Server (HS)

741 699 293

Linux-Server mit zu wenig RAM und Oracle (LO)

1432 413 386

Die grosse Überraschung ist, dass alle Systeme so etwa in der gleichen Grössenordnung liegen. Lediglich der Linux-Server mit dem RAM-Handicap hat etwas Probleme, aber bei Licht betrachtet sind 24 Minuten (1423 sec) für den CEO-Testfall anstatt der 20 Minuten mit dem Produktionsserver auch kein qualitativer Unterschied.

Microsoft SQL Server fällt positiv auf und ist auf dem Heim-PC etwas schneller als Oracle, und das ist immerhin schon zweimal so schnell wie Oracle auf der Produktionsplatform. Allerdings ist dieser Vergleich mit Vorsicht zu geniessen, weil man auf einer Produktionsmaschine nie sicher sein kann, dass man sie wirklich für sich alleine hat. Der Test wurde daher mehrfach zu verschiedenen Tageszeiten wiederholt, allerdings ohne bemerkenswerte Schwankungen im Ergeb-nis.

Figure 2: CEO-Szenario auf verschiedenen Plattformen

White Paper Neue Datenbanken für BI

White Paper Neue Datenbanken für BI

Um es griffig zu formulieren: Ein moderner PC ist schneller als man denkt, und SQL Server auf einer WindowsPlattform läuft gut.

Allerdings scheint diese harmlos aussehende Standardquery jedes Standard-DBMS so zu überfordern, dass es keinen wesentlichen Unterschied macht, ob man 4 CPUS hat oder nur eine, und ob man 8 GB RAM hat oder nur ein halbes.

Datenbank-Tuning, oder Herkules und die HydraAn dieser Stelle werden Leser mit DB-Erfahrung fragen, wo denn die Indexe gesetzt waren, mit welchen Optionen das Kommando zum Sammeln der Tabellen-Statistiken abge-setzt wurde und wie die Tabellen partitioniert waren. Ein Oracle-Guru wird anmerken, dass durch das Setzen geeig-neter Hints in der Abfrage die Performance bisweilen um einen Faktor 10 verbessert werden kann, und so weiter und so fort.

Tatsache ist, dass all diese Fragen berechtigt sind. Gleichzei-tig sind sie wenig hilfreich. Business Intelligence bedeutet vor allem, dass Queries automatisch erzeugt werden und so laufen müssen, wie sie aus dem SQLGenerator kommen. Die Endanwender erzeugen ständig wechselndes SQL, ohne überhaupt zu wissen, welche Tabellen daran beteiligt sind. Die Option, von Hand am SQL-Code zu drehen, gibt es nicht.

Am konkreten Beispiel der Testquery hat sich gezeigt, dass Indexe auf der Fakt-Tabelle immer schaden, und zwar unab-hängig davon, welches DBMS eingesetzt wird. Generell verdoppeln sich die Laufzeiten für den CEO-Fall, wenn man die Ratschläge aus der Literatur beherzigt und auf der Fakt-tabelle einen Index pro Dimensionstabelle anlegt. Bedeutet dies, dass z.B. Ralph Kimball in [4] nicht weiss, wovon er spricht ? Nein.

Es bedeutet nur, dass die Indexe schaden, wenn man über die ganze Tabelle aggregiert, weil dann ein Full Table Scan effizienter ist. Und genau das ist es, was im CEO-Testcase geschieht. Die Optimizer sind generell nicht in der Lage, dies zu erkennen und wenden die Indexe an, auch wenn dies völlig sinnlos ist und die Performance nach unten zieht.

Also löscht man die Indexe, damit die CEO-Query schnell wird, aber ein Dutzend andere Abfragen, die nur wenige Rows aus der Fakttabelle selektieren, werden dafür langsa-mer. Dieses Spiel kann auf die Dauer sehr frustrierend sein, sowohl für den DB-Admin als auch für die Anwender, deren Query-Laufzeiten total unvorhersehbar werden.

Ein guter DB-Admin kann hier einen gewaltigen Unterschied machen. Er beherrscht als einziger die schwarze Kunst der Optimierung, und kann durch geschicktes Editieren einer Konfigurationsdatei Laufzeiten um Grössenordnungen verbessern. Das Problem ist, solche Leute zu finden oder überhaupt zu erkennen.

Verschiedene Systeme auf vergleichbarer Hardware Wenn man eine Evaluation verschiedener DB-Systeme durchführt, sollte die zugrundeliegende Hardware zumindest vergleichbar sein. Die nächste Testreihe verwendet daher ein und denselben Server für jedes DBMS. Eine Ausnahme bil-det Exasol, das auf seinem eigenen Testserver lief, der aber von der Ausstattung her vergleichbar ist.

Neben der reinen Performance kommen dabei auch die Aspekte Installation, Konfiguration und Stabilität zum Tragen. Insbesondere ist von Interesse, ob an der SQLSyntax der Testquery Veränderungen notwendig sind, um sie auf einem DBMS lauffähig zu machen.

ÜberblickDer Testserver hate als CPU einen Intel Dual-Xeon E5205, dazu 16 GB RAM und zwei mal 250 GB Festplatte. Als Be-triebssystem kam ein 64 Bit Debian Linux zum Einsatz.Für Oracle und LucidDB stellt die Abbildung die langsameren Laufzeiten mit Indexen und die schnelleren ohne Indexe in einem Balken dar. Der rote Teil ist dabei der Performancege-winn durch Weglassen der Indexe.

Bei MonetDB stellt der rote Teil den Performancegewinn durch den Bugfix im Optimizer dar.

Figure 3: CEO-Szenario mit verschiedenen DBMS

Im folgenden werden die Erfahrungen beim Test der verschiedenen DBMS einzeln diskutiert.

Oracle 11Debian Linux wird von Oracle offiziell nicht unterstützt, und 64 Bit Debian erst recht nicht. Allerdings gibt es eine Linux-Distribution für Red Hat Linux, die man für Evaluations- zwecke kostenfrei auf der Oracle-Webseite herunterladen kann.

Ausserdem findet man mit Google recht schnell Hinweise, was bei einer Installation auf Debian alles schief geht, und was man dagegen unternehmen muss. Dennoch dauert es circa ein Wochenende, bis so eine Installation gelingt.

Zum Beispiel benötigt man zwingend eine graphische Ober-

fläche wie KDE, erstens weil man das Installationspaket mit einem textbasierten Browser nicht herunterladen kann, und weil zweitens der Installationsassistent keine Kommandozei-lenunterstützung bietet. Remote mit putty ist hier also nichts zu machen. Erschwerend kommt hinzu, dass die unzip Utility in der 64-Bit Oracle Distribution ein 32-Bit Binary ist und des-wegen einfach nicht funktioniert.

Die Pfade zu einigen Bibliotheken sind verkehrt, und manche Teile des Installationsprozesses benötigen dann doch wieder 32-Bit Shared Libraries, für die erstmal die 64-Bit Versionen versucht werden, was zu obskuren Fehlermeldungen führt.

Damit Oracle den mächtigen Server auch richtig ausnutzen kann, gilt es anschliessend noch, diverse Kernel-Parameter in /etc/sysctl.conf anzupassen.

Hat man das alles hinter sich, läuft Oracle reibungslos und ohne Einschränkungen, und der Performancegewinn gegen-über einem 32-Bit System ist mit einem Faktor 4 sehr beachtlich.

Der Effekt, dass Indexe auf der Fakt-Tabelle die Performance halbieren, bleibt. Wir geben deshalb zwei Zahlen in der Er-gebnistabelle an, einmal mit Indexen, und einmal ohne. Der Grund ist, dass wir von einem Szenario mit automatisch ge-neriertem SQL ausgehen, wo das Ausschalten von Indexen durch manuelles Einfügen eines Hints nicht in Frage kommt.

Man kann auch nicht unbedingt erwarten, dass jemand auf Verdacht alle Indexe löscht, um herauszufinden, ob das viel-leicht die Performance bei manchen Queries verbessert, während die meisten anderen langsamer werden.

MySQLFür MySQL gibt es ein fertiges APT-Package, welches man mit einem Einzeiler

apt-get install mysql-server

herunterladen und installieren kann. Es funktioniert sofort. Die Performance ist jedoch entäuschend. Für den CEOTest-case braucht Mysql 38 min, was ungefähr 10 mal langsamer ist als Oracle 11. Im Abteilungsleiter-Fall verliert man sogar einen Faktor 50, was in anschaulich gesprochen 10 Minuten statt 10 Sekunden bedeutet

Inwiefern hier Optimierungspotential vorhanden ist, sei da-hingestellt. Die Kernel-Parameter waren bereits vorher für Oracle nach oben gesetzt worden, am Shared Memory oder dergleichen liegt es also sicher nicht. MySQL selbst hat über 200 weitere interne Parameter, deren aktuellen Wert man mit show variables anzeigen lassen kann.

Eine Suche mit Google deutet darauf hin, dass key_buffer_

size ein heisser Kandidat für Optimierungen ist. Eine Erhö-hung dieses Parameters von 8 MB auf 4 GB änderte jedoch schlichtweg gar nichts an den Laufzeiten.

LucidDBLucidDB tritt mit dem Anspruch an, bei minimaler Wartung und Konfiguration schnelle Antwortzeiten bei komplexen analytischen Abfragen zu liefern.

Die Installation verläuft reibungslos. Zwar gibt es kein De-bian-Package, aber Herunterladen, unzippen und einmal kurz # ./install.sh und# ./lucidDbServer

eintippen, und der Server läuft.

Wie bei MySQL sind die Antwortzeiten aber zunächst schlecht, vor allem im CEO-Fall, wo es 1 Stunde und 24 Mi-nuten dauert, bis ein Ergebnis geliefert wird.

Eine Suche im Netz legt nahe, die Lucid-Parameter cache-PagesMax und cachePagesInit zu erhöhen, die anfänglich auf jeweils 5000 Pages zu 32 KB gesetzt sind.

Nach

alter system set „cachePagesMax“ = 1000000;

und

alter system set „cachePagesInit“ = 100000; verkürzt sich die Laufzeit auf akzeptable 460 Sekunden. Das ist eine Verbesserung um einen Faktor 10, nur durch korrek-tes Setzen eines DB-Parameters. Es ist vorstellbar, dass einer von den 200 MySQL-Parametern auch zu einer derarti-gen Verbesserung geführt hätte, aber dazu müsste man erst einmal herausfinden, welcher. Wie üblich verdoppelt auch bei LuciddDB das Anlegen von Indexen auf der Fakttabelle die Laufzeit im CEOTestcase. Offenbar haben alle Datenbanksysteme den gleichen blinden Fleck im Optimizer. MonetDB MonetDB ist das Resultat von Forschungsarbeiten am CWI (Centrum Wiskunde & Informatica) in den Niederlanden. Das aktuelle Interesse an spaltenbasierten Datenbanken, die Plattenzugriffe weitgehend vermeiden, sowie eine Veröffentli-chung über MonetDB in CACM (Communications of the ACM) haben diesem Datenbanksystem zu einiger Bekannt-heit verholfen.

Damit ist auch schon klar, wo sich MonetDB positioniert: An forderster Front, wo neue Ideen erstmalig in der Praxis er-

White Paper Neue Datenbanken für BI

probt werden. Entsprechend häufig ändert sich etwas an der Implementierung. Wer mit MonetDB arbeiten will, muss die Bereitschaft mitbringen, direkten Kontakt mit den Entwick-lern zu pflegen und bei Bedarf auch regelmässig die neueste Version aus dem CVSRepository zu holen.

Die Installation auf Debian gestaltet sich einfach, weil vom CWI ein vorkompiliertes Debian-Package bereitgestellt wird, das sich wie auf Debian üblich mit apt-get... installieren lässt.

Der Bedienung von MonetDB merkt man deutlich an, dass es sich um ein Experimentalsystem handelt. So ist zum Bei-spiel das Erstellen einer neuen Datenbank nur durch einen Start des DB-Servers mit bestimmten Kommandozeilen-Pa-rametern möglich.

Ein DDL-Statement zum Erstellen einer DB gibt es nicht. Merkwürdig ist auch, dass man eine Liste der Tabellen mit \d (backslash d) bekommt, und dass man die interaktive Ses-sion nicht mit quit oder exit verlässt, sondern mit \q. Möchte man herausfinden, wieviele Datenbanken man angelegt hat, und wie sie heissen, bleibt nur der Umweg über das Filesys-tem, wo für jede DB ein Folder existiert.

An der Testquery mussten leichte Anpassungen durchge-führt werden, um sie durch den SQL-Parser zu bekommen. Die Änderungen waren zwar trivial, aber dennoch kann man im allgemeinen nicht damit rechnen, dass automatisch gene-riertes SQL akzeptiert wird.

Die gemessene Antwortzeit war im CEO Case bei ca 200 Sekunden, was ziemlich genau der Performance von Oracle entspricht. Interessanterweise scheint MonetDB eine Art ‚Warmlaufphase‘ zu benötigen, was sich darin äussert, dass Wiederholungen der Abfrage immer schneller werden. Die-sen Effekt haben andere Systeme auch, aber normalerweise stellt sich dort nach der ersten Wiederholung keine weitere Verbesserung mehr ein.

Seltsam ist auch, dass zwar der CEO-Case geringfügig schneller als Oracle war, die ‚Assisstent‘- und ‚Abteilungs-leiter‘-Abfragen aber noch langsamer waren, wohl weil sie zuerst ausgeführt wurden.

Das Entwickler-Team am CWI war extrem hilfsbereit und er-klärte sich bereit, den Testfall selbst nachzuvollziehen und die Performance zu untersuchen. Dabei wurde ein Bug im Opti-mizer entdeckt und behoben. Anschliessend wurde der Benchmark am CWI wiederholt, auf einem Intel Quad Core Server mit 8GB RAM und Fedora-Linux 10.

Die berichteten Zahlen sind:

White Paper Neue Datenbanken für BI

Bezeichnung

Dau

er (k

alt)

in m

s

Dau

er (w

arm

) in

ms

Assistent 10‘815 371

Abteilungsleiter 5‘496 2‘148

CEO 30‘982 30‘730

Um sie nachzuvollziehen, wäre ein Herunterladen und Kom-pilieren des neuesten Quellcodes notwendig gewesen, was uns ein wenig zu aufwendig war. Vielleicht wird der Bugfix ja Teil der nächsten stabilen Release, und dann kann man es noch einmal versuchen.

Leser mit Spieltrieb und technischem Interesse sind herzlich eingeladen, es selbst zu probieren. Die Autoren würden sich über jedes Feedback freuen!

ExasolDa Exasol sein eigenes, auf einem Linux-Kernel basierendes Betriebssystem einsetzt, war es nicht möglich, einen direkten Vergleich auf dem Debian-Server durchzuführen.Der von Exasol zur Verfügung gestellte Testserver verwendet eine Quad-Core CPU anstatt eines Dual-Core Prozessors, und das RAM ist mit 32 GB zweimal so gross.

Da aber 16 GB bereits komplett überdimensioniert für den Benchmark mit 7GB Daten waren, macht die Hauptspeicher-grösse wohl keinen Unterschied. Ob der QuadCore im Ver-gleich zum Dual Core eine wesentliche Verbesserung bringt, und wenn ja wieviel, lässt sich nicht ohne weiteres beurteilen. Dies würde stark davon abhängen, inwieweit der Benchmark vom DBMS parallelisiert wird. Falls der Optimizer das nicht hinbekommt, gäbe es keinen Unterschied. Das ist aber reine Spekulation und würde weitere Versuche erfordern.

Tatsache ist, dass auf dem Exasol-Testsystem auf Anhieb al-les perfekt funktioniert hat, und dass es auf preiswerter Stan-dardhardware läuft. Das vom Tool generierte SQL lief ohne Anpassungen und mit konstanten Laufzeiten, egal ob im ers-ten, zweiten, oder dritten Versuch.

Der Effekt mit den Indexen auf der Fakt-Tabelle erledigt sich von selbst, weil es gar kein CREATE INDEXStatement gibt. Indexe werden intern erzeugt und sind damit komplett un-sichtbar.

Wenn man den täglichen Umgang mit Datenbanksystemen gewohnt ist, fühlt man sich ein wenig verloren, wenn es keine Parameter gibt, an denen man zwecks Optimierung drehen

© D1 Solutions AGZypressenstrasse 71, Postfach, 8040 Zürich, Switzerlandwww.d1-solutions.com, info@d1-solutions.com T +41 44 435 10 10, F +41 44 435 10 15

kann. Nicht einmal das Sammeln der Tabellen-Statistiken kann man vergessen, weil auch das intern automatisch geschieht.

Eine Antwortzeit war nur im CEO-Fall überhaupt wahrnehm-bar, mit sehr erfreulichen 20 Sekunden. Je nachdem, ob man die Indexe auf Oracle ausschaltet, oder nicht, bedeutet das eine Beschleunigung um einen Faktor 10 oder 20.

Offenbar ist der Benchmark unterdimensioniert, und man kann das Problem eigentlich als gelöst abhaken. Aber es wäre ja gelacht, wenn man durch Verzehnfachen der Daten-menge keine Performanceprobleme bekommen würde. Und wenn wir schon dabei sind, verdoppeln wir die Grösse der Fakt-Tabelle anschliessend noch einmal, auf das 20-fache.

Das Ergebnis ist, dass die Laufzeiten nahezu linear skalieren, d.h. eine Verzehnfachung der Zeilen in der Fakttabelle ver-zehnfacht auch die Laufzeit für die Testquery. Oder anders ausgedrückt: Wenn sich die Datenmenge verzehn- oder zwanzigfacht, kommt man bei der Performance an, die man heute mit einem herkömmlichen System hat.

Figure 4: Exasol: Lineare Skalierbarkeit

FazitBezahlen lohnt sich. Die kostenlos erhältlichen Systeme ha-ben alle Einschränkungen bei der SQL-Syntax und eventuell noch zusätzliche Probleme bei Performance oder Stabilität. LucidDB und MySQL unterstützen die with-Syntax nicht, und MonetDB erwartet vor einem Spalten-Alias immer ein as-Schlüsselwort, wie in SUM ( AL1.FACT_1 ) **as** fact_1, was von den meisten Tools einfach weggelassen wird. Bei MonetDB war ein Bugfix notwendig, damit der Optimizer mit der Abfrage zurechtkam, und bei MySQL ge-lang es nicht, einen Optimierungsparameter zu finden, der die Perfomance auf ein akzeptables Niveau gehoben hätte.

Lediglich LucidDB scheint eine echte Alternative zu sein, weil die Performance immerhin zu Oracle vergleichbar ist und In-stallation und Konfiguration sehr einfach sind. Bei dem Preis kann man sich eigentlich nicht beschweren.

Oracle 11 auf 64 Bit läuft rund.

Die Performance von Oracle 11 auf einer 64-Bit Plattform ist beachtlich. Man kann einen Faktor 4 an Performancegewinn gegenüber einem Oracle 10 auf einer 32-Bit Plattform erwar-ten. Man hat damit ein bewährtes AllroundSystem, das stabil läuft, und das so weit verbreitet ist, dass man mit Google zu praktisch jedem Problem eine Lösung findet.

Allerdings sind die Anforderungen an den DB-Admin hoch, weil die vielen Features auch zu einer schwer zu beherr-schenden Komplexität führen.

Dies gilt insbesondere bei der Performance-Optimierung, die inzwischen genug Stoff für einen eigenen Hochschulab-schluss bieten würde.

Die DBMS-Welt steht vor einem Umbruch Die Testergebnisse machen deutlich, dass mit RAMbasier-ten, spaltenorientierten Systemen wie Exasol oder MonetDB eine Performance-Steigerung um mindestens eine Grössen-ordnung stattgefunden hat.

Im Falle von Exasol zeigt sich auch, dass nicht nur die Perfor-mance stimmt, sondern dass dabei keine Abstriche hinsicht-lich Stabilität und Kompatibilität gemacht werden müssen.

Vielmehr fallen sogar viele komplexe Konfigurations- und Tuningaufgaben weg, weil sie intern automatisiert werden. Es ist zu diesem Zeitpunkt nicht verhersehbar, ob sich eines der neuen Systeme zum Marktführer entwickelt, oder ob die Technologie von einem der etablierten Big Player gekauft oder kopiert werden wird.

Sicher ist, dass in absehbarer Zukunft eine Revolution bei der Geschwindigkeit und beim Preis relationaler Datenbanksys-teme eintreten wird, die mit dem Preisverfall bei PCs und Flachbildschirmen vergleichbar sein wird. Wer jetzt in den Ausbau seines bestehenden alten Systems investiert, sollte von dem Geld lieber Bier kaufen. Wenn man das getrunken hat, kann man das Flaschenpfand kassieren und davon ein besseres System anschaffen.

White Ppaper Neue Datenbanken für BI

Literatur [1] Hasso Plattner: A common database approach for OLTP and OLAP using an in-memory column database. Procee-dings of the 35th SIGMOD international conference on Ma-nagement of data (2009)

[2] TPC-H benchmark results http://www.tpc.org/tpch/results/tpch_perf_results.asp

[3] P. A. Boncz, M. L. Kersten, S. Manegold: Breaking the Memory Wall in MonetDB.

Communications of the ACM, Vol. 51, No. 12 (Dezember 2008), S. 77-85

[4] Ralph Kimball and Margy Ross: The Data Warehouse Toolkit.

Second Edition, John Wiley & Sons, 2002

AutorDr. Andreas Hauenstein promovierte 1996 an der Universität Hamburg in Informatik. In seinen Forschungsarbeiten beschäftigte er sich mit automatischer Spracherken-nung. Seine Themenschwerpunkte sind Daten-Analyse & Statistik, Daten Architektur, hochperformante DB Systeme und Data Mi-ning. Er begleitet Projekte in den Branchen Finanzindustrie, Telecom und Energiewirt-schaft.

Kontakt /AnsprechpartnerSimon Hefti, Chairmansimon.hefti@d1-solutions.com, T +41 44 435 10 10

White Paper Neue Datenbanken für BI