Local compression of tree-based index structures

Abstract

A system includes: storing data into a target memory location allocated to a target leaf node of a tree-based index structure, the target leaf node being a child of a parent node of the tree-based index structure, wherein the tree-based index structure includes one or more other leaf nodes as children of the parent node, and each of the target leaf node and the one or more other leaf nodes is associated with a plurality of allocated memory locations; incrementally identifying all unused allocated memory locations between a first allocated memory location of a left-most one of the target leaf node and the one or more other leaf nodes and a last used allocated memory location of a right-most one of the target leaf node and the one or more other leaf nodes; and moving data stored in the target leaf node and the one or more other leaf nodes into the identified unused allocated memory locations.

Description

Background Technology

[0001] Conventional database systems manage large amounts of data in the form of database tables. These systems need to store, retrieve, and update this managed data. Designing a system that meets each of these requirements involves numerous performance and cost trade-offs.

[0002] For example, data can be stored in a highly compressed format to reduce the amount of memory required by the system. However, this compression hinders the system's ability to quickly update data in response to received DML (Data Manipulation Language) statements. On the other hand, system update performance can be improved by using a tree-based index structure, but the strong compression of a tree-based index structure diminishes the performance advantages it offers. Therefore, tree-based index structures typically consume significantly more space than a highly compressed version of the same data.

[0003] In some cases, less memory consumption can achieve faster performance. Specifically, processing performance improves when data is stored "closer" to the central processing unit (CPU). Data stored in the L1 cache can be processed 10 times faster than data stored in the L2 cache, and 100 times faster than data stored in main memory (e.g., dynamic random access memory (DRAM)). The size of the L1 cache is typically much smaller than that of the L2 cache, which in turn is much smaller than the main memory. Therefore, it is desirable to reduce the size of the stored data in order to increase the proportion of data that can be stored in higher-performance memory regions.

[0004] In cloud-based environments, cost and performance considerations are particularly important. To maximize the utilization of available hardware, cloud-based deployments can run multiple database system instances within corresponding virtual machines on a single computer server. Each database system instance shares the volatile memory and processing power of the single computer server. Furthermore, shared volatile memory is more expensive than on-premises deployments.

[0005] In contrast to conventional systems, some existing systems operate to occasionally rewrite the tree-based index structure without including unused memory areas that would normally reside within the tree-based index structure. These systems save memory but reduce insertion performance because new memory areas must be allocated to receive the inserted data. Furthermore, during the rewrite, access to the entire tree-based index structure (and therefore all the data it represents) is blocked.

[0006] Therefore, it is desirable for the system to reduce the amount of memory used by tree-based index structures while providing satisfactory update performance. Attached Figure Description

[0007] Figure 1This is a block diagram of a database architecture based on some embodiments.

[0008] Figure 2 This is a block diagram of a cloud-based database architecture based on some embodiments.

[0009] Figure 3 It is a tabular representation of multiple <key, value> pairs according to some embodiments.

[0010] Figure 4 It is a graphical representation of a tree-based index structure according to some embodiments.

[0011] Figure 5 It is a graphical representation of a tree-based index structure according to some embodiments.

[0012] Figure 6 This includes a flowchart of a process for partially compressing a tree-based index structure according to some embodiments.

[0013] Figure 7 It is a graphical representation of inserting data into a tree-based index structure according to some embodiments.

[0014] Figure 8 It is a compressed graphical representation of sibling nodes based on a tree-based index structure, according to some embodiments.

[0015] Figure 9 It is a graphical representation of inserting data into a tree-based index structure according to some embodiments.

[0016] Figure 10 It is a compressed graphical representation of sibling nodes based on a tree-based index structure, according to some embodiments.

[0017] Figure 11 This is a block diagram of a cloud-based database architecture based on some embodiments. Detailed Implementation

[0018] The following description is provided to enable any person skilled in the art to make and use the described embodiments. However, various modifications will be apparent to those skilled in the art.

[0019] Tree-based index structures are often designed to optimize update performance at the expense of memory consumption. For example, some tree-based index structures leverage the presence of unused pre-allocated memory to support the fast insertion of new values ​​without having to move existing data.

