Fast skip list scan and insertion

Abstract

Techniques related to efficiently managing a skip list data structure are disclosed. In various embodiments, a computing system stores a skip list including a 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 skip list for a location associated with a particular key. The scanning includes identifying a particular portion of the skip list using a prefix of the particular key, where the particular portion includes key / value records having keys with the same prefix. The scanning further includes initiating a scan of a location within the identified portion. In some embodiments, the computing system inserts a key / value record into the skip list at the location associated with the particular key in response to the scanning identifying the location.

Description

[Technical field]

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

[0002] In the field of computer science, a variety of complex data structures have been developed to facilitate the storage of information. These data structures are often created using multiple pointers to stitch together groups of records. When designing complex structures, developers often weigh the complexity of inserting and retrieving information against concerns related to the size of the overall data structure. A skip list is an example of a more complex data structure, which is popular because it can maintain large data sets while offering an insertion complexity of up to O(log n) and a search complexity of up to O(log n). In this type of data structure, records may be 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 with varying heights of pointer towers, so that within a given tower, pointers may be positioned based on the number of records skipped. This ability to skip records when traversing a skip list may allow a given record to be found more quickly than by scanning the records sequentially. [Brief description of the drawings]

[0003] [Figure 1] FIG. 1 is a block diagram illustrating an embodiment of a database system that uses skip lists in a buffer data structure to process concurrent database transactions.

[0004] [Diagram 2] FIG. 2 is a block diagram illustrating one embodiment of record chains in a buffer data structure.

[0005] [Diagram 3] FIG. 2 is a block diagram illustrating one embodiment of a skip list within a buffer data structure.

[0006] [Figure 4] FIG. 2 is a block diagram illustrating an embodiment of a slow skip list scan.

[0007] [Diagram 5] FIG. 13 is a flow diagram illustrating one embodiment of a fast skip list scan.

[0008] [Figure 6A] FIG. 2 is a block diagram illustrating an embodiment of a key space partitioning that uses key prefixes to facilitate fast skip list scans. [Figure 6B] FIG. 2 is a block diagram illustrating an embodiment of a key space partitioning that uses key prefixes to facilitate fast skip list scans.

[0009] [Figure 7A] FIG. 13 is a block diagram illustrating an embodiment of anchor record identification during high speed skip list scanning. [Figure 7B] FIG. 13 is a block diagram illustrating an embodiment of anchor record identification during high speed skip list scanning.

[0010] [Figure 8] FIG. 1 is a block diagram illustrating one embodiment of climbing a mountain during a fast skip list scan.

[0011] [Figure 9A] FIG. 2 is a block diagram illustrating one embodiment of backward walking a skip list for record insertion. [Figure 9B] FIG. 2 is a block diagram illustrating one embodiment of backward walking a skip list for record insertion.

[0012] [Figure 10A] FIG. 2 is a flow diagram illustrating an embodiment of a method associated with scanning a skip list. [Figure 10B] FIG. 2 is a flow diagram illustrating an embodiment of a method associated with scanning a skip list. [Figure 10C] FIG. 2 is a flow diagram illustrating an embodiment of a method associated with scanning a skip list.

[0013] [Figure 11] FIG. 1 is a block diagram illustrating one embodiment of an exemplary multi-tenant system.

[0014] [Figure 12] FIG. 1 is a block diagram illustrating one embodiment of an exemplary computer system for implementing various systems described herein. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0015] In some examples, skip lists may be used to maintain large amounts of information that is frequently manipulated. 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. Because the database system may process large volumes of transactions in parallel, efficient scanning of the skip list may be important to the performance of the database.

[0016] This disclosure describes an embodiment that uses a more efficient scan algorithm to scan records in a skip list and / or insert new records into the skip list. As described below in various embodiments, the skip list can be divided into sections based on the prefix of the key, such that a given section contains keys with the same prefix. When a scan is performed for a particular key, the prefix of the key is first used to determine the relevant section for that prefix. The scan can then start within that section and run on only a subset of the skip list. This is in contrast to other approaches where the scan starts at an initial node (i.e., a sentinel node) and runs through the entire skip list. Because a given section is much smaller than the entire skip list, much fewer memory accesses are performed. This can result in significant performance improvements, especially in an exemplary database system described below, where in one embodiment, a skip list can maintain nearly 200,000,000 key-value records at a given time.

[0017] This disclosure begins with a discussion of a database system, with reference to Figures 1 and 2, that may maintain a skip list and use the fast scan algorithm described above. An exemplary skip list is discussed with reference to Figure 3. An inefficient algorithm for scanning a skip list is discussed with reference to Figure 4. A fast scan algorithm is discussed with reference to Figures 5-9B. Finally, a method and exemplary computing system are discussed with reference to Figures 10A-12.

[0018] Turning now to FIG. 1, a block diagram of database system 10 is shown. In the illustrated 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 data structures that control access to a resource shared among multiple potential consumers.) In the illustrated embodiment, manager 104 also includes a scan engine 150. In some embodiments, database system 10 may be implemented differently than is shown. For example, in some embodiments, buffer data structure 106 may include more (or fewer) structures. Although some structures 110, 120, 130, and 140 are depicted separately for purposes of illustration, in some embodiments, structures 110, 120, 130, and / or 140 may be intertwined with one another. For example, skip list 140 may be implemented by adding pointers inside key / value records 112 in record chain 110.

[0019] The transaction manager 104, in one embodiment, includes program instructions executable to process received database transactions 102. In general, the 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 software executing on one or more client devices, application servers, database system 10, etc. As described in more detail below, this processing may involve the manager 104 initially storing the key / value pair records 112 of the transactions 102 in a buffer data structure 106 until the records 112 can be flushed to persistent storage of the records 112. Thus, various functionalities described below in connection with the buffer data structure 106, such as adding the key / value records 112 to the record chain 110, facilitating acquisition of a hash bucket latch 126 for the transaction 102, and modifications to the active transaction list 130 and skip list 140, may be implemented by the transaction manager 104.

[0020] 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 in a manner that allows for rapid insertion of key / value pairs, possibly executed simultaneously, allowing for efficient processing of large volumes of transactions. 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 allows for concurrent modifications to be performed for different transactions 102, but provides a concurrency control mechanism via a hash bucket latch 126 for the data in the buffer data structure 106. 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 at commit time for the data of each transaction 102, 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.

[0021] Database 108 may correspond to any suitable form of database implementation. In some embodiments, database 108 is a non-relational database implemented using a log-structured merge (LSM) tree for persistent storage. In some embodiments, tiers 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 a user.

[0022] 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 that includes the value and the 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 withdraws 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 also be organized into the record chain 110 based on the order in which the transactions 102 are received. For example, as described below with respect to Figure 2, the record chain 110 may be implemented using a linked list such that new records 112 are inserted at the head of the linked list and moved to the tail as newer records 112 are created and older records are flushed to the database 108. To facilitate quick access to the key / value records 112, the record chain 110 is attached to a hash bucket 124 of a hash table 120.

[0023] The hash table 120, in one embodiment, is a data structure that 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 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 record chain 110 may then be retrieved by referencing a direct pointer in the hash bucket 124. The ability to perform constant time lookups may significantly reduce the time spent reading key / value records 112, writing records 112, or performing a key probe (i.e., determining whether a key has a key / value record 112 present in the buffer data structure 106).

[0024] As noted above, in various embodiments, each hash bucket 124 includes a respective latch 126 that controls access to this record chain 110. Thus, when a transaction seeks to read or write a value associated with a particular key, it may use that key to index into the hash table 120 to acquire the latch 126 corresponding to the key associated with the hash bucket 124 before performing the read or write. If the latch 126 cannot be acquired for the 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 acquired, and exclusively acquired. If the transaction 102 is not currently accessing the record chain 110, then the 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, meaning that other transactions 102 may also acquire the latch 126 as long as they are performing a read (i.e., they are not attempting to modify the record 112 while reading). However, if a transaction 102 is performing a write, the latch 126 is acquired in an exclusive state for the transaction 102, meaning that other transactions 102 cannot acquire the latch 116 until it is released. Thus, if two transactions 102 are attempting to perform a write to the same key, the later transaction is delayed until the former completes the 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 is described 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 the persistent store 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.

[0025] 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 for identifying records 112 for the transaction 102 based on the transaction identifier, which can be useful, for example, when determining which records 112 to delete if the 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 by the shark to determine whether that record 112 can be marked for flushing to the database 108.

