Fast Skiplist Purge

Abstract

Techniques related to efficiently managing a skip list data structure are disclosed. In some embodiments, a computing system stores a skip list including a plurality of key-value records, the plurality of key-value records including one or more pointers to other ones of the plurality of key-value records. The computing system scans the plurality of key-value records in key order to identify key-value records to be purged from the skip list. The scan includes maintaining a list of key-value records including pointers to key-value records not yet scanned by the scan. In response to identifying a key-value record to be purged, the computing system purges the key-value record by replacing a pointer included in the key-value record in the list with a pointer included in the key-value record being purged.

Description

[Technical field]

[0001] The present disclosure relates generally to data storage, and more particularly to manipulating skip list data structures. [Background technology]

[0002] In the field of computer science, various complex data structures have been developed to facilitate the storage of information. These data structures are often constructed using multiple pointers to join a collection of records together. When designing complex structures, developers often ponder concerns related to the overall data structure size as well as the complexity of inserting and retrieving information. A skip list is an example of a more complex data structure, which may be popular because it can maintain large data sets while still offering an insertion complexity of O(log n) and a search complexity of O(log n). In this type of data structure, records are sorted based on key order and related using a linked hierarchy of data record sequences, with each successive sequence skipping fewer elements than the previous sequence. This linked hierarchy is implemented using pointer towers of various heights, such that within a given tower, pointers may be positioned based on the number of records skipped. This ability to skip records as the skip list is traversed may allow a given record to be located more quickly than scanning the records sequentially. [Brief description of the drawings]

[0003] [Figure 1] FIG. 1 is a block diagram illustrating one embodiment of a database system that uses skip lists in a buffer data structure to process concurrent database transactions. [Diagram 2] FIG. 2 is a block diagram illustrating one embodiment of record chaining in a buffer data structure. [Diagram 3]FIG. 2 is a block diagram illustrating one embodiment of a skip list within a buffer data structure. [Figure 4] FIG. 1 is a block diagram illustrating one embodiment of a slow purge process for purging records from a skip list. [Figure 5A] FIG. 1 illustrates an embodiment of a fast purge process for purging records from a skip list. [Figure 5B] FIG. 1 illustrates an embodiment of a fast purge process for purging records from a skip list. [Figure 5C] FIG. 1 illustrates an embodiment of a fast purge process for purging records from a skip list. [Figure 5D] FIG. 1 illustrates an embodiment of a fast purge process for purging records from a skip list. [Figure 6] FIG. 2 is a block diagram illustrating one embodiment of a purge engine that performs purging of skip lists. [Figure 7] FIG. 1 illustrates one embodiment of a parallel fast purge process for purging records from a skip list. [Figure 8A] FIG. 1 is a flow diagram illustrating an embodiment of a method associated with purging records from a skip list. [Figure 8B] FIG. 1 is a flow diagram illustrating an embodiment of a method associated with purging records from a skip list. [Figure 8C] FIG. 1 is a flow diagram illustrating an embodiment of a method associated with purging records from a skip list. [Figure 9] FIG. 1 is a block diagram illustrating one embodiment of an exemplary computer system. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0004] In some instances, skip lists may be used to maintain large amounts of frequently manipulated information. For example, as described in more detail below, a database system may use a buffer data structure to store data of active database transactions until the database transactions are committed and the data can be flushed to the database system's persistent storage. The buffer data structure may include a skip list data structure that allows efficient storage and lookup of transaction records in key order. As the database system potentially processes high volumes of transactions in parallel, efficient maintenance of the skip list may be important to database performance.

[0005] This disclosure describes embodiments that use a fast purge algorithm to efficiently purge records from a skip list when they are no longer in use. As described below in various embodiments, the key-value records of a skip list are scanned in key order by walking the lowest level of the skip list to identify key-value records to purge. (As used herein, a "key-value record" refers to a record identified by a key and containing a corresponding value; the key and value are collectively referred to as a "key-value pair.") As records are scanned, they are examined to determine whether they are ready to be purged, in some embodiments by examining a flag that is set to indicate when purging is permitted. Pointer information is recorded for pointers contained in the pointer tower and maintained until these pointers are resolved (i.e., the records pointed to by these pointers are scanned). If a record is identified for purging, its key-value record is purged by replacing one or more of its currently unresolved pointers with pointers contained in the key-value record being purged. As discussed, this approach of scanning the skip list in key order and tracking unresolved pointers can result in significantly fewer memory accesses than other approaches, such as approaches that rely on traversing down the skip list to determine which pointers should be updated when a record is being purged.

[0006] Additionally, a fast parallel purge algorithm is discussed in which the skip list is divided into sections that are traversed in parallel by multiple threads. (As used herein, the phrase "in parallel" refers to two or more operations (or two or more instances of the same operation) that are performed in an overlapping manner for at least a portion of the time.) As discussed in various embodiments, the skip list sections can be determined by traversing the top portion of the skip list to identify key-value records that can form the boundaries of these sections. These sections can be assigned to separate threads that can traverse their assigned sections in parallel using a fast purge algorithm. After the sections have been traversed by the threads, records at the section boundaries that have been identified for purging can be purged by traversing down the skip list to identify which skip list pointers should be updated.

[0007] This disclosure begins with a discussion of a database system that can maintain a skip list and use a fast purge algorithm, with reference to Figures 1 and 2. An exemplary skip list is discussed with reference to Figure 3. A less efficient algorithm for purging records is then discussed with reference to Figure 4. The fast purge algorithm is discussed with reference to Figures 5A-6. A parallel fast purge algorithm using multiple threads is discussed in Figure 7. Finally, a method and an exemplary computing system are discussed with reference to Figures 8A-9.

[0008] Referring now to FIG. 1, a block diagram of a database system 10 is shown. In an example embodiment, database system 10 includes a transaction manager 104, a buffer data structure 106, and a database 108. As shown, buffer data structure 106 includes a number of record chains 110, a hash table 120, an active transaction list 130, and a skip list 140. Record chain 110 includes key-value records 112. Hash table 120 includes a hash function 122 and an array of hash buckets 124, each of which includes a latch 126. (As used herein, the terms "latch," "lock," and "semaphore" are used generally to refer to variables that control access to a resource shared among multiple potential consumers.) In an example embodiment, manager 104 further includes a purge engine 150. In some embodiments, database system 10 may be implemented differently than illustrated. For example, in some embodiments, buffer data structure 106 may include more (or fewer) structures.

[0009] The transaction manager 104, in one embodiment, includes program instructions that are executable to process received database transactions 102. Generally, transactions 102 may be issued to read or write data to the database 108 and may be received from any of a variety of sources, such as one or more client devices, an application server, software running on the database system 10, etc. As described in more detail below, this processing involves the manager 104 initially storing records 112 for the key-value pairs of the transactions 102 in a buffer data structure 106 until the records 112 can be flushed to persistent storage in the database 108. Thus, various functions described below with respect to the buffer data structure 106 may be performed by the transaction manager 104, such as adding the key-value records 112 to the record chain 110, facilitating the acquisition of the hash bucket latch 126 for the transaction 102, modifications to the active transaction list 130 and the skip list 140, etc.

