Similarity information in a skip list

Abstract

This paper discloses a technique involving skip lists. A computer system maintains a skip list, which consists of towers of different depths and entries storing pointers to other towers. A first tower includes entries located at a specific depth, and these entries store pointers for accessing entries in a second tower. The pointers include first similarity information, a quantity indicating the similarity between the keys of the first tower and the keys of the second tower. The computer system performs a traversal of the skip list for a search key. The computer system generates second similarity information, a quantity indicating the similarity between the keys of the first tower and the search key. Based on a comparison involving the first and second similarity information, and without accessing the second tower to obtain information about its keys, the computer system determines whether to use the pointers to traverse to the second tower or descend along the first tower.

Description

Technical Field

[0001] The public text as a whole deals with computer systems, and more specifically with various mechanisms for traversing and managing skip lists. Background Technology

[0002] Enterprises typically implement database management systems (or simply "database systems") to enable users to store collections of information in an organized manner that can be efficiently accessed and manipulated. In various cases, database systems implement a log-structured merge tree (LSM tree) with multiple levels, each level storing data from records as key-value pairs. A database system may include persistent storage housing the LSM tree and database nodes with local in-memory caches. During operation, database nodes initially write records to their in-memory cache and then flush the records to persistent storage. As part of flushing records, database nodes write records to a new file stored at one of the multiple levels of the LSM tree. Over time, as records are merged down the LSM tree, these records are rewritten to new files stored at lower levels. Attached Figure Description

[0003] Figure 1 This is a block diagram illustrating exemplary elements of a system having a database and a database application according to some implementation schemes, wherein the database application utilizes skip lists as part of managing the database.

[0004] Figure 2A This is a block diagram illustrating an exemplary skip table with pointers storing similarity information according to some embodiments.

[0005] Figure 2B This is a block diagram illustrating an exemplary traversal between records via indirect pointers according to some implementation schemes.

[0006] Figure 3A This is a block diagram illustrating exemplary letter distances between multiple keys according to some implementation schemes.

[0007] Figure 3B This is a block diagram illustrating exemplary components of similarity information according to some implementation schemes.

[0008] Figure 4 This is a block diagram illustrating an exemplary traversal of a skip list for locating a record for a search key, according to some implementations.

[0009] Figure 5 This is a block diagram illustrating an exemplary insertion of a record into a jump table and its tower according to some implementation schemes.

[0010] Figure 6This is a flowchart illustrating an exemplary method, according to some implementations, involving traversing a skip list to locate a record for a search key.

[0011] Figure 7 This is a block diagram illustrating the elements of a computer system for implementing the various systems described in the public text, according to some implementation schemes. Detailed Implementation

[0012] A particular database system manages a database built around an LSM tree, in which database records are stored in files written to persistent storage. During their operation, database nodes in such database systems can handle database transactions that involve writing records to a local in-memory cache / buffer and then flushing the records from the in-memory cache to the LSM tree, where records are “merged” down the tree over time by copying them from higher to lower levels. A common requirement for database systems managing LSM trees is that when groups of records are written to files in the LSM tree, these records must be written to the file in key-sorted order. However, records stored in the in-memory cache are not typically stored in key-sorted order, so locating records in key-sorted order to flush to files in the LSM tree can be a time-consuming process. To access records in the in-memory cache in key-sorted order, a data structure type called a “skip list” can be used. As used and described herein, a skip list refers to a data structure that includes a linked hierarchical structure of sequences of records, where each consecutive, lower sequence skips fewer elements than the previous sequence. Such a structure can be implemented using records in a tower / stack that store pointers to successive records. These successive records take advantage of the property that, on average, a pointer at level N+1 of the tower will skip twice as many records as a pointer at level N of the tower. Although skip lists are discussed in the context of database systems, skip lists are used in a variety of different applications, and the techniques for making public texts can be applied to those skip lists.

[0013] Traversing a skip list to locate a record for a search key can involve moving from one tower to the next (via pointers) and descending along the levels of the tower. To determine whether to move from the first tower to the second tower or descend along the levels of the first tower, a string comparison is performed between the search key and the key of the second tower (which is the key of the record that includes the second tower). If the search key is less than the key of the second tower, the traversal descends along the levels of the first tower; otherwise, the traversal advances to the second tower via pointers in the first tower, thus remaining at the same level. This process is then repeated until a record is located or cannot be located. However, this approach has several drawbacks. First, to perform the string comparison, the record containing the second tower must be accessed to determine the key of the second tower. Second, acquiring a latch / lock as part of the process of determining the key of the second tower and performing the string comparison can lead to contention between multiple participants interacting with records stored in an in-memory cache. Third, the key can be a fairly large string, so the string comparisons can be an expensive operation that accumulates together, especially when a single traversal involves many string comparisons. Among other things, the published text addresses the technical problem of how to implement a skip list that overcomes at least one or more of these defects.

[0014] In the various embodiments described below, the system includes a database and database nodes for writing database records to the database. The database nodes maintain skip lists that allow access to records in a key-sorting order. Skip lists include towers of varying depths and entries storing pointers to other towers. Thus, a first tower may include entries located at a specific depth, which store pointers to entries at the same depth (or, in some cases, higher depths) in a second tower that can be used to access those entries. In various embodiments, the pointers include similarity information identifying a quantity of similarity between the keys of the first tower and the keys of the second tower. This similarity information may take the form of offset value codes that identify: 1) the first byte (character) that differs between the keys of the first and second towers; and 2) the value of the differing byte of the key in the second tower. As an example, if the key of the first tower is “ABBC” and the key of the second tower is “ABBD”, then in various embodiments, the offset value code is (4, D) — their fourth bytes differ, and the fourth byte of the latter key is “D”.

[0015] In various implementations, when traversing the skip list for a search key, similarity information is generated based on the search key and the key of the current tower being traversed (e.g., the first tower mentioned above). Then, a comparison is performed between the newly generated similarity information and the similarity information encoded in a pointer to the next tower (e.g., the second tower). Based on the comparison, the database node determines whether to advance the traversal to the next tower using the pointer or descend along the current tower. If, as the comparison indicates, the letter distance between the key indicating the current tower and the key of the next tower is greater than the letter distance between the key of the current tower and the search key, the database node descends along the current tower; otherwise, in various implementations, the database node advances to the next tower. The database node may repeat this process until it reaches the record in the skip list corresponding to the search key.