[0026] The skip list 140, in one embodiment, is a data structure that maintains the order of keys within the records 112, allowing forward and reverse scanning of the keys. In some embodiments, the database 108 is configured such that the records 112 for committed transactions 102 are flushed in ascending key order (as well as 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., pointer records that point to memory addresses), 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, rather than the indirect pointers of the skip list 140. The use of indirect pointers also allows the skip list 140 to utilize the hash bucket latches 126 when manipulating the records 112 with respect to the list 140. Thus, when a record 112 of a transaction 102 is being accessed via skip list 140 for modification or deletion, latch 126 may be obtained for the key of key 112 to prevent other modifications from being performed. As noted above, although shown separately from record 112 in FIG. 1, a portion of skip list 140 may, in some embodiments, reside in record 112, as described below with respect to FIGs. 2 and 3.

[0027] When a record 112 is inserted into the buffer data structure 106, a scan of the skip list 140 may be performed to determine where in the skip list 140 the record should be inserted. When a record 112 is inserted, an additional skip list scan may be performed to locate the particular record 112 within the skip list 140. In the illustrated embodiment, the scan engine 150 is a component of the transaction manager 104 that is executable to traverse the skip list 140 and may implement a fast scan algorithm, which is described in more detail below and begins with FIG. 5. Thus, as described above, the scan engine 150 may divide the skip list 140 into sections (hereinafter referred to as "anchor ranges") based on the prefixes of the keys, such that a given section contains keys with the same prefix. To easily look up a particular section, in various embodiments, the scan engine 150 maintains an index that can be referenced to determine the relevant section for a given key prefix so that a scan can begin within that section. As described below, in some embodiments, this index is integrated into the hash table 120 by adding pointers to the records 112 in the respective sections (called "anchor records") in the hash buckets 124, thereby allowing a given section to be found quickly for a given key prefix. Once the relevant sections have been determined for a given key prefix, the scan engine 150 may implement a technique referred to below as "climbing the mountain" to sequentially scan the records. In various embodiments, the scan engine 150 may also be responsible for maintaining the skip list 140, including performing record insertions (and record deletions) for the skip list 140. As described, once the location of the record insertion is determined from the scan, when the record 112 is inserted as well as determining the pointers to include in the skip list tower for the record 112.The scan engine 150 may "walk backwards" from that position to determine what pointers to update in other records 112. In some embodiments, the scan engine 150 manages a thread pool of running threads to implement parallel high speed scanning.

[0028] The contents of records 112, including those used to implement skip list 140, will now be described in more detail to facilitate a better understanding of the fast scanning algorithm described in detail below.

[0029] Turning now to Figure 2, a block diagram of a record chain 110 is shown. As shown, record chain 110 may include a set of key / value records 112A-C, a collision record 220, and a lock record 230. Record 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, 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.

[0030] In the illustrated embodiment, the record chain 110 is implemented using a linked list such that each key / value record 112 includes 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, described below. The added record 112 may then include a pointer 219 to the record that was previously at the head. As a record 112 ages, it moves toward the tail (record 112B or lock record 230 in FIG. 2) until the transaction 102 is committed. It may then be flushed to persistent storage in the database 108 and deleted. The transaction identifier 214 of a given record 112 may not only identify the transaction 102 with which the record 112 is associated, but may also indicate the order in which the transactions 102 were received. Thus, because record 112B is further from the head than record 112A, transaction ID 214B may correspond to a transaction 102 that precedes transaction ID 214A. If the transaction 102 corresponding to transaction ID 214B is to be rolled back, the transaction manager 104 can find record 112B by referencing the direct pointer 202 to identify the head of the chain 110 and traversing records 112A and 220 until record 112B with corresponding transaction ID 214B is found. Record 112B is then deleted and pointer 222A is modified to have the same address as pointer 219B. In some embodiments, when the transaction 102 commits, the commit identifier 215 of that record 112 is set to reflect the commit, marking the record 112 as ready to be flushed to persistent storage in the database 108. The records 112 are later scanned by a process of the transaction manager 104 to identify which records 112 have commit identifiers 215 and determine which records 112 can be flushed to the database 108.

[0031] Once a key / value record 112 is successfully flushed to persistent storage, in some embodiments, 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. In some embodiments, a purge engine may read this flag 216 to determine whether the record 112 should be purged from the buffer data structure 106.

[0032] In some embodiments, 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, the collision record 220 is used to append the record 112 to the chain 110. In various embodiments, the size of the hash table 120 is selected to have a sufficient number of hash buckets 124 to keep the likelihood of collisions low. However, if a hash collision occurs, the record 220 is inserted to include a pointer 222 to the record 112 with the different key 212. While in many cases the hash bucket latch 126 is specific to a single respective key 212, in such cases the hash bucket latch 126 is associated with multiple different keys 212.

[0033] As noted above, in some embodiments, individual records 112 also include their own respective locks 217 to provide additional coherency control. In some embodiments, separate lock records 230 are also inserted into the record chain 110 to create a lock that is bound to a particular key when there is no corresponding value.

[0034] Skip list pointers 218 are pointers that, in one embodiment, form the skip list 140. As will now be described in FIG. 3, the pointers 218 in a given record 112 form a pointer tower that implements a linked hierarchy of data record sequences, where each successive sequence skips fewer records 112 than the previous sequence. In some embodiments, the pointers 218 may also be implemented using indirect pointers, whereby 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 hash buckets 124 that point to the record chain 110 that contains the record 112. In various embodiments, the use of indirect pointers greatly simplifies pointer management, since only one direct pointer needs to be maintained for a given record 112. That is, the location of the hash buckets 124 remains the same, so if the record 112 is moved, for example, to a later location in the record chain 110, the indirect pointers are not updated.

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

[0036] When a particular key 212 is being searched for within the skip list 140, traversal of the skip list 140 may begin at the top of the left-most tower 300 (in the illustrated embodiment, at a location corresponding to bucket ID 312A1), where the key 212 in the record 112 is compared to the key being searched for. If there is a match, the record 112 being searched for has been found. If there is no match, traversal proceeds along a path from forward pointer 314A to another key record 112 having another key 212 with which to compare. If that key 212 is less than the key 212 being searched for, traversal returns to the previous tower 300 and down to the next level within the tower 300 (at bucket ID 312A2 in FIG. 3). However, if the key 212 being searched for is greater than the other key 212, traversal proceeds forward along another pointer 314. This process then continues in a forward direction until a match is identified for the record 112 being searched for. An example of this traversal is described below in conjunction with FIG.

[0037] While forward pointer 314 is shown in FIG. 3 (and subsequent figures) for ease of understanding, skip list pointer 218 is implemented in some embodiments using indirect pointers. In the illustrated embodiment, skip list pointer 218 is implemented specifically using bucket identifier 312, which points to bucket 124 in hash table 120, which in turn points to record 112 via pointer 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 containing record 112 using 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, as described in more detail below.

[0038] Before describing the fast scan algorithm, it is useful to consider how the less efficient scan algorithm is implemented.

[0039] Turning to FIG. 4, a block diagram of a slow scan 400 is shown. As will be explained, the slow scan 400 is a less efficient algorithm than the fast scan algorithm described herein because it may use many more memory accesses to scan a particular key 212. As shown in FIG. 4, an example skip list 140 may be comprised of records 112 sorted in order of keys 212A-W. The skip list 140 includes eight levels of forward pointers 314 (denoted as levels 1-8) that allow traversal in ascending key order, and another level of backward pointers (denoted as level -1) that allow traversal in descending key order. Sentinel towers 300 are located at both ends of the skip list 140 and do not correspond to records 112 (and thus are shown as having keys of -∞ and ∞). Also beneath each key 212 in FIG. 4 is a bucket identifier 312 of a bucket 124 that contains a direct pointer 202 to that record 112 (or its record chain 110); thus, as shown, the bucket 124 with a bucket identifier 312 of 19 contains a pointer 202 to a record 112 with a key 212 of A.

[0040] In the example shown in FIG. 4, a slow scan 400 is performed to find a record 112 having a key 212 of S (or simply "record S"). As shown, the scan 400 begins with a skip list traversal at the top of the left sentinel tower 300, where a first memory access is performed to read the skip list pointer 218 for 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 having key K. Since key S is greater in key order than key K, the traversal continues along level 8, where record W is read during the third memory access. Since key S is less than key W, the traversal returns to record K in the fourth memory access, reading the skip list pointer 218 for level 7 in key order, and then descending to the next level.

