Concurrency control and recovery for multiversion database structures

Abstract

In modern database applications access to historical versions of the dataset is becoming increasingly important. Several multiversion structures with corresponding concurrency-control and recovery algorithms exist, but none of these have optimal logarithmic execution times for all actions in all situations. The time-split B + -tree by Lomet et al. (TSBT) is used in the Immortal DB database prototype, but it does not consolidate pages. The multiversion B + -tree by Becker et al. (MVBT) is an asymptotically optimal multiversion structure that guarantees logarithmic execution times for all actions, but it lacks concurrency-control algorithms.It is our plan to design and implement several multiversion index structures with full concurrency-control and ARIESbased recovery algorithms and evaluate their performance. We will experiment with using a multiversion B + -tree as a historical storage, to which the updates of committed transactions are moved one at a time from a separate B + -tree. We will also consider using an optimized R-tree to store the multiversion data as two-dimensional line segments. To evaluate these solutions, we will also implement a straightforward B + -tree based solution that stores the different versions of a data item consecutively; and a solution based on the existing time-split B + -tree. We expect that the solution that uses a multiversion B + -tree will be the most efficient.

Concurrent updating transactions on versioned data

“…Also, concurrency-control and recovery algorithms were not discussed. Our transactional extension to the MVBT, called the transactional multiversion B + -tree, or TMVBT [7,8], extends the transaction model to allow multiple updates to be applied within a single transaction. We described an efficient concurrency-control and recovery scheme that allows a single updating transaction to operate concurrently with multiple read-only transactions.…”

“…Thus, the maintenance transaction does not need to do latch-coupling. Furthermore, as explained in our TMVBT paper [7,8], readers that read inactive data do not need latch-coupling either. Therefore read-only transactions that are reading stable versions do not need latch-coupling.…”

“…Both read-only and updating transactions can use the same algorithms for querying the index structures, and we will thus use the term reader to refer to a read-only transaction or an updating transaction that is performing a query action. When a version is stable, and the reader knows it to be stable (the version was stable at the beginning of the read action), the reader can directly query for the version from the TMVBT, as explained in our TMVBT article [7,8]. In this situation, the TMVBT index can be traversed without latch-coupling, and saved paths can be used for key-range and next-key queries without having to check for page validity when relatching them.…”

“…Querying for a single key from the TMVBT (key-query-TMVBT) works exactly as explained in our TMVBT article [7,8], except that the third parameter is used to indicate whether the reader might need to read active data and must therefore use latch-coupling. In other words, if the version is known to be stable, the traversed paths in the TMVBT are known to be inactive and thus remain stable.…”

“…As an initial step, we have extended the MVBT to support multi-action transactions and designed concurrency-control algorithms that allow a single updating transaction to operate concurrently with multiple read-only transactions [7,8]. Our extension is called the transactional multiversion B + -tree, or TMVBT.…”