[0020] The implementation identifies portions of the tree-based index structure for compression and effectively compresses these identified portions. This compression reduces the amount of memory consumed by the tree-based index structure while allowing read and write access to other portions of the tree-based index structure. Compression occurs at the leaf node level. Due to the high fanout of typical tree-based index structures, compression at the leaf node level can significantly reduce the amount of memory required to store the tree-based index structure.

[0021] In some embodiments, compression of a portion of the tree is triggered by an insertion operation. For example, in response to inserting a value into a leaf node, embodiments may operate to merge the values ​​stored in the leaf node and all its sibling leaf nodes into a minimum number of desired leaf nodes. According to some embodiments, inserting a value into a leaf node triggers an evaluation of one or more compression criteria, and the merging of sibling nodes is initiated only if the compression criteria are met.

[0022] As described below, such a merge may require updating the key stored in the parent node of the sibling leaf node. A merge can result in one or more empty leaf nodes, and the memory allocated to the now-empty leaf nodes can be deallocated. Some embodiments perform compaction as an incremental job piggybacked on regular DML operations. This job may have a low impact on the DML workload and does not require costly, long-running global maintenance.

[0023] Figure 1 This is a block diagram of system 100 according to some embodiments. The illustrated elements of system 100 can be implemented using any suitable combination of known or becoming known computing hardware and / or software. Such combinations may include one or more programmable processors (microprocessors, central processing units, microprocessor cores, execution threads), one or more non-transitory storage media, and processor-executable program code. In some embodiments, two or more elements of system 100 are implemented by a single computing device. One or more elements of system 100 may be implemented by an on-site system and / or using cloud-based resources.

[0024] System 100 includes a database server 110 and persistent storage 120. Database server 110 may include server hardware, such as, but not limited to, a field computer server. Database management system (DBMS) 112 may include program code for any query-response DBMS known or becoming known, including but not limited to Structured Query Language (SQL) relational DBMS. Volatile memory 114 may include caches known in the art for storing recently used data. In some embodiments, database server 110 provides an "in-memory" database, wherein volatile memory 114 stores both the cache and the complete database during operation.

[0025] More specifically, for each database table, volatile memory 114 can store the master structure and incremental (delta) structures. The master structure of a given table may include one or more separate master structures for each column of that table, and the incremental structures may similarly include one or more separate incremental structures for each column of that table. The master structure is highly compressed and read-optimized, while the incremental structures are used for updates, i.e., to handle DML workloads. Each incremental structure is merged into its corresponding master structure from time to time based on various triggers to update the master structure to reflect the latest version of the database table / column.

[0026] Persistent storage device 120 includes persistent data 122. Persistent data 122 may include database tables of the database, as well as database snapshots and other backup-related files. At startup, in the case of an in-memory database, the database tables of persistent data 122 are loaded into volatile storage 114. Log 124 includes records of database transactions and allows for auditing and transaction rollback in the event of a database crash, as known in the art.

[0027] Database tables can be stored in permanent data 122 and / or volatile memory 114 in a column-based and / or row-based format. In a column-based format, the data for each column of the database table is stored at contiguous memory addresses, as is known in the art. In a row-based format, the data for each row is stored at contiguous memory addresses. Due to the sequential processing of similar data, column-based storage can exhibit greater compressibility than row-based storage.

[0028] During the operation of system 100, write transactions 130 received from an application (not shown) issue commands, such as, but not limited to, DML statements that require changes to stored database tables. In some embodiments, such changes are applied to incremental structures stored as tree-based index structures in volatile memory 114 and / or permanent data 122. Tree-based storage and compression as described herein are not limited to incremental structures and can be implemented as any set of <key, value> pairs.

[0029] Although System 100 reflects a “single-node” database system, embodiments can also be implemented within one or more nodes of a distributed database, each node including execution processes, caches, and data storage. The data stored in the data storage of each node together represent the complete database, and the database server process on each node operates to transparently provide the complete database data to the aforementioned applications. System 100 can also, or alternatively, support multi-tenancy by providing multiple logical database systems that are programmatically isolated from each other.

[0030] Figure 2A cloud-based database implementation according to some embodiments is depicted. The cloud-based server 210 may include blade servers located in a cloud data center. Consistent with the principles of cloud-based resource provisioning, server 210 may execute a hypervisor to allocate server 210's hardware resources (e.g., volatile memory) among virtual machines 212, 214, and 216. Each of virtual machines 212, 214, and 216 executes its own operating system and corresponding DBMS to provide a database system instance. Each database system instance may communicate with a cloud-based persistent storage device (not shown) to store persistent data and logs as needed.

