Quick hop list clear

Abstract

Techniques related to efficiently managing skip list data structures are disclosed. In some embodiments, a computing system stores a skip list comprising a plurality of key-value records, the key-value records comprising one or more pointers to other key-value records in the plurality of key-value records. The computing system scans the plurality of key-value records in order of keys to identify key-value records to purge from the skip list. The scanning includes maintaining a list of key-value records comprising pointers to key-value records that have not yet been scanned by the scanning. In response to identifying a key-value record for purging, the computing system purges the key-value record by replacing pointers included in the key-value records of the list with pointers included in the key-value record that is being purged.

Description

Background Technology Technical Field

[0002] The publicly available text generally deals with data storage, and more specifically, with manipulating jump list data structures.

[0003] Related technical descriptions

[0004] In computer science, various complex data structures have been developed to facilitate information storage. These data structures typically use multiple pointers to link sets of records together. When designing complex structures, developers often weigh the complexity of inserting and retrieving information against the overall size of the data structure. Skip lists are an example of a more complex data structure that can be popular because they can hold large datasets while still providing O(log n) insertion and O(log n) search complexity. In this type of data structure, records are sorted according to key order and linked using a hierarchical structure of linked sequences of records, with each successive sequence skipping fewer elements than the previous one. This hierarchical structure of links is implemented using a pointer tower of varying heights, allowing pointers to be arranged based on the number of records skipped within a given tower. This ability to skip records when traversing a skip list allows for locating a given record much faster than a sequential scan. Attached Figure Description

[0005] Figure 1 This is a block diagram illustrating one implementation of a database system that uses a skip list within a buffered data structure to handle concurrent database transactions.

[0006] Figure 2 This is a block diagram illustrating one implementation of a record chain within a buffered data structure.

[0007] Figure 3 This is a block diagram illustrating one implementation of a skip list within a buffered data structure.

[0008] Figure 4 This is a block diagram illustrating one implementation of a slow clearing process for removing records from a skip list.

[0009] Figures 5A-5D This is a diagram illustrating an implementation of a quick clearing process for removing records from a skip list.

[0010] Figure 6 This is a block diagram illustrating one implementation of a clearing engine that performs the clearing of a skip list.

[0011] Figure 7 This is a diagram illustrating one implementation of a parallel, fast clearing process for removing records from a skip list.

[0012] Figures 8A-8C This is a flowchart illustrating an implementation of a method related to clearing records from a skip list.

[0013] Figure 9 This is a block diagram illustrating one implementation of an exemplary computer system. Detailed Implementation

[0014] In some cases, skip lists can be used to hold large amounts of frequently manipulated information. For example, as will be described in further detail below, a database system can use a buffered data structure to store data from active database transactions until the transactions can be committed and their data flushed to the database system's persistent storage. The buffered data structure can include a skip list data structure, which enables efficient storage and retrieval of transaction records in key order. Since the database system can process a large number of transactions in parallel, the efficient maintenance of the skip list is crucial for database performance.

[0015] The published text describes an implementation scheme in which a fast cleanup algorithm efficiently removes records from a skip list when a record is no longer in use. As will be described below in various implementation schemes, the key-value records of the skip list are scanned in key order by traversing the lowest level of the skip list to identify key-value records to be cleaned. (As used herein, a “key-value record” refers to a record identified by a key and including a corresponding value – the key and value are collectively referred to as a “key-value pair”.) While scanning records, in some implementations, records are checked to determine if they are ready to be cleaned by examining a flag set to indicate when cleanup is permitted. Pointer information is recorded for pointers included in the pointer tower and is maintained until these pointers are resolved (i.e., the records pointed to by these pointers have been scanned). If a record to be cleaned is identified, the key-value record is cleaned by replacing one or more currently unresolved pointers with pointers included in the key-value record being cleaned. As will be discussed, this method of scanning the skip list in key order and tracking unresolved pointers can result in significantly fewer memory accesses than methods that rely on traversing the skip list downwards to determine which pointers should be updated when a record is cleaned.

[0016] Furthermore, a fast parallel clearing algorithm is discussed, in which the skip list is divided into portions scanned in parallel by multiple threads. (As used herein, the phrase "parallel" refers to two or more operations (or two or more instances of the same operation) performed such that they overlap at least partially in time.) As will be discussed in various implementations, the portions of the skip list can be determined by traversing the top of the skip list to identify key-value records that can form the boundaries of these portions. These portions can then be assigned to separate threads, which can scan their assigned portions in parallel using the fast clearing algorithm. After a thread has scanned a portion, the records at the boundaries of the portions identified as needing clearing can be cleared by traversing down the skip list to identify which skip list pointers should be updated.

[0017] Public text combined Figure 1 and 2 Let's begin by discussing a database system that can maintain a skip list and use a fast cleanup algorithm. Combined with... Figure 3 Discuss an example skip list. Then refer to... Figure 4 This section discusses inefficient algorithms for clearing records. (References) Figures 5A-6 Discuss fast clearing algorithms. Figure 7 A fast, parallel cleanup algorithm using multithreading is discussed. Finally, refer to... Figures 8A-9 The discussion covers methodologies and exemplary computing systems.

[0018] Now go to Figure 1 A block diagram of database system 10 is depicted. In the illustrated embodiment, database system 10 includes a transaction manager 104, a buffered data structure 106, and a database 108. As shown, the buffered data structure 106 includes multiple record chains 110, a hash table 120, an active transaction list 130, and a skip list 140. Record chains 110 include key-value records 112. The hash table 120 includes an array of hash functions 122 and hash buckets 124, each hash bucket including a latch 126. (As used herein, the terms “latch,” “lock,” and “semaphore” are generally used to refer to variables that control access to resources shared among multiple potential consumers.) In the illustrated embodiment, manager 104 also includes a scavenging engine 150. In some embodiments, database system 10 may be implemented differently than shown. For example, in some embodiments, buffered data structure 106 may include more (or fewer) structures.

[0019] In one implementation, transaction manager 104 includes program instructions executable to process received database transaction 102. Typically, transaction 102 can be issued to read data or write data to database 108, and can be received from any of a variety of sources such as one or more client devices, application servers, software running on database system 10, etc. As will be described in more detail below, this processing may require manager 104 to initially store the key-value pair record 112 of transaction 102 in buffered data structure 106 until record 112 can be flushed to persistent storage in database 108. Therefore, various functions described below with respect to buffered data structure 106 can be implemented by transaction manager 104, such as adding key-value record 112 to record chain 110, facilitating the acquisition of hash bucket latch 126 for transaction 102, modifying active transaction list 130 and skip list 140, etc.

[0020] In one implementation, buffer data structure 106 is a data structure that buffers key-value pairs of active transactions until the transaction is committed. As described below, buffer data structure 106 is constructed in a manner that allows for fast insertion of key-value pairs, which in some cases can be performed concurrently, thereby allowing for efficient handling of a large number of transactions. Furthermore, buffer data structure 106 can reside in local memory to allow for faster reads and writes than the persistent storage of database 108 where data resides long-term. In various implementations, buffer data structure 106 allows concurrent modifications to it for different transactions 102, but provides concurrency control mechanisms for the data within buffer data structure 106 via hash bucket latch 126. In various implementations, committed transaction data is asynchronously flushed from buffer data structure 106 to the persistent storage of database 108. That is, instead of flushing data on each transaction 102 when it is committed, flushing is performed periodically for multiple committed transactions 102. For example, in one implementation, transaction manager 104 initiates a flush of database 108 in response to buffer data structure 106 meeting a specific size threshold.

