JP2018124658A - Information processing device, program and information processing method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To shorten a period in which a resource is used.SOLUTION: A storage unit 1a stores data D1 to be processed by a plurality of processes contained in a query Q1. A processing unit 1b determines a monitoring object process whose processing load is estimated to be larger than a prescribed load among the plurality of processes on the basis of data D1 stored in the storage unit 1a. The processing unit 1b instructs both of a first device 2 and a second device 3 to start execution of the query Q1. The processing unit 1b obtains first progress information of the monitoring object process executed by the first device 2, and obtains second progress information of the monitoring object process executed by the second device 3. The processing unit 1b instructs stop of the execution of the query Q1 to one of the first device 2 and the second device 3 on the basis of the first progress information and the second progress information.SELECTED DRAWING: Figure 1

Description

  The present invention relates to an information processing apparatus, a program, and an information processing method.

  In the field of information processing, the scale of data to be processed is increasing. When the data to be processed becomes large, the time for data processing by a computer or the like increases. Therefore, a method of performing data processing at high speed has been considered.

  For example, in a multi-database system (MDBS: Multi DataBase System), there is a proposal of a method for reducing a query response time in data search. In this proposal, MDBS allows global access to multiple databases residing at multiple locations. The MDBS converts a query tree including a plurality of join operations for a plurality of tables scattered in various places so that each join operation can be parallelized. The MDBS shortens the query response time by executing a plurality of join operations among the data queries in parallel by the converted tree.

JP-A-8-328920

  By the way, the control device causes each of the two devices to execute a query related to data processing (a set of processing instructions), and adopts the execution result of which the execution is completed earlier, thereby shortening the response time. Conceivable.

  In this case, if an execution result is obtained by one device, the processing by the other device becomes unnecessary. Therefore, it is conceivable to stop execution of processing by the other device after the execution result is obtained. However, this method has a problem in that resources are continuously used for the processing in the other device until an execution result is obtained in one device.

  In one aspect, the present invention aims to make it possible to shorten the period during which resources are used.

  In one aspect, an information processing apparatus is provided. The information processing apparatus includes a storage unit and a processing unit. The storage unit stores data to be processed by a plurality of processes included in the query. The processing unit determines a monitoring target process in which the processing load is estimated to be larger than a predetermined load among the plurality of processes based on the data stored in the storage unit, and both the first device and the second device To start execution of the query, obtain first progress information of the monitoring target process executed by the first device, and obtain second progress information of the monitoring target processing executed by the second device Based on the first progress information and the second progress information, one of the first device and the second device is instructed to stop execution of the query.

  In one aspect, the period during which resources are used can be shortened.

It is a figure which shows the information processing apparatus of 1st Embodiment. It is a figure which shows the example of the information processing system of 2nd Embodiment. It is a figure which shows the hardware example of DB server. It is a figure which shows the function example of a system. It is a figure which shows the example of a table of DB. It is a figure which shows the example of a query. It is a figure which shows the example of a plan tree. It is a figure which shows the example of an offload selection table. It is a figure which shows the example of the difference of a scan progress rate. It is a flowchart which shows the example of a process of DB server. It is a flowchart which shows the example of query execution control. It is a flowchart which shows the example of sub control. It is a figure which shows the 1st example of query execution control. It is a figure which shows the 2nd example of query execution control. It is a figure which shows the 3rd example of query execution control. It is a figure which shows the 4th example of query execution control. It is a figure which shows the 5th example of query execution control. It is a figure which shows the 6th example of query execution control. It is a figure which shows the example of the timing of resource release. It is a figure which shows the comparative example of the timing of resource release.

Hereinafter, the present embodiment will be described with reference to the drawings.
[First Embodiment]
FIG. 1 is a diagram illustrating the information processing apparatus according to the first embodiment. The information processing device 1 is connected to the first device 2, the second device 3, the terminal device 4, and the storage device 5 via a network 6. The information processing apparatus 1 receives an input of the query Q1 from the terminal device 4. A “query” is a set of instructions indicating the processing content for data. For this reason, it can be said that the query includes a plurality of processes corresponding to a plurality of instructions. The “query” can also be expressed as “processing request”, “query request”, or “query request”.

  The information processing device 1 causes both the first device 2 and the second device 3 to execute the query Q1. The information processing apparatus 1 employs the execution result of the first apparatus 2 and the second apparatus 3 that has completed execution earlier.

  Here, for example, a difference in hardware configuration or software configuration between the two apparatuses may affect the processing speed. The first device 2 may execute the first type of data processing at a higher speed than the second device 3, or the second device 3 may execute the second type of data processing from the first device 2. Sometimes run faster. However, it is difficult to determine in advance which one of the two devices can execute a certain query at high speed. For this reason, the information processing apparatus 1 causes both the first apparatus 2 and the second apparatus 3 to execute the query Q1, acquires the execution result from the earlier completed execution, and responds to the terminal apparatus 4. . In such an operation, the information processing apparatus 1 provides a function for improving the efficiency of resource utilization by the first device 2 and the second device 3. The information processing apparatus 1 includes a storage unit 1a and a processing unit 1b.

  The storage unit 1a may be a volatile storage device such as a RAM (Random Access Memory) or a non-volatile storage device such as an HDD (Hard Disk Drive) or a flash memory. The processing unit 1b may include a CPU (Central Processing Unit), a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), and the like. The processing unit 1b may be a processor that executes a program. As used herein, the “processor” may include a set of multiple processors (multiprocessor).

  The storage unit 1a stores data to be processed (processing target data) D1 by a plurality of processes included in the query Q1. For example, the query Q1 includes processes proc1, proc2, proc3, proc4,. The processing target data D1 includes data sets d1, d2, and d3. The process proc1 is a process for the data set d1. The process proc2 is a process for the data set d2. The process proc3 is a process for the data set d3. For example, the processing target data D1 may be a part of the population of data stored in the storage device 5.

  The processing unit 1b receives an input of the query Q1 from the terminal device 4. Based on the data (processing target data D1) stored in the storage unit 1a, the processing unit 1b performs a monitoring target process in which a processing load is estimated to be larger than a predetermined load among a plurality of processes included in the query Q1. decide. One or more monitoring target processes may be performed. Further, the processing unit 1b specifies the processing target data D1 used by the plurality of processes for the query Q1 based on the received query Q1, acquires the processing target data D1 from the storage device 5, and stores it in the storage unit 1a. May be.

  Here, “processing load” means a load applied to a device that executes the corresponding process. For example, the processing unit 1b may consider the calculation cost of each of the plurality of processes as the processing load of each of the plurality of processes. The processing unit 1b can evaluate the calculation cost of each process based on the number of calculation steps for the data set to be processed and an index corresponding to the number of steps. More specifically, the processing unit 1b may use the information amount such as the number of records included in the data set as the calculation cost. This is because the calculation cost is likely to increase as the amount of information to be processed increases. The “record” is a unit of information belonging to the data set. For example, when the data set is a table, it corresponds to one row of the table.

  In one example, the “predetermined load” is determined by a threshold for the number of records. The processing unit 1b compares the number of records in each of the data sets d1, d2, and d3 with a threshold value. Here, the number of records in the data set d1 is larger than the threshold value. The number of records in the data set d2 is larger than the threshold value. The number of records in the data set d3 is smaller than the threshold value. In this case, the processing unit 1b determines that the process proc1 using the data set d1 and the process proc2 using the data set d2 are monitoring target processes.

  The processing unit 1b instructs both the first device 2 and the second device 3 to start executing the query Q1. For example, the processing unit 1b instructs the start of execution of the query Q1 by transmitting a predetermined command for instructing the start of execution of the query Q1 to both the first device 2 and the second device 3.

  When the first device 2 receives an instruction to start execution, the first device 2 starts executing the query Q1. When the second device 3 receives an instruction to start execution, the second device 3 starts executing the query Q1. Each of the plurality of processes included in the query Q1 is individually executed by the first device 2 and the second device 3, respectively. The processing unit 1b may provide the processing target data D1 to the first device 2 and the second device 3.

  The processing unit 1 b acquires first progress information of the monitoring target process executed by the first device 2. In addition, the processing unit 1 b acquires second progress information of the monitoring target process executed by the second device 3. Here, the progress information indicates, for example, the progress rate of the monitoring target process. In one example, the progress rate is n / N × 100 (%) with respect to the total number of records N and the number of processed records n of the data set used by the monitoring target process.

  For example, the processing unit 1b may acquire the first progress information by inquiring the first device 2 about the progress of the monitoring target process. Alternatively, the processing unit 1b may provide the first device 2 with records included in the data set used in the monitoring target process in order according to the progress of the monitoring target process by the first device 2. It is done. In this case, the processing unit 1b may obtain the first progress information from the record provision status with respect to the first device 2. Similarly, the processing unit 1b acquires the second progress information by making an inquiry to the second device 3. Alternatively, the processing unit 1b may acquire the second progress information from the record provision status with respect to the second device 3.

  Then, the processing unit 1b instructs one of the first device 2 and the second device 3 to stop execution of the query Q1 based on the first progress information and the second progress information. For example, based on the first progress information and the second progress information, the processing unit 1b determines whether the progress rate of all the monitoring target processes has reached 100% in one device. If the processing unit 1b determines that the progress rate of all the monitoring target processes has reached 100% in one device, the processing unit 1b instructs the other device to stop executing the query Q1. If the processing unit 1b determines that the progress rate of all the monitoring target processes has not reached 100% in one device, the processing unit 1b continues execution of the query Q1 by both devices. Note that “the progress rate of all the monitoring target processes has reached 100%” can be said to be “the execution of all the monitoring target processes has been completed”. Further, for example, the processing unit 1b transmits a predetermined instruction instructing to stop the execution of the query Q1 to one of the first device 2 and the second device 3, thereby allowing the first device to Instruct to stop execution of query Q1.

  A control example when the monitoring target process is the process proc1, proc2 is as follows. In the following description, the term “time” may be considered to represent a time range having a certain (minute) width. In the control example at the bottom of FIG. 1, the direction from the left side to the right side is the positive direction of the time axis.

  At time T1, the processing unit 1b instructs both the first device 2 and the second device 3 to start executing the query Q1. After time T1, the processing unit 1b periodically acquires first progress information for each of the monitoring target processes proc1 and proc2. In addition, the processing unit 1b periodically acquires second progress information for each of the monitoring target processes proc1 and proc2. For example, each time the processing unit 1b periodically acquires the first progress information and the second progress information, the processing unit 1b makes a stop determination related to the execution of the query Q1 based on the first progress information and the second progress information. Do. The condition for the stop determination is the above-mentioned “all monitoring target processes have been executed in one apparatus”.

  At time T2, the processing unit 1b has first progress information (referred to as “a”) of the processing proc1 performed by the first device 2 and first progress information (referred to as “b”) of the processing proc2 performed by the first device 2. To get. For example, assume that a = 50% and b = 100%. Further, at time T2, the processing unit 1b receives the first progress information (c) of the process proc1 by the second device 3 and the second progress information (d and d) of the process proc2 by the second device 3. To get). For example, suppose c = 100% and d = 100%.

  The processing unit 1b performs stop determination based on the first progress information (a, b) and the second progress information (c, d). In this case, the processing unit 1b determines that the progress rate of all the monitoring target processes has reached 100% in the second device 3. Therefore, the processing unit 1b instructs the first device 2 to stop executing the query Q1.

