RU2490702C1 - Method of accelerating processing of multiple select-type request to rdf database using graphics processor - Google Patents

Abstract

FIELD: information technology.

SUBSTANCE: disclosed is a method for parallel processing of multiple requests to RDF databases using a graphics processor, which is characterised by that a linking request received at a server is first broken down into elementary requests, after which said elementary requests are placed into a common input queue, from where they are loaded in blocks into the memory of the graphics processor and passed through the graphics processor conveyor, where for each elementary request, a set of elementary responses is calculated, and the obtained responses are then merged into a list of threes, which is a response to the linking request.

EFFECT: high capacity of the request processing server.

18 cl, 5 dwg, 2 tbl

Description

The invention relates to information processing technologies, and more specifically to methods for providing access to information stored in databases.

Data and databases play a key role in today's world. With the development of network technologies, a tendency has emerged to share network resources. One database serves many clients over the network. Thus, the most important characteristic of a database is its throughput - the number of queries that it can process per unit of time. The bottleneck is often the processing power of the machine. To combat this problem, various parallel query processing schemes have been developed.

One of the attempts is described in [1]. The authors of this work propose a method for decomposing an SQL query, as well as an optimal strategy for parallel processing of query components on several processors. The disadvantage of the described method is that the potential degree of parallelism of this method is limited by the number of query components. Some of the simplest types of SQL queries are not decomposable at all.

In [2], it is proposed to bind each processor in a cluster to a separate piece of data. Then the SQL query will be applied simultaneously to all portions, and the results will then be combined. Theoretically, the degree of parallelism of this approach is limited only by the number of processors. In practice, however, combining the results can take considerable time for a large number of servings. A bottleneck could also be a data transfer channel between processors in a cluster. In addition, the economic efficiency of using a cluster with a large number of machines for this task is doubtful.

Currently, GPU (Graphics Processing Unit) GPUs are a relatively inexpensive alternative to multi-core processors and clusters. GPU is based on a graphic multiprocessor. It consists of many processors (streaming processor), which are logically grouped. On such a multiprocessor, you can run hundreds (by the number of processors) of parallel threads - copies of the same procedure called the kernel (the English term is kernel). In the prior art, parallel algorithms are known for several classes of problems, allowing them to be solved by GPUs much more efficiently than on a multicore processor or in a cluster.

The main difficulty encountered when trying to use a graphic multiprocessor for general computing is that the power of one processor is not large enough, which is offset by a large number of them. Also, the device of modern graphic processors is such that full parallelism of execution is possible only for the simplest cores. The presence of branching and memory accesses in the kernel code can cause delays and lead to a strong decrease in the degree of parallelism. This implies the need to divide any task into as many very simple independent sub-tasks as possible.

In [3], a technique was proposed in which the query processing kernel is launched simultaneously for many different queries. To use the GPU was justified, you need to process hundreds of requests at the same time. Obviously, all the data that is processed by the request during the search must be in the GPU memory (this may be the entire database or some segment of it). Data found during the search should also be stored in the GPU's memory before being transferred to the main memory. To run hundreds of threads at once, you will need a very large amount of GPU memory to store the results. In addition, the kernel code that processes the entire SELECT-type query will obviously be quite complex, and the actual degree of parallelism at its launch will be far from the maximum.

Of particular interest in connection with this problem are semantic databases, in particular, presented in the form of RDF (Resource Description Framework). In fact, in such a base, triples (s, p, o) are stored - the subject, predicate and object. Each field is represented by a string, but a fairly common technique is to store triples of integer hash codes, which is enough for identification. SELECT queries to the RDF database are usually formulated in SPARQL (SPARQL Protocol and RDF Query Language).

The significant simplicity of the RDF database structure allows us to hope that for the implementation of SELECT queries, we can construct very simple algorithms that allow parallel implementation. The basis of the SPARQL query is a formula that operates on triples templates, between which there are logical operations “AND” and “OR”. Each template contains three fields that contain either a specific value or a variable name.

The currently used technique for processing a SPARQL query is that, based on this set of templates, a formula is derived that operates on a different type of template, also connected by the signs “AND” and “OR”. Moreover, each template in each position contains either a set of valid values or a special mask, which means that any value is allowed in this position. Each such template is actually the simplest request to retrieve data from the database (the so-called request for binding). The result of its implementation is a lot of specific triples extracted from the base. The above-mentioned formulas are then calculated over these sets (the operation “AND” is replaced by the intersection of the sets, and “OR” by the union) and the resulting set of triples is obtained.

