Transaction processing device and transaction processing method

Abstract

A transaction processing device (10) causes each of a plurality of worker threads executing transaction operations to apply the operations to an ordered index. In addition, the transaction processing device (10) adds a lock associated with each operation of the plurality of worker threads to a queue structure corresponding to each of the plurality of worker threads.

Description

Transaction processing device and transaction processing method

[0001] The present invention relates to a transaction processing device and a transaction processing method.

[0002] Since the performance of transaction processing in a database system is heavily dependent on indexes, an efficient index structure is very important. Griffin is a well-known index that improves the performance of point queries that operate on a single key (see, for example, Non-Patent Documents 1, 2, and 3; however, in Non-Patent Documents 1 and 2, Griffin is called PLI).

[0003] Nakazono, S., Bessho, Y., Kawashima, H., & Nakamori, T. (2024). Griffin: Fast Transactional Database Index with Hash and B+-Tree. arXiv preprint arXiv:2407.13294.

[0004] However, conventional techniques may not be able to improve the performance of transaction processing.

[0005] For example, the Sync Manager described in Non-Patent Documents 1, 2, and 3 is a thread that synchronizes multiple data structures included in Griffin and integrates them into a single index. However, in Griffin, the Sync Manager, which is a single thread, requires a large amount of calculation for synchronizing two index structures, which can degrade transaction processing performance.

[0006] The present invention has been made in view of the above, and has as its object to improve the performance of transaction processing.

[0007] In order to solve the above-mentioned problems and achieve the object, the transaction processing device of the present invention is characterized by having an execution unit that causes each of multiple worker threads, each of which executes a transaction operation, to apply the operation to an ordered index.

[0008] According to the present invention, it is possible to improve the performance of transaction processing.

[0009] FIG. 1 is a diagram illustrating an example of the configuration of a transaction processing device according to an embodiment. FIG. 2 is a diagram illustrating the operation of Precision Locking. FIG. 3 is a diagram illustrating the configuration and operation of Griffin. FIG. 4 is a diagram illustrating the configuration and operation of Lu and Lp according to an embodiment. FIG. 5 is a diagram illustrating an implementation example of TLQ according to an embodiment. FIG. 6 is a flowchart illustrating the processing flow of a transaction processing device according to an embodiment. FIG. 7 is a flowchart illustrating the processing flow of a transaction processing device according to an embodiment. FIG. 8 is a diagram illustrating an example of a computer that executes a transaction processing program.

[0010] Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings. Note that the present invention is not limited to this embodiment. In addition, in the description of the drawings, the same parts are designated by the same reference numerals.

[0011] 1 is a diagram showing an example of the configuration of a transaction processing device according to an embodiment. The transaction processing device 10 is a general-purpose computer such as a PC.

[0012] As shown in FIG. 1, the transaction processing device 10 includes a communication unit 11 , an input unit 12 , an output unit 13 , a storage unit 14 , and a control unit 15 .

[0013] The communication unit 11 performs data communication with other devices via a network. For example, the communication unit 11 is a network interface card (NIC). The input unit 12 is an interface connected to input devices such as a keyboard and a mouse. The output unit 13 is an interface connected to an output device such as a display.

[0014] The storage unit 14 is a storage device such as a hard disk drive (HDD), a solid state drive (SSD), or an optical disk. Note that the storage unit 14 may also be a data-rewritable semiconductor memory such as a random access memory (RAM), a flash memory, or a non-volatile static random access memory (NVSRAM). The storage unit 14 stores an operating system (OS) and various programs executed by the transaction processing device 10.

[0015] The storage unit 14 stores a database 141 capable of executing transaction processing. For example, the database 141 is a relational database.

[0016] The control unit 15 controls the entire transaction processing device 10. The control unit 15 is, for example, an electronic circuit such as a CPU (Central Processing Unit), an MPU (Micro Processing Unit), or a GPU (Graphics Processing Unit), or an integrated circuit such as an ASIC (Application Specific Integrated Circuit) or an FPGA (Field Programmable Gate Array).

[0017] The control unit 15 also has an internal memory for storing programs that define various processing procedures and control data, and executes each process using the internal memory. The control unit 15 also functions as various processing units when various programs are executed. For example, the control unit 15 has an execution unit 151, a lock addition unit 152, and a collision determination unit 153.

[0018] The execution unit 151 executes transaction processing. The lock addition unit 152 adds locks to operations in the transaction. The collision determination unit 153 determines whether there is a collision between operations in the transaction.

[0019] Before describing the processing of the transaction processing device 10, transaction processing and indexing will be described.