[0010] The buffer data structure 106, in one embodiment, is a data structure that buffers key-value pairs for active transactions until the transactions commit. As described below, the buffer data structure 106 is structured to allow for rapid insertion of key-value pairs, which in some instances may be executed simultaneously, allowing high volume transactions to be processed efficiently. Furthermore, the buffer data structure 106 may reside in local memory, allowing for faster reads and writes than the persistent storage of the database 108 where the data resides for long periods of time. In various embodiments, the buffer data structure 106 provides a concurrency control mechanism via the hash bucket latch 126 for the data in the buffer data structure 106 while allowing concurrent modifications to be performed thereon for different transactions 102. In some embodiments, committed transaction data is flushed from the buffer data structure 106 to the persistent storage of the database 108 asynchronously. That is, rather than performing a flush for the data of each transaction 102 upon its commitment, a flush is performed periodically for multiple committed transactions 102. For example, in one embodiment, the transaction manager 104 initiates a flush to the database 108 in response to the buffer data structure 106 meeting a particular size threshold.

[0011] Database 108 may correspond to any suitable form of database implementation. In some embodiments, database 108 is a relational database implemented using a log-structured merge (LSM) tree for persistent storage. In some embodiments, layers of the LSM tree may be distributed across multiple physical computer systems that provide persistent storage. In some embodiments, these computer systems are cluster nodes of a computer cluster that provides a cloud-based system accessible to multiple clients. In some embodiments, database 108 may be part of a software as a service (SaaS) model, while in other embodiments, database 108 may be directly operated by users.

[0012] As described above, when the transaction manager 104 stores a key-value pair for an active transaction 102 in the buffer data structure 106, a corresponding key-value record 112 may be created, which includes a value and a key. If multiple transactions 102 attempt to write values ​​associated with the same key, a key-value record 112 may be generated for each value and linked together to form a record chain 110 corresponding to the key. For example, if a user withdraws a first amount from a bank account resulting in a first database transaction 102 and then a second amount resulting in a second database transaction 102, the record chain 110 corresponding to the account balance key may 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) that specifies its associated transaction 102, and the records 112 may be further organized into the record chain 110 based on the ordering in which the transactions 102 were received. 2, the record chain 110 may be implemented using linked lists, whereby new records 112 are inserted at the head of the linked list and transition to the tail as newer records 112 are created and older ones are flushed to the database 108. To facilitate rapid access to the key-value records 112, the record chain 110 is appended to hash buckets 124 of a hash table 120.

[0013] The hash table 120 is a data structure that, in one embodiment, allows for constant time lookup of the record chain 110 based on a given key. That is, when a key is received, the hash table 120 is indexed into by applying a hash function 122 to the key to generate an appropriate index value for the hash bucket 124 that corresponds to the key. The direct pointer in the hash bucket 124 can then be referenced to retrieve the record chain 110. The ability to perform constant time lookups can significantly reduce the time consumed to read a key-value record 112, write a record 112, or perform a key probe (i.e., determining whether a key has a key-value record 112 present in the buffer data structure 106).

[0014] As discussed above, in various embodiments, each hash bucket 124 includes a respective latch 126 that controls access to its record chain 110. Thus, when a transaction seeks to read or write a value associated with a particular key, the key can be used to index into the hash table 120 and acquire the latch 126 corresponding to the key's associated hash bucket 124 before the read or write is performed. If the latch 126 cannot be acquired for a database transaction 102, processing of the database transaction 102 may be delayed until the latch 126 is released. In some embodiments, the latch 126 may have one of three possible states: available, shared acquire, and exclusive acquire. If a transaction 102 is not currently accessing the record chain 110, its latch 126 is available for acquisition. If a transaction 102 is performing a read of a key-value record 112, the latch 126 may be acquired in a shared state, which means that other transactions 102 can also acquire the latch 126 as long as they are also performing a read (i.e., not attempting to modify the record 112 while it is also being read). However, if a transaction 102 is performing a write, the latch 126 is acquired for the transaction 102 in an exclusive state, which means that other transactions 102 cannot acquire it until the latch 126 is released. Thus, if two transactions 102 are attempting to perform a write to the same key, the later transaction is delayed until the earlier one completes its write operation and releases the latch 126. If a transaction 102 is attempting to access multiple key-value pairs, the latches 126 may be acquired in ascending bucket 124 order to prevent deadlocks.Although the acquisition of latch 126 may be discussed primarily with respect to read and write operations, latch 126 may also be acquired when performing other operations such as defragmentation, garbage collection, flushing records 112 to persistent storage of database 108, etc. In some embodiments, latch 126 may also function as a concurrency control mechanism for active transaction list 130 and skip list 140.

[0015] The active transaction list 130, in one embodiment, is a data structure that tracks various metadata about active transactions 102. In various embodiments, the metadata for a given transaction 102 includes a transaction identifier for the transaction 102 and one or more pointers that can be used to access records 112 associated with the transaction 102. In doing so, the list 130 allows records 112 for a transaction 102 to be identified based on their transaction identifier, which can be useful, for example, when determining which records 112 should be removed if the transaction 102 is rolled back. The metadata may further include an indication of whether the transaction is active or committed, which can be used to determine whether the records 112 may be marked for flushing to the database 108.

[0016] The skip list 140 is a data structure that, in one embodiment, maintains an ordering of keys within the records 112 to enable forward and reverse traversal of the keys. In some embodiments, the database 108 may be configured such that the records 112 of committed transactions 102 are flushed in ascending key order (and version order), and the skip list 140 may allow this ordering to be determined quickly and easily. As described in more detail below with respect to FIG. 3, in some embodiments, the skip list 140 includes indirect pointers for accessing the records 112 of the skip list 140. That is, rather than having direct pointers between the records 112 (i.e., pointers that specify the memory addresses of the records 112), the skip list 140 includes indirect pointers to the hash buckets 124, which in turn include direct pointers to the chain 110. Advantageously, when a new record 112 is added to the record chain 110, the direct pointers in the hash buckets 124 are updated and the indirect pointers in the skip list 140 are not updated. The use of indirect pointers may also enable skip list 140 to utilize hash bucket latches 126 when manipulating records 112 with respect to list 140. Thus, when a record 112 for a transaction 102 is being accessed through skip list 140 for modification or removal, latch 126 may be acquired for the key of record 112 to prevent other modifications from being performed. Although shown in FIG. 1 as separate from records 112, portions of skip list 140 may, in some embodiments, reside on records 112 as discussed with respect to FIGs. 2 and 3.

[0017] When records 112 for committed transactions 102 are flushed, the contents of the records 112 may continue to remain in the buffer data structure 106 until it can be confirmed that they have been successfully written to persistent storage in the database 108. The records 112 may then be flagged for purging when their contents may no longer be needed and to free up more space in the buffer data structure 106 for newly incoming database transactions 102. To facilitate this purging, the pointers used to implement the record chains 110, the active transaction list 130, and the skip list 140 may need to be updated.

[0018] The purge engine 150 is a component of the transaction manager 104 that, in one embodiment, handles the purging of records 112, including updating these pointers. As described in more detail below in various embodiments, the purge engine 150 implements a fast purge algorithm for identifying and purging records 112 from the skip list 140. As described above, this may include the purge engine 150 traversing the skip list 140 in key order to determine whether any of the key-value records 112 have been flagged for purging. As part of this traversal, the purge engine 150 maintains a list of unresolved skip list pointers, and in response to identifying a key-value record 112 to be purged, the purge engine 150 may replace unresolved pointers in other records 112 with the skip list pointers contained in the key-value record 112 being purged. In various embodiments, the purge algorithm is further implemented to allow the transaction manager 104 to continue inserting records 112 into the skip list 140 (or, more generally, the buffer data structure 106) while a scan is in progress to reduce the impact of the purge engine 150 on the database system 10. As discussed, to ensure that the insertion of records 112 does not interfere with the purging of records 112 in a problematic manner, the purge engine 150 may further manage acquiring latches 126, pinning records 112, and validating outstanding pointer information before performing pointer replacement. In some embodiments, the purge engine 150 may further manage a thread pool of execution threads to implement the parallel fast purge algorithm described above and discussed in more detail below.