In [4], a method for processing queries of the SELECT type to an RDF database is described, where the entire process described above for receiving a response to a query is preceded by its optimization - presentation in the form of another, equivalent set of templates, which is characterized by a shorter data search path in the database. This is done on the basis of semantic rules derived automatically from the current contents of the database at the pre-processing stage. In principle, this optimization can be applied regardless of how the data extraction process itself is implemented, but its effect may depend on this.

The problem to which the invention is directed, is to increase the throughput of the server for processing queries of the SELECT type to the RDF database.

The technical result is achieved through the development and application of an original algorithm for parallel processing of multiple binding requests executable on a graphic processor unit (GPU), as well as an improved RDF database system based on a graphic processor unit (GPU).

To solve this problem, the claimed invention proposes a method for parallel processing of multiple queries to RDF databases using a GPU, characterized in that the binding request received by the server is first divided into elementary queries, after which these elementary queries are transferred to the input queue, from where they are loaded with blocks into the memory of a graphic processing unit (GPU) and passed through a GPU pipeline, where for each elementary request a set of electronic elementary answers, and then combine the received answers into a list of triples, which is a response to a request for linking.

According to the claimed invention, said GPU device allows using its computing power for general purpose computing using OpenCL technology (Open Computing Language).

According to the claimed invention, said linking request is a set of three lists, each of which contains a set of valid values for the subject, predicate and object, respectively, and an empty list means that any value is allowed in the corresponding position.

According to the claimed invention, the indicated elementary query is a template with three fields, each of which contains either a specific value for the subject, predicate and object, or a mask, which means that any value is allowed in this position.

According to the claimed invention, said transformation of a request for binding to a set of elementary queries consists in calculating the Cartesian product of the sets given by the lists that make up the binding request.

According to the claimed invention, each elementary request contains a record for identification with the binding request that generated it.

According to the claimed invention, the processing of elementary requests on the GPU pipeline is carried out in three stages, at each of which for each elementary request received from the previous stage, a set of elementary requests for the next stage is calculated and recorded in each of the received requests in the field corresponding to the current stage, defined value, so that it, in combination with the values of the fields corresponding to the previous stages, forms an acceptable combination.

According to the claimed invention, when processing requests on the GPU pipeline, the predicate binding, the subject binding, the object binding are sequentially performed.

According to the claimed invention, at each stage of the GPU pipeline, first, using the GPU expansion procedure, for each elementary request, a set of elementary requests for the next stage is calculated from the input buffer and written to an intermediate buffer, where space is allocated for the maximum number of requests, checking for each received query whether it contains a valid combination of fields, and then using the GPU, the drop procedures move the validated requests to the output buffer, which is one at the same time the input buffer for the next stage.

According to the claimed invention, after the end of the current stage of processing GPU data by the device, the next processing step is selected so that it uses the maximum number of GPU flows.

In addition, to solve the problem, the claimed invention also proposes an RDF database system based on a GPU device for parallel processing of multiple requests, including:

- a server for receiving requests for binding to the database, where they convert the request for binding into a set of elementary queries,

- database

- a graphics processing unit configured to process queries to a database in parallel, comprising

- memory and

- GPU pipeline, configured to calculate a set of elementary answers for each elementary request, and then combine the received answers into a list of triples, which are a response to a request for linking to the database.

According to the claimed invention, the GPU device conveyor consists of three sequentially executed stages of processing elementary requests.

According to the claimed invention, the stages of processing elementary queries on the GPU pipeline are predicate binding, subject binding, and object binding.

According to the claimed invention, at each stage of the GPU pipeline, an elementary request generates zero or more requests for the next stage.

According to the claimed invention, part of the GPU memory is intended for storing a database, and the other part is reserved for buffers for storing elementary requests awaiting processing at one of the stages of the GPU pipeline, and for intermediate buffers.

According to the claimed invention, buffers for storing elementary queries are a ring queue.

According to the claimed invention, the database is stored in memory in the form of a hierarchy of balanced binary trees, which is based on a predicate tree, each node of which corresponds to a specific predicate and refers to a tree of subjects forming a valid pair with this predicate.

According to the claimed invention, when storing a database in memory, balanced binary trees of subjects are used, each node of which corresponds to a specific subject and refers to a tree of objects that form an admissible triple with this subject and the predicate to which the subject tree is subordinate.

For a better understanding of the claimed invention the following is a detailed description with the involvement of graphic materials.