[0021] Database 108 can correspond to any suitable form of database implementation. In some implementations, database 108 is a relational database implemented using a Log Structured Merge (LSM) tree for persistent storage. In some implementations, the layers of the LSM tree can be distributed across multiple physical computer systems providing persistent storage. In some implementations, these computer systems are cluster nodes of a computer cluster providing a cloud-based system accessible to multiple clients. In some implementations, database 108 can be part of a Software as a Service (SaaS) model; in other implementations, database 108 can be directly manipulated by users.

[0022] As described above, when transaction manager 104 stores key-value pairs of active transaction 102 in buffer data structure 106, corresponding key-value records 112, including values ​​and keys, can be created. If multiple transactions 102 attempt to write values ​​associated with the same key, key-value records 112 can be generated for each value and chained together to form a record chain 110 corresponding to that key. For example, if a user has withdrawn a first amount from a bank account leading to a first database transaction 102, and then withdrawn a second amount leading to a second database transaction 102, the record chain 110 corresponding to the account balance key could have two key-value records 112 reflecting these withdrawals. In various embodiments, each record 112 includes a transaction identifier (e.g., a transaction sequence number) specifying its associated transaction 102; records 112 can also be organized in the record chain 110 based on the order in which transactions 102 are received. For example, as described below... Figure 2 As described, a linked list can be used to implement record chain 110, such that a new record 112 is inserted at the head of the linked list and migrates to the tail as the new record 112 is created and the old record is flushed to the database 108. To facilitate fast access to key-value record 112, record chain 110 is attached to hash bucket 124 of hash table 120.

[0023] In one implementation, hash table 120 is a data structure that allows constant-time lookups of record chain 110 based on a given key. That is, when a key is received, hash table 120 is indexed by applying hash function 122 to the key to generate an appropriate index value for hash bucket 124 corresponding to that key. The record chain 110 can then be retrieved by referencing a direct pointer in hash bucket 124. The ability to perform constant-time lookups significantly reduces the time consumed by reading key-value record 112, writing record 112, or performing key probing (i.e., determining whether a key exists as a key-value record 112 in buffered data structure 106).

[0024] As described above, in various implementations, each hash bucket 124 includes a corresponding latch 126 that controls access to its record chain 110. Thus, when a transaction attempts to read or write a value associated with a specific key, that key can be used to index into the hash table 120, and the latch 126 corresponding to the associated hash bucket 124 can be acquired before performing the read or write. If the latch 126 cannot be acquired for database transaction 102, processing of database transaction 102 can be delayed until the latch 126 is released. In some implementations, the latch 126 can have one of three possible states: available, shared acquisition, and exclusive acquisition. If no transaction 102 is currently accessing record chain 110, its latch 126 is available for acquisition. If transaction 102 is performing a read on key-value record 112, the latch 126 can be acquired in the shared state—meaning other transactions 102 can also acquire the latch 126 as long as they are also performing reads (i.e., not attempting to modify record 112 while reading it). However, if transaction 102 is performing a write operation, latch 126 is acquired exclusively for transaction 102, meaning that no other transaction 102 can acquire latch 126 until it is released. Therefore, if two transactions 102 are attempting to write to the same key, the latter transaction is delayed until the former completes its write operation and releases latch 126. If transaction 102 is attempting to access multiple key-value pairs, latch 126 can be acquired in ascending order of bucket 124 to prevent deadlock. While latch acquisition can be discussed primarily in relation to read and write operations, latch 126 can also be acquired during other operations such as defragmentation, garbage collection, or flushing record 112 to persistent storage in database 108. In some implementations, latch 126 can also be used as a concurrency control mechanism for active transaction lists 130 and skip lists 140.

[0025] In one implementation, the active transaction list 130 is a data structure that tracks various metadata for active transactions 102. In various implementations, the metadata for a given transaction 102 includes a transaction identifier for transaction 102 and one or more pointers that can be used to access records 112 associated with transaction 102. In doing so, list 130 makes it possible to identify records 112 of transaction 102 based on the transaction identifier of transaction 102, which can be helpful, for example, in determining which records 112 should be removed if transaction 102 is being rolled back. The metadata may also include an indication of whether the transaction is active or committed, which can be used to determine whether its records 112 can be marked as flushed to database 108.

[0026] In one implementation, skip list 140 is a data structure that maintains the order of keys in record 112 to allow for forward and backward scans of the keys. In some implementations, database 108 may be configured such that records 112 of committed transaction 102 are refreshed in ascending key order (and version order); skip list 140 allows this ordering to be determined quickly and easily. Reference will be made below. Figure 3 In more detail, in some embodiments, skip list 140 includes indirect pointers for accessing record 112 of skip list 140. That is, instead of having direct pointers between records 112 (i.e., pointers specifying the memory address of record 112), skip list 140 includes indirect pointers to hash bucket 124, which includes direct pointers to chain 110. Advantageously, if a new record 112 is added to record chain 110, the direct pointer in hash bucket 124 is updated, not the indirect pointer in skip list 140. The use of indirect pointers also allows skip list 140 to utilize hash bucket latch 126 when manipulating record 112 relative to list 140. Thus, if record 112 of transaction 102 is being accessed via skip list 140 for modification or removal, latch 126 can be acquired for the key of record 112 to prevent further modifications. Although with Figure 1 Record 112 is shown separately, but in some implementations, a portion of skip list 140 may reside in record 112, as will be shown in reference to Figure 2 and 3 As discussed.

[0027] When record 112, used for committing transaction 102, is flushed, the contents of record 112 can remain in buffer data structure 106 until it can be confirmed that they have been successfully written to the permanent storage of database 108. Record 112 can then be marked for clearing, as its contents may no longer be needed, and additional space in buffer data structure 106 is freed up for the new database transaction 102. To facilitate this clearing, it may be necessary to update the pointers used to implement record chain 110, active transaction list 130, and skip list 140.

[0028] In one implementation, the cleanup engine 150 is a component of the transaction manager 104 that handles the cleanup of records 112, including updating these pointers. As will be described in more detail below in various implementations, the cleanup engine 150 implements a fast cleanup algorithm for identifying and cleaning records 112 from the skip list 140. As described above, this may include the cleanup engine 150 scanning the skip list 140 in key order to determine if one of the key-value records 112 has been marked for cleanup. As part of this scan, the cleanup engine 150 may maintain a list of unresolved skip list pointers and, in response to identifying a key-value record 112 to be cleaned, replace unresolved pointers in other records 112 with skip list pointers included in the key-value record 112 being cleaned. In various implementations, the cleanup algorithm is also implemented in a manner that allows the transaction manager 104 to continue inserting records 112 into the skip list 140 (and more generally, the buffered data structure 106) while a scan is in progress, in order to reduce the impact of the cleanup engine 150 on the database system 10. As will be discussed, to ensure that the insertion of record 112 does not problematically interfere with the clearing of record 112, the clearing engine 150 can also manage the acquisition of latch 126, locking of record 112, and verification of unresolved pointer information before performing any pointer replacements. In some implementations, the clearing engine 150 can also manage a thread pool of execution threads to implement the parallel fast clearing algorithm mentioned above and discussed in more detail below.

[0029] The contents of record 112 will now be discussed in more detail, including those used to implement skip list 140, to facilitate a better understanding of the fast clearing algorithm discussed in detail later.

[0030] Now go to Figure 2 A block diagram depicts a record chain 110. As shown, the record chain 110 may include a set of key-value records 112A-112C, conflicting records 220, and locked records 230. Record 112 may also include a key 212, a value 213, a transaction identifier 214, a commit identifier 215, a clear flag 216, a lock 217, a skip list pointer 218, and a record chain pointer 219. In some embodiments, chain 110 may include more (or fewer) records 112, 220, or 230 than shown; a given record 112 may also include more (or fewer) elements 212-219 than shown.

