JP2015026396A - Database management system and method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To shorten a time to be spent on the execution of one query.SOLUTION: A database management system includes: a query acceptance part 7 for accepting a query; and a query execution part 9 for executing the accepted query. The query execution part 9 dynamically generates a task, and executes the generated tasks in parallel. In the case of executing each task, the query execution part 9 generates the task for acquiring the data each time the data of the database are required, and in the case of executing the generated tasks, issues a data reading request for reading the data from the database as necessary.

Description

  The present invention relates to database management technology.

  For example, Japanese Unexamined Patent Application Publication No. 2004-192292 discloses a management server in a system in which a DB (database) is built on a virtualization environment. The management server obtains DB processing information such as an execution plan and processing priority of DB processing from a DBMS (database management system), predicts data to be accessed and the order of access based on the information, and makes predictions Based on the result, an instruction is given to read the data to be accessed in the near future onto the cache of the storage device, and the data to be accessed in the near future is read into the cache memory of the own server.

JP 2004-192292 A

  By the way, the DBMS normally accepts a query, and when a query is accepted, the DBMS executes the query and outputs the execution result. There are cases where a multi-stage database operation is executed before the execution result of the query is output. These multi-stage database operations are generally executed in a predetermined order, and at least one of the multi-stage database operations requires issuing a read request to the storage device. There may be. Hereinafter, one specific example will be described with reference to FIGS. 1A to 1C.

  For example, when a DBMS receives a query from a computer program (for example, an application program) that is above the DBMS, the query plan shown in FIG. 1A is used as an execution plan for the query (hereinafter simply referred to as “query plan”). Is generated. Then, the part table 23A, the line item table 23B, the order table 23C, and various indexes 25 illustrated in FIG. 1B are stored in a storage device (for example, an external storage device communicably connected to an information processing terminal equipped with a DBMS). Suppose that

  According to the query plan illustrated in FIG. 1A, database operations (hereinafter abbreviated as “OP”) 1 to 5 are repeated until there are no unread rows in the part table 23A. OP1 is an initial database operation and is a process of reading one line from the part table 23A (see FIG. 1B). OP2 is a process for searching the line item index 25A for the pointer (rowid) of the line item table 23B (see FIG. 1B) corresponding to the PID in the read row. OP3 is a process of fetching the line item table 23B with the obtained pointer and filtering with the OID (for example, a process of outputting only those with an OID of less than 504). OP4 is a process of searching the order index 25B for a pointer (rowid) of the order table 23C (see FIG. 1B) corresponding to the output OID. OP5 is a process of fetching the order table 23C with the obtained pointer and returning as a result. By repeating OP1 to OP5 as described above, the query execution result illustrated in FIG. 1C can be returned to the computer program that issued the query.

  When one query is executed as described above, a plurality of OPs are repeatedly executed, and in each execution, one OP ends and the next OP starts. For this reason, for example, when a read request is issued in a certain OP (for example, OP3), the processing is interrupted until data is read in response to the read request. Therefore, it takes a long time to execute one query.

  Further, when one query is executed as described above, the storage device may be randomly accessed. Specifically, the reading of the line item table 23B, the order table 23C, and the index may be random. More specifically, for example, after accessing the first line of the line item table 23B, the sixth line and the ninth line are temporarily accessed to the twelfth line even though the sixth line and the ninth line correspond to the lines of the part table 23A. After that, the 6th line is accessed. When executing one query, a read request is issued a plurality of times from the DBMS. However, if random access as described above is performed, the data read waiting time as a whole becomes long.

  Therefore, one object of the present invention is to shorten the time required to execute one query. Specifically, for example, the entire data read waiting time in executing one query is shortened.

  Other objects of the present invention will become clear from the following description.

  A database management system according to one aspect of the present invention executes a query reception unit that receives a query and the received query, and reads data in a database from a storage device (for example, a main storage device) as necessary. A query execution unit that issues a data read request for the data read. The query execution unit dynamically generates tasks and executes the generated tasks in parallel. The query execution unit generates a task for acquiring the data every time the data of the database is required in the execution of each task. In addition, the query execution unit issues the data read request for reading data from the database, as necessary, in executing the generated task.

  Specific examples of this database management system are as follows. That is, the database management system includes a query receiving unit that receives a query (for example, SQL) from a host computer program (for example, an application program), and a query plan generating unit that generates a query plan that is a plan for executing the received query. A query execution unit that executes a query according to the generated query plan. The query plan is composed of, for example, one or more database operations accompanied by data reading, and the execution order between the database operations has a tree-structured order relationship. The query execution unit can be composed of a step of assigning a task by extracting an initial database operation that does not depend on other database operations, and a step of executing the assigned task.