When receiving an instruction to stop execution of query Q1, first device 2 stops execution of query Q1. On the other hand, the second device 3 continues to execute the query Q1.
At time T3, the second device 3 completes the execution of the query Q1. The second device 3 notifies the processing unit 1b that the execution of the query Q1 has been completed. The processing unit 1b acquires the execution result of the query Q1 from the second device 3. The processing unit 1b transmits the execution result of the query Q1 to the terminal device 4. The terminal device 4 receives the execution result of the query Q1.

  Here, in the above example, it is considered that the execution of the query Q1 by the first device 2 is continued without performing the stop determination by the processing unit 1b. In this case, it is estimated that the time when the execution of the query Q1 by the first device 2 is completed is likely to be a time later than the time T3. The reason is as follows.

  The ratio of the time required for executing each process to the total time required for executing the query Q1 is considered to be larger as the process with a higher processing load (calculation cost). That is, in the case of the above example, the ratio of the required execution times of the processes proc1 and proc2 is larger than the ratio of the required execution times of the process proc3. This relationship is common to the first device 2 and the second device 3. For this reason, in the first apparatus 2 in which execution completion of both or one of the processes proc1 and proc2 (process proc1 in the above example) is delayed, the total execution time of the query Q1 is longer than that of the second apparatus 3. It is estimated that the possibility is high. Therefore, it is estimated that the time when the execution of the query Q1 by the first device 2 is completed is likely to be a time later than the time T3.

  According to such an analysis result, it is inefficient to continue the execution of the query Q1 by the first device 2 after the time T2. In particular, after the execution result of the query Q1 by the second device 3 is obtained (after time T3), it is too late to stop the execution of the query Q1 by the first device 2. The first device 2 uses extra resources for executing the processing of the query Q1, reduces the opportunity to use the first device 2 for other processing, and also adds extra resources by the first device 2. This is because extra power consumption occurs due to use. Therefore, the processing unit 1b stops the execution of the query Q1 by the first device 2 at time T2.

  As a result, the period during which resources are used for processing the query Q1 in the first device 2 can be shortened. In the example of FIG. 1, the processing of the query Q1 in the first device 2 is performed by the time difference ΔT = T3−T2 as compared with the case where the execution of the query Q1 by the first device 2 is stopped at the time T3. This makes it possible to shorten the resource usage period. As a result, the free resources of the first device 2 can be used for another process. Further, the power consumption of the first device 2 associated with the execution of the query Q1 can be reduced.

  In the example of FIG. 1, the example in which the processing unit 1b stops the execution of the query Q1 by the first device 2 is shown. However, in another query, conversely, the execution of the query by the second device 3 is stopped. The execution of the query by the first device 2 may be continued. In this case, it is possible to shorten the period of extra resource use by the second device 3.

Thus, the resources of the first device 2 and the second device 3 can be used efficiently.
The processing unit 1b extracts some processes that can be executed in the initial stage from among the plurality of processes included in the query Q1, and selects the monitoring target process from among the several processes that can be executed in the initial stage. You may decide. For example, the processing unit 1b specifies the second process that is executed earlier than the first process from the plurality of processes included in the query Q1 from the syntax of the query Q1, and sets the second process as the monitoring target process. May be determined. More specifically, it is conceivable that the query Q1 is an SQL (Structured Query Language) statement describing a query to the database. In this case, the processing unit 1b specifies a plurality of table scans performed at the beginning of a series of processes indicated by the query Q1, based on the syntax of the SQL statement, and specifies a monitoring target process from the plurality of table scans. May be. In this way, the execution stop of the query Q1 by one apparatus can be further accelerated.

  The functions of the storage unit 1a and the processing unit 1b may be provided in the first device 2 (or the second device 3). That is, the first device 2 (or the second device 3) may have the same function as the information processing device 1. The information processing device 1 and the first device 2 may be the same device). Alternatively, the information processing device 1 and the second device 3 may be the same device. In addition, the first device 2 (or the second device 3) may execute the processing of the query Q1 in a distributed manner using a plurality of other devices.

  Hereinafter, the function of the information processing apparatus 1 will be described more specifically by exemplifying a database management system (DBMS: DataBase Management System) that executes an inquiry to a relational database (RDB: Relational DataBase).

[Second Embodiment]
FIG. 2 is a diagram illustrating an example of an information processing system according to the second embodiment. The information processing system according to the second embodiment includes a database (DB) server 100, a master server 200, slave servers 300, 400, 500, and a client 600. The DB server 100 and the client 600 are connected to the network 10.

  The master server 200 and the slave servers 300, 400, 500 form a cluster 20. The cluster 20 includes a network 21. Master server 200 and slave servers 300, 400, 500 are connected to network 21. The network 21 is connected to the network 10. The networks 10 and 21 are, for example, LANs (Local Area Networks).

  The DB server 100 is a server computer having a DBMS function. The DB server 100 receives from the client 600 a query indicating the inquiry content for the DB, and executes a process corresponding to the query for the DB. The DB server 100 responds to the client 600 with the processing execution result as a response to the inquiry. The DB server 100 is connected to the storage 30. The storage 30 includes a plurality of storage devices such as HDDs and SSDs (Solid State Drives), and stores the DB using the plurality of storage devices. The storage 30 may be externally attached to the DB server 100 (directly or via a network), or may be built in the DB server 100.

  The cluster 20 is a subsystem that is used for DB access together with the DB server 100. The master server 200 in the cluster 20 receives a query execution instruction and data to be processed according to the query from the DB server 100 and allocates processing to the slave servers 300, 400, and 500. The slave servers 300, 400, and 500 execute the process allocated by the master server 200 and transmit the execution result to the master server 200. The master server 200 receives the execution results from each of the slave servers 300, 400, and 500, merges a plurality of execution results, and transmits the execution results after merging to the DB server 100.

  A client 600 is a client computer used by a user. The client 600 receives a query input from the user and transmits the input query to the DB server 100. The user inputs a query to the client 600 using SQL. The client 600 receives the execution result of the query from the DB server 100, and displays the received execution result on the display.

  Here, in the information processing system according to the second embodiment, the DB access processing of the DB server 100 can also be executed by the cluster 20. That is, the DB server 100 can offload its own processing to the cluster 20. The load on the DB server 100 can be reduced by offloading. The DB server 100 is a server having a DBMS that manages a DB, and is sometimes called native. One example of software that provides a native DBMS function is PostgreSQL (however, other software may be used). The native-side DB server may be composed of a plurality of server computers (for example, the native-side DB server may be used to distribute load and improve availability). The cluster 20 is an offload destination subsystem and may be called an accelerator. An example of software that provides an accelerator function is Spark (however, other software may be used).

  The DB server 100 can speed up the processing by allocating (offloading) processing (referred to as query processing) corresponding to the query to the cluster 20. However, not all query processing needs to be offloaded. For example, the DB server 100 may be able to execute processing at a higher speed than the cluster 20 depending on the size of the table to be subjected to query processing and the type of processing for the table (for example, whether or not index scanning is performed). .

  Specifically, in the cluster 20, when the query process is a process for a relatively large table, or when an index scan is not used (in the case of a sequential scan), the process can be executed faster than the DB server 100. there is a possibility. This is because sequential processing for a large amount of data can be efficiently executed by being shared by a plurality of slave servers of the cluster 20. On the other hand, in the DB server 100, there is a possibility that the process can be executed faster than the cluster 20 when the query process is a process for a relatively small size table or when an index scan is used. This is because when the data size to be processed is relatively small, the overhead of processing for distribution in the cluster 20 can be larger than the original processing. However, the algorithm used by the cluster 20 is often a black box. For this reason, it is difficult to evaluate in advance which one of the DB server 100 (native) and the cluster 20 (accelerator) can execute processing at a high speed for a specific query.

The DB server 100 provides a function for improving the response performance to a query in consideration of such properties in the DB server 100 and the cluster 20.
FIG. 3 is a diagram illustrating a hardware example of the DB server. The DB server 100 includes a processor 101, a RAM 102, an HDD 103, an HBA (Host Bus Adapter) 104, an image signal processing unit 105, an input signal processing unit 106, a medium reader 107, and a communication interface 108. Each hardware is connected to the bus of the DB server 100.

  The processor 101 is hardware that controls information processing of the DB server 100. The processor 101 may be a multiprocessor. The processor 101 is, for example, a CPU, DSP, ASIC, or FPGA. The processor 101 may be a combination of two or more elements of CPU, DSP, ASIC, FPGA, and the like.

  The RAM 102 is a main storage device of the DB server 100. The RAM 102 temporarily stores at least part of an OS (Operating System) program and application programs to be executed by the processor 101. The RAM 102 stores various data used for processing by the processor 101.

  The HDD 103 is an auxiliary storage device of the DB server 100. The HDD 103 magnetically writes and reads data to and from the built-in magnetic disk. The HDD 103 stores an OS program, application programs, and various data. The DB server 100 may include other types of auxiliary storage devices such as flash memory and SSD, or may include a plurality of auxiliary storage devices.

  The HBA 104 is a connection interface used for connection with the storage 30. The HBA 104 is, for example, a fiber channel (FC) or SAS (Serial Attached SCSI, SCSI is an abbreviation for Small Computer System Interface) interface.

  The image signal processing unit 105 outputs an image to the display 11 connected to the DB server 100 in accordance with an instruction from the processor 101. As the display 11, a CRT (Cathode Ray Tube) display, a liquid crystal display, or the like can be used.

  The input signal processing unit 106 acquires an input signal from the input device 12 connected to the DB server 100 and outputs it to the processor 101. As the input device 12, for example, a pointing device such as a mouse or a touch panel, a keyboard, or the like can be used.

  The medium reader 107 is a device that reads a program and data recorded on the recording medium 13. As the recording medium 13, for example, a magnetic disk such as a flexible disk (FD) or an HDD, an optical disk such as a CD (Compact Disc) or a DVD (Digital Versatile Disc), or a magneto-optical disk (MO) is used. Can be used. Further, as the recording medium 13, for example, a non-volatile semiconductor memory such as a flash memory card can be used. For example, the medium reader 107 stores a program or data read from the recording medium 13 in the RAM 102 or the HDD 103 in accordance with an instruction from the processor 101.

  The communication interface 108 communicates with other devices via the network 10. The communication interface 108 may be a wired communication interface or a wireless communication interface.