[0041] As can be seen, this process continues for 20 more memory accesses until record R is identified with bucket #17's pointer 218 to the record, not including additional memory accesses to use the indirect pointers, and not including multiple accesses to move down the record chain 110. Additionally, the slow scan 400 may be performed multiple times to insert multiple records 112 associated with a given transaction. Additionally, in some embodiments, the skip list 140 may include even higher skip list towers 300 (e.g., one with 33 levels) and may be significantly wider. All of these memory accesses can impact system performance. In many cases, the fast scan algorithm described next uses far fewer memory accesses.

[0042] Turning to FIG. 5, fast scan 500 is shown. As noted above, fast scan 500 is an algorithm used by scan engine 150 to more quickly scan skip list 140 in response to receiving a request to identify associated locations for a given key. Although illustrated as including steps 510-540, fast scan 500 may include more (or less) than those illustrated. For example, step 540 may not be included if scan 500 is being performed for purposes other than record insertion.

[0043] In the illustrated embodiment, the fast scan 500 begins at step 510, where the scan engine 150 uses a prefix of a particular key to identify an anchor range in the skip list 140 that contains the associated location of the particular key. As described above, an "anchor range" is a set / range of records in the skip list that have the same key prefix and are used to anchor where the skip list scan begins. As described below with respect to Figures 6A and 6B, the scan engine 150 may use key prefixes of different lengths to generate anchor ranges with various widths so that the scan can begin from the narrowest anchor range available. As described below with respect to Figures 7A and 7B, the scan engine 150 identifies the anchor range for a particular key prefix using an index that associates key prefixes with anchor ranges by including respective pointers to "anchor records" in those ranges. In some embodiments, the anchor record for a particular anchor range is the record 112 that has the lowest key 212 for that anchor range, but still has the same prefix. Once the anchor record 112 is found, the scan engine 150 can use it as a starting point to begin scanning from the anchor record 112 to find the associated location.

[0044] In step 520, the scan begins with the scan engine 150 "climbing a mountain" from the anchor record to a record 112 that has a skip list tower 300 that overshoots the relevant location. As described below with respect to FIG. 8, the anchor record may not contain a tower that is tall enough to allow the relevant location to be determined using skip list traversal alone. Thus, using pointer 314, the scan engine 150 may scan forward from the anchor record using the highest available tower pointer (i.e., the key / value record 112 pointed to by pointer 314 has a key that is later in key order than the particular key) until a key / value record 112 that has a skip list tower 300 that overshoots the location is identified. In some cases, the relevant location may be identified as part of this forward scan without performing step 530.

[0045] In step 530, once an overshooting tower 300 is identified, scan engine 150 performs a local skip list traversal from the overshooting tower 300 to identify the associated location of the particular key. In various embodiments, this local skip list scan may be implemented in a manner similar to slow scan 400, but need not begin at a sentinel tower. If scan 500 is being performed to access record 112, scan 500 may end with scan engine 150 accessing the contents of record 112 after traversal identifies its location. If record 112 is being inserted at its location, scan 500 may proceed to step 540 to determine how skip list 140 should be modified to facilitate the insertion.

[0046] In step 540, the scan engine 150 walks backwards from the identified location to identify the associated skip list pointers 314 for the record insertion. As described with reference to Figures 9A and 9B, the scan engine 150 scans backwards sequentially until it identifies an overshooting pointer for each level in the tower 300 of the record 112 being inserted. Once all the associated pointers 314 have been identified, the scan engine 150 may then insert the new record 112 at the determined location and include in the new record 112 the tower 300 with the identified pointers 314. The scan engine 150 then updates the associated pointers 314 in the other towers 300 to point to the newly inserted record 112.

[0047] In many cases, the fast scan 500 will require far fewer memory accesses than the slow scan 400 because the skip list traversal is performed only on a small subset of the total records 112 in the skip list 140. To facilitate this local skip list traversal, some additional memory accesses may be performed, but the use of techniques such as climbing mountains and backward walking for associated pointer identification ensures that the number of additional memory accesses is often much less than the number required to perform the slow scan 400.

[0048] Various examples of using key prefixes to partition the key space of skip list 140 are now described.

[0049] Turning to FIG. 6A, a block diagram of key space partitioning 600A is shown. As shown and previously described, the skip list 140 includes a set of records 112 having respective keys 212 and accessible from buckets 124 having various bucket identifiers 302. The records 112 are also arranged in key order and have respective skip list towers 300. In the illustrated embodiment, the key space partitioning 600A divides the key space using two different key prefixes 610, a short key prefix 610A and a long key prefix 610B. As can be appreciated, the short key prefix 610A results in a larger anchor range 620A having a larger number of records 112. In the illustrated example, the key 212 "DEBHQTT" is the lowest key of the "DE" key prefix 610A, so the range 620A has an anchor record 622A in bucket 19. The longer key prefix 610B has fewer records 112 because key 212 "DEJKEVM" is the lowest key of the "DEJK" key prefix 610B, and results in a narrower anchor range 620B with anchor record 622B. Although anchor ranges 620A and 620B are illustrated as having separate anchor records 622A and 622B, it is worth noting that an anchor record 622 can participate in multiple anchor ranges 620 based on different length prefixes 610 of the keys 212 of the records 112. For example, anchor record 622A is also an anchor record for the longer "DEBH" key prefix 610.

[0050] In the example shown in FIG. 6A, the scan engine 150 is performing a scan for a location 624 that corresponds to the key 212 “DEJKSBC” of the record 112 being inserted into the skip list 140. In various embodiments, the scan engine 150 first selects the longest available prefix 610 for the particular key 212 to determine whether there is an associated anchor range 620 in the skip list 140, since there may be fewer records 112 being scanned. In the illustrated example, the long key prefix 610B “DEJK” does not have a corresponding anchor range 620B, and therefore the scan engine 150 can begin scanning from anchor record 622B. However, if the long key prefix 610B were “DEJA”, in this example, there would be no corresponding anchor range 620, since no other records 112 have this prefix. In various embodiments, in response to determining that no associated anchor range 620 exists in the skip list 140 for the longest prefix 610, the scan engine 150 selects the next longest prefix 610 for the particular key 212. In this example, since "DE" is still a component of the key 212, the scan engine 150 may fall back to use the shorter key prefix 610A. Although a scan from the anchor record 622A via the broader anchor range 620A will result in more records being scanned than the narrower anchor range 620B, the number of records scanned is still often much less than those scanned when performing the slow scan 400. If no corresponding anchor range exists (e.g., the key has the prefix 610 "DFAC"), the scan engine 150 may still fall back to using the slow scan 400 to identify the location 624. However, once this record 112 is inserted, it can become an anchor record 622 for both DF prefixes 610 and DFAC prefixes 610 that can enable fast scans of these prefixes 610 in the future.

[0051] Although partitioning 600A uses the same key prefix length throughout the entire key space, in some embodiments, different key prefix lengths may be used for different portions of the key space, as discussed next.

[0052] Turning to FIG. 6B, a block diagram of another key space partitioning 600B is shown. In the illustrated embodiment, different portions of the key space may use different anchor plans 650 to partition the key space using different numbers of prefixes 610. For example, as shown, an anchor plan 650A using three different prefixes 610 is used for keys 212 having initials A through L, an anchor plan 650B using four different prefixes 610 is used for keys 212 having initials M through S, and an anchor plan 650C using two different prefixes 610 is used for keys 212 having initials T through Z. In such an embodiment, the scan engine 150 may first access the anchor plan 650 to determine what length prefix to use for a given key 212. For example, if a scan is being performed on a key 212 having the initial letter G, the scan engine 150 may determine from the anchor plan 650A that a 10 character initial prefix 610 should be used, followed by an 8 character prefix, then a 3 character prefix.

[0053] In various embodiments, different anchor plans 650 may be selected based on the underlying distribution of keys 212 in the skip list 140. For example, portions of the key space with a greater concentration of keys 212 may use additional prefixes 610. In some embodiments in which the database system 10 implements a multi-tenant database, the scan engine 150 may use different anchor plans 650 for different tenants. Still further, the prefixes 610 may be selected to group records 112 that have common attributes (e.g., are contained in the same database table) into the same anchor range 620. In some embodiments, the scan engine 150 may also modify the anchor plans 650 over time to improve performance. For example, in one embodiment, the scan engine 150 may use machine learning algorithms to determine appropriate anchor plans 650 for various divisions of the key space. However, such a change may not be disruptive to the database system 10 because the scan engine 150 may initially fall back to using the slow scan 400 to insert records 112 until a sufficient number of records 112 have been inserted based on the new anchor plan 650 such that the fast scan 500 can be performed again. Such a change may not pose a major problem because the temporary performance degradation to change the anchor plan is likely to only affect a small number of scans.