In the step of executing the task corresponding to the database operation, the following steps (A) to (D):
(A) generating a plurality of independent tasks for data read processing;
(B) issuing a data read request to the operating system when data read from the external storage device is necessary in the data read processing of the plurality of generated tasks;
(C) resuming execution of the database operation from the task that has completed the data reading;
(D) if there is a next database operation dependent on the database operation, executing the next database operation;
Can be executed.

  In the first aspect, the query execution unit waits for generation of a new task when the existing number of tasks in a predetermined situation has reached a predetermined number, and when the existing number decreases, New tasks can be created. The predetermined situation may be, for example, an existing situation or a situation waiting for data acquisition.

  In the second aspect, the database management system may further include a read order control unit. The read order control unit receives a plurality of data read requests issued from the query execution unit, and the received plurality of data read requests are different from the order in which the plurality of data read requests are received as a whole. Can be issued in the order for shortening the data read time length (that is, the time length until data is read in response to a plurality of data read requests).

  Specifically, for example, the database management system can include a read optimization unit that receives a data read request from the query execution unit and issues the data read request to the operating system. The read optimization unit queues the received data read request and when a condition for controlling the timing for issuing the data read request (for example, a batch scheduling drive condition of the second embodiment described later) is satisfied. The data read time can be optimized by changing the output order of the queued data read requests.

  In the third aspect, the database management system can further include a plurality of queues having different priorities. The query execution unit can store the data read request in a queue corresponding to a priority that satisfies a predetermined condition among the plurality of queues by executing the generated task. The read order control unit can issue data read requests stored in a queue with higher priority with higher priority.

Specifically, for example, the read optimization unit has a plurality of read request queues including those not scheduled, and can issue a data read request according to the processing procedure set for each read request queue. In this case, when a data read request is issued to the read optimization unit by executing a task, the following processes (a) to (c):
(A) a process for assigning a scheduling flag for a read request;
(B) a process of selecting one read request queue from a plurality of read request queues according to the value of the scheduling flag;
(C) processing for storing a read request in the selected read request queue;
Can be executed. The read optimization unit can change the length of time that data read requests are kept in the queue.

  In a fourth aspect, in the third embodiment described above, when the read order control unit receives a predetermined command, it separates at least one read request stored in a queue having a certain priority. Can be moved to the priority queue.

  Specifically, for example, the database management system issues a schedule cancel command to a data read request queued in the schedule target read request queue, thereby causing the data read request to be read out of the schedule target read request queue. Can be moved to.

  According to a fifth aspect, in the third aspect described above, the query execution unit determines which priority depending on the content of the execution plan of the accepted query or the performance requirement required for the execution of the accepted query. It is possible to determine whether to store read requests in the queue.

  In a sixth aspect, in the third aspect described above, the database management system can include a task management unit. The task management unit can calculate the number of remaining steps based on the query execution plan and increase the priority of the task with the small number of remaining steps calculated. In this case, the query execution unit can store a read request issued by executing a task with an increased priority in a queue corresponding to the priority. Here, the remaining step can be, for example, the number of remaining data operations.

  In a seventh aspect, in the execution of each generated task, the query execution unit waits for the acquisition of data in the database, and after acquiring the data, in the same order as the order in which the acquisition wait for data is started, The execution of the task can be resumed. This can also be done in the second embodiment.

  A computer system according to another aspect of the present invention includes the above-described database management system and a reading order control unit. The read order control unit receives a plurality of data read requests issued from the database management system, and the received plurality of data read requests are different from the order in which the plurality of data read requests are received. Issued in order to shorten the data read time length.

  According to the database management system according to the present invention, the length of time required to execute one query can be shortened.

