<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving DTD v1.0 20120330//EN" "JATS-journalarchiving.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:ali="http://www.niso.org/schemas/ali/1.0">
  <front>
    <article-meta>
      <title-group>
        <article-title>Use of Graphics Processors in Data Compression Algorithms</article-title>
      </title-group>
      <contrib-group content-type="author">
        <contrib id="person-4df579562a65bbfd1298b17b7546d630" contrib-type="person" equal-contrib="no" corresp="no" deceased="no">
          <name>
            <surname>Uchkunovna</surname>
            <given-names>Khalilova Shahnoza</given-names>
          </name>
          <email>Uchkunovna@gmail.co</email>
          <xref ref-type="aff" rid="aff-1" />
        </contrib>
      </contrib-group>
      <aff id="aff-1">
        <country>Uzbekistan</country>
      </aff>
      <history>
        <date date-type="received" iso-8601-date="2022-04-12">
          <day>12</day>
          <month>04</month>
          <year>2022</year>
        </date>
      </history>
      <abstract />
    </article-meta>
  </front>
  <body id="body">
    <sec id="heading-c322ff00205c5752144bd497258de9b0">
      <title>
        <bold id="_bold-8">Introduction</bold>
      </title>
      <p id="_paragraph-9">Graphics processors (GPUs) have become an emerging and powerful co-processor for many applications including scientiﬁc computing [1] and databases [2]. The new-generation GPU has an order of magnitude higher memory bandwidth and higher GFLOPS (Giga FLoating point Operations Per Second) than the multi-core CPU. For example, an NVIDIA GTX 280 card contains 240 cores with a peak performance of 933 GLOPS and 141.7 GB/s memory bandwidth. Despite of the superb hardware performance, GPU co-processing requires data transfer between the main memory and the GPU memory via a low bandwidth PCI-E bus, e.g., with theoretical peak bandwidths of 4 and 8 GB/s on 16-lane PCIE v1.0 and v2.0, respectively. As a result, previous studies [3] show that such data transfer can contribute to 15–90% of the total time in relational query co-processing. Query co-processing performance can be further improved if such data transfer time is reduced. Compression has been long considered as an effec-tive means to reduce the data footprint in databases, especially for column-oriented databases [4, 5]. In this paper, we investigate how compression can reduce the data transfer time and improve the overall query co-processing performance on column oriented databases. Database compression has been extensively studied in column oriented databases (e.g., MonetDB/x100 [6] and C-store). Most of these systems adopt lightweight compression schemes, such as dictionary encoding, instead of more sophisticated compression algorithms such as gzip. With the lightweight compression schemes, column-oriented databases efﬁciently utilize vectorized executions, processing data tuples bulk-at-a-time or vector/array-at-a-time via (de)compressing multiple tuples simultaneously [7]. However, due to the poor decompression performance on CPUs, current systems often use a single compression scheme, even though cascaded compression (i.e., applying multiple lightweight compression schemes one after another on a data set) is potentially more effective. For example, Harizopoulos et al. showed that the column-oriented DBMS with the combination of two lightweight compression schemes hardly outperforms that with a single compression scheme. Given the superb memory bandwidth and GLFOPS of the GPU, we should revisit the commonly used lightweight compression schemes as well as their combinations on the GPU. The reduced data footprint by cascaded compression in GPU co-processing can potentially compensate the computational overhead.</p>
    </sec>
    <sec id="heading-fef3ece474520a51062f40631dd22ca6">
      <title>
        <bold id="_bold-9">GPU-based Data Processing</bold>
      </title>
      <p id="_paragraph-11">Due to the massive parallelism, GPUs have demonstrated signiﬁcant speedup over CPUs on various query processing tasks, including sorting [8], index search, join [9], selection and aggregation. In addition to relational query processing, GPUs have been applied to other data management tasks, for example, data mining, spatial databases, MapReduce, scatter/gather and similarity joins. GPU-based data compression has been applied on the inverted index in information retrieval. In comparison, we not only investigate individual GPU-accelerated compression schemes for column-oriented databases, but also the combinations of different schemes for reducing the overhead of data transfer between the main memory and the GPU memory.</p>
    </sec>
    <sec id="heading-bb8c3574e80f1edbfd9b9178545134b4">
      <title>
        <bold id="_bold-10">Database Compression</bold>
      </title>
      <p id="_paragraph-13">Compression is an effective method to reduce the data storage and to improve query processing performance. In disk-based databases, compression algorithms are typically computation-intensive, and they trade more computation for better compression ratios, since disk accesses are far slower than the CPU. Because the compression algorithms are complex, the compressed data are often required to be fully decompressed for query processing.</p>
      <p id="_paragraph-14">As the price of main memory drops, machines tend to have large amounts of main memory. Moreover, column-oriented databases allow query processing to read only the required columns, instead of the entire rows. Disk I/Os become less signiﬁcant for such scenarios. As a result, studies on compression techniques in columnoriented databases [10] have focused on lightweight schemes such as Run-Length-Encoding (RLE) that balance between compression ratio and computational overhead. With these lightweight compression schemes, most queries can be evaluated without decompression. In addition, lightweight compression can easily be vectorized. Although the combination of lightweight schemes is undesirable on CPU-based column-oriented databases due to the computation overhead, the high memory bandwidth and the high computation capability of GPUs make combinations of multiple compression schemes practical. Moreover, compression can beneﬁt GPU query co-processing by signiﬁcantly reducing the overhead of data transfer between the main memory and the GPU memory.</p>
    </sec>
    <sec id="heading-ba53cadb96de8da3576729fe1954fe8a">
      <title>
        <bold id="_bold-11">CASCADED </bold>
        <bold id="_bold-12">compression</bold>
      </title>
      <p id="_paragraph-16">Based on the GPU-accelerated, individual compression schemes, we further investigate the combinations of multiple compression schemes (namely cascaded compression) on the GPU. The core beneﬁt of cascaded compression is to further reduce the data size by applying more than one lightweight scheme. While cascaded compression remains of low interest on the CPU, it appears promising to further alleviate the performance issues in data transfer and query processing on the GPU.</p>
      <p id="_paragraph-17">The main question in cascaded compression is, given a number of individual compression schemes and a data set (a column), how do we ﬁnd a feasible and good combination of the individual schemes (compression plan)? Our answer to this question is through a compression planner together with a cost model. In this section, we ﬁrst present our compression planner, and then describe our cost model for GPU-based compression schemes.</p>
    </sec>
    <sec id="heading-f616c09f06a6875b16017d56417f9def">
      <title>
        <bold id="_bold-13">Conclusion</bold>
      </title>
      <p id="_paragraph-19">GPU co-processing has demonstrated signiﬁcant performance speedups on main memory databases. This paper further improves the performance of such co-processing with database compression techniques. Compression not only improves the query processing performance, but also alleviates the overhead of data transfer on the low-bandwidth PCI-E bus in GPU co-processing.</p>
    </sec>
  </body>
  <back />
</article>