The master server 200, the slave servers 300, 400, 500, and the client 600 can also be realized using the same hardware as the DB server 100.
FIG. 4 is a diagram illustrating an example of functions of the system. The DB server 100 includes a storage unit 110, a communication processing unit 120, a progress monitoring unit 130, a query execution unit 140, and a cooperation control unit 150.

  The storage unit 110 stores information related to the progress of query processing. The storage unit 110 also stores information (offload selection table) used for determining whether to perform offloading.

The communication processing unit 120 receives a query from the client 600. In addition, the communication processing unit 120 transmits the execution result of the query process to the client 600.
The progress monitoring unit 130 determines a monitoring target process to be monitored for progress among a plurality of processes included in the query according to the content of the query. The progress monitoring unit 130 monitors the progress of the monitoring target process by the DB server 100 and the progress of the monitoring target process by the cluster 20. The progress monitoring unit 130 controls to stop the query processing by either one according to the progress of the monitoring target process by the DB server 100 and the progress of the monitoring target process by the cluster 20. Specifically, the progress monitoring unit 130 obtains the execution result of one of the DB server 100 and the cluster 20 that has executed the monitoring target process earlier, and controls to stop the query process by the other.

  The progress monitoring unit 130 acquires the data of the table to be subjected to query processing from the DB 31 stored in the storage 30 and provides the data to the query execution unit 140 and the cooperation control unit 150. In addition, the progress monitoring unit 130 acquires the execution result of the query processing by the query execution unit 140 and the cooperation control unit 150 and provides the result to the communication processing unit 120.

The query execution unit 140 executes query processing. The query execution unit 140 is an SQL execution engine in the DBMS.
The cooperation control unit 150 controls cooperation with the cluster 20. The cooperation control unit 150 requests the master server 200 to execute query processing. The cooperation control unit 150 provides the master server 200 with data of the table to be processed by the query processing. In addition, the cooperation control unit 150 acquires the execution result of the query process from the master server 200.

  The master server 200 has a distributed control unit 210. The distribution control unit 210 controls distributed execution of queries using the slave servers 300, 400, and 500. The distribution control unit 210 receives the query processing request and the query processing target table data from the cooperation control unit 150, and allocates each part of the query processing to each of the slave servers 300, 400, and 500. For example, the distributed control unit 210 can speed up the query processing by allocating different portions of the query processing to the slave servers 300, 400, and 500, respectively. The distribution control unit 210 acquires query processing execution results from the slave servers 300, 400, and 500 and merges them. The distribution control unit 210 responds to the cooperation control unit 150 with the execution result after merging.

  The slave server 300 includes a distributed execution unit 310. The slave server 400 has a distributed execution unit 410. The slave server 500 has a distributed execution unit 510. The distributed execution units 310, 410, and 510 execute part of the query processing allocated by the distribution control unit 210, and return an execution result to the distribution control unit 210. Note that the master server 200 may also have the function of a distributed execution unit.

  Here, the storage unit 110 is realized as a storage area secured in the RAM 102 or the HDD 103. The functions of the communication processing unit 120, the progress monitoring unit 130, the query execution unit 140, and the cooperation control unit 150 are exhibited when the processor 101 executes a program stored in the RAM 102. However, the communication processing unit 120, the progress monitoring unit 130, the query execution unit 140, and the cooperation control unit 150 may be realized by a hard wired logic such as an FPGA or an ASIC.

  Furthermore, the function of the distributed control unit 210 is exhibited when a processor included in the master server 200 executes a program stored in a RAM included in the master server 200. The functions of the distributed execution unit 310 are exhibited when a processor included in the slave server 300 executes a program stored in a RAM included in the slave server 300. The function of the distributed execution unit 410 is exhibited when a processor included in the slave server 400 executes a program stored in a RAM included in the slave server 400. The functions of the distributed execution unit 510 are exhibited when a processor included in the slave server 500 executes a program stored in a RAM included in the slave server 500.

  FIG. 5 is a diagram illustrating an example of a DB table. The DB 31 includes tables 31a, 31b, 31c, 31d,. FIG. 5 illustrates the contents of the tables 31 a and 31 b among the plurality of tables included in the DB 31.

  The table name of the table 31a is “tbl1”. The table 31a includes items (or attributes) of name and age. The name of the person is registered in the name item. The age of a person is registered in the item “age”. For example, a row (or tuple) in which name is “Alice” and age is “31” is registered in the table 31a. This indicates that the age of the person “Alice” is “31” years old. One row may be referred to as one record.

  The table name of the table 31b is “tbl2”. The table 31b includes items of name and state. The name of the person is registered in the name item. In the “state” item, a local abbreviation to which the person belongs is registered. For example, in the table 31b, a line where name is “Alice” and state is “NY” is registered. This indicates that the local abbreviation to which the person “Alice” belongs is “NY” (New York).

It is assumed that the table name of the table 31c is “tbl3”. Further, the table name of the table 31d is assumed to be “tbl4”.
FIG. 6 is a diagram illustrating an example of a query. The query 40 is described using SQL. The query 40 includes a plurality of commands corresponding to a plurality of processes. The query 40 is an operation of joining the tables 31a and 31b with the name and taking out (selecting) a row (a set of name, age, and state) whose age is “40” or more from the joined table. In the example of the query 40, the progress monitoring unit 130 generates a plan tree of the query 40 using the SQL syntax. The plan tree is information that represents a query execution plan.

  FIG. 7 is a diagram illustrating an example of a plan tree. The plan tree 50 is a plan tree corresponding to the query 40. The plan tree 50 includes nodes 51, 52, 53, and 54. Each of the nodes 51 and 52 is connected to the node 53 by an edge. The node 53 is connected to the node 54 at the edge.

  The node 51 represents a scan of a row that is age “40” or more with respect to the table 31a. Here, “scan” is a process of extracting from the table the rows that match the corresponding condition (or all rows if there is no condition). The node 52 represents a full scan (scan of all rows) for the table 31b. The node 53 represents a join operation (JOIN) by name for the scan results of the nodes 51 and 52. The node 54 represents a name, age, and state selection operation (SELECT) for the combined result. Nodes 51 and 52 are called leaves or leaf nodes.

  According to the plan tree 50, when the query 40 is executed by the DB server 100 or the cluster 20, first, the scans of the tables 31a and 31b (corresponding to the nodes 51 and 52) are executed. Next, a join operation (corresponding to the node 53) is executed. Thereafter, a selection operation (corresponding to the node 54) is executed. Note that which type (index scan or sequential scan) of the tables 31a and 31b is to be scanned is determined by the query execution unit 140 and the distribution control unit 210 according to the contents of the query. For the same query, the query execution unit 140 and the distribution control unit 210 employ the same type of scan.

  Here, in the query processing for the DB, the table scan tends to have a higher operation cost than the join operation or the selection operation. For example, some tables include tens of thousands to tens of millions of rows, and a large amount of data can be scanned. Accordingly, the progress monitoring unit 130 identifies a table scan with a relatively large load from the plan tree 50 and sets it as a monitoring target. At this time, the progress monitoring unit 130 further narrows down the table scans to be monitored among the plurality of table scans included in the plan tree 50 based on the information amount of the table to be scanned.

  Specifically, the progress monitoring unit 130 sets a table having the largest size among a plurality of tables to be processed by the query as a reference table. The progress monitoring unit 130 determines a table that satisfies the following condition (1) or condition (2) among the plurality of tables as a monitoring target table. Here, “maximum size” indicates “maximum number of rows”.