[0054] Turning to FIG. 7A, a block diagram of an anchor record identification 700 is shown. As noted above, in various embodiments, the scan engine 150 maintains an index that associates a key prefix 610 with key / value records 112 in each anchor range 620 that have the same key prefix, and accesses the index to identify the associated anchor record 622 from which to begin the scan. In the illustrated embodiment, the index is implemented by including the anchor entries 710 in a hash bucket 124. Each anchor entry 710 further includes the bucket identifier 312 of the anchor record 622 and its corresponding key prefix 610. In other embodiments, the index may be implemented differently. For example, the anchor entries 710 may be located elsewhere, such as appended to the record chain 110, the anchor entries 710 may include more (or fewer) components, the key prefix 610 may be replaced with a hash value generated from the key prefix 610 (as shown in FIG. 7B), the index may be implemented using a data structure other than a hash table 120, etc.

[0055] In the illustrated embodiment, the scan engine 150 implements the anchor record identification 700 by applying the hash function 122 to a given prefix 610 to determine the bucket identifier 312 of the associated hash bucket 124 (e.g., bucket 124N). If a corresponding anchor entry 710 exists in the bucket 124 (meaning a corresponding anchor range 620 exists for that prefix 610), the containing bucket identifier 312 of the anchor record 622 is read to determine the hash bucket 124 associated with the anchor record 622. This bucket identifier 312 is then used to access the hash bucket 124 of the anchor record 612 (e.g., bucket 124A). The scan engine 150 then traverses the pointer in the bucket 124 to the anchor chain 110 that contains the anchor record 622. However, if there is no anchor entry 710 in the hash bucket 124 (meaning that a corresponding anchor range 620 does not yet exist), the scan engine 150 proceeds using the next larger key prefix 610 for the particular key 212 and repeats this process until it can identify an associated anchor record 622, or proceeds to perform the slow scan 400 if it cannot identify an anchor entry 710 for any key prefix 610 of the key 212.

[0056] In various embodiments, the scan engine 150 creates an anchor entry 710 for an anchor range 620 when an initial record 112 is added to the range 620 - when the initial record becomes an anchor record 622. When records 112 with lower keys 212 are added to the range 620 (or records 112 with lower keys 212 are deleted), the scan engine 150 updates the anchor record bucket identifier 312 in the anchor entry 710 to point to the hash bucket 124 of these new anchor records 622 (or records 112 with the next lower keys 212). When each record 112 of a particular anchor range 620 is deleted, the scan engine 150 may remove the corresponding anchor entry 710 from the hash bucket 124. In some cases, multiple anchor entries 710 may be modified for a given key 212 if that corresponding record 112 becomes an anchor record 622 for multiple prefixes 610.

[0057] In some rare instances, hash collisions may cause two prefixes 610 to map to the same hash bucket 124. Thus, to verify that the anchor entry 710 is the correct one for the prefix 610 being hashed, the scan engine 150 may compare the prefix 610 being hashed to the key prefix 610 in the anchor entry 710. In some embodiments, if two prefixes 610 are associated with the same hash bucket 124, a given hash bucket 124 may contain multiple anchor entries 710. In another embodiment, for a colliding prefix 610, the anchor entry 710 may be stored in a collision record 220 pointed to by the hash bucket 124. In other embodiments, other techniques may be used to handle collisions, such as using the next longest prefix 610 for the particular key 212 being scanned.

[0058] Turning now to FIG. 7B, a block diagram illustrating an example of an anchor record identification 700 is shown. Continuing with the example introduced in FIG. 6A, the scan engine 150 is again attempting to determine the associated location 624 for the key 212 “DEJKSBC”. In this example, the scan engine 150 may first apply the hash function 122 to the long prefix 610B “DEJK” to obtain the bucket identifier 312 “31”. The scan engine 150 may then compare the hash value of “DEJK” to the hash value 702 “739813” to determine that the anchor entry 710 is the correct one. If so, the scan engine 150 may retrieve the bucket identifier 312 “6” and then access the corresponding bucket 124, in which case the scan engine 150 may access the anchor record 622 in the narrower range 620 to begin the scan. However, if no corresponding entry 720 exists (or the hash values ​​702 do not match), the scan engine 150 may apply the hash function 122 to the short prefix 610A “DE” and access the corresponding entry 710 to determine the anchor record 622 of the broader anchor range 620A, in which case a scan may begin, as described next.

[0059] Turning to FIG. 8, a block diagram of a "climbing mountain" 800 is shown. Once the scan engine 150 has determined an anchor record 622 for a given prefix 610, the scan engine 150 may read the tower 300 in that record 121 to determine one or more pointers 314 for scanning forward within the anchor range 620 for the associated location 624. However, in many cases, the tower 300 is not high enough to perform a skip list traversal (i.e., it does not have a pointer 314 pointing to a record 112 located after the location 624). While the scan engine 150 could scan the records 112 sequentially in a forward direction, this approach is inefficient and does not take advantage of the logarithmic scanning provided by the skip list. Thus, in the illustrated embodiment, the scan engine 150 uses a climbing mountain 800.

[0060] In various embodiments, this technique means that the scan engine 150 begins by "climbing up the mountain," i.e., scanning forward from the anchor record 622 along the highest available pointers 314 in the tower 300 of the skip list 140, until it can identify an overshooting tower 300 (i.e., a tower 300 with a pointer 314 that points past / overshoots the position 624). Thus, in the example shown in FIG. 8, the scan engine 150 may traverse the pointer 314 "17" in the anchor record 622, the pointer 314 "29" of the next record 112, and the pointer 314 "42" of the subsequent record 112, since these are the highest available pointers in the tower 300 of these records 112. The advantage of "climbing up the mountain" is that any intermediate records 112 with short towers 300 can be skipped, resulting in a logarithmic scan with an upward climb. In some cases, location 624 may be within the record 112 being accessed in this upward climb.

[0061] Once an overshooting tower 300 is identified, the scan engine 150 may "climb down the mountain" using a local skip list traversal 810. In various embodiments, the local traversal 810 is implemented in the same manner as the skip list traversal of the slow scan 400, but the traversal 810 is a "local" performance, meaning that it begins at the overshooting tower 300 rather than the sentinel tower 300. Thus, in the illustrated example, in response to determining that the pointer 314 "42" points past the location 624, the scan engine 150 traverses the next highest pointer 314 "15", traverses the pointer 314 "9", and determines the location 624 after the overshoot. Because the local scan 810 also allows for logarithmic scanning, the process of climbing up the mountain and climbing down the mountain is an efficient approach for determining the associated location 624 after the associated anchor range 620 has been identified.

[0062] If the scan 500 is being performed to find an existing record 112, the scan 500 may end with the scan engine 150 providing the contents of the record 112. However, if the scan 500 is being performed to insert a record 112, the scan engine 150 may need to perform additional work to determine which pointers 314 should be included in the record 112 and which pointers 314 should be modified in other records 112, as described next.

[0063] 9A, a block diagram of "backward walking" 900 is shown. In a slow scan 400, relevant pointers 314 may be determined to facilitate record insertion as the scan 400 is being performed. Because the scan engine 150 does not have access to all relevant pointers 314 while performing Climbing Mountain 800, the scan engine 150 may perform backward walking 900 with this in mind.

[0064] In the illustrated embodiment, the scan engine 150 implements backward walking 900 by sequentially scanning backward along the lowest level in the skip list 140 to identify pointers 314 in other records 112 that are associated with the key / value record 112 being inserted into the skip list 140. In various embodiments, the scan engine 150 may first determine the height of the new tower 300 for the record 112 being inserted in order to know how many levels there are in the new tower 300 and therefore how many associated pointers 314 to insert into the tower 300. In some embodiments, the scan engine 150 determines the height of the tower 300 using a backoff power of 2, meaning that the heights of the skip list towers are assigned logarithmically, with ½ being 1 height (not including the lowest reverse level), ¼ being 2 heights, and so on. In one embodiment, the scan engine 150 may determine the height of the tower 300 by generating a random number and counting consecutive 1s (or 0s) from the most significant bit (or least significant bit). Once the tower heights are determined, the scan engine 150 may sequentially scan backwards until the engine 150 identifies an overshoot pointer 314 for each level in the new tower 300. Thus, in the example shown in FIG. 9A, a tower height of four forward pointers 314 is used. Thus, the scan engine 150 may sequentially scan backwards until it has pointers 314 "12", "9", "42" and "42" in each of the four levels. Once relevant pointers 314 are identified, the scan engine 150 may pin the record by recording those relevant pointers 314 and the corresponding bucket identifiers 312 of the record 112.

