Trie Data Structure with Subtrie Data Structures

Abstract

Techniques are disclosed for a tree data structure capable of storing information indicative of a database key. A computer system is capable of operating the database. The computer system can store a multi-level tree data structure usable to perform key lookups on the database. In various cases, the multi-level tree data structure can be stored in system memory as multiple subtree data structures, each including a set of linked nodes. A given one of the multiple subtree data structures can be stored in system memory as a respective contiguous block of information. The computer system can access the respective contiguous blocks for a first specific subtree data structure that encompasses a particular range of levels in the multi-level tree data structure. This access can be performed without accessing one or more other subtree data structures that encompass one or more levels within the particular range of levels.

Description

[Technical field]

[0001] The present disclosure relates generally to database systems, and more particularly to tree data structures capable of storing information indicative of database keys. [Background technology]

[0002] Modern database systems routinely implement management systems that can store collections of information in an organized manner that users can efficiently access and manipulate. In some cases, these management systems maintain a log-structured merge tree (LSM tree) with multiple levels that each store information as key-value pairs in database records. LSM trees typically contain two high-level components: an in-memory buffer and persistent storage. In operation, the database system first writes the database records to an in-memory buffer before later flushing the database records to persistent storage. As part of flushing the database records, the database system writes the database records to a new file that is stored in persistent storage. [Brief description of the drawings]

[0003] [Figure 1] FIG. 1 is a block diagram illustrating example elements of a system that can use a set of trie data structures, according to some embodiments. [Diagram 2] FIG. 2 is a block diagram illustrating elements of an example trie data structure having a set of subtrie data structures, in accordance with some embodiments. [Diagram 3] FIG. 2 is a block diagram illustrating example elements of pointer information for a node of a trie data structure, in accordance with some embodiments. [Figure 4] FIG. 2 is a block diagram illustrating example elements for creating and updating a trie by a database application, according to some embodiments. [Diagram 5]FIG. 1 is a flow diagram illustrating an example methodology relating to the use of a trie data structure in accordance with some embodiments. [Figure 6] FIG. 1 is a flow diagram illustrating an example methodology relating to the use of a trie data structure in accordance with some embodiments. [Figure 7] FIG. 1 is a block diagram illustrating an exemplary computer system according to some embodiments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0004] This disclosure includes references to "one embodiment" or "an embodiment." The appearances of the phrases "in one embodiment" or "in an embodiment" do not necessarily refer to the same embodiment. Particular features, structures, or characteristics may be combined in any suitable manner not inconsistent with this disclosure.

[0005] In this disclosure, various 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 - [entity] configured to [perform one or more tasks] - is used herein to refer to a structure (i.e., something physical, such as an electronic circuit). More specifically, this formulation is used to indicate that this structure is arranged to perform one or more tasks during operation. A structure may be said to be "configured to" perform some task even if the structure is not currently operated. A "network interface configured to communicate over a network" is intended to cover, for example, an integrated circuit having circuitry that performs this function during operation, even if the integrated circuit in question is not currently in use (e.g., no power supply is connected to it). Thus, an entity described or described as being "configured to" perform some task refers to something physical, such as a device, a circuit, a memory that stores executable program instructions to perform a task. This phrase is not used herein to refer to something intangible. Thus, the construct "configured to" is not used herein to refer to software entities such as application programming interfaces (APIs).

[0006] The term "configured to" does not mean "configurable to." For example, an unprogrammed FPGA is not considered to be "configured to" perform any particular function, although it may be "configurable to" perform that function and may be "configured to" perform the function after programming.

[0007] As used herein, the terms "first," "second," etc. are used as labels for the nouns they precede and do not imply any type of ordering (e.g., spatial, temporal, logical, etc.) unless otherwise specified. For example, in a processor having eight processing cores, the terms "first" and "second" processing core may be used to refer to any two of the eight processing cores. In other words, the first and second processing cores are not limited to, for example, processing cores 0 and 1.

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

[0009] As used herein, a "module" refers to software and / or hardware operable to perform a specified set of operations. A module may refer to a set of software instructions executable by a computer system to perform a set of operations. A module may also refer to hardware configured to perform a set of operations. Hardware modules may comprise general-purpose hardware, non-transitory computer-readable media that store program instructions, or specialized hardware such as customized ASICs. Thus, a module described as being "executable" to perform an operation refers to a software module, while a module described as being "configured" to perform an operation refers to a hardware module. A module described as being "operable" to perform an operation refers to both software and hardware modules.

[0010] During operation of a database built around an LSM tree, the database system typically flushes database records from an in-memory buffer to a file stored in persistent storage. A file often contains multiple database records corresponding to a variety of different database key values. In operation, the database system processes transaction requests that may involve accessing database records from files in persistent storage for database keys specified in the transaction requests. As part of processing transaction requests, in some cases the database system performs a single-database-record lookup, in which the database system retrieves files from persistent storage and checks them for a database record that corresponds to a particular database key identified in the transaction request. However, in many cases, the files retrieved by the database system do not contain a database record that corresponds to this particular database key. As a result, the database system wastes time and resources fetching these files from persistent storage.