[0031] Write transactions 230 can be received and routed to the appropriate database system instances of virtual machines 212, 214, and 216. The database system instances can update one or more corresponding tree-based index structures as described herein based on the received write transaction 230. The tree-based index structures can be stored in the virtual machine's volatile memory, in persistent storage, or in a combination of both.

[0032] Figure 3 This is a tabular representation of a portion of data that can be stored in a tree-based index structure according to some embodiments. Data 300 includes multiple <key, value> pairs. For example, data 300 may include a portion of a database column, where each value represents a column value. Data 300 may include a data dictionary for dictionary compression, as known in the art. In some embodiments, the values ​​of data 300 include pointers to memory locations storing data values ​​corresponding to the respective keys.

[0033] The embodiments can be applied to any type of tree-based index structure in which leaf nodes may include unused allocated memory locations. Examples of such structures include, but are not limited to, B-trees, B+ trees, and CSB+ trees.

[0034] Figure 4 A B+ tree 400 is depicted. As is known in the art, the root node 410 and each internal node 420 of the B+ tree 400 store key values ​​(up to four in this example) and corresponding pointers to lower-level nodes. Each leaf node 430 stores <key, value> pairs, where the value may include one or more data values, pointers to stored data values, tuples, identifiers, or other suitable data. Advantageously, leaf nodes 430 include pointers to adjacent leaf nodes to form a linked list providing ordered access to the stored values.

[0035] In another example of a tree-based index structure, Figure 5The CSB+ tree 500 is described. Unlike B+ trees, all child nodes of a given parent node (i.e., sibling nodes) are considered a "node group" and stored contiguously. A node group consists of... Figure 5 The dashed lines in the diagram represent this. Due to contiguous storage, any node in a node group can be located based on its offset from the first node in the node group.

[0036] Therefore, each of the internal nodes 510 and 520 includes a pointer to its first child node (and no other pointers), the number of keys in the node, and a list of keys. Because a node in the CSB+ tree 500 stores only one child pointer, it can store more keys per node than a B+ tree. For example, given a 64-byte node size (and cache line size on an Intel CPU architecture) and 4 bytes of keys and child pointers, a B+ tree node can hold 7 keys, while a CSB+ tree node can hold 14 keys. Each leaf node 530 stores a list of <key, value> pairs, the number of stored pairs, and pointers to its sibling nodes.

[0037] Figure 6 This includes a flowchart of process 600, which uses a tree-based index structure to process insertion operations according to some embodiments. In some embodiments, various hardware elements execute DBMS program code to perform process 200. Process 200 and other processes described herein can be executed by a database system using any suitable combination of hardware and software. The program code embodying these processes can be stored on any non-transitory tangible medium, including fixed disks, volatile or non-volatile random access memory, DVDs, flash drives, and magnetic tapes, and can be executed by any suitable processing unit, including but not limited to one or more programmable microprocessors, microcontrollers, processing cores, and processor threads. Embodiments are not limited to the examples described below.

[0038] Initially, in S610, a <key, value> pair is received to be inserted into a specific tree-based index structure. This pair may be received by the storage engine, page manager, or other components that manage data storage and retrieval. In one example, the <key, value> pair is the value of a cell in a database table stored in column format. Accordingly, the <key, value> pair will be stored in a tree-based index structure associated with the column of the cell. The embodiments are not limited to this. For example, as described above, the value of the <key, value> pair may include a pointer to a memory location where the cell value is stored.

[0039] Next, in S620, the leaf node to which the <key, value> pair should be inserted is identified. The identified leaf node can be referred to as the target leaf node. The identification at S620 depends on the type of tree-based index structure. Typically, for example, the identification of the correct leaf node involves performing a specific search algorithm based on the tree-based index structure to search for the key of the <key, value> pair in the node where the key should be stored.

[0040] The <key, value> pair is inserted into the identified leaf node in S630. Figure 7 Explanation of S630 key K 42 (And its paired value, not shown) is an example that has already been inserted at leaf node 432 of the tree-based index structure 400. In some embodiments, the identified node may not include any unused allocation memory. In this case, the node can be split as is known in the art to produce two nodes with unused allocation memory, and the <key, value> pair can be inserted into the appropriate node of these two nodes. The splitting and insertion process depends on the type of tree-based index structure and will not be discussed in detail herein for the sake of brevity.

