[Database] Hierarchy of database elements, multi-granularity locking under tree structure, and correct handling of phantoms

Database element hierarchy

​专栏content：

• Handwritten database toadb
  This column mainly introduces how to develop from scratch, the steps of development, the principles involved in the development process, problems encountered, etc., so that everyone can keep up. And can be developed together so that everyone who needs it can become a participant.
  This column will be updated regularly, and the corresponding code will also be updated regularly. The code at each stage will be tagged to facilitate learning at each stage.

​Open source contribution：

• toadb open source library

Personal homepage:My homepage
Manage community: Open source database
Motto: When the sky is strong, a gentleman will strive to strive for self-improvement; when the terrain is weak, a gentleman will carry his wealth with kindness.

Preface

With the rapid development of information technology, data has penetrated into various fields and become one of the most important assets of modern society. In this era of big data, database theory plays a vital role in data management, storage and processing. However, many readers may be confused about database theory and do not know how to choose a suitable database, how to design an effective database structure, and how to process and manage large amounts of data. Therefore, this column aims to provide readers with a comprehensive and in-depth guide to database theory to help them better understand and apply database technology.

Database theory is the study of how to effectively manage, store and retrieve data. In the modern information society, the amount of data is growing exponentially, and how to efficiently process and manage this data has become an important issue. At the same time, with the continuous development of emerging technologies such as cloud computing, the Internet of Things, and big data, the importance of database theory has become increasingly prominent.

Therefore, the sharing of this column hopes to improve everyone's knowledge and understanding of database theory and help interested friends.

Overview

We have shared different blocking modes earlier. This article mainly introduces the database elements, that is, the locked objects. It may appear in a tree structure. At this time, two problems will arise:

1. The first type of tree structure encountered is a hierarchical structure that can be blocked. This article describes how to allow locks on both large elements, such as tables, and smaller elements contained within them, such as blocks or tuples.

2. Another important type of level in a concurrency control system is that the structure itself is a tree, such as a B-tree index. If it is locked as a database element, the performance in blocking mode will be very low, and we need a new method;

How to solve and optimize these two types of problems will be described in detail below.

Multi-granularity locks

Database elements are not specially explained in the previous introduction, because they are different in the implementation of different databases. There are entire tables, data blocks, and table tuples. Some applications benefit from small database elements, while others perform better with larger database elements.

If a lock is provided for each tuple, then for bank account business, no matter what kind of account collection there is, it can be updated at the same time, but it is not worth paying a particularly large price for such a fine-grained lock.

As a comparison, consider a database of documents that may be edited from time to time, but a big data transaction will retrieve the entire document. If the entire document is treated as a database element, simultaneous editing or viewing of the document will not be possible.

It seems that both large-granularity locks and small-granularity locks need to be used, which can make some application updates more efficient. However, acquiring a shared lock on a table in order to compute an aggregation on the table while having an exclusive lock on a single tuple may result in non-serializable behavior.

Let's take a look at some extended lock modes.

warning lock

The method to solve the problem of managing different granularities extends to a new type of lock, warning lock, also called intention lock. As its name suggests, it is an alert only and is useful when database elements form a nested or hierarchical structure.

As shown in the figure above, you can see three levels: table, block, and tuple;

• The table is the largest blockable element;
• Each table is composed of one or more blocks; each block stores tuples of the table;
• Each block contains one or more tuples;

The rules for managing locks at the database element level consist of alert protocols, which include both ordinary locks and alert locks.
The warning lock is represented by adding the prefix I before the blocking mode of ordinary locks S and X. For example, IS represents the intention to obtain a shared lock on the child element.

Alert Protocol Rules

1. To add an S or X lock to any element, we must start from the root of the hierarchy;
2. If you are at the position of the element to be blocked, you do not need to look further to request the S or X lock on the element.
3. If the element you want to lock is located in the middle or lower part of the hierarchy, first add a warning lock on this node; that is, if you want to obtain a shared lock on its child elements, first request the IS lock on the node. , if you want to obtain the exclusive lock of its child node, first request the IX lock on the node, and then repeat this step until the required node is reached.

Warning Lock Compatibility Matrix

For a clearer understanding of the warning lock, here is its compatibility matrix.

	IS	IX	S	X
IS	yes	yes	yes	no
IX	yes	yes	no	no
S	yes	no	yes	no
X	no	no	no	no

Correct handling of illusions and insertions

Sometimes things can go wrong when a transaction creates a new child element of a lockable element. The problem is that you can only block existing objects. There is no simple way to block database elements that do not exist but may be inserted later. Let's look at an example below.

Transaction T1, execute select sum(salary) from employ where egroup = 2;
Transaction T2, insert a new tuple into the group with egroup=2;

When T1 is executed, IS lock will be added to the table, and S lock will be added to the tuple of egroup=2;
When T2 is executed, it seems that no lock is needed , but it makes the result of T1 incorrect.

Because for T1, there is a phantom tuple, which is not locked because it does not exist when it is locked. One way is to add an X write lock to the entire table when tuples need to be inserted or deleted, so that T2 needs to wait for T1 to finish before it can be executed, so that the results are consistent.

Summarize

At different database element levels, it is necessary to increase the lock type to prevent the entire tree structure from being locked; of course, it is also necessary to solve the problem of phantom locking.

end

Thank you very much for your support. Don’t forget to leave your valuable comments while browsing. If you think it is worthy of encouragement, please like and save it. I will work harder!

Author’s email: [email protected]
If there are any errors or omissions, please point them out and learn from each other.