Multi-version indexing and modern hardware technologies

Riegger, Christian; Vinçon, Tobias; Petrov, Ilia

doi:10.1145/3151759.3151779

Cited by 2 publications

(3 citation statements)

References 10 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…MV-IDX [9] maintains a virtual identifier for each tuple and data nodes for each version as an indirection layer. With Snapshot Isolation Append Storage (SIAS) [10] write amplification on base tables is reduced in comparison to HOT, but index management operations can cause a high write amplification and base table nodes are still required for visibility-checking [20]. LSM-Trees [17] reduce write amplification due to collecting modifications in main memory components, but there is no concept for managing tuple-versions and perform an index-only visibility-check [20].…”

Section: Related Workmentioning

confidence: 99%

“…With Snapshot Isolation Append Storage (SIAS) [10] write amplification on base tables is reduced in comparison to HOT, but index management operations can cause a high write amplification and base table nodes are still required for visibility-checking [20]. LSM-Trees [17] reduce write amplification due to collecting modifications in main memory components, but there is no concept for managing tuple-versions and perform an index-only visibility-check [20]. Time-Split B-Trees [15] and Multiversion B-Trees [5] are able to separate index records of old tuple-versions from current dataset and to perform an index-only visibility-check, but maintenance operations are complex and can cause a high write amplification of index nodes [20].…”

Section: Related Workmentioning

confidence: 99%

“…LSM-Trees [17] reduce write amplification due to collecting modifications in main memory components, but there is no concept for managing tuple-versions and perform an index-only visibility-check [20]. Time-Split B-Trees [15] and Multiversion B-Trees [5] are able to separate index records of old tuple-versions from current dataset and to perform an index-only visibility-check, but maintenance operations are complex and can cause a high write amplification of index nodes [20].…”

Section: Related Workmentioning

confidence: 99%

See 2 more Smart Citations

MV-PBT: Multi-Version Index for Large Datasets and HTAP Workloads

Riegger,

Vincon,

Gottstein

et al. 2019

Preprint

Self Cite

View full text Add to dashboard Cite

Modern mixed (HTAP) workloads execute fast update-transactions and long-running analytical queries on the same dataset and system. In multi-version (MVCC) systems, such workloads result in many short-lived versions and long version-chains as well as in increased and frequent maintenance overhead.Consequently, the index pressure increases significantly. Firstly, the frequent modifications cause frequent creation of new versions, yielding a surge in index maintenance overhead. Secondly and more importantly, index-scans incur extra I/O overhead to determine, which of the resulting tuple-versions are visible to the executing transaction (visibility-check) as current designs only store version/timestamp information in the base table -not in the index. Such index-only visibility-check is critical for HTAP workloads on large datasets.In this paper we propose the Multi-Version Partitioned B-Tree (MV-PBT) as a version-aware index structure, supporting indexonly visibility checks and flash-friendly I/O patterns. The experimental evaluation indicates a 2x improvement for analytical queries and 15% higher transactional throughput under HTAP workloads (CH-Benchmark). MV-PBT offers 40% higher transactional throughput compared to WiredTiger's LSM-Tree implementation under YCSB.

show abstract

Section: Related Workmentioning

confidence: 99%