Tree index access method and device, equipment, medium and program product
The access of tree indexes is managed through the shared lock and exclusive lock mechanisms, which solves the problem of mutex restricting concurrent operations, realizes concurrent write access to multiple clients, and improves access performance.
Patent Information
- Application Number
- CN202510346565.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-03-21
- Publication Date
- 2025-07-11
AI Technical Summary
In the prior art, concurrent operations of tree indexes are limited by mutex schemes, resulting in a degradation of multi-client access performance.
The shared lock and exclusive lock mechanism are adopted to manage tree node access by updating shared ticket numbers and exclusive count values, allowing multiple clients to acquire shared locks at the same time and write access when the exclusive lock is idle.
Concurrent write access for multiple clients is realized, and the access performance of tree indexes is improved.
Smart Images
Figure CN120296013A_ABST
Abstract
Description
Technical Field
[0001] One or more embodiments of this specification relate to the field of storage technology, and in particular, to a method, apparatus, device, medium, and program product for accessing a tree index. Background Art
[0002] A tree index is a data structure used to efficiently store and retrieve data. It is usually organized in the form of a tree, such as a B+ tree, etc. The tree index can be widely applied in databases and file systems for quickly locating and managing a large amount of data.
[0003] In the related art, for access control of tree nodes in a tree index, a mutex lock scheme is usually adopted. A mutex lock is set for each tree node. Before modifying it, the corresponding mutex lock needs to be obtained first, and then the modification is performed. After the modification is completed, the mutex lock is released. In this way, for the same tree node, only one client can modify it at the same time, which greatly limits the concurrent operations of multiple clients and reduces the access performance. Summary of the Invention
[0004] In view of this, one or more embodiments of this specification provide the following technical solutions:
[0005] According to a first aspect of one or more embodiments of this specification, a method for accessing a tree index is proposed. Each tree node in the tree index is provided with a corresponding shared lock and an exclusive lock. The shared lock includes a shared count value and a shared ticket number, and the exclusive lock includes an exclusive count value and an exclusive ticket number. The method includes:
[0006] Updating the shared ticket number of the target shared lock corresponding to the target tree node to obtain the target shared lock;
[0007] Obtaining the current exclusive count value and the current exclusive ticket number of the target exclusive lock corresponding to the target tree node;
[0008] In response to the current exclusive count value being consistent with the current exclusive ticket number, determining that the target exclusive lock corresponding to the target tree node is idle, and performing a write access on the target tree node;
[0009] After the write access is executed, updating the shared count value of the target shared lock to release the target shared lock.
[0010] Optionally, it further includes:
[0011] In response to the current exclusive count value being inconsistent with the current exclusive ticket number, determining that the target exclusive lock is not idle;
[0012] Poll the current exclusive count value of the target exclusive lock until the current exclusive count value is consistent with the current exclusive ticket number, and perform a write access on the target tree node.
[0013] Optionally, the process of performing a write access on the target tree node includes:
[0014] When it is determined that the current write access does not require splitting of the tree node, perform a write access on the target tree node.
[0015] Optionally, it further includes:
[0016] When it is determined that the current write access requires splitting of the tree node, update the shared count value of the target shared lock to release the target shared lock;
[0017] Update the exclusive ticket number of the target exclusive lock, and determine whether both the target shared lock and the target exclusive lock are idle;
[0018] When both the target shared lock and the target exclusive lock are idle, determine that the target exclusive lock is acquired, and perform a write access on the target tree node;
[0019] After the write access is completed, update the exclusive count value of the target exclusive lock to release the target exclusive lock.
[0020] Optionally, the process of determining whether both the target shared lock and the target exclusive lock are idle includes:
[0021] Re-acquire the current exclusive count value and the current exclusive ticket number of the target exclusive lock, and the current shared count value and the current shared ticket number of the target shared lock;
[0022] When the re-acquired current exclusive count value is consistent with the current exclusive ticket number, determine that the target exclusive lock is idle;
[0023] When the current shared count value is consistent with the current shared ticket number, determine that the target shared lock is idle.
[0024] Optionally, it further includes:
[0025] When the target exclusive lock is not idle, poll the current exclusive count value of the target exclusive lock until the current exclusive count value is consistent with the current exclusive ticket number, and then determine that the target exclusive lock is idle;
[0026] When the target shared lock is not idle, poll the current shared count value of the target shared lock until the current shared count value is consistent with the current shared ticket number, and then determine that the target shared lock is idle.
[0027] Optionally, it further includes:
[0028] When performing a read access to the target tree node, read the key-value entry stored in the target tree node and the data version number of the key-value entry;
[0029] Determine the commit version number of the key-value entry;
[0030] When the data version number matches the commit version number, perform a read access based on the key-value entry.
[0031] Optionally, the commit version number comes from the pointer in the parent node of the target tree node that points to the target tree node.
[0032] Optionally, it further includes:
[0033] When performing a write access to the target tree node, embed the data version number of the target key-value entry to be written into the target value corresponding to the target key-value entry;
[0034] Write the target key-value entry to the target tree node, and update the commit version number after the writing is completed.
[0035] According to the second aspect of one or more embodiments of this specification, an access device for a tree index is proposed. Each tree node in the tree index is provided with a corresponding shared lock and exclusive lock. The shared lock includes a shared count value and a shared ticket number, and the exclusive lock includes an exclusive count value and an exclusive ticket number. The device includes:
[0036] A shared lock acquisition unit that updates the shared ticket number of the target shared lock corresponding to the target tree node to acquire the target shared lock;
[0037] A write access unit that acquires the current exclusive count value and the current exclusive ticket number of the target exclusive lock corresponding to the target tree node, and determines that the target exclusive lock corresponding to the target tree node is idle in response to the consistency of the current exclusive count value and the current exclusive ticket number, and performs a write access to the target tree node;
[0038] A shared lock release unit that updates the shared count value of the target shared lock after the write access is completed to release the target shared lock.
[0039] According to the third aspect of one or more embodiments of this specification, an electronic device is proposed, including: a processor; a memory for storing processor-executable instructions; wherein, the processor realizes the steps of the foregoing method by running the executable instructions.
[0040] According to a fourth aspect of one or more embodiments of the present specification, a computer-readable storage medium is provided, on which computer instructions are stored, and when the instructions are executed by a processor, the steps of the foregoing method are implemented.
[0041] According to a fifth aspect of one or more embodiments of the present specification, a computer program product is provided, including a computer program / instructions, and when the computer program / instructions are executed by a processor, the steps of the foregoing method are implemented.
[0042] As can be seen from the above description, by adopting the technical solution provided in the present specification, the target shared lock corresponding to the target tree node can be obtained by updating the shared ticket number, so that multiple clients can obtain the target shared lock simultaneously. And after obtaining the target shared lock, it is possible to determine whether the target exclusive lock is idle according to the exclusive count value and the exclusive ticket number of the target exclusive lock corresponding to the target tree node. If it is determined that the target exclusive lock is idle, then write access can be performed on the target tree node. When the target exclusive lock is idle, multiple clients holding the target shared lock can perform write access on the target tree node simultaneously, realizing concurrent write access to the tree node and greatly improving the access performance. BRIEF DESCRIPTION OF THE DRAWINGS
[0043] Figure 1 is a schematic structural diagram of an access system for a tree index provided by an exemplary embodiment.
[0044] Figure 2 is a schematic diagram of a shared lock and an exclusive lock provided by an exemplary embodiment.
[0045] Figure 3 is a flowchart of a method for accessing a tree index provided by an exemplary embodiment.
[0046] Figure 4 is a flowchart of another method for accessing a tree index provided by an exemplary embodiment.
[0047] Figure 5 is a flowchart of another method for accessing a tree index provided by an exemplary embodiment.
[0048] Figure 6 is a schematic diagram of version number storage provided by an exemplary embodiment.
[0049] Figure 7 is a flowchart of another method for accessing a tree index provided by an exemplary embodiment.
[0050] Figure 8 is a schematic structural diagram of a device provided by an exemplary embodiment.
[0051] Figure 9It is a block diagram of a tree index access device provided by an exemplary embodiment. DETAILED DESCRIPTION
[0052] A tree index is a data structure used to efficiently store and retrieve data. It is usually organized in the form of a tree, such as a B+ tree. Tree indexes can be widely used in databases and file systems to quickly locate and manage large amounts of data.
[0053] In the related art, for access control of tree nodes in tree index, a mutex lock solution is usually adopted. A mutex lock is set for each tree node. Before modifying it, it is necessary to obtain the corresponding mutex lock first, then modify it, and then release the mutex lock after the modification is completed. In this way, for the same tree node, only one client can modify it at the same time, which greatly limits the concurrent operations of multiple clients and reduces access performance.
[0054] This specification provides a tree index access method that can achieve concurrent write access by multiple clients, greatly improving access performance.
[0055] Figure 1 FIG. 1 is a schematic diagram of the architecture of a tree index access system provided by an exemplary embodiment. Figure 1 As shown, the system may include a tree index 110 and a plurality of clients 120 .
[0056] The tree index 110 may be stored in a memory device or a disk.
[0057] The client 120 is the subject that initiates an access request to the tree index 110, and may be an application, a thread, a node device in a distributed system, a user agent, etc. This specification does not impose any special restrictions on this.
[0058] For example, in a separate memory system, the tree index 110 may be stored in a memory device, and the client 120 may be a computing device that can access the tree index 110 through a network.
[0059] The specific implementation process of this specification is described in detail below with reference to the accompanying drawings.
[0060] The access method of the tree index provided in this specification can set corresponding shared locks and exclusive locks for each tree node in the tree index. Among them, the shared lock is used for concurrent writing to the corresponding tree node, allowing multiple clients to obtain and hold it simultaneously. When the write access does not cause the tree node to split, the client that obtains the shared lock can perform write access to the corresponding tree node, thereby realizing concurrent write access of multiple clients. The exclusive lock is used for exclusive writing to the corresponding tree node, and only allows one client to obtain and hold it when the shared lock is in an idle state (that is, not obtained by any client). When the write access causes the tree node to split, since it involves the movement of multiple key-value entries, only the client that obtains the exclusive lock can perform write access to the corresponding tree node.
[0061] Please refer to Figure 2 the shared lock and the exclusive lock shown. The sizes of the shared lock and the exclusive lock can both be 32 bits, totaling 64 bits. Among them, the shared lock includes a 16-bit shared count value and a 16-bit shared ticket number. When the shared count value and the shared ticket number are the same, it can be confirmed that the shared lock is idle. In the initial state, the shared count value and the shared ticket number can both be 0. Similarly, the exclusive lock includes a 16-bit exclusive count value and a 16-bit exclusive ticket number. When the exclusive count value and the exclusive ticket number are the same, it can be determined that the exclusive lock is idle. In the initial state, the exclusive count value and the exclusive ticket number can also both be 0.
[0062] Figure 3 is a flowchart of an access method for a tree index provided by an exemplary embodiment.
[0063] In this embodiment, the access method of the tree index can be applied to the aforementioned Figure 1 shown client. Please refer to Figure 3 , and includes the following steps:
[0064] Step 302, update the shared ticket number of the target shared lock corresponding to the target tree node to obtain the target shared lock.
[0065] In this embodiment, after updating the shared ticket number, it can be regarded as obtaining the corresponding shared lock. For the write access to the target tree node, the client can first update the shared ticket number of the target shared lock corresponding to the target tree node to obtain the corresponding target shared lock.
[0066] Exemplarily, the shared ticket number of the target shared lock can be incremented by 1 to implement the update operation. Suppose the value of the shared ticket number is the initial value 0, then it becomes 1 after the update.
[0067] Of course, in other examples, the update of the shared ticket number can also be achieved by adding 2, adding 5, etc. This specification does not impose special restrictions on this.
[0068] Step 304: Obtain the current exclusive count value and the current exclusive ticket number of the target exclusive lock corresponding to the target tree node.
[0069] In this embodiment, for a write access to a target tree node, the current exclusive count value and the current exclusive ticket number in its target exclusive lock can also be obtained.
[0070] Exemplarily, taking the case where a client accesses a tree index using the RDMA (Remote Direct Memory Access) technology as an example, the update of the shared ticket number, as well as the acquisition of the current exclusive count value and the current exclusive ticket number, can be achieved simultaneously through an RDMA_FAA (Fetch And Add) primitive.
[0071] Step 306: In response to the consistency between the current exclusive count value and the current exclusive ticket number, determine that the target exclusive lock corresponding to the target tree node is idle, and perform a write access to the target tree node.
[0072] In this embodiment, after obtaining the current exclusive count value and the current exclusive ticket number, it can be compared whether the two are consistent. If the current exclusive count value and the current exclusive ticket number are consistent, it can be explained that the target exclusive lock is idle and not held by other clients, that is, no client performs a write access involving tree node splitting on the target tree node. Furthermore, a write access to the target tree node can be performed.
[0073] For example, assuming that the initial values of the exclusive count value and the exclusive ticket number of the target exclusive lock are also both 0, then the obtained current exclusive count value and the current exclusive ticket number are both 0, and the two are consistent, determining that the target exclusive lock corresponding to the target tree node is idle.
[0074] In this embodiment, if multiple clients simultaneously obtain the target shared lock and the target exclusive lock is in an idle state, these clients can all perform a write access to the target tree node, realizing concurrent write access of multiple clients.
[0075] Step 308: After the write access is completed, update the shared count value of the target shared lock to release the target shared lock.
[0076] Based on the foregoing step 306, after the write access is completed, the target shared lock can be released by updating the shared count value of the target shared lock.
[0077] Exemplarily, taking the previous step of incrementing the shared ticket number of the target shared lock to implement the update operation as an example, after the write access is completed, the shared count value of the target shared lock can also be incremented to release the target shared lock. In this case, both the shared ticket number and the shared count value of the target shared lock corresponding to the target tree node become 1, and the exclusive ticket number and the exclusive count value of the corresponding target exclusive lock are still both the initial value of 0. If two clients perform write access to the target tree node, then another client will update the shared ticket number of the target shared lock from 1 to 2, and subsequently increment the shared count value of the target shared lock after the access is completed. If both of these two clients have completed the write access, then both the shared ticket number and the shared count value of the target shared lock corresponding to the target tree node become 2, and the exclusive ticket number and the exclusive count value of the corresponding target exclusive lock are still both the initial value of 0.
[0078] As can be seen from the above description, by adopting the technical solution provided in this specification, the target shared lock corresponding to the target tree node can be obtained by updating the shared ticket number, so that multiple clients can obtain the target shared lock simultaneously. Moreover, after obtaining the target shared lock, it is possible to determine whether the target exclusive lock is idle based on the exclusive count value and the exclusive ticket number of the target exclusive lock corresponding to the target tree node. If it is determined that the target exclusive lock is idle, then a write access can be performed on the target tree node. When the target exclusive lock is idle, multiple clients holding the target shared lock can perform write access to the target tree node simultaneously, realizing concurrent write access to the tree node and greatly improving the access performance.
[0079] In another example of this specification, if it is determined that the obtained current exclusive count value and the current exclusive ticket number are inconsistent, it can be determined that the exclusive lock is not idle, indicating that there is currently a client performing a write access that requires splitting the tree node on the target tree node. Then, the current exclusive count value of the target exclusive lock can be polled to wait until the current exclusive count value is consistent with the current exclusive ticket number obtained in the previous step 304, and then a write access is performed on the target tree node.
[0080] For example, assume that the current exclusive count value obtained by the client in step 304 is 0 and the current exclusive ticket number is 1, and the two are inconsistent. Then, the current exclusive count value of the target exclusive lock is polled. If the current exclusive count value of the target exclusive lock is polled to become 1, which is consistent with the current exclusive ticket number 1 obtained in step 304, it can be determined that the client that previously held the target exclusive lock has released the target exclusive lock, that is, the target exclusive lock is idle, and then a write access can be performed on the target tree node.
[0081] Also assume that the current exclusive count value obtained by the client in step 304 is 0, and the current exclusive ticket number is 2, and the two are inconsistent, which indicates that two clients want to hold the target exclusive lock. Then, poll the current exclusive count value of the target exclusive lock. If the current exclusive count value of the target exclusive lock is polled to become 1, it means that one client has released the exclusive lock and the other client is holding the target exclusive lock. Then continue to poll and wait until the current exclusive count value of the target exclusive lock is polled to become 2, which is consistent with the current exclusive ticket number 2 obtained in step 304. Then it can be determined that other clients have released the target exclusive lock, that is, the target exclusive lock is idle, and then the target tree node can be written to.
[0082] Thus, by adopting the access scheme provided in this specification, after the client obtains the target shared lock, if it determines that the target exclusive lock is not idle, it can poll and wait until the target exclusive lock is released and becomes idle, and then write to the target tree node. Only one shared lock is obtained in the whole process and then wait for the exclusive lock to be idle, and there will be no starvation problem in obtaining the lock.
[0083] In another example of this specification, if it is determined that the current exclusive count value and the current exclusive ticket number are consistent, after determining that the target exclusive lock is idle, it can also first determine whether the tree node needs to be split for this write access. If the tree node does not need to be split, the target tree node can be written to.
[0084] Specifically, after determining that the target exclusive lock is idle, if the write access requires an insert operation of key-value entries, it can be determined whether there is an empty slot in the target tree node. If there is an empty slot, the key-value entry can be inserted into the empty slot to achieve the write access. In this case, there is no need to split the tree node.
[0085] If the target tree node is full and there is no empty slot, the tree node needs to be split. Splitting the tree node often requires moving multiple key-value entries, and the operation is relatively complex. To ensure consistency, the obtained target shared lock can be released and the target exclusive lock can be obtained. If the target exclusive lock is successfully obtained, the write access can be performed.
[0086] Please refer to Figure 4 , in the case where it is determined that the tree node needs to be split for this write access, the process of performing the write access may include the following steps:
[0087] Step 402, in the case where it is determined that the tree node needs to be split for this write access, update the shared count value of the target shared lock to release the target shared lock.
[0088] In this embodiment, after obtaining the target shared lock corresponding to the target tree node, if the target exclusive lock is idle but the current write access requires splitting the tree node, an attempt can be made to obtain the target exclusive lock.
[0089] In this embodiment, the shared count value of the target shared lock can be updated first, and then the target shared lock can be released first. Still taking the initial values of both the shared count value and the shared ticket number as 0 as an example, before the write access, the client has updated the shared ticket number of the target shared lock to 1 first, and then obtained the target shared lock. Then, in this step, the shared count value of the target shared lock can also be updated to 1 to release the target shared lock. At this time, if no other client has obtained the target shared lock, both the shared count value and the shared ticket number of the target shared lock are 1.
[0090] Step 404: Update the exclusive ticket number of the target exclusive lock, and determine whether both the target shared lock and the target exclusive lock are idle.
[0091] In this embodiment, to obtain the target exclusive lock, on the one hand, the exclusive ticket number of the target exclusive lock can be updated first. Taking the initial values of both the exclusive count value and the exclusive ticket number of the target exclusive lock as 0 as an example, the exclusive ticket number of the target exclusive lock can be updated to 1.
[0092] On the other hand, it can be determined whether both the target shared lock and the target exclusive lock are in an idle state.
[0093] For the target shared lock, after releasing the target shared lock, the current shared count value and the current shared ticket number of the target shared lock can be obtained, and then whether the two are consistent can be compared. If they are consistent, it can be determined that the target shared lock is idle. If they are inconsistent, it can be determined that the target shared lock is held by other clients and is in a non-idle state.
[0094] Still taking updating the shared count value of the target shared lock to 1 to release the target shared lock as an example, after releasing the target shared lock, it can be obtained that both the current shared count value and the current shared ticket number of the target shared lock are 1, and it can be determined that the target shared lock is idle.
[0095] Suppose that after the shared ticket number of the target shared lock is updated to 2 in the foregoing step 302, if the obtained current shared count value is 1, it can be indicated that there is still a client holding the target shared lock, and the target shared lock is non-idle. Then, the current shared count value of the target shared lock can be polled until the current shared count value and the current shared ticket number are consistent, and it is determined that the target shared lock is idle. For example, until the current shared count value is also updated to 2 after polling, it can be determined that the target shared lock is idle.
[0096] For the target exclusive lock, the current exclusive count value and the current exclusive ticket number of the target exclusive lock can be re-obtained. When the re-obtained current exclusive count value is consistent with the current exclusive ticket number, it can be determined that the target exclusive lock is idle. Among them, the current exclusive ticket number is the ticket number before its update in this step.
[0097] Still taking the initial values of the exclusive count value and the exclusive ticket number of the target exclusive lock being 0 as an example, assuming that the re-obtained current exclusive count value is 0 and the current exclusive ticket number is also 0 (the value before update), then it can be determined that the target exclusive lock is idle.
[0098] Suppose, taking the updated exclusive ticket number of the target exclusive lock being 2 as an example, then the re-obtained current exclusive ticket number is 1. If the re-obtained current exclusive count value is still 0 and the two are inconsistent, it can be indicated that there is currently a client holding the target exclusive lock and the target exclusive lock is not idle. Then, the current exclusive count value of the target exclusive lock can be polled until the current exclusive count value is consistent with the previously re-obtained current exclusive ticket number, and it is determined that the target exclusive lock is idle. For example, until it is polled that the current exclusive count value is also 1, it can be determined that the target exclusive lock is idle.
[0099] Step 406, when both the target shared lock and the target exclusive lock are idle, it is determined to obtain the target exclusive lock, and a write access is performed on the target tree node.
[0100] In this embodiment, when it is determined that both the target shared lock and the target exclusive lock are idle, it can be determined to obtain the target exclusive lock, and then a write access to the target tree node can be performed.
[0101] If the target shared lock and / or the target exclusive lock is not idle, the aforementioned polling method can be adopted until it becomes idle.
[0102] Step 408, after the write access is completed, update the exclusive count value of the target exclusive lock to release the target exclusive lock.
[0103] In this embodiment, after the write access is completed, the exclusive count value of the target exclusive lock can also be updated to release the target exclusive lock. For example, the exclusive count value can be incremented by 1, etc.
[0104] It can be seen from this that for a write access that requires tree node splitting, it is possible to determine whether both the target shared lock and the target exclusive lock are idle after releasing the target shared lock, and if both are idle, it is possible to acquire the target exclusive lock and then perform the write access. When the target shared lock and / or the target exclusive lock are not idle, it is only necessary to wait for a certain number of lock releases to successfully acquire the target exclusive lock, and there will be no starvation problem in acquiring the lock.
[0105] Optionally, in Figure 4 In the embodiment shown, the update of the shared count value of the target shared lock (release of the target shared lock) and the update of the exclusive ticket number of the target exclusive lock can be achieved simultaneously through one RDMA_FAA primitive. In this case, the current shared count value of the re-acquired target shared lock will be the count value before the target shared lock was released (e.g., 0). Therefore, when performing a consistency comparison, it is necessary to update the currently re-acquired shared count value before comparing it with the currently re-acquired shared ticket number. If the two are the same, it can be determined that the target shared lock is idle. Adopting the scheme of simultaneously updating the shared count value and the exclusive ticket number can save one network round-trip time for releasing the shared lock.
[0106] In another embodiment of this specification, when accessing a tree index, a read-write conflict may also occur, that is, for the same tree node, there is a client reading while there is also a client writing. At this time, it is necessary to ensure that the data read by the client is correct.
[0107] To address this problem, in the related art, a version number comparison technique can be adopted. A corresponding version number is set for each tree node. When the write client updates the data, it will increment the version number before and after the update. The read client needs to perform three read operations. First, it reads the version number, then reads the data, and finally reads the version number again. If the two version numbers read are the same, it indicates that there is no concurrent write operation during the reading process, and then it is determined whether the data has been modified. However, in this way, the read client needs three read operations, increasing the access overhead.
[0108] In related technologies, a cache line version number technology can also be adopted to solve the read-write conflict problem. Specifically, a version number can be embedded at the beginning of each cache line of a tree node. When a write client updates data, it first updates the version numbers of all cache lines to a special value representing "locked", then updates the data, and finally updates the version number to a value representing "committed". For a read client, it can read the entire tree node through one read operation, and then determine whether the data has been updated by verifying whether the version numbers of all cache lines are consistent and not in the "locked" state. Although the read client can perform one read operation in this way, for the write client, multiple write operations are required to update the version number and the data. Moreover, when updating the version number, since the version numbers are scattered in each cache line, the update operation is extremely complex.
[0109] This specification provides a tree-like index access solution for solving read-write conflicts, which can reduce the read operations of the read client and simplify the write operations of the write client at the same time.
[0110] In this embodiment, for each tree node, a data version number and a commit version number are set for it. The data version number can be stored at the beginning of the cache line, and the data and its corresponding data version number can be read through one read operation. The commit version number can be stored at the head of the tree node.
[0111] Please refer to Figure 5 , for the read client, the access process of the tree-like index may include the following steps:
[0112] Step 502, when performing a read access to the target tree node, read the key-value entry stored in the target tree node and the data version number of the key-value entry.
[0113] In this embodiment, when the read client performs a read access to the target tree node, it can read the key-value entry stored in the target tree node and the data version number of the key-value entry through one read operation. Among them, the key-value entry is the data stored in the target tree node.
[0114] Step 504, determine the commit version number of the key-value entry.
[0115] In this embodiment, the commit version number corresponding to the key-value entry can also be determined.
[0116] In an example, the commit version number may be located at the head of the target tree node, then the read client can obtain the commit version number from the head of the target tree node.
[0117] Step 506, when the data version number and the commit version number match, perform a read access based on the key-value entry.
[0118] In this embodiment, it can be determined whether the data version number matches the submitted version number. For example, it can be determined whether the data version number is the same as the submitted version number, or whether the data version number has a corresponding relationship with the submitted version number, etc. This specification does not impose any special restrictions on this.
[0119] In this embodiment, if the data version number matches the submission version number, it can be indicated that the key-value entries read by the read client have not been modified, and read access can be performed based on these key-value entries.
[0120] As can be seen from the above description, this embodiment sets a data version number and a submission version number for the key value entry in the tree node, and determines whether the key value entry has been modified by matching the data version number and the submission version number during read access, thereby preventing node read-write conflicts. At the same time, compared with the aforementioned version number comparison technology, the read client can obtain the data version number and the submission version number through two read operations, reducing access overhead.
[0121] In another example of the present specification, in order to further reduce access overhead, the submission version number of the key-value entry can be stored in the pointer to execute the target tree node in the parent node of the target tree node. In this way, the submission version number can be directly obtained in the search path, which reduces one read operation and makes it possible to obtain the version number without adding additional read operations.
[0122] In another example of the present specification, in order to further reduce the storage overhead of the data version number, for each pair of key-value entries stored in the target tree node, a value (such as a pointer P) can be placed in front of the key K, and the data version number can be embedded in the value, thereby eliminating the need to store the data version number separately.
[0123] Please refer to Figure 6 For example, the commit version number Vc of the target tree node can be stored in a pointer to it in its parent node, and the data version number Vd of the key-value entry can be embedded in the pointer. Figure 6 The parent node, when the pointer is the first byte in the cache line, may include a data version number Vd, a lower-level child node (target tree node) submission version number Vc, G that can be used to store other information, and an address pointing to the lower-level child node.
[0124] Please refer to Figure 7 For a write client, the access process of the tree index may include the following steps:
[0125] Step 702: When performing write access to a target tree node, embed the data version number of the target key-value entry to be written into the target value corresponding to the target key-value entry.
[0126] Step 704: Write the target key-value entry into the target tree node, and update the commit version number after the writing is completed.
[0127] In this embodiment, when performing a write access, the data version number of the target key-value entry to be written can be embedded in the target value corresponding to the target key-value entry. For example, the data version number is embedded in the pointer of the target key-value entry. Then, when writing the target key-value entry into the target tree node, the writing of the target key-value condition and its data version number can be achieved simultaneously without additional writing operations.
[0128] In this embodiment, after the target key-value entry is written, its corresponding commit version number can be updated. For example, the commit version number in the pointer of the parent node that executes the target node is updated. Thus, the update of the version number can be achieved through two writes, which greatly simplifies the update operation of the version number compared with the cache line version number technology.
[0129] It can be seen from this that in this embodiment, by decoupling the version number of the key-value entry into a data version number and a commit version number, during the writing process, the update of the data version number, the commit version number, and the target key-value entry can be achieved through two write operations, which greatly simplifies the update operation of the version number compared with the cache line version number technology.
[0130] Figure 8 It is a schematic structural diagram of a device provided by an exemplary embodiment. Please refer to Figure 8 , at the hardware level, this device includes a processor 802, an internal bus 804, a network interface 806, a memory 808, and a non-volatile memory 810. Of course, it may also include other hardware required for other functions. One or more embodiments of this specification can be implemented in a software manner. For example, the processor 802 reads the corresponding computer program from the non-volatile memory 810 into the memory 808 and then runs it. Of course, in addition to the software implementation manner, one or more embodiments of this specification do not exclude other implementation manners, such as a logic device or a combination of software and hardware, etc. That is, the execution subject of the following processing flow is not limited to each logic unit, and can also be hardware or a logic device.
[0131] Please refer to Figure 9 , the access device 900 of the tree index can be applied to a device as shown in Figure 8 to implement the technical solution of this specification. Among them, the access device 900 of the tree index can include:
[0132] A shared lock acquisition unit 901, which updates the shared ticket number of the target shared lock corresponding to the target tree node to acquire the target shared lock;
[0133] The write access unit 902 obtains the current exclusive count value and the current exclusive ticket number of the target exclusive lock corresponding to the target tree node, and in response to the consistency between the current exclusive count value and the current exclusive ticket number, determines that the target exclusive lock corresponding to the target tree node is idle, and performs a write access on the target tree node;
[0134] The shared lock release unit 903 updates the shared count value of the target shared lock after the write access is completed to release the target shared lock.
[0135] Optionally, in response to the inconsistency between the current exclusive count value and the current exclusive ticket number, it is determined that the target exclusive lock is not idle;
[0136] Poll the current exclusive count value of the target exclusive lock until the current exclusive count value is consistent with the current exclusive ticket number, and perform a write access on the target tree node.
[0137] Optionally, the process of the write access unit 902 performing a write access on the target tree node includes:
[0138] When it is determined that the current write access does not require splitting of the tree node, a write access is performed on the target tree node.
[0139] Optionally, when the write access unit 902 determines that the current write access requires splitting of the tree node, it updates the shared count value of the target shared lock to release the target shared lock; updates the exclusive ticket number of the target exclusive lock, and determines whether both the target shared lock and the target exclusive lock are idle; when both the target shared lock and the target exclusive lock are idle, it is determined that the target exclusive lock is acquired, and a write access is performed on the target tree node; after the write access is completed, the exclusive count value of the target exclusive lock is updated to release the target exclusive lock.
[0140] Optionally, the process of determining whether both the target shared lock and the target exclusive lock are idle includes:
[0141] Re-obtain the current exclusive count value and the current exclusive ticket number of the target exclusive lock, and the current shared count value and the current shared ticket number of the target shared lock;
[0142] When the re-obtained current exclusive count value is consistent with the current exclusive ticket number, it is determined that the target exclusive lock is idle;
[0143] When the current shared count value is consistent with the current shared ticket number, it is determined that the target shared lock is idle.
[0144] Optionally, when the target exclusive lock is not idle, poll the current exclusive count value of the target exclusive lock until the current exclusive count value is the same as the current exclusive ticket number, and then determine that the target exclusive lock is idle;
[0145] When the target shared lock is not idle, poll the current shared count value of the target shared lock until the current shared count value is the same as the current shared ticket number, and then determine that the target shared lock is idle.
[0146] Optionally, the device further includes a read access unit 904. When performing a read access on the target tree node, read the key-value entry stored in the target tree node and the data version number of the key-value entry; determine the committed version number of the key-value entry; and when the data version number matches the committed version number, perform a read access based on the key-value entry.
[0147] Optionally, the committed version number comes from the pointer in the parent node of the target tree node that points to the target tree node.
[0148] Optionally, when performing a write access on the target tree node, the write access unit 902 embeds the data version number of the target key-value entry to be written into the target value corresponding to the target key-value entry;
[0149] write the target key-value entry into the target tree node, and update the committed version number after the writing is completed.
[0150] Based on the same concept as the above method, this specification also provides an electronic device, including: a processor; a memory for storing instructions executable by the processor; wherein, the processor realizes the steps of the method as described in any one of the above embodiments by running the executable instructions.
[0151] Based on the same concept as the above method, this specification also provides a computer-readable storage medium, on which computer instructions are stored, and when the instructions are executed by a processor, the steps of the method as described in any one of the above embodiments are realized.
[0152] Based on the same concept as the above method, this specification also provides a computer program product, including computer programs / instructions, and when the computer programs / instructions are executed by a processor, the steps of the method as described in any one of the above embodiments are realized.
Claims
1. A method for accessing a tree - shaped index, where each tree node in the tree - shaped index is provided with a corresponding shared lock and an exclusive lock. The shared lock includes a shared count value and a shared ticket number, and the exclusive lock includes an exclusive count value and an exclusive ticket number. The method includes: Updating the shared ticket number of the target shared lock corresponding to the target tree node to obtain the target shared lock; Obtaining the current exclusive count value and the current exclusive ticket number of the target exclusive lock corresponding to the target tree node; In response to the consistency of the current exclusive count value and the current exclusive ticket number, determining that the target exclusive lock corresponding to the target tree node is idle, and performing a write access on the target tree node; After the write access is completed, updating the shared count value of the target shared lock to release the target shared lock.
2. The method according to claim 1, further including: In response to the inconsistency of the current exclusive count value and the current exclusive ticket number, determining that the target exclusive lock is not idle; Polling the current exclusive count value of the target exclusive lock until the current exclusive count value and the current exclusive ticket number are consistent, and performing a write access on the target tree node.
3. The method according to claim 1, the process of performing a write access on the target tree node includes: When it is determined that the current write access does not require splitting of the tree node, performing a write access on the target tree node.
4. The method according to claim 1, further including: When it is determined that the current write access requires splitting of the tree node, updating the shared count value of the target shared lock to release the target shared lock; Updating the exclusive ticket number of the target exclusive lock, and determining whether both the target shared lock and the target exclusive lock are idle; When both the target shared lock and the target exclusive lock are idle, determining that the target exclusive lock is obtained, and performing a write access on the target tree node; After the write access is completed, updating the exclusive count value of the target exclusive lock to release the target exclusive lock.
5. The method according to claim 4, the process of determining whether both the target shared lock and the target exclusive lock are idle includes: Re - obtaining the current exclusive count value and the current exclusive ticket number of the target exclusive lock, and the current shared count value and the current shared ticket number of the target shared lock; When the re - obtained current exclusive count value and the current exclusive ticket number are consistent, determining that the target exclusive lock is idle; When the current shared count value and the current shared ticket number are consistent, determining that the target shared lock is idle.
6. The method according to claim 5, further including: When the target exclusive lock is not idle, polling the current exclusive count value of the target exclusive lock until the current exclusive count value and the current exclusive ticket number are consistent, and then determining that the target exclusive lock is idle; When the target shared lock is not idle, polling the current shared count value of the target shared lock until the current shared count value and the current shared ticket number are consistent, and then determining that the target shared lock is idle.
7. The method according to claim 1 further includes: When performing a read access to the target tree node, reading the key-value entry stored in the target tree node and the data version number of the key-value entry; Determining the commit version number of the key-value entry; When the data version number matches the commit version number, performing a read access based on the key-value entry.
8. The method according to claim 7, wherein the commit version number comes from a pointer in the parent node of the target tree node that points to the target tree node.
9. The method according to claim 7 further includes: When performing a write access to the target tree node, embedding the data version number of the target key-value entry to be written into the target value corresponding to the target key-value entry; Writing the target key-value entry into the target tree node, and updating the commit version number after the writing is completed.
10. An access device for a tree-like index, where each tree node in the tree-like index is provided with a corresponding shared lock and exclusive lock. The shared lock includes a shared count value and a shared ticket number, and the exclusive lock includes an exclusive count value and an exclusive ticket number. The device includes: A shared lock acquisition unit that updates the shared ticket number of the target shared lock corresponding to the target tree node to acquire the target shared lock; A write access unit that obtains the current exclusive count value and the current exclusive ticket number of the target exclusive lock corresponding to the target tree node, and determines that the target exclusive lock corresponding to the target tree node is idle and performs a write access to the target tree node in response to the current exclusive count value and the current exclusive ticket number being the same; A shared lock release unit that updates the shared count value of the target shared lock after the write access is completed to release the target shared lock.
11. An electronic device, comprising: A processor; A memory for storing instructions executable by the processor; wherein the processor implements the steps of the method according to any one of claims 1-9 by running the executable instructions.
12. A computer-readable storage medium having computer instructions stored thereon, and when the instructions are executed by a processor, the steps of the method according to any one of claims 1-9 are implemented.
13. A computer program product including a computer program / instructions, and when the computer program / instructions are executed by a processor, the steps of the method according to any one of claims 1-9 are implemented.