[0065] In some cases, the scan engine 150 may not perform backward walking 900 if the record 112 being inserted has a tower 300 that is tall enough (e.g., in some embodiments, more than eight levels, although this is rare) to make backward walking 900 a less efficient approach than performing a slow scan 400 to determine a set of associated pointers 314. Thus, in some embodiments, before sequentially scanning backwards, the scan engine 150 may determine the number of pointers 314 contained in the tower 300 of the new record 112. Based on the determined number, the scan engine 150 decides whether to use a slow scan 400 to traverse the skip list 140 from the sentinel node or to use walking backwards 900 to sequentially scan backwards from the identified location 624.

[0066] Once all relevant pointers 314 have been identified, the scan engine 150 may perform record insertion as described next.

[0067] Turning now to Figure 9B, a block diagram of record insertion 950 is shown. As shown, this involves the scan engine 150 placing the previously pinned associated pointers 314 to the new tower 300 in the inserted record 112 at location 624, so that the new record 112 points to the same previously linked record 112 as the associated pointers 314 in the other records 112. Because the new tower 300 occludes the pointers 314 in the other records 112, the scan engine 150 may update those pointers 314 to point to the bucket identifiers 312 of the inserted record 112, as shown in Figure 9B.

[0068] Because record chains 110 and / or records 112 may potentially be modified during backward walking 900 and record insertion 950, scan engine 150 may also acquire latches 126 and / or locks 217 of determined records 112 that have associated pointers 314 to prevent modification during walking 900 and insertion 950. Once each associated pointer 314 is identified, scan engine 150 may further perform validation of pointers 314 before performing code insertion 950 to ensure that a concurrent record modification or another record insertion is not interfering with record insertion 950.

[0069] As noted above, in various embodiments, the scan engine 150 may also need to add or update one or more anchor entries 710 in response to an inserted record 112 becoming the initial record 112 of an anchor range 620 or having a new lowest key 212 for one or more anchor ranges 620.

[0070] Various methods of using one or more of the techniques described above are now described.

[0071] 10A, a flow chart is shown of a method 1010 of fast skip list scanning. Method 1010 is one embodiment of a method performed by a computing system, such as database system 10, running scan engine 150. In some cases, method 1010 may improve performance of scanning a skip list.

[0072] In step 1015, a skip list (e.g., skip list 140) is stored containing a plurality of key / value records (e.g., key / value records 112) that contain one or more pointers (e.g., skip list pointers 218 / 314) to other ones of the plurality of key / value records. In some embodiments, the skip list maintains an order of the keys of the key / value records stored in a buffer data structure that stores data for active database transactions.

[0073] In step 1020, the skip list is scanned for a position (position 624) associated with a particular key.

[0074] In sub-step 1022, the scanning step includes using a particular key prefix (e.g., key prefix 610) to identify a particular portion of the skip list (e.g., anchor range 620), where the particular portion contains key / value records with keys of the same prefix. In various embodiments, an index is maintained that associates the key prefix with key / value records in each portion that have the same key prefix, and using the prefix includes accessing the index to identify an initial key / value record (e.g., anchor record 612) in the particular portion where the scan should begin. In some embodiments, accessing the index includes applying a hash function (e.g., hash function 122) to the prefix to identify a pointer (e.g., bucket identifier 312) to an initial key / value record in the particular portion, and traversing (e.g., local traversal 810) the pointer to the initial key / value record in the particular portion. In some embodiments, the method includes selecting a first prefix (e.g., short key prefix 610A) and a second longer prefix (e.g., long key prefix 610B) of a particular key, determining whether associated portions of a skip list (e.g., broader anchor range 620A and narrower anchor range 620B) exist for the first and second prefixes, and in response to determining that an associated portion exists in the skip list of the second longer prefix, selecting an associated portion of the second prefix for use in scanning for the location. In some embodiments, the length of the prefix used is determined by accessing a set of anchor plans (e.g., anchor plan 650) that specify the prefix length to be used based on the portion of the particular key.

[0075] In sub-step 1024, the scanning step includes initiating a scan for a location within the identified portion. In various embodiments, the scanning includes scanning forward through the key / value records within the particular portion along the highest available pointer in a skip list tower of key / value records (e.g., climbing mountain 800) until a key / value record is identified that contains a pointer to another key / value record that is located after the location associated with the particular key in key order (e.g., in overshooting tower 300 of FIG. 8 ), and traversing the skip list from the identified key / value record (e.g., local traversal 810).

[0076] In some embodiments, the method 1010 further includes inserting a key / value record (e.g., inserted record 112 in FIG. 9B) into the skip list at a location associated with the particular key in response to the scan identifying a location. In some embodiments, the method 1010 further includes determining a set of pointers (e.g., for the new tower 300 in FIG. 9B) to be included in the key / value record being inserted by sequentially scanning backwards (e.g., walking backwards 900) from the identified location and identifying key / value records that include pointers that point to key / value records located after the identified location in key order. In some embodiments, before sequentially scanning backwards, a number of pointers in the set (e.g., the height of the new tower 300) is determined. Based on the determined number, a decision is made as to whether to traverse the skip list from a sentinel node (e.g., the sentinel tower 300 in FIG. 4) or to sequentially scan backwards from the identified location.

[0077] 10B, a flow chart of another method 1030 for high speed skip list scanning is shown. Method 1030 is another embodiment of a method performed by a computer system, such as database system 10, which may be running scan engine 150. In some cases, execution of method 1030 may reduce the burden of scanning the skip list.

[0078] In step 1035, a skip list (e.g., skip list 140) is stored that maintains an order of keys (e.g., keys 212) of key / value records (e.g., records 112) of a database (e.g., database 108). In various embodiments, the skip list maintains key order for key / value records of database transactions that are waiting to be committed by the database.

[0079] In step 1040, a position (e.g., position 624) in the skip list associated with a particular key is determined. In sub-step 1042, the determining step includes using a prefix (e.g., key prefix 610) of the particular key to identify a range (e.g., anchor range 620) in the skip list, where the range includes key / value records with keys of the same prefix. In sub-step 1044, the determining step includes initiating a scan of positions within the identified range. In some embodiments, the determining step includes scanning the identified range forward with a pointer that overshoots the position until a key / value record is identified that includes the skip list tower (e.g., overshoot tower 300 of FIG. 8 ) and traversing the skip list from the skip list tower (e.g., local traversal 810). In some embodiments, the determining step includes, in response to determining the location, sequentially scanning backwards from the location in the skip list (e.g., backward walking 900) to identify a pointer (e.g., associated skip list pointer 218 of FIG. 9A) to be included in the tower of the key / value record being inserted into the skip list (e.g., new tower 300 of FIG. 9B), and inserting the key / value record at the determined location with the tower containing the identified pointer. In some embodiments, the determining step includes applying a hash function (e.g., hash function 122) to the prefix to identify a hash table (e.g., hash table 120) that contains a pointer (e.g., bucket identifier 312) to an initial key / value record in the range (e.g., anchor record 622), and starting the scan from the initial key / value record in the range.

[0080] 10C, a flow chart of a method 1060 for high speed skip list scanning is shown. Method 1060 is another embodiment of a method performed by a computer system, such as database system 10, which may be executing scan engine 150. In some cases, execution of method 1060 may reduce the time it takes to scan the skip list and / or insert records into the skip list.

[0081] At step 1065, a skip list (e.g., skip list 140) is maintained that preserves the order of keys of the plurality of key / value records (e.g., records 112). 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., bucket identifier 312) to a bucket of a hash table (e.g., hash table 120), where the bucket includes a second pointer to the second key / value record.

[0082] At step 1070, the skip list is partitioned (e.g., key space partitioning 600) into sections (e.g., anchor ranges 620) based on the prefixes of the keys (e.g., prefixes 610). In some embodiments, the partitioning includes maintaining a hash table (e.g., hash table 120) that associates prefixes with pointers to sections within the skip list (e.g., anchor record bucket identifiers 312).

[0083] In step 1075, a location (e.g., location 624) associated with the particular key is determined by beginning a scan of locations within the section that correspond to a prefix of the particular key. In various embodiments, the determining step includes scanning forward within the section (e.g., climbing up in FIG. 8) with a pointer pointing past the location until a key / value record is identified that includes a skip list tower (e.g., overshooting tower 300 in FIG. 8), and from the identified key / value record, performing a skip list traversal (e.g., local traversal 810) to determine the location.