[0019] Next, the contents of records 112, including those used to implement skip list 140, will be discussed in more detail to facilitate a better understanding of the fast purge algorithm discussed in detail below.

[0020] 2, a block diagram of a record chain 110 is shown. As shown, the record chain 110 may include a collection of key-value records 112A-112C, a collision record 220, and a lock record 230. The records 112 may further include a key 212, a value 213, a transaction identifier 214, a commit identifier 215, a purge flag 216, a lock 217, a skip list pointer 218, and a record chain pointer 219. In some embodiments, the chain 110 may include more (or fewer) records 112, 220, or 230 than are shown, and a given record 112 may include more (or fewer) elements 212-219 than are shown.

[0021] In the illustrated embodiment, the record chain 110 is implemented using a linked list such that each key-value record 112 contains a pointer 219 that identifies the next record 112 in the chain 110. When a record 112 is added, it is inserted at the head identified by a direct pointer 202 in the hash bucket 124 or appended to a collision record 220, discussed below. The added record 112 may then contain a pointer 219 to the record that was previously at the head. As the record 112 gets older, it moves towards the tail (record 112B or lock record 230 in FIG. 2) until its transaction 102 commits. It may then be flushed to persistent storage in the database 108 and removed. The transaction identifier 214 of a given record 112 not only identifies the transaction 102 with which the record 112 is associated, but may also indicate the ordering in which the transactions 102 were received. Thus, transaction ID 214B may correspond to a transaction 102 that precedes transaction ID 214A because record 112B is further from the beginning than record 112A. If the transaction 102 corresponding to transaction ID 214B is to be rolled back, transaction manager 104 may locate record 112B by directly referencing pointer 202 to identify the beginning of chain 110 and traversing records 112A and 220 until it finds record 112B with corresponding transaction ID 214B. Record 112B may then be removed and pointer 222A may be modified to have the same address as pointer 219B. In some embodiments, when transaction 102 commits, commit identifier 215 for that record 112 may be set to reflect the commitment and mark record 112 as ready to be flushed to persistent storage in database 108.The records 112 may later be scanned by a process of the transaction manager 104 to identify which records 112 have a commit identifier 215 and to determine which records 112 may be flushed to the database 108 .

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

[0023] In some embodiments, the collision record 220 is used to append a record 112 to the chain 110 when two different keys (e.g., keys 212A and 213C) generate the same hash value (i.e., a hash collision occurs) and therefore share the same hash bucket 124. In various embodiments, the size of the hash table 120 is selected 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 may be inserted that includes a pointer 222 to a record 112 with a different key 212. While in many instances the hash bucket latch 126 is specific to a single respective key 212, in such cases the hash bucket latch 126 will be associated with multiple different keys 212.

[0024] As mentioned above, in some embodiments, individual records 112 may further include their own respective locks 217 to provide further coherency control. In some embodiments, a separate lock record 230 may be inserted into the record chain 110 to create a lock tied to a particular key when there is no corresponding value.

[0025] Skip list pointers 218 are pointers that, in one embodiment, form the skip list 140. As discussed next in FIG. 3, the pointers 218 in a given record 112 can form a pointer tower that implements a linked hierarchy of data record sequences, with each successive sequence skipping fewer records 112 than the previous sequence. In some embodiments, the pointers 218 are further implemented using indirect pointers where the key-value records 112 are linked together in the skip list 140, without using direct pointers to the physical addresses of the records 112. Instead, the pointers 218 reference a hash bucket 124 that points to the record chain 110 that contains the record 112. In various embodiments, using indirect pointers greatly simplifies pointer management, since only one direct pointer may be maintained for a given record 112. That is, the indirect pointer is not updated if the record 112 is moved, for example, to a later position in the record chain 110, since the location of the hash bucket 124 remains the same.

[0026] 3, a block diagram of a skip list 140 is shown. As mentioned above, in various embodiments, a skip list 140 can be used to maintain an ordering of the keys 212 stored in records 112, which can be used to flush the records 112 of committed transactions 102 in ascending key order. In the illustrated embodiment, the skip list pointers 218 in the records 112 form towers 300 that point to towers 300 in other records 112.

[0027] When a particular key 212 is being searched for within the skip list 140, traversal of the skip list 140 may begin, in an exemplary embodiment, at the top of the leftmost tower 300 (a location corresponding to bucket ID 312A1 in the exemplary embodiment), where the keys 212 in the records 112 are compared against the key being searched for. If there is a match, the record 112 being searched for has been located. If not, traversal proceeds along the path of forward pointer 314A to another record 112 having another key 212 to compare with. If that key 212 is less than the key 212 being searched for, traversal returns to the previous tower 300 and descends downward to the next level of the tower 300 (the location of bucket ID 312A2 in FIG. 3). However, if the key 212 being searched for is greater than the other key 212, traversal proceeds along another pointer 314. This process then continues forward until a match is identified for the record 112 being searched for. An example of this traversal is discussed below in FIG.

[0028] While forward pointers 314 are shown in FIG. 3 (and subsequent figures) for ease of understanding, skip list pointers 218 are implemented in some embodiments using indirect pointers. In the illustrated embodiment, skip list pointers 218 are specifically implemented using bucket identifiers 312 that point to buckets 124 in hash table 120, which in turn point to records 112 via pointers 202. Thus, proceeding along pointer 314C involves following pointer 218 of bucket ID 312A3 to bucket 124 and proceeding along pointer 202A to record chain 110 that includes record 112 having pointer 218 of bucket 312B1. Although not shown, in some embodiments skip list 140 further includes a set of backward pointers, which may be implemented in a similar manner and are discussed in more detail below.

[0029] When a record 112 is finally purged, any skip pointers 218 existing in other records 112 that point to the purged record 112 are identified so that they can be updated so that they no longer point to the purged record 112. Once they are identified, they are updated using the skip list pointer 218 in the record 112 being purged. Before discussing the fast purge algorithm, it is instructive to consider how the less efficient purge algorithm identifies the relevant skip list pointers 218 that should be updated.

[0030] Referring now to FIG. 4, a block diagram of a slow purge 400 is shown. As discussed, the slow purge 400 is a less efficient algorithm than the fast purge algorithm discussed below, since it uses a much larger number of memory accesses to identify relevant records 112 for updating. As shown in FIG. 4, an exemplary skip list 140 may be constructed from records 112 sorted in an ordering of keys 212A-W. The skip list 140 includes eight levels of forward pointers 314 (depicted as levels 1-8) that allow traversal in ascending key order, and another level of backward pointers (depicted as level -1) that allow traversal in descending key order. Sentinel towers 300 are located at either end of the skip list 140 and do not correspond to records 112 (and thus are shown with keys of -∞ and ∞). Also, under each key 212 in FIG. 4 is a bucket identifier 312 for a bucket 124 that contains a direct pointer 202 to that record 112 (or its record chain 110). Thus, as shown, the bucket 124 having a bucket identifier 312 of 19 contains a pointer 202 to a record 112 having a key 212 of A.