[0020] <1. Assumptions and definitions of indexes for transaction processing> First, as a premise, a transaction consists of several operations. Furthermore, a transaction issues the following operations (one or more) to an index. Lookup(k): Reading data corresponding to a single key k. Insert(k): Inserting data corresponding to a single key k. Delete(k): Deleting data corresponding to a single key k. Scan(r): Scanning key range r, i.e., reading all data corresponding to keys included in r. Commit(): Notifies the index that the issuing transaction has been committed. Issued after the issuing transaction has been committed. Abort(): Notifies the index that the issuing transaction has been aborted. Issued after the issuing transaction has been aborted.

[0021] A key range r is expressed by a key start point b and an end point e (b≦e). You can specify whether the range includes b and e. That is, r can be any of (b,e), [b,e), (b,e], or [b,e].

[0022] The worker thread is a thread that executes the above operations, and there may be multiple worker threads. One transaction is executed by one worker thread.

[0023] A transaction ends when it either commits (succeeds) or aborts (fails).

[0024] As a premise, when an operation o issued by a transaction t is aborted (failed), t is also aborted.

[0025] As a premise, to guarantee the correctness (serializability) of transaction processing, it is necessary to avoid an execution anomaly called a phantom anomaly (Reference 1).

[0026] Reference 1: K. P. Eswaran, J. Gray, R. A. Lorie, and I. L. Traiger, The notions of consistency and predicate locks in a database system, Commun. ACM, vol. 19, no. 11, pp. 624-633, 1976.

[0027] 2. Precision Locking: A Method to Avoid Phantom Anomalies Phantom anomalies occur due to the interaction of conflicting operations. Precision Locking (Reference 2) is a method to avoid phantom anomalies by restricting the execution order of conflicting operations.

[0028] Reference 2: J. R. Jordan, J. Banerjee, and R. B. Batman. Precision locks. In SIGMOD Conf., pages 143-147, 1981.

[0029] A conflict between operations is a conflict in access range. Insert(k) or Delete(k) conflicts with Scan(r).

[0030] The access range of Insert(k) or Delete(k) and Scan(r) conflicts when k∈r. Examples of access range conflicts are as follows: Insert(15) and Scan([10,20]) conflict. Delete(10) and Scan([20,30]) do not conflict. Insert(20) and Scan((20,30]) do not conflict. Insert(30) and Scan((20,30]) conflict.

[0031] Precision Locking imposes the restriction that "from the start of issuing an operation o (either Insert, Delete, or Scan) by any transaction t until the end of t (completion of commit or abort processing), no operations that conflict with o will be executed."

[0032] Due to the restrictions, operation o acquires a lock before inserting / deleting / traversing data and holds it until the end of the transaction that issued operation o. Also, while the lock on operation o is held, other transactions cannot perform operations that conflict with o.

[0033] When operation o_1 acquires lock l_1 and operation o_1 and operation o_2 collide, operation o_2 and lock l_1 are said to collide. Also, when operation o discovers a lock that conflicts with itself, operation o waits until the lock is released, or aborts. In this embodiment, it is assumed that operation o will abort in this case.

[0034] To achieve this restriction, the following algorithm is used:

[0035] Operation locks are managed by the following two sets: Lu: Manages the locks for Insert and Delete Lp: Manages the locks for Scan

[0036] Operation o (insert, scan, or delete) is executed in the following steps as shown in Figure 2. Figure 2 explains the operation of Precision Locking. Each step will be explained separately for the cases of Insert(k), Delete(k) and Scan(r).

[0037] For Insert(k) and Delete(k), secure the lock for the operation itself: add the lock for o to Lu (add). Check for conflicts with other operations: search for locks that conflict with o in Lp (conflict?), and abort o if found. Execute the operation: If it is not aborted, insert or delete key k.

[0038] In the case of Scan(r), securing a lock for the current operation: Add the lock for o to Lp (add). Checking for conflicts with other operations: Search for locks that conflict with o in Lu (conflict?), and abort o if found. Executing the operation: If not aborted, scanning the key range r is performed.

[0039] <3. Griffin> <3-1. Overview of Griffin> Below, we will explain Griffin. Griffin is an index structure designed to provide high-speed transaction processing, and Figure 3 is a diagram explaining the configuration and operation of Griffin. In Griffin, a single thread called the Sync Manager is responsible for synchronizing the hash index and the ordered index. Griffin has the following features (1) and (2).

[0040] (1) It has two index structures: a hash index and an ordered index. Single-key operations such as Lookup, Insert, and Delete are performed on the hash index. Scan is performed on the ordered index. (2) Phantom anomalies are avoided by precision locking. When performing operations that can cause phantom anomalies, such as Insert, Delete, and Scan, a lock is acquired on Lu and Lp before accessing the index.