FIG. 1A shows an example of a query plan. FIG. 1B shows a configuration example of a part table, a line item table, and an order table, and the relationship between the tables. FIG. 1C shows an example of information output as a query execution result. FIG. 2 shows a configuration example of a system according to the first embodiment of the present invention. FIG. 3 shows an example of the flow of processing performed by the query execution unit 9. FIG. 4A shows an example of the flow of processing performed in the task generation waiting process in S2 of FIG. FIG. 4B shows an example of the flow of processing performed in the data acquisition processing of S11 of FIG. FIG. 5A shows an example of a conventional query execution flow. FIG. 5B shows an example of the flow of query execution in the first embodiment of the present invention. FIG. 6 shows a configuration example of a system according to the second embodiment of the present invention. FIG. 7A shows an example of the flow of data acquisition processing performed in the second embodiment of the present invention. FIG. 7B shows an example of the flow of I / O request issue processing. FIG. 8 is an explanatory diagram of the I / O optimization unit 27. FIG. 9A shows an example of the flow of processing performed by the I / O optimization unit 27. FIG. 9B shows an example of the flow of immediate issue processing. FIG. 10A shows an example of the flow of schedule cancellation processing. FIG. 10B shows an example of the flow of batch schedule processing. 11A and 11B are explanatory diagrams of examples of effects expected by the DBMS 5 according to the first embodiment of this invention. Specifically, FIG. 11A shows an example of a flow of issuing an I / O request and reading data in the first embodiment. FIG. 11B shows an example of a disk seek image in the flow shown in FIG. 11A. 12A and 12B are examples of the effects expected by the DBMS 5 according to the second embodiment of the present invention, and are explanatory diagrams when the immediate issue process is not performed. 13A and 13B are examples of effects expected by the DBMS 5 according to the second embodiment of the present invention, and are explanatory diagrams when an immediate issue process is performed. FIG. 14A shows a configuration example of a data acquisition waiting table in the third embodiment of the present invention. FIG. 14B shows a first difference from the process performed by the generated child task in the first embodiment. FIG. 14C shows a second difference from the process performed by the generated child task in the first embodiment. FIG. 15A shows an example of the relationship between the start order of the data acquisition process, the data acquisition order, and the task restart order. FIG. 15B shows an example of the disk seek image in FIG. 15A.

  Hereinafter, some embodiments of the present invention will be described with reference to the drawings.

  FIG. 2 shows a configuration example of a system according to the first embodiment of the present invention.

  The database server 1 and an external storage device 19 that is a storage device existing outside the database server 1 are connected to be communicable via a communication network 17.

  The external storage device 19 may be any device as long as it has storage resources. For example, the external storage device 19 may be a file server, a single disk drive (for example, a hard disk drive), or a storage device system including a plurality of disk drives. The external storage device 19 has a database 21 and can store a plurality of electronic indexes 25, 25,... And a plurality of electronic tables 23, 23,. Each index 25 is, for example, data including a plurality of pointers (for example, indexes 25A and 25B in FIG. 1B) indicating the connection between each row in one table and each row in another table, and a B-tree index or the like is used. It is done. Each table 23 is data (for example, the part table 23A, the line item table 23B, or the order table 23C in FIG. 1B) having a plurality of rows composed of a plurality of row elements.

  The database server 1 is, for example, a storage resource (for example, a memory or a hard disk) that can store a plurality of computer programs, or a processor (for example, a CPU) that can read and execute a computer program from the storage resources, although not specifically illustrated. And so on. As a computer program stored in the storage resource, for example, an application program (hereinafter referred to as AP) 3 that issues a query (for example, SQL (Structured Query Language)) and a query from AP3 are executed, and an execution result is returned to AP3. There is a database management system (hereinafter referred to as DBMS) 5 and an operating system (hereinafter referred to as OS) 15 such as Windows (registered trademark). The DBMS 5 is above the OS 15, and the AP 3 is above the DBMS 5. The AP may exist on a computer different from the DBMS. In that case, an inquiry request from the AP is accepted via the network. Further, a database buffer (hereinafter referred to as a DB buffer) 12 used in the DBMS 5 can be constructed by using a part of the storage resource, for example.

  The DBMS 5 is generated, for example, a query receiving unit 7 that receives a query from the AP 3, a query plan generating unit 11 that generates a query plan as exemplified in FIG. 1A based on the query received by the query receiving unit 7, and the like. A query execution unit 9 that executes a query according to a query plan, and an execution task management unit 13 that manages a task for executing the query (for example, assigns resources such as a CPU and a memory to the task). . The query plan defines the execution order of a plurality of database operations (OP).

  This first embodiment is particularly characterized in the processing performed by the query execution unit 9. The query execution unit 9 can execute at least one OP by executing a task to which at least one OP is assigned. When the query execution unit 9 needs to read data from the external storage device 19 during the execution of the task, the query execution unit 9 reads the data and generates a task to execute the next OP. The generated task By executing this, a data input / output request (hereinafter referred to as “I / O request”) can be issued. When a plurality of tasks are generated, a plurality of tasks can be executed in parallel, and therefore a plurality of I / O requests can be issued in parallel. As the task implementation, any execution environment such as a process or thread managed by the OS or a pseudo process or pseudo thread implemented by an application or middleware can be used.

  Hereinafter, processing performed by the query execution unit 9 will be described. Hereinafter, for the sake of easy understanding, it is assumed that one OP is executed by executing one task. However, of course, it is not necessary to limit to this. For example, a plurality of OPs may be executed by executing one task. Specifically, for example, one task may execute a certain OP, take over the execution result, and execute the next OP.

  FIG. 3 shows an example of the flow of processing performed by the query execution unit 9.

  The query execution unit 9 can execute the OP by executing a task to which a certain level of database operation (OP) is assigned (hereinafter referred to as “parent task” for convenience).

  If the executed parent task has remaining data (for example, data that has not been read from the index 25 or the table 23) in the execution of the OP (“data present” in step S1), task generation waiting processing Is executed (S2). When a task can be generated by the task generation wait process, the parent task is assigned to read the remaining data and execute the next OP (hereinafter referred to as “child task” for convenience). 31 is generated (S3). While the parent task is being executed (“parent task” in S4), S1 is executed again. Further, in the case of “no data” in S1, the parent task can disappear.

  The query execution unit 9 can execute the generated child task 31 in parallel. When a plurality of child tasks that execute the same next OP are generated by repeating the processing of the “parent task” in S1 to S4, the generated plurality of child tasks 31, 31,. Can be executed in parallel.

  The executed child task 31 executes a data acquisition process for acquiring the remaining data in S1 (S11). If the data can be acquired (“data present” in S11), the acquired data matches the selection condition. (S12 is not performed depending on the type of OP). If there is a match (“Yes” in S12), the child task 31 executes the next OP if there is an OP next to the OP assigned to itself (“Yes” in S13) (S14), otherwise ( The result is returned (S15). Whether or not there is a next OP can be determined by referring to the query plan illustrated in FIG. 1A generated by the query plan generation unit 11, for example. Further, in the execution of the next OP in S14, the child task can execute the above-described processing of S1 as a parent task and generate a child task in S3.

  FIG. 4A shows an example of the flow of processing performed in the task generation waiting process in S2 of FIG.

  The parent task determines whether a task having a higher priority than itself is waiting to be generated (S2-1). Specifically, for example, the parent task refers to the query plan, and determines whether or not a child task that is waiting to be generated in the execution of another parent task is a task that executes an OP subsequent to itself. .

  If the result of the determination in S2-1 is a wait (“Yes” in S2-1), the parent task waits for the occurrence of an event that triggers the generation of the task (S2-2).

  On the other hand, if the result of the determination in S2-1 is not waiting (“None” in S2-1), the parent task determines whether or not the number of existing data acquisition waiting tasks is less than a predetermined threshold (S2-3). ). The number of existing data acquisition waiting tasks is determined by, for example, increasing the predetermined count value by 1 each time the query execution unit 9 generates a task, and reducing the count value by 1 each time data acquisition is completed. It can be determined by referring to. The threshold value is a value stored in the storage resource of the database server 1. The threshold is, for example, a kind of tuning parameter, and can be set to a desired value by the administrator of the DBMS 5. Further, the threshold value can be determined for the entire DBMS system, and can be set in an arbitrary unit such as an inquiry or a user.

  As a result of the determination in S2-3, if the number of remaining tasks is less than the predetermined threshold (“Yes” in S2-3), the parent task finishes the task generation waiting process in S2 of FIG. 3 and executes the next S3 If not (“No” in S2-3), it waits for the occurrence of an event that triggers the disappearance of at least one task (S2-4). An example of the event here is “no data” in S1 of FIG.

  FIG. 4B shows an example of the flow of processing performed in the data acquisition processing of S11 of FIG.

  The child task accesses the DB buffer 12, and if the data to be read exists in the DB buffer 12 due to reasons such as remaining data read in the past (" Hit "), the data is acquired from the DB buffer 12 (S11-5), and the data acquisition process is completed.

  When there is no data to be read out in the DB buffer 12 (“fault” in S11-1), the child task must still issue an I / O request to the area where the data exists. If this is the case (“No” in S11-2), I / O issuance by OS system call is performed (S11-3). That is, the child task issues an I / O request to the external storage device 19 from the OS 15 by issuing an I / O request to the OS 15. In response to the execution of the child task, it waits until data is read from the external storage device 19 via the OS 15. If the data is read (S11-5), the child task resumes the process, stores the read data in the DB buffer 12, and ends this data acquisition process.

  If the child task is “fault” in S11-1, if the I / O request has already been issued to the area where the data to be read exists (“already” in S11-2), Wait for completion of the O request (S11-4). If the data is read (S11-5), the child task resumes the process, stores the read data in the DB buffer 12, and ends this data acquisition process. Note that whether each task issues an I / O request to the OS 15, for example, whether or not an I / O request has already been issued to the area where the data to be read is present. The I / O destination information related to the access destination by the O request is written in a predetermined storage area on the storage resource of the database server 1, and the child task is determined by referring to each I / O destination information on the predetermined storage area. can do. As the I / O destination information, for example, information including an identifier of a logical unit (for example, a logical unit number) provided in the external storage device 19 and a logical block address (hereinafter referred to as LBA) of an access destination may be used. it can. The storage resource of the database server 1 includes, for example, a DB object (for example, table 23, index 25, or each row element (for example, PID, OID) on the table 23 or index 25) and a storage location (for example, logical unit identifier and / or Or mapping information representing the correspondence relationship with the LBA), each task can issue an I / O request to the OS 15 based on the mapping information, and the I / O destination information can be specified. It can be written to the storage area.

  According to the first embodiment described above, when the query execution unit 9 needs to read data from the external storage device 19 during the execution of the task, the query execution unit 9 reads the data and executes the next OP. An I / O request can be issued by generating and executing the generated task. When a plurality of tasks are generated, a plurality of tasks can be executed in parallel, and therefore a plurality of I / O requests can be issued in parallel. This will be described by taking an example in which a query is executed according to the query plan illustrated in FIG. 1A. According to the conventional technique, as shown in FIG. 5A, an unread line is read from the part table 23A. It is necessary to finish from OP1 to OP5 and start again from OP1 until there is no more, but according to the first embodiment described above, the OP at the same stage is executed in parallel as shown in FIG. 5B can do. Specifically, for example, since the number of rows in the part table 23A is 3, when a task to which OP1 is assigned is executed, a plurality of child tasks are generated, and the plurality of child tasks are executed in parallel. Thus, the three OP2 corresponding to the three rows of the part table 23A can be executed in parallel. After the execution of each OP2, OP3 is also executed in parallel. Depending on the execution result, the task disappears and OP4 and the subsequent steps are not executed (for example, because the fetched OID is less than 504, S12 in FIG. 3). The task ends and the task disappears because it does not match the selection condition of (1), and a plurality of OP4s are executed in parallel after execution of one OP3 (for example, two rows corresponding to PID “301” are 2 Since two of them are found, two OP4 corresponding to the two rows are executed in parallel). Since an OP requiring processing for issuing an I / O request is executed in parallel, a plurality of I / O requests are issued in parallel. Thus, for example, a read request is issued for each generated task, and even if processing of the task is interrupted until data is read in response to the read request, other generated tasks are executed independently. The query execution itself is not interrupted. As a result, the time required to execute one query can be shortened compared to the conventional case.

  In addition, according to the first embodiment described above, tasks are not generated indefinitely. When the number of existing data acquisition waiting tasks reaches a predetermined value, no new task is generated and the existing data acquisition waiting When the number of tasks becomes less than a predetermined value, a new task is generated. Thereby, the amount of computer resources (for example, CPU usage rate, memory usage amount, etc.) consumed by the processing in the DBMS 5 can be suppressed.

  The second embodiment of the present invention will be described below. In this case, differences from the first embodiment will be mainly described, and the description of the common points with the first embodiment will be simplified or omitted in order to omit redundant description.

  FIG. 6 shows a configuration example of a system according to the second embodiment of the present invention. In this figure, the same elements as those in the first embodiment are denoted by the same reference numerals.

  In this second embodiment, the DBMS 5 is provided with an I / O optimization unit 27. In this case, the query execution unit 9 issues an I / O request not to the OS 15 but to the I / O optimization unit 27. The I / O optimization unit 27 receives and holds a plurality of I / O requests issued in parallel from the query execution unit 9, and optimizes the order of the received plurality of I / O requests and the data read time length. It is possible to issue a plurality of I / O requests to the OS 15 in the changed order.

  Hereinafter, the second embodiment will be described in detail.

  FIG. 7A shows an example of the flow of data acquisition processing performed in the second embodiment of the present invention.

  In FIG. 7A, S31, S32, S35, and S36 correspond to S11-1, S11-2, S11-4, and S11-5 of FIG. 4A, respectively. The difference is S33 and S34.

  In S33, the child task being executed by the query execution unit 9 determines whether or not an I / O request to be issued is to be scheduled, and determines that a schedule flag is to be given if the I / O request is to be scheduled. . The case of being a schedule target is, for example, a case where the urgency of issuing an I / O request to the OS 15 is low, and if that is not the case, the schedule target is excluded. Whether to be a schedule target can be determined, for example, according to the contents of the query plan or the performance requirements required for executing the query. In the specific example of the former, when the child task refers to the query plan and the OP assigned to the child task is recognized as an OP at a later stage than a certain stage, it is excluded from the schedule. If this is not the case, the schedule may be used. In the latter specific example, when issuing an I / O request for database access having a low urgency access characteristic such as a decision support system, the child task is a target of scheduling, such as an online transaction system. When issuing an I / O request for database access having a highly urgent access specification, it may be out of schedule.

  After S33, the child task executes an I / O request issue process (S34).

  FIG. 7B shows an example of the flow of I / O request issue processing.

  The child task inserts an I / O request into the schedule target queue (S34-2) when giving a schedule flag ("Yes" in S34-1), and does not add a schedule flag ("S34-1" No ”), an I / O request is inserted into the non-scheduled queue.

  Here, the schedule target queue and the non-schedule queue are queues that the I / O optimization unit 27 has.

  FIG. 8 is an explanatory diagram of the I / O optimization unit 27.

  The I / O optimization unit 27 includes a non-scheduled queue 61A and a scheduled queue 61B. The priority of the non-scheduled queue 61A (in other words, the urgency of issuing an I / O request) is higher than the priority of the scheduled queue 61B. The I / O request 63 excluded from the schedule is stored in the non-scheduled queue 61A by the query execution unit 9, and the I / O request 63 set as the schedule target is stored in the query execution unit 9 in the schedule target queue 61B. Stored by.

  The flow of processing performed by the I / O optimization unit 27 will be described below with reference to FIGS. 9A, 9B, 10A, and 10B. At that time, FIG. 8 is also referred to as appropriate.

  FIG. 9A shows an example of the flow of processing performed by the I / O optimization unit 27.

  The I / O optimization unit 27 waits for an event that matches at least one of the conditions 1 to 3 to occur (S41). Here, the condition 1 is that an I / O request is stored in the non-scheduled queue 61A. Condition 2 is arrival of a schedule cancel command. Condition 3 is the establishment of a batch scheduling drive condition described later.

  When an event that matches at least one of the above conditions 1 to 3 occurs, the I / O optimization unit 27 determines a condition that matches the generated event (S42), and is determined. Execute the process according to the conditions. That is, the I / O optimization unit 27 executes the immediate issue process when it is determined that the condition 1 is satisfied (S43), and executes the schedule cancel process when it is determined that the condition 2 is satisfied. If it is determined that the condition 3 is satisfied (S44), batch schedule processing is executed (S45). When a plurality of conditions are matched, for example, the I / O optimization unit 27 can preferentially execute a process corresponding to a condition with a high priority. For example, in the case where condition 1 has a higher priority than condition 3, and an event that matches both condition 1 and condition 3 occurs, the I / O optimization unit 27 corresponds to condition 1 The immediate issue process can be executed before the batch schedule process corresponding to the condition 3.

  FIG. 9B shows an example of the flow of immediate issue processing.

  The I / O optimization unit 27 extracts all I / O requests from the non-scheduled queue 61A (S43-1), and issues the extracted I / O requests using the system call of the OS 15 (S43-2). ). As a result, an I / O request is issued to the external storage device 19. This immediate issuance process is performed every time the I / O optimization unit 27 detects that an I / O request is stored in the non-scheduled queue 61A. The stay time of I / O requests is short.

  FIG. 10A shows an example of the flow of schedule cancellation processing.

  As indicated by a dotted line in FIG. 8, the I / O optimization unit 27 acquires the I / O request 63T specified by the schedule cancel command from the schedule target queue 61B (S44-1), and acquires the acquired I / O The O request 63T is inserted into the non-scheduled queue 61A (S44-2). The insertion position may be anywhere. For example, it may be the tail of one or more I / O requests existing in the non-scheduled queue 61A, may be the head, or may be an arbitrary position between them.

  FIG. 10B shows an example of the flow of batch schedule processing.

  As described above, this batch schedule process is started when the batch scheduling drive condition is satisfied. As the batch scheduling driving condition, for example, a condition that a predetermined time has elapsed since the batch scheduling process was performed immediately before or the usage rate of the schedule target queue 61B has become a predetermined value or more can be employed.

  The I / O optimization unit 27 changes the order of the plurality of I / O requests stored in the schedule target queue 61B to the order for optimizing the total data read time length of the plurality of I / O requests. Rearrange (S45-1). This rearrangement can be performed based on the mapping information described above, for example. Specifically, for example, the I / O optimization unit 27 identifies the access destination LBA for each I / O request, and rearranges them in an order that minimizes the disk seek time length in the external storage device 19. Can do. The rearrangement target can be, for example, an I / O request that exists in the schedule target queue 61B at the time when the batch schedule process is started. In this case, even if an I / O request enters the schedule target queue 61B after starting the batch schedule process, the I / O request is not subject to reordering in the current batch schedule process, and the batch schedule for the next and subsequent times. In the process, it will be the target of sorting.

  The I / O optimization unit 27 determines whether or not the non-scheduled queue 61A is empty (S45-2), and if it is empty (YES in S45-2), there is an I / O request in the scheduled queue 61B. If it is determined (S45-3) and if there is (“Yes” in S45-3), the I / O request is extracted from the schedule target queue 61B, and the extracted I / O request is issued to the OS 15. If the non-scheduled queue 61A is not empty in S45-2 (NO in S45-2), the I / O optimizer 27 gives priority to the I / O request in the non-scheduled queue 61A. Once the batch schedule processing is finished, the immediate processing of S43 can be executed through S41 and S42 of FIG. 9A.

  The above is the description of the second embodiment. According to the second embodiment, a plurality of I / O requests issued from the query execution unit 9 are temporarily stored rather than transmitted to the external storage device 19 in the order issued from the query execution unit 9. The order of the plurality of accumulated I / O requests is optimized by the I / O optimization unit 27 and then output. As a result, the overall read time length from when a plurality of I / O requests are issued from the query execution unit 9 to when data is read out to the query execution unit 9 can be reduced. Hereinafter, the effects expected in the second embodiment will be described in comparison with the effects expected in the first embodiment. In addition, the following description is only for deepening the understanding of the first embodiment and the second embodiment, and deviates from the technical scope of the present invention simply because the following expected effects are not achieved. It is not a thing. Therefore, FIGS. 11A to 13B used in the description are not necessarily precise descriptions. For example, in the disk seek image diagrams of FIGS. 11B, 12B, and 13B, the time length represented by the unit distance on the horizontal axis is not necessarily the same.

  For example, in the first example, it is assumed that six I / O requests A to F are issued from the query execution unit 9 as illustrated in FIG. 11A. In the first embodiment, since the I / O optimization unit 27 does not exist, in the DBMS 5, as in the second embodiment, the rearrangement of the plurality of I / O requests A to F issued to the OS 15 is performed in the DBMS 5. Not done. In this case, for example, the I / O requests may be rearranged by the kernel of the OS 15 or the function of the external storage device 19. For example, rearrangement may be performed for each group of I / O requests A to C and D to F among all I / O requests A to F. For example, the OS 15 or the external storage device 19 does not know how many I / O requests are received, but waits for a predetermined number or a fixed time, instead of all I / O requests A to F. This is because if the rearrangement of the I / O requests is not performed at the accumulated stage, the host device or the computer program will wait for a long time. In the example of FIG. 11A, when the OS 15 or the external storage device 19 receives the I / O requests A to C, the data is rearranged in the order of “A → B → C” to “B → C → A”. Read. Next, when the OS 15 or the external storage device 19 accepts the next I / O requests D to F, the data is read out in the order of “D → E → F” to “E → F → D”. I do. As a result, as illustrated in FIG. 11B, the disk seek time length for reading data corresponding to the I / O requests A to F can be reduced to some extent (however, as described above, the I / O request is Will be issued in parallel, which is still shorter than the prior art).

  On the other hand, in the second embodiment, as illustrated in FIG. 12A, the order of the plurality of I / O requests A to F issued to the OS 15 is optimized in the DBMS 5. A / O request is issued to the external storage device 19 via the OS 15. Therefore, as illustrated in FIG. 12B, the disk seek time length for reading data corresponding to the I / O requests A to F can be shortened as compared to the first embodiment. In the second embodiment, as in the first embodiment, even if the I / O requests are rearranged by the OS 15 or the external storage device 19, they are rearranged by the I / O optimization unit 27. Since there is a high possibility that the order is the same as the order, the effects illustrated in FIGS. 12A and 12B are expected.

  In the second embodiment, for example, after the I / O request issuance order is optimized by batch schedule processing, an I / O request that is not scheduled is issued, and the I / O request is given priority. When issued from the DBMS 5, the disk seek time length for reading data corresponding to the I / O requests A to F is larger than that when there is no immediate issuance as illustrated in FIGS. 13A and 13B. Can be long. However, it is still possible to shorten the disk seek time length for reading data corresponding to the I / O requests A to F at least conventionally. 13A and 13B, the I / O optimization unit 27 may rearrange the remaining I / O requests A to D and F when the immediate issue of the I / O request E is determined. .

  The third embodiment of the present invention will be described below.

  In the third embodiment, the query execution unit 9 resumes the execution of tasks in the order of reading when a plurality of data is read in the first embodiment (or the second embodiment). Instead, the task execution is resumed in the order in which the data acquisition processing is started. As a method for controlling the order in which task execution is resumed, for example, there is a method using a data acquisition waiting table.

  FIG. 14A shows a configuration example of a data acquisition waiting table in the third embodiment of the present invention.

  The data acquisition waiting table 71 is information stored in the storage resource of the database server 1. The data acquisition waiting table 71 includes a plurality of pieces of waiting information 71R, 71R,. The waiting information 71R includes a data acquisition sequence number and a task ID. The data acquisition order number is a number representing the order in which the data acquisition process is started. The task ID is an ID of a task describing the waiting information 71R.

  FIG. 14B shows a first difference from the process performed by the generated child task in the first embodiment.

  The generated child task inserts waiting information corresponding to itself into the data acquisition waiting table 71 before executing the data acquisition processing (S61). Specifically, the child task, as wait information 71R corresponding to itself, sets the data acquisition sequence number that is the order of starting the data acquisition process of S11 in FIG. 3 and the ID of its own task to wait for data acquisition. Insert into Table 71.

  FIG. 14C shows a second difference from the process performed by the generated child task in the first embodiment.

  When the data is acquired by the data acquisition process, the child task searches the data acquisition waiting table 71 and waits until its own task becomes the oldest waiting task. The waiting information 71R inserted by the user is deleted (S62). Whether or not the oldest waiting task has been reached is determined by determining whether or not the data acquisition sequence number in the waiting information 71R inserted by itself is a lower number among the data acquisition sequence numbers entered in the data acquisition waiting table 71. This can be specified. As another method, for example, when the data acquisition waiting table 71R is a queue, and the waiting information 71R written by itself becomes the head address, it is determined that the own task is the oldest waiting task. Also good.

  With the above processing, when the plurality of child tasks generated are waiting for data in the data acquisition process, the execution is not resumed in the order in which the data was acquired, but in the order in which the data acquisition process was started. It will be resumed. Specifically, for example, as illustrated in FIG. 15A, when the I / O requests A to F are issued in the same order as the start order of the data acquisition processing, for example, the I / O request is different from the order. Even if data B, C is acquired as a response to I / O requests B, C before data A corresponding to A, execution of tasks B, C that process data B, C is resumed. After the data A is acquired and the execution of the task A that processes the data A is resumed, the execution is resumed in the order of the tasks B and C (note that the disk seek image is as illustrated in FIG. 15B) For example, the same as the first embodiment). Thus, in the third embodiment, the execution of each task can be resumed in the same order as the start order of the data acquisition process.

  As mentioned above, although several suitable Example of this invention was described, it cannot be overemphasized that this invention is not limited to those Examples, and can be variously changed in the range which does not deviate from the summary. Absent.

  For example, in the second embodiment, when the I / O optimization unit 27 receives another type of predetermined cancel command, the I / O request specified by the cancel command or the non-scheduled queue 61A All I / O requests remaining in the queue may be taken out from the non-scheduled queue 61A, and the retrieved I / O requests may be stored in the scheduled queue 61B.

  Further, for example, in each embodiment, the processing of the DBMS 5 can be executed by a processor that has read it. Specifically, for example, a processor that executes a parent task generates a child task on a storage resource (for example, a memory) of the database server 1 and reads and executes the child task, for example, after S11 in FIG. Processing can be executed.

  In addition, for example, the execution task management unit 13 calculates the number of remaining steps (for example, the number of OPs remaining until the last OP) based on the query plan at a predetermined timing, and the task having a small number of remaining steps. You may raise the priority. In this case, for example, it is possible to preferentially generate a task whose priority is increased by the processing of S2 and S3 in FIG. Also, since the task has a high priority, when issuing an I / O request, the issued I / O request can be inserted into the non-scheduled queue 61A.

  Further, for example, in the second embodiment, three or more queues with different priorities may be prepared instead of the two types of queues for the schedule target and the non-schedule target. In this case, the query execution unit 9 may determine a schedule flag having a value corresponding to the priority of the I / O request, and store the I / O request in a queue corresponding to the determined schedule flag value. .

  Further, for example, in the second embodiment, the I / O optimization unit 27 may exist outside the DBMS 5. Specifically, for example, the I / O optimization unit 27 may be interposed between the DBMS 5 and the OS 15. The I / O optimization unit 27 can accept a plurality of I / O requests issued from the DBMS 5. Further, the I / O optimization unit 27 may receive an I / O request from the AP 3 as well. The I / O optimization unit 27 rearranges the received plurality of I / O requests (issuer is DBMS5 or AP3) in an order different from the accepted order, and sends the I / O request to the OS 15 in the order after the rearrangement. Can be issued.

  Further, for example, the database management system may be constructed on one computer machine or may be constructed on a plurality of computer machines. Specifically, for example, the processing of the DBMS 5 in each embodiment can be similarly applied to a parallel DBMS operating in parallel on a plurality of computers. In parallel DBMS, after a query plan is generated by a query generation unit, processing is assigned to a plurality of DBMS servers. Therefore, each DBMS server can reduce the query execution time by processing I / O requests in parallel while generating a plurality of tasks using the technology of the present invention. It is.