[0031] The slow purge 400 may begin with an initial scan (not shown in FIG. 4 ) in which records 112 are accessed in ascending bucket order to identify records 112 that have a set flag 216 indicating that they are ready for purging. In the example shown in FIG. 4 , a record 112 with a key 212 of S (or simply “record S”) is identified for purging. The skip list 140 may then be traversed to identify a record 112 that contains a skip list pointer 218 to record S. As shown, the traversal begins at the top of the left sentinel tower 300 in which a first memory access is performed to read the skip list pointer 218 at level 8, which contains a bucket ID 312 of 20. A second memory access is then performed to read the record 112 pointed to by bucket #20, which is the record 112 with key K. Because the key S of the purged record 112 is greater than the key K in the key order, the traversal continues along level 8, where record W is read during the third memory access. Because key S is less than key W, the traversal returns to record K in the fourth memory access, where it reads the next-level skip list pointer 218 down to level 7. As can be seen, this process continues for another 20 memory accesses until record R is identified as having a bucket #17 pointer 218 to record S. Once all records with pointers to record S have been identified (records R and T in this example), their pointers can be updated with the pointers in the record 112 being purged. For example, bucket #17 of record R can be replaced with bucket #9 of record S, so record R can point past it when record S is removed.

[0032] As can be seen, the traversal to remove one record involves 20 memory accesses, not including the memory accesses of the initial scan or the multiple accesses to move down the record chain 110. Furthermore, the slow purge 400 may perform multiple traversals if multiple records 112 are identified for purging. Furthermore, in some embodiments, the skip list 140 may be substantially wider, including an even taller skip list tower 300 (e.g., one with 33 levels). All these memory accesses can impact system performance. In many instances, the fast purge algorithm discussed next uses much fewer memory accesses.

[0033] 5A, a block diagram of a fast purge 500 is shown. As mentioned above, the fast purge 500 may be an algorithm used by the purge engine 150 to remove records 112 from the skip list 140. In an exemplary embodiment, the fast purge 500 begins with a forward scan 510 of the skip list 140 in key order. As shown, this scan 510 may begin with the sentinel tower 300 shown on the left, and proceeds efficiently forward in key order using the skip list pointer 218 at level 1. In this example, the scan 510 moves from the sentinel tower 300 to bucket #13, which points to record B. The scan 510 then moves to record C via bucket #22 using the skip pointer 218 at level 1 at record B. This process may continue until the scan 510 reaches the other sentinel tower 300 all the way to the right.

[0034] In various embodiments, the forward scan 510 serves a dual purpose: 1) reading the purge flags 216 to identify the records 112 to be purged, and 2) determining which records 112 warrant updating as they point to the records 112 being purged. This approach contrasts with the slow purge 400, where these actions are handled as separate operations, i.e., an initial scan followed by a traversal down the skip list 140. As a record 112 is read during the scan 510, the purge engine 150 may read the purge flags 216 and store information about the skip list pointers 218 contained in the record 112, which is shown as purge engine information 550. In some embodiments, the purge engine 150 further pins 514 the record 112 (meaning that the purge engine 150 prevents the record 112 from being relocated in memory). This may be done, for example, to prevent a garbage collection process from moving the record 112, to prevent the record 112 from being purged if it is still flagged, etc.

[0035] In the illustrated embodiment, purge engine information 500 is a table that includes a row for each level in the skip list 140. Within each row is a level 552 that identifies the skip list level associated with the row, a source record bucket 554 that identifies the bucket 124 that points to the record 112, a source record address 556 that identifies the physical address where the record 112 resides in memory, and a target bucket 124 to which the skip list pointer 218 points. As records 112 are read during scan 510, each row is updated in purge engine information 550 for the tower 300 height of that record 112. Thus, in the illustrated example, record K has a height of 1 (level-1 is not considered in the height in the illustrated embodiment), and therefore its one skip list pointer 218 at level 1 is recorded in the level 1 row of purge engine information 550. Thus, row 1 specifies a bucket ID 312 of 41 and includes a record address 556 of the record 112 and a target bucket 558 of 52. This pointer's information remains in purge engine information 550 until the pointer is resolved. As discussed above and shown in FIG. 5A, an unresolved pointer 512 is a pointer that points to a record 112 that has not yet been scanned during a forward scan 510. Thus, pointer 218 to bucket 52 is currently an unresolved pointer 512 because record M has not yet been scanned in the example shown in FIG. 5A. In contrast, a resolved pointer 516 is one that points to a record 112 that has already been scanned, such as the sentinel tower's pointer to record B in FIG. 5A. When pointer 218 is resolved, purge engine 150 replaces and updates information 550 with the information of the newly scanned record, as discussed next.

[0036] 5B, a block diagram of information update 520 of purge engine information 550 is shown. Continuing with the example of FIG. 5A, forward scan 510 now reaches bucket #52 and reads record M. At this point, the pointers 218 in records B-K have been resolved. If the newly scanned record M has not been purged, purge engine 150 may unpin 522 records B-K and replace their information in purge engine information 550 with pointer information record M, which is also pinned. In this example, record M has six levels of pointers 218 in its tower 300, and therefore all six levels of purge engine information 550 are updated. If record M's tower 300 only has three pointers 218, then in this example, only three rows would be updated, and therefore the rows with levels 4-6 would remain intact.

[0037] On the other hand, if the newly scanned record 112 was flagged for purging, the fast purge 500 can proceed as next discussed in Figures 5C and 5D.

[0038] 5C, there is shown a block diagram of bucket identifier replacement 530 of fast purge 500. In this example, the purge engine 150 now scans record M and determines from its purge flag 216 that this record 112 is to be purged. To do this, the purge engine 150 updates the pointer 218 in the skip list 140 to account for the fact that record M is about to be gone.

[0039] Because the purge engine 150 is already tracking unresolved pointers 512, the purge engine 150 knows which pointers 218 potentially point to the record 112 being purged, and therefore which pointers 218 may warrant updating. As illustrated in the example shown in FIG. 5C, the purge engine information 550 has already identified six unresolved pointers 218 at six different levels at the time record M is scanned. Because record M has a tower 300 with a height of six, the purge engine 150 assumes that six pointers potentially point to record M, which it can determine from the target bucket 558 in the information 550. Using this knowledge, the purge engine 150 can perform a bucket ID substitution 530 in which the purge engine 150 replaces the pointer 218 to record M with the pointer 218 contained within 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 past record M. Similar changes are made to the pointers 218 in records C-K at levels 1-5. If record M had a shorter tower 300 (e.g., four levels), then only a subset of these pointers 218 would be updated (e.g., those in records E-K). In various embodiments, the purge engine 150 further continues to pin the records 112 being updated and the records 112 being purged while these replacements 530 are being performed. As shown, the purge engine information 550 is also updated to reflect these changes, since these updated pointers 218 may still point to later-scanned records 112 that have been flagged for purging. In the illustrated embodiment, record N, which precedes record M, has its level-1 pointer 218 updated to point to record K.In one such embodiment, the level-1 pointers may not need to be tracked using the purge engine information 550 because they can be easily identified by traversing the level-1 pointer 218 in the record 112 being purged and using this backward pointer 218 to identify the next record 112 in ascending key order.