The condition (1) is “to be a table of maximum number of rows (reference table)”.
The condition (2) is “threshold Y = (number of rows in the table with the maximum number of rows X) * the table having the number of rows equal to or more than the cost value C”). Here, as the cost value C, for example, the ratio of the calculation cost of the index scan to the calculation cost of the sequential scan can be considered. For example, if the calculation cost of the index scan is “0.005” when the calculation cost of the sequential scan is “1.0”, the cost value C is “0.005”.

  As an example, consider a case where the table 31a has 10 million rows and the table 31b has 50,000 rows. In this case, according to the plan tree 50, scanning by the tables 31a and 31b is included. Among these, the table with the maximum number of rows is the table 31a. The maximum number of rows X is 10 million. Therefore, the threshold Y = XC = 10 million * 0.005 = 50,000. In this case, since the number of rows in the table 31b is 50,000, it is equal to or greater than the threshold Y and satisfies the condition (2). Therefore, the progress monitoring unit 130 determines the tables 31a and 31b as monitoring target tables.

  A table scan for the monitoring target table corresponds to monitoring target processing. That is, it can be said that the progress monitoring unit 130 determines the monitoring target process by determining the monitoring target table.

  FIG. 8 is a diagram illustrating an example of an offload selection table. The offload selection table 111 is stored in the storage unit 110. The offload selection table 111 includes items of a use table, a scan type, a scan progress rate difference, and an offload selection flag.

  In the use table field, the table name of the monitoring target table in the query executed in the past is registered. The scan type used in the table scan for the monitoring target table is registered in the scan type item. The scan type “seq” represents a sequential scan. The scan type “ind” represents an index scan. In the item of the difference in scan progress rate, the final difference between the scan progress rate of the DB server 100 and the scan progress rate of the cluster 20 with respect to the monitoring target table is registered. The scan progress rate is the ratio (percentage) of the number of scanned rows out of the total number of rows in the table to be scanned. The difference between the scan progress rates is “(accelerator progress rate) − (native progress rate)”. Therefore, if the difference in scan progress rate is a positive value (all positive), the accelerator side has completed the monitoring target process earlier. On the other hand, if the difference in the scan progress rate is negative (all negative), the native side has completed the monitoring target process earlier. In the item of the offload selection flag, a flag indicating whether or not to perform offloading from the next time is registered. The offload selection flag “TRUE” indicates that offloading is performed. “Perform offload” indicates that the corresponding query process is allocated to the cluster 20 and the DB server 100 does not execute the query process. The offload selection flag “FALSE” indicates that offloading is not performed. “Do not perform offload” indicates that the DB server 100 executes the query process without allocating the query process to the cluster 20. It can be said that the offload selection flag is identification information that can identify one of the DB server 100 and the cluster 20 that has instructed the execution stop of the query in the record of the corresponding row.

  Here, a plurality of values (the number of values is the same for each item) can be registered in the items of the difference between the usage table, the scan type, and the scan progress rate. When a plurality of values are registered in the items of the difference between the usage table, the scan type, and the scan progress rate, the plurality of values are associated in order.

  For example, in the offload selection table 111, the usage table is “tbl1, tbl2, tbl3”, the scan type is “seq, ind, seq”, the difference in scan progress rate is “30, 20, 50”, the offload selection flag Is registered as “TRUE”.

  This is because a query including a table scan for the three monitoring target tables having the table names “tbl1” (table 31a), “tbl2” (table 31b), and “tbl3” (table 31c) has been executed in the past. Indicates. This result shows that the sequential scan is executed on the table 31a and the difference in scan progress rate is “30”. In addition, the result shows that an index scan is performed on the table 31b, and the difference in scan progress rate is “20”. Further, the result shows that the sequential scan is executed on the table 31c, and the difference in the scan progress rate is “50”. Then, after the next time, when a query for performing a sequential scan with respect to the table 31a, an index scan with respect to the table 31b, and a sequential scan with respect to the table 31c is received, it indicates that offloading is performed.

  Further, for example, in the offload selection table 111, the usage table is “tbl2, tbl3”, the scan type is “ind, ind”, the difference in scan progress rate is “−30, −50”, and the offload selection flag is “ The information “FALSE” is registered.

  This indicates that there has been a past execution result of a query including a table scan for the monitoring target table with respect to the two tables having the table names “tbl2” (table 31b) and “tbl3” (table 31c). The result shows that the index scan is executed on the table 31b and the difference in scan progress rate is “−30”. In addition, the result shows that the index scan is performed on the table 31c, and the difference in the scan progress rate is “−50”. Then, when a query for performing an index scan for the table 31b and an index scan for the table 31c is received after the next time, it indicates that offloading is not performed.

  FIG. 9 is a diagram illustrating an example of a difference in scan progress rate. The progress monitoring unit 130 obtains a difference between final progress rates of the DB server 100 (native) and the cluster 20 (accelerator) with respect to a query that has been executed in the past. As described above, the difference between the progress rates is “(accelerator progress rate) − (native progress rate)”. Therefore, if the difference in the final progress rate of the monitoring target process is positive (if there are a plurality of monitoring target processes, all are positive), the processing by the accelerator is faster than the processing by the native. On the other hand, if the difference in the final progress rate of the monitoring target process is negative (all negative when there are a plurality of monitoring target processes), the native process is faster than the accelerator process.

  In the following, an example in which the difference in scan progress rate is “(accelerator progress rate) − (native progress rate)” is shown, but “(native progress rate) − (accelerator progress rate)” is also shown. Good. In this case, the interpretation of the positive value and the negative value of the difference in scan progress rate is reversed.

Next, a processing procedure by the DB server 100 will be described.
FIG. 10 is a flowchart illustrating an example of processing of the DB server. In the following, the process illustrated in FIG. 10 will be described in order of step number.

(S1) The communication processing unit 120 receives a query from the client 600.
(S2) The progress monitoring unit 130 acquires the query received by the communication processing unit 120 and performs query execution control. Details of the processing will be described later. The progress monitoring unit 130 acquires the execution result of the query by the DB server 100 or the cluster 20 by query execution control, and provides it to the communication processing unit 120.

(S3) The communication processing unit 120 transmits a query execution result to the client 600.
FIG. 11 is a flowchart illustrating an example of query execution control. In the following, the process illustrated in FIG. 11 will be described in order of step number. The following procedure corresponds to step S2 in FIG.

  (S11) The progress monitoring unit 130 creates a plan tree based on the SQL syntax of the query, and identifies a table (used table) used in the table scan based on the plan tree. The progress monitoring unit 130 acquires a usage table from the DB 31 stored in the storage 30. The progress monitoring unit 130 stores the acquired use table in the storage unit 110.

  (S12) The progress monitoring unit 130 determines a use table having a predetermined number of rows or more as a monitoring target table. Specifically, the progress monitoring unit 130 determines a table that satisfies the following condition (1) or condition (2) as a monitoring target table as described above. The condition (1) is “to be a table of maximum number of rows (reference table)”. The condition (2) is “threshold Y = (number of rows in the table with the maximum number of rows X) * the table having the number of rows equal to or more than the cost value C”).

  (S13) The progress monitoring unit 130 identifies the scan type of the monitoring target table. When there are a plurality of monitoring target tables, the progress monitoring unit 130 identifies a scan type for each monitoring target table. The scan type is determined by the query execution unit 140 (or a predetermined function of the DBMS) according to the content of the query. The progress monitoring unit 130 may acquire the scan type by inquiring of the query execution unit 140 (or a predetermined function of the DBMS) about the scan type selected for the monitoring target table.

  (S14) The progress monitoring unit 130 refers to the offload selection table 111 stored in the storage unit 110, and the offload selection table 111 has a tuple that completely matches the processing content of the current query (referred to as a complete match tuple). It is determined whether or not there is. Here, the processing contents are a monitoring target table and a scan type. When all the monitoring target tables are the same as the current query and the scan types for the respective monitoring target tables are all the same as the current query, the offload selection table 111 has a complete match tuple. If there is a complete match tuple in the offload selection table 111, the progress monitoring unit 130 proceeds to step S15. If there is no complete match tuple in the offload selection table 111, the progress monitoring unit 130 proceeds to step S16.

  (S15) The progress monitoring unit 130 instructs the request destination according to the offload selection flag in the complete match tuple of the offload selection table 111 to start executing query processing. Specifically, when the corresponding offload selection flag is “FALSE”, the progress monitoring unit 130 instructs the query execution unit 140 to start executing query processing. Further, when the corresponding offload selection flag is “TRUE”, the progress monitoring unit 130 instructs the cooperation control unit 150 to send an instruction to start execution of query processing to the master server 200. Then, the progress monitoring unit 130 proceeds with the process to step S21.

  (S16) The progress monitoring unit 130 refers to the offload selection table 111 and determines whether the offload selection table 111 has a tuple that partially matches the processing content of the current query (referred to as a partial match tuple). . Of the rows of the offload selection table 111, the usage table is a part of the current query monitoring target table, and the scan type for the usage table is the same as the scan type for the monitoring target table corresponding to the current query part. Is a partially matched tuple. If there is a partial match tuple in the offload selection table 111, the progress monitoring unit 130 proceeds with the process to step S17. If there is no partial match tuple in the offload selection table 111, the progress monitoring unit 130 proceeds to step S18. Note that the past performance monitoring target process corresponding to the partial match tuple can be said to be the first part of the plurality of monitoring target processes in the current query. On the other hand, it can be said that the second part other than the first part of the plurality of monitoring target processes in the current query is a new part.

(S17) The progress monitoring unit 130 executes sub-control in query execution control. Details of the sub-control will be described later. Then, the progress monitoring unit 130 proceeds with the process to step S20.
(S18) The progress monitoring unit 130 instructs both the native (DB server 100) and the accelerator (cluster 20) to start executing query processing, and starts acquiring the progress information of both. Specifically, the progress monitoring unit 130 instructs the query execution unit 140 to start executing query processing. In addition, the progress monitoring unit 130 instructs the cooperation control unit 150 to send an instruction to start execution of query processing to the master server 200. The progress monitoring unit 130 also provides a query processing usage table to the query execution unit 140 and the cooperation control unit 150. The query execution unit 140 executes query processing based on the provided usage table. The cooperation control unit 150 transmits an instruction to start executing query processing and the provided usage table to the master server 200.

  (S19) The progress monitoring unit 130 instructs the other to stop the execution of the query process when one of the scans for all the monitoring target tables identified in step S13 is completed. For example, it is assumed that the query execution unit 140 completes scanning of all the monitoring target tables before the cluster 20. In this case, the progress monitoring unit 130 instructs the cooperation control unit 150 to send a query processing execution stop instruction to the master server 200. In response to the instruction, the cooperation control unit 150 transmits an instruction to stop execution of query processing to the master server 200. For example, it is assumed that the cluster 20 has completed scanning of all the monitoring target tables before the query execution unit 140. In this case, the progress monitoring unit 130 instructs the query execution unit 140 to stop execution of query processing. The query execution unit 140 stops the execution of the corresponding query process in response to the instruction.

  (S20) The progress monitoring unit 130 registers the current performance in the offload selection table 111. Specifically, the progress monitoring unit 130 registers the current query use table and scan type in the offload selection table 111. Further, the progress monitoring unit 130 calculates the difference between the scan progress rates based on both final scan progress rates in step S19 (all of the scan progress rates for the monitoring target table are 100%), and performs offloading. Register in the selection table 111. The difference between the scan progress rates is “(accelerator progress rate) − (native progress rate)”. Accordingly, the progress monitoring unit 130 registers the offload selection flag “TRUE” in the offload selection table 111 when all the differences in the scan progress rates are positive values. In addition, the progress monitoring unit 130 registers an offload selection flag “FALSE” in the offload selection table 111 when all the scan progress rate differences are negative values.

  (S21) The progress monitoring unit 130 acquires the execution result of the query process from the query execution unit 140 or the cooperation control unit 150 that has completed the execution of the query process, and provides the acquired execution result to the communication processing unit 120. . Then, the progress monitoring unit 130 ends the query execution control process. Here, the execution result of the query process acquired from the cooperation control unit 150 is the execution result of the query process by the cluster 20 acquired from the master server 200 by the cooperation control unit 150.

  Here, in step S <b> 18, for example, the progress monitoring unit 130 may obtain the scan progress rate by the query execution unit 140 by inquiring the query execution unit 140 about the progress of the table scan for the monitoring target table. Further, the progress monitoring unit 130 may obtain the scan progress rate by the cluster 20 by inquiring the cluster 20 via the cooperation control unit 150 about the progress of the table scan for the monitoring target table.

  Alternatively, the progress monitoring unit 130 may provide the query execution unit 140 with the records included in the monitoring target table in order according to the progress of the table scan by the query execution unit 140. In this case, the progress monitoring unit 130 may obtain the scan progress rate by the query execution unit 140 from the record provision status to the query execution unit 140. In addition, the progress monitoring unit 130 may provide the records included in the monitoring target table in order to the cluster 20 via the cooperation control unit 150 according to the progress of the table scan by the cluster 20. In this case, the progress monitoring unit 130 may acquire the scan progress rate by the cluster 20 from the record provision status for the cluster 20.

