The art of computer programming, volume 3: (2nd ed.) sorting and searching
The art of computer programming, volume 3: (2nd ed.) sorting and searching
Efficient locking for concurrent operations on B-trees
ACM Transactions on Database Systems (TODS)
A symmetric concurrent B-tree algorithm
ACM '86 Proceedings of 1986 ACM Fall joint computer conference
ACM Computing Surveys (CSUR)
Real-time index concurrency control
ACM SIGMOD Record
Restructuring the concurrent B+-tree with non-blocked search operations
Information Sciences—Informatics and Computer Science: An International Journal
Concurrency and recovery for index trees
The VLDB Journal — The International Journal on Very Large Data Bases
Concurrency control and recovery for balanced B-link trees
The VLDB Journal — The International Journal on Very Large Data Bases
B-tree concurrency control and recovery in page-server database systems
ACM Transactions on Database Systems (TODS)
Concurrency control in B+-trees databases using preparatory operations
VLDB '85 Proceedings of the 11th international conference on Very Large Data Bases - Volume 11
A dichromatic framework for balanced trees
SFCS '78 Proceedings of the 19th Annual Symposium on Foundations of Computer Science
Concurrent updating transactions on versioned data
IDEAS '09 Proceedings of the 2009 International Database Engineering & Applications Symposium
A survey of B-tree locking techniques
ACM Transactions on Database Systems (TODS)
Hi-index | 0.00 |
For concurrent database access, the B-link tree is a well-suited data structure; this paper describes a modification of the B-link tree to reduce the expense associated with splits and merges while moving down the tree. The modification is keyed to the concept of stability in each B-link tree node. Being stable amounts to a node having somewhere between a small percentage more than the minimum number and a small percentage fewer than the maximum number of child links such a node may have. When additions or deletions lead to instability in a node, either an overflow or underflow is considered to be imminent. Upon visiting a node, an update process will determine if the node's content is at the B-link maximum or minimum; if this is the case, the process performs whatever split or merge and redistribution operations necessary to make this and any related node stable. As a result of this action, there will always be room for an overflowed child to insert an entry in its parent and likewise room for an underflowed child to remove an entry from its parent; backward propagation of insertions or deletions further up the Blink tree are thus eliminated, improving the possible degree of concurrency. Further, no node will be left without a parent, obviating horizontal traversal within the tree in all but highly infrequent process scheduling scenarios.