[0041] Summarizing (1) and (2), the operations of Lookup, Insert, Delete, and Scan in Griffin are as follows: Lookup(k): Accesses the hash index and retrieves data for key k. Note: Precision Locking is not required as phantom anomalies cannot occur. Insert(k), Delete(k): Places the lock for the operation in Lu and searches for conflicting locks in Lp. Aborts if a conflicting lock is found. Otherwise, performs insertion or deletion of key k in the hash index. Scan(r): Places the lock for the operation in Lp and searches for conflicting locks in Lu. Aborts if a conflicting lock is found. Otherwise, performs a scan of key range r in the ordered index.

[0042] <3-2. Synchronization of two index structures by Sync Manager> Only hash indexes allow direct key insertion and deletion using Insert and Delete. Therefore, while hash indexes are always up to date, the state of ordered indexes will lag behind the hash index if nothing is done.

[0043] Therefore, a single thread, the Sync Manager, is provided to synchronize the hash index and the ordered index. The synchronization is achieved by determining the difference between the state of the hash index and the ordered index and applying that difference to the ordered index.

[0044] The difference between the state of a hash index and an ordered index is an Insert / Delete operation that satisfies the following conditions: (a) the transaction that issued it has committed, and (b) it has been applied to the hash index but not to the ordered index (inserting / deleting a key).

[0045] Information about recently issued Insert / Delete operations is stored in Lu's locks. To understand (a) and (b), Lu is designed as follows: To understand (a), the completion status of transactions issued for each lock in Lu is saved. Specifically, a status field is prepared for each lock and updated as follows: When an Insert / Delete command acquires a lock in Lu, the status is initialized to "active." When the transaction that issued the Insert / Delete command terminates, the status of the acquired Lu lock is updated to "committed" (if committed) or "aborted" (if aborted). For this update process, the Commit / Abort operations described in the "Summary of Griffin Operation" below are added. To understand (b), the locks for Insert / Delete commands applied to the ordered index are deleted (released). This indicates that the Insert / Delete locks remaining in Lu have not been applied to the ordered index.

[0046] Based on the above, the Sync Manager periodically executes the following process S1 on Lu to synchronize the two index structures: S1: Find all locks whose status is committed, and apply the operations related to each lock to the ordering index (for example, for a lock with Insert(30), insert key 30 into the ordering index). The locks for the applied operations are released (deleted from Lu).

[0047] Non-Patent Documents 1 and 2 assume a group commit such as epoch-based group commit (Reference 3), but Non-Patent Document 3 and the embodiment show a generalized algorithm. In a system that assumes group commit, all locks are deleted upon commit, so a Commit / Abort interface at transaction granularity is unnecessary. Furthermore, the two call functions shown in Non-Patent Document 1, Get and Update, are the same process that provides a pointer to data when viewed from an index, so Non-Patent Document 3 and the embodiment integrate them into Lookup.

[0048] Reference 3: Badrish Chandramouli, Guna Prasaad, Donald Kossmann, Justin J. Levandoski, James Hunter, and Mike Barnett. FASTER: A concurrent key-value store with in-place updates. In SIGMOD Conf., pages 275-290, 2018.

[0049] <3-3. Releasing Locks by Sync Manager> In Precision Locking, a lock secured by any transaction t can be released after t has finished.

[0050] If a lock is held for a long time after the end of t, the degree of parallelism will decrease and transaction processing performance will deteriorate, so it is desirable to release locks as soon as possible.

[0051] The Sync Manager is responsible for synchronizing the two index structures (S1) and periodically releasing locks on Lu and Lp. When a lock is removed from Lu and Lp, it means that it has been released.

[0052] The Sync Manager can release locks such as (c) and (d). (c) For the locks on Lu and Lp, the transaction that issued the operation that secured the lock has completed (committed or aborted). (d) For the lock on Lu, the operation related to the lock has already been applied to the ordering index.

[0053] To grasp the above locks, Lu and Lp are designed as follows: To grasp (c), the transaction execution status is recorded not only for Lu but also for Lp in the same way as for Lu. To satisfy (d), before releasing the lock of Lu, the lock operation is applied to the ordering index.

[0054] Based on the above, the Sync Manager periodically executes the following process S2 for Lu and Lp to release the locks. S2: Find and release all locks whose status is committed or aborted. For locks in Lu with a committed status, apply the lock operation to the ordering index before releasing them.

[0055] <3-4. Summary of Sync Manager Operation> The processes S1 (synchronization of two index structures) and S2 (releasing locks) that the Sync Manager must perform can be summarized as the following process S. The Sync Manager periodically executes the following process S.