[0084] In some embodiments, the method 1060 further includes scanning backwards along a bottom level of the skip list (e.g., backward walking 900) for the key / value record being inserted into the skip list for insertion into a skip list tower (e.g., new tower 300 in FIG. 9B ) and inserting the key / value record into the skip list using the skip list tower.

[0085] Exemplary Multitenant Database System Turning to FIG. 11, an exemplary multi-tenant database system (MTS) 1100 is shown that may implement functionality as database system 10. In the illustrated embodiment, MTS 1100 includes a database platform 1110, an application platform 1120, and a network interface 1130 that is connected to a network 1140. The database platform 1110 includes a data storage 1112 and a set of database servers 1114A-N that interact with the data storage 1112, and the application platform 1120 includes a set of application servers 1122A-N with respective environments 1124. In the illustrated embodiment, MTS 1100 is connected to various user systems 1150A-N via the network 1140. In other embodiments, the techniques of this disclosure are implemented in non-multi-tenant environments, such as client / server environments, cloud computing environments, clustered computers, and the like.

[0086] The MTS 1100, in various embodiments, is a set of computer systems that together provide various services to users (alternatively referred to as "tenants") who interact with the MTS 1100. In some embodiments, the MTS 1100 implements a customer relationship management (CRM) system that provides a mechanism for tenants (e.g., businesses, government agencies, etc.) to manage relationships and interactions with customers and potential customers. For example, the MTS 1100 may enable tenants to store customer contact information (e.g., customer websites, email addresses, phone numbers, and social media data), identify sales opportunities, record service issues, and manage marketing campaigns. Additionally, the MTS 1100 may enable these tenants to identify how customers communicate, what customers have purchased, when they last purchased an item, and what they have paid for. To provide the services of the CRM system and / or other services, as illustrated, the MTS 1100 includes a database platform 1110 and an application platform 1120.

[0087] The database platform 1110 is a combination of hardware elements and software routines that, in various embodiments, implements a database service for storing and managing data for the MTS 1100, including tenant data. As shown, the database platform 1110 includes a data storage 1112, which in various embodiments includes a set of storage devices (e.g., solid state drives, hard disk drives, etc.) that are connected together over a network (e.g., a storage attached network (SAN)) and configured to store data redundantly to prevent data loss. In various embodiments, the data storage 1112 is used to implement the database 108, which includes a collection of information organized to allow access, storage, and manipulation of the information. The data storage 1112 may implement a single database, a distributed database, a collection of distributed databases, a database with redundant online / offline backups or other redundancies, etc. As part of a database implementation, data storage 1112 may store one or more database records 112 having respective data payloads (e.g., values ​​of fields in a database table) and metadata (e.g., key values, timestamps, table identifiers for tables associated with the record, tenant identifiers for tenants associated with the record, etc.).

[0088] In various embodiments, a database record 112 may correspond to a row in a table. A table typically contains one or more data categories that are logically arranged as columns or fields in a viewable schema. Thus, each record in a table may contain an instance of data for each category defined by a field. For example, a database may contain a table that describes customers with fields for basic contact information such as name, address, phone number, fax number, etc. Thus, a record in that table may contain a value for each field in the table (e.g., name for a name field). Another table may describe a purchase order, which includes fields for information such as customer, product, sale price, date, etc. In various embodiments, standard entity tables are provided for use by all tenants, such as tables for account, contact, lead, and opportunity data, each containing predefined fields. The MTS 1100 may store database records for one or more tenants in the same table, i.e., tenants may share tables. Thus, a database record, in various embodiments, includes a tenant identifier that indicates the owner of the database record. As a result, one tenant's data is kept secure and isolated from other tenants' data, so that one tenant does not have access to another tenant's data unless such data is explicitly shared.

[0089] In some embodiments, data stored in data storage 1112 includes a buffer data structure 106 and persistent storage organized as part of a log-structured merge tree (LSM tree). As described above, database server 1114 may first write database records to local in-memory buffer data structure 106 before later flushing those records to persistent storage (e.g., in data storage 1112). As part of flushing the database records, database server 1114 may write the database records 112 to a new file contained in the "top" level of the LSM tree. Over time, as database records are moved to lower levels of the LSM tree, the database records may be rewritten by database server 1114 to a new file contained in a lower level. In various implementations, as database records age and are moved down the LSM tree, they are moved to slower storage devices in data storage 1112 (e.g., from solid state drives to hard disk drives).

[0090] When the database server 1114 wants to access a database record for a particular key, the database server 1114 may traverse different levels of the LSM tree for files that potentially contain the database record for that particular key. If the database server 1114 determines that a file may contain a related database record, the database server 1114 may fetch the file from the data storage 1112 into the memory of the database server 1114. The database server 1114 may then check the fetched file for a database record 112 having the particular key 212. In various embodiments, the database record 112 is immutable once written to the data storage 1112. Thus, when the database server 1114 wants to modify a value in a row of a table (which may be identified from the accessed database record), the database server 1114 writes the new database record 112 to the buffer data structure 106, which is erased to the top level of the LSM tree. Over time, that database record 112 is merged to a lower level of the LSM tree. Thus, an LSM tree may store different database records 112 for a database key 212, where older database records 112 for that key 212 are at a lower level in the LSM tree than newer database records.

[0091] The database server 1114 is, in various embodiments, a hardware element, software routine, or combination thereof that can provide database services such as data storage, data retrieval, and / or data manipulation. Such database services may be provided by the database server 1114 to components within the MTS 1100 (e.g., the application server 1122) and to components external to the MTS 1100. As an example, the database server 1114 may receive a database transaction request from the application server 1122 requesting to write data to or read data from the data storage 1112. The database transaction request may specify a SQL SELECT command that selects one or more rows from one or more database tables. The contents of the row may be defined in a database record, and the database server 1114 may find and return one or more database records that correspond to the selected table row or rows. In various cases, the database transaction request may instruct the database server 1114 to write one or more database records for an LSM tree, which the database server 1114 maintains implemented in the database platform 1110. In some embodiments, the database servers 1114 implement a relational database management system (RDMS) or an object-oriented database management system (OODBMS) that facilitates the storage and retrieval of information from the data storage 1112. In various cases, the database servers 1114 may communicate with each other to facilitate the processing of transactions. For example, database server 1114A may communicate with database server 1114N to determine whether database server 1114N has written a database record for a particular key to its in-memory buffer.

[0092] The application platform 1120, in various embodiments, is a combination of hardware elements and software routines that implements and executes the CRM software application and provides associated data, code, forms, web pages, and other information to and from the user systems 1150, and provides associated data, objects, web page content, and other tenant information via the database platform 1110. To facilitate these services, in various embodiments, the application platform 1120 communicates with the database platform 1110 to store, access, and manipulate data. In some cases, the application platform 1120 may communicate with the database platform 1110 via different network connections. For example, one application server 1122 may be coupled via a local area network and another application server 1122 may be coupled via a direct network link. Transmission Control Protocol and Internet Protocol (TCP / IP) is an exemplary protocol for communication between the application platform 1120 and the database platform 1110, although it will be apparent to one skilled in the art that other transport protocols may be used depending on the network interconnect used.

[0093] The application server 1122 is a hardware element, software routine, or combination thereof that can provide the services of the application platform 1120, including, in various embodiments, processing requests received from tenants of the MTS 1100. The application server 1122 can, in various embodiments, generate environments 1124 that can be used for various purposes, such as providing functionality for developers to develop, run, and manage applications. Data can be transferred to an environment 1124 from another environment 1124 and / or the database platform 1110. In some cases, an environment 1124 cannot access data from other environments 1124 unless the data is explicitly shared. In some embodiments, multiple environments 1124 can be associated with a single tenant.

[0094] The application platform 1120 may provide the user systems 1150 with access to multiple different hosted applications (standard and / or custom), including a CRM application and / or applications developed by tenants. In various embodiments, the application platform 1120 may manage the creation of applications, the testing of applications, the storage of applications in database objects in the data storage 1112, the execution of applications in the environment 1124 (e.g., virtual machines in the process space), or any combination thereof. In some embodiments, the application platform 1120 may add and remove application servers 1122 from the server pool at any time for any reason, but there may be no server affinity with a user and / or organization for a particular application 1122. In some embodiments, an interface system (not shown) implementing load balancing functionality (e.g., an F5 Big-IP load balancer) may be located between the application servers 1122 and the user systems 1150 and configured to distribute requests to the application servers 1122. In some embodiments, the load balancer routes user requests to the application servers 1122 using a least connections algorithm. Other examples of load balancing algorithms, such as round robin or observed response time, may also be used. For example, in one embodiment, three consecutive requests from the same user may hit three different servers 1122, and three requests from different users may hit the same server 1122.