[0040] As mentioned above, in some embodiments, while the fast purge 500 is being performed, the transaction manager 104 is still permitted to insert records 112 into the buffer data structure 106 because preventing insertions can have a significant impact on system performance. However, because insertions have the potential to interfere with the purging of records 112, the purge engine 150 can perform validation of the purge engine information 550 before using it for any bucket ID substitutions 530, as discussed.

[0041] 5D, there is shown a block diagram of validation 540 of collected purge engine information 550. Because purge engine information 550 can become out of date when new records 112 are inserted, in various embodiments, purge engine 150 validates that this information 550 has not become inaccurate before it is used in replacement 530.

[0042] In various embodiments, purge engine 150 performs validation 540 by accessing record 112 using source record address 556. Purge engine 150 can then validate that pointers 218 at level 552 still point to the same bucket ID 312 identified by target bucket 558. If these pointers still match those recorded in information 550 (as in the case of successful validation 540A shown on the left side of FIG. 5D), purge engine 150 can proceed to perform bucket ID substitution 530 as just discussed.

[0043] In some instances, a mismatch can occur when a record 112 is inserted with a tower 300 high enough to disrupt a record 112 that previously pointed to the record 112 being purged. For example, in the unsuccessful verification 540B shown on the right side of FIG. 5D, record H is inserted with a tower height of 4, which results in the pointers at levels 2-4 in records E and G pointing to bucket #35 instead of bucket #52 where record M is located. Thus, when the purge engine 150 proceeds to verify the purge engine information 550, it is no longer consistent with what is actually in the skip list 140. If this occurs, in some embodiments, this is not a problem because the purge engine 150 delays purging the record 112 until another subsequent scan 510 is performed. Record M may be allowed to remain a little longer in this example, but is eventually purged. However, if record H contained a shorter tower 300 (e.g., it had a height of 1), its insertion would not interfere with the purge engine information 550 because the level 1 pointer 218 in record K, which currently points to record M being purged, would not be altered. Thus, the purge engine 150 would successfully validate the information 550 and proceed to perform the bucket ID substitution 530.

[0044] Because the record chain 110 and / or the record 112 may further have the potential to be modified during validation 540 and replacement 530, the purge engine 150 may further handle acquiring latches 126 and / or locks 217 to prevent modifications during validation 540 and replacement 530. In some embodiments, this may include acquiring latches 126 and / or locks 217 associated with the record 112 being purged, records 112 identified in the purge engine information 550, and records 112 that come after the record being purged in key order because they may contain backward pointers that may need to be updated. In one such embodiment, the latches 126 and / or locks 217 may be acquired in response to identifying the records 112 to be purged and retained through validation 540 and replacement 530.

[0045] 6, a block diagram of the inputs and outputs of the purge engine 150 is shown. In an exemplary embodiment, the purge engine 150 receives the 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 purge engine 150 can then use this information to maintain and update the purged engine information 550. The purge engine 150 can also receive the purge flag 216, which again can be used to determine whether the record 112 is to be purged. Based on this information, the purge engine 150 can output instructions to pin 514 or unpin 522 the record 112, the results 602 of the validation 540, the bucket ID 312 of the bucket replacement 530, the purged record 112, and instructions to modify the latch 126 and lock 217. In some embodiments, the purge engine 150 may have more (or fewer) inputs and outputs.

[0046] The purge engine 150 may perform the scan 510 of the entire skip list 140 sequentially, although in some embodiments, further performance improvements may be achieved by scanning multiple sections in parallel, as discussed next.

[0047] 7, which illustrates a block diagram of a parallel fast purge 700. As discussed, the purge engine 150 can perform the parallel fast purge 700 by dividing the skip list 140 into multiple sections 720, which are handled by separate threads running in parallel.

[0048] In an exemplary embodiment, the parallel fast purge 700 begins with the purge engine 150 determining how to split the skip list 140 by performing a traversal 710 of the top portion of the skip list 140 to identify the records 112 with the tallest towers 300 in the skip list 140. One advantage of identifying these records 112 is that they can be used as the leftmost boundary of each section 720, which can be useful because they ensure that most outstanding pointers are local to a given section 720 because they potentially contain the local maximum tower height for that section 720, assuming there are no intervening records 112 with even taller towers 300. For example, in FIG. 7, the tallest tower 300 is in the record 112 pointed to by the left sentinel tower and buckets 124 with bucket IDs 20, 9, 24, and 3. As the purge engine 150 walks down the top portion, it can target creating a particular number of sections 720, which can affect how far down the engine 150 goes. In the example shown in FIG. 7, the purge engine 150 can target creating five sections 720, and therefore continue to walk down the skip list 140 until it has identified that many unique bucket identifiers 312. Thus, in the example shown, the purge engine 150 walks down levels 8 through 6 before it can identify five unique bucket identifiers 312, and then the five unique bucket identifiers 312 are used to create the five sections 720.

[0049] Once the sections 720 are determined, in some embodiments, the purge engine 150 instantiates a thread pool with multiple threads and begins assigning sections 720 to the threads for traversal. Each execution thread can then use the fast purge 500 discussed above to traverse its assigned section 720 (including maintaining its own copy of the purge engine information 550 for the outstanding pointers 512 of its assigned section 720) and purge flagged records 112. If there are fewer threads in the thread pool than sections 720, a thread can circle back to receive another assigned section 720 from the purge engine 150 once it has completed work on a previously assigned section 720.

[0050] As the threads traverse their assigned sections 720, they may determine that the first records 112 at the left boundary of the section 720 are flagged for purging. In some embodiments, these threads may note that these records 112 are ready for purging, but may defer purging them until after the section 720 has been traversed. At that point, the purge engine 150 may perform a slow purge 400 on only the flagged records 112, and thus the purge engine 150 has traversed down the skip list 140 for only a small number of records 112 rather than every record 112 being purged.

[0051] We now discuss various ways in which one or more of the techniques discussed above can be used.

[0052] 8A, a flow chart of a method 800 for fast purging of skip list records is shown. Method 800 is one embodiment of a method performed by a computing system, such as database system 10, capable of executing purge engine 150. In some examples, execution of method 800 can reduce the burden of purging records from the skip list.

[0053] In step 805, a skip list (e.g., skip list 140) is stored that includes a plurality of key-value records (e.g., key-value records 112) that include one or more pointers (e.g., skip list pointers 218) to other ones of the plurality of 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 the database transaction committing and the key-value record being stored in persistent storage (e.g., the LSM tree of database 108), a flag (e.g., purge flag 216) is set in the key-value record to indicate that the key-value record is authorized to be purged. In some embodiments, a first key-value record of the plurality of key-value records in the skip list points to a second key-value record of the plurality of key-value records in the skip list by including a first pointer (e.g., indirect pointer 312) that points to a bucket (e.g., bucket 124) in a hash table (e.g., hash table 120), where the bucket includes a second pointer (e.g., direct pointer 202) to the second key-value record.