[0031] In the illustrated implementation, the record chain 110 is implemented using a linked list, such that each key-value record 112 includes a pointer 219 identifying the next record 112 in the chain 110. When a record 112 is added, it is either inserted at the head of the hash bucket 124, identified by the direct pointer 202, or appended to the conflicting record 220 discussed below. The added record 112 can then include a pointer 219 pointing to the record previously at the head. As the record 112 ages, it migrates towards the tail. Figure 2 The transaction manager 104 can then flush the record 112B (or lock record 230) to the persistent storage of the database 108 and remove it. The transaction identifier 214 for a given record 112 not only identifies the transaction 102 associated with record 112 but also indicates the order in which transactions 102 received it. Therefore, since record 112B is further from the head than record 112A, transaction ID 214B can correspond to a transaction 102 earlier than transaction ID 214A. If the transaction 102 corresponding to transaction ID 214B needs to be rolled back, the transaction manager 104 can locate record 112B by referencing the direct pointer 202 to identify the head of chain 110 and traverse records 112A and 220 until it finds record 112B with the corresponding transaction ID 214B. Record 112B can then be removed, and pointer 222A can be modified to have the same address as pointer 219B. In some implementations, if transaction 102 commits, the commit identifier 215 of its record 112 can be set to reflect the commit and mark record 112 as ready to be flushed to persistent storage in database 108. Record 112 can later be scanned by the process of transaction manager 104 to identify which records 112 have commit identifier 215 and determine which records 112 can be flushed to database 108.

[0032] In some implementations, once the key-value record 112 has been successfully flushed to persistent storage, the transaction manager 104 sets a clear flag 216 to indicate that record 112 is ready to be cleared from the buffer data structure 106. As described above, the clearing engine 150 can read this flag 216 to determine whether record 112 should be cleared from the buffer data structure 106.

[0033] In some implementations, when two different keys (e.g., keys 212A and 213C) produce the same hash value (i.e., a hash collision occurs) and therefore share the same hash bucket 124, a collision record 220 is used to attach record 112 to chain 110. In various implementations, the size of hash table 120 is chosen to have a sufficient number of hash buckets 124 to ensure a low probability of collisions. However, if a hash collision occurs, a record 220 can be inserted, including a pointer 222 pointing to a record 112 with a different key 212. Although in many cases the hash bucket latch 126 is specific to a single corresponding key 212, in this case, the hash bucket latch 126 will be associated with multiple different keys 212.

[0034] As described above, in some embodiments, individual records 112 may also include their own corresponding locks 217 to provide additional consistency control. In some embodiments, when no corresponding value exists, a separate lock record 230 may also be inserted into the record chain 110 to create a lock bound to a specific key.

[0035] In one implementation, skip list pointer 218 is a pointer that forms skip list 140. This will be discussed in the following sections. Figure 3 As discussed, pointers 218 within a given record 112 can form a pointer pyramid, which implements a linked hierarchy of data record sequences, where each successive sequence skips fewer records 112 than the previous sequence. In some implementations, pointers 218 are also implemented using indirect pointers, through which key-value records 112 are linked together in skip list 140 without using direct pointers to the physical addresses of records 112. Instead, pointer 218 references hash bucket 124, which points to a record chain 110 that includes record 112. In various implementations, using indirect pointers greatly simplifies pointer management because only one direct pointer can be maintained for a given record 112. That is, since the position of hash bucket 124 remains constant, if record 112 moves to a later position in, for example, the record chain 110, the indirect pointer is not updated.

[0036] Now go to Figure 3 A block diagram of skip list 140 is depicted. As described above, in various embodiments, skip list 140 can be used to maintain the order of keys 212 stored in record 112, which can be used to refresh the record 112 of committed transaction 102 in ascending order of keys. In the illustrated embodiment, skip list pointers 218 within record 112 form towers 300 pointing to towers 300 in other records 112.

[0037] When searching for a specific key 212 in skip list 140, in the illustrated embodiment, traversal of skip list 140 can begin at the top of the leftmost tower 300 (corresponding to bucket ID 312A1 in the illustrated embodiment), where key 212 in record 112 is compared with the key being searched. If a match is found, the record 112 being searched has been located. If not, the traversal proceeds along the path of forward pointer 314A to another record 112 with another key 212, and compares it. If that key 212 is smaller than the key 212 being searched, the traversal returns to the previous tower 300 and descends to the next level in tower 300 (…). Figure 3 (The position of the middle bucket ID 312A2). However, if the key 212 being searched is greater than another key 212, the traversal proceeds forward along another pointer 314. Then, the process continues until a match is found for the record 112 being searched. The following will combine... Figure 4 This section discusses examples of this traversal.

[0038] Despite Figure 3 For clarity, forward pointer 314 is depicted in (and subsequent figures), but in some embodiments, indirect pointers are used to implement skip list pointer 218. In the illustrated embodiment, skip list pointer 218 is specifically implemented using bucket identifier 312, which points to bucket 124 in hash table 120, and bucket 124 in turn points to record 112 via pointer 202. Thus, advancing along pointer 314C involves following pointer 218 of bucket ID 312A3 to bucket 124 and advancing along pointer 202A to the record chain 110 that includes record 112, which includes pointer 218 of bucket 312B1. Although not shown, in some embodiments, skip list 140 also includes a set of backward pointers, which can be implemented in a similar manner and will be discussed in more detail below.

[0039] When record 112 is finally cleared, the skip pointers 218 residing in other records 112 that point to the cleared record 112 are identified, so that they can be updated to no longer point to the cleared record 112. Once identified, they are updated using the skip list pointers 218 in the cleared record 112. Before discussing the fast clearing algorithm, it is helpful to consider how the less efficient clearing algorithm identifies the relevant skip list pointers 218 to be updated.

[0040] Now go to Figure 4 A block diagram of Slow Clear 400 is depicted. As will be discussed, Slow Clear 400 is less efficient than the Fast Clear algorithm discussed later because it uses a large number of memory accesses to identify relevant records 112 for updating. Figure 4As shown, an example skip list 140 can be constructed from records 112 sorted in order of keys 212A-W. Skip list 140 includes eight levels (shown as levels 1-8) of a forward pointer 314 that allows movement in ascending order of keys and another level (shown as level -1) of a backward pointer that allows movement in descending order of keys. Sentinel tower 300 is located at either end of skip list 140 and does not correspond to record 112 (and is therefore shown with -∞ and ∞ keys). Furthermore, in Figure 4 Each key 212 in the bucket 124 is followed by a bucket identifier 312, which includes a direct pointer 202 pointing to that record 112 (or its record chain 110). Thus, as shown, the bucket 124 with a bucket identifier 312 of 19 includes a pointer 202 pointing to the record 112 with a key 212 of A.

