HackerPapers

arXiv:2109.14349cs.DB

Relational Memory: Native In-Memory Accesses on Rows and Columns

Shahin Roozkhosh, Denis Hoornaert, Ju Hyoung Mun, Tarikul Islam Papon, Ahmed Sanaullah, Ulrich Drepper, Renato Mancuso, Manos Athanassoulis

Abstract

Analytical database systems are typically designed to use a column-first data layout to access only the desired fields. On the other hand, storing data row-first works great for accessing, inserting, or updating entire rows. Transforming rows to columns at runtime is expensive, hence, many analytical systems ingest data in row-first form and transform it in the background to columns to facilitate future analytical queries. How will this design change if we can always efficiently access only the desired set of columns? To address this question, we present a radically new approach to data transformation from rows to columns. We build upon recent advancements in embedded platforms with re-programmable logic to design native in-memory access on rows and columns. Our approach, termed Relational Memory, relies on an FPGA- based accelerator that sits between the CPU and main memory and transparently transforms base data to any group of columns with minimal overhead at runtime. This design allows accessing any group of columns as if it already exists in memory. We implement and deploy Relational Memory in real hardware, and we show that we can access the desired columns up to 1.63x faster than accessing them from their row-wise counterpart, while matching the performance of a pure columnar access for low projectivity, and outperforming it by up to 1.87x as projectivity (and tuple re-construction cost) increases. Moreover, our approach can be easily extended to support offloading of a number of operations to hardware, e.g., selection, group by, aggregation, and joins, having the potential to vastly simplify the software logic and accelerate the query execution.

arXiv comments
Journal reference
DOI
Subjects
cs.DBDatabases cs.ARHardware Architecture

On Hacker News

Linked by 2 identifiable commenters in 5 comments across 5 threads, from Oct 2021 to Dec 2023. Found in 2 HN submissions from Oct 2021 to Oct 2022. Open submission discussions.

Comments linking this paper, per year.

Discussed in comments5 threads

    • Red Hat supported a lot of research into this and there's some really interesting stuff, but nothing that is very compelling for commercial use. What uses do you have in mind? To my mind the more interesting stuff are the PCIe FPGA boards like…

      rwmjView on HNParent context

    • But the bet was customers would buy Xeons with an FPGA block that would "do magic". What magic it would do and how you'd program it in a sane way was never specified in great detail. In any case for those that really want this it turns out you can put the FPGA on the end of a…

      rwmjView on HNParent context

  1. Fast memcpy, a system design 1 comment
    • Something similar in this paper, putting an FPGA between the processor and DRAM so you can arbitrarily remap bits of it: https://arxiv.org/abs/2109.14349

      rwmjView on HNParent context

    • This paper is a slightly different approach to a similar problem: https://arxiv.org/abs/2109.14349 They are inserting an FPGA fabric between standard CPUs and standard DDR RAM, allowing the memory to be reorganized on the fly. For example you can flip columns and rows in arrays…

      rwmjView on HNParent context

    • "Analytical database systems are typically designed to use a column-first data layout that maps better to analytical queries of access patterns. This choice is premised on the assumption that storing data in a row-first format leads to accessing unwanted fields; moreover…

      belterView on HNParent context

Submitted to Hacker News

Connected through shared HN threads, not inferred similarity or a recommendation.