[0054] In step 810, the plurality of key-value records are scanned in key order to identify key-value records to be purged from the skip list. In various embodiments, the scan includes maintaining a list of key-value records (e.g., purge engine information 550) that includes a pointer (e.g., unresolved pointer 512) that points to a key-value record that has not yet been scanned by the scan. In some embodiments, the scan includes determining that a pointer (e.g., resolved pointer 516) of a first key-value record included in the list points to a second key-value record currently being scanned. In response to this determination, the first key-value record in the list is replaced (e.g., via information update 520) with the second key-value record. Relocation of the second key-value record is prevented in memory (e.g., via pinning 514) while the second key-value record is included in the list. In some embodiments, one or more key-value records are inserted into the skip list while the scan is being performed. In some embodiments, the scan includes identifying key-value records to purge based on a set flag.

[0055] In step 815, in response to identifying a key-value record to be purged, the key-value record is purged by replacing a pointer contained in the key-value record of the list with a pointer contained in the key-value record being purged (e.g., bucket ID replacement 530). In some embodiments, in response to identifying a key-value record to be purged, a validation of the list of key-value records (e.g., validation 540) is performed, including determining whether a pointer contained in the key-value record of the list points to the key-value record to be purged. In some embodiments, in response to determining that an insert has caused one or more pointers contained in the key-value record of the list to no longer point to the key-value record to be purged, the purging 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 performing the scan. The latch is held until after the pointer contained in the list's key-value record has been replaced by the pointer contained in the key-value record being purged.

[0056] In some embodiments, the method 800 further includes traversing the skip list downward (e.g., via upper skip list traversal 710) to identify a subset of the plurality of key-value records prior to traversing the plurality of key-value records in key order. Based on the key-value records in the identified subset, the skip list is divided into sections (e.g., sections 720). The sections are assigned to a plurality of executable threads for traversing the sections in parallel. In some embodiments, one of the plurality of threads receives an assigned section for traversal and traverses the assigned section, including maintaining a list of key-value records having unresolved pointers for the assigned section. In response to identifying key-value records to purge in the assigned section, the thread purges the key-value records in the assigned section using the list of key-value records for the assigned section.

[0057] 8B, a flow chart of a method 830 for fast purging of skip list records is shown. Method 830 is another embodiment of a method performed by a computing system, such as database system 10, capable of executing purge engine 150. In some examples, performance of method 830 can reduce the burden of purging records from the skip list.

[0058] In step 835, the computing system stores a skip list (e.g., skip list 140) that maintains an ordering of keys (e.g., keys 212) for key-value records (e.g., key-value records 112) of a database (e.g., database 108). In some embodiments, the skip list maintains an ordering of keys for key-value records of database transactions awaiting commitment by the database.

[0059] In step 840, the computing system identifies key-value records to be purged from the skip list. In an example embodiment, step 840 includes, in sub-step 841, scanning the skip list in key order to determine whether any of the key-value records include an indication that purging is permitted (e.g., purge flag 216). In some embodiments, prior to the scan, the computing system traverses a top portion of the skip list (e.g., via top skip list traversal 710) to determine divisions (e.g., sections 720) of the skip list for parallel scanning. The computing system assigns the divisions to multiple threads that are executable to scan the divisions in parallel with each other. In an example embodiment, step 840 further includes recording unresolved pointers (e.g., unresolved pointers 512) of the key-value records in the skip list, the unresolved pointers pointing to key-value records of the key-value records that have not yet been scanned by the scan.

[0060] In step 845, in response to identifying the key-value record to be purged, the computing system purges the key-value record by replacing the unresolved pointers of the unresolved pointers with pointers included in the key-value record being purged (e.g., via bucket ID substitution 530). In some embodiments, during the scan, the computing system inserts one or more key-value records into a skip list. In response to identifying the key-value record to be purged, the computing system verifies (e.g., verify 540) that the unresolved pointers of the unresolved pointers still point to the key-value record to be purged after inserting the one or more key-value records. 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 purged, the computing system delays purging the key-value record until a subsequent scan of the skip list is performed.

[0061] 8C, a flow chart of a method 860 for fast purging of records in parallel is shown. Method 860 is another embodiment of a method performed by a computing system, such as database system 10, capable of executing purge engine 150. In some examples, performance of method 860 can reduce the amount of time it takes to identify and purge records from a skip list.