[0011] In some cases, probabilistic data structures such as Bloom filters can be used to reduce the number of files fetched from persistent storage because they often provide an indication that for a database key, a corresponding database record is likely to exist in the file or is definitely not present in the file. Thus, the database system can fetch only files for which a corresponding database record is likely to exist and skip files for which a corresponding database record does not exist. However, in some cases, as part of processing a transaction request, the database system performs a key range lookup, in which the database system searches for database records whose database keys fall within a specified key range. To reduce the number of files fetched from persistent storage, a particular type of probabilistic data structure called a "trie" (alternatively, a "trie data structure") can be used in the key range lookup. Furthermore, a trie can be used to determine whether a particular database node contains in its in-memory buffer a database record whose database key falls within a specified key range. As used herein, the term "trie" is used in line with its established meaning and refers to a set of linked nodes that correspond to character values. branch It refers to a tree-like data structure in which a trie is created. branch Is that branch can represent a database key where each node in the can represent an individual character in the database key.

[0012] Although tries offer advantages over other probabilistic data structures, such as Bloom filters, for key range lookups, there are drawbacks to current implementations of tries. One drawback is related to the way tries are stored in system memory and then fetched from system memory into the system cache. These implementations currently branchThis results in a relatively large number of memory fetches when traversing the trie. In particular, current implementations store the trie in system memory such that every node at a given level precedes in memory every node at the next level in the trie. As a result, branch Traversing downward from one level to the next as part of a traversal may involve moving a reasonable memory distance in the system memory. Consider an example where a computer system traverses from the 27th level to the 28th level of a particular trie. Due to the fact that the 27th level may contain a large number of nodes and due to limited cache size, when the computer system issues a memory request to fetch data of the 27th level from the system memory to the cache, the data returned from the system memory is highly unlikely to include data of the nodes of the 28th level. That is, the chunk of sequential data fetched from the system memory for storage in the system cache may only include data representing a portion of the nodes of the 27th level, and may not include data representing the nodes of the 28th level. As a result, when traversing downward from the 27th level to the 28th level of a trie, the computer system needs to issue another memory request to fetch data of the 28th level. The above method of storing a trie in the system memory allows the system to easily store the trie in the memory of the trie that is being descended. branch This results in one memory request having to be issued for each node in the branch Descending (which is often multiple levels of a data structure) involves numerous memory requests which, together, can take an inordinate amount of time to process.

[0013] This disclosure describes techniques for implementing a trie data structure that overcomes some or all of the shortcomings of other trie approaches. In various embodiments described below, a computer system maintains a trie data structure that includes a set of subtrie data structures, each subtrie data structure having a set of linked nodes. In various cases, a first subtrie data structure is a particular subtrie data structure of the trie data structure. branch The first subtrie data structure may be connected to the second subtrie data structure as part of a set of nodes. In various embodiments, the first subtrie data structure is stored in the system memory as a contiguous block of information including node information detailing the nodes of the first subtrie data structure and pointer information identifying a location in the system memory where the information of the second subtrie data structure is stored. The computer system may load the second subtrie data structure into a system cache of the computer system using the pointer information included in the first subtrie data structure. In various cases, the second subtrie data structure and the other subtrie data structure may encompass nodes within the same particular range of levels in the trie data structure. In various embodiments, the computer system loads the second subtrie data structure without accessing one or more other subtrie data structures that encompass nodes within one or more of the same particular range of levels as the second subtrie data structure.

[0014] The computer system is branch Consider the previous example, where we traverse down the 27th and 28th levels of branch ) and a specific subtrie data structure from level 27 to level 34. branchThe second subtrie data structure may include a second subtrie data structure that includes nodes from the 27th level through the 34th level. The second subtrie data structure may be stored entirely in the system cache, while including nodes from the 27th level through the 34th level, because the second subtrie data structure does not need to include all of the nodes at those levels. As a result, when the computer system fetches the second subtrie data structure into the system cache using the pointer information included in the first subtrie data structure, the computer system can retrieve a particular branch Therefore, these techniques can traverse the 27th to 34th levels of the trie data structure. branch This may be advantageous over previous approaches because it allows a computer system to issue fewer memory requests when traversing the trie. That is, previous approaches may be advantageous because many of the nodes at a particular level are not part of a particular trie. branch It would be wasteful of cache space to fetch most or all of those nodes when they are not relevant to the traversal of the .One exemplary application of these techniques is now discussed, first with reference to FIG.

[0015] Referring now to FIG. 1, a block diagram of a system 100 is shown. System 100 includes a set of components that may be implemented by hardware or a combination of hardware and software routines. In an exemplary embodiment, system 100 includes a database 110 and a database node 130 that includes a compute complex 140 and a system memory 150. As further shown, database 110 includes a file 115 and a trie 120, and compute complex 140 executes a set of program instructions to implement a database application 146 and includes a system cache 144. In some embodiments, system 100 is implemented differently than shown. For example, system 100 may include multiple database nodes 130 that interact with each other and with database 110.

[0016] System 100, in various embodiments, provides a platform service (e.g., a customer relationship management (CRM) platform service) that allows users of the service to develop, execute, and manage applications. System 100 may be a multi-tenant system that provides various functions to multiple users / tenants hosted by the multi-tenant system. Thus, system 100 may execute software routines from various different users (e.g., providers and tenants of system 100) as well as provide code, web pages, and other data to users, databases, and other entities associated with system 100. As shown, for example, system 100 includes database node 130 that can store and access data from files 115 of database 110 for users associated with system 100.

[0017] Database 110, in various embodiments, is a collection of information that is organized in a manner that allows that information to be accessed, stored, and manipulated. Thus, database 110 may include supporting software that allows database nodes 130 to perform operations (e.g., access, store, etc.) on the information stored in database 110. In some embodiments, database 110 is implemented with a single or multiple storage devices connected together on a network (e.g., a storage attached network (SAN)) and configured to store information redundantly to prevent data loss. The storage devices may store data persistently, and thus database 110 may function as persistent storage. In various embodiments, database 110 is shared among multiple database nodes 130 such that database records written to file 115 by one database node 130 are accessible by other database nodes 130.