[0016] These techniques may outperform existing methods because they allow the system to determine whether to advance a skip list traversal to the next tower without having to access the record containing the next tower to determine the key of the next tower. That is, since similarity information between the keys of the current tower and the next tower is stored in a pointer to the current tower and can be used to determine whether to advance to the next tower, the system does not need to access the record containing the next tower. Furthermore, since the record containing the next tower does not need to be accessed, latches do not need to be acquired as part of the process of determining the key of the next tower and performing comparisons, which reduces competition among multiple participants interacting with the record. Moreover, since the similarity information can be in the form of offset value codes, traversing the skip list involves integer comparisons (i.e., comparisons between offset value codes) rather than string comparisons (i.e., comparisons between the search key and the key of the next tower). Therefore, the computational cost of traversing the skip list is reduced.

[0017] Now go to Figure 1 A block diagram of system 100 is shown. System 100 includes a set of components that can be implemented via hardware or a combination of hardware and software routines. In the illustrated embodiment, system 100 includes a database 110 and database nodes 140. As shown, database 110 includes an LSM tree 120 having records 130 including keys 135, and database nodes 140 include a database application 150 and an in-memory cache 160. As further shown, the in-memory cache 160 includes records 130 that collectively implement a skip list 170 having a tower 175 including entries 177. Similarly, as shown, entries 177 include pointers 180 that include similarity information 185. In some embodiments, system 100 is implemented in a different manner than shown. For example, skip list 170 may be stored separately from records 130, and database 110 may store records 130 independently of LSM tree 120, etc.

[0018] In various implementations, system 100 implements platform services (e.g., customer relationship management (CRM) platform services) that allow users of the services to develop, run, and manage applications. System 100 may be a multi-tenant system providing various functionalities to users / tenants hosted by a multi-tenant system. Therefore, system 100 can execute software routines from various different users (e.g., the provider and tenants of system 100), and provide code, web pages, and other data to users, databases, and entities associated with system 100 (e.g., third-party systems). In various implementations, system 100 is implemented using cloud infrastructure provided by a cloud provider. Therefore, database 110 and database node 140 can execute on and utilize the available cloud resources (e.g., computing resources, storage resources, etc.) of the cloud infrastructure to facilitate their operation. For example, program code capable of executing to implement components of database node 140 can be stored on non-transitory computer-readable media of server-based hardware included in the cloud provider's data center and executed in virtual machines hosted on the server-based hardware. In some cases, database node 140 can run on a computing system within a cloud infrastructure without the aid of virtual machines or specific deployment technologies such as containerization. In some implementations, system 100 is implemented on on-premises or private infrastructure relative to the public cloud.

[0019] In various implementations, database 110 is a collection of information organized in a manner that allows access, storage, and / or manipulation of information. Database 110 may include supporting software (e.g., storage nodes) that allows database nodes 140 to perform these operations (e.g., access, storage, etc.) on the information stored at database 110. In various implementations, database 110 is implemented using one or more storage devices connected together on a network (e.g., a storage attached network (SAN)) and configured to redundantly store information to prevent data loss. The storage devices can persistently store data, and therefore database 110 can be used as a persistent storage device for system 100. Furthermore, as discussed, components of system 100 can utilize available cloud resources of a cloud infrastructure and therefore can use storage services provided by a cloud provider (e.g., Amazon S3). ® The database 110 stores data. In various implementations, data written to the database 110 by the database server 140 can be accessed by other database servers 140 in a multi-node configuration. As depicted, the database 110 includes an LSM tree 120, which organizes at least a portion of the data managed by the database node 140.

[0020] In various implementations, LSM tree 120 is a data structure that stores files (with records 130) in an organized manner using a hierarchical scheme. Record 130 can be a key-value pair that includes data and a corresponding key 135 that can be used to look up record 130. For example, record 130 can be a row in a database table, where record 130 specifies the value of one or more attributes associated with the database table. In various implementations, record 130 is immutable once written. To update the value of a given record 130, database node 140 writes a new record 130 with the updated value, replacing the older record 130. However, older records 130 can continue to be persistently stored in LSM tree 120. Records 130 can be written in batches from an in-memory cache 160 to files at the top level of LSM tree 120 in database 110 and merged down the hierarchy of LSM tree 120 over time. In various implementations, records 130 written to files in LSM 120 are written in key-sorted order. Therefore, a file can be associated with a range of keys defined by key 135 of the record 130 included in the file. In order to write the record 130 in a key-sorted order in an efficient manner, the database node 140 uses a skip list 170.

[0021] In various implementations, database node 140 provides database services such as data storage, data retrieval, and / or data manipulation. In various implementations, database node 140 is software capable of execution on hardware, while in some implementations, the database node encompasses both hardware and software. Database services can be provided to other components within system 100 and / or components outside system 100. For example, database node 140 can receive transaction requests 155 from an application node via an established database connection to execute database transactions. In various implementations, a database transaction is a logical unit of work (e.g., a specified set of database statements) to be performed with respect to database 110. For example, processing a database transaction may include executing an SQL SELECT statement to select one or more rows from one or more tables. The content of the rows may be specified in record 130, and therefore database node 140 may return one or more records 130 corresponding to one or more rows. Executing a database transaction may also include database node 140 writing data records 130 to database 110.

[0022] In various implementations, database application 150 is executable software that provides database services to database node 140. Therefore, database application 150 can receive transaction requests 155 (e.g., received from an application node) and process these transaction requests. To process database transactions, database application 150 can execute one or more query plans that define a corresponding sequence of steps to be performed, in order to implement database statements for the database transactions. In various implementations, database application 150 can access the definition of the query plan (e.g., from database 110), compile it into an executable form, and store it in an in-memory cache 160. In response to a request to execute a database statement, database application 150 can obtain and execute the compiled form of the query plan corresponding to the database statement. As part of processing transaction requests, database application 150 can also execute user-defined functions to perform desired operations—these functions can also be compiled and stored in the in-memory cache 160. Furthermore, database application 150 can process transactions according to guidelines for ensuring transaction consistency, such as ACID (Atomicity, Consistency, Isolation, and Durability).