[0056] The Sync Manager searches for locks in Lu, and for locks with a status of "committed", it applies the operation to the ordered index and deletes (i.e., releases) them. Applying means inserting the target key for an Insert lock, and deleting the target key for a Delete lock. For locks with a status of "aborted", the Sync Manager applies (rolls back) the reverse operation to the hash index and deletes (i.e., releases) them. Applying (rolling back) the reverse operation means deleting the target key for an Insert lock, and inserting the target key for a Delete lock.

[0057] The Sync Manager searches for locks in Lp and deletes (i.e., releases) any locks whose status is "committed" or "aborted."

[0058] The pseudocode for operation S is shown below, where hashIndex is a hash index and orderedIndex is an ordered index.

[0059] / / Pseudocode for process S foreach lock in Lu do if lock.status == "committed" orderedIndex.apply(lock) remove lock if lock.status == "aborted" hashIndex.rollback(lock) remove lock foreach lock in Lp do if lock.status == "committed" or lock.status == "aborted" remove lock

[0060] <3-5. Summary of Griffin operation> Algorithm 1 shows how each index operation is processed in Griffin. Each lock in Lu and Lp has the following information: op: type of operation (Insert, Delete, Scan) key: key to be accessed (in the case of Lu) range: key range to be accessed (in the case of Lp) status: status of the transaction that issued the operation

[0061] The processes in Algorithm 1 are as follows. locks: A variable maintained for each transaction, which saves a set of references to locks that the transaction created in Lu and Lp. Lu.add(l) / Lp.add(l): An operation to add a new lock l to Lu / Lp. In this pseudocode, it returns a reference to the added lock. Lu.conflict?(r): An operation to determine whether there is a lock in Lu that conflicts with a scan of the key range r. Lp.conflict?(k): An operation to determine whether there is a lock in Lp that conflicts with an insert / delete of key k. Commit() / Abort(): An operation to notify the index of the end of the transaction (commit / abort). It updates the status of all locks created up to that point to committed / all aborted.

[0062] Algorithm 1 is shown below. Note that " / / " and "#" are comments. function Lookup(k) get key k from hashIndex function Insert(k) lock <- Lu.add(op:"insert", key:k, status:"active") locks.add(lock) if Lp.conflict?(k) lock.status <- "aborted" abort insert k into hashIndex / / For Lu, it behaves the same as Insert(k) function Delete(k) lock <- Lu.add(op:"delete", key:k, status:"active") locks.add(lock) if Lp.conflict?(k) lock.status <- "aborted" abort delete k from hashIndex function Scan(r) lock <- Lp.add(op:"scan", range:r, status:"active") locks.add(lock) if Lu.conflict?(r) lock.status <- "aborted" abort orderedIndex.scan(r) function Commit(k) for lock in locks lock.status <- "committed" function Abort(k) for lock in locks lock.status <- "aborted"

[0063] <3-6. (Supplementary Note) Why Griffin is faster than other indexes> In a conventional index consisting of a single ordered index, the computational complexity of single key operations such as Lookup, Insert, and Delete is O(logN) (where N is the number of elements managed by the index). On the other hand, while Griffin's Scan is O(logN) as before, it can execute Lookup, Insert, and Delete in O(1), which is lighter than O(logN).

[0064] <4. Griffin Issues> The current Griffin configuration suffers from poor performance under workloads with many inserts and deletes. The reason for this is that the single-threaded Sync Manager requires a large amount of calculation to synchronize the two index structures, making it difficult to keep up with the speed of inserts and deletes.

[0065] Applying an Insert or Delete operation to an ordered index is more computationally intensive than applying it to a hash index. The computational complexity of the former is O(1), while the computational complexity of the latter is O(logN) (where N is the number of elements in the index). As a result, the Sync Manager spends much of its processing time applying Insert / Delete to the ordered index. This can cause the Sync Manager's other job, releasing locks, to not be performed quickly enough, and the rate at which new locks are added to Lu and Lp exceeds the rate at which locks on Lu and Lp are released, potentially causing the number of locks to balloon.

[0066] This causes two performance problems. First, the computational complexity of conflict detection operations (conflict?) increases, resulting in increased processing for Insert / Delete / Scan. Second, the transaction abort rate increases because the probability that an issued operation will conflict with some lock on Lu or Lp increases.

[0067] To mitigate these performance issues, it is preferable to perform insert / delete applications to an ordered index in multiple threads rather than in a single dedicated synchronization thread.

[0068] <5. Embodiment> <5-1. Overview of Griffin-TLQs> In this embodiment, in order to alleviate the above performance problems, Griffin-TLQs (Griffin Thread Local Queues), a new configuration of Griffin, is introduced. Below, we will mainly explain the differences between Griffin-TLQs and Griffin.

[0069] In Griffin-TLQs, the processes that were executed by a single thread (Sync Manager) in Griffin are executed by all worker threads. That is, the process of applying Insert / Delete to the ordered index is executed by all worker threads. The Sync Manager is abolished in Griffin-TLQs.