FIG. 12 is a flowchart illustrating an example of sub-control. In the following, the process illustrated in FIG. 12 will be described in order of step number. The following procedure corresponds to step S17 in FIG.
(S31) The progress monitoring unit 130 instructs both the native (DB server 100) and the accelerator (cluster 20) to start executing query processing. Specifically, the progress monitoring unit 130 instructs the query execution unit 140 to start executing query processing. In addition, the progress monitoring unit 130 instructs the cooperation control unit 150 to send an instruction to start execution of query processing to the master server 200. The progress monitoring unit 130 also provides a query processing usage table to the query execution unit 140 and the cooperation control unit 150. The query execution unit 140 executes query processing based on the provided usage table. The cooperation control unit 150 transmits an instruction to start executing query processing and the provided usage table to the master server 200.

  (S32) The progress monitoring unit 130 monitors table scans for a plurality of monitoring target tables in two parts, a partially matched part and a new part with respect to past results, and acquires a scan progress rate for each monitoring target table. To start.

  (S33) The progress monitoring unit 130 determines whether the scan progress rate of the partially matching portion has reached 100% before the new portion in both the native and the accelerator. When the scan progress rate of the partially matching part reaches 100% before the new part in both the native and the accelerator, the progress monitoring unit 130 advances the process to step S34. If the scan progress rate of the partially matching part has not reached 100% before the new part in both the native and the accelerator, the progress monitoring unit 130 advances the process to step S35.

  Note that either or both of the partially matching part and the new part may include table scans (monitoring target processing) for a plurality of monitoring target tables. For example, when the partially matching portion includes a plurality of table scans for a plurality of monitoring target tables, the progress monitoring unit 130 scans the partially matching portion when all the scan progress rates of the plurality of table scans become 100%. The progress rate is considered to be 100%. The same applies to the new part.

  (S34) The progress monitoring unit 130 instructs the execution stop of the query processing to the lower of the scan progress rate of the new part among the native and the accelerator. When there are a plurality of scan progress rates to be considered, the progress monitoring unit 130 may instruct the lowering of the average value of the scan progress rates to stop execution of query processing. For example, when the cluster 20 has a lower scan progress rate of the new part, the progress monitoring unit 130 instructs the cooperation control unit 150 to send an instruction to stop executing query processing to the master server 200. In response to the instruction, the cooperation control unit 150 transmits an instruction to stop execution of query processing to the master server 200. Further, for example, when the query execution unit 140 has a lower scan progress rate of the new part, the progress monitoring unit 130 instructs the query execution unit 140 to stop executing the query process. In response to the instruction, the query execution unit 140 stops executing the corresponding query process. Then, the progress monitoring unit 130 ends the process.

  (S35) The progress monitoring unit 130 determines whether or not the scan progress rate of the new part has reached 100% before the partial matching part in at least one of the native and the accelerator. If the scan progress rate of the new part reaches 100% before the partially matched part in at least one of the native and the accelerator, the progress monitoring unit 130 advances the process to step S36. If the scan progress rate of the new part has not reached 100% before the partially matched part in at least one of the native and the accelerator, the progress monitoring unit 130 proceeds to step S33 (continues monitoring of the scan progress rate) To do).

  Note that either or both of the partially matching part and the new part may include table scans (monitoring target processing) for a plurality of monitoring target tables. For example, when the partially matching portion includes a plurality of table scans for a plurality of monitoring target tables, the progress monitoring unit 130 scans the partially matching portion when all the scan progress rates of the plurality of table scans become 100%. The progress rate is considered to be 100%. The same applies to the new part.

  (S36) The progress monitoring unit 130 determines whether or not the absolute value of the difference in the current scan progress rate is greater than or equal to the absolute value of the difference in scan progress rate in the partial match tuple of the offload selection table 111 stored in the storage unit 110. Determine whether. If the absolute value of the current scan progress rate difference is equal to or greater than the absolute value of the scan progress rate difference in the partial match tuple, the progress monitoring unit 130 proceeds to step S37. When the absolute value of the current scan progress rate difference is not equal to or greater than the absolute value of the scan progress rate difference in the partial match tuple, the progress monitoring unit 130 proceeds to step S33 (continues monitoring of the scan progress rate). Here, when there are a plurality of partial match tuples, the progress monitoring unit 130 selects a partial match tuple having the largest number of matching monitoring target tables.

  There may be a plurality of scan progress rate differences to be considered. In this case, the progress monitoring unit 130 determines that the absolute value of all the current scan progress rate differences is equal to or greater than the absolute value of the scan progress rate differences of the corresponding partial match tuples. In this case, step S36 is No.

  Further, the progress monitoring unit 130 may confirm the coincidence between the sign (positive or negative) of the difference in the current scan progress rate and the sign (positive or negative) of the difference in the scan progress rate in the partial match tuple. The progress monitoring unit 130 may compare the absolute values of both differences if the signs match, and may proceed to step S33 if the signs do not match.

  (S37) The progress monitoring unit 130 determines that the request destination where the scan progress rate of the new part has reached 100% is the execution continuation destination specified by the offload selection flag of the partial match tuple (stops query processing based on past results) Judgment is made whether or not it matches. If they match, the progress monitoring unit 130 proceeds to step S38. If they do not match, the progress monitoring unit 130 proceeds to step S33 (continues to monitor the scan progress rate).

  (S38) The progress monitoring unit 130 instructs the execution stop of the query processing to the one with the lower scan progress rate of the partially matched portion. When there are a plurality of scan progress rates to be considered, the progress monitoring unit 130 may instruct the lowering of the average value of the scan progress rates to stop execution of query processing. Here, it is expected that an instruction to stop execution will be given to a direction different from the execution continuation destination specified in step S37. For example, when instructing to stop execution of query processing by the cluster 20, the progress monitoring unit 130 instructs the cooperation control unit 150 to send an instruction to stop execution of query processing to the master server 200. In response to the instruction, the cooperation control unit 150 transmits an instruction to stop execution of query processing to the master server 200. When the query processing by the query execution unit 140 is stopped, the progress monitoring unit 130 instructs the query execution unit 140 to stop execution of the corresponding query process. In response to the instruction, the query execution unit 140 stops executing the corresponding query process. Then, the progress monitoring unit 130 ends the sub control process.

  Here, it can be said that the determinations in steps S36 and S37 are processes for confirming that past results can be used for the scan progress rate of the current table scan in the partially matched portion. In other words, if the monitoring target process corresponding to the new part is completed in both the native and accelerator, the query execution of either the native or accelerator is executed based on the past results for the monitoring target process corresponding to the partial matching part. It is possible to stop.

  At this time, when the monitoring target process for the new part is completed by the person who has not stopped the query execution in the past results (which can be specified by the offload selection flag of the partial match tuple), the partial match tuple is indicated. The result may be diverted to this query processing. For the monitoring target process corresponding to the partially matched part that is not completed in the current query, the execution subject side (execution destination) that did not stop the query execution specified by the offload selection flag in the past results, This is because it is estimated that the execution can be completed earlier than the other.

  Therefore, in this case, the progress monitoring unit 130 determines that the partial match portion is larger when the absolute value of the current scan progress rate difference with respect to the partial match portion is larger than the absolute value of the scan progress rate difference with respect to the partial match portion. Is instructed to stop the execution of query processing to the one with the lower scan progress rate. This is because it is considered that the results of partial match tuples may be applied if the width of the difference in the progress rate this time is greater than the past results.

  At this time, “the one with the lower scan progress rate of the partially matched portion” in step S38 is the one in which the query execution is stopped based on the past results indicated by the offload selection flag of the partially matched tuple (in this example, the offload selection is selected). The flag “FALSE” is expected to match the native, and the same “TRUE” to the accelerator). Further, as exemplified in step S36, when the coincidence of the signs of the scan progress rate differences is also confirmed in step S36, “the lower scan progress rate of the partially matched portion” is the offload selection flag of the partially matched tuple. It matches the person who stopped query execution in the past results shown by.

The execution order of steps S36 and 37 may be reversed.
Next, a specific example of query execution control by the DB server 100 according to the above procedure will be described.
FIG. 13 is a diagram illustrating a first example of query execution control. The direction from the left side to the right side in FIG. 13 is the positive direction of the time axis (the same applies to the following drawings).

  At time T <b> 11, the DB server 100 receives a query input from the client 600. It is assumed that the record corresponding to the content of the corresponding query has not yet been recorded in the offload selection table 111. The DB server 100 creates a plan tree from the query and determines a monitoring target table. Here, it is assumed that the monitoring target tables are the tables 31a and 31b. The DB server 100 instructs both the query execution unit 140 (native DBMS) and the cluster 20 (accelerator) of the DB server 100 to start executing the accepted query. When the query execution unit 140 receives an instruction to start execution, the query execution unit 140 starts executing the query. When the cluster 20 receives an instruction to start execution, the cluster 20 starts executing the query. The DB server 100 starts monitoring the progress of table scans of the tables 31a and 31b by the query execution unit 140 and the cluster 20, respectively.

  At time T12, the DB server 100 detects the scan progress rate 60% of the table 31a and the scan progress rate 100% of the table 31b for the query execution unit 140. Further, the DB server 100 detects the scan progress rate 100% of the table 31a and the scan progress rate 100% of the table 31b for the cluster 20. For this reason, the DB server 100 instructs the query execution unit 140 to stop executing the corresponding query. The query execution unit 140 stops executing the corresponding query. The cluster 20 continues to execute the corresponding query.