[0041] Slow Clean 400 can be removed from the initial scan ( Figure 4 (Not shown in the original text) The process begins by accessing records 112 in ascending order of buckets to identify those with setting flags 216 indicating they are ready for clearing. Figure 4 In the embodiment depicted, record 112 (or simply "record S") with key 212 of S has been identified as the record to be cleared. Skip list 140 can then be traversed to identify record 112, including skip list pointer 218, as record S. As shown, traversal begins from the top of sentry tower 300 on the left, where a first memory access is performed to read skip list pointer 218 at level 8, which includes bucket ID 312 of 20. A second memory access is then performed to read record 112 pointed to by bucket #20, which is record 112 with key K. Because the key S of the cleared record 112 is greater than key K in key order, traversal continues along level 8, where record W is read during a third memory access. Because key S is less than key W, traversal returns to record K in a fourth memory access to read skip list pointer 218 at level 7 (the next level). As can be seen, the process continues with another twenty memory accesses until record R is identified as having a pointer 218 pointing to bucket #17 of record S. Once all records (records R and T in this embodiment) have been identified as having pointers to record S, their pointers can be updated using pointers from the cleared record 112. For example, record R in bucket #17 can be replaced with bucket #9 of record S, so that when record R is removed, it can point to the past record S.

[0042] As can be seen, the traversal used to remove a record involves twenty memory accesses, not including the memory accesses for the initial scan or the multiple accesses for moving down the record chain 110. Furthermore, if multiple records 112 to be cleared have been identified, the slow clearing 400 may perform multiple traversals. Additionally, in some embodiments, the skip list 140 may include a much taller skip list tower 300 (e.g., a tower with 33 levels) and is substantially wider. All of these memory accesses impact system performance. In many cases, the fast clearing algorithm discussed below uses far fewer memory accesses.

[0043] Now go to Figure 5A A block diagram of a fast clear 500 is depicted. As described above, fast clear 500 can be an algorithm used by clearing engine 150 to remove record 112 from skip list 140. In the illustrated embodiment, fast clear 500 begins by forward scanning 510 of skip list 140 in key order. As shown, scan 510 can begin at sentinel tower 300 shown on the left and efficiently advances in key order using skip list pointer 218 at level 1. In this embodiment, scan 510 moves from sentinel tower 300 to bucket #13 pointing to record B. Then scan 510 uses level 1 skip pointer 218 in record B to move to record C via bucket #22. This process can continue until scan 510 reaches another sentinel tower 300 on the far right.

[0044] In various implementations, forward scan 510 serves a dual purpose: 1) reading the clear flag 216 to identify the record 112 to be cleared, and 2) determining which records 112 need to be updated when a record points to the record 112 to be cleared. This approach contrasts with slow clearing 400, where these actions are handled by separate operations: a downward traversal of skip list 140 following the initial scan. While reading record 112 during scan 510, clearing engine 150 may read the clear flag 216 and store information about the skip list pointer 218 that includes record 112, which is shown as clearing engine information 550. In some implementations, clearing engine 150 also performs a locking 514 on record 112 (meaning clearing engine 150 prevents record 112 from being relocated in memory). This can be performed, for example, to prevent the garbage collection process from moving record 112, to clear record 112 if it is also marked, and so on.

[0045] In the illustrated embodiment, the clearing engine information 500 is a table including rows for each level in the skip list 140. Within each row are a level 552 identifying the skip list level associated with that row, a source record bucket 554 identifying the bucket 124 pointing to record 112, a source record address 556 identifying the physical address where record 112 resides in memory, and a target bucket 124 pointed to by the skip list pointer 218. When record 112 is read during scan 510, each row in the clearing engine information 550 is updated for the height of the tower 300 of record 112. Thus, in the depicted embodiment, record K has a height of 1 (in the illustrated embodiment, level -1 is not considered in the height), so a skip list pointer 218 for it at level 1 is recorded in the level 1 row of the clearing engine information 550. Therefore, row 1 specifies the bucket ID 312 of 41, including the record address 556 of record 112 and the target bucket 558 of 52. This pointer information is retained in the clearing engine information 550 until the pointer is resolved. As described above and... Figure 5A As shown, unresolved pointer 512 is a pointer to record 112 that has not yet been scanned during the forward scan 510. Therefore, in Figure 5A In the embodiment depicted, because record M has not yet been scanned, pointer 218 to bucket 52 is currently unresolved pointer 512. Conversely, resolved pointer 516 is a pointer to a scanned record 112, for example, pointing to... Figure 5A The pointer to the sentry tower of record B. When pointer 218 is resolved, the cleanup engine 150 replaces the update information 550 with the information of the newly scanned record, which will be discussed below.

[0046] Turn now Figure 5B The diagram depicts the information update 520 after clearing engine information 550. (Continue) Figure 5A In this embodiment, the forward scan 510 has now reached bucket #52 and read record M. At this point, pointers 218 in record BK have been resolved. If the newly scanned record M has not been cleared, the clearing engine 150 can perform a delocking 522 on record BK and replace their information in the clearing engine information 550 with the also locked pointer information record M. In this embodiment, record M has six levels of pointers 218 in its tower 300, so all six levels of the clearing engine information 550 are updated. If record M's tower 300 only has three pointers 218, in this embodiment, only three rows will be updated—therefore, rows with levels 4-6 will remain unchanged.

[0047] On the other hand, if the newly scanned record 112 has already been marked as to be cleared, it can be used as follows: Figure 5C and Figure 5D Perform a rapid cleanup of 500 as discussed.

[0048] Now go to Figure 5C The diagram depicts a rapid clearing of bucket identifier replacement 530 for record 500. In this embodiment, clearing engine 150 has already scanned record M and determined from its clearing flag 216 that record 112 will be cleared. To do this, clearing engine 150 updates pointer 218 in skip list 140 to indicate that record M is about to disappear.

[0049] Because the cleanup engine 150 has tracked the unresolved pointer 512, it can know which pointers 218 potentially point to the record 112 being cleaned—and therefore know which pointers 218 are guaranteed to be updated. Figure 5C As depicted in the embodiment, when scanning record M, the cleanup engine information 550 has identified six unresolved pointers 218 at six different levels. Because record M has a tower 300 of height 6, the cleanup engine 150 can assume that the six pointers might point to record M and determine this from the target bucket 558 in the information 550. Using this knowledge, the cleanup engine 150 can perform a bucket ID replacement 530, where the cleanup engine 150 replaces the pointers 218 in record M with the pointers 218 included in record M. For example, as shown, the pointer 218 at level 6 in record B has been changed from bucket #55 to bucket #28, so that record B now points to the past record M. A similar change is also made to the pointers 218 in records CK at levels 1-5. If record M has a shorter tower 300 (e.g., four levels), only a subset of these pointers 218 (e.g., those in record EK) is updated. In various implementations, the clearing engine 150 continuously locks the records 112 being updated and cleared while performing these replacements 530. As shown, the clearing engine information 550 is also updated to reflect these changes, because these updated pointers 218 can still point to later scanned records 112 marked for clearing. In the illustrated implementation, the level-1 pointer 218 of record N preceding record M is updated to point to record K. In such an implementation, the level-1 pointers can be tracked without using the clearing engine information 550, as they can be easily identified by traversing the level-1 pointers 218 in the records 112 being cleared, using the backward pointer 218 to identify the next record 112 in ascending key order.

[0050] As described above, in some implementations, while fast cleanup 500 is being performed, transaction manager 104 is still allowed to insert record 112 into buffer data structure 106, because preventing insertion could have a significant impact on system performance. However, because insertion could potentially interfere with the cleanup of record 112, cleanup engine 150 can perform verification of cleanup engine information 550, as will be discussed, before using it for any bucket ID replacement 530.

[0051] Turn now Figure 5D A block diagram depicts the verification 540 of the collected clear engine information 550. Since the clear engine information 550 may become outdated if a new record 112 has been inserted, in various embodiments, the clear engine 150 verifies that the information 550 has not become incorrect before it is used for replacement 530.

[0052] In various implementations, the cleanup engine 150 performs verification 540 by accessing record 112 using source record address 556. The cleanup engine 150 can then verify that pointer 218 at level 552 still points to the same bucket ID 312 identified by target bucket 558. If these pointers still match the content recorded in information 550 (such as...), then... Figure 5D If the successful verification in 540A shown on the left is successful, then the cleanup engine 150 can continue to execute the bucket ID replacement 530 discussed earlier.

