Speicherbanken
Werbung
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