Figure 1 - Scheme of processing a request for binding.

Figure 2 - Scheme of processing SPARQL query.

Figure 3 - Scheme of the device stage of the conveyor.

4 is a flowchart of the generation procedure.

5 is a flowchart of a drop procedure.

Table 1. GPU pipeline stages.

Table 2. Stage 2 results depending on the input.

A diagram of a method for processing a binding request is shown in FIG. When a query 101 arrives at the database server, it is converted to a set of elementary queries 102. An elementary query is essentially a template with three fields. Each field either sets a specific value for the subject (predicate, object), or contains a mask, which means that any value can be in this position. The conversion process is nothing more than calculating the Cartesian product of the lists that make up the query. Each elementary query contains an entry for identification with the parenting query that generated it.

Elementary requests from different binding requests (and even from different clients) fall into the general queue at input 103. From there they are loaded in blocks into the GPU memory and transferred to the GPU pipeline 105. At the output of the GPU pipeline 105, they receive a set of elementary answers. Each answer is the same template with three fields, but this time all the fields in it are fixed (they contain specific values). The presence of such a response in the output queue 107 means that the corresponding triple was found in the database, and that it satisfies the conditions of the request for binding. The number of elementary answers, therefore, depends on how many such triples were found.

The list of triples 108 obtained from the elementary responses corresponding to the same binding request is a response to this request.

Figure 2 shows a well-known technique for processing SPARQL query 201. The procedure is that based on this set of patterns, a formula is derived that operates on a different type of patterns, also connected by the signs "AND" and "OR". Here, each template in each position contains either a set of valid values or a special mask, which means that any value is allowed in this position. Each such template 202 is actually the simplest request to retrieve data from the database. The result of its implementation is a lot of specific triples 203, extracted from the base. These sets are then computed with the above formula (the operation “AND” is replaced by the intersection of the sets, and “OR” by the union) and the resulting set of triples 204 is obtained.

As for the principle of operation of the GPU conveyor, it is illustrated in FIG. 3 and in Table 1.

In the claimed invention, the GPU allows the use of its computing power for general purpose computing using the OpenCL technology (Open Computing Language).

GPU conveyor consists of three stages (see Table 1). At each particular point in time, the graphics processor is busy processing only one stage. At the same time, it processes several elementary queries at once. At this moment, the processor does not play any role in what kind of binding request an elementary request was originally generated. Many queries are completely uniform.

At each stage, each elementary query can generate zero or more queries for the next stage. As a result, for each elementary request that falls into the input queue, the pipeline gives zero or more elementary answers that are written to the output queue.

Each time a certain stage finishes processing, it is necessary to decide which stage will now load the GPU. In order to maximize the power of the GPU, choose the stage that has the greatest potential in terms of the number of threads. This depends on the number of requests in the input buffer of the stage, and on the amount of free space in the output buffer.

GPU consists of a graphic multiprocessor and a certain amount of memory. This memory is divided into local (for individual processors and processor groups) and global. Most of the memory is in global memory, where data is stored, access to which may be required by any processor.

When using the proposed method, part of the global memory is allocated to the database itself (the database can be entirely located on one GPU, and can be divided into segments distributed between several devices), and the other part - under buffers for storing elementary requests awaiting processing on one of the stages of the conveyor. It is important to note that all the data necessary to respond to any request is constantly in the memory of the GPU, because loading data from the main memory into the GPU memory requires very large resources.

The described pipeline sequentially conducts binding first by predicate, then by subject and, finally, by object. Therefore, it is necessary to store the database in memory in such a way as to ensure the quick execution of the following operations.

1) Check if the given predicate p.

2) Get a list of predicates in the database.

3) Check if the given predicate-subject pair is valid (p, s).

4) Get a list of entities forming an acceptable pair with the predicate p.

5) Check if the given triple (p, s, o) is admissible.

6) Get a list of objects forming an admissible triple with a given pair (p, s).

Effective implementation of these operations is achieved by storing data in the form of a hierarchy of balanced binary trees. The hierarchy is based on a predicate tree. Each tree node corresponds to one valid predicate and refers to a tree of subjects that form a valid pair with this predicate. Each node of the subject tree, in turn, refers to a tree of objects that form an admissible triple with this object and an overlying predicate. The binary tree is stored as a linear array of nodes, where the sons of the node with number n have the numbers 2 * n (left) and 2 * n + 1 (right). A node is searched in such a tree in O (log N) time, where N is the number of nodes in the tree.