[0023] In various implementations, in-memory cache 160 is a buffer that stores data in the memory (e.g., random access memory) of database node 140. HBase™ memstore is an example of in-memory cache 160. In various implementations, database application 150 initially writes record 130 to in-memory cache 160. When in-memory cache 160 becomes full and / or at a specific point in time, database application 150 may flush record 130 from in-memory cache 160 to database 110, where record 130 may be stored in a set of files included in the top level of LSM tree 120. As discussed, in various implementations, record 130 is written to files in tree 120 in key-sorted order. To access record 130 in in-memory cache 160 in key-sorted order, database application 150 may use skip list 170. Skip list 170 may also be used as part of processing database transactions to locate record 130 (e.g., returning record 130 that falls within a specific key range).

[0024] In various embodiments, skip list 170 is a data structure comprising a linked hierarchical structure of records 130, wherein each successive, lower sequence skips fewer records 130 than the previous sequence. Specifically, skip list 170 comprises a sequence of towers 175 with different depths and tower entries 177 that store pointers 180 to other towers 175. In various embodiments, tower 175 is a structure having a set of levels representing its depth. Each level of tower 175 may include an entry 177 storing pointers 180 that point to the next tower 175 in the sequence of towers 175 that has an entry 177 at the lower level, thus skipping smaller towers 175. At least a portion of the records 130 in the in-memory cache 160 collectively implements skip list 170 by storing the corresponding towers 175. Relative to Figure 2A Let's discuss the example of skip table 170 in more detail.

[0025] In various implementations, pointer 180 is information that can be used to access tower 175 (or more specifically, record 130 of storage tower 175) pointed to by pointer 180. Pointer 180 may point directly to record 130 of storage tower 175, or indirectly to record 130 by pointing to another location (e.g., a hash bucket), which in turn points to record 130. Relative to Figure 2B An example of the indirect pointer 180 is discussed in more detail. In addition to storing pointer information, pointer 180 also stores similarity information 185. In various embodiments, similarity information 185 indicates the amount of similarity between the key 135 of the record 130 containing tower 175 (which includes similarity information 185) and the key 135 of the record 130 storing tower 175 pointed to by pointer 180 (which includes similarity information 185). Relative to Figure 3B Examples of similarity information 185 are discussed in more detail. In various implementations, the quantity of similarity is defined or represents the letter distance between two keys. Relative to Figure 3A Examples of letter distances will be discussed in more detail.

[0026] In various implementations, when traversing skip list 170 (e.g., to access specific records 130 in key-sorted order), database application 150 compares the similarity information 185 of pointer 180 with the similarity information 185 derived from search key 135 and key 135 of current tower 175. (As relative to...) Figure 4In more detail, based on comparisons, database application 150 can determine whether to advance to the next applicable tower 175 or descend along the current tower 175. Therefore, through a series of comparisons, database application 150 can traverse skip list 170 horizontally and vertically to locate the record 130 that matches search key 135. When accessing multiple records 130 in key-sorted order, database application 150 can use a pointer to the located record 130 to access records 130 that appear sequentially in order. Record 130 can also store a pointer to the next record 130, which in turn points to the next record 130, and so on. Therefore, database application 150 can traverse a series of records 130 in key-sorted order.

[0027] Now go to Figure 2A A block diagram of an exemplary skip table 170 with pointers 180 storing similarity information 185 is shown. In the illustrated embodiment, the skip table 170 includes five towers 175A-E at different depths—towers 175A, 175C, and 175E have four levels, tower 175D has three levels, and tower 175B has two levels. Similarly, as shown, each level of towers 175A-D includes a corresponding pointer 180 storing the corresponding similarity information 185. As further shown, towers 175A-E are respectively included in records 130A-E. Records 130A-E each include keys 135A-E, and each record 130 points to the next record 130 in the series of records 130A-E (except for record 130E). The illustrated embodiment can be implemented in a different manner than shown. For example, records 130A-E can be stored in key-sorted order, with pointers to the next record 130 and the previous record 130, so that records 130A-E can be traversed in both directions (i.e., 130A→130E and 130E→130A).

[0028] As discussed, in various embodiments, similarity information 185 indicates the amount of similarity between two keys 135. In the illustrated embodiment, the top level of tower 175A points to the top level of tower 175C, and entry 177 of the top level of tower 175A includes a pointer 180 with similarity information 185A. Since pointer 180 relates to towers 175A and 175C, similarity information 185A indicates the amount of similarity between keys 135A and 135C that store records 130A and 130C of towers 175A and 175C, respectively. The next level down from tower 175A also includes entry 177 with pointer 180, which points to tower 175C at the same level as pointer 180—skipping tower 175B, since tower 175B has no entry 177 below that level. Therefore, the similarity information 185B of pointer 180 is the same as the similarity information 185A of pointer 180 in the previous level, because they both point to the same tower 175 (and therefore involve the same key 135). However, the next level of tower 175A includes an entry 177 with a pointer 180 pointing to tower 175B. Therefore, the similarity information 185C of pointer 180 of entry 177 indicates the amount of similarity between the keys 135A and 135B of records 130A and 130B, respectively. Entries 177 in the same level of tower 175B store similarity information 185D, which indicates the amount of similarity between the keys 135B and 135C of records 130B and 130C, respectively. Therefore, in various embodiments, the similarity information 185 stored in entry 177 throughout skip list 170 can vary based on the tower 175 that it points to (target tower) and the tower 175 with entry 177 pointing to the target tower (origin tower). Although pointer 180 is shown as pointing directly to the next applicable tower 175, pointer 180 may be an indirect pointer to another location (e.g., a hash bucket), which in turn points to the record 130 storing the next applicable tower 175, as discussed below.