[0053] In some cases, a mismatch may occur if the inserted record 112 has a sufficiently high tower 300 to block a record 112 that previously pointed to the record 112 being cleared. For example, in Figure 5D In the unsuccessful verification 540B shown on the right, record H with a tower height of 4 was inserted. This caused the level 2-4 pointers in records E and G to point to bucket #35 instead of bucket #52 where record M is located. Therefore, when the purge engine 150 goes to verify the purge engine information 550, it is no longer consistent with what is actually in the skip list 140. If this happens, it is not a problem because in some implementations, the purge engine 150 delays the purge of record 112 until another subsequent scan 510 is performed. In this embodiment, although record M can be allowed to remain for a longer time, it will eventually be purged. However, if record H includes a shorter tower 300 (e.g., it has a height of 1), its insertion will not interfere with the purge engine information 550 because the level 1 pointer 218 in record K that currently points to the record M being purged has not changed. Therefore, the purge engine 150 will successfully verify information 550 and continue to perform bucket ID replacement 530.

[0054] Because record chain 110 and / or record 112 may also have the potential to be modified during verification 540 and replacement 530, the clearing engine 150 may also handle acquiring latches 126 and / or locks 217 to prevent modification during verification 540 and replacement 530. In some embodiments, this may include acquiring latches 126 and / or locks 217 associated with the cleared record 112, the record 112 identified in the clearing engine information 550, and the record 112 that appears in key order after the record is cleared, as this may include backward pointers that may need to be updated. In such embodiments, latches 126 and / or locks 217 may be acquired in response to identifying the record 112 that is cleared and held throughout verification 540 and replacement 530.

[0055] Now go to Figure 6 A block diagram depicts the inputs and outputs of a clearing engine 150. In the illustrated embodiment, the clearing engine 150 receives tower level 552, source record bucket 554, source record address 556, and target bucket ID 558 from the record 112 being scanned in the forward scan 510. The clearing engine 150 can then use this information to maintain and update the clearing engine information 550. The clearing engine 150 can also receive a clearing flag 216, which can again be used to determine whether record 112 should be cleared. Based on this information, the clearing engine 150 can output instructions to the locked 514 or unlocked 522 record 112, the result 602 for verification 540, the bucket ID 312 for bucket replacement 530, the cleared record 112, and instructions for modifying latches 126 and locks 217. In some embodiments, the clearing engine 150 may have more (or fewer) inputs and outputs.

[0056] Although the clearing engine 150 can sequentially perform a scan 510 of the entire jump list 140, in some implementations, additional performance gains can be achieved by scanning multiple sections in parallel, which will be discussed below.

[0057] Now go to Figure 7 A block diagram of parallel fast clearing 700 is depicted. As will be discussed, the clearing engine 150 can perform parallel fast clearing 700 by dividing the skip list 140 into portions 720 that are processed by independent threads executed in parallel.

[0058] In the illustrated implementation, parallel fast clearing 700 begins with the clearing engine 150 determining how to divide the skip list 140 by performing a traversal 710 of the top of the skip list 140 in order to identify the record 112 with the highest tower 300 in the skip list 140. The advantage of identifying these records 112 is that they can serve as the leftmost boundary of each section 720, which can be helpful because they ensure that most unresolved pointers 512 are local for a given section 720, as they may include the local maximum tower height of that section 720—assuming no record 112 with an even higher tower 300 was inserted during this period. For example, in Figure 7 In the middle, the tallest tower 300 is stationed in the left sentry tower, and bucket 124 with bucket IDs 20, 9, 24, and 3 points to record 112. When the clearing engine 150 traverses downwards from the top, the clearing engine 150 can target the creation of a specific number of sections 720, which can affect how far the engine 150 descends. Figure 7 In the illustrated embodiment, the cleanup engine 150 may aim to create five sections 720 and thus may continue traversing down the jump list 140 until it has identified that many unique bucket identifiers 312. Therefore, in the illustrated embodiment, the cleanup engine 150 traverses down 8-6 levels before being able to identify five unique bucket identifiers 312, and then uses the five unique bucket identifiers 312 to create five sections 720.

[0059] Once portion 720 is determined, in some implementations, the cleanup engine 150 instantiates a thread pool with multiple threads and begins allocating portion 720 to threads for scanning. Each executing thread then uses the fast cleanup 500 discussed above to scan its allocated portion 720 (including maintaining its own copy of the cleanup engine information 550 with an unresolved pointer 512 for its allocated portion 720) and clean up the marked records 112. If there are fewer threads in the thread pool than portions 720, a thread can loop back to receive another allocated portion 720 from the cleanup engine 150 once it has finished working on the previously allocated portion 720.

[0060] When threads scan their allocated portion 720, they can determine that the initial record 112 at the left boundary of portion 720 has been marked for clearing. In some implementations, these threads may notice that these records 112 are ready for clearing, but not clear them until portion 720 has been scanned. At this point, the clearing engine 150 can perform a slow clearing 400 only on those marked records 112—therefore, the clearing engine 150 only traverses the skip list 140 down for a small number of records 112, rather than clearing every single record 112.

[0061] We will now discuss various methods of using one or more of the techniques discussed above.

[0062] Turn now Figure 8A A flowchart is depicted for a method 800 for quickly clearing records from a skip list. Method 800 is one implementation of a method performed by a computing system such as database system 10, which may be executing a clearing engine 150. In some instances, the execution of method 800 can reduce the burden of clearing records from the skip list.

[0063] In step 805, a skip list (e.g., skip list 140) is stored, comprising multiple key-value records (e.g., key-value record 112), each key-value record including one or more pointers (e.g., skip list pointer 218) to other key-value records among the multiple key-value records. In some embodiments, the key-value record is inserted into the skip list in response to a request to execute a database transaction (e.g., database transaction 102) associated with the key-value record. In response to a database transaction commit and the key-value record being stored in persistent storage (e.g., the LSM tree of database 108), a flag (e.g., clear flag 216) is set in the key-value record to indicate authorization to clear the key-value record. In some embodiments, a first of the multiple key-value records in the skip list is pointed to a second of the multiple key-value records in the skip list by a first pointer (e.g., indirect pointer 312) including a pointer to a bucket (e.g., bucket 124) in a hash table (e.g., hash table 120), wherein the bucket includes a second pointer (e.g., direct pointer 202) to the second key-value record.

[0064] In step 810, multiple key-value records are scanned in key order to identify key-value records to be removed from the skip list. In various embodiments, the scan includes maintaining a list of key-value records (e.g., clearing engine information 550), where each key-value record includes pointers to key-value records not yet scanned by the scan (e.g., unresolved pointer 512). In some embodiments, the scan includes determining that a pointer to a first key-value record included in the list (e.g., resolved pointer 516) points to a second key-value record that has already been scanned. In response to this determination, the first key-value record in the list is replaced by the second key-value record (e.g., via information update 520). When the second key-value record is included in the list, relocation of the second key-value record in memory is prevented (e.g., via lock 514). In some embodiments, one or more key-value records are inserted into the skip list during the scan. In some embodiments, the scan includes identifying key-value records to be cleared based on a set flag.

[0065] In step 815, in response to identifying a key-value record to be cleared, the key-value record is cleared by replacing (e.g., bucket ID replacement 530) a pointer included in a list of key-value records with a pointer included in the key-value record being cleared. In some embodiments, in response to identifying a key-value record to be cleared, a verification of the list of key-value records is performed (e.g., verification 540), including determining whether a pointer included in the list of key-value records points to the key-value record to be cleared. In some embodiments, in response to determining that an insertion has caused one or more pointers included in the list of key-value records not to point to the key-value record to be cleared, the clearing of the key-value record is delayed until a subsequent scan is performed. In some embodiments, a latch (e.g., latch 126 and / or lock 217) is acquired to prevent modification of the key-value record by processes other than the process of performing a scan. The latch is held until after the pointer included in the list of key-value records has been replaced with a pointer included in the key-value record being cleared.

