Der richtige Prozessor für den Auftrag - Co-Prozessoren in einem DBMS

Mehr und mehr Datenbankmanagementsysteme (DBMS) verarbeiten die Daten nur noch im Hauptspeicher oder speichern gar die ganze Datenbank dort, um schnell darauf zugreifen zu können. In diesen Systemen ist die Verarbeitungsgeschwindigkeit nur durch den Prozessor beschränkt, da die Daten nicht erst von der Festplatte geladen werden müssen.Grafikkarten (GPUs) haben vor kurzem CPUs überholt, wenn man reine Verarbeitungsgeschwindigkeit betrachtet. Die Forschung hat zudem gezeigt, dass Sie neben der Bildverarbeitung auch zur Lösung von Problemen anderer Bereiche genutzt werden können. Allerdings können nicht alle Algorithmen die Vorteile der GPU-Architektur nutzen.Zunächst müssen sie angepasst werden, um Daten parallel im SIMD-Stil zu verarbeiten. Außerdem muss beachtet werden, dass die Daten erst über den PCI-Express-Bus transferiert werden müssen, über den Grafikkarten mit dem Speicher verbunden sind.In dieser Arbeit werden Aufgaben in DBMSen untersucht, die auf die Grafikkarte ausgelagert werden können. Es wird gezeigt, dass Anfrageoptimierung, Anfrageverarbeitung und Applikationslogik unter Umständen schneller auf der Grafikkarte ausgeführt werden können als auf der CPU, aber auch, dass sich nicht jede Aufgabe dafür eignet.Durch detaillierte Beschreibung, Implementierung und Evaluierung vier unterschiedlicher Beispiele wird erklärt, wie passende Aufgaben identifiziert und portiert werden können.In jedem Fall ist es nicht vorteilhaft, die Grafikkarte zu benutzen, wenn die Datenmenge zu gering ist, um die Verarbeitung auf alle verfügbaren Kerne zu verteilen. Zudem ist es wahrscheinlich, dass die CPU schneller zu einem Ergebnis kommt als die GPU, wenn nicht der ganze Datensatz in den Grafikspeicher passt. Demzufolge muss die Entscheidung, wo die Verarbeitung stattfindet, zur Laufzeit gefällt werden. Sie hängt ab von den verfügbaren Implementierungen, der Hardware, den Eingabe-Parametern und den Eingabe-Daten. Es wird ein lern-basiertes System vorgestellt, das an Hand vergangener Ausführungen entscheidet, welche Art der Verarbeitung die beste ist.Today, more and more Database Management Systems (DBMSs) keep the data completelyin memory during processing or even store the entire database there for fastaccess. In such system more algorithms are limited by the capacity of the processor, becausethe bottleneck of Input/Output (I/O) to disk vanished. At the same time GraphicsProcessing Units (GPUs) have exceeded the Central Processing Unit (CPU) in terms ofprocessing power. Research has shown that they can be used not only for graphic processingbut also to solve problems of other domains. However, not every algorithm canbe ported to the GPU's architecture with bene_t. First, algorithms have to be adaptedto allow for parallel processing in a Single Instruction Multiple Data (SIMD) style. Second,there is a transfer bottleneck because high performance GPUs are connected viaPCI-Express (PCIe) bus.In this work we explore which tasks can be o_oaded to the GPU with bene_t. Weshow, that query optimization, query execution and application logic can be sped upunder certain circumstances, but also that not every task is suitable for o_oading. Bygiving a detailed description, implementation, and evaluation of four di_erent examples,we explain how suitable tasks can be identi_ed and ported.Nevertheless, if there is not enough data to distribute a task over all available cores onthe GPU it makes no sense to use it. Also, if the input data or the data generate duringprocessing does not _t into the GPU's memory, it is likely that the CPU produces a resultfaster. Hence, the decision which processing unit to use has to be made at run-time. Itis depending on the available implementations, the hardware, the input parameters andthe input data. We present a self-tuning approach that continually learns which deviceto use and automatically chooses the right one for every execution