DESCRIPTION OF SYMBOLS 1 ... Database server 3 ... Application program 5 ... Database management system 7 ... Query reception part 9 ... Query execution part 11 ... Query plan production | generation part 12 ... Database buffer 13 ... Execution task management part 15 ... Operating system 17 ... Communication network 19 ... External Storage device 21 ... Database 23 ... Table 25 ... Index 27 ... I / O optimization unit 61A ... Non-scheduled queue 61B ... Schedule-targeted queue 63 ... I / O request

Claims (10)

A query acceptance unit for accepting queries,
A query execution unit that executes the accepted query, and issues a data read request for reading database data from the storage device, if necessary,
The query execution unit
The task is dynamically generated and the generated tasks are executed in parallel.
In each task execution, each time the data of the database is required, a task for acquiring the data is generated,
In the execution of the generated task, if necessary, issue the data read request for reading data from the database.
Database management system. The query execution unit waits for generation of a new task when the existing number of tasks in a predetermined situation reaches a predetermined number, and generates the new task when the existing number decreases. ,
The database management system according to claim 1. A plurality of data read requests issued from the query execution unit are received, and the received data read requests are different from the order in which the plurality of data read requests are received. It further comprises a read order control unit that issues in an order for shortening.
The database management system according to claim 1. A plurality of queues having different priorities,
The query execution unit stores the data read request in a queue corresponding to a priority meeting a predetermined condition among the plurality of queues by executing the generated task,
The read order control unit issues data read requests stored in a high priority queue with priority.
The database management system according to claim 3. The read order control unit, when receiving a predetermined command, moves at least one read request stored in a queue with a certain priority to a queue with another priority,
The database management system according to claim 4. The query execution unit determines in which priority queue the read request is stored according to the content of the execution plan of the received query or the performance requirement required for the execution of the received query.
The database management system according to claim 4. A task management unit that calculates the number of remaining steps based on the query execution plan and raises the priority of the task with the small number of remaining steps calculated;
The query execution unit stores a read request issued by executing a task with an increased priority in a queue corresponding to the priority.
The database management system according to claim 4. In the execution of each generated task, the query execution unit waits for the acquisition of data in the database, and after acquiring the data, resumes the execution of tasks in the same order as the order in which the data acquisition wait was started ,
The database management system according to claim 1 or 3. Receiving a query;
A query execution step of executing the accepted query, and issuing a data read request for reading the data of the database from the storage device, if necessary, in the query execution step,
Dynamically generate tasks, execute multiple generated tasks in parallel,
In each task execution, each time the data of the database is required, a task for acquiring the data is generated,
In the execution of the generated task, if necessary, issue the data read request for reading data from the database.
Database management method. A database management system according to claim 1;
A plurality of data read requests issued from the database management system are received, and the received data read requests are different from the order in which the plurality of data read requests are received, and the overall data read time length is set. A computer system comprising: a reading order control unit that issues in an order for shortening.

Images