[0066] In some implementations, method 800 further includes traversing downwards (e.g., via upper skip list traversal 710) of the skip list to identify a subset of the multiple key-value records before scanning the multiple key-value records in key order. Based on the key-value records in the identified subset, the skip list is divided into multiple portions (e.g., portion 720). The portions are assigned to multiple threads executable to scan the portions in parallel. In some implementations, one of the multiple threads receives the assigned portion to scan and scans the assigned portion, including maintaining a list of key-value records with unresolved pointers for the assigned portion. In response to identifying key-value records to be cleared in the assigned portion, the thread uses the list of key-value records for the assigned portion to clear the key-value records in the assigned portion.

[0067] Turn now Figure 8B A flowchart is depicted for a method 830 for quickly clearing records from a skip list. Method 830 is another implementation of a method performed by a computing system such as database system 10, which may be executing a clearing engine 150. In some instances, the execution of method 830 can reduce the burden of clearing records from the skip list.

[0068] In step 835, the computing system stores a skip list (e.g., skip list 140) that maintains the order of keys (e.g., key 212) of key-value records (e.g., key-value record 112) in the database (e.g., database 108). In some embodiments, the skip list maintains the order of keys of key-value records of database transactions awaiting commit.

[0069] In step 840, the computing system identifies key-value records to be cleared from the skip list. In the illustrated embodiment, step 840 includes, in substep 841, scanning the skip list in key order to determine whether one of the key-value records contains an indication that clearing is permitted (e.g., clear flag 216). In some embodiments, prior to scanning, the computing system traverses the top of the skip list (e.g., via upward skip list traversal 710) to determine partitions of the skip list for parallel scanning (e.g., portion 720). The computing system assigns the partitions to multiple threads capable of performing scans of the partitions in parallel with each other. In the illustrated embodiment, step 840 also includes recording an unresolved pointer (e.g., unresolved pointer 512) in the skip list to one of the key-value records that has not yet been scanned.

[0070] In step 845, in response to identifying a key-value record to be cleared, the computing system clears the key-value record by replacing (e.g., via bucket ID replacement 530) one of the unresolved pointers included in the key-value record being cleared. In some embodiments, during the scan, the computing system inserts one or more key-value records into the skip list. In response to identifying a key-value record to be cleared, the computing system verifies (e.g., verification 540) after inserting one or more key-value records that one of the unresolved pointers still points to the key-value record to be cleared. In some embodiments, in response to determining that at least one of the unresolved pointers no longer points to the key-value record to be cleared, the computing system delays the clearing of the key-value record until a subsequent scan of the skip list is performed.

[0071] Now go to Figure 8C A flowchart is depicted for a method 860 for parallel and rapid record clearing. Method 860 is another implementation of a method executed by a computing system such as database system 10, which may be executing clearing engine 150. In some instances, the execution of method 860 can reduce the time spent identifying and clearing records from a skip list.

[0072] In step 865, a skip list (e.g., skip list 140) is maintained, which holds the sorting of keys (e.g., key 212) for multiple key-value records (e.g., record 112). In various embodiments, a key-value record is inserted into the skip list when a database transaction (e.g., database transaction 102) corresponding to the inserted key-value record is awaiting commit. In response to a database transaction commit corresponding to one of the inserted key-value records, a flag (e.g., clear flag 216) is set in the inserted key-value record to indicate that the inserted key-value record can be cleared from the skip list. In some embodiments, the first of the multiple key-value records in the skip list indirectly points to the second of the multiple key-value records via a first pointer (e.g., indirect pointer 312) that includes a pointer to a bucket (e.g., bucket 124) in a hash table (e.g., hash table 120), and the bucket includes a second pointer (e.g., direct pointer 202) that points to the second key-value record.

[0073] In step 870, the skip list is divided into portions identified by traversing the top of the skip list (e.g., via upward skip list traversal 710). Figure 7 Record 112 with key G in part 720B.

[0074] In step 875, a portion is allocated to multiple threads, each of which can execute in parallel to scan the allocated portion of the skip list in key order to identify key-value records to be cleared from the skip list. In some implementations, the first of the multiple threads maintains a list (e.g., clear engine information 550) of unresolved pointers (e.g., unresolved pointer 512) of the portion allocated to the first thread, which are pointers to key-value records not yet scanned by the first thread that are included in the key-value records scanned by the first thread. In response to identifying a key-value record in the allocated portion to be cleared, the first thread replaces (e.g., via bucket ID replacement 530) one of the unresolved pointers with a pointer included in the key-value record being cleared.

[0075] In some implementations, method 860 further includes, after allocating portions for multiple threads, accessing key-value records used as boundaries of the portions to identify one of the boundary key-value records to be cleared. In response to identifying the boundary key-value record to be cleared, a skip list is traversed downwards to identify the key-value record to be updated in response to the clearing of the boundary key-value record.

[0076] Exemplary computer system

[0077] Now go to Figure 9This document depicts a block diagram of an exemplary computer system 900 that can implement the functions described herein, such as database system 10, a portion of database system 10, or a client interacting with database system 10. Computer system 900 includes a processor subsystem 980 connected to system memory 920 and I / O interface 940 via interconnect 960 (e.g., a system bus). I / O interface 940 is connected to one or more I / O devices 950. Computer system 900 can be any of a variety of types of devices, including but not limited to server systems, personal computer systems, desktop computers, laptop or notebook computers, mainframe computer systems, tablet computers, handheld computers, workstations, network computers, and consumer devices such as mobile phones, music players, or personal data assistants (PDAs). Although for convenience, Figure 9 The diagram shows a single computer system 900, but system 900 can also be implemented as two or more computer systems operating together in a cluster.

[0078] Processor subsystem 980 may include one or more processors or processing units. In various embodiments of computer system 900, multiple instances of processor subsystem 980 may be coupled to interconnect 960. In various embodiments, processor subsystem 980 (or each processor unit within 980) may include cache or other forms of on-board memory.

[0079] System memory 920 may be used to store program instructions executable by processor subsystem 980 to cause system 900 to perform the various operations described herein. System memory 920 may be implemented using various physical non-transitory storage media, such as hard disk storage, floppy disk storage, removable disk storage, flash memory, random access memory (RAM-SRAM, EDO RAM, SDRAM, DDR SDRAM, RAMBUS RAM, etc.), read-only memory (PROM, EEPROM, etc.), etc. The memory in computer system 900 is not limited to main memory, such as memory 920. Instead, computer system 900 may also include other forms of memory, such as cache memory in processor subsystem 980 and auxiliary memory (e.g., hard disk drive, storage array, etc.) on I / O devices 950. In some embodiments, these other forms of memory may also store program instructions executable by processor subsystem 980 to cause system 900 to perform the operations described herein. In some embodiments, memory 920 may include portions of transaction manager 104, cleanup engine 150, buffered data structure 106, and / or database 108.

[0080] According to various implementations, I / O interface 940 can be any of various types of interfaces configured to connect to and communicate with other devices. In one implementation, I / O interface 940 is a bridge chip (e.g., a southbridge) from the front end to one or more back-end buses. I / O interface 940 can be connected to one or more I / O devices 950 via one or more corresponding buses or other interfaces. Embodiments of I / O device 950 include storage devices (hard disk drives, optical drives, removable flash drives, storage arrays, SANs, or their associated controllers), network interface devices (e.g., to a local area network or wide area network), or other devices (e.g., graphics, user interface devices, etc.). In one implementation, computer system 900 is connected to a network via network interface device 950 (e.g., configured to communicate via WiFi, Bluetooth, Ethernet, etc.).