[0018] In various embodiments, database 110 implements a portion of a log-structured merge-tree (LSM tree) having multiple levels of files 115 containing database records. The LSM tree can include two high-level portions: an in-memory portion and an on-disk portion. One or more "top" levels of the LSM tree can include database records that are written to an in-memory buffer of database node 130. The remaining levels of the LSM tree can include files 115 that contain database records that are written to database 110. In various cases, system memory 150 and system cache 144 can facilitate the in-memory portion of the LSM tree, while database 110 facilitates the on-disk portion of the LSM tree.

[0019] File 115, in various embodiments, is a set of database records. A database record may be a key-value pair that includes data and a corresponding database key that can be used to look up the database record. For example, a database record may correspond to a row of data in a database table, where the database record specifies values ​​for one or more attributes associated with the database table. In various embodiments, file 115 is associated with one or more database key ranges that are defined by the keys of the database records contained in file 115. Consider an example in which file 115 stores three database records that are associated with keys "AA", "AB", and "AC", respectively. These three keys span the database key range AA→AC, and therefore file 115 may be associated with the database key range AA→AC. As discussed herein, trie 120 may be used by database node 130 to determine whether file 115 has database records associated with database keys that fall within a specified database key range.

[0020] In various embodiments, the trie 120 is a trie data structure that includes a set of subtrie data structures, each of which includes a set of linked nodes. FIG. 2 illustrates an example of a trie 120. The trie 120 may be a probabilistic data structure that can provide an indication of a database key range associated with one or more files 115. As used herein, the term "probabilistic data structure" refers to a data structure that maintains information that indicates that a particular item is either not present or likely to be present at a particular location in the system. As an example, a probabilistic data structure may store information that indicates that a database record is either not present or likely to be present in a file. In various embodiments, the trie 120 has a reasonably smaller memory footprint than the corresponding file 115. As a result, the database node 130 may access the trie 120 more quickly and efficiently than it accesses the corresponding file 115. As a result, using the trie 120 to check whether a particular database record is likely to be included in the given file 115, instead of directly accessing the given file 115 to check the database record, may provide a substantial performance increase to the system 100.

[0021] When a database record is written to a file 115, in various embodiments, a database node 130 generates a trie 120 for that file 115. The trie 120 may form a tree-like data structure, branch corresponds to the database key of the database record that is written to the corresponding file 115. Thus, branch may contain nodes that represent the character values ​​of the corresponding database keys. When a database node 130 wishes to determine whether a file 115 may contain a particular database record, in various embodiments, the database node 130 may search for nodes whose characters match the character values ​​of the database keys of that database record. branchA database node 130 may perform a single key lookup for a set of nodes, which includes searching the corresponding trie 120 for the set of nodes that fall within a specified key range. branch For each of the above, a key range lookup may be performed, which includes searching the corresponding trie 120. branch can be found in the trie 120, the database node 130 can determine that at least one database record is likely to exist in the corresponding file 115 that falls within the specified key range.

[0022] In various embodiments, the system 100 is implemented with multiple database nodes 130 that first write database records to their own in-memory buffers before flushing the database records to the database 110. During operation, a database node 130 may wish to access the latest version of a data row as part of processing a database transaction. However, that latest version may be stored in the in-memory buffer of another database node 130. As a result, the former database node 130 may issue a database record request to the latter database node 130 to determine whether the latest version is stored in the latter database node 130. Often, it is not stored in the latter database node 130, and resources are wasted. Thus, in various embodiments, a try 120 may be further used to determine whether the database record may be present in the in-memory buffer of another database node 130 and therefore whether a database record request should be issued.

[0023] Database node 130 is hardware, software, or a combination thereof that can provide database services such as data storage, data retrieval, and / or data manipulation, in various embodiments. Such database services may be provided to other components within system 100 and / or to components external to system 100. As an example, database node 130 may receive a database transaction request from an application server (not shown) requesting that data be written to or read from database 110. The database transaction request may specify an SQL SELECT command to select one or more rows from one or more database tables. The contents of the rows may be defined in database records, and thus database node 130 may locate and return one or more database records that correspond to the selected table row or rows. In some cases, the database transaction request may instruct database node 130 to write one or more database records to an LSM tree. Database node 130, in various embodiments, first writes the database records to system cache 144 and system memory 150 before flushing them to database 110.

[0024] Computation complex 140 is a collection of processors, processor cores, and / or caches 144 in various embodiments. As an example, computation complex 140 may include four processor cores with their own internal system caches 144. The processor cores of computation complex 140 may be configured to execute instructions of a particular instruction set architecture (ISA). This may include operating system instructions and user application instructions (e.g., instructions executable to implement database application 146). These instructions may be stored in a non-transitory computer-readable medium, such as a system memory 150 coupled to computation complex 140. System memory 150 may be volatile memory (e.g., dynamic random access memory) or non-volatile memory (e.g., NAND flash memory). Computation complex 140 may retrieve a set of program instructions from system memory 150 and execute the program instructions to perform functions described herein, such as database application 146.

