Robust Query Processing in Co-Processor-accelerated Databases

Breß, Sebastian; Funke, Henning; Teubner, Jens

doi:10.1145/2882903.2882936

Cited by 38 publications

(22 citation statements)

References 29 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…We implemented Hawk as a prototype that targets mainmemory database engines that store data in a columnmajor format. We show the viability of our approaches on the example of CoGaDB [5,6], as it fulfills our requirements and resulted in the smallest integration effort for us. Note that we can apply our concepts to any other system having an in-memory column store, including commercial systems such as SAP HANA [12], DB2 BLU [40], or the Apollo engine of SQL Server [27].…”

Section: Hawk Implementation Detailsmentioning

confidence: 64%

“…Many database prototypes were developed to study different aspects of query processing on CPUs and GPUs, such as GDB [16], GPUDB [52], OmniDB [56], Ocelot [20], CoGaDB [6], and HeteroDB [55].…”

Section: Databases On Heterogeneous Hardwarementioning

confidence: 99%

“…We discuss the dimensions in which we can vary the generated code of pipeline programs (cf. Section 4,5,6) and show the impact of these variations on common processors and co-processors. 3.…”

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Generating custom code for efficient query execution on heterogeneous processors

et al. 2018

Self Cite

View full text Add to dashboard Cite

Processor manufacturers build increasingly specialized processors to mitigate the effects of the power wall to deliver improved performance. Currently, database engines are manually optimized for each processor: A costly and error prone process.In this paper, we propose concepts to enable the database engine to perform per-processor optimization automatically. Our core idea is to create variants of generated code and to learn a fast variant for each processor. We create variants by modifying parallelization strategies, specializing data structures, and applying different code transformations.Our experimental results show that the performance of variants may diverge up to two orders of magnitude. Therefore, we need to generate custom code for each processor to achieve peak performance. We show that our approach finds a fast custom variant for multi-core CPUs, GPUs, and MICs.

show abstract

Section: Hawk Implementation Detailsmentioning

confidence: 64%

Section: Databases On Heterogeneous Hardwarementioning

confidence: 99%

See 1 more Smart Citation

Generating custom code for efficient query execution on heterogeneous processors

et al. 2018

Self Cite

View full text Add to dashboard Cite

show abstract

“…Comparison with state-of-the-art GPU join. In addition we compare our algorithm with two state-of-the-art GPUenabled analytical engines, DBMS-X, a commercial engine that uses code generation to produce efficient code for GPUquery execution and CoGaDB [8], [9], a research GPU-enabled DBMS system with an operator-at-a-time execution model.…”

Section: Out-of-gpu Joinmentioning

confidence: 99%

Hardware-Conscious Hash-Joins on GPUs

Sioulas

Chrysogelos

Karpathiotakis

et al. 2019

2019 IEEE 35th International Conference on Data Engineering (ICDE)

View full text Add to dashboard Cite

Traditionally, analytical database engines have used task parallelism provided by modern multisocket multicore CPUs for scaling query execution. Over the past few years, GPUs have started gaining traction as accelerators for processing analytical queries due to their massively data-parallel nature and high memory bandwidth. Recent work on designing join algorithms for CPUs has shown that carefully tuned join implementations that exploit underlying hardware can outperform naive, hardwareoblivious counterparts and provide excellent performance on modern multicore servers. However, there has been no such systematic analysis of hardware-conscious join algorithms for GPUs that systematically explores the dimensions of partitioning (partitioned versus non-partitioned joins), data location (data fitting and not fitting in GPU device memory), and access pattern (skewed versus uniform).In this paper, we present the design and implementation of a family of novel, partitioning-based GPU-join algorithms that are tuned to exploit various GPU hardware characteristics for working around the two main limitations of GPUs-limited memory capacity and slow PCIe interface. Using a thorough evaluation, we show that: i) hardware-consciousness plays a key role in GPU joins similar to CPU joins and our join algorithms can process 1 Billion tuples/second even if no data is GPU resident, ii) radix partitioning-based GPU joins that are tuned to exploit GPU hardware can substantially outperform non-partitioned hash joins, iii) hardware-conscious GPU joins can effectively overcome GPU limitations and match, or even outperform, state-of-the-art CPU joins.

show abstract

“…Many heterogeneous devices (e.g. GPU, FPGA, APU) are available and can be used in parallel in order to process database operations, where each processor is optimized for a certain application scenario (Breß et al 2014(Breß et al , 2016.…”

Section: Opportunitymentioning

confidence: 99%