[0029] Now go to Figure 2B A block diagram illustrating an exemplary traversal between records 130 using indirect pointer 180 is shown. In the illustrated embodiment, there are records 130A-C respectively connected to hash buckets 210A-C. As shown, record 130A includes entry 177A with pointer 180A pointing to hash bucket 210C and entry 177B with pointer 180B pointing to hash bucket 210B—these entries 177 may correspond to different levels of tower 175 (the tower's data is included in record 130A). The illustrated embodiment can be implemented in a different manner than shown—for example, pointers 180A and 180B could point directly to record 130.

[0030] In various implementations, a fixed amount of storage space is allocated in the in-memory cache 160 for storing records 130. In this case, when record 130 is removed, other records 130 can be relocated within the fixed storage space to provide contiguous storage space for the new record 130. In some implementations, pointer 180 is a direct pointer to record 130 and thus specifies the physical memory address where its corresponding record 130 is stored. When a record moves within the in-memory cache 160, pointer 180 pointing to record 130 must be updated to reflect the new location of record 130 (in the case of using direct pointer 180). The process may involve updating many pointers 180. Consider... Figure 2A The diagram shows record 130C. If record 130C is moved, four different pointers 180 must be updated to reflect the new position of record 130C. For a large skip list 170, updating pointers 180 can take a long time, during which time access to the skip list 170 may be restricted. In various embodiments, indirect pointers 180 are used to reduce the number of pointers 180 that need to be updated.

[0031] In various embodiments, indirect pointer 180 is a pointer to a location (e.g., hash bucket 210 in the illustrated embodiment), which in turn points to the associated record 130. Hash bucket 210 may be part of a hash table, where each hash bucket 210 corresponds to an entry in the hash table and can be accessed by calculating the index value of the entry using a hash function on the bucket identifier. Thus, indirect pointer 180 can identify the bucket identifier of hash bucket 210 that stores a pointer to record 130 (indirect pointer 180 indirectly points to the record). For example, as shown, pointer 180A indirectly points to record 130C by pointing to hash bucket 210C, and similarly, pointer 180B indirectly points to record 130B by pointing to hash bucket 210B. Therefore, in various embodiments, traversing from the first tower 175 to the second tower 175 involves accessing hash bucket 210 via pointer 180, and then accessing the record 130 stored in the second tower 175 via hash bucket 210. By using indirect pointer 180, when record 130 is relocated in memory cache 160, only one pointer (hash bucket pointer) needs to be updated.

[0032] In embodiments where similarity information 185 is not used but hash bucket 210 is used, determining whether to traverse from the first tower 175 to the second tower 175 involves obtaining information about the key 135 of the second tower 175. Obtaining information involves acquiring a latch / lock on hash bucket 210 that points to the record 130 storing the second tower 175, making it possible to read the key 135 and also preventing another process from making changes that affect the key 135. However, in embodiments where similarity information 185 is used, determining whether to traverse from the first tower 175 to the second tower 175 does not involve acquiring a latch / lock on hash bucket 210 associated with the second tower 175, because the database application 150 does not need to obtain information about the key 135 of the second tower in order to determine whether to traverse to the second tower 175. Therefore, traversing a skip table 170 with similarity information 185 involves fewer latches than traversing a skip table 170 without similarity information 185.

[0033] Now go to Figure 3A A block diagram illustrating exemplary letter distances 310 between various keys 135 is shown. In the illustrated embodiment, keys 135A-C are present. As shown, key 135A has the value "AXPTZLMOQRZPKTAA", key 135B has the value "CXPTZLMOQRZPKTAA", and key 135C has the value "YFDTZLMOQRZPKTAA". Similarly, as shown, there is a letter distance 310A between keys 135A and 135B, and a letter distance 310B between keys 135A and 135C. The illustrated embodiment can be implemented in a different manner than shown—for example, keys 135 can be alphanumeric strings, the length of keys 135 can vary (e.g., keys 135A and 135C can be the same length, while key 135B can be shorter or longer), etc.

[0034] In various implementations, the letter distance 310 between two keys 135 represents how close (or far) the two keys 135 are in alphabetical order (or, in some cases, alphanumeric order). As discussed below, the letter distance 310 can be expressed as an offset value code with two values: an index value and a difference value. Comparisons of the letter distances 310 can be used to determine which key 135 is closer to a particular key 135. For example, in the illustrated implementation, the letter distance 310A between keys 135A and 135B is shorter than the letter distance 310B between keys 135A and 135C because, alphabetically, "C" is closer to "A" than "Y". In various implementations, a comparison of similarity information 185 (representing letter distance 310A) between keys 135A and 135B and similarity information 185 (representing letter distance 310B) between keys 135A and 135C can be used to determine whether key 135B is closer to key 135A in alphabetical order (or alphanumeric order if key 135 also includes numbers) compared to keys 135C through 135A. Based on this knowledge, database application 150 can determine whether to descend along tower 175 or traverse to the next tower 175, as relative to... Figure 4 To be discussed in more detail.

[0035] Now go to Figure 3B A block diagram of similarity information 185 is shown. In the illustrated embodiment, similarity information 185 includes an index value 320 and a difference value 330. As further shown, there are keys 135A (with the value "AXPTZLMOQRZPKTAA") and 130B (with the value "AXPTZLMOQMZAQLMP"). The illustrated embodiment can be implemented in a different manner than shown—for example, keys 135A and 135B can be alphanumeric strings and / or have different lengths from each other.

[0036] As discussed, the letter distance 310 between two keys 135 can be expressed as an offset value code included in the similarity information 185. As shown, the similarity information 185 includes an index value 320 and a difference value 330, which together form the offset value code. In various embodiments, the index value 320 identifies the position in a byte sequence (e.g., a character sequence) corresponding to the first byte (character) that differs between the two keys 135. For example, as depicted, keys 135A and 135B differ at their 10th character (i.e., the “R” of key 135A versus the “M” of key 135B), therefore the index value 320 identifies the 10th position. In some embodiments, the index value 320 may identify the position corresponding to the last identical byte between the two keys 135 (i.e., the 9th position in the previous example). In either case, the index value 320 indicates the identical character sequence between the two keys 135, starting from the first byte. Therefore, in the illustrated embodiment, index value 320 indicates that the sequence “AXPTZLMOQ” is the same between keys 135A and 135B. In various embodiments, the difference value 330 is the value of the byte that differs from the key 135 of the next / target tower 175 between the keys 135 corresponding to the origin tower 175 and the target tower 175. Consider an example where key 135A corresponds to the first tower 175 and key 135B corresponds to the second tower 175, and the traversal moves from the first tower 175 (origin tower) to the second tower 175 (target tower). In this example, the difference value 330 is the value “M” of key 135B, because this is the character that appears sequentially after the matching sequence between keys 135A and 135B.

[0037] In some implementations, the key 135 of the target tower 175 can be stored in the similarity information 185 (instead of the offset value code). However, the key 135 may be quite long (e.g., exceeding 256 bytes), so storing them in the pointer 180 may be impractical (e.g., if the pointer 180 is only 64 bits) or undesirable. Furthermore, string comparisons are computationally more expensive than integer comparisons. Therefore, storing the offset value code (in the form of index value 320 and difference value 330) in the similarity information 185 instead of the key of the target tower 175 can offer several advantages.

[0038] In various implementations, index value 320 and difference value 330 are used to determine which key 135 (between two keys 135) is closer to a particular key 135. Consider an example where there are three keys: a first key 135, a second key 135, and a search key 135. First similarity information 185 can be generated between the first key 135 and the second key 135, and second similarity information 185 can also be generated between the first key 135 and the search key 135. To determine whether the second key 135 is closer to the first key 135 alphabetically than the search key to the first key 135 (i.e., has a shorter alphabetical distance 310), the index values ​​320 of the first similarity information 185 and the second similarity information 185 are compared. In various implementations, a position value identified by index 320 (e.g., the 10th position) being greater than an index value identifying a smaller position value (e.g., the 1st position) means that keys 135 associated with a previous index value 320 are more similar to each other alphabetically than keys 135 associated with a later index value 320. As an example, if index 320 between the first key 135 and the second key 135 is "1" (indicating these keys 135 differ at the first character / byte), and index 320 between the first key 135 and the search key 135 is "10" (indicating these keys 135 differ at the tenth character / byte), then the search key 135 can be determined to be closer to the first key 135 than the second key 135 to the first key 135 because the search key 135 shares a higher similarity with the first key 135 (the first nine characters of these keys 135 are the same).

[0039] If index values ​​320 are the same, a comparison between difference values ​​330 can be performed. In various implementations, the key 135 associated with the difference value 330 that is first in alphabetical order relative to another key 135 is considered closer to the specific key 135 to which the evaluation of both keys 135 is directed. Consider an example where the second tower key 135 has a difference value 330 "T" and the search key 135 has a difference value "L". Because "L" comes before "T" in alphabetical order, the search key 135 is closer to the first tower key 135. However, if index values ​​320 match and difference values ​​330 match, the database application 150 can access the record 130 of the second tower 175 to determine the full value of the second tower key 135. The database application 150 can compare the search key 135 with the second tower key 135 to determine whether to traverse to the second tower 175 or descend along the first tower 175.

[0040] Now go to Figure 4A block diagram is shown of an exemplary traversal of a skip list 170 for locating a record 130 with search key 135. In the illustrated embodiment, there are records 130A-D with corresponding towers. As further shown, key 135 for record 130A has the value "A", key 135 for record 130B has the value "F", key 135 for record 130C has the value "S", and key 135 for record 130D has the value "W". As shown, search key 135 for traversal 400 has the value "S". The illustrated embodiment can be implemented in a different manner than shown. For example, records 130A-D may also include pointers that allow traversal of these records 130 in the opposite direction to that shown. Furthermore, for simplicity... Figure 4 The text shows the letter distance 310 in pointer 180 represented by similarity information 185, instead of similarity information 185.

[0041] In various implementations, traversal 400 begins at the top level of the leftmost tower 175 (referred to as the sentinel tower) of skip list 170. Database application 150 generates similarity information 185 between search key 135(S) and key 135(A) of record 130A, and then compares the generated similarity information 185 (not shown) with similarity information 185 of pointer 180A (also not shown). In response to determining that the letter distance 310 (represented as A→W) between key 135(A) and (W) is greater than the letter distance 310 (represented as A→S) between key 135(A) and search key 135(S), as indicated by the comparison, database application 150 descends along the tower of record 130A to the next level, as shown in the figure. Then, the database application 150 compares the generated similarity information 185 with the similarity information 185 (not shown) of the pointer 180B, and descends along the current tower because the letter distance 310 (A→W) is greater than the letter distance 310 (A→S).

[0042] Subsequently, database application 150 compares the generated similarity information 185 with the similarity information 185 (not shown) of pointer 180C. In response to determining that the letter distance 310 (denoted as A→F) between keys 135(A) and (F) is less than the letter distance 310 (denoted as A→S) between key 135(A) and search key 135(S), as indicated by the comparison, database application 150 traverses to the tower of record 130B, as shown. Database application 150 generates new similarity information 185 between search key 135(S) and key 135(F) of record 130B, and then compares the generated similarity information 185 with the similarity information 185 (not shown) of pointer 180D. In response to the comparison, database application 150 descends along the current tower because the letter distance 310 (F→W) is greater than the letter distance 310 (F→S). Then, database application 150 compares the generated similarity information 185 with the similarity information 185 (not shown) of pointer 180E. In response to the comparison, database application 150 traverses the tower of record tower 130C because letter distance 310 (F→S) equals letter distance 310 (F→S). Therefore, database application 150 has reached the record 130 corresponding to search key 135 (S). Database application 150 can traverse one or more records 130 in key-sorted order, starting from record 130C.

[0043] Now go to Figure 5 A block diagram is shown illustrating the exemplary insertion of record 130 and its tower 175 into skip list 170. In the illustrated embodiment, records 130A and 130B, each including a corresponding tower, initially exist. During its operation, database application 150 may insert record 130 into in-memory cache 160 and, as part of the insertion, add record 130 to skip list 170. As shown, database application 150 adds record 130C to skip list 170 such that the tower of record 130C falls between the towers of records 130A and 130B, because key 135(F) of record 130C lies between keys 135(A) and key (W) of records 130A and 130B. In various embodiments, as part of adding record 130 to skip list 170, database application 150 recalculates similarity information 185 of multiple pointers 180. In the illustrated embodiment, the similarity information of pointer 180A is recalculated based on keys 135(A) and (F) of records 130A and 130C, and the similarity information of pointer 180B is calculated based on keys 135(F) and (W) of records 130C and 130B. Although only one tower level is recalculated in the illustrated embodiment, in various cases, the towers inserted into skip table 170 have multiple levels, so database application 150 can calculate the similarity information of pointer 180 across multiple towers and / or multiple levels.

[0044] Furthermore, records 130 can be removed from skip list 170 (e.g., after these records 130 are flushed to LSM tree 120). Similar to inserting record 130, database application 150 can calculate the similarity information of pointer 180 across multiple towers and / or multiple levels. For example, if record 130C is subsequently removed and records 130A and 130B are retained, database application 150 recalculates the similarity information of pointer 180A based on keys 135(A) and (W) of records 130A and 130B. Therefore, the similarity information of pointer 180 can change throughout the lifetime of pointer 180 when record 130 is inserted into or removed from in-memory cache 160.

[0045] Now go to Figure 6 A flowchart of method 600 is shown. Method 600 is one embodiment of a method executed by a computer system (e.g., system 100) to traverse a skip list (e.g., skip list 170) to locate a record (e.g., key 135) for a search key (e.g., key 135). Method 600 can be executed by executing program instructions stored on a non-transitory computer-readable medium. Method 600 can also be executed as part of writing one or more records from an in-memory cache (e.g., in-memory cache 160) to a storage repository. Method 600 may include more or fewer steps than shown. For example, method 600 may include a step in which a record is removed from the skip list and the skip list is updated to reflect the removal.

[0046] Method 600 begins in step 610, wherein the computer system maintains a skip list that allows access to groups of records in key-sorted order. The skip list includes groups of towers (e.g., tower 175) with different depths and entries (e.g., tower entry 177) storing pointers (e.g., pointer 180) to other towers. A first tower may include an entry located at a specific depth, storing a pointer to an entry at a specific depth in a second tower. The pointer includes first similarity information (e.g., similarity information 185) indicating the amount of similarity between the key of the first tower based on the record corresponding to the first tower and the key of the second tower based on the record corresponding to the second tower. In various embodiments, the groups of records implement the skip list such that the first tower is stored as data in a first record within the group of records, and the second tower is stored as data in a second record within the group of records.

[0047] In step 620, the computer system performs a traversal of the skip list to locate the record for the search key. In step 622, as part of performing the traversal, the computer system generates second similarity information indicating the amount of similarity between the key of the first tower and the search key. In various embodiments, the amount of similarity indicated by the first similarity information corresponds to a first letter distance (e.g., letter distance 310) between the key of the first tower and the key of the second tower. The first similarity information may include: a first portion (e.g., index value 320) indicating a first subsequence of the character sequence of the key of the first tower that matches a second subsequence of the character sequence of the key of the second tower; and a second portion (e.g., difference value 330) identifying the value of a difference character that appears sequentially after the second subsequence in the character sequence of the key of the second tower.

[0048] In step 624, based on a comparison involving first and second similarity information, the computer system determines whether to use a pointer to advance the traversal (e.g., traversal 400) to the second tower or descend along the first tower. This determination is performed without accessing the second tower to obtain information about its keys. In response to a comparison indicating that the first letter distance is greater than the second letter distance between the key in the first tower and the search key, the computer system descends along the first tower to advance the traversal instead of using a pointer to access the second tower. In response to a comparison indicating that the first letter distance is not greater than the second letter distance between the key in the first tower and the search key, the computer system uses a pointer to access the second tower to advance the traversal instead of descending along the first tower.

[0049] In various embodiments, the first record can be accessed via a first hash bucket (e.g., hash bucket 210), and the second record can be accessed via a second hash bucket. In various embodiments, the determination in step 624 is performed without retrieving a latch on the second hash bucket. Accessing an entry in the second stack using a pointer may include accessing the second hash bucket via a pointer and subsequently accessing the second record stored in the second stack via the second hash bucket.

[0050] A computer system can update a skip list to insert a third tower residing between the first and second towers. In some cases, the third tower includes entries located at a specific depth. Therefore, the update may include the computer system generating a amount of third similarity information indicating the similarity between the keys of the first tower and the keys of the third tower, and then updating the pointers to the entries of the first tower to store the third similarity information instead of the first similarity information and allowing access to the third tower via the pointers. A computer system can also update a skip list to remove a second tower. Therefore, the update may include the computer system generating a amount of third similarity information indicating the similarity between the keys of the first tower and the keys of the third tower (the third tower has entries located at a specific depth). The computer system may then update the pointers to the first tower to store the third similarity information instead of the first similarity information and allowing access to the third tower via the pointers.

[0051] Exemplary computer system

[0052] Now go to Figure 7 A block diagram depicts an exemplary computer system 700 that can implement system 100, database 110, and / or database node 140. Computer system 700 includes a processor subsystem 780 connected to system memory 720 and I / O interface 740 via interconnect 760 (e.g., system bus). I / O interface 740 is connected to one or more I / O devices 750. Although for convenience, in... Figure 7 A single computer system 700 is shown, but system 700 can also be implemented as two or more computer systems operating together.

[0053] Processor subsystem 780 may include one or more processors or processing units. In various embodiments of computer system 700, multiple instances of processor subsystem 780 may be coupled to interconnect 760. In various embodiments, processor subsystem 780 (or each processor unit within 780) may include cache or other forms of onboard memory.

[0054] System memory 720 can be used to store program instructions that can be executed by processor subsystem 780 to cause system 700 to perform the various operations described herein. System memory 720 can be implemented using different physical memory media, such as hard disk storage devices, floppy disk storage devices, removable disk storage devices, flash memory, random access memory (RAM—SRAM, EDO RAM, SDRAM, DDR SDRAM, RAMBUS RAM, etc.), read-only memory (PROM, EEPROM, etc.), and so on. The memory in computer system 700 is not limited to main storage devices such as memory 720. Instead, computer system 700 may also include other forms of storage devices, such as cache memory in processor subsystem 780 and auxiliary storage devices (e.g., hard disk drives, storage arrays, etc.) on I / O devices 750. In some embodiments, these other forms of storage devices can store program instructions that can be executed by processor subsystem 780. In some embodiments, program instructions that implement database application 150 and / or in-memory cache 160 when executed may be included / stored in system memory 720.

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

[0056] The published text includes references to “implementation schemes,” which are non-limiting ways of realizing the disclosed concepts. References to “implementation scheme,” “an implementation scheme,” “a specific implementation scheme,” “some implementation schemes,” “various implementation schemes,” etc., do not necessarily refer to the same implementation scheme. Numerous possible implementation schemes are envisioned, including specific implementation schemes described in detail, as well as modifications or substitutions falling within the spirit or scope of the published text. Not all implementation schemes will necessarily exhibit any or all of the potential advantages described herein.

[0057] The disclosure may discuss potential advantages that may arise from the disclosed embodiments. Not all implementations of these embodiments will necessarily exhibit any or all of these potential advantages. Whether an advantage is realized for a particular implementation depends on many factors, some of which are outside the scope of the disclosure. In fact, there are multiple reasons why an implementation falling within the scope of the claims may not exhibit some or all of the disclosed advantages. For example, a particular implementation may include other circuitry outside the scope of the disclosure, which, in combination with an embodiment of the disclosed embodiments, negates or diminishes one or more of the disclosed advantages. Furthermore, suboptimal design execution of a particular implementation (e.g., the implementation technique or tool) may also negate or diminish the disclosed advantages. Even assuming a skilled implementation, the realization of an advantage can still depend on other factors, such as the environmental circumstances in which the implementation is deployed. For example, the inputs provided to a particular implementation may prevent one or more problems addressed in the disclosure from occurring in a particular context, resulting in the benefits of its solution potentially not being realized. Given the existence of possible factors outside the disclosure, this invention expressly aims that any potential advantages described herein should not be construed as requiring the satisfaction of claims limitations to prove infringement. Rather, the identification of such potential advantages is intended to indicate the types of improvements available to the designer that benefit from the disclosure. The permissive description of such advantages (e.g., stating that a particular advantage "may occur") is not intended to express doubt about whether such advantages can actually be realized, but rather to recognize the technological reality that the realization of such advantages often depends on additional factors.

[0058] Unless otherwise stated, the embodiments are non-limiting. That is, the disclosed embodiments are not intended to limit the scope of the claims drafted based on the disclosure, even where only a single example is described with respect to a particular feature. The disclosed embodiments are intended to be illustrative rather than restrictive unless there is any statement to the contrary in the disclosure. Therefore, this application is intended to allow the claims to cover the disclosed embodiments, as well as such alternatives, modifications, and equivalents of the disclosure that would be apparent to those skilled in the art and would benefit from.

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

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

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

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

[0063] Unless the context clearly specifies otherwise, references to the singular form of an item (i.e., nouns or noun phrases beginning with "an," "a," or "the") are intended to mean "one or more." Therefore, references to "an / a type" in a claim do not exclude additional instances of that item in the absence of accompanying context. "A plurality of" items refer to a collection of two or more of that item.

[0064] The word “can” is used in this text in a permissive sense (i.e., having the possibility, being able) rather than in a mandatory sense (i.e., having to).

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

[0066] When the term “or” is used in public text in relation to a list of options, it is generally understood to be used in an inclusive sense, unless the context otherwise specifies. Therefore, a statement of “x or y” is equivalent to “x or y, or both,” and thus encompasses: 1) x but not y; 2) y but not x; and 3) both x and y. On the other hand, phrases such as “either x or y, but not both” clearly indicate that “or” is used in an exclusive sense.

