DE112011101391T5 - GPU-enabled database systems - Google Patents

Abstract

Methods for performing parallel queries of a database operation in a database using a graphics processing unit (GPU) are presented, including: receiving a query by a host computer, the query containing database relations; Starting a GPU kernel, the GPU kernels containing a GPU memory; Hash partitioning of the database relations by the GPU kernel; Loading the partitioned database relations into the GPU memory; Loading encrypted partitions corresponding to the hash partitioned database relations into the GPU memory; Building a hash table for a smaller portion of the hash partitioned database relations; and execute the query. In some embodiments, the methods further include returning a result of the query. In some embodiments, in a long query that includes multiple operations, the methods further include parsing the long query into multiple subqueries; wherein for each of the subqueries one of the GPU kernels is started so that the subqueries are processed in parallel.

Description

background

Conventional database systems execute database queries with disk-based tables. Research has shown that traditional disk-based database query execution suffers from severe delays, such as memory latency, processor waiting for data fetch from memory, and L1 data and L2 instruction blockages. Therefore, to address this problem, multiprocessors are increasingly being used to execute database queries. In addition to the disk-based tables, there are the memory-based tables. Memory-based tables are faster than disk-based tables because there is no fetching and loading on the disk component. Memory-based systems can therefore use more efficient techniques to provide the highest possible performance.

A graphics processing unit (GPU) is a massively parallel piece of hardware that can be thought of as having multiple processors with their own local memory. A GPU can operate as an independent co-processor in the host computer. In the late 1990s, the gaming industry provided the necessary impetus for developing the GPU to accelerate graphics in games. More recently, architectures have been configured to support programmability. This means that universal programs can be written to run on the GPU. GPU-ready programs are well-suited to problems associated with data-parallel computations where the same program of high computational intensity is executed for different data.

Short Summary

The following is a simplified summary of some embodiments of the invention to provide a basic understanding of the invention. This summary is not a comprehensive overview of the invention. It is not intended to identify key elements / critical elements of the invention or to represent the scope of the invention. It merely serves to illustrate some embodiments of the invention in a simplified form as an introduction to the more detailed description presented below.

As such, methods for executing queries or queries of a database operation in a database using a graphics processing unit (GPU) are presented, including: receiving a query by a host computer, the query containing database relations; Starting a GPU kernel, the GPU kernels containing a GPU memory; Hash partitioning of the database relations by the GPU kernel; Loading the partitioned database relations into the GPU memory; Loading encrypted, hash-partitioned Database relations corresponding partitions in the GPU memory; Building a hash table for a smaller portion of the hash partitioned database relations; and execute the query. In some embodiments, the methods further include returning a result of the query. In some embodiments, in a long query that includes multiple operations, the methods further include parsing the long query into multiple subqueries; wherein for each of the subqueries one of the GPU kernels is started so that the subqueries are processed in parallel; and return to hash partitioning. In some embodiments, the host computer is a CPU, and database data and database keys are stored in the GPU memory. In some embodiments, the host computer is a CPU, database data and first database keys are stored on a disk data store, and second database keys are stored in the GPU memory. In some embodiments, methods further include synchronizing the first database keys with the second database keys. In some embodiments, the host computer is a database node, first database data and first database keys are stored on a disk data store, and second database data second database keys are stored in the GPU memory.

In other embodiments, computing device program products for performing queries of a database operation in parallel in a graphics processing unit (GPU) supported database are presented in cooperation with a computing device including: a computer readable medium; first programmatic instructions for receiving a query by a host computer, the query containing database relations; second programmatic instructions for starting a GPU kernel, the GPU kernels including a GPU memory; third programmatic instructions for hash-partitioning the database relations by the GPU kernel; fourth programmatic instructions for loading the partitioned database relations into the GPU memory; fifth programmatic instructions for loading encrypted partitions corresponding to the hash partitioned database relations into the GPU memory; sixth programmatic instructions for building a hash table for a smaller portion of the hash partitioned database relations; seventh programmatic statements for executing the query; and eighth programmatic instructions for returning a result from the query, wherein the programmatic instructions are stored on the computer-readable storage medium.

In other embodiments, GPU-enabled database systems are presented for running queries in parallel, including: a database; a database-exchanging GPU, wherein the GPU is configured to process a database query, wherein the GPU includes at least one kernel, the at least one GPU kernel includes GPU memory, and wherein the GPU is configured to: she processes the database query in parallel; and a host computer for receiving database queries.