[0070] In order to distribute the processing applied to the ordered index to each worker thread, Lu and Lp are implemented using a queue structure distributed to each thread. In this case, Lu and Lp manage locks using queues distributed to each worker thread. Also, the queue assigned to a worker thread is called the TLQ (thread local queue) of Lu for that worker thread. The same applies to Lp.

[0071] Since Lu and Lp are distributed among worker threads, the precision locking processing (add() and conflict?()) in Algorithm 1 changes as follows in Griffin-TLQs:

[0072] Insert() / Delete() Secure a lock for the current operation, i.e., add a lock to Lu (Lu.add()): add a lock to the TLQ of Lu of the worker thread that issued the operation. Check for collisions with other operations, i.e., check for collisions with Lp (Lp.conflict?()): check for collisions with the TLQ of Lp of all worker threads. Scan() Secure a lock for the current operation, i.e., add a lock to Lp (Lp.add()): add a lock to the TLQ of Lp of the worker thread that issued the operation. Check for collisions with other operations, i.e., check for collisions with Lu (Lu.conflict?()): check for collisions with the TLQ of Lu of all worker threads.

[0073] The configuration and operation of Lu and Lp in the Griffin-TLQs of the embodiment is shown in Figure 4. Figure 4 is a diagram explaining the configuration and operation of Lu and Lp in the embodiment. As shown in Figure 4, each worker thread cooperatively applies Insert and Delete to the ordered index (the triangle in Figure 4) and is responsible for synchronizing with the hash index.

[0074] <5-2. Example of TLQ Implementation> In this embodiment, a queue structure is realized by a one-way list in which array structures each having a plurality of slots are linked by pointer references, as shown in FIG.

[0075] A slot is an area that can store one lock. A lock is acquired by adding a lock to the tail slot, and released by removing a lock from the head slot.

[0076] The TLQ has two pointers, a head pointer and a tail pointer, which respectively point to the head slot and tail slot of the current queue.

[0077] Here, the head pointer points to the slot where the oldest lock is stored, and the tail pointer points to the slot that will store the next lock. That is, locks are stored in the area from the slot pointed to by the head pointer to the previous slot pointed to by the tail pointer (for example, the area from 1-3 to 3-2 in Figure 5).

[0078] Here, the execution unit 151 executes each operation in transaction processing using Griffin-TLQs. Furthermore, the lock addition unit 152 controls locks such as adding locks in transaction processing. Furthermore, the collision determination unit 153 performs collision determination in transaction processing. In other words, the execution unit 151 mainly executes transaction processing, and the lock addition unit 152 and collision determination unit 153 perform processing as needed. Furthermore, the execution unit 151, lock addition unit 152, and collision determination unit 153 can cause each of multiple worker threads to execute processing.

[0079] <5-2-1. Adding a Lock> When adding a lock to Lu (in the case of Insert or Delete) or Lp (in the case of Scan) in operation o (Insert, Delete, Scan), the lock adding unit 152 writes the lock to be added to the area pointed to by the tail of the TLQ of the issuing thread, and then moves the tail forward.

[0080] <5-2-2. How to advance a pointer> Advancing the head or tail pointer means updating the pointer so that it points to the slot next to the current slot. The next slot of a given slot e is the first slot of the next array if e is at the end of the array, or the next slot after e in the same array if e is not at the end of the array.

[0081] It is necessary to be able to calculate the advanced pointer SUCC(ptr) from the head or tail pointer ptr that points to the current slot. To achieve this, the TLQ is designed as follows:

[0082] First, an end flag is prepared for each slot of the array, indicating whether it is at the end of the array or not. If it is at the end of the array, the end flag is set to 1, otherwise it is set to 0. Next, a next area is prepared in the last slot of the array, and a pointer to the first slot of the next array is saved in the next area.

[0083] In the above design, to move the pointer forward, the lock adding unit 152 checks the end flag, and if the pointer points to the last slot of the array (the end flag is 1), it updates the pointer to point to the first slot of the next array stored in the next area. If the pointer does not point to the last slot of the array (the end flag is 0), the lock adding unit 152 updates the pointer to point to the next slot of the same array. This can be done, for example, by calculating the pointer by adding the size of the area occupied by one slot (for example, 1 byte).

[0084] The lock adding unit 152 uses an instruction that causes the pointer update to reach at least a cache line so that the update is immediately visible to other threads.

[0085] Based on the above, pseudo code for the lock addition process (add) by the lock addition unit 152 for Lu and Lp is as follows:

[0086] Here, *ptr is the slot pointed to by the pointer ptr, and if a lock is stored in the slot, it represents that lock. UPDATE_PTR(ptr,ptr_val) is an operation that updates the pointer ptr with the value ptr_val. An instruction that ensures that the update reaches at least one cache line is used. ptr<-ptr_val, which appears in the pseudocode, also represents an operation that updates the pointer ptr with the value ptr_val, but it is not necessarily necessary to use an instruction that ensures that the update reaches at least one cache line.

[0087] #Pseudocode for lock addition processing (add) function Lu::add(lock) # Lu_tlq: TLQ of Lu of the thread that executes this function write lock to *Lu_tlq.tail ptr_lock = SUCC(Lu_tlq.tail) UPDATE_PTR(Lu_tlq.tail, ptr_lock) return ptr_lock function Lp::add(lock) # Lp_tlq: TLQ of Lp of the thread that executes this function write lock to *Lp_tlq.tail ptr_lock = SUCC(Lp_tlq.tail) UPDATE_PTR(Lp_tlq.tail, ptr_lock) return ptr_lock

[0088] 5 is a diagram illustrating an example of the implementation of a TLQ in an embodiment. For example, when a worker thread having a TLQ of Lu in the state of FIG. 5 executes Insert / Delete, the lock is written to slot 3-3 and the tail pointer advances to point to 3-4.

[0089] 5-2-3. Conflict Determination (conflict?) The conflict determination unit 153 executes Lp.conflict?(k) in Insert(k), which is an operation for inserting key k, or Delete(k), which is a process for deleting key k. Lp.conflict?(k) is an operation for checking whether there is a Scan lock in Lp that conflicts with Insert(k) / Delete(k).

[0090] The collision determination unit 153 checks whether there are any conflicting Scan locks in the TLQs of the Lp of all worker threads in Griffin-TLQs. To check whether there are any conflicting Scan locks in the TLQ of a certain worker thread, the collision determination unit 153 searches from the head pointer of the TLQ toward the tail pointer, and checks whether there are any conflicts with each stored lock. The collision determination unit 153 can interrupt the search when even one conflicting lock is found.

[0091] The conflict determination unit 153 executes Lu.conflict?(r) in Scan(r), which is an operation for scanning a key range r. In Lu.conflict?(r), the same processing as Lp.conflict?(k) in Insert(k) and Delete(k) is executed.

[0092] 5, when a worker thread executes Scan(r) (r=[25,35]), the collision determination unit 153 searches for locks of conflicting operations in the TLQs of Lu of all worker threads. When the TLQ of Lu of a worker thread is in the state shown in FIG. 5, the collision determination unit 153 starts searching from the lock in slot 1-3, finds a conflict with lock Insert(30) in slot 2-1, and ends the search.

[0093] The pseudocode for the conflict detection process (conflict?) for Lu and Lp is as follows: where Lu.all_tlqs is the TLQ of all worker threads of Lu, and Lp.all_tlqs is the TLQ of all worker threads of Lp.

[0094] / / Pseudocode for conflict detection processing (conflict?) for Lu function Lu::conflict?(r) for tlq in Lu.all_tlqs do ptr_cur <- tlq.head / / Search pointer ptr_end <- tlq.tail / / When the tail is reached, the search of this TLQ is complete while ptr_cur != ptr_end do if r conflicts with (*ptr_cur).key return true ptr_cur <- SUCC(ptr_cur) / / Move the search pointer forward return false / / Pseudocode for conflict detection processing (conflict?) for Lp function Lp::conflict?(k) for tlq in Lp.all_tlqs do ptr_cur <- tlq.head / / Search pointer ptr_end <- tlq.tail / / When the tail is reached, the search of this TLQ is complete while ptr_cur != ptr_end do if k conflicts with (*ptr_cur).range return true ptr_cur <- SUCC(ptr_cur) / / Advance search pointer return false

[0095] <5-2-4. Synchronization and Lock Release Processing (Process S)> Process S, which in conventional Griffin is performed by a single thread called Sync Manager, is performed by each worker thread in this embodiment.

[0096] Each worker thread executes S only for its own TLQ. That is, each worker thread applies the lock processing of its own Lu's TLQ to the ordering index (S1) and releases the locks of its own Lu and Lp's TLQ (S2). At this time, the execution unit 151 causes each of the multiple worker threads that each executes a transaction operation to apply the operation to the ordering index.

[0097] The process S_t of worker thread t in process S is as follows: Search the locks in the TLQ of Lu of t, starting from the head, until an active lock (neither committed nor aborted) is found or the tail is reached. For locks with a status of "committed", apply the operation to the ordered index. For locks with a status of "aborted", apply the reverse operation to the hash index (rollback). Lock deletion (i.e., release) is performed by updating the head pointer. To reduce performance costs, the head pointer is updated only once when the search is complete, rather than each time a "committed" or "aborted" lock is found. Search the locks in the TLQ of Lp of t, starting from the head, until an active lock (neither committed nor aborted) is found or the tail is reached. As with Lu, update the head pointer only once when the search is complete. Each worker thread may execute the operation S_t at any time when it is not executing an Insert, Delete, Scan, Commit, or Abort operation.

