Im Laufe der letzten Jahre lassen sich im Hardwarebereich mehrere Trends erkennen. So kam es etwa ab der Jahrtausendwende zu einem Paradigmenwechsel bei den Prozessoren. Vor dieser Zeit wurde eine Erhöhung der Prozessorleistung vor allem über eine erhöhte Taktrate realisiert. Danach wurde die Taktrate nur noch moderat erhöht. Stattdessen wurden vor allem die Anzahl der CPU-Kerne pro Prozessor vermehrt. Es gibt also nicht mehr einen sehr schnellen Prozessorkern, der die gesamte Arbeit verrichtet, sondern mehrere gleich schnelle CPUs, die parallel rechnen können. Ein weiterer noch anhaltender Trend ist der Preisverfall beim Arbeitsspeicher. Große Mengen Arbeitsspeicher sind heutzutage auch für kleine und mittelständische Unternehmen erschwinglich. Während im Jahr 1965 der Preis pro MB Ram bei über 2.500.000 US$ lag, so fiel dieser Preis bis zum Jahr 2014 auf weniger als 0,01 US$.
Dieser Trend und die Tatsache, dass physikalische Festplatten bei einer Datenbank häufig den Leistungsflaschenhals darstellen, förderten die Entwicklung von In-Memory Datenbanken. Die Technologie wurde schon in den 1990ern entwickelt, eine erhöhte Aufmerksamkeit bekamen die Systeme allerdings erst mit der Vorstellung von HANA, der In-Memory Datenbank von SAP im Jahre 2010. Andere Datenbankhersteller begannen ebenfalls In-Memory Technologien in ihre Produkte einzubauen, darunter auch Microsoft beim SQL-Server. Die Hersteller erhofften sich durch die Datenhaltung im Arbeitsspeicher massive Geschwindigkeitsvorteile gegenüber der üblichen Speicherung der Daten auf Festplatten.
Durch meine Arbeit bei der ixto GmbH hatte ich die Möglichkeit einen Vergleich zwischen der In-Memory Datenbank SAP Hana und den In-Memory OLTP von Microsoft durchzuführen (Vergleich SAP Hana und In-Memory OLTP von Microsoft). Aufbauend darauf, habe ich meine Masterarbeit im Fach Wirtschaftsinformatik zum Thema „Evaluierung von Microsoft Technologien im DWH-Umfeld mit Schwerpunkt In-Memory Technologie“ zu schreiben. In diesem Blog werde ich als erstes, die Grundthematik meiner Arbeit vorstellen. Die Ergebnisse werden in einem separaten Beitrag veröffentlicht.
Für die Evaluation wurde ein Programm geschrieben, welches das U-Bahnsystem von Berlin simuliert. Dieses hat zur Zeit 10 Linien mit über 170 Bahnhöfen. Die hierbei erzeugten Daten für Züge, Stationen, Passagiere und Zugdepots werden in Logtabellen gespeichert. Diese werden minütlich in ein Data-Warehouse überführt und mittels Cube ausgwertet.
In diesen Blogbeitrag werden die Technologien grundsätzlich vorgestellt. In weiteren Beiträgen werden die Ergebnisse dargestellt und zusätzlich werden Ergebnisse eines Benchmarks mit In-Memory OLTP in Verbindungen mit Fusion-IO Karten präsentiert.
In-Memory OLTP
Mit dem SQL Server 2014 hat Microsoft eine neue Datenbankengine mit dem Namen XTP (Extreme Transactional Processing) eingeführt, welche unter dem Projektnamen „Hekaton“ entwickelt wurde. Diese ist vollkommen im Datenbankserver integriert und dient dazu, die Daten einzelner Tabellen komplett in den Arbeitsspecher zu laden, wodurch eine signifikante Beschleunigung bei Lese- und Schreibvorgängen erzielt werden soll. Das Besondere an dieser Technologie ist, dass sie es im Gegensatz zu reinen In-Memory Datenbanken wie z. B. TimesTen von Oracle erlaubt, nicht alle Daten im RAM zu halten, sondern selektiv Tabellen in den Arbeitsspeicher zu laden. Dadurch ist es möglich, selten abgerufene Daten mit der konventionellen Datenbankengine weiter auf Festplatte zu speichern, wodurch RAM und damit auch Kosten gespart werden können.
Neben dem geänderten Speichermedium gibt es auch weitere Änderungen bei den In-Memory Tabellen, welche in diesem und den folgenden Kapiteln beschrieben und erklärt werden. So erfüllen diese Tabellen auch die ACID-Eigenschaften. Am kritischsten ist durch die Datenhaltung im Arbeitsspeicher der Punkt durability, da beim Neustart des Servers der RAM geleert wird. Allerdings können Loggingdaten auch auf Festplatte gespeichert werden, wodurch die Dauerhaftigkeit gewährleistet wird. Es gibt allerdings auch die Möglichkeit, diese Eigenschaft zu deaktivieren und die Daten ohne Sicherung auf Festplatte nur im RAM zu halten. Dadurch werden keine Zugriffe auf Festplatte benötigt und die Performance wird erhöht. Mehr zu diesem Thema und wie In-Memory OLTP eingerichtet werden kann, wird im folgenden Blogbeitrag beschrieben Erweiterungen der In.Memory Technologien im SQL Server 2014
Columnstore-Index
Mit der Version 2012 des SQL Server wurde der nicht gruppierte (non-clustered) Columnstore-Index eingeführt. Durch diesen ist es möglich, eine spaltenorientierte Speicherung (Columnstore) von Daten für ausgewählte Tabellenspalten durchzuführen. Dieser Index wird zusätzlich zur bisherigen zeilenorientierten Speicherung hinzugefügt, ergänzt diese also. Der große Nachteil im SQL Server 2012 bei diesem Index war allerdings, dass die Tabellen nach Erstellung des Index nicht mehr updatebar waren, also z.B. keine Daten hinzugefügt oder entfernt werden konnten. Um dies zu tun, musste als erstes der Index entfernt werden, die Aktualisierung der Daten durchgeführt werden und zum Schluss der Index wieder erstellt werden.
Zusätzlich zum nicht gruppierten Index, wurde daher mit dem SQL Server 2014 ein gruppierter Index mit spaltenorientierter Speicherung (Clustered-Columnstore-Index) vorgestellt. Bei diesem wird die zeilenorientierte Speicherung nicht ergänzt, sondern vollständig durch die Spaltenorientierte ersetzt. Durch Kompressionen kann dadurch der erforderliche Speicherplatz für die Tabelle z.T. erheblich reduziert werden. Des Weiteren ist dieser Index durch den Einsatz eines s.g. Deltastores updatebar, wodurch der große Nachteil des non-clustered Columnstore-Index behoben wurde.
Tabular Cube
Der Tabular Cube stellt eine Weiterentwicklung von Power Pivot for Excel dar, einem Add-In für Excel 2010. Dies wurde in das OLAP-Tool Analysis Services des SQL Server 2012 integriert unter dem Namen „Business Semantic Model“ (BISM) oder Tabular Cube. Das bisherige Cube-Model wird von Microsoft nun als „Multidimensional Model“ bezeichnet und kann auch weiterhin genutzt werden. Power Pivot, die Grundlage des Tabular Cubes, stellt eine In-Memory Datenbank dar, welche dem Nutzer im Zuge des Self-Service BI ermöglichen soll, sich selbst prototypische BI-Lösungen zu bauen. Der Tabular Cube stellt zwei verschiedene Speichermodi bereit: den In-Memory und dem Direct Query. Ersterer speichert die Daten in der xVelocity-Storage-Engine. Diese hält die Daten mittels non-clustered Columnstore-Index spaltenorientiert vollständig im RAM. Als Abfragesprachen können in diesem Modus MDX und DAX verwendet werden. Beim Direct Query Modus hingegen werden die Daten nicht extra gespeichert, sondern liegen relational im SQL-Server vor. Dieser Modus ist vor allem für Echtzeitauswertungen sinnvoll. Allerdings kann hierbei nur die Abfragesprache DAX genutzt werden, wodurch ein Tabular Cube im Direct Query Modus nicht mittels Pivot Tabelle in Excel gebrowst werden kann.