The pipeline requires the following set of buffers:

1) Elementary requests awaiting processing at stage 1 (new elementary requests from the main memory are loaded into the free part of the same buffer; on some types of architectures, this can occur in parallel with data processing by the GPU).

2) Elementary requests awaiting processing at stage 2 (elementary requests at the output from stage 1 fall into the free part of the same buffer).

3) Elementary requests awaiting processing at stage 3 (elementary requests at the output from stage 2 fall into the free part of the same buffer).

4) Elementary answers (elementary requests from stage 3 get here. Since all the fields are already fixed in them, they can be called elementary answers. From here they are uploaded to the main memory. On some types of architectures, this can happen in parallel with data processing by the GPU )

5) Intermediate buffer (used for temporary storage of data during the operation of the stage).

Each of the buffers, except for the intermediate one, is a ring queue (a queue with a limit on the number of elements that are simultaneously in it). It is known where the “head” of the line is currently located, and where is the “tail”. When starting the next stage of the pipeline, the maximum possible number of elements located in the "head" of the input queue is selected, and for the results of the stage, a place is allocated in the "tail" of the output queue.

Stage structure.

Consider, for example, stage 2 (the rest work in a similar way). Each elementary query in the input buffer for this stage contains a template where a specific predicate value is indicated.

We say that subject s satisfies the predicate p (forms an admissible pair with it) if at least one triple of the form (p, s, о) is present in the base, i.e. there is at least one object that complements this pair to a full three. The specific number of child queries generated by one elementary query depends on how many entities satisfy the predicate specified in it, as well as on the template. All possible options are given in Table 2 (at this stage we are not interested in the “object” field, therefore it is marked with a question mark).

The device of one stage of the conveyor shown in Fig.3. Processing takes place in three steps:

1) Generation.

2) Calculation of displacements.

3) Drop.

In the first step, the spawning kernel is launched. The number of threads in this case is determined by how much free space is available in the output buffer 307. The block diagram of the operation of the generation core (for stage 2) is shown in FIG. 4 (steps 401-411). Each thread 303 generates one elementary request 305 and a place is allocated for it in the intermediate buffer 304. Initially, each thread 303 has only one parameter (number) that distinguishes it from others. This is the so-called global ID. It computes which request 302 from the input buffer 301 will serve as the parent for the given one, and the template from the parent request is copied to this one.

This template already explicitly indicates the predicate (in the case of stage 2). This predicate in the database is satisfied by a certain number of subjects. By the global ID, each thread is mapped to a specific subject from this list. The formula for determining the parent request is such that the number of threads 303 that have identified themselves as children for this input request 302 will be equal to the number of subjects in this list.

Thus, each thread 303 creates in the intermediate buffer 304 a child query 305 with a template where the predicate and subject are fixed. It remains to be determined whether this request 305 has a right to exist. To do this, we must make sure that either in the template in the “subject” position there is a mask that allows any value, or if a specific value of the subject is indicated there, that it matches the one selected for this stream. All other generated queries are marked as invalid.

To compact the array of generated queries, the well-known algorithm for calculating the prefix sum is used. For each valid request, 1 is entered in the corresponding cell of the special array of offsets, and 0 for the invalid one. Then, the kernel starts calculating the prefix sum with the number of threads equal to the number of generated requests. As a result, in each cell of the offset array there is a sum of the values of all previous cells. This number can be used as the offset of this request in the output buffer.

Finally, in the third step, the drop core is launched with the number of threads 306 equal to the number of generated requests 303. The block diagram of the drop core is shown in FIG. 5 (steps 501-506). Each thread by global ID determines the offset of the corresponding request 305 in the intermediate buffer 304. If the request 305 is valid, the stream copies it to the output buffer 307 at the offset extracted from the offset array.

It is easy to see that the procedures used by the GPU are quite simple with a small number of branches. At the same time, the number of threads running in parallel is limited only by the number of requests received in processing and the size of buffers. The restriction on the size of the buffer is not significant, since the amount of memory required for the operation of one stream is equal to the size of the structure of the elementary request, which is only about 30 bytes. Thus, the method used provides a higher degree of parallelism and a higher level of loading of the GPU (with a sufficient number of input requests) compared to the method described in [3].

Nothing prevents the use of the optimization proposed in [4] together with the claimed method, but its effect in this case cannot be guaranteed, since it is designed for a certain method of data extraction, the speed of which depends on the length of the search path, the reduction of which is the aim of optimization .