[0098] The process S_t of each worker thread t is shown in the following pseudo code: *ptr is the slot pointed to by the pointer ptr, and if a lock is stored in the slot, it represents the lock.

[0099] / / Pseudocode for process S_t / / Process for Lu / / Search pointer (starts from head) ptr_cur <- Lu_tlq.head; while do / / The search ends when the slot pointed to by tail or an active lock is reached. The lock is deleted by updating head. if ptr_cur == Lu_tlq.tail or (*ptr_cur).status == "active" Lu_tlq.head <- ptr_cur break lock <- *ptr_cur if lock.status == "committed" orderedIndex.apply(lock) else if lock.status == "aborted" hashIndex.rollback(lock) / / Move the search pointer forward ptr_cur <- SUCC(ptr_cur) / / Process for Lp / / Search pointer (starts from head) ptr_cur <- Lp_tlq.head; while do / / The search ends when the slot pointed to by tail or an active lock is reached. The lock is deleted by updating head. if ptr_cur == Lp_tlq.tail or (*ptr_cur).status == "active" Lp_tlq.head <- ptr_cur break / / Advance search pointer ptr_cur <- SUCC(ptr_cur)

[0100] When worker thread t has the TLQ of Lu in the state shown in Figure 5, in process S_t, worker thread t starts searching from slot 1-3, finds an active lock in slot 2-3, and ends the search. The head pointer is updated to point to slot 2-3, and all locks from slot 1-3 to slot 2-2 are deleted (released). Note that the status of the lock in slot 2-4 is committed, but it will not be deleted this time. When S_t is re-executed after the lock in slot 2-3 is updated to committed or aborted, the lock in slot 2-4 will be deleted (released).

[0101] <5-2-5. Memory Management (Extending the Tail Side and Contracting the Head Side of a Queue)> The execution unit 151 secures the tail side and releases the head side as needed in array units of memory areas.

[0102] (Tail Extension) When the tail pointer is located at the end of the array, the execution unit 151 reserves memory space for a new array before advancing the tail pointer, and saves a pointer to the head of the new array at the end of the array where the current head pointer is located. The reservation of memory space for the new array may be performed before the tail pointer reaches the end of the array.

[0103] (Head-Side Contraction) When the tail pointer moves forward from the end of an array, the execution unit 151 can release the memory area of ​​the array because the array does not contain any locks.

[0104] 6. Processing Flow The processing flow of Precision Locking in Griffin-TLQs will be described with reference to Fig. 6 and Fig. 7. Fig. 6 and Fig. 7 are flowcharts showing the processing flow of the transaction processing device according to the embodiment.

[0105] As shown in FIG. 6, when the execution unit 151 executes an Insert( ) / Delete( ) operation, the lock addition unit 152 adds a lock to the TLQ of the Lu of the worker thread that issued the operation (step S101).

[0106] Next, the collision determination unit 153 determines whether there is a collision between the TLQs of the Lp of all worker threads and the Insert() / Delete() operation (step S102). If there is no collision (step S103, No), the execution unit 151 executes the operation (insert a key into the hash table for Insert, or delete a key from the hash table for Delete) (step S104). If there is a collision (step S103, Yes), the execution unit 151 aborts the operation (step S105).

[0107] As shown in FIG. 7, when the execution unit 151 executes the Scan( ) operation, the lock addition unit 152 adds a lock to the TLQ of the Lp of the worker thread that issued the operation (step S201).

[0108] Next, the collision determination unit 153 determines whether there is a collision between the TLQ of Lu of all worker threads and the Scan() operation (step S202). If there is no collision (step S203, No), the execution unit 151 executes the operation (key range scan using ordered index) (step S204). If there is a collision (step S203, Yes), the execution unit 151 aborts the operation (step S205).

[0109] In this way, the lock adding unit 152 adds locks associated with the operations of each of the multiple worker threads to the queue structures corresponding to each of the multiple worker threads.

[0110] Furthermore, when a lock associated with a first operation of a first worker thread among the multiple worker threads is added to a queue structure (e.g., Lu) corresponding to the first operation of the first worker thread (e.g., Insert() or Delete()), the collision determination unit 153 determines whether the first operation of the first worker thread will collide with locks in queue structures (e.g., Lp) corresponding to second operations (e.g., Scan()) of all the worker threads. If the collision determination unit 153 determines that a collision will occur, the execution unit 151 aborts the first operation of the first worker thread.

