Speicherbanken

ct.2213.184 187 27.09.13 10:55 Seite 184
Know-how | Datenbanken
Thomas Kalb, Jürgen Thomas, Peter Schüler
Speicherbanken
Server-Datenbanken setzen auf Hauptspeicher
Neue Datenbank-Server können auch Datenbestände von mehreren TByte
im RAM bearbeiten. IBM DB2 10.5 BLU und Microsoft SQL Server 2014
schaffen Analysen im Hauptspeicher blitzschnell wie in einem Data
Warehouse, wickeln aber Transaktionen gleichzeitig so sicher ab wie
eine festplattengestützte Datenbank.
B
is jetzt ist im Umgang mit großen Datenmengen in Unternehmen eine zweigleisige Arbeitsweise üblich: Für Transaktionen in
den Geschäftsdaten ist eine klassische OLTPDatenbank (Online Transaction Processing)
zuständig, die allerdings durch Festplattenzugriffe permanent ausgebremst wird. Um mit
Datenauswertungen schneller zum Zug zu
kommen, spiegelt man die sorgsam gepflegten Informationen regelmäßig in ein Data
Warehouse. Das ist eine gesonderte OLAPDatenbank (Online Analytical Processing), die
als Read-Only-System alle Tricks der schnellen
Datenanalytik im RAM beherrscht. Diese Strategie erfordert aber den gleichzeitigen Betrieb zweier Datenbanksysteme, und trotzdem liefern dabei auch die schnellsten Abfragen immer Ergebnisse, die schon seit Stunden überholt sein könnten.
Die 2011 erschienene Datenbank SAP
HANA bricht mit dieser Tradition [1]. Sie lagert auf Biegen und Brechen die kompletten
Geschäftsdaten eines Unternehmens komprimiert und großteils nach Spalten angeordnet im Hauptspeicher eines geräumigen
Servers. Dort analysiert und bearbeitet sie
die Daten ohne den Umweg über ein externes Speichermedium. So gehen Leseprozesse weit schneller über die Bühne als sonst.
Veränderungen am spaltenorientierten Datenbestand im RAM statt auf der Festplatte
verursachen dagegen so einen hohen Rechenaufwand, dass die Performance trotz
geballter CPU-Leistung auf das Niveau einer
konventionellen Datenbank absinkt.
Befürchtungen, die Transaktionsverarbeitung auf Basis RAM-residenter Daten könnte
etwa bei einem Stromausfall irreparable
Datenschäden verursachen, sind unangebracht. Alle In-Memory-Systeme dokumentieren Datenveränderungen in Log-Dateien
oder -Streams, die sehr wohl auf dauerhaften Massenspeicher geschrieben werden.
Nur haben diese Schreibvorgänge keinen
wesentlichen Einfluss auf die DatenbankPerformance.
Unterm Strich bleibt der Vorteil, dass die
operativen Daten immer in Echtzeit für Analysen zur Verfügung stehen, ohne dass man
regelmäßige ETL-Maßnahmen (Extraction,
Transformation, Loading) von einer Datenbank in eine andere einplanen müsste. Das
Konzept geht aber nur dann auf, wenn die
Schreiboperationen nur einen hinreichend
kleinen Anteil der Systembelastung ausmachen. Genau diese Voraussetzung stellen
SAPs Mitbewerber IBM und Microsoft infrage
und kontern mit eigenen Ansätzen, die
ebenfalls, aber weniger dogmatisch Gebrauch von In-Memory-Techniken machen.
Jürgen Thomas, Mitglied der MicrosoftSQL-Server-Entwicklungsabteilung und insbesondere zuständig fürs Zusammenspiel
zwischen der Datenbank und großen Unternehmensanwendungen, beschreibt die
Beschleunigungsmaßnahmen im SQL Server 2014. Im Anschluss erläutert Thomas
Kalb, IBM Information Champion, langjähriger Datenbank-Experte bei der Firma ITGAIN
und DB2-Alphatester, Konzepte und Fortschritte der BLU-Technik in IBMs jüngster Datenbank DB2 10.5.
Fast fertig: MS SQL Server 2014
Microsoft hat im Juni den ersten öffentlichen
Preview (CTP1) des fürs kommende Frühjahr
angekündigten SQL Server 2014 herausgebracht. Die Engine hebt sich vom SQL Server 2012 unter anderem durch ganz neue
Strukturen zur Datenbearbeitung im RAM
und durch erweiterte Fähigkeiten im Umgang mit spaltenorientierten Daten ab.
Um analytische und schreibende Aktionen
in Rechnern mit viel Hauptspeicher zu beschleunigen, haben die Entwickler mit der InMemory-optimierten Tabelle ein neues Speicherformat kreiert. Tabellen dieses Typs sind
wie in operativen Datenbanken üblich zeilenweise organisiert, orientieren sich aber
nicht an herkömmlichen Speicherseiten des
Servers. Diese neuen Tabellen bewahrt der
Rechner standardmäßig im RAM auf, ohne
die Daten nach jeder Veränderung sofort auf
die Festplatte zurückzuschreiben. Daher dürfen die Datenbestände in diesen Tabellen
nicht größer sein als der verfügbare Hauptspeicher. Andererseits kann eine Anwendung gleichzeitig Tabellen unterschiedlichen
Typs nutzen – Informationen, die seltener
abgefragt werden oder bei denen es nicht so
entscheidend auf die Antwortzeit der Datenbank ankommt, lassen sich also in herkömmlichen Tabellen speichern und belegen dann
keinen Platz in speicherresidenten Tabellen.
Speicherresidente Tabellen sind die notwendige Basis für das von Microsoft sogenannte In-Memory-OLTP (Codename: Hekaton). Diese Technik bringt zweierlei Geschwindigkeitsvorteile:
Erstens kann die Engine Stored Procedures, die man einmal auf die effizienteste
Durchführung hin analysiert und dann in der
optimierten Form speichert, in die Maschinensprache des Servers kompilieren. Die resultierenden native Stored Procedures lassen
sich viel effizienter und mit erheblich geringerer CPU Belastung ausführen, als das üblicherweise mit SQL-Befehlen möglich wäre.
Der Ansatz geht freilich nur dann auf, wenn
die Anwendungslogik in Stored Procedures
implementiert ist und nicht auf Applikationsoder Webservern abläuft.
c’t 2013, Heft 22
184
©
Copyright by Heise Zeitschriften Verlag
ct.2213.184 187 27.09.13 10:55 Seite 185
Know-how | Datenbanken
Durchgehend geöffnet
Zweitens funktioniert die Datenbearbeitung
Latch-free. Was bedeutet das? Ein herkömmliches Datenbanksystem muss sicherstellen,
dass ein Anwender beim Schreiben etwaiger
Veränderungen auf die Festplatte exklusiven
Zugriff auf die Speicherseite mit dem betroffenen Datensatz hat. Dafür sorgen während
der Synchronisation sogenannte Latches, die
typischerweise für einige Mikrosekunden auf
eine Datenbankseite gehalten werden. Microsofts In-Memory-OLTP kann auf die Synchronisation und die damit verbundenen
Latches verzichten. Im Zusammenspiel mit
nativen Stored Procedures ermöglicht diese
Neuerung nach Microsofts Erkenntnissen
Durchsatzsteigerungen um den Faktor 10 bis
30. Dabei setzt der Hersteller ausdrücklich
nicht voraus, dass die Rechnerlast vorwiegend durch Lesezugriffe zustandekommt.
Vielmehr sollen diese Steigerungen auch für
hohe Einfüge- und Änderungslasten gelten.
In-Memory-OLTP unterstützt nicht in allen
Fällen alle Transaktions-Isolationsstufen (um
das „I“ im Anforderungs-Prinzip „ACID“ – Atomicity, Consistency, Isolation, Durability – zu
erreichen). Daher muss man Anwendungslogik für den Einsatz mit In-Memory-optimierten
Tabellen in manchen Situationen anpassen.
Anlegen, sichern, zurückspielen
Zur Absicherung, dass die Inhalte einer speicherresidenten Tabelle bei einer Störung
nicht verloren gehen, bedient sich die Engine sogenannter Continuous Checkpoints.
Das heißt, sie wertet kontinuierlich das
Transaktions-Log aus, konsolidiert die darin
dokumentierten Daten-Änderungen und
schreibt die daraus resultierenden Daten se-
quentiell in nicht-fragmentierte Festplattendateien. Bei einem Restart liest die Engine
diese Backup-Dateien sequentiell aus und rekonstruiert daraus die speicherresidenten
Tabellen.
Für die Definition von In-Memory-Tabellen sieht SQL Server 2014 zwei Möglichkeiten
vor: Normalerweise gibt man vor, dass sowohl die Tabellenstruktur als auch die Tabelleninhalte beim Restart wiederhergestellt
werden. Für Interims-Tabellen, etwa zur kurzzeitigen Aufnahme gefilterter Datenauszüge,
braucht man aber keine fortlaufenden Daten-Logs aufzuzeichnen. In diesem Fall legt
man fest, dass ausschließlich das Tabellenschema gesichert wird.
Zeilen, Spalten oder beides
Für die meisten analytischen Aufgaben eignen sich spaltenorientierte Tabellen besser
als solche mit Zeilenstruktur [1]. Andererseits
kostet es sehr viel Rechenleistung, einen
kompletten einzelnen Datensatz einer spaltenorientierten Tabelle auszulesen oder gar
zu verändern. Für diese Aufgabe muss das
System eine größere Menge von Werten
jeder Spalte durchkämmen, um das Feld des
betroffenen Datensatzes auszumachen. Die
Vorteile der spalten- und zeilenorientierten
Datenorganisation lassen sich auf zweierlei
Weise miteinander verbinden: den Column
Store Index für zeilenorientierte Tabellen
und die Delta-Tabelle für Veränderungen in
spaltenorientierten Datenbeständen.
Mit dem Column Store Index hat Microsoft
im SQL Server 2012 eine Suchhilfe implementiert, um von den Datensätzen, die einer
Suchanfrage entsprechen, jeweils nur die gerade benötigten Felder in den Speicher zu
laden. Während ein herkömmlicher Index die
kompletten Datensätze einer Tabelle nach
der festgelegten Reihenfolge sortiert, beschreibt ein Column Store Index quasi eine
abgespeckte Zeilen-Tabelle mit bestimmten
oder allen Datenspalten in der festgelegten
Reihenfolge. Bei Abfragen werden dann nur
die Index-Segmente mit den relevanten
Spalten durchsucht. Außerdem ermöglicht
die spaltenorientierte Sortierung der Werte
im Vergleich zu einer zeilenorientierten Ablage eine erheblich bessere Kompression. Bei
SQL Server 2012 sind Column Store Indizes
nicht modifizierbar. Bei Änderungen am Datenbestand muss der Column Store Index
komplett gelöscht und wieder neu aufgebaut werden. Eine Ausnahme bildet nur der
Fall, dass am Ende der Tabelle eine neue Partition mit Daten angefügt wurde.
SQL Server 2014 realisiert den sogenannten In-Memory Column Store for DataWarehousing als Clustered Index – also nicht als
Index mit einer korrespondierenden, aber
getrennt gespeicherten Tabelle, sondern von
vornherein als sortierte Tabelle. Diese Veränderung reduziert schon an sich die Zahl der
benötigten Speicherseiten, dazu kommt
aber noch der Effekt, dass sich diese sortierten Datenspalten viel effizienter im Speicher
komprimieren lassen.
Über die sogenannten Delta-Tabellen verbinden sich die Geschwindigkeitsvorteile der
spaltenorientierten Datenspeicherung mit
einem aufs Erträgliche reduzierten Aufwand,
den Datenbestand zu verändern. Dabei handelt es sich um zeilenorientierte Ergänzungstabellen, in denen zunächst einmal alle
neuen Inhalte landen – neu angelegte Datensätze ebenso wie die neuen Fassungen
bestehender Datensätze, die das System an
ihrer ursprünglichen Position inzwischen als
gelöscht markiert hat. Ist eine Delta-Tabelle
Zeilentabellen umfassen unnötig viele Speicherseiten
In einer zeilenorientierten Tabelle verteilen sich ganze Datensätze auf die einzelnen Speicherseiten.
Um etwa aus der Tabelle „Autos“ die Merkmale „Marke“ und „Jahr“ zu selektieren, muss man mehr
Speicherseiten als nötig laden, weil die relevanten Seiten auch aktuell nicht benötigte Daten enthalten.
Clustered Index über die erste (AutoID-)Spalte
der Tabelle Autos
SELECT Marke, Jahr FROM Autos
Speicherseite 1
101 VW
102 Opel
103 BMW
Golf
Astra
Z1
grau
weiß
braun
in den Speicher geladene Daten
(alle Speicherseiten)
2006
2011
2010
Speicherseite 2
104 Renault
105 Toyota
106 Ford
Clio
Prius
Focus
grün
weiß
blau
2009
2011
2012
Speicherseite 3
107 BMW
108 Audi
109 Ford
325T
A3
S-Max
blau
weiß
rot
2012
2011
2012
angeforderte Daten
101 VW
102 Opel
103 BMW
Golf
Astra
Z1
grau
weiß
braun
2006
2011
2010
VW
Opel
BMW
2006
2011
2010
104 Renault
105 Toyota
106 Ford
Clio
Prius
Focus
grün
weiß
blau
2009
2011
2012
Renault
Toyota
Ford
2009
2011
2012
107 BMW
108 Audi
109 Ford
325T
A3
S-Max
blau
weiß
rot
2012
2011
2012
BMW
Audi
Ford
2012
2011
2012
c’t 2013, Heft 22
185
©
Copyright by Heise Zeitschriften Verlag
ct.2213.184 187 27.09.13 10:55 Seite 186
Know-how | Datenbanken
auf einen vorgegebenen Umfang angewachsen, überträgt das System diese Daten online
in die Spaltentabelle.
Der oben erwähnte Column Store for DataWarehousing kombiniert unter der Haube indexierte Datenspalten mit Delta-Tabellen. Für
den Anwender stellt sich das Ganze einfach
wie ein modifizierbarer Column Store Index
dar, den das Datenbanksystem so weit wie
möglich in einem speziellen Bereich des Arbeitsspeichers unterbringt. Passen nicht alle
Daten in den Arbeitsspeicher, lassen sich Teile
davon auf Festplatte auslagern.
IBMs Blink-Ultra-Konzept
IBM bringt mit der Release 10.5 seiner ServerDatenbank DB2 die sogenannte BLU-Technik
an den Start. Der Name basiert auf dem Projekt Blink des IBM-Forschungszentrums in Almaden. Blink war ursprünglich nur für Datenbanken gedacht, die vollständig in den
Hauptspeicher eines Multiprozessor-Servers
passen. Bei BLU fällt diese Beschränkung
weg: Tabellen dürfen sehr wohl größer sein
als der Arbeitsspeicher.
Trotzdem bleibt es das Ziel, alle Datenbank-Aufgaben mit möglichst wenigen Massen- und Hauptspeicherzugriffen zu erledigen und dabei eine möglichst hohe Trefferquote auf Daten im RAM zu erzielen. Das bedeutet einerseits, die Engine sollte nur die
tatsächlich benötigten Daten verarbeiten,
aber am besten gar keine Rechenzeit damit
vergeuden, auch andere Felder der betroffenen Datensätze zu lesen. Eine wichtige Rolle
spielt auch die Datenkompression: Je mehr
Daten in den Arbeitsspeicher passen, desto
seltener wird man im Betrieb darauf warten
müssen, dass benötigte Datensätze von der
Festplatte gelesen werden.
Die Neuerungen von BLU betreffen zum
einen die Optimierung der Datenorganisation für schnelle Adressierung und effiziente
Nutzung des Speicherplatzes und zum anderen die Nutzung von Rechenverfahren, um
Datenbankoperationen möglichst effizient
und nach Möglichkeit mit mehreren Prozes-
soren und Prozessor-Komponenten parallel
auszuführen.
Spaltenweise verdichtet
Dank BLU kann DB2 in Version 10.5 Daten in
spaltenorientierten Tabellen ablegen. Dabei
entsteht ein Column Store, der im Regelfall
jede Datenspalte einzeln enthält, auch wenn
man in Sonderfällen mehrere Spalten zusammenfassen kann. Die Suche nach allen Datensätzen mit einem bestimmten Attribut
kommt in einer spaltenorientierten Tabelle
wesentlich schneller zu einem Ergebnis als in
einer zeilenorientierten, weil in der ersteren
alle Zeiger auf die gesuchten Datensätze unmittelbar hintereinander liegen.
Einen weiteren Vorteil spielen spaltenorientierte Tabellen aus, wenn für ein Datenfeld
nur wenige Werte in Betracht kommen. In diesem häufigen Fall lässt sich der Inhalt nämlich
besonders wirksam mit der sogenannten Frequenz-Kompression verdichten. Dabei wird in
einem Lexikon festgehalten, wie oft die einzelnen Werte auftreten, und die häufigsten
Werte werden mit weniger Bits kodiert als seltenere Werte. In großen Tabellen kann der
DB2-interne Compression Optimizer eigene
Lexika für verschiedene Abschnitte jeder Spalte führen und in diesen Abschnitten die jeweils effizienteste Kodierung anwenden.
Beispielsweise könnten in einer Tabellenspalte Bundesländer notiert sein, sodass für
jedes Datenfeld nur 16 Werte in Betracht kommen. Nach der Analyse, welche dieser Werte
in einer Stichprobe am häufigsten vorkommen, könnte das System die Spalte in drei Partitionen aufteilen, sodass in der ersten Partition nur die beiden häufigsten Werte auftauchen, jeweils kodiert mit einem Bit „0“ oder
„1“. In der zweiten Partition werden jeweils
zwei Bits verwendet, um den dritt- bis sechsthäufigsten Wert zu kodieren, und alle anderen
Werte erhalten in der dritten Partition eigene
Kombinationen von jeweils vier Bits. Anders
als in einer zeilenorientierten Tabelle müssen
die Elemente einer Datenspalte keine festgelegte Länge haben, deshalb resultiert die Fre-
Spaltenweise Indexierung spart Speicherzugriffe
Sind dieselben Daten wie in der Tabelle auf Seite 185 per Column Store Index
spaltenweise adressierbar, gelingt die Selektion der Merkmale „Marke“ und „Jahr“
ohne überflüssige Speicherzugriffe und damit schneller als in einer Zeilentabelle.
angeforderte Daten
Columnstore Index zur Tabelle Autos
101
102
103
104
105
106
107
108
109
VW
Opel
BMW
Renault
Toyota
Ford
BMW
Audi
Ford
Golf
Astra
Z1
Clio
Prius
Focus
325T
A3
S-Max
grau
weiß
braun
grün
weiß
blau
blau
weiß
rot
2006
2011
2010
2009
2011
2012
2012
2011
2012
SELECT
Marke,
Jahr
FROM
Autos
VW
Opel
BMW
Renault
Toyota
Ford
BMW
Audi
Ford
2006
2011
2010
2009
2011
2012
2012
2011
2012
186
quenzkompression in kürzeren und somit
schneller durchsuchbaren Datenspalten.
Um Abfragen noch weiter zu beschleunigen, pflegt DB2 für jede spaltenorientierte
Tabelle zusätzlich eine Katalogtabelle mit
dem kleinsten und größten Wert für jeweils
rund 1000 aufeinanderfolgende Einträge.
Auf Rechnern mit aktuellen Intel- und IBMPower-Prozessoren nutzt BLU deren Fähigkeiten, dass jeder Prozessor gleichzeitig mehrere
unterschiedliche Daten verarbeiten kann, zum
Beispiel um eine Vergleichsoperation auf
unterschiedliche Abschnitte einer Tabelle anzuwenden. Den bestmöglichen Zeitgewinn
bringt die Parallelverarbeitung aber nur dann,
wenn jeder Prozessor in seinem SpeicherCache ein analoges Daten-Layout vorfindet.
Die Strategie, mit der BLU Daten im Speicher-Cache ablegt oder bei Bedarf verwirft,
richtet sich deshalb auch nach den Anforderungen der Parallelverarbeitung. Frühere Versionen von DB2 entscheiden mit der Least-recently-used-Strategie darüber, welche Daten
bei Platzmangel aus dem Hauptspeicher entfernt werden. Die BLU-Erweiterung priorisiert
die Inhalte der Hauptspeicher-Seiten dagegen
anhand ihrer Nützlichkeit. Dabei erhalten spaltenorientierte Datenseiten Vorrang gegenüber
zeilenorientierten, weil sie ergebisrelevanter
sind: Um in einer Datenspalte einen bestimmten Datensatz ausfindig zu machen, muss man
nur solche Felder lesen, die einen potenziellen
Treffer darstellen. Dieselbe Suche in einer Sequenz ganzer Datenzeilen überstreicht dagegen auch alle anderen, im aktuellen Kontext
irrelevanten Datenfelder der Tabelle.
Außerdem schätzt der Query Optimizer
bei jeder Abfrage zuerst ab, wie viel Speicherplatz dafür zu reservieren ist, und entscheidet daraufhin, wie viele Abfragen er zur
gleichzeitigen Ausführung startet.
DB2 10.5 parallelisiert Rechenschritte
nicht nur zwischen Rechenkernen, sondern
auch durch die Vektor-Rechenfunktionen der
unterstützten Prozessoren. Statt für den Vergleich eines Integer-Datenfelds mit einer 16Bit-Konstanten zwei komplette 64-Bit-Register des Prozessors zu blockieren, kann man
diese Register über Vektorfunktionen gleichzeitig für vier solche Operationen nutzen.
Unabhängig von der Parallelverarbeitung
macht sich bemerkbar, dass DB2 alle BasisVergleichsoperationen wie „=“, „<>“ oder
„BETWEEN“ an den komprimierten Daten im
Speicher vollziehen kann, ohne zusätzlich
Zeit und Platz für deren Dekompression und
anschließende erneute Kompression zu verwenden.
Leichter Umstieg
Die Möglichkeit der spaltenbasierenden Speicherung und die Arbeitsweise gleicht einem
Paradigmen-Wechsel und ist insofern revolutionär. Andererseits ist die Einführung der
BLU-Technik in das bestehende Datenbanksystem eine evolutionäre Veränderung und
damit äußerst kundenfreundlich: BLU ändert
nichts an den fundamentalen Aufgaben der
Datenbankadministration. Sicherung, Wie-
c’t 2013, Heft 22
©
Copyright by Heise Zeitschriften Verlag
ct.2213.184 187 27.09.13 10:55 Seite 187
Know-how | Datenbanken
Techniken zur Verminderung von Speicherzugriffen
Durch Datenkompression, spaltenorientierte Speicherung und Synopsis-Tabellen
vermindert DB2 BLU die Zahl der erforderlichen Speicherzugriffe etwa zur Bearbeitung
einer Abfrage. Die notwendigen Zugriffe werden so weit wie möglich parallelisiert.
Daten
Daten
Daten
Daten
Daten
Spaltenzugriff
Komprimierung
(In-Memory)
10 TByte
Daten
Daten
Daten
1 TByte
derherstellung und Laden der Daten bleiben
gleich. Darüber hinausgehende, spezielle Aktivitäten wie etwa die Neuprogrammierung
bestehender Prozeduren sind zum Einsatz
dieser Technik nicht erforderlich.
Für SQL-Abfragen ist die BLU-Technik
weitgehend transparent. Zum Beispiel lassen
sich innerhalb einer SQL-Abfrage gleichzeitig
zeilenbasierende (non-BLU-) und spaltenbasierende (BLU-) Tabellen verwenden.
Nach der Definition und dem Laden der
Tabellen steht die Datenbank sofort für analytische Abfragen zu Verfügung. Für traditionelle Optimierungen gibt es keine Gelegenheit mehr, aber auch keinen Bedarf:
–ˇMangels Indizes auf spaltenbasierenden
Tabellen entfällt das Indextuning.
–ˇEine Reorganisation der Daten ist nur noch
zum Entfernen gelöschter Seiten notwendig und erfolgt automatisch.
–ˇMaterialized Query Tables (MQTs), also Datenstrukturen zum Zwischenspeichern von
Abfrageergebnissen, und Multiple Dimension Cluster (MDC), also mehrdimensional
indexierte Unter-Tabellen mit Auszügen
größerer Tabellen, lassen sich für BLU-Tabellen nicht anlegen, brächten aber auch
keinen Geschwindigkeitsvorteil.
–ˇBemühungen, eine SQL-Anweisung durch
Umformen schneller ausführbar zu machen, erweisen sich als wirkungslos und
damit als überflüssig.
Die Erfahrungen von ITGAIN als Alphatester
zeigten bereits frühzeitig das Leistungspotenzial der neuen DB2-Version (siehe c’t-Link).
Zwar gab es am Anfang eine Menge sogenannter Never-Come-Back-SQLs, also Prozeduren, deren Ausführung nach mehreren
Stunden immer noch nicht abgeschlossen
war. Doch während der gesamten Testphase
von der ersten Alphaversion bis hin zur Serienversion nahm die Stabilität kontinuierlich
zu und der Anteil schlecht laufender Prozeduren sank auf unter ein Prozent. Gleichzeitig
steigerte sich die Performance, auch für nicht
analytische SQL-Prozeduren, fortlaufend.
Die BLU-Technik beschert der DB2-Engine
vor allem Geschwindigkeitsvorteile bei der
Analyse großer Datenbestände – auch sol-
Daten
Überlesen
von Spalten
10 GByte
Daten
Daten
parallele
Verarbeitung
1 GByte
cher, die nicht vollständig in den Hauptspeicher passen. Für eine rein transaktionale Verarbeitung der Daten ist die spaltenbasierende BLU-Technik heute aber noch nicht optimal geeignet.
Mehrere Wege nach Rom
Während SAP HANA konsequent die Technik
einer spaltenorientierten OLAP-Datenbank
auf die Befähigung zur Transaktionsverarbeitung erweitert, setzen Microsoft und IBM auf
das Miteinander von zeilen- und spaltenorientierten Datenstrukturen, um ihre Engines
auch bei Lastprofilen mit hohem Transaktionsanteil zu beschleunigen. Beide Hersteller
klassifizieren ihre Errungenschaften nicht als
„In-Memory-Datenbank“, sondern als „In-Memory-optimiert“. Deren Vorteile sollen auch
dann zum Tragen kommen, wenn der Datenbestand nicht komplett in den Hauptspeicher passt.
So repräsentiert Microsoft SQL Server 2014
gleichermaßen den Aufbruch in eine neue InMemory-Arbeitsweise wie die Weiterentwicklung von Techniken, die der Hersteller mit
SQL Server 2012 eingeführt hat. Stored Procedures können in Maschinensprache besonders schnell auf dem Datenbankserver laufen.
Neuerungen im Bereich Column Store sind
transparent für Anwendungslogik und Administration implementiert.
Microsofts erste Version der In-MemoryOLTP-Technik entstand nicht als selbstständige Engine, sondern integriert in das existierende Datenbanksystem. Dadurch kann die
Technik auch von Hochverfügbarkeits-Features des SQL-Server-Features wie AlwaysOn,
Log-Shipping und Windows-Clustering profitieren, ohne dass Kunden ihre Konfigurationen und Prozesse für Hochverfügbarkeit und
Disaster-Recovery oder ihre Datensicherungs-Software umstellen müssten.
Weitere Beschleunigungen plant Microsoft noch vor der Marktfreigabe von SQL Server 2014. Im CTP 2 gibt es einen zusätzlichen
Indextyp für In-Memory-optimierte-Tabellen,
der speziell Abfragen nach Bereichen von
Spaltenwerten beschleunigen soll.
c’t 2013, Heft 22
Daten
Vektorverarbeitung
32 MByte
8 MByte
Auch IBMs DB2 10.5 sieht für viele Aufgaben herkömmliche Tabellen vor, führt aber
mit den BLU-Tabellen einen zusätzlichen, InMemory-optimierten Tabellentyp insbesondere für analytische Aufgaben ein. Zwar kann
man unterschiedliche Daten auf herkömmliche und BLU-Tabellen verteilen, doch muss
sich der Datenbank-Designer nach momentanem Stand frühzeitig für das eine oder andere Format entscheiden. Das Ziel zukünftiger Versionen muss es sein, dieses „entweder
oder“ in ein „sowohl als auch“ umzuwandeln.
Dies würde bedeuten, dass eine logische Tabelle gleichzeitig in zwei Formaten gepflegt
wird. Für eine zeilenbasierte Tabelle sollten
bestimmte Inhalte zusätzlich spaltenbasiert
abgelegt und wie ein Performance Index verwendet werden. Die konsistente Speicherung der Daten ist dabei weiterhin durch das
Datenbanksystem sicherzustellen. Bei der
Nutzung der Daten sollte der eingebaute
Query-Optimizer auf Basis der formulierten
Abfrage entscheiden, welche Speicherform
den Datenzugriff optimal unterstützt.
Schon heute nutzt DB2 BLU den verfügbaren Hauptspeicher möglichst effizient,
zum Beispiel, um bevorzugt die besonders
Abfrage-relevanten spaltenorientierten Daten vorzuhalten. Zusätzliche PerformanceGewinne resultieren aus der Parallelisierung
zwischen Prozessorkernen sowie durch Vektor-Operationen einzelner Prozessorkerne,
außerdem durch Synopsis-Tabellen zum
schnelleren Navigieren in Datenspalten.
Sowohl SQL Server 2014 als auch DB2 10.5
BLU eignen sich als neue Software auf bestehenden Datenbank-Servern. Beide Engines
versprechen, als analytische Datenbanken
fungieren zu können, ohne dabei auf die Fähigkeit zur Transaktionsverarbeitung zu verzichten.
(hps)
Literatur
[1]ˇDr. Alexander Zeier, Christian Tinnefeld, Festplatte ade!, Hauptspeicherdatenbanken für Unternehmensanwendungen, c’tˇ26/11, S.ˇ188
www.ct.de/1322184
c
187
©
Copyright by Heise Zeitschriften Verlag