At this point, we can formally define a multiversion database:
Definition 2.6. A multiversion database is a transaction-time data- base that is partially persistent and enables efficient x/−/point queries on data items, where x is either point , range, or∗. The transaction-time instants of the data items in a multiversion database are called database versions. The versions of the multiversion database are ordered based on the commit-time ordering of the transactions. ◻
The versions of a multiversion database do not necessarily directly map to any real-time instants. In fact, using consecutive integer values for database versions has the advantage that the next version can al- ways be easily determined. Users of the system, however, often wish to query past states based on real-time instants. There are two intuitive ap- proaches for overcoming this discrepancy. In the first approach, database versions are increasing integer values, and a separate mapping between versions and real time is maintained in the database system. In the other approach, database versions are timestamps that are based on real time. In this approach, given a version v1 that was used by transaction Tv1,
it is not possible to directly determine the next version v2 used by the
next transaction Tv2, unless all the different versions are separately stored.
2.4 Representing Multiversion Data
array that maps the sequence numbers into real-time instants. Convert- ing from database versions to real time is straightforward, as the array can be directly accessed from the right offset. To convert back from real- time instants to database versions, a binary search can be used, as the real-time instants are also sorted in increasing order. We will assume that this approach is used in the algorithms presented in this dissertation.
The ordering of the database versions must be based on the commit- time ordering of transactions to ensure consistency of the data items be- tween different versions. An ordering that is based on the starting time of transactions, for example, guarantees consistency only if the transaction commit order is forced to be the same as the starting order. Because we do not wish to impose such a requirement, the data items created by a transaction must receive the commit-time version of the transaction, which may differ from the starting time of the transaction. Because the commit-time version is not known at the beginning of the transaction, ac- tive transactions must use a separate identifier to identify their updates. Following Lomet et al. [55], we assume that a transaction T is assigned a transaction identifier, denoted by id(T), when it is created. When the transaction T commits, a commit-time version, denoted by commit(T), is assigned to the transaction. The commit-time version is the version used by the database to order the data items, and users of the database sys- tem use it to query previous database states. In contrast, the transaction identifiers are internal to the database system and not seen by the users. The discrepancy between the transaction identifiers and the commit- time versions is a common challenge in all multiversion databases. Often the entries that represent the data items need to be initially stored with the transaction identifier, and later on revisited to change the transaction identifier into the commit-time version. A lazy timestamping scheme [55] initially uses the transaction identifier to store the versions and lets the transaction commit. Later, when the entries are accessed, the transaction identifiers are changed to the commit-time version of the transaction. In contrast, in an eager timestamping scheme [55], the temporary identifiers are changed as soon as the transaction commits.
The data-update model adopted by most earlier proposals for index- ing versioned data, including the model adopted for the multiversion B+-tree (MVBT) of Becker et al. [8] and the multiversion access struc-
ture (MVAS) of Varman and Verma [92], assumes that each update action creates a new version of the database, so that the versions are unique across all versions of all data items. This model is not adequate for mod- ern transactional applications, because data items within a single trans- action should be assigned the same version. Following Salzberg et al. [76]
and Lomet et al. [55], we assume a multi-action-transaction approach in which all data-item versions created by a transaction T get the same commit-time version commit(T), unless the transaction updates a data item more than once, in which case only the final data-item version gets the commit-time version and remains in the database.
We will now formalize the notion of data items in a multiversion data- base. Remember from Section 2.1 that the logical database consists of tuples of the form (k, w), where k is the key of the data item, and w the value associated with the item. Because the data items need an additional version attribute—the life span #–v (Definition 2.1)—the data item model used in snapshot databases is not sufficient for multiversion databases.
Definition 2.7. A multiversion data item in a multiversion database is a tuple of the form(k, #–v, w), where k and w correspond to the key and value of the snapshot data items of the logical database, and #–v is the life span of the multiversion data item. The life span #–v is either [v1,∞), if
the data item has not been deleted; or [v1, v2), if the data item has been
deleted. The version v1is the commit-time version of the transaction that
inserted the data item, and version v2 is the commit-time version of the
transaction that deleted the data item. ◻
Definition 2.8. The updates performed by an active updating trans- action T are called pending updates, and they are represented by tuples of the form(k, id(T), δ), where k is the key, id(T) is the transaction iden- tifier, and δ tells whether the update is an insertion or a deletion. In the case of an insertion, δ= w, the value of the data item; and in the case of a deletion, δ= , a special marker value used to denote item deletion. ◻
In the logical database model, the pending updates created by a trans- action T are incorporated into the database immediately when T com- mits, either by inserting new data items or by updating the existing data items. Depending on the implementation of the multiversion database, the entries that are used to store the pending updates may exist for some time after the transaction has committed. In this situation, the data-item entries in the database may differ from the data items of the logical data- base, and the database management system must be prepared to apply the effects of the pending updates on the existing data items during the execution of database queries.
With this definition, the logical data items can be identified by the key-life-span pair (k, #–v), or (k, [v1, v2)). However, we can also uniquely
identify a data item using only the creation time of the data item, that is, the version v1. In this dissertation, we will use the pair(k, v1) to uniquely