[0067] The statements “w, x, y, or z or any combination thereof” or “...at least one of w, x, y, and z” are intended to cover all possibilities involving a single element up to all elements in the set. For example, given the set [w, x, y, z], these terms cover any single element of the set (e.g., w, but 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. Therefore, the phrase “...at least one of w, x, y, and z” refers to at least one element in the set [w, x, y, z], thus covering all possible combinations of the list of elements. This phrase should not be interpreted as requiring the existence of at least one instance of w, at least one instance of x, at least one instance of y, and at least one instance of z.

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

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

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

[0071] Within the publicly available text, different entities (which may be referred to differently as “units,” “circuits,” other components, etc.) may be described or claimed to be “configured” to perform one or more tasks or operations. This expression—[entity] configured to [perform one or more tasks]—is used herein to refer to a structure (i.e., a physical thing). More specifically, this expression is used to indicate that the structure is arranged to perform one or more tasks during operation. A structure may be referred to as being “configured” to perform a particular task even if the structure is not currently being operated. Therefore, an entity described or stated as being “configured” to perform a particular task refers to physical things such as devices, circuits, systems having processor units and memory storing program instructions that can be executed to perform that task, etc. This phrase is not used herein to refer to intangible things.

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

[0073] The term "configured as" is not intended to mean "configurable as". For example, an unprogrammed FPGA would not be considered "configured as" to perform a specific function. However, the unprogrammed FPGA can be "configurable as" to perform that function. After proper programming, the FPGA can then be referred to as "configured as" to perform that specific function.

[0074] For the purposes of a U.S. patent application based on a published text, a statement structure in the claims that is “configured” to perform one or more tasks is expressly intended not to invoke 35 USC § 112(f) for that claim element. If an applicant wishes to invoke 112(f) during the examination of a U.S. patent application based on a published text, it will use the “means for [performing a function]” structure to state the claim element.

Claims

1. A method comprising: A skip list maintained by a computer system allows access to groups of records in key-sorted order. The skip list comprises groups of towers with different depths and entries storing pointers to other towers. A first tower includes entries at a specific depth that store pointers to entries at the same depth in a second tower. These pointers include first similarity information indicating the amount of similarity between the keys of the first tower and the keys of the second tower, based on the keys of the records corresponding to the first tower. as well as The computer system performs a traversal of the skip list to locate the record for the search key, wherein the execution of the traversal includes: Generate second similarity information, which indicates the amount of similarity between the key of the first tower and the search key; as well as Based on a comparison involving the first similarity information and the second similarity information, it is determined whether to use the pointer to advance the traversal to the second tower or descend along the first tower, wherein the determination is performed without accessing the second tower to obtain key information about the key of the second tower.

2. The method of claim 1, wherein the amount of similarity indicated by the first similarity information corresponds to a first letter distance between the key of the first tower and the key of the second tower.

3. The method according to claim 2, further comprising: In response to the comparison indicating that the first letter distance is greater than the second letter distance between the key in the first tower and the search key, the computer system descends along the first tower to advance the traversal, instead of using the pointer to access the second tower.

4. The method according to claim 2, further comprising: In response to the comparison indicating that the first letter distance is not greater than the second letter distance between the key in the first tower and the search key, the computer system uses the pointer to access the second tower to advance the traversal, instead of descending along the first tower.

5. The method according to claim 1, wherein the first similarity information includes: The first part indicates a first subsequence of the character sequence of the key of the first tower, the first subsequence matching a second subsequence of the character sequence of the key of the second tower; and The second part identifies the value of the difference character that appears sequentially after the second subsequence in the character sequence of the key of the second tower.

6. The method of claim 1, wherein the grouped records implement the skip list such that the first tower is stored as a first record in the grouped records, and the second tower is stored as a second record in the grouped records.

7. The method of claim 6, wherein the first record is accessible via a first hash bucket, and the second record is accessible via a second hash bucket, and wherein the determination is performed without acquiring a latch on the second hash bucket.

8. The method of claim 6, wherein the second record is accessible via a hash bucket, wherein accessing the entry of the second tower using the pointer includes accessing the hash bucket via the pointer and subsequently accessing the second record storing the second tower via the hash bucket.

9. The method according to claim 1, further comprising: The computer system updates the skip list to insert a third tower residing between the first and second towers, wherein the third tower includes an entry located at the specific depth, and wherein the update includes: Generate third similarity information, the third similarity information indicating the amount of similarity between the keys of the first tower and the keys of the third tower; and The pointer is updated to store the third similarity information instead of the first similarity information, and access to the third tower is allowed via the pointer.

10. The method according to claim 1, further comprising: The computer system updates the skip table to remove the second tower, wherein the update includes: Generate third similarity information, the third similarity information indicating the amount of similarity between the keys of the first tower and the keys of the third tower, wherein the third tower includes entries located at the specific depth; and The pointer is updated to store the third similarity information instead of the first similarity information, and access to the third tower is allowed via the pointer.

11. A computer-readable medium having program instructions stored thereon, the program instructions being capable of causing a computer system to perform operations, the operations including: Maintain a skip list that allows access to groups of records in key-sorted order, wherein the skip list comprises groups of towers with different depths and entries storing pointers to other towers, wherein a first tower comprises entries located at a specific depth, the entries storing pointers for accessing entries located at the specific depth in a second tower, wherein the pointers include first similarity information indicating the amount of similarity between the keys of the first tower and the keys of the second tower based on the keys of the records corresponding to the first tower; as well as Performing a traversal of the skip list to locate the record for the search key, wherein the traversal includes: Generate second similarity information, which indicates the amount of similarity between the key of the first tower and the search key; as well as Based on a comparison involving the first similarity information and the second similarity information, it is determined whether to use the pointer to advance the traversal to the second tower or descend along the first tower, wherein the determination is performed without accessing the second tower to obtain key information about the key of the second tower.

12. The computer-readable medium of claim 11, wherein the first similarity information comprises: An index value that identifies the last character of a first subsequence of the character sequence of the key in the first tower, the first subsequence matching a second subsequence of the character sequence of the key in the second tower; and The value corresponds to the difference character that appears sequentially after the second subsequence in the character sequence of the key of the second tower.

13. The computer-readable medium of claim 12, wherein the operation further comprises: In response to a comparison of the index value with the index value of the second similarity information indicating that the first letter distance between the key of the first tower and the key of the second tower is greater than the second letter distance between the key of the first tower and the search key, the traversal proceeds down the first tower to advance the traversal, instead of using the pointer to access the second tower.

14. The computer-readable medium of claim 12, wherein the operation further comprises: In response to a comparison of the index value with the index value of the second similarity information indicating that the first letter distance between the key of the first tower and the key of the second tower is not greater than the second letter distance between the key of the first tower and the search key, the pointer is used to access the second tower to advance the traversal, instead of descending along the first tower.

15. The computer-readable medium of claim 11, wherein the group of records implements the skip list such that the first tower is stored as data in a first record of the group of records, and the second tower is stored as data in a second record of the group of records, wherein the second record is accessible via a hash bucket, and wherein accessing the entry of the second tower using the pointer includes accessing the hash bucket via the pointer and subsequently accessing the second record via the hash bucket.

16. A system comprising: At least one processor; A memory having stored program instructions executable by the at least one processor to cause the system to perform operations, including: Maintain a skip list that allows access to groups of records in key-sorted order, wherein the skip list comprises groups of towers with different depths and entries storing pointers to other towers, wherein a first tower includes entries located at a specific depth, the entries storing pointers to entries in a second tower located at the same specific depth, wherein the pointers include first similarity information indicating the amount of similarity between the keys of the records corresponding to the first tower and the keys of the second tower; and Performing a traversal of the skip list to locate the record for the search key, wherein the traversal includes: Generate second similarity information, the second similarity information indicating the amount of similarity between the key of the first tower and the search key; and Based on a comparison involving the first similarity information and the second similarity information, it is determined whether to use the pointer to advance the traversal to the second tower or descend along the first tower, wherein the determination is performed without accessing the second tower to obtain key information about the key of the second tower.

17. The system of claim 16, wherein the amount of similarity indicated by the first similarity information corresponds to a first letter distance between the key of the first tower and the key of the second tower.

18. The system of claim 17, wherein the operation further comprises: In response to the comparison indicating that the first letter distance is greater than the second letter distance between the key and the search key in the first tower, the traversal proceeds down the first tower to advance the traversal, instead of using the pointer to access the second tower.

19. The system of claim 17, wherein the operation further comprises: In response to the comparison indicating that the first letter distance is not greater than the second letter distance between the key of the first tower and the search key, the pointer is used to access the second tower to advance the traversal, instead of descending along the first tower.

20. The system of claim 16, wherein the group of records implements the skip list such that the first tower is stored as data in a first record of the group of records, and the second tower is stored as data in a second record of the group of records, wherein the first record is accessible via a first hash bucket, and the second record is accessible via a second hash bucket, and wherein the determination is performed using a latch acquired on the first hash bucket rather than the second hash bucket.

Images