ARIES/IM: an efficient and high concurrency index management method using write-ahead logging

Abstract

This paper provides a comprehensive treatment of index management in transaction systems. We present a method, called ARIESIIM (A/gorlthm for Recovery and /so-/atIon Exploiting Semantics forlndex Management), for concurrency control and recovery of B + -trees. ARI ES/lM guarantees serializability and uses write-ahead logging for recovery. K supports very high concurrency and good performance by (1) treating as the lock of a key the same lock as the one on the corresponding record data in a data page (e.g., at the record level), (2) not acquiring, in the interest of permitting very high concurrency, commit duration locks on index pages even during index structure modification operations (SMOS) like page splits and page deletions, and (3) allowing retrievals, inserts, and deletes to go on concurrently with SMOS. During restart recovery, any necessary redos of index changes are always performed in a pageoriented fashion (i.e., without traversing the index tree) and, during normal processing and restart recovery, whenever possible undos are performed in a page-oriented fashion. ARIES/lM permits different granularities of locking to be supported in a flexible manner. A subset of ARIES/lM has been implemented in the 0S/2 Extended Edition Database Manager.1 Since the locking ideas of ARIES/lM have general applicability, some of them have also been implemented in SQUDS and the VM Shared File System, even though those systems use the shadow-page technique for recovery.

Concurrency Control Protocol for Parallel B-Tree Structures That Improves the Efficiency of Request Transfers and SMOs within a Node

“…MARK-OPT outperforms conventional B-tree concurrency control protocols such as the B-OPT [11] and ARIES/IM protocols [12]. However, MARK-OPT requires three sequential messages for any redirection between PEs.…”

“…In the B-link [37], [38] and ARIES/IM [12] algorithms, access-path errors can also occur. In the B-link algorithm, such errors occur because neither readers nor updaters acquire the latch on only one node at a time.…”

“…It would be possible to adapt the techniques used in ARIES/IM [12] for recovery from system failures. Viable recovery strategies for the B-link algorithms have also been proposed [43].…”

“…Examples are the INC-OPT [9] and MARK-OPT protocols [10], which are suited to parallel B-trees on sharednothing parallel machines. These protocols outperform conventional B-tree concurrency control protocols such as the B-OPT [11] and ARIES/IM protocols [12]. However, the performance of these protocols does not scale well with system size, because they may involve extensive high-cost network communication.…”

“…We then measured the system throughput as a function of system size. Experimental results indicated that both LCFB and LCFB-link are effective and scalable, with LCFB-link being even more effective for higher up- † We implemented ARIES/IM based on [12], but omitted its recovery mechanism because we do not focus on recovery in this paper.…”