[0041] At S640, it is determined whether the inserted leaf node and its sibling node should be compressed as described herein. In some embodiments, compression occurs in response to each insertion. Some embodiments may utilize a counter to make compression occur after every M insertions. The determination at S640 may be based on random chance, such as a software-executed "coin flip" with a 50% chance of either outcome, or a otherwise weighted chance of either outcome (e.g., 75% / 25%).

[0042] In some embodiments, the determination at S640 may also, or alternatively, be based on characteristics of the tree-based index structure. For example, compression may be determined to be performed if the leaf node fill rate exceeds a threshold, or if the memory consumption of the tree-based index structure exceeds a threshold. In yet another embodiment, the determination may be based on the expected outcome of the compression. In some examples, compression is determined to be performed at S640 if compression will eliminate at least one leaf node or a certain percentage of all leaf nodes.

[0043] If it is determined in S640 that the leaf node and its sibling node are not to be compressed, the process returns to S610 to wait for another insertion. If it is determined that the leaf node and its sibling node are to be compressed, the process proceeds to S650.

[0044] In S650, the <key, value> pairs of the identified leaf node and all its sibling nodes are moved to the first <key, value> pair to fill any unused allocation memory between the first stored <key, value> pair and the last stored <key, value> pair of the sibling node. S650 may include all unused allocation memory locations between the first allocation memory location of the leftmost sibling node and the last used allocation memory location of the rightmost sibling node.

[0045] Figure 8 Description of S650 according to some embodiments. As shown, keys K3 and K5 (and their paired values) have been shifted from leaf node 432 to leaf node 434, resulting in key K 42 The keys K1, K6, and K7 (and their paired values) are then shifted from leaf node 436 to three allocated and currently unused storage locations in leaf node 432. The shift at S650 is facilitated by following pointers that exist between sibling nodes in the tree-based index structure 400. However, this shift can be implemented in a tree-based index structure that does not include such pointers.

[0046] In S660, the key and pointer of the parent internal node of the sibling node are confirmed. At this point, the shift at S650 may need to change the key and corresponding pointer of the parent internal node. Continuing this example, leaf node 436 no longer contains any <key, value> pairs. Therefore, as... Figure 8 As shown, parent node 422 no longer needs a pointer to leaf node 436 or its corresponding key. Furthermore, since the first <key, value> pair of node 432 has been changed to include K... 42 Therefore, the second key of parent node 422 is changed from K3 to K. 42 Because the memory location of leaf node 432 remains unchanged, the pointer from internal node 422 to leaf node 432 remains unchanged.

[0047] Then in S670, it is determined whether any sibling nodes are now empty (i.e., do not contain any <key, value> pairs) as a result of the shift. If any sibling nodes are not now empty, the process returns to S610 as described above. If any sibling nodes are now empty, then... Figure 8 As described in the document, in S680, memory allocated to one or more empty sibling nodes is deallocated, thereby freeing up storage space.

[0048] It is worth noting that procedure 600 only affects one internal parent node and its sibling leaf nodes. Therefore, during the execution of procedure 600, all other parts of the tree-based index structure can be accessed to perform database operations.

[0049] Figure 9 and Figure 10 Describing about Figure 5 Examples of structures S630 to S680 of structure 500. For example... Figure 9 As shown in S630, it is again assumed that the key K is... 42 (And its paired value, not shown) has been inserted at leaf node 532. Next, assuming the compressed leaf node and its sibling nodes are determined in S640, the <key, value> pairs of the identified leaf node and all its sibling nodes are shifted in S650. Specifically, these pairs are shifted toward the first <key, value> pair of the leaf node to fill any unused allocated memory between the first <key, value> pair and the last <key, value> pair of the sibling node.

[0050] Figure 10 The following are examples illustrating the causes of some embodiments. Figure 9 The insertion shown is followed by a shift at S650. Keys K3 and K5 (and their paired values) have been shifted from leaf node 532 to leaf node 534, resulting in key K... 42 The keys K1, K6, and K7 (and their paired values) are also shifted from leaf node 536 to three allocated and currently unused storage locations in leaf node 532. As described above, all sibling nodes of the tree-based index structure 500 are stored in contiguous memory areas. In S650, this arrangement facilitates the shifting of <key, value> pairs between nodes.