[0025] The database application 146 is a set of program instructions that are executable to manage the database 110, including, in various embodiments, managing an LSM tree built around the database 110. Thus, the database application 146 can process database transactions to read records from and write records to the LSM tree. The database application 146 can maintain metadata that describes the structural layout of the LSM tree, including where the files 115 are stored in the database 110 and what records those files 115 may contain. In various embodiments, the metadata includes tries 120 that correspond to the files 115 stored in the database 110. The database application 146 can use the metadata to perform faster and more efficient key range lookups as part of processing database transactions, as discussed.

[0026] To facilitate processing of database transactions, in various embodiments, database node 130 uses tries 120. For example, as discussed, when database node 130 searches for database records that fall within a database key range, it may use tries 120 to identify files 115 and / or database nodes 130 that may contain such database records. Thus, database node 130 may first retrieve one or more of tries 120 from database 110 and then store them in system memory 150. In some embodiments, when database node 130 wants to check a particular file 115 and / or other database node 130, database node 130 retrieves the trie 120 that corresponds to that time and stores it in system memory 150. Once trie 120 is stored in system memory 150, database node 130 may begin performing a traversal of that trie 120.

[0027] When traversing trie 120, database node 130 issues memory fetches 148 to system memory 150 to load subtries 125 of trie 120, including the root node of the entire trie 120, into system cache 144. As previously mentioned, trie 120 includes a set of subtries 125. A subtrie 125, in various embodiments, is one or more subtries made up of linked nodes corresponding to character values. branch For example, a subtrie with 125 branch may correspond to part or all of a particular database key, and the remainder of that database key may correspond to other subtries 125 that are linked to the former subtrie 125. branchWhen stored in the system cache 144 and the system memory 150, the sub-trie 125 may be stored as one contiguous block of information / data (bytes) in the memory address space. However, the trie 120 may not be stored as one contiguous block of information in some cases, i.e., the individual sub-trie 125 may not be adjacent to each other in memory. However, in some cases, the trie 120 may be stored as one contiguous block of information in memory. In various embodiments, the memory size of the sub-trie 125 does not exceed the memory space of the system cache 144. Thus, the database node 130 may load the entire sub-trie 125 into the system cache 144. However, the trie 120 may be larger than the memory space of the system cache 144 and therefore may not be fully loaded into the system cache 144 by the database node 130. An example of a sub-trie 125 is discussed with respect to FIG. 2.

[0028] After the subtrie 125 is loaded into the system cache 144, the database node 130 then branch Start traversing the branch It can be determined whether a given subtrie in the first subtrie 125 corresponds to a database key that falls within a particular database key range. branch When traversing, in various cases, a database node 130 is linked to another node included in the second subtrie 125, branch The database node 130 may reach a node in the first subtrie 125. The database node 130 may load the second subtrie 125 into the system cache 144 using pointer information included in the first subtrie 125 that identifies the memory location where the second subtrie 125 is stored in the system memory 150. The database node 130 may then load the second subtrie 125 into the system cache 144 via the second subtrie 125 stored in the system cache 144. branchThus, a database node 130 may extend across multiple subtries 125. branch When a database node 130 accesses a subtrie 125 that spans a range of levels, in various embodiments the database node 130 accesses a subset of all nodes within those levels, with other nodes contained in other subtries 125 that span the range of levels. branch By not having to access all the nodes in a level as part of traversing the branch Using the memory space that would be occupied by nodes not related to that particular branch , further nodes at lower levels of the trie 120 that are relevant to the traversal of .

[0029] 2, a block diagram of exemplary elements of trie 120 and its layout within system memory 150 is shown. In the illustrated embodiment, trie 120 includes sub-tries 125A-D, each having a set of nodes 210. As shown, sub-trie 125A includes nodes 210A, 210B, 210E, 210F, and 210K; sub-trie 125B includes nodes 210C and 210G; sub-trie 125C includes nodes 210D, 210H, 210I, 210J, and 210L; and sub-trie 125D includes node 210M. As further shown, information representing sub-trie 125A-125D is stored contiguously within system memory 150. In some embodiments, trie 120 and / or its layout within system memory 150 may be implemented differently than as shown. As an example, tries 120 may be stored non-contiguously in system memory 150 .

[0030] As previously discussed, in various embodiments, trie 120 is used to store database keys for database records written to file 115 corresponding to trie 120. As shown, trie 120 in the illustrative embodiment stores at least the keys "AM", "ART", "OX", "TA", "TIP", and "TOP". Each database key is stored in trie 120's branch For example, the key "TIP" may be stored in the trie 120 as a set of linked nodes 210 forming a set of nodes 215A-D of the trie 120. branch 3, the node 210 is a data structure that, in various embodiments, stores information about the character value that it represents and how the node 210 is linked to other nodes 210.

[0031] When performing a key range lookup (or a single key lookup), database node 130 may traverse levels 215 of trie 120 by issuing memory fetches 148 to load subtries 125 from system memory 150 into system cache 144. Consider an example in which database node 130 wants to determine whether file 115 corresponding to trie 120 may contain database records that fall within the key range "TCP" -> "TLC". In various embodiments, database node 130 first issues memory fetch 148 to system memory 150 to load subtrie 125 including node 210 that represents the root of trie 120. In the illustrated embodiment, node 210A stores the root character value, and therefore subtrie 125A is fetched into system cache 144. As shown, five nodes 210 are fetched, which may be because system cache 144 may have the capacity to store information for only five nodes 210 at a time.

