In recent work, it has been shown that NVIDIA's ray tracing cores on RTX video cards can be exploited to realize hardware-accelerated lookups for GPU-resident database indexes. This is done by materializing all keys as triangles in a 3D scene. Lookups are performed by firing rays into the scene and utilizing the built-in index structure to detect collisions with triangles in a hardware-accelerated fashion. While this approach, called RTIndeX (or RX for short), is indeed promising, it currently suffers from three limitations: (1) significant memory overhead per key, (2) slow range lookups, and (3) poor updateability. In this work, we show that all three problems can be tackled by a single design change: Generalizing RX to become a coarse-granular index cgRX, which no longer indexes individual keys, but key buckets. We show that representing buckets in 3D space such that the lookup of a key is performed both correctly and efficiently is highly nontrivial and requires a careful orchestration of positioning triangles and firing rays in a specific sequence. Our experimental evaluation shows that cgRX offers the most bang for the buck(et) by providing a up to 6.9 x higher ratio of throughput to memory footprint than comparable baselines (that support range lookups). At the same time, cgRX improves the range-lookup performance over RX by up to 15 x and offers practical updatability that is up to 5.6x faster than rebuilding from scratch

Data processing in climate research regularly involves analyzing massive datasets, particularly atmospheric model data that spans around the globe. A typical task is to align this model data with measurement series for validation or trend analysis. Unfortunately, for this task, traditional join operations prove extremely inefficient: They load vast amounts of data into main-memory only to discard most of it afterwards due to the high selectivity typically occurring in these joins.To address this issue, we introduce a new operation we call the Gather Join. This method optimizes highly selective join operations by directly loading only the portions of the larger dataset that are actually relevant to the join result. We achieve this by exploiting the spatio-temporal information that is typically encoded in the file structure of the dataset. We present three different strategies for realizing the Gather Join, where we integrate the operation in the cluster computing framework Apache Spark to handle the multidimensional atmospheric datasets stored in NetCDF files. Our results show that the Gather Join outperforms the traditional join operation by a factor of up to 135x for the tested datasets. Increasing the selectivity of the join query is expected to further enhance these performance gains.

In main-memory column stores, column scans are one of the base operations performed when answering analytical queries. Typically, one or multiple columns must be filtered with respect to the given query predicate, which, by default, involves inspecting all data of the involved columns. To reduce the amount of data to scan, there exist essentially two strategies: (1) Create a coarse-granular index on the column, then use it for early pruning during each scan. While creating such an index is relatively lightweight, unfortunately, accessing the relevant portions of the column through the index causes unpleasant overhead during scanning. (2) Create materialized views that contain semantic portions of the column and filter on these. While this enables fast scans, unfortunately, it requires physical copying and causes significant space overhead. To break this trade-off, in the following, we propose a view-based strategy that avoids any physical copying of column data while providing optimal scan performance. We achieve this by utilizing tools of the virtual memory subsystem provided by the OS: On the lowest level, we materialize all columns within physical main memory. On top of that, we allow the creation of arbitrarily many partial views in virtual memory that map to subsets of the physical columns having certain properties of interest. Creation, maintenance, and usage of these partial virtual views happens fully adaptively as a side-product of scan-based query processing.

Research projects in the database community are often evaluated based on experimental results. A typical evaluation setup looks as follows: Multiple methods to compare with each other are embedded in a single shared benchmarking codebase. In this codebase, all methods execute an identical workload to collect the individual execution times. This seems reasonable: Since the only difference between individual test runs are the methods themselves, any observed time difference can be attributed to these methods. Also, such a benchmarking codebase can be used for gradual optimization: If one method runs slowly, its code can be optimized and re-evaluated. If its performance improves, this improvement can be attributed to the particular optimization.

Data management on GPUs has become increasingly relevant due to a tremendous rise in processing power and available GPU memory. Similar to main-memory systems, there is a need for performant GPU-resident index structures to speed up query processing. Unfortunately, mapping indexes efficiently to the highly parallel and hard-to-program hardware is challenging and often fails to yield the desired performance and flexibility. Instead of proposing yet another hand-tailored index, we investigate whether we can exploit an indexing mechanism that is already built into modern GPUs: The raytracing hardware accelerator provided by NVIDIA RTX GPUs. To do so, we re-phrase the database indexing problem as a raytracing problem, where we express the dataset to be indexed as objects in a 3D scene, and point/range lookups as rays across the scene. In this combination, coined RX in the following, lookups are performed as intersection tests in hardware by dedicated raytracing cores. To analyze the pros, cons, and usefulness of the raytracing pipeline for database indexing, we carefully evaluate RX along fourteen dimensions and demonstrate its competitiveness and potential in a large variety of situations.

Research in atmospheric physics, meteorology, and weather prediction requires the processing of very large multi-dimensional observational or modeled datasets on a daily basis. One of the numerous existing array engines looks like the natural choice for this task. Interestingly, the actual data analysis situation in the community looks surprisingly different: Researchers often process their data manually using hand-written Python or Julia scripts that directly operate on the raw data files. This results in poor performance due to a lack of data-driven optimizations, as well as poor scalability due to being restricted to a single physical machine. Reasons for this trend lie in the high complexity and upfront effort associated with any specialized system: Distributed large-scale engines must be set up carefully and data must be be converted/transferred into the the proprietary representation of the system. The users, who are typically not computer scientists or data management experts, must adopt and use a specialized multi-dimensional query language to formulate their analytical tasks.

The volume of data that is processed and produced by modern data-intensive applications is constantly increasing. Of course, along with the volume, the interest in analyzing and interpreting this data increases as well. As a consequence, more and more DBMSs and processing frameworks are specialized towards the efficient execution of long-running, read-only analytical queries. Unfortunately, to enable analysis, the data first has to be moved from the source application to the analytics tool via a lengthy ETL process, which increases the runtime and complexity of the analysis pipeline. In this work, we advocate to simply skip ETL altogether. With AnyOLAP, we can perform online analysis of data directly within the source application and while it is running. In the proposed demonstration, the audience will get the chance to put AnyOLAP to the test on a set of data-intensive applications that are supposed to be analyzed while they are up and running. As the entire analysis pipeline of AnyOLAP will be exposed to the audience in form of live and interactive visualizations, users will be able to experience the benefits of true online analysis firsthand.