[0051] Next, in S660, parent node 522 is modified to delete key K1 because leaf node 536 no longer contains any pairs. Furthermore, due to key K... 42 Now that the first key is for sibling node 532, the second key for node 522 is changed to key K. 42 The pointer from internal node 522 to leaf node 534 remains unchanged because the memory location of leaf node 432 has not changed. Next, in S680, the memory allocated to leaf node 536 is deallocated because leaf node 536 is now unused.

[0052] Figure 11 This describes a cloud-based database deployment 1100 according to some embodiments. The described components can reside in one or more public clouds that provide self-service and on-demand provisioning, autoscaling, security, compliance, and identity management features.

[0053] User device 1110 can interact with an application running on application server 1120, for example, via a web browser running on user device 1110, to create, read, update, and delete data managed by database system 1130 and persistently stored in distributed file storage device 1135. Database system 1130 can store data as described herein and can perform processes as described herein to selectively compress portions of the stored tree-based index structure. Application server 1120 and / or database system 1130 may include cloud-based computing resources, such as virtual machines, allocated by a public cloud provider. In this way, application server 1120 and database system 1130 can withstand demand-based resource elasticity.

[0054] The foregoing figures illustrate a logical architecture for describing processes according to some embodiments, and actual implementations may include more or different components arranged in other ways. Other topologies may be used in conjunction with other embodiments. Furthermore, each component or device described herein may be implemented by any number of devices communicating via any number of other public and / or private networks. Two or more such computing devices may be located remotely to each other and may communicate with each other via any known network and / or private connection. Each component or device may include any number of hardware and / or software elements adapted to provide the functionality described herein and any other functionality. For example, any computing device used in an implementation of system 100 may include a programmable processor that executes program code such that the computing device operates as described herein.

[0055] All systems and processes discussed herein can be embodied as program code stored on one or more non-transitory computer-readable media. Such media may include, for example, DVD-ROM, flash memory drives, magnetic tape, and solid-state random access memory (RAM) or read-only memory (ROM) storage units. Therefore, embodiments are not limited to any particular combination of hardware and software.

[0056] The elements described herein as communicating with each other can communicate directly or indirectly through any number of different systems used for transmitting data, including but not limited to shared memory communication, local area networks, wide area networks, telephone networks, cellular networks, fiber optic networks, satellite networks, infrared networks, radio frequency networks, and any other type of network that can be used to transmit information between devices. Furthermore, communication between systems can be carried out through any one or more known or becoming known transport protocols, such as Asynchronous Transfer Mode (ATM), Internet Protocol (IP), Hypertext Transfer Protocol (HTTP), and Wireless Application Protocol (WAP).

[0057] The embodiments described herein are for illustrative purposes only. Those skilled in the art will recognize that other embodiments can be practiced through modifications and changes to the above embodiments.

Claims

1. A system comprising: At least one processing unit; as well as A non-transitory computer-readable medium storing program code, which, when executed by the at least one processing unit, causes the at least one processing unit to perform operations including: Data is stored in a target memory location allocated to a target leaf node of a tree-based index structure, the target leaf node being a child node of a parent node of the tree-based index structure, wherein the tree-based index structure includes one or more other leaf nodes that are children of the parent node, and each of the target leaf node and the one or more other leaf nodes is associated with a plurality of allocated memory locations. Identify all unused allocated memory locations between the first allocated memory location of the target leaf node and the leftmost of the one or more other leaf nodes, and the last used allocated memory location of the rightmost of the target leaf node and the one or more other leaf nodes; and Data stored in the target leaf node and the one or more other leaf nodes is moved to the identified unused allocated memory location. Moving the data includes moving a first data item from a first position of the target leaf node or the one or more other leaf nodes to the first identified unused allocated memory location, and moving a second data item from a second position of the target leaf node or the one or more other leaf nodes to the first position.

2. The system according to claim 1, wherein, When the program code is executed by the at least one processing unit, the at least one processing unit causes the at least one processing unit to perform the following operations: The data updated based on the movement is stored in the parent node.