[0032] Once subtrie 125A is loaded into system cache 144, database node 130 can determine that node 210A is linked to three nodes, namely, nodes 210B, 210C, and 210D. Database node 130 can further determine that nodes 210B and 210C represent character values ​​that are outside the key range "TCP" -> "TLC", while the character value "T" of node 210D falls within that range. Therefore, database node 130 can determine that node 210A is linked to three nodes, namely, nodes 210B, 210C, and 210D. branch , which is traversed by the database node 130. Because subtrie 125A does not include node 210D, the database node 130 can issue another memory fetch 148 to load subtrie 125C into the system cache. Because node 210A is linked to nodes 210 that are stored as part of other subtries 125, in various embodiments, node 210A includes pointers 220A and 220B that point to memory locations in system memory 150 where the other subtries 125 are stored. Thus, using pointer 220A, the database node 130 can load subtrie 125C into the system cache 144 without having to load the other subtries 125.

[0033] Once the subtrie 125C is loaded into the system cache 144, the database node 130: branch, and can determine that linked nodes 210D, 210I, and 210L form keys that fall within the key range "TCP" -> "TLC" and therefore that the corresponding file 115 may store database records that fall within that key range. In various cases, database node 130 may perform key lookups that descend multiple levels 215, but not all nodes 210 for those levels 215 that are descended are accessed. In the previous example, database node 130 did not fetch information for nodes 210C, 210G, and 215M into system cache 144. By not accessing all nodes 210 for the levels 215 that are descended in the key lookup, database node 130 can reduce the number of memory fetches 148 issued, saving time and resource consumption.

[0034] 3, a block diagram of exemplary elements of a node 210 included in a subtrie 125 within a trie 120 is shown. In an exemplary embodiment, subtrie 125A includes node 210A, and subtrie 125B includes node 210B. As shown, node 210A includes node information 310 and pointer information 320 that indicates the location of node 210B. As further shown, pointer information 320 includes pointer 220 and a memory size indicator 325. In some embodiments, node 210 is implemented differently than shown. As one example, pointer information 320 may not include memory size indicator 325.

[0035] The node information 310, in various embodiments, includes information indicating the character value represented by the corresponding node 210. The node information 310 may further indicate nodes 210 that are connected to the node 210 of the node information 310. For example, the node information 310 of node 210A may indicate that node 210A is linked to node 210C, and that node 210C follows node 210A in the order. As another example, the node information 310 of node 210A may indicate that node 210A descends from another particular node 210. In some embodiments, the node information 310 indicates at which level of the trie 120 the node 210 of the node information 310 resides. For example, the node information 310 may indicate that node 210A is at the second level down from the top of the trie 120.

[0036] The pointer information 320, in various embodiments, includes information that can be used to access one or more nodes 210 linked to the node 210 of the pointer information 320. In various cases, the pointer information 320 can include a pointer (e.g., a memory offset) to a node 210 that resides in the same subtrie 125 as the node 210 of the pointer information 320. For example, nodes 210A and 210B (not shown) may be directly linked and included in a particular subtrie 125. The pointer information 320 of node 210A can indicate a location within the data structure of a particular subtrie 125 where node 210B can be accessed. In various cases, the pointer information can include a pointer (e.g., a memory offset) to a node 210 that resides in a different subtrie 125 than the node 210 of the pointer information 320. As shown, pointer information 320 of node 210A includes a pointer 220 that identifies a location (e.g., a memory address within system memory 150) of node 210C; i.e., pointer 220 can identify a location within system memory 150 that contains a block of information / data (e.g., bytes that define node information 310 and pointer information 320) that describes the pointed-to node 210.

[0037] Therefore, from node 210A to node 210C branch When traversing node 210A, database node 130 can load subtrie 125B (including node 210C) from system memory 150 into system cache 144 using pointer information 320 of node 210A. In various embodiments, pointer information 320 includes a memory size indicator 325 indicating the size (e.g., 64KB) of subtrie 125 including the pointed to node 210. Thus, when attempting to direct subtrie 125B to system cache 144, database node 130 can determine how much data to request from system memory 150 to load subtrie 125B based on the size of subtrie 125B indicated by memory size indicator 325 of pointer information 320 of node 210A. As an example, memory size indicator 325 can specify the number of cache lines that subtrie 125 will consume when stored in system cache 144. Thus, database node 130 can fetch that number of cache lines corresponding to the data from system memory 150. By using the memory size indicator 325 , the database node 130 does not have to fetch more data from the system memory 150 than is required to load the subtrie 125 .

[0038] 4, a block diagram of a database application 146 writing files 115 and tries 120 to a database 110 is shown. As further shown, the database application 146 receives a set of transaction requests 410 having keys 415. The transaction requests 410 may specify a set of database records (along with their corresponding keys 415) to be written to the database 110 as files 115. Thus, the database application 146 may process the transaction request 410 to write one or more files 115 to the database 110. As part of processing the transaction request 410, the database application 146 may generate a corresponding trie 120 for one or more files 115 that includes the keys 415 of the database records contained in those one or more files 115. Additionally, in some cases, as part of processing the transaction request 410, the database application 146 may generate the set of tries 120 based on the keys of the database records stored in an in-memory buffer (which may be implemented using the system cache 144 and system memory 150) of the database node 130.