[0081] While specific embodiments have been described above, these embodiments are not intended to limit the scope of the disclosure, even if only a single embodiment is described for a particular feature. Unless otherwise stated, embodiments of features provided in the disclosure are intended to be illustrative rather than restrictive. The above description is intended to cover such substitutions, modifications, and equivalents that will be apparent to those skilled in the art who benefit from the disclosure.

[0082] The scope of the disclosed text includes any feature or combination of features disclosed herein (explicitly or implicitly), or any generalization thereof, whether or not it alleviates any or all the problems addressed herein. Therefore, during the examination of this application (or an application claiming priority thereto), new claims may be made for any such combination of features. Specifically, referring to the appended claims, features from dependent claims may be combined with features from independent claims, and features from individual independent claims may be combined in any suitable manner, not just in the specific combinations listed in the appended claims.

[0083] Public texts include references to “one” implementation or a set of “implementations” (e.g., “some implementations” or “various implementations”). An implementation is a different way or instance of the disclosed concept. References to “implementation,” “one implementation,” “specific implementation,” etc., do not necessarily refer to the same implementation. A large number of possible implementations are envisioned, including those specifically disclosed implementations as well as modifications or substitutions that fall within the spirit or scope of the public text.

[0084] The disclosure may discuss potential advantages that may arise from the disclosed embodiments. Not all implementations of these embodiments necessarily exhibit any or all of the potential advantages. Whether an advantage is realized for a particular implementation depends on many factors, some of which are beyond the scope of the disclosure. In fact, there are many reasons why an implementation falling within the scope of the claims may not exhibit some or all of the disclosed advantages. For example, a particular implementation may include circuitry outside the scope of the disclosure that, when combined with one of the disclosed embodiments, negates or diminishes one or more of the disclosed advantages. Furthermore, suboptimal design execution of a particular implementation (e.g., the implementation technique or tool) may also negate or diminish the disclosed advantages. Even assuming skillful implementation, the realization of an advantage may still depend on other factors, such as the environmental circumstances in which the implementation is deployed. For example, the inputs provided to a particular implementation may prevent one or more problems addressed in the disclosure from occurring in a particular context, and as a result, the benefits of its solution may not be realized. Given the possibility of factors beyond the disclosure, it is expressly stated that any potential advantages described herein should not be construed as a limitation of the claims that must be satisfied to prove infringement. Rather, the identification of such potential advantages is intended to illustrate the type of improvement available to a designer who benefits from the disclosure. Describing these advantages permissively (e.g., stating that a particular advantage "may occur") is not intended to convey doubt about whether these advantages can actually be realized, but rather to acknowledge that the realization of these advantages often depends on the technological reality of additional factors.

[0085] Unless otherwise stated, the embodiments are non-limiting. That is, the disclosed embodiments are not intended to limit the scope of the claims drafted based on the disclosure, even if only a single embodiment is described for a particular feature. The disclosed embodiments are intended to be illustrative rather than limiting, and there is no statement to the contrary in the disclosure. Therefore, this application is intended to allow for claims covering the disclosed embodiments, as well as substitutions, modifications, and equivalents that will be apparent to those skilled in the art who benefit from the disclosure.

[0086] For example, features in this application can be combined in any suitable manner. Therefore, during the examination of this application (or an application claiming priority thereto), new claims can be made for any such combination of features. In particular, referring to the appended claims, features of dependent claims can be combined with features of other dependent claims, including claims dependent on other independent claims, where appropriate. Similarly, features from various independent claims can be combined where appropriate.

[0087] Therefore, while appended dependent claims can be drafted such that each dependent claim depends on a single other claim, additional dependent claims may also be considered. Any combination of features in dependent claims consistent with the published text is contemplated and may be claimed in this application or another application. In short, combinations are not limited to those specifically listed in the appended claims.

[0088] Where appropriate, it is also anticipated that claims drafted in one format or statutory type (e.g., apparatus) are intended to support corresponding claims in another format or statutory type (e.g., method).

[0089] Because the published text is a legal document, various terms and phrases may be subject to administrative and judicial interpretation. Therefore, it is hereby announced that the following paragraphs, as well as the definitions provided throughout the publication, will be used to determine how to interpret the claims drafted based on the published text.

[0090] Unless the context clearly specifies otherwise, references to the singular form of an item (i.e., a noun or noun phrase preceded by "a," "an," or "the") are intended to mean "one or more." Therefore, without accompanying context, a reference to "item" in a claim does not exclude additional instances of that item. "A plurality of" items refers to a group of two or more items.

[0091] The word "may" used in this article is permissive (i.e., possible, able) rather than mandatory (i.e., required).

[0092] The terms “including” and “comprise” and their forms are open-ended, meaning “including but not limited to”.

[0093] When the term “or” is used in public texts concerning a list of options, it is generally understood to be used in an inclusive sense unless the context otherwise specifies. Therefore, a statement of “x or y” is equivalent to “x or y or both,” thus encompassing 1) x but excluding y, 2) y but excluding x, and 3) both x and y. On the other hand, phrases such as “x or y, but excluding both” indicate that “or” is used in an exclusive sense.

[0094] The statements “w, x, y, or z or any combination thereof” or “...at least one of w, x, y, and z” are intended to cover all possibilities involving a single element up to the total number of elements in the set. For example, given the set [w, x, y, z], these terms cover any single element of the set (e.g., w, but excluding x, y, or z), any two elements (e.g., w and x, but excluding y or z), any three elements (e.g., w, x, and y, but excluding z), and all four elements. The phrase “...at least one of w, x, y, and z” therefore refers to at least one element in the set [w, x, y, z], thus covering all possible combinations in the list of elements. This phrase should not be interpreted as requiring the existence of at least one instance of w, at least one instance of x, at least one instance of y, and at least one instance of z.

[0095] In public text, various “labels” may precede nouns or noun phrases. Unless the context otherwise specifies, different labels used for a feature (e.g., “first circuit,” “second circuit,” “specific circuit,” “given circuit,” etc.) refer to different instances of that feature. Furthermore, when applied to features, the labels “first,” “second,” and “third” do not imply any type of ordering (e.g., spatial, temporal, logical, etc.) unless otherwise stated.

[0096] The phrase "based on" is used to describe one or more factors that influence the determination. This term does not exclude the possibility that additional factors might influence the determination. That is, the determination can be based solely on the specified factors or on the specified factors along with other unspecified factors. Consider the phrase "A is determined based on B." This phrase specifies that B is a factor used to determine A or a factor influencing the determination of A. This phrase does not exclude the possibility that the determination of A could also be based on another factor, such as C. This phrase is also intended to cover implementations where A is determined solely based on B. As used herein, the phrase "based on" is synonymous with the phrase "at least partially based on."

[0097] The phrases “responding to” and “responsive” describe one or more factors that trigger an effect. This phrase does not exclude the possibility that additional factors may influence or otherwise trigger the effect, whether in conjunction with or independently of a specific factor. That is, an effect may respond only to those factors, or it may respond to the specified factor as well as other unspecified factors. Consider the phrase “responding to B to execute A.” This phrase specifies that B is a factor that triggers the execution of A or triggers a specific result of A. This phrase does not exclude that the execution of A may also respond to some other factor, such as C. This phrase also does not exclude that the execution of A may jointly respond to B and C. This phrase is also intended to cover implementations where A is executed only in response to B. As used herein, the phrase “responding to” is synonymous with the phrase “at least partially responding to.” Similarly, the phrase “responding to” is synonymous with the phrase “at least partially responding to.”