Brief description of the drawings

One or more embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings. Show it:

1 an illustrative representation of a G80 architecture-compatible GPU according to embodiments of the present invention;

2 an illustrative representation of a memory hierarchy in a GPU according to embodiments of the present invention;

3 an illustrative representation of a connected memory memory pattern and a non-connected memory pattern according to embodiments of the present invention;

4 an illustrative flowchart of methods for providing GPU-enabled database services in accordance with embodiments of the present invention;

5 an illustrative representation of a full-GPU capable database system using memory-based tables in accordance with embodiments of the present invention;

6 an illustrative representation of a cache memory for a GPU-enabled database system according to embodiments of the present invention; and

7 an illustrative representation of a full-GPU capable database system using disk-based tables in accordance with embodiments of the present invention;

Detailed description

Those skilled in the art will understand that the present invention may be practiced as a system, method, or computer program product. Accordingly, aspects of the present invention may take the form of a complete hardware embodiment, a complete software embodiment (including firmware, software in memory, microcode, etc.), or a software and hardware aspects combining embodiment, all herein generally referred to as "circuit", "module" or "system". Further, the present invention may take the form of a computer program product contained on any physical expression medium, including program code usable on the medium on a computer. Any combination of one or more computer usable or computer readable media may be used. The computer-readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or such distribution medium. More concrete examples (a non-exhaustive list) of the computer-readable storage medium include the following: an electrical connection with one or more wires, a portable computer diskette, a hard disk, random access memory (RAM), read only memory (ROM) , an erasable programmable read only memory (EPROM), an optical fiber, a portable compact disk read only memory (CD-ROM), an optical storage unit, a transmission medium such as those using the Internet or a Intranet support or a magnetic storage unit. Note that the computer-readable or even computer-readable medium may even be paper or other suitable medium on which the program is printed, for example, the program may be via optical scanning of the paper electronically detected by other media, then compiled, evaluated or otherwise processed as appropriate, and then stored in computer memory. In the context of this document, a computer-readable or computer-readable medium may be any medium that supports the program being accessed by or in Connection to the instruction execution system, apparatus or unit may be used to contain, store, transmit, propagate or transport. The computer-usable medium may include a forwarded data signal having computer-usable program code therein either in baseband or as part of a carrier wave. The computer usable program code may be transmitted using a suitable medium, including, but not limited to, wireless, wireline, fiber optic cable, RF, etc.

Computer program code for performing operations of the present invention may be written in any combination of one or more programming languages, including object-oriented programming languages such as Java, Smalltalk, C ++, and the like, as well as conventional procedural programming languages such as the "C" programming language or similar programming languages. The program code may be executed entirely on the user's computer, partly on the user's computer, as a standalone software package, partially on the user's computer and partly on a remote computer, or entirely on the remote computer or server. In the latter case, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (e.g. Internet using an Internet service provider).

The present invention will now be described with reference to flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should be understood that each block of the flowcharts and / or block diagrams, as well as combinations of blocks in the flowcharts and / or block diagrams, may be executed by computer program instructions. These computer program instructions may be provided to the processor of a general-purpose computer, a special purpose computer or other programmable data processing device to generate a machine such that the instructions executed via the processor of the computer or other programmable data processing device comprise means for implementing the data in the block or software. Generate the blocks / blocks or the block diagrams or graphs defined functions / steps.

These computer program instructions may also be stored in a computer readable medium that may control a computer or other programmable computing device to function in a particular manner such that instructions stored on the computer readable medium produce a manufactured product. including instruction means which translate the function / step specified in the block (s) of the flowcharts and / or block diagrams.

The computer program instructions may also be loaded onto a computer or other programmable data processing device to cause the execution of a series of process steps on the computer or other programmable device to generate a process executed on a computer such that the computer's computer or any other programmable device generate processes to translate the functions / steps specified in the block (s) of the flowchart and / or block diagrams.

Turning now to the figures, the flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of the systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of code that includes one or more executable instructions for performing the particular logical function (s). It should also be noted that in some alternative embodiments, the functions indicated in the block may take place in a different order than shown in the figures. For example, two blocks shown in succession may in fact be performed substantially simultaneously, or the blocks may sometimes be executed in reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and / or the flowcharts, as well as combinations of blocks in the block diagrams and / or schedules, may be implemented by special hardware-based systems having the designated functions or functions Perform steps, or combinations of specialized hardware and computer instructions.