[0039] When generating the trie 120, the database application 146 may branch In various cases, keys 415 may share a common prefix, resulting in branch For example, as shown in FIG. 2, the keys "AM" and "ART" can share the common part of their respective branch2. As part of generating the trie 120, in various embodiments, the database application 146 determines the division of the nodes 210 of the trie 120 into sub-tries 125. The database application 146 may use various criteria for determining how to divide the nodes 210. One such criterion may include ensuring proximity to the ratio between the number of nodes 210 in the sub-trie 125 and the number of levels 215 in the sub-trie 125. For example, the database application 146 may be confident that for every four nodes, the sub-trie 125 descends at least one further level. Thus, if the sub-trie 125 contains nine nodes 210 in this example, the sub-trie 125 contains three levels 215. Another criterion may include ensuring proximity to the ratio between the number of nodes 210 in the trie 120 and the number of sub-tries 125. For example, if there are 50 nodes 210 in a trie 120, the database application 146 may divide these nodes 210 into five subtries 125, with 10 nodes 210 per subtrie 125. Another criterion is to determine the number of nodes 210 in a given trie 120. branch This may include ensuring that the average number of memory fetches 148 required to access the entire set is minimized. After determining the partitioning of nodes 210, in various embodiments, database application 146 structures each group of nodes 210 as a respective continuous block of data.

[0040] In some cases, the database application 146 may update the trie 120. For example, if a particular trie 120 is being used to determine whether, for a specified key 415, a record is stored in another database node 130, and the nature of which records are stored in this other database node 130 changes over time, the trie 120 may be updated to reflect the change. That is, if another database node 130 updates its in-memory buffer to include a new database record, the trie 120 used by the database application 146 may be updated to incorporate the key 415 of that database record. In various cases, when updating the trie 120, the database application 146 adds one or more nodes 210 to the trie 120. When adding one or more nodes 210, the database application 146 may modify a particular sub-trie 125 to encompass the added one or more nodes 210, thereby allowing the particular sub-trie 125 to span one or more additional levels 215. In some cases, the database application 146 may create a new subtrie 125 that includes the one or more added nodes 210. In some further cases, the database application 146 may split a particular subtrie 125 into multiple subtries 125, where one of the subtries 125 includes the one or more added nodes 210.

[0041] 5, a flow diagram of a method 500 is shown. Method 500 is one embodiment of a method performed by a computer system (e.g., database node 130) to facilitate processing of a transaction request (e.g., transaction request 410). Method 500 may be performed by executing one or more program instructions stored on a non-transitory computer-readable medium. In some embodiments, method 500 may include more or fewer steps than illustrated, for example, method 500 may include a step of a computer system receiving a transaction request.

[0042] Method 500 begins at step 510 with a computer system manipulating a database (e.g., database 110). In various embodiments, manipulating the database includes the computer system receiving a transaction request to perform a transaction including writing a file (e.g., file 115) to the database, the file including a set of records associated with a set of keys (e.g., set of keys 415). The computer system can perform the transaction, which can include generating a multi-level tree data structure (e.g., trie 120) such that nodes (e.g., nodes 210) included in the multi-level tree data structure correspond to characters in the set of keys. The multi-level tree data structure can be associated with the file.

[0043] In step 520, the computer system stores the multi-level tree data structure that is usable to perform a key lookup against the database. In various cases, the multi-level tree data structure can be stored in a system memory (e.g., system memory 150) as a plurality of subtree data structures (e.g., subtries 125) each including a set of linked nodes. A given one of the plurality of subtree data structures can be stored in the system memory as a respective contiguous block of information. The memory size of the respective contiguous blocks for a given subtree data structure may not exceed the memory size of a system cache (e.g., system cache 144) coupled to the system memory. The multi-level tree data structure can be stored in the system memory as a contiguous block of information.

[0044] In step 530, the computer system accesses each successive block for a first particular subtree data structure (e.g., subtrie 125A) that encompasses a particular range of levels (e.g., levels 215A-D) in the multi-level tree data structure. In various cases, this access can be performed without accessing one or more other subtree data structures (e.g., subtrie 125B and 125C) that encompass one or more levels in the particular range of levels. The computer system can update the multi-level tree data structure to include one or more nodes. As part of updating the structure, the computer system can modify a particular one of the subtree data structures such that the particular range of levels encompassed by the particular subtree data structure is changed (e.g., the subtree data structure is expanded to encompass the newly added nodes at a different level). In some cases, the update may include splitting one of the subtree data structures into two or more subtree data structures.

[0045] In some cases, the set of linked nodes of the first particular subtree data structure may correspond to a character of a key inserted into the multi-level tree data structure. The particular key may correspond to at least one node in the first particular subtree data structure and at least one node in the second particular subtree data structure. Each successive block for the first particular subtree data structure may include pointer information (e.g., pointer information 320) that identifies a location in the system memory where each successive block for the second particular subtree data structure is stored. As such, the computer system may fetch each successive block for the second particular subtree data structure from the system memory into a system cache using the pointer information included in each successive block for the first particular subtree data structure. The pointer information may identify a memory size of each successive block for the second particular subtree data structure. The memory size may indicate a number of cache lines that each successive block for the second particular subtree data structure consumes when stored in a system cache coupled to the system memory.

[0046] 6, a flow diagram of a method 600 is shown. Method 600 is one embodiment of a method performed by a computer system (e.g., database node 130) to facilitate processing of a transaction request (e.g., transaction request 410). Method 600 may be performed by executing one or more program instructions stored on a non-transitory computer-readable medium. In some embodiments, method 600 may include more or fewer steps than illustrated, for example, method 600 may include a step of a computer system receiving a transaction request.