At time T13, the cluster 20 completes the execution of the query. The DB server 100 acquires a query execution result from the cluster 20 and transmits it to the client 600.
Thus, the DB server 100 can stop the query processing in the DB server 100 at time T12. As a result, the resource for the query processing in the DB server 100 can be released at the stage of time T12.

  FIG. 14 is a diagram illustrating a second example of query execution control. In the example of FIG. 14, it is assumed that the contents of the query input to the DB server 100 include a sequential scan for the table 31a (table name “tbl1”) and a sequential scan for the table 31c (table name “tbl3”). The monitoring target tables are assumed to be tables 31a and 31c.

  Furthermore, it is assumed that past results (complete match tuples for input queries) of queries that have been subjected to sequential scan for the table 31a and sequential scan for the table 31c are registered in the offload selection table 111. For example, the DB server 100 performs the following control.

  At time T <b> 21, the DB server 100 receives a query input from the client 600. The DB server 100 specifies that the query includes a sequential scan for each of the tables 31a and 31c. Further, the DB server 100 determines the monitoring target tables in the query as the tables 31a and 31c. The DB server 100 refers to the offload selection table 111 and identifies a row corresponding to the results of a query that has performed a sequential scan on the table 31a and a sequential scan on the table 31c. The identified row is an exact match tuple for the entered query content. Then, the DB server 100 specifies that the offload selection flag set in the specified row is “TRUE”.

  For this reason, the DB server 100 instructs the cluster 20 to start executing the currently accepted query. Further, the DB server 100 does not instruct the DB server 100 to start executing the query. Therefore, the DB server 100 does not execute the query from the beginning.

At time T22, the cluster 20 completes the execution of the query. The DB server 100 acquires a query execution result from the cluster 20 and transmits it to the client 600.
As described above, the DB server 100 can also perform control so as not to instruct execution of a query to either the DB server 100 or the cluster 20 based on the past results. Thereby, execution of the unnecessary process by the DB server 100 can be suppressed. As a result, it is possible to suppress the use of extra resources in the DB server 100 by the processing.

  FIG. 15 is a diagram illustrating a third example of query execution control. In the example of FIG. 15, the contents of the query input to the DB server 100 include an index scan for the table 31b (table name “tbl2”), an index scan for the table 31c (table name “tbl3”), and a table 31d (table Assume that a sequential scan for the name “tbl4”) is included. Assume that the monitoring target tables are tables 31b, 31c, and 31d.

  In addition, past results of queries that have been index-scanned for each of the tables 31b and 31c and a sequential scan for the table 31d (a complete match tuple for the contents of the input query) are not registered in the offload selection table 111. Shall. Furthermore, it is assumed that the past results (partial match tuples for the contents of the input query) of the queries that have performed the index scan on the table 31b and the index scan on the table 31c are registered in the offload selection table 111. For example, the DB server 100 performs the following control.

  At time T <b> 31, the DB server 100 accepts a query input from the client 600. The DB server 100 specifies that the query includes an index scan for each of the tables 31b and 31c and a sequential scan for the table 31d. Further, the DB server 100 determines the monitoring target tables in the query as the tables 31b, 31c, and 31d. The DB server 100 refers to the offload selection table 111 and identifies a row corresponding to the performance of the query that performed the sequential scan for each of the tables 31b and 31c. The identified line is a partial match tuple for the contents of the input query.

  The DB server 100 instructs both the query execution unit 140 and the cluster 20 of the DB server 100 to start executing the accepted query. When the query execution unit 140 receives an instruction to start execution, the query execution unit 140 starts executing the query. When the cluster 20 receives an instruction to start execution, the cluster 20 starts executing the query. The DB server 100 starts monitoring the progress of table scans of the tables 31a and 31b by the query execution unit 140 and the cluster 20, respectively. In this case, the DB server 100 separately monitors table scans for the partially matched portions (tables 31b and 31c) and the new portion (table 31d) among the plurality of monitoring target tables.

  At time T32, the DB server 100 detects the scan progress rate 100% of the table 31b, the scan progress rate 100% of the table 31c, and the scan progress rate 80% of the table 31d for the query execution unit 140. Further, the DB server 100 detects the scan progress rate 100% of the table 31b, the scan progress rate 100% of the table 31c, and the scan progress rate 90% of the table 31d for the cluster 20.

  In this case, the scan progress rates for the partially matched portions (tables 31b and 31c) among the plurality of monitoring target tables are all 100% in both the query execution unit 140 and the cluster 20. For this reason, the DB server 100 instructs the query execution stop to the lower scan progress rate of the new part (table 31d) among the plurality of monitoring target tables. In this example, the scan progress rate of the table 31d by the query execution unit 140 is lower than the scan progress rate of the table 31d by the cluster 20. Therefore, the DB server 100 instructs the query execution unit 140 to stop executing the query. When the query execution unit 140 receives an instruction to stop execution, the query execution unit 140 stops execution of the query.