[0098] In public texts, different entities (which may be referred to differently as “units,” “circuits,” other components, etc.) may be described or required to be “configured” to perform one or more tasks or operations. This expression—[entity] configured to perform one or more tasks—is used in this document to refer to a structure (i.e., something physical). More specifically, this expression is used to indicate that the structure is set up to perform one or more tasks during operation. It can be said that a structure is “configured” to perform some tasks, even if the structure is not currently being operated. Therefore, an entity described or stated as “configured to” perform a task refers to something physical, such as a device, circuit, system with processor units and memory storing program instructions executable to perform that task, etc. This phrase is not used in this document to refer to intangible things.

[0099] In some cases, various units / circuits / components may be described herein as performing a set of tasks or operations. It should be understood that these entities are "configured" to perform those tasks / operations, even if not specifically indicated otherwise.

[0100] The term "configured as" does not mean "configurable as." For example, an unprogrammed FPGA is not considered "configured as" to perform a specific function. However, such an unprogrammed FPGA can be "configurable as" to perform that function. After proper programming, an FPGA can be said to be "configured as" to perform a specific function.

[0101] For the purposes of a U.S. patent application based on a published text, a statement of a structure in a claim that is “configured” to perform one or more tasks is not expressly intended to invoke 35 U.S.SC § 112(f) for that claim element. If an applicant wishes to invoke section 112(f) during the proceedings of a U.S. patent application based on a published text, a “component” structure for [performing a function] will be used to state the claim element.

Claims

1. A non-transitory computer-readable medium having program instructions stored thereon, the program instructions enabling a computing system to perform operations including: The storage includes a skip list comprising multiple key-value records, each key-value record including one or more pointers to other key-value records among the multiple key-value records; Scanning the plurality of key-value records in key order to identify key-value records to be removed from the skip list, wherein the scan includes: Maintain a list of key-value records that includes pointers to key-value records that have not yet been scanned by the scan; and In response to identifying a key-value record to be cleared, the key-value record is cleared by replacing the pointer in the key-value record included in the list with the pointer included in the key-value record being cleared.

2. The computer-readable medium of claim 1, wherein the operation further comprises: In response to a request to execute a database transaction associated with the key-value record, the key-value record is inserted into the skip list; and In response to committing the database transaction and storing the key-value record in the database's persistent storage, a flag is set in the key-value record to indicate authorization to clear the key-value record; and The scan includes identifying key-value records to be cleared based on set flags.

3. The computer-readable medium of claim 1, wherein the scanning comprises: Determine that the pointer to the first key-value record included in the list points to the second key-value record that has already been scanned; In response to the determination: Replace the first key-value record in the list with the second key-value record; and While including the second key-value in the list, the second key-value record is prevented from being relocated in memory.

4. The computer-readable medium of claim 1, wherein the operation further comprises: While performing the scan, one or more key-value records are inserted into the skip list.

5. The computer-readable medium of claim 4, wherein the operation further comprises: In response to identifying the key-value record to be cleared, a validation of the list of key-value records is performed, wherein the validation includes: Determine whether a pointer in the key-value record included in the list points to the key-value record to be cleared.

6. The computer-readable medium of claim 5, wherein the operation further comprises: In response to determining that the insertion has caused one or more pointers in the key-value records included in the list to no longer point to the key-value record to be cleared, the clearing of the key-value record is delayed until a subsequent scan is performed.

7. The computer-readable medium of claim 5, wherein the verification comprises: Acquire a latch to prevent modification of the key-value record by any process other than performing the scan; and Hold the latch until after the pointer included in the key-value record in the list is replaced with a pointer included in the key-value record being cleared.

8. The computer-readable medium of claim 1, wherein the operation further comprises: Before scanning the multiple key-value records in key order: Traverse the skip list downwards to identify a subset of the multiple key-value records; Based on the key-value records in the identified subset, the skip list is divided into multiple parts; and The portion is assigned to multiple threads capable of performing parallel scans of the portion.

9. The computer-readable medium of claim 8, wherein the operation further comprises: The portion of the scan is assigned to one of the plurality of threads; The thread scans the allocated portion, wherein scanning the allocated portion includes maintaining a list of key-value records with unresolved pointers for the allocated portion; and In response to identifying key-value records to be cleared in the allocated portion, the thread uses a list of key-value records for the allocated portion to clear the key-value records in the allocated portion.

10. The computer-readable medium of claim 1, wherein the first of the plurality of key-value records in the skip list is pointed to the second of the plurality of key-value records in the skip list by a first pointer including a bucket in a hash table, wherein the bucket includes a second pointer to the second key-value record.

11. A method for clearing records from a skip list, comprising: The skip list is stored by the computing system, and the skip list maintains the order of the keys of the key-value records in the database; The computing system identifies key-value records to be removed from the skip list, including: The skip list is scanned in key order to determine which of the key-value records contains an indication that clearing is permitted; The skip list records unresolved pointers to key-value records, wherein the unresolved pointers point to one or more key-value records that have not yet been scanned by the scan; and In response to identifying a key-value record to be cleared, the computing system clears the key-value record by replacing one of the unresolved pointers with a pointer included in the key-value record being cleared.

12. The method of claim 11, further comprising: Prior to the scan, the computing system traverses the top of the skip list to determine the partitioning of the skip list for parallel scanning; and The computing system distributes the partition to multiple threads that are capable of scanning the partition in parallel with each other.

13. The method of claim 11, further comprising: During the scan, the computing system inserts one or more key-value records into the skip list; and In response to identifying the key-value record to be cleared, the computing system verifies, after inserting the one or more key-value records, that the one or more unresolved pointers still point to the key-value record to be cleared.

14. The method of claim 13, further comprising: In response to determining that at least one of the unresolved pointers no longer points to the key-value record to be cleared, the clearing of the key-value record is delayed until a subsequent scan of the skip list is performed.

15. The method of claim 11, wherein the skip list maintains the order of the keys of the key-value records of the database transactions awaiting commit.

16. A non-transitory computer-readable medium having program instructions stored thereon, the program instructions enabling a computing system to perform operations including: Maintain a skip list that preserves the order of keys for multiple key-value records; The skip list is divided into multiple parts, wherein the parts are identified by traversing the top of the skip list to identify one or more of the key-value records that will be used as the boundaries of the parts; and The portion is allocated to multiple threads, each capable of executing in parallel while scanning the allocated portion of the skip list in key order to identify key-value records to be removed from the skip list. The operation also includes: The first of the plurality of threads maintains a list of unresolved pointers allocated to the portion of the first thread, wherein the unresolved pointers are pointers included in the key-value records scanned by the first thread that point to key-value records that have not yet been scanned by the first thread; and In response to identifying the key-value record to be cleared in the allocated portion, the first thread replaces one or more of the unresolved pointers with pointers included in the key-value record to be cleared.

17. The computer-readable medium of claim 16, wherein the operation further comprises: After the multiple threads scan the allocated portion: Access the key-value records that serve as the boundaries of the portion to identify one or more of the boundary key-value records to be cleared; and In response to identifying a boundary key-value record to be cleared, the skip list is traversed downwards to identify key-value records that are updated in response to the boundary key-value record to be cleared.

18. The computer-readable medium of claim 16, wherein the operation further comprises: When the database transaction corresponding to the inserted key-value record is waiting to be committed, the key-value record is inserted into the skip list; and In response to a database transaction commit corresponding to one of the inserted key-value records, a flag is set in the inserted key-value record to indicate that the inserted key-value record is allowed to be cleared from the skip list.

19. The computer-readable medium of claim 16, wherein the first of the plurality of key-value records in the skip list is indirectly pointed to the second of the plurality of key-value records by including a first pointer to a bucket in a hash table, wherein the bucket includes a second pointer to the second key-value record.

Images