Measurements of performance in the described embodiment of the proposed method show that on some types of requests it is possible to get a win three times in relation to the processing algorithm executed on a modern central processor. With the increase in the number of processors in the graphic multiprocessor and the amount of memory on the GPU device, the method will give an increasing effect.

Literature

1.- Program product for optimizing parallel processing of database queries (US 6009265, 12/28/1999)

2. - Database early parallelism method and system (US 20050131893, 06/16/2005)

3.- GPU ENABLED DATABASE SYSTEMS (US 20110264626, 10/27/2011)

4. - METHOD AND SERVER FOR HANDLING DATABASE QUERIES (WO 2011162645, 12/29/2011)

Claims (18)

1. A method for parallel processing of multiple queries to RDF databases using a GPU, characterized in that the binding request received on the server is preliminarily divided into elementary queries, after which these elementary queries are placed in a common input queue, from where they are loaded into memory in blocks GPU devices and pass through the GPU pipeline, where for each elementary request a set of elementary answers is calculated, and then the received answers are combined into a list of triples, vlyayuschiysya response to the link request. 2. The method according to claim 1, characterized in that the GPU device is configured to use its computing power for general purpose computing using the Open Computing Language technology. 3. The method according to claim 1, characterized in that the binding request is represented as a set of three lists, each of which contains a set of valid values for the subject, predicate and object, respectively, and an empty list means that any value is allowed in the corresponding position . 4. The method according to claim 1, characterized in that the elementary query is a template with three fields, each of which contains either a specific value for the subject, predicate and object, or a mask, which means that any value is allowed in this position. 5. The method according to claim 1, characterized in that the conversion of the binding request into a set of elementary queries is performed by calculating the Cartesian product of the sets specified by the lists constituting the binding request. 6. The method according to claim 1, characterized in that each elementary request contains an entry for identification with the binding request that generated it. 7. The method according to claim 1, characterized in that the processing of elementary requests on the GPU pipeline is carried out in three stages, at each of which for each elementary request received from the previous stage, a set of elementary requests for the next stage is calculated and recorded in each of the received queries in the field corresponding to the current stage, a certain value, so that it, in combination with the values of the fields corresponding to the previous stages, forms an acceptable combination. 8. The method according to claim 7, characterized in that when processing requests on the GPU pipeline, the predicate binding, the subject binding, the object binding are sequentially performed. 9. The method according to claim 7, characterized in that at each stage of the GPU pipeline, first using the GPU expansion procedure for each elementary request, from the input buffer, a set of elementary requests for the next stage is calculated and written to an intermediate buffer, where space is allocated for the maximum possible the number of requests, checking for each request received whether it contains a valid combination of fields, and then using the GPU, the drop procedures move the tested requests to the output buffer, which is simultaneously input buffer for the next stage. 10. The method according to claim 7, characterized in that after the end of the current stage of processing GPU data by the device, the next stage for processing is selected so that it uses the maximum number of GPU flows. 11. RDF database system based on a GPU device for parallel processing of multiple queries, including a server for receiving binding requests to a database, where the binding request is converted into a set of elementary queries, a database, and a GPU device with the possibility of parallel processing of queries to the database, containing the memory and the GPU pipeline, configured to calculate a set of elementary answers for each elementary request a, and the subsequent combination of the received answers in a list of triples, which are a response to a request for linking to the database. 12. The system according to claim 11, characterized in that the pipeline of the GPU device consists of three sequentially executed stages of processing elementary requests. 13. The system of claim 12, wherein the steps of processing elementary queries are predicate binding, subject binding, and object binding. 14. The system according to p. 12, characterized in that at each stage of the GPU pipeline elementary request generates zero or more requests for the next stage. 15. The system according to p. 12, characterized in that part of the memory of the GPU device is configured to store a database, and the other part is configured to be used as buffers for storing elementary requests awaiting processing at one of the stages of the GPU pipeline, and for intermediate buffers . 16. The system of clause 15, wherein the database is stored in memory in the form of a hierarchy of balanced binary trees, which is based on a predicate tree, each node of which corresponds to a specific predicate and refers to a tree of subjects that form a valid pair with this predicate. 17. The system according to clause 15, characterized in that when the database is stored in memory, balanced binary trees of subjects are used, each node of which corresponds to a specific subject and refers to a tree of objects forming an admissible triple with this subject and the predicate to which the subject tree is subordinate . 18. The system according to p. 12, characterized in that the buffers for storing elementary queries are a ring queue.

Images