[0111] According to the embodiment, the data structures of Lu and Lp are distributed to multiple worker threads, and each worker thread can execute insert / delete operations on the ordered index in parallel, thereby improving the performance of transaction processing.

[0112] For example, it has been reported that in some in-memory systems, index access accounts for 14-94% of transaction processing time (Reference 4). Therefore, according to the embodiment, it is possible to significantly reduce processing time.

[0113] Reference 4: Yusuf Onur Ko cberber, Boris Grot, Javier Picorel, Babak Falsafi, Kevin T. Lim, and Parthasarathy Ranganathan. Meet the walkers: accelerating index traversals for in-memory databases. In MICRO, pages 468-479. ACM, 2013

[0114] [Program] In one embodiment, the transaction processing device 10 can be implemented by installing a transaction processing program that executes the above-described processing as package software or online software on a desired computer. For example, by having an information processing device execute the above-described transaction processing program, the information processing device can function as the transaction processing device 10. The information processing device referred to here includes desktop and notebook personal computers. Other examples of information processing devices include smartphones, tablet terminals, etc.

[0115] 8 is a diagram showing an example of a computer that executes a transaction processing program. The computer 1000 includes, for example, a memory 1010 and a CPU 1020. The computer 1000 also includes a hard disk drive interface 1030, a disk drive interface 1040, a serial port interface 1050, a video adapter 1060, and a network interface 1070. These components are connected by a bus 1080.

[0116] The memory 1010 includes a ROM (Read Only Memory) 1011 and a RAM (Random Access Memory) 1012. The ROM 1011 stores, for example, a boot program such as a BIOS (Basic Input Output System). The hard disk drive interface 1030 is connected to a hard disk drive 1090. The disk drive interface 1040 is connected to a disk drive 1100. A removable storage medium such as a magnetic disk or optical disk is inserted into the disk drive 1100. The serial port interface 1050 is connected to, for example, a mouse 1110 and a keyboard 1120. The video adapter 1060 is connected to, for example, a display 1130.

[0117] The hard disk drive 1090 stores, for example, an OS 1091, an application program 1092, a program module 1093, and program data 1094. That is, the program that defines each process of the transaction processing device 10 is implemented as a program module 1093 in which computer-executable code is written. The program module 1093 is stored, for example, in the hard disk drive 1090. For example, a program module 1093 for executing processes similar to those of the functional configuration of the transaction processing device 10 is stored in the hard disk drive 1090. The hard disk drive 1090 may be replaced by an SSD.

[0118] Furthermore, setting data used in the processing of the above-described embodiment is stored as program data 1094, for example, in the memory 1010 or the hard disk drive 1090. The CPU 1020 then reads the program module 1093 or the program data 1094 stored in the memory 1010 or the hard disk drive 1090 into the RAM 1012 as necessary, and executes the processing of the above-described embodiment.

[0119] The program module 1093 and program data 1094 may not necessarily be stored in the hard disk drive 1090, but may also be stored in, for example, a removable storage medium and read by the CPU 1020 via the disk drive 1100 or the like. Alternatively, the program module 1093 and program data 1094 may be stored in another computer connected via a network (such as a local area network (LAN) or a wide area network (WAN)). The program module 1093 and program data 1094 may then be read by the CPU 1020 from the other computer via the network interface 1070.

[0120] Although the present invention has been described above as an embodiment, the present invention is not limited to the description and drawings that form part of the disclosure of the present invention. In other words, other embodiments, examples, and operational techniques that can be made by those skilled in the art based on the present invention are all included in the scope of the present invention.

[0121] REFERENCE SIGNS LIST 10 transaction processing device 11 communication unit 12 input unit 13 output unit 14 storage unit 15 control unit 151 execution unit 152 lock addition unit 153 collision determination unit

Claims

1. A transaction processing device comprising an execution unit that causes each of a plurality of worker threads, each of which executes a transaction operation, to apply the operation to an ordering index.

2. A transaction processing device according to claim 1, further comprising a lock adding unit that adds locks associated with the operations of each of the plurality of worker threads to queue structures corresponding to each of the plurality of worker threads.

3. The transaction processing device described in claim 2, further comprising a collision determination unit that, when a lock associated with a first operation of a first worker thread among the plurality of worker threads is added to a queue structure corresponding to the first operation of the first worker thread, determines whether or not the first operation of the first worker thread will collide with locks in queue structures corresponding to second operations of all of the plurality of worker threads, and when the collision determination unit determines that a collision will occur, the execution unit aborts the first operation of the first worker thread.

4. A transaction processing method executed by a transaction processing device, characterized in that each of a plurality of worker threads, each of which performs an operation of a transaction, is caused to apply the operation to an ordering index.

Images