3. The system according to claim 1, wherein, When the program code is executed by the at least one processing unit, the at least one processing unit causes the at least one processing unit to perform the following operations: Identify the target leaf node and one of the other leaf nodes, including a leaf node with unused memory location; and Release the memory location of the identified leaf node.

4. The system according to claim 3, wherein, When the program code is executed by the at least one processing unit, the at least one processing unit causes the at least one processing unit to perform the following operations: The data stored in the parent node is updated based on the moved data and the deallocated memory location.

5. The system according to claim 1, wherein, The allocated memory locations associated with the target leaf node and the one or more other leaf nodes are contiguous.

6. The system according to claim 1, wherein, When the program code is executed by the at least one processing unit, the at least one processing unit causes the at least one processing unit to perform the following operations: In response to storing the data in the target memory location, a determination is made as to whether to move the data.

7. A computer-implemented method, comprising: Data is stored in a target memory location allocated to a target leaf node of a tree-based index structure, the target leaf node being a child node of a parent node of the tree-based index structure, wherein the tree-based index structure includes one or more other leaf nodes that are children of the parent node, and each of the target leaf node and the one or more other leaf nodes is associated with a plurality of allocated memory locations. Identify all unused allocated memory locations between the first allocated memory location of the target leaf node and the leftmost of the one or more other leaf nodes, and the last used allocated memory location of the rightmost of the target leaf node and the one or more other leaf nodes; and Data stored in the target leaf node and the one or more other leaf nodes is moved to the identified unused allocated memory location. Moving the data includes moving a first data item from a first position of the target leaf node or the one or more other leaf nodes to the first identified unused allocated memory location, and moving a second data item from a second position of the target leaf node or the one or more other leaf nodes to the first position.

8. The method of claim 7, further comprising: The data updated based on the movement is stored in the parent node.

9. The method of claim 7, further comprising: Identify a leaf node among the target leaf node and one or more other leaf nodes, including a leaf node with an unused memory location; as well as Release the memory location of the identified leaf node.

10. The method of claim 9, further comprising: The data stored in the parent node is updated based on the moved data and the deallocated memory location.

11. The method according to claim 7, wherein, The allocated memory locations associated with the target leaf node and the one or more other leaf nodes are contiguous.

12. The method of claim 7, further comprising: In response to storing the data in the target memory location, a determination is made as to whether to move the data.

13. A non-transitory computer-readable medium storing program code, which, when executed by at least one processing unit, causes the at least one processing unit to perform operations including: The data is stored in the target memory location allocated to the target leaf node of the tree-based index structure, where the target leaf node is a child node of the parent node of the tree-based index structure. The tree-based index structure includes one or more other leaf nodes that are child nodes of the parent node, and each of the target leaf node and the one or more other leaf nodes is associated with a plurality of allocated memory locations. Identify all unused allocation memory locations between the first allocation memory location of the target leaf node and the leftmost leaf node of the one or more other leaf nodes and the last used allocation memory location of the rightmost leaf node of the one or more other leaf nodes; as well as Data stored in the target leaf node and the one or more other leaf nodes is moved to the identified unused allocated memory location. Moving the data includes moving a first data item from a first position of the target leaf node or the one or more other leaf nodes to the first identified unused allocated memory location, and moving a second data item from a second position of the target leaf node or the one or more other leaf nodes to the first position.

14. The medium according to claim 13, wherein, When the program code is executed by the at least one processing unit, the at least one processing unit causes the at least one processing unit to perform the following operations: The data updated based on the movement is stored in the parent node.

15. The medium according to claim 13, wherein, When the program code is executed by the at least one processing unit, the at least one processing unit causes the at least one processing unit to perform the following operations: Identify the target leaf node and one of the other leaf nodes, including a leaf node with unused memory location; and Release the memory location of the identified leaf node.

16. The medium according to claim 15, wherein, When the program code is executed by the at least one processing unit, the at least one processing unit causes the at least one processing unit to perform the following operations: The data stored in the parent node is updated based on the moved data and the deallocated memory location.

17. The medium according to claim 13, wherein, The allocated memory locations associated with the target leaf node and the one or more other leaf nodes are contiguous.

18. The medium according to claim 13, wherein, When the program code is executed by the at least one processing unit, the at least one processing unit causes the at least one processing unit to perform the following operations: In response to storing the data in the target memory location, a determination is made as to whether to move the data.

Images