<?xml version="1.0" encoding="UTF-8"?><feed xmlns="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
<title>P290 - BTW2019 - Datenbanksysteme für Business, Technologie und Web - Workshopband</title>
<link href="http://dl.gi.de/handle/20.500.12116/21574" rel="alternate"/>
<subtitle/>
<id>http://dl.gi.de/handle/20.500.12116/21574</id>
<updated>2026-07-23T10:52:04Z</updated>
<dc:date>2026-07-23T10:52:04Z</dc:date>
<entry>
<title>Workload-Driven Data Placement for GPU-Accelerated Database Management Systems</title>
<link href="http://dl.gi.de/handle/20.500.12116/21829" rel="alternate"/>
<author>
<name>Schmidt, Christopher</name>
</author>
<author>
<name>Uflacker, Matthias</name>
</author>
<id>http://dl.gi.de/handle/20.500.12116/21829</id>
<updated>2019-04-17T00:47:35Z</updated>
<published>2019-01-01T00:00:00Z</published>
<summary type="text">Workload-Driven Data Placement for GPU-Accelerated Database Management Systems
Schmidt, Christopher; Uflacker, Matthias
Meyer, Holger; Ritter, Norbert; Thor, Andreas; Nicklas, Daniela; Heuer, Andreas; Klettke, Meike
An increase in the memory capacity of current Graphics Processing Unit (GPU) generations and advances in multi-GPU systems enables a large unified GPU memory space to be utilized by modern coprocessor-accelerated Database Management System (DBMS). We take this as an opportunity to revisit the idea of using GPU memory as a hot cache for the DBMS. In particular, we focus on the data placement for the hot cache. Based on previous approaches and their shortcomings, we present a new workload-driven data placement for a GPU-accelerated DBMS. Lastly, we outline how we aim to implement and evaluate our proposed approach by comparing it to existing data placement approaches in future work.
</summary>
<dc:date>2019-01-01T00:00:00Z</dc:date>
</entry>
<entry>
<title>Workshop Digitale Lehre im Fach Datenbanken</title>
<link href="http://dl.gi.de/handle/20.500.12116/21830" rel="alternate"/>
<author>
<name>Rakow, Thomas C.</name>
</author>
<author>
<name>Faeskorn-Woyke, Heide</name>
</author>
<id>http://dl.gi.de/handle/20.500.12116/21830</id>
<updated>2019-04-17T00:47:34Z</updated>
<published>2019-01-01T00:00:00Z</published>
<summary type="text">Workshop Digitale Lehre im Fach Datenbanken
Rakow, Thomas C.; Faeskorn-Woyke, Heide
Meyer, Holger; Ritter, Norbert; Thor, Andreas; Nicklas, Daniela; Heuer, Andreas; Klettke, Meike
</summary>
<dc:date>2019-01-01T00:00:00Z</dc:date>
</entry>
<entry>
<title>Query Planning for Transactional Stream Processing on Heterogeneous Hardware: Opportunities and Limitations</title>
<link href="http://dl.gi.de/handle/20.500.12116/21826" rel="alternate"/>
<author>
<name>Götze, Philipp</name>
</author>
<author>
<name>Pohl, Constantin</name>
</author>
<author>
<name>Sattler, Kai-Uwe</name>
</author>
<id>http://dl.gi.de/handle/20.500.12116/21826</id>
<updated>2019-04-17T00:47:35Z</updated>
<published>2019-01-01T00:00:00Z</published>
<summary type="text">Query Planning for Transactional Stream Processing on Heterogeneous Hardware: Opportunities and Limitations
Götze, Philipp; Pohl, Constantin; Sattler, Kai-Uwe
Meyer, Holger; Ritter, Norbert; Thor, Andreas; Nicklas, Daniela; Heuer, Andreas; Klettke, Meike
In a heterogeneous hardware landscape consisting of various processing units and memory types, it is crucial to decide which device should be used when running a query. There is already a lot of research done for placement decisions on CPUs, coprocessors, GPUs, or FPGAs. However, those decisions can be further extended for the various types of memory within the same layer of the memory hierarchy. For storage, a division between SSDs, HDDs or even NVM is possible, whereas for main memory types like DDR4 and HBM exist. In this paper, we focus on query planning for the transactional stream processing model. We give an overview of several techniques and necessary parameters when optimizing a stateful query for various memory types, outlined with chosen experimental measurements to support our claims.
</summary>
<dc:date>2019-01-01T00:00:00Z</dc:date>
</entry>
<entry>
<title>Skew-resilient Query Processing for Fast Networks</title>
<link href="http://dl.gi.de/handle/20.500.12116/21827" rel="alternate"/>
<author>
<name>Ziegler, Tobias</name>
</author>
<author>
<name>Binnig, Carsten</name>
</author>
<author>
<name>Röhm, Uwe</name>
</author>
<id>http://dl.gi.de/handle/20.500.12116/21827</id>
<updated>2019-04-17T00:47:32Z</updated>
<published>2019-01-01T00:00:00Z</published>
<summary type="text">Skew-resilient Query Processing for Fast Networks
Ziegler, Tobias; Binnig, Carsten; Röhm, Uwe
Meyer, Holger; Ritter, Norbert; Thor, Andreas; Nicklas, Daniela; Heuer, Andreas; Klettke, Meike
Motivation: Scalable distributed in-memory databases are at the core of data-intensive computation. Although scaling-out solutions help to handle large amounts of data, more nodes do not necessarily lead to improved query performance. In fact, recent papers have shown that performance can even degrade when scaling out due to higher communication overhead (e.g., shuffling data across nodes) and limited bandwidth [Rö15]. Thus, current distributed database systems are built with the assumption that the network is the major bottleneck [BH13] and should be avoided at all costs. In recent years, high-speed networks (e.g., InfiniBand (IB)) with a bandwidth close to the local memory bus [Bi16] have become economically viable. These network technologies provide Remote Direct Memory Access (RDMA) to allow direct memory access to a remote host and also reduce the latency of data transfer through bypassing the remote’s CPU [In17, Gr10]. Therefore, the assumption that the network is the bottleneck no longer holds. Consequently, recent research has focused on integrating RDMA-enabled high-speed networks into existing database systems designed along a Shared-Nothing Architecture (SN) [Rö16, LYB17]. This architecture co-locates computation and data to reduce the communication overhead in a cluster. Although combining a SN with IB’s higher network bandwidth enables scalability to a certain extent, this approach fails if the data or workload is skewed and cannot be evenly partitioned. The root cause is that classical query execution schemes assume that each partition is processed by one node. Since nodes with larger partitions must process more data, they may become a bottleneck and hinder the overall scalability. In consequence, only utilizing the higher bandwidth without adapting the database architecture and query execution, does not automatically lead to improved scalability [Bi16]. Contributions: In this paper, we present a new approach to execute distributed queries on fast networks with RDMA. Our main contribution is a novel execution strategy, which enables collaborative query processing by remote work stealing to mitigate skew, as this is a common issues that hinders scalable query execution [WDJ91, Ly88]. Moreover, we implement this execution strategy in our prototype engine I-Store and show that it introduces almost no overhead to handle skew.
</summary>
<dc:date>2019-01-01T00:00:00Z</dc:date>
</entry>
</feed>