Compute Unified Device Architecture (CUDA ^TM ) is a collection tools that enable you to run universal programs written in a C-like language. The collection of CUDA ^TM tools shows the underlying target hardware via a C-like API. CUDA ^TM is designed to increase performance in many data-parallel applications by supporting the parallel execution of thousands of threads. As such, a compiled CUDA ^™ program can scale with the advances of hardware. There are at least two ways to implement a GPU-enabled database - a) in one embodiment, a real database system can be activated and b) a cache can be activated to speed up other database queries, ie a GPU storage database can only be used for the Running database queries will be activated.

1 shows an illustrative representation 100 a G80 architecture-compatible graphics processing unit (GPU) according to embodiments of the present invention. As illustrated, a G80 architecture may include multiple components, including: a host computer 102 , an input assembler 104 , a thread execution manager 106 , a store / save 108 and a global memory 110 , These components work in concert with multiple shared multiprocessors 120 , A typical G80 architecture-compatible GPU can handle 128 data stream processors 122 included in 8 shared multiprocessors 120 are divided, each containing 16 data stream processors. Each shared multiprocessor 120 contains shared local storage 124 that is shared by threads running on the shared multiprocessor. This is beneficial because it helps with coalesced access - when thread groups perform operations on data in the vicinity.

2 shows an illustrative representation of a memory hierarchy 200 in a GPU according to embodiments of the present invention; The storage hierarchy 200 contains the per-thread memory 204 , the per-thread group store 208 and the global / unit memory 212 , Any thread running in the GPU can access the global / device memory 212 access. Read and write operations on the device memory 212 are compared to the other stores 204 and 208 slowly. The GPU threads 208 Compared to CPU threads, they are extremely lightweight, and so there is essentially zero overhead in creating thousands of threads. Most importantly, threads do not run on a single processor. Instead, multiple threads are named in "warps (warps)" thread groups 206 executed on a single shared multiprocessor (see 1 . 120 ). Threads in a chain can share the local memory of the shared multiprocessors. This capability results in improved performance since fewer read / write operations are performed in the global memory to fetch and load data. That is, data is retrieved once into shared memory of the shared multiprocessor, calculations are performed, and results are loaded into global memory.

Embodiments described herein optimize memory utilization by a) effectively and efficiently utilizing parallelism, and b) associating read operations from the global memory. By leveraging parallelism, parallel execution of database operations across as many threads on a GPU as possible at any one time is possible. By connecting read operations from the global memory, adjacent areas in global memory can be manipulated by threads in a thread group. 3 shows an illustrative representation of an associated memory memory pattern 300 and a non-merged memory map 310 according to embodiments of the present invention. In the connected memory pattern 300 are the threads t0 to t3 302 in the right order in the store 304 , In contrast, the threads are t0 to t3 312 in the unconnected memory pattern 310 not in the right order in the memory 314 , Associated memory patterns, in some embodiments described herein, may provide benefits for processing. In some embodiments, hash partitioned relations in a connected access pattern may be loaded into the GPU memory so that an adjacent portion of the GPU memory is used.

4 shows an illustrative flowchart 400 method of providing GPU-enabled database services according to embodiments of the present invention. In particular, methods for performing parallel queries of a database operation in a data table using a GPU are illustrated. In a first step 402 the method receives a query. Queries may be received by any host computer in any manner known in the art without departing from the present invention. In embodiments, a query may include at least two database relations. In a next step 404 The method determines whether the received query is a long query. In embodiments, a long query may require additional processing steps. If the process in one step 404 If the query determines that the query is not a long query, the procedure moves in one step 406 and starts a GPU kernel, whereupon the method comes with a step 410 continues. If the process in one step 404 If the query determines that the query is a long query, the procedure moves in one step 420 continues and dissects the long query into multiple subqueries. Partitioning long queries provides the benefit of running queries across multiple GPU kernels in parallel. As such, the method starts in a next step 422 a GPU kernel for each subquery. Subqueries may, in embodiments, be based on a variety of parameters, e.g. As the size determined. That is, a subquery can be determined based on whether the subquery fits into the GPU memory.