[0047] The method 600 begins in step 610 with a computer system storing a tree data structure (e.g., trie 120) that includes a number of subtree data structures (e.g., subtries 125) in a system memory (e.g., system memory 150). branch A first subtree data structure (e.g., subtrie 125A) that is connected to a second subtree data structure (e.g., subtrie 125C) as part of a tree data structure may include pointer information (e.g., pointer information 320) that identifies a location in system memory where the second subtree data structure is stored. The pointer information may identify a memory size (e.g., memory size indicator 325) of the second subtree data structure. In various embodiments, the memory size of the tree data structure does not allow the tree data structure to be fully loaded into the system cache, while the memory size of a given one of the multiple subtree data structures allows the given subtree data structure to be fully loaded into the system cache. In some cases, the tree data structure may not be stored as one contiguous block of information in system memory.

[0048] In step 620, the computer system uses the tree data structure to branch , which may include loading the second subtree data structure into a system cache (e.g., system cache 144) using pointer information included in the first subtree data structure. In some embodiments, loading the second subtree data structure into the system cache is based on memory size (e.g., the computer system may issue memory requests only for data from the system memory that contains the second subtree data structure). The pointer information may further identify a location in the system memory where a third subtree data structure (e.g., subtrie 125B) is stored. The first subtree data structure may be a pointer to another particular subtree of the tree data structure. branchIn some embodiments, the computer system updates the tree data structure to include the set of nodes, which may result in the tree data structure including one or more additional subtree data structures.

[0049] Exemplary Computer System 7, a block diagram of an exemplary computer system 700 on which system 100, database 110, and / or database node 130 may be implemented is shown. Computer system 700 includes a processor subsystem 780 coupled to a system memory 720 and an I / O interface 740 via an interconnect 760 (e.g., a system bus). The I / O interface 740 is coupled to one or more I / O devices 750. Computer system 700 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 mobile phone, a music player, or a consumer device such as a personal data assistant (PDA). For simplicity, a single computer system 700 is shown in FIG. 7, however system 700 may be realized as two or more computer systems operating together.

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

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

[0052] I / O interface 740 may be any of a variety of types of interfaces configured to couple and communicate with other devices according to various embodiments. In one embodiment, I / O interface 740 is a bridge chip (e.g., a southbridge) from a frontside to one or more backside buses. I / O interface 740 may be coupled 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 drives, optical drives, removable flash drives, storage arrays, SANs, or their associated controllers), network interface devices (e.g., for a local or wide area network), or other devices (e.g., graphics, user interface devices, etc.). In one embodiment, computer system 700 is coupled to a network via network interface device 750 (e.g., configured to communicate via WiFi, Bluetooth, Ethernet, etc.).

[0053] Implementations of the subject matter of this application include, but are not limited to, the following Examples 1-20. 1. operating a database by a computer system; storing, by the computer system, a multi-level tree data structure usable to perform key lookups against the database, the multi-level tree data structure being stored in system memory as a plurality of subtree data structures each including a set of linked nodes, a given one of the plurality of subtree data structures being stored in system memory as a respective continuous block of information; accessing, by the computer system, the respective contiguous blocks for a first particular subtree data structure that encompasses a particular range of levels in the multi-level tree data structure, the accessing being performed without accessing one or more other subtree data structures that encompass one or more levels within the particular range of levels; The method includes: 2. The method of Example 1, wherein the set of linked nodes of the first specific subtree data structure corresponds to characters of a key inserted into the multilevel tree data structure, and a specific key corresponds to at least one node in the first specific subtree data structure and at least one node in a second specific subtree data structure. 3. The method of example 2, wherein each successive block for the first particular subtree data structure includes pointer information that identifies a location in the system memory where each successive block for the second particular subtree data structure is stored. 4. The accessing is: 4. The method of claim 3, further comprising fetching the respective contiguous blocks for the second particular subtree data structure from the system memory into a system cache using the pointer information contained in the respective contiguous blocks for the first particular subtree data structure. 5. The method of example 3, wherein the pointer information identifies a memory size of the respective contiguous blocks for the second particular subtree data structure. 6. The method of example 5, wherein the memory size indicates a number of cache lines that each of the contiguous blocks for the second particular subtree data structure consumes when stored in a system cache coupled to the system memory. 7. The method of example 1, wherein the memory size of each contiguous block for the given subtree data structure does not exceed the memory size of a system cache coupled to the system memory. 8. updating, by the computer system, the multi-level tree data structure to include one or more nodes, said updating including modifying a particular one of the plurality of subtree data structures such that a particular range of levels encompassed by the particular subtree data structure is changed. The method of Example 1 further comprising: 9. Operating said database comprises: receiving a request to perform a transaction including writing a file to the database, the file including a set of records associated with a set of keys; executing the transaction, the transaction including generating a multi-level tree data structure such that nodes included in the multi-level tree data structure correspond to characters of the set of keys, the multi-level tree data structure being associated with the file; The method of Example 1, comprising: 10. The method of example 1, wherein the multi-level tree data structure is stored in the system memory as a contiguous block of information. 11. A computer-readable medium having stored thereon program instructions for causing a computer system to perform operations, said operations comprising: storing a multi-level tree data structure usable to perform key lookups against a database, said multi-level tree data structure being stored in a system memory as a plurality of sub-tree data structures each including a set of linked nodes, a given one of said plurality of sub-tree data structures being stored in the system memory as a respective contiguous block of information; accessing the respective contiguous blocks for a first particular subtree data structure that encompasses a particular range of levels in the multi-level tree data structure, said accessing being performed without accessing one or more other subtree data structures that encompass one or more levels within the particular range of levels; Including, media. 12. The medium of Example 11, wherein the respective contiguous blocks of the first particular subtree data structure are accessed using pointer information contained in the respective contiguous blocks of the second particular subtree data structure. 13. The operation is and updating the multi-level tree data structure to include a set of nodes, the updating including expanding the set of linked nodes of one of the plurality of subtree data structures to include one or more of the sets of nodes. 14. The operation is The medium of Example 11, further comprising: updating the multi-level tree data structure to include a set of nodes, the updating comprising splitting one of the plurality of subtree data structures into two or more subtree data structures. 15. Storing, by the computer system, in a system memory, a tree data structure including a plurality of subtree data structures, branch a first subtree data structure connected to a second subtree data structure as part of the first subtree data structure including pointer information identifying a location in the system memory where the second subtree data structure is stored; The computer system uses the tree data structure to branch performing a key range lookup including traversing a first subtree data structure, said performing including loading the second subtree data structure into a system cache using the pointer information contained in the first subtree data structure; The method includes: 16. The pointer information further identifies a location in the system memory where a third subtree data structure is stored, the first subtree data structure being a pointer to another particular part of the tree data structure. branch16. The method of example 15, wherein the third subtree data structure is connected as part of the 17. The method of example 15, wherein the pointer information identifies a memory size of the second subtree data structure, and wherein loading the second subtree data structure into the system cache is based on the memory size. 18. The method of example 15, wherein a memory size of the tree data structure does not allow the tree data structure to be fully loaded into the system cache, and a memory size of a given one of the plurality of subtree data structures allows the given subtree data structure to be fully loaded into the system cache. 19. Updating the tree data structure to include a set of nodes, said updating resulting in the tree data structure including one or more further subtree data structures. The method of Example 15, further comprising: 20. The method of example 15, wherein the tree data structure is not stored in the system memory as one contiguous block of information.