At time T33, the cluster 20 completes the execution of the query. The DB server 100 acquires a query execution result from the cluster 20 and transmits it to the client 600.
Thus, the DB server 100 can stop the query processing in the DB server 100 at time T32. As a result, resources for the query processing in the DB server 100 can be released at the stage of time T32. In particular, by using the past results, the execution of one of the native or accelerator queries is executed before all the scan progress rates of the plurality of monitoring target tables reach 100% as compared with the case of FIG. Can be stopped. As a result, resource release can be further accelerated.

  FIG. 16 is a diagram illustrating a fourth example of query execution control. In the example of FIG. 16, the contents of the query input to the DB server 100 include an index scan for the table 31b (table name “tbl2”), an index scan for the table 31c (table name “tbl3”), and a table 31d (table Assume that a sequential scan for the name “tbl4”) is included. Assume that the monitoring target tables are tables 31b, 31c, and 31d.

  In addition, past results of queries that have been index-scanned for each of the tables 31b and 31c and a sequential scan for the table 31d (a complete match tuple for the contents of the input query) are not registered in the offload selection table 111. Shall. Furthermore, it is assumed that the past results (partial match tuples for the contents of the input query) of the queries that have performed the index scan on the table 31b and the index scan on the table 31c are registered in the offload selection table 111. For example, the DB server 100 performs the following control.

  At time T <b> 41, the DB server 100 accepts a query input from the client 600. The DB server 100 specifies that the query includes an index scan for each of the tables 31b and 31c and a sequential scan for the table 31d. Further, the DB server 100 determines the monitoring target tables in the query as the tables 31b, 31c, and 31d. The DB server 100 refers to the offload selection table 111 and identifies a row corresponding to the performance of the query that performed the sequential scan for each of the tables 31b and 31c. The identified line is a partial match tuple for the contents of the input query.

  The DB server 100 instructs both the query execution unit 140 and the cluster 20 of the DB server 100 to start executing the accepted query. When the query execution unit 140 receives an instruction to start execution, the query execution unit 140 starts executing the query. When the cluster 20 receives an instruction to start execution, the cluster 20 starts executing the query. The DB server 100 starts monitoring the progress of table scans of the tables 31a and 31b by the query execution unit 140 and the cluster 20, respectively. In this case, the DB server 100 separately monitors table scans for the partially matched portions (tables 31b and 31c) and the new portion (table 31d) among the plurality of monitoring target tables.

  At time T42, the DB server 100 detects the scan progress rate 90% of the table 31b, the scan progress rate 70% of the table 31c, and the scan progress rate 100% of the table 31d for the query execution unit 140. Further, the DB server 100 detects the scan progress rate 30% of the table 31b, the scan progress rate 20% of the table 31c, and the scan progress rate 100% of the table 31d for the cluster 20.

  In this case, the scan progress rate for the new part (table 31d) among the plurality of monitoring target tables is 100% in both the query execution unit 140 and the cluster 20. For this reason, the DB server 100 registers the absolute value of the difference in the current scan progress rates of the partially matched portions (tables 31b and 31c) among the plurality of monitoring target tables in the partially matched tuple of the offload selection table 111. Compare with absolute value of scan progress rate difference.

  For the table 31b, the difference in the current scan progress rate is 30% −90% = − 60%. Therefore, for the table 31b, the absolute value of the difference in the current scan progress rate is 60%. For the table 31c, the difference in the current scan progress rate is 20% −70% = − 50%. Therefore, for the table 31c, the absolute value of the difference in the current scan progress rate is 50%.

  On the other hand, the absolute value of the difference in the scan progress rates of the table 31b included in the partial match tuple of the offload selection table 111 is 30%. Further, the absolute value of the difference in the scan progress rates of the table 31c included in the partial match tuple is 50%.

  In this case, the absolute value (60%) of the difference in the current scan progress rate ≧ the absolute value (30%) of the difference in the scan progress rate in the partial match tuple is satisfied for the table 31b. For the table 31c, the absolute value (50%) of the difference in current scan progress rate ≧ the absolute value (50%) of the difference in scan progress rate in the partially matched tuple is satisfied. Therefore, the DB server 100 determines that the absolute value of the difference in the current scan progress rates of the partially matched portions (tables 31b and 31c) is greater than or equal to the absolute value of the difference in the scan progress rates registered in the partially matched tuple.

  Further, the request destination at which the scan progress rate of the new part (table 31d) has reached 100% is the query execution unit 140 (DB server 100) which is the execution continuation destination specified by the offload selection flag “FALSE” in the partial match tuple. ). For this reason, the DB server 100 instructs the query execution stop to the lower scan progress rate of the partially matched portions (tables 31b and 31c) among the plurality of monitoring target tables. In this example, the scan progress rates of the tables 31b and 31c by the cluster 20 are lower than the scan progress rates of the tables 31b and 31c by the query execution unit 140 (for example, as described above, the average value of the scan progress rates) You may compare). Therefore, the DB server 100 instructs the cluster 20 to stop executing the query. When receiving an execution stop instruction, the cluster 20 stops the execution of the query. Here, based on the past performance regarding the unfinished monitoring target process, the execution is stopped for the one (cluster 20) different from the query execution unit 140 that is the execution continuation destination specified by the offload selection flag “FALSE”. It is expected that instructions will be given.

  At time T43, the query execution unit 140 completes the execution of the query. The DB server 100 acquires a query execution result from the query execution unit 140 and transmits it to the client 600.

  Thus, the DB server 100 can stop the query processing in the cluster 20 at time T42. As a result, resources for the query processing in the cluster 20 can be released at the stage of time T42. In particular, by using the past results, the execution of one of the native or accelerator queries is executed before all the scan progress rates of the plurality of monitoring target tables reach 100% as compared with the case of FIG. Can be stopped. As a result, resource release can be further accelerated.

  FIG. 17 is a diagram illustrating a fifth example of query execution control. In the example of FIG. 17, the contents of the query input to the DB server 100 include an index scan for the table 31b (table name “tbl2”), an index scan for the table 31c (table name “tbl3”), and a table 31d (table Assume that a sequential scan for the name “tbl4”) is included. Assume that the monitoring target tables are tables 31b, 31c, and 31d.

  In addition, past results of queries that have been index-scanned for each of the tables 31b and 31c and a sequential scan for the table 31d (a complete match tuple for the contents of the input query) are not registered in the offload selection table 111. Shall. Furthermore, it is assumed that the past results (partial match tuples for the contents of the input query) of the queries that have performed the index scan on the table 31b and the index scan on the table 31c are registered in the offload selection table 111. For example, the DB server 100 performs the following control.

  At time T <b> 51, the DB server 100 accepts a query input from the client 600. The DB server 100 specifies that the query includes an index scan for each of the tables 31b and 31c and a sequential scan for the table 31d. Further, the DB server 100 determines the monitoring target tables in the query as the tables 31b, 31c, and 31d. The DB server 100 refers to the offload selection table 111 and identifies a row corresponding to the performance of the query that performed the sequential scan for each of the tables 31b and 31c. The identified line is a partial match tuple for the contents of the input query.

  The DB server 100 instructs both the query execution unit 140 and the cluster 20 of the DB server 100 to start executing the accepted query. When the query execution unit 140 receives an instruction to start execution, the query execution unit 140 starts executing the query. When the cluster 20 receives an instruction to start execution, the cluster 20 starts executing the query. The DB server 100 starts monitoring the progress of table scans of the tables 31a and 31b by the query execution unit 140 and the cluster 20, respectively. In this case, the DB server 100 separately monitors table scans for the partially matched portions (tables 31b and 31c) and the new portion (table 31d) among the plurality of monitoring target tables.

  At time T52, the DB server 100 detects the scan progress rate 90% of the table 31b, the scan progress rate 70% of the table 31c, and the scan progress rate 100% of the table 31d for the query execution unit 140. Further, the DB server 100 detects the scan progress rate 30% of the table 31b, the scan progress rate 20% of the table 31c, and the scan progress rate 40% of the table 31d for the cluster 20.

  In this case, the scan progress rate for the new part (table 31d) among the plurality of monitoring target tables is 100% in the query execution unit 140. For this reason, the DB server 100 registers the absolute value of the difference in the current scan progress rates of the partially matched portions (tables 31b and 31c) among the plurality of monitoring target tables in the partially matched tuple of the offload selection table 111. Compare with absolute value of scan progress rate difference.

  For the table 31b, the difference in the current scan progress rate is 30% −90% = − 60%. Therefore, for the table 31b, the absolute value of the difference in the current scan progress rate is 60%. For the table 31c, the difference in the current scan progress rate is 20% −70% = − 50%. Therefore, for the table 31c, the absolute value of the difference in the current scan progress rate is 50%.

  On the other hand, the absolute value of the difference in the scan progress rates of the table 31b included in the partial match tuple of the offload selection table 111 is 30%. Further, the absolute value of the difference in the scan progress rates of the table 31c included in the partial match tuple is 50%.

  In this case, the absolute value (60%) of the difference in the current scan progress rate ≧ the absolute value (30%) of the difference in the scan progress rate in the partial match tuple is satisfied for the table 31b. For the table 31c, the absolute value (50%) of the difference in current scan progress rate ≧ the absolute value (50%) of the difference in scan progress rate in the partially matched tuple is satisfied. Therefore, the DB server 100 determines that the absolute value of the difference in the current scan progress rates of the partially matched portions (tables 31b and 31c) is greater than or equal to the absolute value of the difference in the scan progress rates registered in the partially matched tuple.

  Further, the request destination at which the scan progress rate of the new part (table 31d) has reached 100% is the query execution unit 140 (DB server 100) which is the execution continuation destination specified by the offload selection flag “FALSE” in the partial match tuple. ). For this reason, the DB server 100 instructs the query execution stop to the lower scan progress rate of the partially matched portions (tables 31b and 31c) among the plurality of monitoring target tables. In this example, the scan progress rates of the tables 31b and 31c by the cluster 20 are lower than the scan progress rates of the tables 31b and 31c by the query execution unit 140 (for example, as described above, the average value of the scan progress rates) You may compare). Therefore, the DB server 100 instructs the cluster 20 to stop executing the query. When receiving an execution stop instruction, the cluster 20 stops the execution of the query. Here, based on the past performance regarding the unfinished monitoring target process, the execution is stopped for the one (cluster 20) different from the query execution unit 140 that is the execution continuation destination specified by the offload selection flag “FALSE”. It is expected that instructions will be given.

  At time T53, the query execution unit 140 completes the execution of the query. The DB server 100 acquires a query execution result from the query execution unit 140 and transmits it to the client 600.

  Thus, the DB server 100 can stop the query processing in the cluster 20 at time T52. As a result, resources for the query processing in the cluster 20 can be released at the stage of time T52. In particular, by using the past results, the execution of one of the native or accelerator queries is executed before all the scan progress rates of the plurality of monitoring target tables reach 100% as compared with the case of FIG. Can be stopped. As a result, resource release can be further accelerated.

  In particular, in the DB server 100, if the scan progress rate of the table 31d has reached 100%, the query execution by the cluster 20 is executed even if the scan progress rate of the table 31d has not reached 100% in the cluster 20. Can be stopped. Therefore, the release of resources can be further accelerated.

  FIG. 18 is a diagram illustrating a sixth example of query execution control. In the example of FIG. 18, the contents of the query input to the DB server 100 include an index scan for the table 31b (table name “tbl2”), an index scan for the table 31c (table name “tbl3”), and a table 31d (table Assume that a sequential scan for the name “tbl4”) is included. Assume that the monitoring target tables are tables 31b, 31c, and 31d.

  In addition, past results of queries that have been index-scanned for each of the tables 31b and 31c and a sequential scan for the table 31d (a complete match tuple for the contents of the input query) are not registered in the offload selection table 111. Shall. Furthermore, it is assumed that the past results (partial match tuples for the contents of the input query) of the queries that have performed the index scan on the table 31b and the index scan on the table 31c are registered in the offload selection table 111. For example, the DB server 100 performs the following control.

  At time T <b> 61, the DB server 100 accepts a query input from the client 600. The DB server 100 specifies that the query includes an index scan for each of the tables 31b and 31c and a sequential scan for the table 31d. Further, the DB server 100 determines the monitoring target tables in the query as the tables 31b, 31c, and 31d. The DB server 100 refers to the offload selection table 111 and identifies a row corresponding to the performance of the query that performed the sequential scan for each of the tables 31b and 31c. The identified line is a partial match tuple for the contents of the input query.

  The DB server 100 instructs both the query execution unit 140 and the cluster 20 of the DB server 100 to start executing the accepted query. When the query execution unit 140 receives an instruction to start execution, the query execution unit 140 starts executing the query. When the cluster 20 receives an instruction to start execution, the cluster 20 starts executing the query. The DB server 100 starts monitoring the progress of table scans of the tables 31a and 31b by the query execution unit 140 and the cluster 20, respectively. In this case, the DB server 100 separately monitors table scans for the partially matched portions (tables 31b and 31c) and the new portion (table 31d) among the plurality of monitoring target tables.

  At time T62, the DB server 100 detects the scan progress rate 90% of the table 31b, the scan progress rate 70% of the table 31c, and the scan progress rate 60% of the table 31d for the query execution unit 140. Further, the DB server 100 detects the scan progress rate 30% of the table 31b, the scan progress rate 20% of the table 31c, and the scan progress rate 100% of the table 31d for the cluster 20.

  In this case, the scan progress rate for the new part (table 31d) among the plurality of monitoring target tables is 100% in the cluster 20. For this reason, the DB server 100 registers the absolute value of the difference in the current scan progress rates of the partially matched portions (tables 31b and 31c) among the plurality of monitoring target tables in the partially matched tuple of the offload selection table 111. Compare with absolute value of scan progress rate difference.

  For the table 31b, the difference in the current scan progress rate is 30% −90% = − 60%. Therefore, for the table 31b, the absolute value of the difference in the current scan progress rate is 60%. For the table 31c, the difference in the current scan progress rate is 20% −70% = − 50%. Therefore, for the table 31c, the absolute value of the difference in the current scan progress rate is 50%.

  On the other hand, the absolute value of the difference in the scan progress rates of the table 31b included in the partial match tuple of the offload selection table 111 is 30%. Further, the absolute value of the difference in the scan progress rates of the table 31c included in the partial match tuple is 50%.

  In this case, the absolute value (60%) of the difference in the current scan progress rate ≧ the absolute value (30%) of the difference in the scan progress rate in the partial match tuple is satisfied for the table 31b. For the table 31c, the absolute value (50%) of the difference in current scan progress rate ≧ the absolute value (50%) of the difference in scan progress rate in the partially matched tuple is satisfied. Therefore, the DB server 100 determines that the absolute value of the difference in the current scan progress rates of the partially matched portions (tables 31b and 31c) is greater than or equal to the absolute value of the difference in the scan progress rates registered in the partially matched tuple.

  Furthermore, the cluster 20 is the request destination for which the scan progress rate of the new part (table 31d) has reached 100%. The cluster 20 does not match the query execution unit 140 (DB server 100), which is the execution continuation destination specified by the offload selection flag “FALSE” in the partial match tuple. For this reason, at the stage of time T62, the DB server 100 determines that the query processing by both the query execution unit 140 and the cluster 20 is continued, and continues monitoring the table scan of each monitoring target table. This is because at this stage, it is impossible to appropriately determine which one of the native and the accelerator can complete all the monitoring target processes earlier. That is, at this stage, the query execution unit 140 has not completed scanning of the table 31d (relatively large load processing), so that the query execution unit 140 will scan the tables 31b and 31c in the future rather than past results. The possibility of taking time cannot be denied. Therefore, in such a case, the DB server 100 continues both query processes and continues to monitor the scan progress rate.

  In this way, if it is not possible to determine which query processing is advantageous, it is possible to continue query processing by both and continue monitoring so that queries by either native or accelerator can be performed at an appropriate timing. Processing can be stopped.

  FIG. 19 is a diagram illustrating an example of resource release timing. FIG. 19A illustrates a case where execution of a query on the accelerator side is stopped. FIG. 19B illustrates a case where execution of a query on the native side is stopped.

  In the example of FIG. 19A, both the native and the accelerator start executing a query at time T71. Then, at time T72, the execution of the query on the accelerator side is stopped. Further, at time T73, execution of the native-side query is completed. In this way, the execution of the accelerator-side query is stopped at time T72 before the time T73 when the execution of the native-side query is completed. In this way, resources associated with accelerator side query processing can be released at time T72. In particular, the processing executed at the initial stage of a query called table scan can be monitored for progress, so that the execution of queries on the accelerator side can be stopped at the initial stage, and resources can be released at a relatively early stage. Can do.

  In the example of FIG. 19B, both the native and the accelerator start executing the query at time T71a. At time T72a, execution of the native-side query is stopped. Further, at time T73a, the execution of the query on the accelerator side is completed. As described above, the execution of the query on the native side is stopped at the time T72a before the time T73a at which the execution of the query on the accelerator side is completed. In this way, resources associated with native-side query processing can be released at time T72a. As in the case of FIG. 19A, by executing the table scan as the progress monitoring target, it is possible to stop the execution of the query on the native side at the initial stage and to release the resource at a relatively early stage. it can.