The process moves with one step 410 and hash partitioned all relations to GPU kernel (s). Hash partitioning may be done in any manner known in the art without departing from the present invention. In a next step 412 The procedure loads hash-encrypted partition relations and keys into the GPU memory. In a next step 414 builds a hash table for the smaller table and performs in one step 416 the query or subqueries by the GPU kernel (s). In one step 416 returned results may first be written to the GPU device memory and then made accessible to a user in the host computer memory, whereupon the method ends.

In an exemplary embodiment, take a case of a JOIN between two database relations R and S. Assume that the relations are small enough to fit in the GPU memory. Thus, the example is not a large query. Embodiments hash-partition both relations (R and S) and import the same encrypted partition from both relations into the GPU memory. Embodiments then construct a hash table for the smaller table and check the other relation for matches. In one embodiment, hash encryption is performed on the join key. If relationships are larger than the available GPU memory, you can use multiple hash functions to reduce the size. In a long query embodiment with many operators, the long query can be split into multiple subqueries that can be executed in parallel and then combined after processing.

It can be understood that GPU-enabled database processing is associated with at least some memory-based problems, e.g. For example: table selection, shared access, data volatility and memory usage. In CEILADB ^™ embodiments, the table selection may be tied to the number of accesses / second performed on the table. In other embodiments using CEILADB ^™ , shared access may be compromised because thread blocks may be operating in the same shared multiprocessor. As such, in embodiments, a call such as SYNCTHREADS (from a CUDA ^™ library) synchronizes the threads in the same shared multiprocessor. However, any similar call may be made without departing from the embodiments set forth herein. If two threads from two different shared multiprocessors want to write data, they must synchronize via global memory. In other embodiments using CEILADB ^™ , the volatility can be solved by implementing a function which stores the data from the GPU on the disk. In other embodiments using CEILADB ^™ , memory consumption can be resolved by allowing a user at any time to poll the amount of memory used by the tables created by the user. The user can also set memory usage parameters that control the way data is written to memory or disk - each time or when the memory consumed is used.

The following examples are provided for clarity of understanding of embodiments of the present invention and are not to be considered as limiting. 5 shows an illustrative representation of a fully GPU capable database system 500 using memory-based tables according to embodiments of the present invention. In the illustrative embodiment, a user may 502 either locally or remotely at the host computer 504 log in to perform queries. In some embodiments, the host computer is a CPU. In some embodiments, the queries are SQL-type queries. Queries can be sent to the GPU 506 sent on the GPU 506 executed and sent to the host computer 504 be sent back. Results can be sent to the user 502 be sent back. As noted above, in embodiments, a GPU may be a G80 architecture-compatible GPU. As illustrated, the GPU 506 be configured to use memory-based tables. As such, in embodiments, database data and database keys may be stored in the GPU memory, where the memory may be shared in some embodiments. Since database data and database keys are located entirely in the GPU memory, performance benefits can be achieved. However, due to the limited size of the GPU memory, in embodiments, size limitations of the database table may be required. As noted above, memory usage in embodiments employing CEILADB ^™ may be resolved by allowing a user at any time to query the amount of memory used by the tables created by the user. The user can also set memory usage parameters that control the way data is written to memory or disk - each time or when the memory consumed is used.

6 shows an illustrative representation of a cache memory for a GPU-enabled database system 600 according to embodiments of the present invention. In the illustrative embodiment, a user may 602 either locally or remotely at the host computer 604 log in to perform queries. In some embodiments, the host computer is a database node. In some embodiments, the queries are SQL-type queries. Queries can be sent to the GPU 606 sent on the GPU 606 executed and sent to the host computer 604 be sent back. Results can be sent to the user 602 be sent back. As noted above, in embodiments, a GPU may be a G80 architecture-compatible GPU. In this embodiment, a user may take advantage of the GPU's high processing power and memory bandwidth to speed database queries from other database systems, since in this example the host computer is a database node. As above, in embodiments, database data and database keys may be stored in the GPU memory, where the memory may be shared in some embodiments. In addition, in embodiments, database data and database keys may be on the tertiary disks 608 get saved. Running queries in a commercial database is the user 602 in embodiments, not aware that queries are made by the GPU 606 are processed.