[0054] 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 that will be apparent to those skilled in the art having the benefit of this disclosure.

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

Claims

1. storing, by a computer system, the set of records as a file; storing, by the computer system, a multi-level tree data structure usable to determine whether a record for a database key may be stored in the file, the multi-level tree data structure being stored in a system memory of the computer system as a plurality of subtree data structures, a memory size of the multi-level tree data structure not allowing the entire multi-level tree data structure to be loaded into a system cache of the computer system, a memory size of a given subtree data structure allowing the entire given subtree data structure to be loaded into the system cache, and linked nodes of the given subtree data structure corresponding to character values ​​of a database key inserted into the multi-level tree data structure; as part of a key lookup for a database key, the computer system fetches from the system memory in the system cache a first subtree data structure encompassing a particular range of levels in the multi-level tree data structure, the fetching being performed without accessing one or more other subtree data structures encompassing one or more levels within the particular range of levels, the first subtree data structure including pointer information that enables the computer system to fetch an entire second subtree data structure, the pointer information indicating a memory size of the second subtree data structure, and the pointer information further indicating a location in the system memory where contiguous blocks for the second subtree data structure are stored; fetching, by the computer system, the second subtree data structure in the system cache using the pointer information. The method includes:

2. 2. The method of claim 1, wherein a first character of the particular database key corresponds to a node in the first subtree data structure and a second character of the particular database key corresponds to a node in the second subtree data structure.

3. The method of claim 1 , wherein the memory size indicates a number of cache lines that the second subtree data structure consumes when stored in the system cache.

4. updating, by the computer system, the multi-level tree data structure to include one or more nodes, the updating including modifying a particular one of the plurality of subtree data structures such that a particular range of levels encompassed by the particular subtree data structure is changed. The method of any one of claims 1 to 3, further comprising:

5. Working with the database is receiving a request to perform a transaction including writing the set of records, the file, to a database; executing the transaction, including generating the multi-level tree data structure, the multi-level tree data structure being associated with the file; The method of any one of claims 1 to 4, comprising:

6. The method of claim 1 , wherein the multi-level tree data structure is stored in the system memory as a contiguous block of information.

7. A computer readable medium having stored thereon program instructions for causing a computer system to perform operations, the operations including: storing the set of records as a file; storing a multi-level tree data structure usable to determine whether a record for a database key may be stored in the file, the multi-level tree data structure being stored in a system memory of the computer system as a plurality of subtree data structures, a memory size of the multi-level tree data structure not allowing the entire multi-level tree data structure to be loaded into a system cache of the computer system, a memory size of a given subtree data structure allowing the entire given subtree data structure to be loaded into the system cache, and linked nodes of the given subtree data structure corresponding to character values ​​of a database key inserted into the multi-level tree data structure; fetching, as part of a key lookup for a database key, from the system memory in the system cache, a first subtree data structure encompassing a particular range of levels in the multi-level tree data structure, said fetching being performed without accessing one or more other subtree data structures encompassing one or more levels within the particular range of levels, said first subtree data structure including pointer information that enables said computer system to fetch an entire second subtree data structure, said pointer information indicating a memory size of said second subtree data structure, said pointer information further indicating a location in said system memory where contiguous blocks of said second subtree data structure are stored; fetching, by the computer system, the second subtree data structure in the system cache using the pointer information. Including, media.

8. The operation includes:

8. The medium of claim 7, further comprising: updating the multi-level tree data structure to include a set of nodes, the updating comprising expanding the set of linked nodes of one of the plurality of subtree data structures to include one or more of the sets of nodes.

9. The operation includes:

8. The medium of claim 7, further comprising: updating the multi-level tree data structure to include a set of nodes, the updating comprising splitting one of the plurality of subtree data structures into two or more subtree data structures.

10. At least one processor; A memory storing program instructions executable by said at least one processor to perform the method of any one of claims 1 to 6; 1. A computer system comprising:

Images