On the other hand, a method in which the DB server 100 does not perform query execution control is also conceivable.
FIG. 20 is a diagram illustrating a comparative example of resource release timing. FIG. 20 shows an example in which execution of the other query is stopped when one of the native and accelerators completes all the processes included in the query. FIG. 20A shows a case where execution of the query on the accelerator side is stopped. FIG. 20B shows a case where execution of a query on the native side is stopped.

  In the example of FIG. 20A, both the native and the accelerator start executing the query at time T81. At time T82, the execution of the native query is completed. For this reason, at time T82, execution of the incomplete accelerator-side query is stopped.

  In the example of FIG. 20B, both the native and the accelerator start executing the query at time T81a. Then, at time T82a, execution of the query on the accelerator side is completed. For this reason, at time T82a, execution of the incomplete native-side query is stopped.

  In both the examples of FIGS. 20A and 20B, the execution of the other query is continued until the execution of the one query is completed. For this reason, until the execution of the query is completed on the one hand, the use of resources accompanying the query processing by the other is continued, and the resource release timing is delayed. That is, in the example of FIG. 20A and FIG. 20B, the period during which the resources are used excessively becomes longer.

  On the other hand, according to the query execution control of the DB server 100, as described above, the execution of the other query can be stopped before the query execution of one of the native and accelerator is completed. Therefore, the execution of the other query can be stopped earlier than the execution of the other query is stopped after the execution of the query is completed. As a result, resources associated with the query processing by the other can be released more quickly. Then, the released resource can be used for another process. Further, by speeding up the stop of query execution, it is possible to reduce power consumption associated with query processing.

In this way, it is possible to improve the resource utilization efficiency by the native and accelerator while improving the response performance to the query by the information processing system.
The information processing according to the first embodiment can be realized by causing the processing unit 1b to execute a program. The information processing according to the second embodiment can be realized by causing the processor 101 to execute a program. The program can be recorded on a computer-readable recording medium 13.

  For example, the program can be distributed by distributing the recording medium 13 on which the program is recorded. Alternatively, the program may be stored in another computer and distributed via a network. For example, the computer stores (installs) a program recorded in the recording medium 13 or a program received from another computer in a storage device such as the RAM 102 or the HDD 103, and reads and executes the program from the storage device. Good.

Regarding the embodiments including the first and second embodiments, the following additional notes are disclosed.
(Supplementary Note 1) A storage unit that stores data to be processed by a plurality of processes included in a query;
Based on the data stored in the storage unit, a monitoring target process that is estimated to have a processing load larger than a predetermined load among the plurality of processes is determined, and both the first device and the second device are determined. The execution start of the query is instructed, the first progress information of the monitoring target process executed by the first device is acquired, and the second progress of the monitoring target process executed by the second device A processing unit for acquiring information and instructing one of the first device and the second device to stop executing the query based on the first progress information and the second progress information When,
An information processing apparatus.

  (Additional remark 2) The said process part stores the identification information which can identify the direction which instruct | indicated the said execution stop among the said 1st apparatus and the said 2nd apparatus with respect to the said monitoring object process in the said memory | storage part. When another query including the monitoring target process is received, the other query is sent to one of the first device and the second device based on the identification information stored in the storage unit. The information processing apparatus according to appendix 1, instructing the start of execution of.

  (Supplementary Note 3) When the monitoring target process included in the query matches a first part of a plurality of monitoring target processes included in the other query, the processing unit includes the first and second Instructing both of the devices to start execution of the other query, the progress of the first portion of each of the first and second devices, and the first portion of the plurality of monitoring target processes Instructing one of the first and second devices to stop executing the other query based on the progress of each of the first and second devices with respect to a second part different from The information processing apparatus according to appendix 2.

  (Supplementary Note 4) When the execution of the first part is completed by both the first and second devices, the processing unit performs a third operation on the second part executed by the first device. Execution of the other query to one of the first and second devices based on progress information and fourth progress information for the second portion executed by the second device The information processing apparatus according to appendix 3, which instructs to stop.

  (Supplementary Note 5) When the execution of the second part is completed by either or one of the first and second devices, the processing unit is executed by the first device. One of the first and second devices based on the fifth progress information for and the sixth progress information and the identification information for the first portion executed by the second device. The information processing apparatus according to attachment 3 or 4, wherein the apparatus instructs the apparatus to stop execution of the other query.

  (Supplementary Note 6) The processing unit may determine the processing load of each of the plurality of processes based on an information amount of each of the plurality of data sets used by the plurality of processes. The information processing apparatus described.

  (Additional remark 7) The said process part determines the process with respect to the data set which is the largest information amount among these data sets as a 1st monitoring object process, and performs 2nd monitoring based on the said largest information amount. The information processing apparatus according to attachment 6, wherein the target process is determined.

(Appendix 8) The data set is a table in a relational database,
The processing unit acquires the information amount based on the number of rows in the table.
The information processing apparatus according to appendix 6 or 7.

  (Additional remark 9) The said process part determines the 2nd process performed prior to a 1st process among each of the said several processes contained in the said query as the said monitoring object process, The said 1st The information processing apparatus according to any one of appendices 1 to 8, wherein the process is not the monitoring target process.

(Supplementary Note 10) The query includes a plurality of processes for tables in a relational database,
The second process is a table scan for the table.
The information processing apparatus according to appendix 9.

(Additional remark 11) Based on the data of the process target by the some process contained in a query, the monitoring object process estimated that a process load is larger than predetermined | prescribed load among these processes is determined,
Instructing both the first device and the second device to start executing the query;
Obtaining first progress information of the monitoring target process executed by the first device; obtaining second progress information of the monitoring target process executed by the second device;
Instructing one of the first device and the second device to stop execution of the query based on the first progress information and the second progress information.
A program that causes a computer to execute processing.

(Supplementary note 12)
Based on data to be processed by a plurality of processes included in the query, a monitoring target process that is estimated to have a processing load larger than a predetermined load among the plurality of processes is determined.
Instructing both the first device and the second device to start executing the query;
Obtaining first progress information of the monitoring target process executed by the first device; obtaining second progress information of the monitoring target process executed by the second device;
Instructing one of the first device and the second device to stop execution of the query based on the first progress information and the second progress information.
Information processing method.

DESCRIPTION OF SYMBOLS 1 Information processing apparatus 1a Memory | storage part 1b Processing part 2 1st apparatus 3 2nd apparatus 4 Terminal device 5 Memory | storage device 6 Network D1 Process target data Q1 Query

Claims (7)

A storage unit for storing data to be processed by a plurality of processes included in the query;
Based on the data stored in the storage unit, a monitoring target process that is estimated to have a processing load larger than a predetermined load among the plurality of processes is determined, and both the first device and the second device are determined. The execution start of the query is instructed, the first progress information of the monitoring target process executed by the first device is acquired, and the second progress of the monitoring target process executed by the second device A processing unit for acquiring information and instructing one of the first device and the second device to stop executing the query based on the first progress information and the second progress information When,
An information processing apparatus.   The processing unit stores, in the storage unit, identification information that can identify the one of the first device and the second device that has instructed the execution stop for the monitoring target process. When another query including the target process is received, based on the identification information stored in the storage unit, one of the first device and the second device starts executing the other query. The information processing apparatus according to claim 1, wherein an instruction is given.   The information processing apparatus according to claim 1, wherein the processing unit determines the processing load of each of the plurality of processes based on an information amount of each of a plurality of data sets used by the plurality of processes.   The processing unit determines a process for a data set having the maximum information amount among the plurality of data sets as a first monitoring target process, and determines a second monitoring target process based on the maximum information amount. The information processing apparatus according to claim 3.   The processing unit determines, as the monitoring target process, a second process that is executed before the first process among the plurality of processes included in the query, and the first process is the monitoring process The information processing apparatus according to claim 1, wherein the information processing apparatus is not a target process. Based on data to be processed by a plurality of processes included in the query, a monitoring target process that is estimated to have a processing load larger than a predetermined load among the plurality of processes is determined.
Instructing both the first device and the second device to start executing the query;
Obtaining first progress information of the monitoring target process executed by the first device; obtaining second progress information of the monitoring target process executed by the second device;
Instructing one of the first device and the second device to stop execution of the query based on the first progress information and the second progress information.
A program that causes a computer to execute processing. Computer
Based on data to be processed by a plurality of processes included in the query, a monitoring target process that is estimated to have a processing load larger than a predetermined load among the plurality of processes is determined.
Instructing both the first device and the second device to start executing the query;
Obtaining first progress information of the monitoring target process executed by the first device; obtaining second progress information of the monitoring target process executed by the second device;
Instructing one of the first device and the second device to stop execution of the query based on the first progress information and the second progress information.
Information processing method.

Images