Indexing multiversion databases

Jouini, Khaled; Jomier, Geneviève

doi:10.1145/1321440.1321574

Cited by 15 publications

(8 citation statements)

References 4 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Tree based indexes on temporal data include the multi-version B-tree [3], Interval B-tree [2], Interval B+-tree [5], TP-Index [30], Append-only Tree [11] Monotonic B+tree [9], and distributed multi-version B-Tree [31]. Efficiently indexing data with branched evolution is discussed by Jouni et al [15], who build efficient structures to run queries on both current and historical data. A transient versioned database introduced by Mohan et al aim to isolate reader and writer transactions, similar to our technique, at the cost of slightly outdated but a consistent snapshot for readers [21].…”

Section: Related Workmentioning

confidence: 99%

Reducing database locking contention through multi-version concurrency

Sadoghi¹,

Canim²,

Bhattacharjee³

et al. 2014

Proc. VLDB Endow.

View full text Add to dashboard Cite

In multi-version databases, updates and deletions of records by transactions require appending a new record to tables rather than performing in-place updates. This mechanism incurs non-negligible performance overhead in the presence of multiple indexes on a table, where changes need to be propagated to all indexes. Additionally, an uncommitted record update will block other active transactions from using the index to fetch the most recently committed values for the updated record. In general, in order to support snapshot isolation and/or multi-version concurrency, either each active transaction is forced to search a database temporary area (e.g., rollback segments) to fetch old values of desired records, or each transaction is forced to scan the entire table to find the older versions of the record in a multi-version database (in the absence of specialized temporal indexes).In this work, we describe a novel kV-Indirection structure to enable efficient (parallelizable) optimistic and pessimistic multi-version concurrency control by utilizing the old versions of records (at most two versions of each record) to provide direct access to the recent changes of records without the need of temporal indexes. As a result, our technique results in higher degree of concurrency by reducing the clashes between readers and writers of data and avoiding extended lock delays. We have a working prototype of our concurrency model and kV-Indirection structure in a commercial database and conducted an extensive evaluation to demonstrate the benefits of our multi-version concurrency control, and we obtained orders of magnitude speed up over the single-version concurrency control.

show abstract

Section: Related Workmentioning

confidence: 99%

Reducing database locking contention through multi-version concurrency

Sadoghi¹,

Canim²,

Bhattacharjee³

et al. 2014

Proc. VLDB Endow.

View full text Add to dashboard Cite

show abstract

“…Tree based indexes on temporal data include the multiversion B-tree [12], Interval B-tree [9], Interval B+-tree [16], TP-Index [52], Append-only Tree [30] and Monotonic B+tree [26]. Efficiently indexing data with branched evolution is discussed by Jouni et al [36], who build efficient structures to run queries on both current and historical data.…”

Section: Related Workmentioning

confidence: 99%

Making updates disk-I/O friendly using SSDs

Sadoghi¹,

Ross

Canim³

et al. 2013

Proc. VLDB Endow.

View full text Add to dashboard Cite

Multiversion databases store both current and historical data. Rows are typically annotated with timestamps representing the period when the row is/was valid. We develop novel techniques for reducing index maintenance in multiversion databases, so that indexes can be used effectively for analytical queries over current data without being a heavy burden on transaction throughput. To achieve this end, we re-design persistent index data structures in the storage hierarchy to employ an extra level of indirection. The indirection level is stored on solid state disks that can support very fast random I/Os, so that traversing the extra level of indirection incurs a relatively small overhead.The extra level of indirection dramatically reduces the number of magnetic disk I/Os that are needed for index updates, and localizes maintenance to indexes on updated attributes. Further, we batch insertions within the indirection layer in order to reduce physical disk I/Os for indexing new records. By reducing the index maintenance overhead on transactions, we enable operational data stores to create more indexes to support queries. We have developed a prototype of our indirection proposal by extending the widely used Generalized Search Tree (GiST) open-source project, which is also employed in PostgreSQL. Our working implementation demonstrates that we can significantly reduce index maintenance and/or query processing cost, by a factor of 3. For insertions of new records, our novel batching technique can save up to 90% of the insertion time.

show abstract

“…Many indexing structures [2,5,9,14,16,23,25,39] have been proposed for versioned and temporal data. A good survey of temporal indexing has appeared in [37].…”

Section: Temporal Indexing and Compressionmentioning

confidence: 99%

“…A recent paper [23] studies the problem of efficiently indexing data with "branched evolution". The main contributions here are the extension of temporal index structures to data with branched evolution and a steady state analysis that estimates the performance of the different index structures and provides guidelines for the selection of the most appropriate one.…”

Section: Temporal Indexing and Compressionmentioning

confidence: 99%

Transaction time indexing with version compression

et al. 2008

View full text Add to dashboard Cite

Immortal DB is a transaction time database system designed to enable high performance for temporal applications. It is built into a commercial database engine, Microsoft SQL Server. This paper describes how we integrated a temporal indexing technique, the TSB-tree, into Immortal DB to serve as the core access method. The TSB-tree provides high performance access and update for both current and historical data. A main challenge was integrating TSB-tree functionality while preserving original B+tree functionality, including concurrency control and recovery. We discuss the overall architecture, including our unique treatment of index terms, and practical issues such as uncommitted data and log management. Performance is a primary concern. To increase performance, versions are locally delta compressed, exploiting the commonality between adjacent versions of the same record. This technique is also applied to index terms in index pages. There is a tradeoff between query performance and storage space. We discuss optimizing performance regarding this tradeoff throughout the paper. The result of our efforts is a high-performance transaction time database system built into an RDBMS engine, which has not been achieved before. We include a thorough experimental study and analysis that confirms the very good performance that it achieves.

show abstract

Indexing multiversion databases

Cited by 15 publications

References 4 publications

Reducing database locking contention through multi-version concurrency

Reducing database locking contention through multi-version concurrency

Making updates disk-I/O friendly using SSDs

Transaction time indexing with version compression

Contact Info

Product

Resources

About