PUSHtap: PIM-based In-Memory HTAP with Unified Data Storage Format
Fuente:
arXiv
Saved in:
| Main Authors: | , , , , , , , |
|---|---|
| Format: | Preprint |
| Published: |
2025
|
| Subjects: | |
| Online Access: | |
| Tags: |
Add Tag
No Tags, Be the first to tag this record!
|
| _version_ | 1866913974571761664 |
|---|---|
| author | Zhao, Yilong Gao, Mingyu Zhang, Huanchen Liu, Fangxin Chen, Gongye Xian, He Guan, Haibing Jiang, Li |
| author_facet | Zhao, Yilong Gao, Mingyu Zhang, Huanchen Liu, Fangxin Chen, Gongye Xian, He Guan, Haibing Jiang, Li |
| contents | Hybrid transaction/analytical processing (HTAP) is an emerging database paradigm that supports both online transaction processing (OLTP) and online analytical processing (OLAP) workloads. Computing-intensive OLTP operations, involving row-wise data manipulation, are suitable for row-store format. In contrast, memory-intensive OLAP operations, which are column-centric, benefit from column-store format. This \emph{data-format dilemma} prevents HTAP systems from concurrently achieving three design goals: performance isolation, data freshness, and workload-specific optimization. Another background technology is Processing-in-Memory (PIM), which integrates computing units (PIM units) inside DRAM memory devices to accelerate memory-intensive workloads, including OLAP.
Our key insight is to combine the interleaved CPU access and localized PIM unit access to provide two-dimensional access to address the data format contradictions inherent in HTAP. First, we propose a unified data storage format with novel data alignment and placement techniques to optimize the effective bandwidth of CPUs and PIM units and exploit the PIM's parallelism. Second, we implement the multi-version concurrency control (MVCC) essential for single-instance HTAP. Third, we extend the commercial PIM architecture to support the OLAP operations and concurrent access from PIM and CPU. Experiments show that PUSHtap can achieve 3.4\texttimes{}/4.4\texttimes{} OLAP/OLTP throughput improvement compared to multi-instance PIM-based design. |
| format | Preprint |
| id |
arxiv_https___arxiv_org_abs_2508_02309 |
| institution | arXiv |
| publishDate | 2025 |
| record_format | arxiv |
| spellingShingle | PUSHtap: PIM-based In-Memory HTAP with Unified Data Storage Format Zhao, Yilong Gao, Mingyu Zhang, Huanchen Liu, Fangxin Chen, Gongye Xian, He Guan, Haibing Jiang, Li Distributed, Parallel, and Cluster Computing Hybrid transaction/analytical processing (HTAP) is an emerging database paradigm that supports both online transaction processing (OLTP) and online analytical processing (OLAP) workloads. Computing-intensive OLTP operations, involving row-wise data manipulation, are suitable for row-store format. In contrast, memory-intensive OLAP operations, which are column-centric, benefit from column-store format. This \emph{data-format dilemma} prevents HTAP systems from concurrently achieving three design goals: performance isolation, data freshness, and workload-specific optimization. Another background technology is Processing-in-Memory (PIM), which integrates computing units (PIM units) inside DRAM memory devices to accelerate memory-intensive workloads, including OLAP. Our key insight is to combine the interleaved CPU access and localized PIM unit access to provide two-dimensional access to address the data format contradictions inherent in HTAP. First, we propose a unified data storage format with novel data alignment and placement techniques to optimize the effective bandwidth of CPUs and PIM units and exploit the PIM's parallelism. Second, we implement the multi-version concurrency control (MVCC) essential for single-instance HTAP. Third, we extend the commercial PIM architecture to support the OLAP operations and concurrent access from PIM and CPU. Experiments show that PUSHtap can achieve 3.4\texttimes{}/4.4\texttimes{} OLAP/OLTP throughput improvement compared to multi-instance PIM-based design. |
| title | PUSHtap: PIM-based In-Memory HTAP with Unified Data Storage Format |
| topic | Distributed, Parallel, and Cluster Computing |
| url | https://arxiv.org/abs/2508.02309 |