[0095] In some embodiments, the MTS 1100 keeps each tenant's data separate unless the data is shared, using security mechanisms such as encryption. When more than one server 1114 or 1122 is used, they may be located in close proximity to one another (e.g., in a server farm located in a single building or campus), or they may be distributed in locations far from one another (e.g., one or more servers 1114 are located in City A and one or more servers 1122 are located in City B). Thus, the MTS 1100 may include one or more logically and / or physically connected servers, either locally or distributed across one or more geographic locations.

[0096] One or more users (e.g., via user systems 1150) may interact with MTS 1100 over network 1140. User systems 1150 may correspond to, for example, a tenant of MTS 1100, a provider (e.g., an administrator) of MTS 1100, or a third party. Each user system 1150 may be a desktop personal computer, a workstation, a laptop, a PDA, a cellular phone, or any wireless access protocol (WAP)-enabled device, or any other computing device capable of interfacing directly or indirectly to the Internet or other network connection. User systems 1150 may include dedicated hardware configured to interface with MTS 1100 over network 1140. The user systems 1150 may execute a graphical user interface (GUI) for the MTS 1100, an HTTP client (e.g., a browsing program such as Microsoft's Internet Explorer browser, Netscape's Navigator browser, Opera browser, or a WAP-enabled browser in the case of a cell phone, PDA, or other wireless device), or both, to enable a user of the user system 1150 (e.g., a subscriber to the CRM system) to access, process, and display information and pages available from the MTS 1100 over the network 1140. Each user system 1150 may include one or more user interface devices, such as a keyboard, mouse, touch screen, pen, etc., for interacting with the graphical user interface (GUI) provided by the browser on a display monitor screen, LCD display, etc., along with pages, forms, and other information provided by the MTS 1100 or other systems and servers. As noted above, the disclosed embodiments are suitable for use with the Internet, which refers to a specific global internetwork of networks.However, it should be understood that other networks may be used in place of the Internet, such as an intranet, an extranet, a virtual private network (VPN), a non-TCP / IP based network, any LAN or WAN, etc.

[0097] Because users of the user system 1150 may be of different capabilities, the capabilities of a particular user system 1150 may be determined by one or more permission levels associated with the current user. For example, when a sales representative is using a particular user system 1150 to interact with the MTS 1100, the user system 1150 may have the capabilities (e.g., user privileges) assigned to the sales representative. However, when an administrator is using the same user system 1150 to interact with the MTS 1100, the user system 1150 may have the capabilities (e.g., administrative privileges) assigned to the administrator. In a system using a hierarchical role model, a user at one permission level may have access to applications, data, and database information accessible by a user at a lower permission level, but may not have access to certain applications, database information, and data accessible by a user at a higher permission level. Thus, different users may have different capabilities with respect to accessing and modifying application and database information depending on the user's security or permission level. There may also be some data structures managed by the MTS 1100 that are allocated at the tenant level, while other data structures are managed at the user level.

[0098] In some embodiments, the user system 1150 and its components are configurable using an application, such as a browser, that includes computer code executable on one or more processing elements. Similarly, in some embodiments, the MTS 1100 (and additional instances of the MTS, if more than one MTS is present) and their components are operator configurable using applications that include computer code executable on the processing elements. Thus, various operations described herein may be performed by executing program instructions that are stored in a non-transitory computer-readable medium and executed by the processing elements. The program instructions may be stored in a non-volatile medium, such as a hard disk, or in any other volatile or non-volatile storage medium or device known in the art, such as a ROM or RAM, or provided on any medium capable of initiating program code, such as a compact disc (CD) medium, a digital versatile disc (DVD) medium, a floppy disk, or the like. Additionally, the entire program code or portions thereof may be transmitted and downloaded from a software source, for example, via the Internet or from another server as is well known, or may be transmitted over any other conventional network connection as is well known (e.g., extranet, VPN, LAN, etc.) using any communication medium and protocol as is well known (e.g., TCP / IP, HTTP, HTTPS, Ethernet, etc.). It will also be appreciated that computer code for implementing aspects of the disclosed embodiments can be implemented in any programming language executable on a server or server system, such as, for example, C, C+, HTML, Java, JavaScript, or any other scripting language such as VBScript.

[0099] Network 1140 may be a LAN (local area network), a WAN (wide area network), a wireless network, a point-to-point network, a star network, a token ring network, a hub network, or any other suitable configuration. The global internetwork of networks is often referred to as the "Internet" with a capital "I" and is an example of a TCP / IP (Transmission Control Protocol and Internet Protocol) network. However, it should be understood that the disclosed embodiments may utilize any of a variety of other types of networks.

[0100] The user system 1150 may communicate with the MTS 1100 using TCP / IP, or at higher network levels, using other common Internet protocols such as HTTP, FTP, AFS, WAP, etc. For example, if HTTP is used, the user system 1150 may include an HTTP client, commonly referred to as a "browser," to send and receive HTTP messages from an HTTP server in the MTS 1100. Such a server may be implemented as the only network interface between the MTS 1100 and the network 1140, although other techniques may be used as well or alternatively. In some implementations, the interface between the MTS 1100 and the network 1140 includes load sharing functionality, such as a round-robin HTTP request distributor to balance the load and distribute incoming HTTP requests evenly across multiple servers.

[0101] In various embodiments, the user system 1150 communicates with the application server 1122 to request and update system-level and tenant-level data from the MTS 1100, which may request one or more queries to the data storage 1112. In some embodiments, the MTS 1100 automatically generates one or more SQL statements (SQL queries) designed to access the desired information. In some cases, the user system 1150 may generate requests having a specific format that corresponds to at least a portion of the MTS 1100. As an example, the user system 1150 may request that a data object be moved to a particular environment 1124 using an object notation that describes the object-relational mapping (e.g., JavaScript object notation mapping) of a number of specified objects.

[0102] Exemplary Computer System Turning now to Figure 12, a block diagram of an exemplary computer system 1200 that may implement the functionality 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 1200 includes a processor subsystem 1280 that is coupled to a system memory 1220 and an I / O interface 1240 via an interconnect 1260 (e.g., a system bus). The I / O interface 1240 is coupled to one or more I / O devices 1250. Computer system 1200 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 or music player, or a personal data assistant (PDA). Although a single computer system 1200 is illustrated in Figure 12 for convenience, system 1200 may also be implemented as two or more computer systems operating together in a cluster.

[0103] Processor subsystem 1280 may include one or more processors or processing units. In various embodiments of computer system 1200, multiple instances of processor subsystem 1280 may be coupled to interconnect 1260. In various embodiments, processor subsystem 1280 (or each processor unit within 1280) may include a cache or other form of on-board memory.

[0104] The system memory 1220 can be used to store program instructions executable by the processor subsystem 1280 to cause the system 1200 to perform various operations described herein. The system memory 1220 can 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-SRAM, EDO RAM, SDRAM, DDR SDRAM, RAMBUS RAM, etc.), read-only memory (PROM, EEPROM, etc.), etc. The memory in the computer system 1200 is not limited to primary storage, such as the memory 1220. Rather, the computer system 1200 can also include other forms of storage, such as cache memory in the processor subsystem 1280 and secondary storage on the I / O device 1250 (e.g., hard drive, storage array, etc.). In some embodiments, these other forms of storage may also store program instructions executable by the processor subsystem 1280 to cause the system 1200 to perform the operations described herein. In some embodiments, the memory 1220 may include portions of the transaction manager 104, the scan engine 150, the buffer data structure 106, and / or the database 108.

[0105] I / O interface 1240 may be any of a variety of types of interfaces configured to couple to and communicate with other devices according to various embodiments. In one embodiment, I / O interface 1240 is a bridge chip (e.g., a southbridge) from a front-side bus to one or more back-side buses. I / O interface 1240 is coupled to one or more input / output devices 1250 via one or more corresponding buses or other interfaces. Examples of I / O devices 1250 include storage devices (hard drives, optical drives, removable flash drives, storage arrays, SANs or controllers associated therewith), network interface devices (to local or wide area networks) or other devices (graphics, user interface devices, etc.). In one embodiment, computer system 1200 is coupled to a network via network interface device 1250 (e.g., configured to communicate via WiFi, Bluetooth, Ethernet, etc.).

[0106] 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 for a particular feature. The examples of features provided in this disclosure are intended to be illustrative rather than limiting, unless otherwise stated. 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.