[0062] In step 865, a skip list (e.g., skip list 140) is maintained that maintains an ordering of keys (e.g., keys 212) for a number of key-value records (e.g., records 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 waiting for commitment. In response to the database transaction corresponding to one of the inserted key-value records committing, a flag (e.g., purge flag 216) is set in the inserted key-value record to indicate that the inserted key-value record is permitted to be purged from the skip list. In some embodiments, a first key-value record of the plurality of key-value records in the skip list indirectly points to a second key-value record of the plurality of key-value records by including a first pointer (e.g., indirect pointer 312) to a bucket (e.g., bucket 124) in a hash table (e.g., hash table 120), which in turn includes a second pointer (e.g., direct pointer 202) to the second key-value record.

[0063] In step 870, the skip list is divided into identified sections (e.g., sections 720) by traversing the top portion of the skip list (e.g., via upper skip list traversal 710) to identify those key-value records that are to be used as section boundaries (e.g., record 112 with key G in section 720B in FIG. 7).

[0064] In step 875, the section is assigned to a number of threads, each executable in parallel to traverse the assigned section of the skip list in key order to identify key-value records to be purged from the skip list. In some embodiments, a first thread of the number of threads maintains a list (e.g., purge engine information 550) of unresolved pointers (e.g., unresolved pointers 512) for the section assigned to the first thread, where an unresolved pointer is a pointer included in a key-value record traversed by the first thread that points to a key-value record that has not yet been traversed by the first thread. In response to identifying a key-value record in the assigned section to be purged, the first thread replaces (e.g., via bucket ID replacement 530) an unresolved pointer of the unresolved pointer with a pointer included in the key-value record to be purged.

[0065] In some embodiments, the method 860 further includes accessing key-value records used as boundaries of the section following traversal of the allocated section by the multiple threads to identify boundary key-value records of the boundary key-value records to be purged. In response to identifying the boundary key-value records to be purged, the skip list is traversed downward to identify key-value records to be updated in response to the boundary key-value records being purged.

[0066] Exemplary Computer System 9, a block diagram of an exemplary computer system 900 capable of performing the functions described herein, such as database system 10, a portion of database system 10, or a client that interacts with database system 10, is shown. Computer system 900 includes a processor subsystem 980 coupled to a system memory 920 and an I / O interface 940 via an interconnect 960 (e.g., a system bus). The I / O interface 940 is coupled to one or more I / O devices 950. Computer system 900 may be any of a variety of types of devices, including, but not limited to, a server system, a personal computer system, a desktop computer, a laptop or notebook computer, a mainframe computer system, a tablet computer, a handheld computer, a workstation, a network computer, a consumer device, such as a mobile phone, a music player, or a personal data assistant (PDA). For simplicity, a single computer system 900 is shown in FIG. 9, however system 900 may be implemented as multiple computer systems operating together in a cluster.

[0067] 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 a cache or other form of on-board memory.

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

[0069] I / O interface 940 may be any of a variety of types of interfaces configured to couple and communicate with other devices according to various embodiments. In one embodiment, I / O interface 940 is a bridge chip (e.g., a southbridge) from a frontside to one or more backside buses. I / O interface 940 may be coupled to one or more I / O devices 950 via one or more corresponding buses or other interfaces. Examples of I / O devices 950 include storage devices (hard drives, optical drives, removable flash drives, storage arrays, SANs, or their associated controllers), network interface devices (e.g., for a local or wide area network), or other devices (e.g., graphics, user interface devices, etc.). In one embodiment, computer system 900 is coupled to a network via network interface device 950 (e.g., configured to communicate via WiFi, Bluetooth, Ethernet, etc.).

[0070] Although specific embodiments have been described above, these embodiments are not intended to limit the scope of the present disclosure, even if only a single embodiment is described with respect to a particular feature. The examples of features provided in this disclosure are intended to be illustrative rather than limiting, unless otherwise indicated. The above description is intended to cover alternatives, modifications, and equivalents as would be apparent to one skilled in the art having the benefit of this disclosure.

[0071] The scope of the present disclosure includes any feature or combination of features disclosed herein (either explicitly or implicitly), or any generalization thereof, whether or not it alleviates any or all of the problems addressed herein. Accordingly, during the prosecution of this application (or any application claiming priority thereto), new claims may be formulated for any such combination of features. In particular, with reference to the appended claims, features from the dependent claims may be combined with features of the independent claims, and features from each independent claim may be combined in any suitable manner, not just in the specific combinations recited in the appended claims.

[0072] This disclosure includes references to "one embodiment" or groups of "embodiments" (e.g., "some embodiments" or "various embodiments"). Embodiments are different implementations or instances of the disclosed concepts. References to "one embodiment," "one embodiment," "particular embodiment," etc. do not necessarily refer to the same embodiment. Numerous possible embodiments are contemplated, including those specifically disclosed, as well as modifications or alternatives that are within the spirit or scope of the disclosure.

[0073] This disclosure may discuss potential advantages that may result from the disclosed embodiments. Not all implementations of these embodiments necessarily exhibit any or all of the potential advantages. Whether advantages are realized for a particular implementation depends on many factors, some of which are outside the scope of this disclosure. Indeed, there are several reasons why an implementation that falls within the scope of the claims may not exhibit some or all of the disclosed advantages. For example, a particular implementation may include other circuitry outside the scope of this disclosure that negates or reduces one or more of the disclosed advantages relative to one of the disclosed embodiments. Furthermore, suboptimal design execution of a particular implementation (e.g., implementation technique or tool) may also negate or reduce the disclosed advantages. Even assuming a skilled implementation, realization of advantages may still depend on other factors, such as the environmental conditions in which the implementation is deployed. For example, inputs provided to a particular implementation may prevent one or more of the problems addressed in this disclosure from occurring on a particular occasion, such that the benefits of that solution may not be realized. It is expressly intended that the potential advantages described herein, subject to the existence of possible factors external to this disclosure, should not be construed as claim limitations that must be satisfied in order to prove infringement. Rather, the identification of such potential advantages is intended to illustrate the types of improvements available to a designer having the benefit of this disclosure. That such advantages have been permissively described (e.g., stating that a particular advantage "may result") is not intended to convey doubt as to whether such advantages can actually be realized, but rather to acknowledge the technical reality that realization of such advantages often depends on additional factors.

[0074] Unless otherwise indicated, the embodiments are non-limiting. That is, the disclosed embodiments are not intended to limit the scope of the claims that are drafted based on this disclosure, even if only a single example of a particular feature is described. The disclosed embodiments are intended to be illustrative, not limiting, unless otherwise stated in the disclosure. Thus, the present application is intended to enable claims that cover the disclosed embodiments, as well as alternatives, modifications, and equivalents that would be apparent to one skilled in the art having the benefit of this disclosure.

[0075] For example, features in the present application may be combined in any suitable manner. Accordingly, during prosecution of this application (or an application claiming priority thereto), new claims may be formulated to any such combination of features. In particular, with reference to the appended claims, features from dependent claims may be combined where appropriate with features of other dependent claims, including claims that are dependent on other independent claims. Similarly, features from each independent claim may be combined where appropriate.

[0076] Thus, the appended dependent claims may be drafted so that each is dependent on one other claim, but further dependencies are also contemplated. Any combination of features in the dependencies that is not inconsistent with the present disclosure is contemplated and may be claimed in this or another application. In short, combinations are not limited to those specifically recited in the appended claims.

[0077] Furthermore, where appropriate, claims drafted in one form or statutory type (e.g., apparatus) are deemed to be intended to support a corresponding claim in another form or statutory type (e.g., method).

[0078] Because this disclosure is a legal document, various terms and phrases may be subject to administrative and judicial interpretation. Notice is hereby given that the following paragraphs, as well as the definitions provided throughout this disclosure, should be used in determining how to interpret the claims drafted based on this disclosure.

[0079] Reference to the singular form of an item (i.e., a noun or noun phrase preceded by "a," "an," or "the") is intended to mean "one or more" unless the context clearly indicates otherwise. Thus, a reference to an "item" in a claim does not exclude further instances of the item without attendant context. A "plurality" of an item refers to a set of two or more of that item.

[0080] The word "may" is used herein in its permissive sense (i.e., having the potential, being able to) and not in its mandatory sense (i.e., must).

[0081] The terms "comprising" and "including" and their forms are open-ended, meaning "including but not limited to."

[0082] In this disclosure, when the term "or" is used in reference to a list of alternatives, it is generally understood to be used in an inclusive sense unless the context dictates otherwise. Thus, a description of "x or y" is equivalent to "x or y, or both," and thus covers 1) x but not y, 2) y but not x, and 3) both x and y. On the other hand, a phrase such as "either x or y, but not both" makes it clear that "or" is used in an exclusive sense.

[0083] The phrases "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, including single elements, up to the total number of elements in the set. For example, given the set [w, x, y, z], these phrases cover any single element of the set (e.g., w but not x, y, or z), any two elements (e.g., w and x but not y or z), any three elements (e.g., w, x, and y but not z), and all four elements. Thus, the phrase "... at least one of w, x, y, and z" refers to at least one element of the set [w, x, y, z], thereby covering all possible combinations within this list of elements. This phrase should not be interpreted as requiring that there be 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.