7 shows an illustrative representation of a fully GPU capable database system 700 using disk-based tables according to embodiments of the present invention. In the illustrative embodiment, a user may 702 either locally or remotely at the host computer 704 log in to perform queries. In some embodiments, the host computer is a CPU. In some embodiments, the queries are SQL-type queries. Queries can be sent to the GPU 706 sent on the GPU 706 executed and sent to the host computer 704 be sent back. Results can be sent to the user 702 be sent back. As noted above, in embodiments, a GPU may be a G80 architecture-compatible GPU. If a user is dealing with huge amounts of data in this embodiment, it may not be possible to store all the data in the GPU memory. Therefore, in embodiments, database data and database keys may be on the tertiary disks 708 get saved. Additionally, in embodiments, database keys may be stored in the GPU memory. As such, a host computer copy is used in retrieving data from the disks, and the GPU unit copy is used to access tuples in the GPU storage. After inserting operations into a database, all copies must be synchronized to avoid inconsistencies. In some embodiments, it is imperative to process the disk accesses with pipelined calculations to achieve significant improvements in performance.

Although this invention has been described in terms of several embodiments, there are variations, implementations and equivalents that fall within the scope of this invention. It should also be noted that there are many alternative ways of implementing the methods, the computer program products and the devices of the present invention. Furthermore, unless expressly stated, any method embodiments described herein are not limited to any particular order or sequence. Furthermore, the summary is provided herein for convenience and is not to be taken as limiting or limiting in its entirety to the invention set forth in the claims. Therefore, it is intended that the following appended claims be interpreted as including all such alterations, implementations, and equivalents that fall within the true spirit and scope of the present invention.

Claims (20)

A method of performing queries of a database operation in parallel in a database using a graphics processing unit (GPU), the method comprising: Receiving a query by a host computer, the query comprising at least two database relations; Launching at least one GPU kernel, wherein the at least one GPU kernel includes a GPU memory; Hash partitioning of the at least two database relations by the GPU kernel; Loading the at least two hash partitioned database relations into the GPU memory; Loading encrypted partitions corresponding to the at least two hash partitioned database relations into the GPU memory; Building a hash table for a smaller part of the at least two hash partitioned database relations; and execute the query. The method of claim 1, further comprising returning a result of the query. The method of claim 1, further comprising: if the query is a long query containing a plurality of operators, parsing the long query into multiple subqueries; wherein, for each of the subqueries, one of the at least one GPU kernel is started so that the subqueries are processed in parallel; and Return to hash partitioning. The method of claim 1, wherein it is the host computer is a CPU, and where Database data and database keys are stored in the GPU memory. The method of claim 1, wherein it is the host computer is a CPU, where Database data and first database key are stored on a disk data storage, and wherein second database keys are stored in the GPU memory. The method of claim 5, further comprising: Synchronize the first database key with the second database key. The method of claim 1, wherein the host computer is a database node, where first database data and first database keys are stored on a disk data store, and wherein second database data and second database key are stored in the GPU memory. The method of claim 7, wherein the data disk storage is pileline-coupled to the GPU. The method of claim 1, wherein the database is a CEILADB ^™ database. The method of claim 9, wherein the CEILADB ^™ database is configured to log transactions so that a rollback can be initiated when an inconsistent state occurs between the host computer and the GPU. The method of claim 9, wherein the CEILADB ^™ database is configured to limit memory usage so that the query is restricted to a restricted class of queries. The method of claim 1, wherein the GPU is a G80 architecture-compatible GPU. The method of claim 1, wherein the GPU memory is a shared memory for the at least one GPU kernel. The method of claim 1, wherein there are two hash partitioned relations in the GPU memory in a connected access pattern such that an adjacent area of the memory is used. A computer program product for performing parallel queries of a database operation on a database using a graphics processing unit (GPU) in cooperation with a computing device, the computer program product including a computer readable medium containing program instructions that, when executed by a computer, cause the computer to: to carry out the steps according to one of claims 1 to 14. A graphics processing unit (GPU) supported database system for executing queries in parallel, comprising: a database; a database-exchanging GPU, the GPU configured to process a database query, wherein the GPU includes at least one GPU kernel, the at least one GPU kernel containing a GPU memory, and wherein the GPU is configured to process the database query in parallel; and a host computer for receiving database queries. The system of claim 16, wherein the host computer is a CPU, and the Database data and database keys are stored in the GPU memory. The system of claim 16, wherein it is the host computer is a CPU, where Database data and first database key are stored on a disk data storage, and wherein second database keys are stored in the GPU memory. The system of claim 16, wherein the host computer is a database node, where first database data and first database keys are stored on a disk data store, and wherein second database data and second database key are stored in the GPU memory. The system of claim 16, wherein the database is a CEILADB ^™ database.

Images