[0107] 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, new claims may be formulated for any such combination of features during the prosecution of this application (or any application claiming priority thereto). 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.

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

[0109] This disclosure may discuss potential advantages that may result from the disclosed embodiments. Not all implementations of these embodiments will necessarily reveal any or all of the potential advantages. Whether an advantage is realized for a particular embodiment depends on many factors, some of which are outside the scope of this disclosure. Indeed, there are several reasons why an implementation within the scope of the claims may not exhibit some or all of any disclosed advantages. For example, a particular implementation may include other circuitry outside the scope of the disclosure that negates or reduces one or more of the disclosed advantages along with one of the disclosed embodiments. Furthermore, suboptimal design execution of a particular implementation (e.g., implementation techniques or tools) may also negate or reduce the disclosed advantages. Even assuming a skilled implementation, realization of an advantage may still depend on other factors, such as the environmental circumstances 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, resulting in the advantages of that solution not being realized. In view of the existence of possible factors external to this disclosure, it is expressly intended that any potential advantages described herein should not be construed as limitations of the claims that must be met to establish infringement. Rather, the identification of such potential advantages is intended to illustrate the types of improvements available to a designer having the benefit of the present disclosure. The permissive description of such advantages (e.g., stating that a particular advantage "may result") is not intended to convey doubt as to whether such advantages may actually be realized, but rather to recognize the technological reality that realization of such advantages often depends on additional factors.

[0110] 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 this disclosure, even if only a single example of a particular feature is described. The disclosed embodiments are intended to be illustrative rather than limiting, and nothing in the disclosure states to the contrary. Accordingly, the application is intended to allow claims covering the disclosed embodiments, as well as alternatives, modifications, and equivalents as would be apparent to one of ordinary skill in the art having the benefit of this disclosure.

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

[0112] Thus, the accompanying dependent claims may be drafted so that each is dependent on a single other claim, but additional dependencies are also contemplated. Any combination of features in the dependent claims consistent with this disclosure is contemplated and may be claimed in this or another application. In short, combinations are not limited to those specifically recited in the accompanying claims.

[0113] It is also contemplated that, where appropriate, a claim drafted in one format or statutory type (e.g., apparatus) is intended to support a corresponding claim in another format or statutory type (e.g., method).

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

[0115] 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 additional instances of that item without the context requiring it. A "plurality" of an item refers to a set of two or more items.

[0116] The term "may" is used herein in a permissive sense (i.e., having the possibility, being able to do) and not in a mandatory sense (i.e., must).

[0117] The terms "comprise" and "include" and their forms are open ended, meaning "including, but not limited to."

[0118] In this disclosure, when the term "or" is used in connection with a list of alternatives, it will generally be understood to be used in an inclusive sense unless the context provides otherwise. Thus, a statement 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.

[0119] 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 a single element 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 in 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.

[0120] In this disclosure, various "labels" may precede a noun or noun phrase. Unless the context provides otherwise, different labels used for a feature (e.g., "first circuit," "second circuit," "particular circuit," "given circuit," etc.) refer to different instances of the feature. In addition, when applied to features, the labels "first," "second," and "third" do not imply any type of order (e.g., spatial, temporal, logical, etc.) unless otherwise specified.

[0121] The phrase "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 as well as 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 also be 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 the phrase "based at least in part on."

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

[0123] 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 is 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 operating. Thus, an entity described or illustrated 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 implement the task. This phrase is not used herein to refer to an intangible object.

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

[0125] 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, this unprogrammed FPGA may be "configurable to" perform that function. After appropriate programming, the FPGA can be said to be "configured to" perform a particular function.

[0126] For purposes of filing a U.S. patent application based on this disclosure, reciting a claim as a structure "configured to" perform one or more tasks is not expressly intended to invoke 35 USC §112(f) for that claim element. If an applicant wishes to invoke §112(f) during prosecution of a U.S. patent application based on this disclosure, the applicant will recite the claim element using the structure "means for" [performing a function].

Claims

1. In the computing system, storing a skip list including a plurality of key / value records including one or more pointers to other ones of the plurality of key / value records; scanning the skip list for a location associated with a particular key, the scanning step comprising: using a prefix of the particular key to identify a particular portion of the skip list, the particular portion containing key / value records having keys with the same prefix; initiating a scan of said location within said identified portion; a scanning step including: A non-transitory computer-readable medium having stored thereon program instructions that can cause operations including

2. The scanning scanning forward through the key / value records within the particular portion along the highest available pointer in a skip list tower of key / value records until a key / value record is identified that contains a pointer to another key / value record located after the position associated with the particular key in key order; traversing the skip list from the identified key / value record; The computer readable medium of claim 1 , comprising:

3. The operation includes: responsive to said scan identifying said location, inserting a key / value record into said skip list at said location associated with said particular key; The computer-readable medium of claim 1 further comprising:

4. The operation includes: determining a set of pointers to include in the key / value record being inserted by sequentially scanning backwards from the identified location to identify key / value records that contain pointers to key / value records that are located after the identified location in key order; The computer readable medium of claim 3 further comprising:

5. The operation includes: determining the number of said pointers in said set prior to said sequential scanning in the reverse direction; determining whether to traverse the skip list from a sentinel node or sequentially scan backwards from the identified location based on the determined number; The computer-readable medium of claim 4 further comprising:

6. The operation includes: maintaining an index relating key prefixes to key / value records in each portion that have the same key prefix; and using the prefix further comprises: accessing the index to identify an initial key / value record within the particular portion from which to begin a scan; The computer-readable medium of claim 1 .

7. the index is a hash table; Accessing the index comprises: applying a hash function to the prefix to identify a hash bucket that contains a pointer to the initial key-value record within the particular portion; traversing the pointer to the initial key / value record within the particular portion; The computer readable medium of claim 6 , comprising:

8. The scanning selecting a first prefix of the particular key and a second prefix of the particular key to determine whether there is an associated portion of the skip list for the first prefix and the second prefix, the second prefix being longer than the first prefix; in response to determining that there is an associated portion in the skip list for the second prefix that is longer, selecting the portion associated with the second prefix for use in the scanning of the locations; The computer readable medium of claim 1 , comprising:

9. The operation includes: determining the length of the prefix to be used by accessing a set of anchor plans, the anchor plans specifying a prefix length to be used based on a portion of the particular key; The computer-readable medium of claim 1 .

10. the skip list maintains an order of keys of key / value records stored in a buffer data structure that stores data for active database transactions; The computer-readable medium of claim 1 .

11. storing, by a computing system, a skip list that maintains key ordering for the key / value records of the database; determining, by the computing system, a position within the skip list associated with a particular key; and the determining step comprises: using a prefix of the particular key to identify a range in the skip list, the range containing key / value records having keys with the same prefix; initiating a scan of the location within the identified range; A method comprising:

12. The determining step includes: scanning, by the computing system, forward through the identified range until a key / value record is identified that includes a skip list tower with a pointer that overshoots the location; traversing, by the computing system, the skip list from the skip list tower; The method of claim 11 , comprising:

13. In response to determining the location, scanning sequentially backwards from the location in the skip list by the computing system to identify pointers to be included in a tower of key / value records being inserted into the skip list; inserting, by the computing system, the key / value record at the determined location using the tower containing the identified pointer; The method of claim 11 further comprising:

14. The determining step includes: applying a hash function to the prefix to index into a hash table containing pointers to initial key / value records in the range; initiating said scan from said initial key / value record within said range; The method of claim 13, comprising:

15. the skip list maintains key ordering for key / value records of database transactions waiting to be committed by the database; The method of claim 11.

16. 1. A computing system comprising: one or more processors; The computing system includes: maintaining a skip list that preserves an order of keys for a plurality of key / value records; dividing the skip list into sections based on prefixes of the keys; determining a location associated with a particular key by starting a scan of locations within the section corresponding to a prefix of said particular key; A memory having stored thereon program instructions capable of implementing operations including: A computing system comprising:

17. The dividing step includes: maintaining a hash table that associates the prefixes with pointers to the sections in the skip list; 17. The computing system of claim 16.

18. The determining step includes: scanning forward within said section until a key / value record is identified that includes a skip list tower having a pointer pointing beyond said location; performing a skip list traversal from the identified key / value record to determine the location; 20. The computing system of claim 16, comprising:

19. The operation includes: for a key / value record that has been inserted into the skip list, scanning backwards along a bottom level of the skip list to identify a pointer to be inserted into a skip list tower; adding the key / value record to the skip list using the skip list tower; The computing system of claim 16 further comprising:

20. 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; 17. The computing system of claim 16.

Images