[0084] In this disclosure, various "labels" may precede a noun or noun phrase. Unless the context dictates otherwise, different labels used for a feature (e.g., "first circuit," "second circuit," "particular 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 indicated.

[0085] The phrase "based on" or "based on" is used to describe one or more factors that influence the decision. This term does not exclude the possibility that additional factors may influence the decision. That is, the decision may be based only on the specified factors, or may be based on the specified factors and other unspecified factors. Consider the phrase "determining A based on B." This phrase specifies that B is a factor that is used to determine A or that influences the decision of A. This phrase does not exclude that the decision of A may be further based on some other factor, such as C. This phrase is also intended to cover embodiments in which A is determined only based on B. As used herein, the phrase "based on" is synonymous with "based at least in part on."

[0086] The phrases "in response to" and "depending on" describe one or more factors that trigger an effect. This phrase does not exclude the possibility that additional factors may affect or otherwise trigger the effect, either jointly with or independently of the specified factors. That is, the effect may be in response only to those factors, or may be in response to the specified factors and other unspecified factors. Consider the phrase "performing A in response to B." This phrase specifies that B is a factor that triggers the execution of A or triggers a particular outcome of A. This phrase does not exclude that performing A may be further in response to some other factor, such as C. This phrase further does not exclude that performing A may be in response to B and C jointly. This phrase is further intended to cover embodiments in which A is performed only in response to B. As used herein, the phrase "in response to" is synonymous with "at least partially in response to." Similarly, the phrase "in response to" is synonymous with "at least partially in response to."

[0087] In this disclosure, different entities (which may be variously referred to as "units," "circuits," other components, etc.) may be described or claimed as being "configured" to perform one or more tasks or operations. This formulation - an entity configured to perform one or more tasks - is used herein to refer to a structure (i.e., something physical). More specifically, this formulation is used to indicate that this structure is arranged to perform one or more tasks during operation. A structure can be said to be "configured to perform" some task even if the structure is not currently in operation. Thus, an entity described or described as being "configured to perform" some task refers to something physical, such as a device, a circuit, a system having a processor unit and a memory that stores executable program instructions to realize the task. This phrase is not used herein to refer to something intangible.

[0088] In some cases, various units / circuits / components may be described herein as performing a set of tasks or operations, and these entities will be understood to be "configured to" perform these tasks / operations, even if not specifically described.

[0089] The term "configured to" is not intended to mean "configurable to." For example, an unprogrammed FPGA is not considered to be "configured to" perform a particular function; however, the unprogrammed FPGA may be "configurable to" perform that function. After appropriate programming, the FPGA can then be said to be "configured to" perform a particular function.

[0090] For purposes of U.S. patent applications based on this disclosure, reciting in a claim that a structure is "configured to" perform one or more tasks is expressly intended to not invoke 35 U.S.C. § 112(f) for that claim element. If an applicant wishes to invoke Section 112(f) during prosecution of a U.S. patent application based on this disclosure, the claim element should be recited using the "means for" construct [to perform a function].

Claims

1. A non-transitory computer readable medium having stored thereon program instructions capable of causing a computing system to perform operations, the operations including: storing a skip list including a plurality of key-value records, the plurality of key-value records including one or more pointers to other ones of the plurality of key-value records; scanning the plurality of key-value records in key order to identify key-value records to be purged from the skip list, the scanning comprising: maintaining a list of key-value records including pointers to key-value records not yet traversed by said scan; purging the key-value record in response to identifying a key-value record to be purged by replacing the pointer contained in the key-value record in the list with the pointer contained in the key-value record being purged; 23. A computer readable medium comprising:

2. The operation includes: inserting the key-value record into the skip list in response to a request to perform a database transaction associated with the key-value record; in response to the database transaction committing and the key-value record being stored in persistent storage of a database, setting a flag in the key-value record to indicate that the key-value record is authorized to be purged; Further comprising: The computer-readable medium of claim 1 , wherein the scanning includes identifying the key-value records to purge based on the set flags.

3. The scanning comprises: determining that a pointer of a first key-value record in the list points to a second key-value record currently being scanned; In response to said determination, replacing the first key-value record in the list with the second key-value record; preventing relocation of the second key-value record in memory while the second key-value record is included in the list; and The computer readable medium of claim 1 , comprising:

4. The operation includes: Inserting one or more key-value records into the skip list while the scan is being performed. The computer-readable medium of claim 1 further comprising:

5. The operation includes: performing a validation of the list of key-value records in response to identifying the key-value records to be purged, the validation including: determining whether the pointer included in the key-value record of the list points to the key-value record to be purged. The computer readable medium of claim 4 further comprising:

6. The operation includes: in response to determining that the insertion caused one or more pointers included in the key-value record in the list to no longer point to the key-value record to be purged, delaying the purging of the key-value record until a subsequent scan is performed. The computer readable medium of claim 5 further comprising:

7. The verification may include: acquiring a latch to prevent modification of said key-value record by processes other than the process performing said scan; maintaining the acquisition of the latch until after the replacement of the pointer contained in the key-value record of the list with the pointer contained in the key-value record being purged; The computer readable medium of claim 5 , comprising:

8. The operation includes: prior to said scanning of said plurality of key-value records in key order, traversing down the skip list to identify a subset of the plurality of key-value records; dividing the skip list into sections based on the key-value records in the identified subset; allocating said sections to a number of threads executable for traversing said sections in parallel; The computer-readable medium of claim 1 further comprising:

9. The operation includes: receiving an assigned section for scanning by one of the plurality of threads; traversing the allocated section by the thread, the traversing the allocated section including maintaining a list of key-value records having unresolved pointers for the allocated section; in response to identifying key-value records to purge in the allocated section, the thread purging the key-value records in the allocated section using the list of key-value records for the allocated section; The computer readable medium of claim 8 further comprising:

10. 2. The computer-readable medium of claim 1, wherein a first key-value record of the plurality of key-value records in the skip list includes a first pointer that points to a bucket in a hash table, thereby pointing to a second key-value record of the plurality of key-value records in the skip list, the bucket including a second pointer to the second key-value record.

11. storing, by a computing system, a skip list that maintains an ordering of keys for the key-value records of the database; identifying, by the computing system, key-value records to be purged from the skip list; scanning the skip list in key order to determine whether a key-value record among the key-value records includes an indication that purging is permitted; recording unresolved pointers of key-value records in the skip list, the unresolved pointers pointing to key-value records among the key-value records that have not yet been scanned by the scan; and in response to identifying a key-value record to be purged, the computing system purging the key-value record by replacing an unresolved pointer among the unresolved pointers with a pointer contained in the key-value record being purged; The method includes:

12. prior to said scanning, said computing system traversing a top portion of said skip list to determine a partition of said skip list for parallel scanning; allocating, by the computing system, the partition to a number of threads executable to traverse the partition in parallel with one another; The method of claim 11 further comprising:

13. During the scan, the computing system inserts one or more key-value records into the skip list; in response to identifying the key-value record to be purged, the computing system verifying that after inserting the one or more key-value records, an unresolved pointer among the unresolved pointers still points to the key-value record to be purged; The method of claim 11 further comprising:

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

15. 12. The method of claim 11, wherein the skip list maintains key ordering for key-value records of database transactions awaiting commitment by the database.

16. A non-transitory computer readable medium having stored thereon program instructions capable of causing a computing system to perform operations, the operations including: maintaining a skiplist that preserves an ordering of keys for a plurality of key-value records; dividing the skip list into sections, the sections being identified by traversing a top portion of the skip list to identify key-value records among the key-value records to be used as boundaries of the sections; assigning the sections to a number of threads, each operable in parallel to scan the assigned sections of the skip list in key order to identify key-value records to be purged from the skip list; 23. A computer readable medium comprising:

17. The operation includes: maintaining, by a first thread of the plurality of threads, a list of unresolved pointers for the section assigned to the first thread, the unresolved pointers being pointers contained in key-value records traversed by the first thread that point to key-value records not yet traversed by the first thread; in response to identifying a key-value record within the allocated section to be purged, the first thread replaces an unresolved pointer among the unresolved pointers with a pointer contained in the key-value record to be purged; 20. The computer readable medium of claim 16, further comprising:

18. The operation includes: Following said allocated section being scanned by said plurality of threads, accessing the key-value records used as boundaries of the section to identify boundary key-value records among the boundary key-value records to be purged; in response to identifying a boundary key-value record to be purged, traversing down the skip list to identify key-value records to be updated in response to the boundary key-value record being purged; 20. The computer readable medium of claim 17, further comprising:

19. The operation includes: inserting a key-value record into the skip list when a database transaction corresponding to the inserted key-value record is waiting for commitment; in response to a database transaction corresponding to one of the inserted key-value records committing, setting a flag in the inserted key-value record to indicate that the inserted key-value record is permitted to be purged from the skip list; 20. The computer readable medium of claim 16, further comprising:

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

Images