JP2013003695A - Distributed database retrieval device, distributed database retrieval method and program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a distributed database retrieval device which realizes an effective search without complicating a mechanism of a master server side.SOLUTION: A distributed database retrieval device is composed by connecting plural slave servers each having a data base to a master server searching the data bases based on an input query. The slave server comprises: a second transmitter-receiver to perform data transmission/reception with the master server; a local plan candidate generation part to generate a local plan candidate based on a received dispersion plan; and a local plan selection part to determine a local plan that computing cost is the lowest based on the generated local plan candidate.

Description

  Embodiments described herein relate generally to a distributed database search device, a distributed database search method, and a program.

  There is a distributed database search device composed of a plurality of servers in order to handle a large amount of data such as a table format and an XML format. A distributed database search apparatus is generally composed of a master server that communicates with users and a slave server that actually manages data.

  All of the slave servers may be composed of database retrieval apparatuses having the same architecture, or may be composed of database retrieval apparatuses having different architectures.

  Generally, when a search expression (hereinafter referred to as a query) is input to the distributed database search device, the query is received by the master server. The master server analyzes the query and divides it into a part that each slave server executes inside the server and a part that needs to be operated between the servers. Each slave server generates an optimal local plan for the part executed in each slave server. The master server generates an optimal distributed plan for the calculation part between servers. The local plan is a plan for the slave server to search for data held by the slave server, and the distributed plan is a plan for searching the entire data of the target distributed database.

  When generating a distributed plan, the order of operation processing such as join operation processing for data between servers such as JOIN, set operation processing for a plurality of servers such as SORT, and join operation processing of divided partial queries is executed. The search response time is determined to be the shortest. Further, a data transfer method, a format, and the like to the server that executes the calculation are determined.

  In distributed databases, there is a demand to reduce the data transfer cost in data transfer processing between these databases and the data calculation cost between servers by strengthening the optimization of the distributed plan to improve search performance. is there.

  Conventionally, all optimization of distributed plans has been realized by a master server. However, there are many problems for the master server to determine all of the distributed plans.

  First of all, since the scope of consideration of distributed plans is very wide, such as the query division range, determination of the order and execution location of operations between servers, and the method of joining the divided queries as mentioned above, many candidate plans are generated. Therefore, it takes a lot of information to search for an optimal plan. For this reason, the master server needs to closely acquire, maintain, and manage indexes and statistical information from each slave server. Therefore, the structure of the master server is complicated and requires a high management cost.

  Also, even when all the information desired by the master server is acquired, there is a possibility that the optimum operation may be different for each slave server if the statistics are greatly different for each slave server or if the architecture is different. In such a case, in a distributed plan unified for all slave servers, the execution speed of some slave servers may become a bottleneck and the overall performance may be reduced. However, generating a distributed plan that can perform optimal operation for each slave server complicates the mechanism for generating the distributed plan of the master server. That is, if the optimization function of the distributed plan processing unit of the master server is improved, the mechanism for optimizing the master server becomes complicated. For this reason, it is difficult for the master server to generate a distributed plan in a form suitable for each state of each slave server.

JP 2001-331485 A Japanese Patent Application Laid-Open No. 07-141399

  The problem to be solved by the present invention is to provide a distributed database search device that realizes efficient search without complicating the mechanism on the master server side.

  The distributed database search apparatus according to the embodiment is configured by connecting a master server that searches a database based on an input query query and a plurality of slave servers that include the database. A second transmission / reception unit that performs transmission / reception, a local plan candidate generation unit that generates a local plan candidate based on the received distributed plan, and a local that determines a local plan with the lowest calculation cost based on the generated local plan candidate A plan selection unit.

It is an example of the whole block diagram of the distributed database search device concerning a 1st embodiment. It is a schematic diagram which shows an example of the XML data which is one of the data registered into the database which concerns on 1st Embodiment. It is a schematic diagram which shows an example of the XML data which is one of the data registered into the database which concerns on 1st Embodiment. It is a schematic diagram which shows an example of the database information which the slave server which concerns on 1st Embodiment hold | maintains. It is a schematic diagram which shows an example of the slave server group information which the master server which concerns on 1st Embodiment hold | maintains. It is a flowchart which shows an example of the distributed database search process which concerns on 1st Embodiment. It is a schematic diagram which shows an example of the query language XQuery with respect to XML which concerns on 1st Embodiment. It is a figure which shows an example of the partial query produced | generated in the query division part which concerns on 1st Embodiment. It is a figure which shows an example of the dispersion | distribution plan produced | generated in the dispersion | distribution plan production | generation part which concerns on 1st Embodiment. It is a flowchart figure which shows an example of the distributed plan correction process by the division | segmentation query combination calculation addition part which concerns on 1st Embodiment. It is a schematic diagram which shows an example of the distributed plan in which the division | segmentation query combination operation addition process which concerns on 1st Embodiment was performed. It is a schematic diagram which shows an example of the local plan produced | generated in the local plan selection part which concerns on 1st Embodiment. It is a flowchart figure which shows an example of the local plan candidate production | generation process which concerns on 1st Embodiment. It is a flowchart figure which shows an example of the local plan candidate production | generation process which concerns on 1st Embodiment. It is a flowchart figure which shows an example of the local plan candidate production | generation process which concerns on 1st Embodiment. It is a schematic diagram which shows an example of the local plan produced | generated in the local plan candidate production | generation part which concerns on 1st Embodiment. It is a schematic diagram which shows an example of the local plan produced | generated in the local plan candidate production | generation part which concerns on 1st Embodiment. It is a schematic diagram which shows an example of the local plan produced | generated in the local plan candidate production | generation part which concerns on 1st Embodiment. It is a schematic diagram which shows an example of the local plan produced | generated in the local plan candidate production | generation part which concerns on 1st Embodiment. It is a schematic diagram which shows an example of the local plan produced | generated in the local plan candidate production | generation part which concerns on 1st Embodiment. It is a schematic diagram which shows an example of the local plan produced | generated in the local plan candidate production | generation part which concerns on 1st Embodiment. It is a flowchart figure which shows an example of the parameter used when calculating the calculation cost in the local plan candidate production | generation part which concerns on 1st Embodiment. It is a flowchart figure which shows an example of the process in which the distribution plan update part which concerns on 1st Embodiment updates a distribution plan. It is a schematic diagram which shows an example of the distribution plan updated in the distribution plan update part which concerns on 1st Embodiment. It is an example of the whole block diagram of the distributed database search device concerning a 2nd embodiment. It is a schematic diagram which shows an example of the schema before being changed by the schema change part which concerns on 2nd Embodiment. It is a flowchart which shows an example of the distributed database search process which concerns on 2nd Embodiment. It is a schematic diagram which shows an example of the local plan with which the local plan order determination process which concerns on 2nd Embodiment was performed. It is a flowchart figure which shows an example of the process which the schema production | generation part which concerns on 2nd Embodiment produces | generates the schema of a distributed plan. It is a schematic diagram which shows an example of the new schema changed in the schema change part which concerns on 2nd Embodiment. It is a flowchart figure which shows an example of the process in which the schema change part which concerns on 2nd Embodiment updates the schema of the data input into calculation of a distributed plan. The figure which shows an example of the input-output schema obtained as a result of performing the schema production | generation process by the schema change part which concerns on 2nd Embodiment.

  Hereinafter, a distributed database search apparatus according to an embodiment will be described with reference to the drawings.

(First embodiment)
FIG. 1 is a configuration diagram illustrating a functional configuration of the distributed database search apparatus according to the first embodiment. The distributed database search device of this embodiment performs a search based on a search expression (hereinafter referred to as a query query) input from a user, and outputs a search result.

  As shown in FIG. 1, the distributed database search apparatus of this embodiment is configured by connecting a computer 0 that functions as a master server and computers 1 to N that function as slave servers.

  The computer 0 which is a master server includes a syntax analysis unit 11, a query division unit 12, a distributed plan generation unit 13, a divided query join operation addition unit 14, a distributed plan update unit 15, a distributed plan execution unit 16, A transmission / reception unit 17 (first transmission / reception unit) and an information storage unit 20 (first storage device) are provided.

  The information storage unit 20 includes a slave server group information storage unit 21 that stores slave server group information, and a distributed plan storage unit 22 that stores a distributed plan to be described later. Note that the slave server group information is information about the database held by the slave server, such as the names and positions of all slave servers, and the number of registrations, and is part of the database information held by the slave server. The master server determines which data is to be transmitted to the slave server based on the slave server group information.

  The syntax analysis unit 11 parses the query query 51 given by the user.

  The query dividing unit 12 has a function of dividing the query query 51, and based on the result of the syntax analysis of the query query 51 by the syntax analysis unit 11 and the slave server group information table 21, a unit of intra-server operation and inter-server operation The query query 51 is divided by The divided query 51 is referred to as a partial query. The intra-server operation means that the query 51 is processed in each slave server. The inter-server calculation is a process of collecting data from a plurality of slave servers and calculating in the master server.

  The distributed plan generating unit 13 functions as a distributed plan generating unit, and generates a distributed plan based on the partial query obtained by the query dividing unit 12 and information in the slave server group information table 21. That is, the distributed plan generation unit 13 calculates the operation order of the divided intra-server operation and inter-server operation based on the name and position of the slave server stored in the slave server group information storage unit 21 and the number of registrations. Then, a distributed plan in which the contents of the data to be transmitted / received between the execution location and the server is determined is generated. The contents of data transmitted / received between servers include, for example, slave server data, a part of slave server data, the result of operation of slave server data such as an average value, or the maximum value and data of a plurality of slave servers. It is a result of calculation between servers, such as a combination.

  The distributed plan generating unit 13 includes a divided query join operation adding unit 14 and a distributed plan updating unit 15.

  The divided query join operation adding unit 14 modifies the distributed plan obtained by the distributed plan generating unit 13 according to the divided query join operation adding process shown in the flowchart of FIG. Hereinafter, the modified distributed plan is referred to as a modified distributed plan. The split query join operation addition process will be described later.

  The distributed plan update unit 15 functions as a distributed plan update unit, and performs a distributed plan update process for updating the modified distributed plan based on the local plan selection unit and the local plan sent from the slave server. The distributed plan correction process will be described later.

  The distributed plan execution unit 16 executes a calculation based on the distributed plan updated by the distributed plan update unit 15.

  The transmission / reception unit 17 functions as a data transmission / reception unit.

  Next, computers 1 to N that are slave servers will be described.

  The computers 1 to N function as slave servers, and include a local plan selection unit 31, a local plan candidate generation unit 32, a local plan execution unit 33, a transmission / reception unit 34 (second transmission / reception unit), and information storage. Unit 40 (second storage device).

  The information storage unit 40 includes a database information storage unit 41 that holds database information that is information related to data stored in a database such as schema information of stored data and statistical information such as the number of cases, and a local plan storage that holds a local plan And a storage data storage unit 43 that holds actual data to be searched (hereinafter referred to as storage data).

  The local plan selection unit 31 functions as a local plan generation unit, and includes a local plan candidate generation unit 32. The local plan selection unit 31 generates a local plan made up of partial plans related to its own server among the modified distributed plans obtained by the split query join operation addition unit 14. Based on the local plan generated by the local plan selection unit, the local plan candidate generation unit 3 further creates a local plan candidate. The local plan selection unit 31 calculates a calculation cost including an estimated execution time or an estimated execution calculation amount from the local plan created by itself and the local plan candidate created by the local plan candidate generation unit 32. The local plan selection unit 31 determines the plan that minimizes the calculated calculation cost as the local plan.

  The local plan execution unit 33 performs a calculation based on the local plan obtained by the local plan selection unit 31. The transmission / reception unit 34 has the same function as the transmission / reception unit 17 of the master server.

  Here, FIGS. 2 and 3 show an example of data registered in the stored data storage unit 43 of the slave server. Note that the data registered in the stored data storage unit 43 of the slave server of this embodiment is described in the XML format. The data shown in FIG. 2 is data related to the publication year, title, author, and price of the book. The data shown in FIG. 3 is data relating to the award year of a certain award, the winner, the title of the book that has been awarded, and the gender of the winner.

  FIG. 4 is an example of database information held by the data information storage unit 41 of the slave server. As shown in FIG. 4, the database information is held as a database information table 111 having items of “registration node” 112, “number of registrations” 113, and “index information” 114.

  The “registered node” 112 indicates a node name included in the XML data registered in the stored data storage unit 43 of the slave server, and is described here including under which node. Note that a node is an element or attribute that constitutes XML data.

  “Registered number” 113 indicates the number of times each registered node 112 appears in the XML data registered in the stored data storage unit 43 of the slave server.

  “Index information” 114 describes the type of index set for the registration node 112. The index type is, for example, a numerical index or a character index. FIG. 4 shows database information tables 111-1 to 111-4 of the computers 1 to 4 as an example.

  FIG. 5 is an example of the slave server group information 21 stored in the slave server group information storage unit 21 held by the computer 0 that is the master server. As shown in FIG. 5, the slave server group information is held as a slave server group information table 121 having items of “server name” 122, “Collection information” 123, and “number of registered documents” 124.

  The “server name” 122 stores the name of the slave server. The “Collection information” 123 stores the name of the storage location of the registered XML data (hereinafter referred to as “Collection name”). Since the distributed database of the present embodiment can have the same collection information 123 even in different slave servers, the user can search within a set of specific XML data by specifying the collection name. “Registered document count” 124 stores the number of XML data registered in the collection.

  Here, with reference to FIG. 6 to FIG. 25, processing of the distributed database search device of this embodiment will be described. FIG. 6 is a flowchart illustrating an example of a search process of the distributed database search apparatus according to this embodiment. In the distributed database search device of this embodiment, it is assumed that the database information shown in FIG. 4 is stored in the database information storage unit 41 of the computers 1 to 4.

  First, a query query 51, which is a search expression, is input to the master server by the user (step S1).

  Here, FIG. 7 shows an example of the query query 51 input by the user. The query 51 shown in FIG. 7 is described in XQuery, which is a query language for XML data. The query 51 shown in FIG. 7 means “output the title and price of a book published since 1990 among the books of male authors who have received awards”.

  One sentence starting from “for” in the first line of the input query query 51 is a node having a book name registered in the collection “publisher”, and the value of the attribute node “year” is more than 1990. The node is stored in the variable $ x. As a result, a list of books published since 1990 is acquired. In XQuery, a variable is expressed as a character string starting with “$”.

  Next, one sentence starting from “for” on the second line is a character string “male” obtained by converting the value of a child node named “generator” into a character string from among the nodes having the name “prizeWinner” registered in the collection “prizeWinners”. Is selected, the child node name is stored in the variable $ y, thereby obtaining a list of names of male writers who have received awards. Next, the author, title, and price nodes that are child nodes of the book acquired on the first line in the first sentence starting from the let on the third, fourth, and fifth lines are stored in the variables $ z, $ u, and $ v, respectively. The book author name, title, and price are obtained. Next, in the first sentence starting with “where” on the 6th line, a combination of a male writer whose name matches the author's name is obtained. Finally, in one sentence starting from “return” on the 7th line, an XML surrounded by a node with the name of List is created for the combination acquired on the 6th line and returned to the user. As a result, the title and price of the book that satisfies the conditions are acquired.

  When the query query 51 shown in FIG. 7 is input to the master server, the syntax analysis unit 11 of the master server parses the query query 51 (step S2). The result of parsing by the parsing unit 11 is transmitted to the query dividing unit 12 of the master server.

  The query division unit 12 that has received the parsing result, based on the information in the slave server group information table 21, performs an in-server operation for processing the query query 51 in each slave server and a server that collects and calculates data from a plurality of slave servers. A query query 51 dividing process is performed to divide into partial queries in the unit of inter-operation (step S3).

  That is, the query dividing unit 12 divides the query query 51 into partial queries based on the result of syntax analysis by the syntax analyzing unit 11. The query division unit 12 refers to the slave server group information table 121 to determine whether the partial query content is an inter-server operation or an intra-server operation for each partial query. Here, FIG. 8 shows an example of the partial query one column table 131 that is a list of partial queries that are the results of the division by the query dividing unit 12.

  The partial query list table 131 shown in FIG. 8 includes a “number” 132 for storing numbers sequentially assigned to partial queries, a “partial query content” 133 for storing partial queries obtained by division, and partial queries in the server. It has items of “inter-server / intra-server operation” 134 for storing whether the operation is an operation between servers or “corresponding server” 135 for storing the name of a computer storing data necessary for the operation.

  Hereinafter, the query query dividing process by the query dividing unit 12 will be described in detail with reference to FIGS.

  Based on the slave server group information table 121, the query dividing unit 12 specifies a computer that holds data used for calculation for each partial query. In FIG. 8, attention is focused on two pieces of collection information of collection (“publisher”) and collection (“prizeWinner”) in the query query 51 shown in FIG. That is, the slave server group information table 121 shown in FIG. 5 is searched using these collection information.

  In other words, the query division unit 12 determines that Collection (“publisher”) exists in the computers 1 to 3 and that Collection (“prizeWinner”) exists in the computer 4.

  Further, the query division unit 12 pays attention to XQuery operations such as “/”, “//”, “> =”, “=” performed on the collection, and whether the operation requires values from a plurality of different computers. Determine. When the operation requires values from a plurality of different computers, this operation is determined as an inter-server operation. In addition, in the case of the calculation performed with the value from one computer, this calculation is determined as the calculation in the server.

  As shown in FIG. 8, in the query 51, operations such as “/”, “//”, “> = 1990” can all be performed on the input data calculator, so that $ x, $ z, $ u , $ V all store data calculated on the same computer. Note that the intra-server computation is divided into several computation units. In FIG. 8, the query is divided in units in which assignment statements such as “for” and “let” are generated, and partial queries of numbers 1 to 5 are generated. Note that the division in units of assignment statements such as “for” and “let” is just an example, and in actuality, the division may be performed in smaller operation units or in larger operation units.

  On the other hand, in the calculation “where $ y = $ z”, it is assumed that $ y is data of the computer 4 and $ z is data in the computers 1 to 3 and thus is an inter-server operation.

  Subsequently, since the next “return <List> {$ u} {$ v} </ List>” is an operation that returns the final result, the computers 1 to 3 having data of $ u and $ v It is determined that an inter-server operation that collects and calculates data is necessary.

  Subsequently, the distributed plan generation unit 13 generates a distributed plan based on the partial query list table 131 shown in FIG. 8 and the slave server group information table 121 shown in FIG. 5 (step S4). The generated distributed plan is stored in the distributed plan table 141.

  FIG. 9 shows an example of the distributed plan table 141.

  The distributed plan table 141 includes “operation number” 142, “partial query number” 143, “operation content” 144, “pre-execution operation number” 145, “execution location” 146, “transmission location” 147, “input variable” 148, It has an item “output variable” 149.

  The “calculation number” 142 indicates a number assigned for each calculation. The “partial query number” 143 stores the number assigned in the item of the partial query number 132 in the partial query table 131 shown in FIG. If the partial query number 132 is not assigned, it is left blank.

  “Operation content” 144 stores the content of each operation. Here, the distributed plan generation unit 13 uses the intra-server operation in the partial query list table 131 shown in FIG. 8 as the intra-server operation as it is, and the inter-server operation in the partial query list table 131 represents a specific operation. Describe the content. Further, before and after the inter-server calculation in the partial query list table 131, data transmission and data reception calculations are required, and are newly added.

  The “pre-execution operation number” 145 stores the operation number when there is an operation that must be executed before the operation is executed. The “execution location” 146 stores a location (computer) where the calculation is executed. In the case of calculation of data transmission and data reception, the transmission destination of the data of the calculation result is stored in “transmission location” 147. That is, the execution location 146 is a computer that is a data transmission source, and the transmission location 147 is a computer that is a data transmission destination.

  The “input variable” 148 is stored when input data is required for the operation, and stores a list of names of variables in which the data is stored. The “output variable” 149 stores a list of names of variables to be stored when the operation creates a new value.

  Note that the operation numbers 1 to 5 in the distributed plan table 141 illustrated in FIG. 9 correspond to the numbers 1 to 5 in the partial query list table 131 illustrated in FIG. The operation numbers 10 and 11 in the distributed plan table 141 correspond to the numbers 6 and 7 in the partial query list table 131 shown in FIG.

  In addition, in the partial query list table 131, the operation of the partial query number 6 stored in the intra-server / inter-server operation 134 is stored as “inter-server JOIN” in the operation content 144. That is, the specific calculation content based on the partial query content 133 is stored. Similarly, the calculation of partial query number 7 stores a specific calculation “return data creation” in the calculation content 144. Note that “inter-server JOIN” is an operation that leaves the same combination of data stored in two variables, and “return data creation” is an operation that creates new XML data using the input data. It is.

  The distributed plan generation unit 13 pays attention only to “inter-server computation” and determines the execution order and execution location. Specifically, in the distributed plan table 141 shown in FIG. 9, since the calculation contents 144 of the inter-server calculation are two types of JOIN between servers and return data creation, the return data creation calculation is executed after executing the server-to-server JOIN. It is determined that the target is less efficient and the efficiency is better.

  Further, in the present embodiment, the execution location is determined on the assumption that the inter-server calculation is performed by the master server. In addition, in order to perform the calculation between servers by a master server, it is necessary to collect the data in each slave server. Therefore, the distribution plan generation unit 13 adds the calculation number 6 and the calculation number 8 of the distribution plan table 141, and stores “data transmission” that is the calculation in which the slave server sends data to the master server in each calculation content 144. Subsequently, in order for the master server to receive the data transmitted in the calculation numbers 6 and 8, the calculation numbers 7 and 9 are added, and the master server receives the data from the slave server in each calculation content 144. Stores “data received”.

  In the present embodiment, the inter-server calculation is determined to be executed by the master server, but may be determined to be executed by, for example, a plurality of slave servers instead of the master server.

  The distributed plan generation unit 13 stores the input variable 148 and the output variable 149 based on the partial query content 133 described in FIG. For example, a variable written in “for” in “for˜in” and “let˜: =” is an output variable 149, and a variable written elsewhere is an input variable 148. In the data transmission calculation, the input variable 148 becomes the output variable 149. Further, in the data reception calculation, the output variable 149 of the data transmission calculation becomes an input variable 148 and an output variable 149.

  The intra-server operations are arranged in an arbitrary order so that the order relation is not broken by the distributed plan generation unit 13. As described above, the distributed plan generation unit 13 of this embodiment considers only “inter-server operation” of the partial query list table 131. Since the examination range is thereby limited, the distributed plan generation unit 131 can easily generate a distributed plan.

  Next, the split query join operation addition unit 14 adds a “split query join” operation to the distributed plan generated by the distributed plan generation unit 13 and performs split query join operation addition processing for correcting the distributed plan ( Step S5).

  Here, with reference to FIG. 10, the operation when the split query join operation adding unit 14 performs the split query join operation adding process on the distributed plan stored in the distributed plan table 141 shown in FIG. 9. This will be specifically described.

  Note that variables i and j are used in this split query join operation addition process. i is an integer greater than or equal to 1, and is less than or equal to the operation number of the target distributed plan (1 ≦ i ≦ maximum value of operation numbers of the distributed plan). Also, i = 1 at the start of the split query join operation addition process. In addition, the maximum value of the calculation number of the distributed plan is “max”. In addition, the calculation of the distributed plan whose operation number 142 is i is defined as operation E. Note that j is a variable having the same property as i, and an operation of a distributed plan whose operation number 142 is j is an operation S.

  When the split query join operation addition unit 14 receives the distribution plan from the distribution plan generation unit 13, first, i = 1 is set as the initialization process, and the maximum value of the operation number of the distribution plan is set to max (step S10).

  The divided query join calculation adding unit 14 acquires the calculation E of the calculation number i in the distributed plan table 141 described in FIG. 9 (Step S20). Next, the divided query join operation adding unit 14 determines whether or not the acquired operation E is an inter-server operation and i ≠ max (step S30).

  When the acquired operation E is an inter-server operation and i ≠ max, that is, when the operation E is other than the last operation (step S30 is Yes), j: = 1 is set (step S40).

  Next, the operation S of the operation number j in the distributed plan table 141 is acquired (step S50). The divided query join operation adding unit 14 refers to the distributed plan table 141 of FIG. 9 to determine whether the operation content 144 of the operation S is data transmission and whether the computer stored in the transmission location 147 is a slave server. (Step S60).

  When the calculation content 144 of the calculation S is “data transmission” and the computer at the transmission location 147 is a slave server (Yes in step S60), the split query join calculation addition unit 14 adds the input variable 147 of the calculation S and the calculation E A list (hereinafter referred to as varList) storing variables that appear in common with the input variable 147 is created (step S70). Next, a list (hereinafter referred to as “newVarList”) storing variables excluding variables in varList from the input variable 147 of the operation S is created (step S80). The split query join operation addition unit 14 creates a new VarList variable and a new VarList variable in which the created varList is not empty and the variable included in the varList does not completely match the input variable 147 of the operation S and the variable of the varlist is output. It is determined whether or not the operation for outputting can be executed in parallel (step S90).

  Here, a description will be given of a method for determining whether or not an operation that outputs a variable of a variable and an operation that outputs a variable of a newVarList can be executed in parallel in the distributed plan table 141 shown in FIG. In this method, when the pre-execution operation number 145 of one operation and the pre-execution operation number 145 of the operation of this pre-execution operation number 145 are repeatedly examined, the other operation does not exist as the pre-execution operation number. In addition, it is determined that the two operations can be executed in parallel. In other words, if there is an operation number of operation B in the pre-execution operation number 145 of operation A, since operation A must be executed after operation B is executed, it is determined that parallel execution is not possible.

  Returning to the description of step S90 in FIG. When varList is not empty, and the variable included in varList does not completely match the input variable 147 of operation S, and the operation that outputs the variable of variable and the operation that outputs the variable of newVarList can be executed in parallel (Step S90 is Yes), the next five operations are inserted after the operation E, and after the insertion, i + 5 is substituted for i (i: = i + 5) (step S100).

  In the first calculation, calculation content 144 is “data transmission”, input variable 148 and output variable 149 are variables included in varList, execution location 146 is “transmission location 147 of calculation S, and transmission location 147 is execution of calculation S. Location 146 ".

  In the second calculation, the calculation content 144 is “data reception”, the input variable 148 and the output variable 149 are variables included in the varList, the execution location 146 is “the transmission location 147 of the calculation S”, and the “transmission location 147 is the calculation S. Execution location 146 ".

  In the third operation, the operation content 144 is “partitioned query combination”, the input variable 148 is a variable included in varList, and the execution location 146 is “the execution location 146 of the operation S”. Note that the operation content “divided query combination” is an operation for re-combining the results obtained by separately processing a certain variable in parallel.

  In the fourth calculation, the calculation content 144 is “data transmission”, the input variable 148 and the output variable 149 are variables included in the newVarList, the execution location 146 is “execution location 146 of the calculation S”, and the transmission location 147 is the calculation S. Is the transmission location 147 ".

  In the fifth calculation, the calculation content 144 is “data reception”, the input variable 148 and the output variable 149 are newVarList, the execution place 146 is “the execution place 146 of the calculation S”, and the transmission place 147 is “the transmission place of the calculation S”. is there.

  Next, three processes are performed in order to change the variable transmitted by the calculation S (step S110). The first is to change the contents of the input variable 148 and the output variable 149 of the operation S to the value of varList. The second obtains the next operation R after the operation S. The operation R is an operation of the operation content 144 “data reception” corresponding to the operation S. Third, the contents of the R input variable 148 and output variable 149 lists are changed to the value of varList. Thereafter, the process proceeds to step S120.

  Note that also when the calculation S is not data transmission or the computer at the execution place 146 is not a slave server (No in step S60), the process proceeds to step S120.

  Also, when varList is empty, or an operation that outputs a variable of varlist and an operation that outputs a variable of newVarList cannot be executed in parallel (when Step S90 is No). The process proceeds to step S120.

  In step S120, the divided query join operation adding unit 14 substitutes j + 1 for j (j: = j + 1) (step S120). That is, step S120 is performed when step S60 is No or when step S90 is No or after step S110.

  Subsequent to step S120, the split query join operation adding unit 14 determines whether j is smaller than i (step S130). When j is smaller than i (step S130 is Yes), the process returns to step S50 and is repeated. When j is not smaller than i (No in step S130), the process proceeds to step S140, and i + 1 is substituted for i (i: = i + 1) (step S140).

  When the calculation E is not an inter-server calculation or i = max (No in step S30), the process proceeds to step S140. That is, the process of step S140 is performed subsequently when step S130 is No or when step S30 is No.

  Subsequent to step S140, the split query join operation adding unit 14 determines whether i is equal to or less than max (step S150). That is, it is determined whether the divided query calculation addition processing has been performed for all partial queries.

  When i is less than or equal to max (step S150 is Yes), the divided query join operation adding unit 14 returns to step S20 and repeats the process. When i is larger than max (step S150: No), the split query join operation adding unit 14 ends the process.

  Here, in FIG. 11, as a result of the split query join operation addition unit 14 performing the above-described split query join operation addition processing on the distributed plan shown in FIG. An example).

  In the distributed plan described in the distributed plan table 141 in FIG. 9, since the operations 1 to 10 are not server-to-server operations, the divided query join operation adding unit 14 increases by 1 until i becomes 10 (FIG. 10). Step S20, Step S30, Step S140, Step S150).

  When i = 10, since the operation E is an inter-server operation (Yes in step S30), 1 is substituted into the variable j (step S40). Whether or not the operation E is an inter-server operation is determined with reference to the distributed plan table 141 based on the partial query number of the operation E.

  Next, since j is not a data transmission until j reaches 6, j is incremented by 1 (No in step S50 and step S60, step S120 and step S130).

  When j is 6, since the operation content of the operation S is data transmission and the computer at the execution place 146 is a slave server (Yes in step S60), the input variable 148 of the operation number 6 and the input variable 148 of the operation number 10 are common. A variable list varList that stores the variable $ z that appears in step S70 is created (step S70).

  A variable list newVarList storing the variables $ u and $ y obtained by removing the variable list of varList from the obtained input variable 148 of the operation number 6 is created (step S80).

  Since varList is not empty, does not completely match the input variable list of operation number 6, and operations that output variables of varlist and newVarList can be executed in parallel, five operations of operation numbers 11-15 in FIG. 11 are added. After that, i is incremented by 5 and 15 is substituted (step S90, step S100). Next, the value variable $ z of varList is substituted into the input variable 148 and the output variable 149 of the data transmission of the operation number 6 and the data transmission of the operation number 7 (step S110).

  Next, since j is not data transmission until j reaches 8, the variable j is simply increased by 1 (step S50, step S60, step S120, step S130). When j is 8, since the operation content 144 is data transmission and the execution place 146 is a slave server, the variable list varList storing the variable $ y that appears in common in the input variable of the operation number 8 and the input variable list of the operation number 10 is stored. Obtain (step S70).

  Although the acquired varList is not empty, it completely matches the input variable list of operation number 8 (No in step S90), so 1 is added to j (step SS120). Since there is no further data transmission calculation, i is incremented by 1 and 16 is substituted (step S120, step S130, step S140, step S150).

  Next, the calculation in which i is 16 is an inter-server calculation, but since i is equal to max (Yes in step S150), the process is repeated in step S20. When the value of i exceeds max (No in step S150), the split query join operation adding unit 14 ends the process. As a result, a distributed plan is created. FIG. 11 shows a table 151 of the modified distributed plan. That is, the distributed plan combination operation addition unit 14 executes the inter-server operation and other operations in parallel as much as possible, and rewrites the plan so that it is combined later.

  As described above, when the split query join operation addition unit 14 corrects the distribution plan, the transmission / reception unit 17 of the master server transmits the corrected distribution plan to the slave server. At this time, the modified distribution plan may be transmitted to all slave servers. Alternatively, the modified distribution plan may be transmitted only to the related slave server with reference to the execution location.

  The local plan selection unit 31 of the slave server generates a local plan candidate for a portion related to its own server in the distributed plan modified by the received divided query combination procedure adding unit 14 (step S6).

  Here, the local plan candidates generated by the local plan selection unit 31 are illustrated in FIG. The local plan candidate 2 shown in FIG. 12 is generated by the local plan selection unit 31 of the slave server that is the computer 2 based on the distributed plan shown in FIG. 11 and the database information 111 shown in FIG. It is an example of the local plan candidate regarding.

  As shown in the local plan candidate 2 shown in FIG. 12, the local plan candidate 2 includes “operation number” 302, “partial query number” 303, “operation content” 304, “pre-execution operation number” 305, and “execution location” 306. , “Transmission location” 307, “input variable” 308, and “output variable” 309. Note that items 302 to 309 included in the local plan candidates of the present embodiment and the local plan described later are the same as the items 142 to 149 included in the distributed plan table of the present embodiment.

  In the local plan candidate 2 shown in FIG. 12, in the computer 2, a numerical index is set for the year attribute node under the book from the database information in FIG. Therefore, the process corresponding to the partial query of the first query number 1 and the partial query number 1 is realized by the calculation “numerical index”. The operation "numerical index" is the first node of a node that satisfies a comparison condition with a given numeric value or the document that owns that node for a node that has a numeric index that is obtained by indexing the values of nodes. This is an operation for acquiring a node at high speed.

  Specifically, the local plan selection unit 31 searches for a book node satisfying the condition that the value of the attribute node “year” is 1990 or more from the numerical index and stores it in the variable $ x.

  Operation numbers 2, 4, and 5 perform an operation “TRAVERSE” that processes partial queries of partial query numbers 3, 4, and 5, respectively. The operation “TRAVERSE” is an operation that traces from a certain node (input) to a certain node (output) in XML. Specifically, the author node, title, and price as child nodes are acquired from the book node stored in $ x obtained by the operation number 1 and stored in the variables $ z, $ u, and $ v, respectively. The operation numbers 3, 6, 7, and 8 are the data transmission, data reception, and split query join operations created by the distributed plan as they are.

  Next, a local plan candidate generation process in which the local plan candidate generation unit 32 further generates a local plan candidate based on the local plan candidate 2 in FIG. 12 will be described with reference to FIG. 13 (step S7 in FIG. 6). FIG. 13 is a flowchart illustrating an example of local plan candidate generation processing.

  This local plan candidate generation process uses a variable i. i is 1 or more and is equal to or less than the number of elements in the list of local plan candidates (hereinafter referred to as inputPlanList) generated by the target local plan selection unit 31 (1 ≦ i ≦ number of elements in the inputPlanList).

  First, the local plan candidate generation unit 32 acquires the local plan candidates shown in FIG. 12 (step S200). The local plan candidate generating unit 32 sets i = 1 and the number of elements in the inputPlanList = max (step S210).

  Subsequently, the local plan candidate generation unit 32 acquires the i-th local plan candidate plan from the inputPlanList (step S220). Based on the acquired plan, the local plan candidate generation unit 32 performs a combination pattern generation process of an execution variable for split query combination, which will be described later, and creates a new local plan candidate list including this plan (step S230). The combination pattern generation process of the execution variable of the split query combination is a process of generating various local plan candidates by changing the calculation performed before and after the split query combination, and will be described in detail later with reference to the flowchart of FIG.

  The local plan candidate generation unit 32 acquires a new local plan candidate list (hereinafter, referred to as “nextPlanList”) obtained by the combination pattern generation processing of the execution variables of the split query combination (step S240). Here, a variable called j is used. j is 1 or more and less than or equal to the number of elements in nextPlanList (1 ≦ j ≦ number of elements in nextPlanList). At this time, j = 1 and the number of elements in nextPlanList = finalMax (step S250).

  Next, the local plan candidate generation unit 32 acquires the jth local plan candidate nextPlan from the nextPlanList (step S260). The local plan candidate generation unit 32 performs the execution location pattern generation process of the split query combination based on the acquired nextPlan, and creates a new local plan candidate list including the nextPlan (step S270). The execution location pattern generation process for split query join is a process for generating various local plan candidates by changing the execution place of the split query join operation, and will be described in detail later with reference to the flowchart of FIG.

  The local plan candidate generation unit 32 creates a new local plan candidate list finalPlanList based on the execution location pattern generation processing result of the split query combination (step S280). The local plan candidates in the created finalPlanList are added to the output candidate plan list outputList that is the final output (step S290).

  Next, proceeding to step S300, j + 1 is substituted for j (j: = j + 1) (step S300). The local plan candidate generation unit 32 determines whether this j is equal to or less than finalMax (step S310). If j is not more than finalMax (step S310 is Yes), the process returns to step S260 and is repeated.

  When j is larger than finalMax (step S310: No), the process proceeds to step S320, and i + 1 is substituted for i (i: = i + 1) (step S320).

  Next, it is determined whether i is equal to or less than max (step S330). If i is less than or equal to max (step S330 is Yes), the process returns to step S220 and is repeated. If i is larger than max, the process ends. The final output is a local plan candidate list stored in outputList, and the local plan selection unit 31 finally selects one local plan from the local plan candidate list.

  Next, according to the flowchart of FIG. 14, the combination pattern generation process of the execution variable of the split query combination in step S230 of FIG. 13 by the local plan candidate generation unit 32 will be described. Note that the variable i is used in the combination pattern generation process of the execution variable of the split query combination. i is 1 or more and is equal to or less than the operation number of the local plan candidate plan to be input (the maximum value of the operation numbers of 1 ≦ i ≦ plan).

  First, the local plan candidate generating unit 32 registers plan in the temporary candidate list nextPlanList that is the final output (step S400). Further, the local plan candidate generating unit 32 sets i = 1 and the maximum value of the operation number of plan = max (step S410).

  Subsequently, the local plan candidate generation unit 32 acquires the operation E of the operation number i of the input local plan candidate plan (step S420). If the acquired operation E is a split query join operation (Yes in step S430), the operation number i + 1 of the plan and the data transmission operation S of the 1st data are acquired, and further, a list varPatternList of all combination patterns of the input variables of the operation S is acquired ( Step S440).

  Next, j: = 1, and the number of elements in nextPlanList = nextMax (step S450). Next, the jth plan nextPlan of nextPlanList is acquired (step S460). Next, k: = 1 and the number of elements in varPatternList = vtMax (step S470). Next, a new local plan candidate newPlan is created by copying the contents of nextPlan (step S480).

  Next, the local plan candidate generation unit 32 performs the following three processes (step S490). The first is a process for obtaining the k-th element targetVars of varPatternList, the second is the process for obtaining the newPlan operation number i + 1, and the third data transmission operation AS, and the third is the process number i- This is processing for obtaining the first data reception calculation AR.

  Next, it is determined whether the input variable list of the operation AS matches the contents of targetVars (step S500).

  If the input variable list of the calculation AS is empty (step S500 is Yes), the calculation E, the calculation AS, and the calculation AR are unnecessary, so that each calculation content is changed to dummy. Dummy is an operation that does nothing, and is deleted later. Here, the calculation number is shifted, so it is not deleted.

  Next, the following four processes are performed in order to change the input / output variable and the pre-execution operation number of the data transmission operation before the operation E so as to send the variable that does not perform the split query combination in advance (step S520). ). The first is a process of acquiring a data transmission calculation BS using the input variable of the calculation E as an input variable, and the second is a process of adding a variable included in the targetVars to the input / output variable list of the BS. The fourth is a process of acquiring the operation number list preExeList of the operation for outputting the variable of targetVars, and the fourth is the process of substituting the value of preExeList for the pre-execution operation number of the BS.

  The local plan candidate generation unit 32 adds newPlan that has been subjected to the process of step S520 to the newPlanList (step S530).

  Thereafter, k + 1 is substituted for k (k: = k + 1) (step S540), and it is determined whether k is equal to or less than vtMax (step S550). When k is less than or equal to vtMax (step S550 is Yes), the process returns to step S480 and the process is repeated. When k is larger than vtMax (step S550: No), the process proceeds to step S560, and j + 1 is substituted for j (j: = j + 1) (step S560).

  The local plan candidate generation unit 32 determines whether j is equal to or less than nextMax (step S570). When j is less than or equal to nextMax (step S570 is Yes), the process returns to step S460 and is repeated. If j is larger than nextMax (No in step S570), the process proceeds to step S580, and all the elements in newPlanList are moved to nextPlanList (step S580). Thereafter, the process proceeds to step S590, where i + 1 is substituted for i (i: = i + 1) (step S590).

  Even when the operation E is not a split query join (No in step S430), the process proceeds to step S590 and i + 1 is substituted for i (i: = i + 1) (step S590). That is, the process of step S590 is performed after step S430 is No or step S580.

  The local plan candidate generation unit 32 determines whether i is equal to or less than max (step S600). If i is less than or equal to max (step S600 is Yes), the process returns to step S420 and is repeated. If i is larger than max, the process ends. The final output after the processing is the local plan candidate list stored in nextPlanList, and the processing of the local plan candidate generating unit 32 is continued by returning to step S240 in FIG.

  Next, the execution location pattern generation process for split query combination will be described with reference to the flowchart of FIG. Note that the variable location i is used in the execution location pattern generation process of the split query combination. i is 1 or more and is equal to or smaller than the operation number of the local plan candidate nextPlan to be input (the maximum value of the operation numbers of 1 ≦ i ≦ nextPlan).

  The local plan candidate generation unit 32 registers nextPlan in the final candidate list finalPlanList that is the final output (step S700).

  Further, i = 1 and the maximum value of the nextPlan operation number = max at the start of processing (step S710).

  First, the execution location pattern generation process of split query combination acquires the operation E of the operation number i of the input local plan candidate nextPlan (step S720). When the acquired operation E is a split query join operation (Yes in step S730), the operation number i + 1 of the nextPlan is acquired (step S740). Next, j: = 1 and the number of elements in finalPlanList = finalMax (step S750). Next, the jth plan finalPlan of finalPlanList is acquired (step S760). Next, a new local plan candidate newPlan is created by copying the contents of finalPlan (step S770).

  Next, the local plan candidate generating unit 32 performs the following five processes in order to change the execution location of the split query combination to the master server (step S780). The first is a process of acquiring the transmission data calculation S immediately after the split / join calculation E. The second is a process of acquiring the received data calculation R immediately before the split query join calculation E. The third is a process of changing the execution location from the transmission destination of the calculation S to the transmission source of the S, with the calculation content of the calculation R being the transmission data calculation and the input variable of S being added to the input / output variable. The fourth process is a process of changing the calculation content of the calculation S that is no longer necessary to “dummy”. The fifth process is a process of changing the execution location of the operation E to the S transmission source.

  Next, the process proceeds to step S790, and newPlan corrected in step S780 is added to the new plan list newPlanList (step S790). Next, proceeding to step S800, j + 1 is substituted for j (j: = j + 1) (step S800). Next, it is determined whether j is equal to or less than finalMax (step S810). If j is not more than finalMax (step S810 is Yes), the process returns to step S760 and the process is repeated. When j is larger than finalMax (step S810: No), the process proceeds to step S820, and all the elements in newPlanList are moved to finalPlanList (step S820). Further, the process proceeds to step S830.

  When the calculation E is not a split query combination (No in step S730), the process proceeds to step S830 and i + 1 is substituted for i (i: = i + 1) (step S830). That is, the process of step S830 is performed after step S730 is No or step S820.

  Next, it is determined whether i is equal to or less than max (step S840). If i is less than or equal to max (step S840 is Yes), the process returns to step S720 and is repeated. If i is larger than max, the process proceeds to step S850.

  In step S850, all the calculations in the local plan candidates in finalPlanList are deleted with the calculation content being dummy (step S850). The final output is a local plan candidate list stored in finalPlanList, and the process returns to step S280 of FIG. 13 to continue the processing of the local plan candidate generation unit 32.

  When the local plan candidate 2 shown in FIG. 12 is a local plan candidate obtained by the local plan selection unit 31, a new local plan candidate 2-1 obtained as a result of the above-described local plan candidate generation processing is performed. 1 to 6 are shown in FIGS.

  A process in which the local plan candidate generating unit 32 generates these local plan candidates 2-1 to 2-6 will be specifically described. First, the local plan candidate 2 in FIG. 12 is passed as an input for combination pattern processing of the execution variable of the split query combination (steps S200, S210, S220, and S230 in FIG. 13).

  Next, in the combination pattern processing of the execution variables of the split query join, the input local plan candidate 2 (hereinafter referred to as “plan”) in FIG. 12 is registered in the temporary candidate list (hereinafter referred to as “nextPlanList”) (step in FIG. 14). S400). Next, in plan, since i is not a split query join operation until i becomes 7, the variable i is incremented by 1 (steps S420, S430, S550, and S540). Since the operation E when i is 7 is a split query join, the operation S with the operation number 8 is acquired, and three combinations ($ u), ( $ V) and ($ u, $ v) are stored in varPatternList (step S440). Next, the plan of FIG. 12 registered first as the first element in the nextPlanList with j: = 1 is acquired as the nextPlan (steps S450 and S460). Next, newPlan is created by copying nextPlan (step S480).

  Next, the first element ($ u) of varPatternList is acquired, and the data transmission operation AS of operation number 8 and the data reception operation AR of operation number 6 are acquired (step S490). Since the AS input variables ($ u, $ v) and ($ u) do not match, the data transmission operation of operation number 3 for transmitting the input variable of the split query combination is acquired and the input / output variable is selected from the target of the split query connection. Add the removed variable $ u. Further, the operation number 4 for outputting the variable $ u is added to the pre-execution operation number of the operation number 3 (steps S500 and S520). The newPlan obtained in this way is added to the newPlanList (step S530). The contents of the local plan candidate 2-1 that is newPlan are shown in FIG. However, in the local plan candidate 2-1 shown in FIG. 16, the calculation of the calculation content dummy has been deleted. Next, 2 is substituted for k, and a newPlan is created by copying the plan of FIG. 12 again (step S480).

  Next, the second element ($ v) of varPatternList is acquired, and the data transmission operation AS of operation number 8 and the data reception operation AR of operation number 6 are acquired (step S490). Since the AS input variables ($ u, $ v) and ($ v) do not match, the data transmission operation of operation number 3 for transmitting the input variable $ z of the split query combination is acquired, and the split query connection is input to the input / output variable. Add the variable $ v excluded from the target. Further, the operation number 5 for outputting the variable $ v is added to the pre-execution operation number of the operation number 3 (steps S500 and S520). The newPlan obtained in this way is added to the newPlanList (step S530). The contents of the local plan candidate 2-2 which is newPlan are shown in FIG. However, in the local plan candidate 2-2 shown in FIG. 17, the calculation of the calculation content dummy has been deleted. Next, newPlan is created by substituting 3 for k and copying the plan of FIG. 12 again (step S480).

  Next, the third element ($ u, $ v) of varPatternList is acquired, and the data transmission operation AS of operation number 8 and the data reception operation AR of operation number 6 are acquired (step S490). Since the AS input variables ($ u, $ v) and the third element ($ u, $ v) of varPatternList completely match, the computation contents of computations E, AS, AR are changed to dummy (step S510). . Next, the data transmission operation of operation number 3 for transmitting the input variable of the split query combination is acquired, and the variables $ u and $ v excluded from the target of the split query connection are added to the input / output variables. Further, the operation numbers 4 and 5 for outputting the variables $ u and $ v are added to the pre-execution operation number of the operation number 3 (step S520). The newPlan obtained in this way is added to the newPlanList (step S530). The contents of the local plan candidate 2-3 that is the newPlan are shown in FIG. However, in the local plan candidate 2-3 shown in FIG. 18, the calculation of the calculation content dummy has been deleted. Next, 4 is substituted for k (step S540).

  Next, since varPatternList has only 3 elements, 2 is substituted for j (steps S590 and S580). Next, since nextPlanList has only one element, the three local plan candidates in the newPlanList obtained so far are transferred to the nextPlanList (steps S570 and S560). NextPlanList has the local plan candidates shown in FIGS. 12, 16 to 18 as elements at this time. Next, even if a value after 8 is substituted for i, there is no split query combination, and therefore the combination pattern generation processing of the execution variable of the split query combination is ended (steps S550, S540, S420, S430).

  Next, nextPlanList in which the local plan candidates shown in FIGS. 12, 16 to 18 are stored is acquired as an output list of the combination pattern generation process of the execution variable of the split query combination (step S240 in FIG. 13). Next, 1 is substituted into j, and the local plan candidate nextPlan of FIG. 12 which is the first element of nextPlanList is acquired (steps S250 and S260). NextPlan is then passed as an input for the execution location pattern generation process for split query join (step S270).

  Next, the local plan candidate nextPlan in FIG. 12 passed as the input of the execution location pattern generation process for split query combination is registered in the final candidate list finalPlanList (step S700 in FIG. 15). Next, 1 is substituted into i (step S710).

  Since nextPlan is not a split query join operation until i becomes 7, variable i is incremented by 1 (steps S720, S730, S830, and S840). Since the operation E when i is 7 is a split query combination, the data transmission operation S with the operation number 8 is acquired (step S740). Next, 1 is substituted into j, and the local plan candidate nextPlan shown in FIG. 12 that is first registered as the first element in finalPlanList is obtained as finalPlan (steps S750 and S760). Next, newPlan is created by copying finalPlan (step S770).

  The following processing is performed to change the execution location of the partial query number to the master server (step S780). First, the transmission data calculation S of calculation number 8 and the reception data calculation R of calculation number 6 are acquired. Next, the execution location is changed to “computer 2 → 0”, with R being the transmission data calculation, the input / output variables being the addition of the S input variables $ u and $ v. Further, the calculation content of S is changed to dummy. Finally, the execution location of E is changed to computer 0.

  Next, newPlan obtained in this way is added to newPlanList (step S790). The contents of the local plan candidate 2-4, which is newPlan, are shown in FIG. However, in the local plan candidate 2-4 shown in FIG. 19, the calculation of the calculation content dummy has been deleted.

  Next, 2 is substituted for j. Since finalPlanList has only one element, one local plan candidate 2-4 in newPlanList obtained so far is transferred to finalPlanList (steps S800, S810, and S820). Next, even if a value after 8 is substituted for i, there is no split query join. Therefore, the operation contents existing in each local plan candidate obtained by finalPlanList until now delete the operation of dummy and the split query join The execution location pattern generation process ends (steps S830, S840, S850).

  Next, finalPlanList that stores the local plan candidates shown in FIGS. 12 and 19 is acquired as an output list of the execution location pattern generation process for split query combination (step S280 in FIG. 13). Next, the local plan candidates shown in FIGS. 12 and 19 in the finalPlanList are moved to the output candidate plan list outputList (step S290). Next, 2 is substituted for j, and the local plan candidate nextPlan of FIG. 16 which is the second element of nextPlanList is acquired (steps S300, S310, and S260). NextPlan is then passed as an input for the execution location pattern generation process for split query join (step S270).

  The local plan candidate 2-1 shown in FIG. 16 in the execution location pattern generation process of split query join is almost the same as the local plan candidate 2 shown in FIG. 12 except for the input / output variable 149. FIG. Since the operation is the same as when the local plan candidate 2 shown in FIG. 16 is input, the details when the local plan candidate 2-1 shown in FIG. 16 is input are omitted. The contents of the output list finalPlanList of the execution location pattern generation process of the split query combination are the local plan candidate lists of FIGS.

  Next, the local plan candidates shown in FIGS. 16 and 20 in finalPlanList are moved to the output candidate plan list outputList (step S290). Next, 3 is substituted into j, and the local plan candidate nextPlan of FIG. 17 that is the third element of nextPlanList is acquired (steps S300, S310, and S260). NextPlan is passed as an input of the execution location pattern generation process for split query join (step S270).

  In the execution location pattern generation process of split query combination, the local plan candidate 2-2 shown in FIG. 17 is almost the same as the local plan candidate 2 shown in FIG. 12 except for the input / output variable 149. Since the operation is the same as that in the case where the local plan candidate 2 shown in FIG. 17 is input, details in the case where the local plan candidate 2-2 shown in FIG. 17 is input are omitted. The contents of the output list finalPlanList of the execution location pattern generation process of the split query combination are the local plan candidate lists of FIGS.

  Elements in finalPlanList The local plan candidates in FIGS. 17 and 21 are moved to the output candidate plan list outputList (step S290). Next, 4 is substituted into j, and the local plan candidate nextPlan of FIG. 18 that is the fourth element of nextPlanList is acquired (steps S300, S310, and S260). NextPlan is then passed as an input for the execution location pattern generation process for split query join (step S270).

  The local plan candidate nextPlan shown in FIG. 18 passed as an input for the execution location pattern generation process for split query join is registered in the final candidate list finalPlanList (step S700 in FIG. 15). Next, 1 is substituted into i (step S720). Next, in nextPlan, the variable i is incremented by 1, but since there is no split query join operation until the end, the process proceeds to step S850 (steps S720, S730, S830, S840). In step S850, the calculation content existing in the local plan candidate 2-3 shown in FIG. 18 registered in finalPlanList shown in FIG. 18 is deleted, and the split query join execution location pattern generation process ends (step S850). The content of the output list finalPlanList of the execution location pattern generation process of the split query combination is the local plan candidate list of FIG.

  Element in finalPlanList The local plan candidate 2-4 in FIG. 19 is moved to the output candidate plan list outputList (step S290). Next, 5 is substituted for j (step S300). Since there are only four elements registered in nextPlanList, 2 is substituted for i (steps S310 and S320). Since the number of elements of inputPlanList is only 1, the local plan candidate generation process is terminated. The local plan candidates registered in the finally obtained local plan candidate list outputList are shown in FIGS.

  In the local plan candidate 2 in FIG. 12, since it is necessary for the calculation between servers, the variable $ z transmitted by the data transmission calculation of the calculation number 3 and the variables $ u, obtained by the calculations 4 and 5 executed in parallel with the calculation between the servers. $ V is divided and combined in the computer 2 by the operation number 7.

  The local plan candidate 2-1 shown in FIG. 16 does not execute the operation number 4 in parallel with the inter-server operation for the local plan candidate 2 shown in FIG. This is a local plan candidate that transmits u and is divided and combined with $ v by the division and combination of operation number 7.

  17 is not executed in parallel with the inter-server operation for the local plan candidate 2-2 shown in FIG. 17 and the local plan candidate 2 shown in FIG. , And a local plan candidate that is divided and combined with $ u by the division and combination of operation number 7.

  The local plan candidate 2-3 shown in FIG. 18 does not execute the operation numbers 4 and 5 in parallel with the inter-server operation for the local plan candidate 2 shown in FIG. This is a local plan candidate in which z, $ v, and $ u are transmitted so as not to be divided and combined.

  The local plan candidate 2-4 shown in FIG. 19 is a local plan candidate when the execution location is not the computer 2 but the computer 0 with respect to the local plan candidate 2 shown in FIG.

  A local plan candidate 2-5 shown in FIG. 20 is a local plan candidate when the execution location is not the computer 2 but the computer 0 with respect to the local plan candidate 2-1 shown in FIG.

  The local plan candidate 2-6 shown in FIG. 21 is a local plan candidate when the execution location is not the computer 2 but the computer 0 with respect to the local plan candidate 2-2 shown in FIG.

  As described above, in the local plan candidates shown in FIG. 12 and FIGS. 16 to 21, the local plan candidates with and without the split / join operation, and the target when split / join when the split / join operation is performed. Local plan candidates are generated that cover all combinations of variables and combinations of whether the location of the split / join is the master server or the slave server.

  The local plan selection unit 31 calculates a cost consisting of the estimated execution time or the estimated execution calculation amount from these local plan candidates, and selects a local plan that minimizes the cost (step S8).

  Here, an example of calculating the estimated execution time of the local plan candidate will be described. The estimated execution time of the local plan candidate is calculated based on, for example, the parameters for the estimated processing time of each calculation listed in FIG. 22 and the calculation included in the local plan.

  The parameters of each operation are, for example, “numerical index: 0.001 msec / number of output variables”, “TRAVERSE: 1 msec / number of input variables”, “partition query combination: 1 msec / number of input variables”, “JOIN between servers” : 1 msec / number of input variables ”,“ data transmission 5 msec + (0.001 msec / number of input variables) × number of variables ”,“ data reception 5 msec + (0.001 msec / number of input variables) × number of variables ”, etc. It is. The number of items to be stored in the output variable is set in advance according to the calculation contents.

  Here, an example of an estimated time calculation process in the local plan candidate 2 shown in FIG. 12 will be described below. Since it can be seen from FIG. 4 that 10,000 pieces of XML data are registered in the computer 2, the estimated execution time of each calculation is calculated by this.

  (1) When using a “> =” operation in a numerical index, it is estimated that 10% of the total hits. Therefore, it is estimated that 1000 hits in 10% of 10,000 cases. Therefore, the estimated calculation time of the numerical index is 0.001 msec / number of output variables × 1000 cases = 1 msec.

  (2) The number of input variables of TRAVELS is estimated to be 1000 from the result of (1). Assuming that the output will not change, the number is estimated to be 1000. Therefore, the estimated calculation time of TRAVELSE is 1 msec / number of input variables × 1000 cases = 1000 msec.

  (3) The number of input variables for data transmission is estimated to be 1000 from the result of (2). Therefore, the estimated calculation time for data transmission is 5 msec + 0.001 msec / number of input variables × 1000 × 1 = 6 msec.

  (4) The number of input variables of TRAVERS is estimated to be 1000 from the result of (2). Assuming that the output will not change, the number is estimated to be 1000. Therefore, the estimated calculation time of TRAVELSE is 1 msec / number of input variables × 1000 cases = 1000 msec.

  (5) The number of input variables of TRAVERS is estimated to be 1000 from the result of (4). Assuming that the output will not change, the number is estimated to be 1000. Therefore, the estimated calculation time of TRAVELSE is 1 msec / number of input variables × 1000 cases = 1000 msec.

  (6) The number of input variables for data reception is estimated to be 400, which is reduced to 40% by executing the server-to-server JOIN on the master server. Therefore, the estimated calculation time for data reception is 5 msec + 0.001 msec / number of input variables × 400 × 1≈6 msec.

  (7) The number of input queries for split query is estimated to be 1400 in total from (5) and (6). Therefore, the estimated calculation time for the split query combination is 1 msec / number of input variables × 1400 cases = 1400 msec.

  (8) After data transmission to the master server in (3), the master server executes the server-to-server JOIN with the operation number 10 in the distributed plan of FIG. Here, it is assumed that the estimated calculation time of the server-to-server JOIN is calculated by the distributed plan generation unit 13 in the same way as the estimated calculation time of the local plan candidate, and then sent to the slave server together with the distributed plan. The distributed plan generation unit 13 calculates the number of input JOINs between servers on the assumption that the number of registered data of each slave server is about 1/3. Therefore, the estimated time for JOIN between servers is 1 msec / number of input variables × 11250/3 = 3750 msec.

  In FIG. 11, the intra-server operations of operation numbers 4 and 5, which are listed as operations that can be executed in parallel with the inter-server JOIN of operation number 10 by the divided query join operation addition unit 14, are the operations of the local plan candidate 2. It corresponds to TRAVERSE of numbers 4 and 5. For this reason, it can be seen that the operation numbers 4 and 5, the operation numbers 3 and 6, and the inter-server JOIN are executed in parallel, so the estimated time of the local plan candidate 2 is the longer of the following two estimated times.

(1) + (2) + (3) + (8) + (6) + (7) = 6163 msec
(1) + (2) + (4) + (5) + (7) = 4401 msec
As a result, it is estimated to be 6163 msec.

As another example, when the local plan candidate 2-3 is executed by the computer 2, since all the processes cannot be executed in parallel, the estimated times are (1), (2), (3), (4), and (5 ) And the server-to-server JOIN. That is,
1 msec + 1000 msec + 1000 msec + 1000 msec + 6 msec + 3750 msec = 6757 msec
It is calculated that the local plan candidate 2 is faster when including the server-to-server JOIN. In this way, by adding the estimated time of the inter-server calculation executed on the master server to the estimated calculation time of the local plan candidate, it is possible to determine whether the optimization by the divided query combination added by the divided query join calculation adding unit is effective.

  In the present embodiment, the computer 1 is a local plan candidate 2-3 shown in FIG. 18, the computer 2 is a local plan candidate 2 shown in FIG. 12, and the computer 3 is a local plan candidate 2-4 shown in FIG. As chosen.

  The local plan selection unit 31 of each computer transmits the selected local plan to the distributed plan update unit 15 of the master server. When the local plan selection unit 31 transmits the selected local plan to the distributed plan update unit 15, the slave server executes the target local plan (step S9).

  In parallel with step S9 performed by the slave server, the distributed plan update unit 15 of the master server that has received the local plan performs distributed plan update processing (step S10).

  Here, when the distributed plan update unit 15 of the master server selects the local plan candidates shown in FIGS. 18, 12, and 19 for the distributed plan shown in FIG. The distributed plan update process when the distributed plan is updated according to the flowchart of FIG. This distributed plan update process uses a variable i. i is 1 or more and less than or equal to the number of target slave servers (1 ≦ i ≦ number of slave servers).

  I = 1 at the start of the process. Further, the number of slave servers = max is set (step S900).

  The distributed plan update unit 15 acquires the local plan LPlan for the computer number i (step S910). Next, the difference regarding the split query combination between the distributed plan and the local plan is checked (step S920). Based on the difference check, the LPlan determines whether the split query combination is completely deleted (step S930).

  If the split query join is completely deleted in LPlan (step S930 is Yes), the computer i is deleted from the execution place of the split query join in the distributed plan and the data transmission operation and the data reception operation before and after that (step S930). S940). Next, it is determined whether the execution location of the deleted result divided query join operation is empty (step S950).

  If the execution location of the split query join operation is empty (step S950 is Yes), the split query join in the distributed plan, the data transmission operation and the data reception operation before and after that are deleted (step S960). Next, the process proceeds to step S970.

  If the execution location of the split query join operation is not empty (No in step S950), the process proceeds to step S970. Further, when the split query combination is not completely deleted in LPlan (step S930 is No), the process proceeds to step S970. That is, the process of step S970 is performed when step S930 is No, when step S950 is No, or after step S960. In step S970, it is determined whether the execution location of the split query combination is changed in LPlan.

  When the execution location of the split query join is changed in LPlan (step S970 is Yes), the computer i is deleted from the execution location of the split query join in the distributed plan, the data transmission operation before and after that, and the data reception operation ( Step S980). Next, it is determined whether or not the execution location of the deleted result divided query join operation is empty (step S990).

  When the execution location of the split query join operation is empty (Yes in step S990), the split query join in the distributed plan, the data transmission operation and the data reception operation before and after that are deleted (step S1000). Next, the process proceeds to step S990.

  If the execution location of the split query join operation is not empty (No in step S990), the process proceeds to step S1010. That is, the process of step S1010 is performed when step S990 is No or subsequent to step S1000. In step S1010, it is determined whether a split query combination in which the execution location of LPlan has been changed already exists in the distributed plan.

  If the split query join whose LPlan execution location has been changed does not already exist in the distributed plan (No in step S1010), the split query join whose execution location has been changed, and the data transmission and data reception operations before and after the split query join are distributed plan. (Step S1030). Next, the process proceeds to step S1040.

  If a split query combination whose LPlan execution location has been changed already exists in the distributed plan (No in step S1010), the computer i is added to the execution location (step S1020). Next, the process proceeds to step S1040.

  Further, when the execution location of the split query combination is not changed in LPlan (No in step S970), the process proceeds to step S1040. That is, the process of step S1040 is performed when step S970 is No, subsequent to step S1020, or subsequent to step S1030. In step S1040, i + 1 is substituted for i (i: = i + 1) (step S1040).

  Next, it is determined whether i is equal to or less than max (step S1050). When i is less than or equal to max (step S1050 is Yes), the process returns to step S910 and is repeated. If i is larger than max, the process ends.

  With respect to the distributed plan shown in FIG. 11, when the local plans of the computers 1, 2, and 3 are the local plan candidate 2-3, the local plan candidate 2, and the local plan candidate 2-4, respectively, the distributed plan update process described above is performed. FIG. 24 shows a dispersion plan obtained as a result of the above.

  The distribution plan 3 shown in FIG. 24 includes “operation number” 312, “partial query number” 313, “operation content” 314, “pre-execution operation number” 315, “execution location” 316, “transmission location” 317, “ It has items of “input variable” 318 and “output variable” 319. The items 312 to 319 included in the distribution plan 3 are the same as the items 142 to 149 included in the distribution plan table 141 and the items 302 to 309 included in the local plan candidates 2, 2-1 to 2-6.

  First, 1 is assigned to i, and the difference regarding the split query combination between the local plan candidate 2-3, which is the local plan selected by the computer 1, and the distributed plan of FIG. 11 is checked (steps S900, S910, S920). In the local plan candidate 2-3, since the split query combination of the computer 1 is completely deleted, the split query combination of the distributed plan of FIG. 11 and the data transmission and data reception operations before and after that (operation number 11 of FIG. 24). -15), the computer 1 is deleted from the execution location (step S940).

  Next, since the execution location of the split query join is not empty, the distributed plan update unit 15 checks the local plan candidate 2-3 to check whether the execution location of the split query join has been changed (Steps S950 and S970). ). Since the execution location has not been changed, 2 is substituted for i (steps S1040 and S1050).

  Next, i is set to 2, and the difference regarding the split query combination between the distributed plan of FIG. 11 and the local plan candidate 2 which is the local plan selected by the computer 2 is checked (step S920). In the local plan candidate 2 shown in FIG. 12, since the split query combination of the computer 2 is not deleted and the execution location is not changed, 3 is substituted for i (steps S930, S970, S1040, and S1050).

  Next, i is set to 3, and the difference regarding the split query combination between the distributed plan of FIG. 11 and the local plan candidate 2-4 which is the local plan selected by the computer 3 is checked (step S920). Since the local query candidate 2-4 has not deleted the split query join of the computer 3, it next checks whether the execution location of the split query join has been changed (steps S930 and S970).

  In addition, since the execution location of the split query join is changed in the local plan candidate 2-4, the split query join of the distributed plan and the data transmission and data reception calculations before and after the split query join (operation numbers 11-15 in FIG. 24) The computer 3 is deleted from the execution location (step S980). Since the execution location of the split query join is not empty, the distributed plan update unit 15 confirms whether the split query join whose execution location has been changed next is inserted in the distributed plan (steps S980 and S1010). Since it is not inserted in the distributed plan, the split query combination whose execution location has been changed and the data transmission and data reception operations before and after that are inserted into the distributed plan (operation numbers 14, 15, and 16 in FIG. 24) (step S1030). ). Next, 4 is substituted for i. Since the number of computers is up to 3, the processing is terminated (steps S1040 and S1050). Finally, the distribution plan 3 of FIG. 24 is obtained.

  The distributed plan execution unit 16 executes the calculation of the distributed plan 3 (step S11 in FIG. 6). The execution of the distributed plan 3 and the execution of the local plan execution unit 33 of the slave server are dependent on each other in data transmission / reception. For example, they are executed in parallel or waiting for data to be transmitted from the other party. To do. That is, the distributed plan is executed while data is exchanged between the transmission / reception unit 17 of the master server and the transmission / reception unit 34 of the slave server.

  As described above, according to the present embodiment, for the query query input to the master server by the user, the master server performs only the optimization of the portion related to the inter-server operation excluding the join processing of the partial queries. However, the slave server performs optimization of partial query joins. In other words, since the master server can exclude partial query join processing from the scope of optimization, it can be realized with a simple mechanism as compared with the case where everything is optimized on the master server side. .

  That is, the master server tentatively determines the partial query join processing without depending on the partial query join processing determined by the slave server. The slave server optimizes the partial query join processing based on the database information for each server. Further, the master server generates an efficient distributed plan by the slave server notifying the master server of the result of the join processing of the partial query. In addition, since the slave server side optimizes the split query join operation, an efficient plan suitable for each slave server can be generated.

  Therefore, according to the embodiment of the present invention, for the query query 51, by removing the operation related to the split query join operation from the range of the distributed plan determined by the master server, the mechanism for optimizing the distributed plan of the master server is simplified. After that, the slave server performs the optimization in the above range in an optimal manner for each. Thereby, efficient query processing can be realized.

(Second Embodiment)
A distributed database search apparatus according to a second embodiment will be described with reference to the drawings. In addition, the same code | symbol is attached | subjected to the structure same as the distributed database search device of 1st Embodiment, and description is abbreviate | omitted.

  FIG. 25 is a configuration diagram illustrating a functional configuration of the distributed database search device according to the second embodiment. As shown in FIG. 25, the distributed database search device of the present embodiment is configured to further include schema generation units 18 and 35 and schema change units 19 and 36 in the configuration of the distributed database search device shown in FIG.

  A schema is a data structure that holds the type and position information of data to be stored.

  The schema generation units 18 and 35 generate schemas of input and output data as a result of operations performed in each server. For example, the schema generation unit 18 included in the master server generates an input / output data schema for each operation of the distributed plan. Further, the schema generation unit 35 provided in the slave server generates a schema of input / output data of each calculation of the local plan.

  The schema changing units 19 and 36 change the schema of the data when passing the data obtained by each calculation of the distributed plan or the local plan to the next calculation. The schema change unit 19 of the master server changes the data schema when passing the data obtained by the output of each operation of the distributed plan or the local plan to the input of the next operation of the distributed plan. The schema change unit 36 of the slave server changes the schema of the data when passing the data obtained by the output of each operation of the distributed plan or the local plan to the next operation of the local plan.

  Here, FIG. 26 shows an example of items included in the schema before being changed by the schema changing unit 19 in the present embodiment. The schema before being changed is a schema generated by the schema generation unit 18 described later. The schema holds the type and position information of data to be stored. As shown in FIG. 26, in this embodiment, “variable area” 401 and “variable˜” 402-i (i is an integer of 1 or more). ) And “extended variable $ # e (V1..., Vn)” 403.

  “$ # E” of “extended variable $ # e (V1,..., Vn)” 403 contains a unique character string that does not match “~” of “variable˜” 402-i, and “(V1,. .., Vn) ”includes n unique character strings separated by“, ”. The “variable area” 401 is an item for storing data for absorbing the difference in the number of columns when data is transmitted between servers. “Variable˜” 402-i is an item for storing data of each variable, and “Extended variable $ # e (V1,..., Vn)” 403 is data of all variables from variable “V1” to variable “Vn”. The item to store. Note that “variable˜” 402-i stores various variables for each input / output data.

  Here, with reference to FIG. 27, an example of the search processing of the distributed database search device of this embodiment will be described. FIG. 27 is a flowchart showing an example of search processing of the distributed database search device of this embodiment. Note that the processing of steps S1 to S8 and S10 is the same as that in the flowchart shown in FIG.

  After determining the local plan in steps S1 to S8 in FIG. 27, the local plan selection unit 37 performs a local plan order determination process for determining a portion in which the execution order is non-deterministic in the determined local plan (step S12). Here, the portion whose execution order is non-deterministic is a set of operations in which the prior execution numbers of the operations in the local plan are equal. Since these operations are not specified in any order, they can be executed in any order. That is, the execution order of these operations is uniquely determined by the local plan order determination process.

  FIG. 28 shows a result of the local plan candidate 2 shown in FIG. 12 having the non-deterministic operation set order uniquely determined by the local plan order determination process (step S12). In the local plan candidate 2 shown in FIG. 12, the prior execution number of each operation of operation numbers 2, 4, and 5 is 1, and the execution order is non-deterministic. In FIG. 29, the execution numbers are determined to be executed in the order of operation numbers 2, 4, and 5, and the pre-execution number of operation number 4 is rewritten from 1 to 2, and the pre-execution number of operation number 5 is rewritten from 1 to 4.

  After the local plan order determination process in step S12, the local plan whose operation order has been determined is transmitted to the master server by the transmission unit 34. When the master server receives the local plan, the distributed plan update unit 10 performs distributed plan update processing (step S10). In parallel with step S10, the schema generation unit 35 of the slave server generates an input schema and an output schema (hereinafter referred to as an input / output schema) for each operation in the local plan (step S14). The input schema is a schema of input data. The output schema is a schema of data output by calculation.

  Here, with reference to FIG. 29, the operation | movement at the time of the schema production | generation part 35 performing a schema production | generation process (step S14) with respect to the local plan shown in FIG. 28 is demonstrated concretely.

  In this schema generation process, a variable i is used. i is an integer of 1 or more and is equal to or smaller than the operation number of the target local plan (1 ≦ i ≦ maximum value of the operation number of the local plan). Also, i = 1 at the start of the schema generation process. In addition, the maximum value of the operation number of the local plan is “max”. In addition, the calculation of the local plan whose calculation number 301 is i is defined as calculation S.

  When receiving the local plan from the local plan selection unit 31, the schema generation unit 35 first sets i = 1 as the initialization process and sets the maximum value of the local plan operation number = max (step S1110). Next, it is determined whether i is equal to or less than max (step S1110).

  If i is less than or equal to max (step S1110 is Yes), the calculation S of the calculation number i is acquired (step S1120). Next, it is determined whether or not the operation S has an output variable (step S1130).

  If there is an output variable in the operation S (Yes in step S1130), the output variable of the operation S is added to the output schema and the variable list VL. Further, an arrival number list RL and a usage number list UL are prepared for each variable (step S1140). Next, a list AL of operation numbers to be executed after the operation S and the operation S is obtained from the prior execution numbers of the operations (step S1150). Next, for each output variable of the operation S, the operation numbers stored in the list AL are registered in the arrival operation number list RL prepared for each variable (step S1160). Thereafter, the process proceeds to step S1170. Note that if the calculation S has no output variable (No in step S1130), the process also proceeds to step S1170.

  In step S1170, it is determined whether there is an input variable in operation S (step S1170).

  When there is an input variable in the operation S (step S1170 is Yes), the pre-execution operation number of the operation S is traced, and a list BL of operation numbers executed before the operation S is acquired (step S1180). Next, the operation numbers stored in the list BL are registered in the use operation number list UL prepared for each variable for each input variable of the operation S (step S1200). Thereafter, the process proceeds to step S1210. Note that if the calculation S has no input variable (No in step S1170), the process also proceeds to step S1210.

  In step S1210, i + 1 is substituted for i (i: = i + 1) (step S1210). Next, the process returns to step S1110.

  If i is greater than max (No in step S1110), the process proceeds to step S1220.

  Here, a variable called j is used. j is 1 or more and less than or equal to the number of elements in the variable list VL (1 ≦ j ≦ number of elements in VL). At this time, j = 1 and the number of elements in the VL = vmax (step S1220). Next, it is determined whether j is equal to or less than vmax (step S1230).

  If j is equal to or less than vmax (step S1230 is Yes), the j-th variable var is acquired from the variable list VL (step S1240). Next, the operation number list CL that appears in common in the reaching operation number list RL and the usage number list UL of the variable var is acquired (step S1250). Next, a variable var is added to the output schema of each operation of the operation number in the list CL (step S1260). Next, j + 1 is substituted for j (j: = j + 1) (step S1270). Next, the process returns to step S1230.

  If j is greater than vmax (No in step S1230), 1 is substituted for i (i: = 1) (step S1280). Next, it is determined whether i is equal to or less than max (step S1290).

  When i is less than or equal to max (step S1290 is Yes), the calculation S of the calculation number i is acquired (step S1300). Next, the operation output schema of the pre-execution operation number is copied to the operation S input schema (step S1310). Next, the variable area is added to the head of the output schema of the operation S, and the extension variable $ # e () is added to the tail (step S1320). Next, i + 1 is substituted for i (i: = i + 1) (step S1330). Next, the process returns to step S1290.

  If i is greater than max (No in step S1290), the process ends. Note that the flowchart shown in FIG. 29 operates in the same way only in the schema generation process S15 in the schema generation unit 18 of the slave server, except for whether the target is a local plan or a distributed plan.

  Here, FIG. 30 shows an example of an input / output schema obtained as a result of the above-described schema generation processing in the local plan obtained by the local plan order determination processing shown in FIG. The input / output schema table 500 shown in FIG. 30 shows items of operation number 500, input schema 1, input schema 2, and output schema 502.

  The operation number 501 of the input / output schema table 500 stores an operation number corresponding to the operation number of the plan for which the schema generation processing has been performed.

  The input schema 1 stores the first input schema generated in the schema generation process. The input schema 2 stores the second input schema of the input schema generated in the schema generation process.

  The output schema 504 stores the output schema generated in the schema generation process.

  A process in which the schema generation processing unit 18 calculates the input / output schema table 500 will be specifically described. First, the local plan of FIG. 28 is passed as an input of the schema generation process. Next, 1 is substituted for i and 8 is substituted for max (step S1100). Next, since i is equal to or less than max, the operation S with the operation number 1 is acquired (steps S1110 and S1120). Since the operation S has the output variable $ x, $ x is added to the output schema 504 and the variable list VL. Further, an arrival number list RL and a usage number list UL for $ x are prepared (steps S1130 and S1140). Next, the advance execution number is traced, and the operation number 1 of the operation S and the operation number 2-8 executed after the operation S are stored in the arrival number list RL (steps S1150 and S1160). Since the calculation S has no input variable, 2 is substituted for i, and the calculation S of the calculation number 2 is acquired (steps S1210, S1110, S1120).

  Since the operation S has the output variable $ z, $ z is added to the output schema 504 and the variable list VL. Further, an arrival number list RL and usage number list UL for $ z are prepared (steps S1130 and S1140). Next, the advance execution number is traced, and the operation number 2 of the operation S and the operation number 3-8 executed after the operation S are stored in the arrival number list RL (steps S1150 and S1160). Next, since the operation S has the input variable $ x, the operation number 1 executed before S is registered in the use operation number UL. (Steps S1170, S1180, S1200). Next, the operation S with the operation number 3 is acquired (steps S1210, S1110, S1120).

  Since the operation S has the output variable $ z, $ z is added to the output schema 504 and the variable list VL. Further, an arrival number list RL and usage number list UL for $ z are prepared (steps S1130 and S1140). Next, the advance execution number is traced, and the operation number 3 of the operation S and the operation numbers 3 and 6-8 executed after the operation S are stored in the arrival number list RL (steps S1150 and S1160). Next, since it has the input variable $ z, the operation numbers 1 and 2 executed before S are registered in the utilization operation number UL of $ z. (Steps S1130, S1170, S1180, S1200). Next, the operation S with the operation number 4 is acquired (steps S1210, S1110, S1120).

  Since the operation S has the output variable $ u, $ u is added to the output schema 504 and the variable list VL. Further, a reaching number list RL and a usage number list UL for $ u are prepared (steps S1130 and S1140). Next, the advance execution number is traced, and the operation number 4 of the operation S and the operation numbers 5, 7, and 8 executed after the operation S are stored in the arrival number list RL (steps S1150 and S1160). Next, since the operation S has the input variable $ x, the operation numbers 1 and 2 executed before S are registered in the use operation number UL. (Steps S1170, S1180, S1200). Next, the operation S with the operation number 5 is acquired (steps S1210, S1110, S1120).

  Since the operation S has the output variable $ v, $ v is added to the output schema 504 and the variable list VL. Further, an arrival number list RL and usage number list UL for $ v are prepared (steps S1130 and S1140). Next, the advance execution number is traced, and the operation number 5 of the operation S and the operation numbers 7 and 8 executed after the operation S are stored in the arrival number list RL (steps S1150 and S1160). Next, since the operation S has the input variable $ x, the operation numbers 1, 2, and 4 executed before S are registered in the use operation number UL. (Steps S1170, S1180, S1200). Next, the calculation S of the calculation number 6 is acquired (steps S1210, S1110, S1120).

  Since the operation S has the output variable $ z, $ z is added to the output schema 504 and the variable list VL. Furthermore, for $ z. A reachable number list RL and a use number list UL are prepared (steps S1130 and S1140). Next, the advance execution number is traced, and the operation number 6 of the operation S and the operation numbers 7 and 8 executed after the operation S are stored in the arrival number list RL (steps S1150 and S1160). Next, since it has the input variable $ z, the operation numbers 1-3 executed before S are registered in the utilization operation number UL of $ z. (Steps S1130, S1170, S1180, S1200). Next, the calculation S of the calculation number 7 is acquired (steps S1210, S1110, S1120).

  Since the operation S has no output variable and has the input variable $ z, the operation numbers 1-6 executed before S are registered in the usage operation number UL of $ z. (Steps S1130, S1170, S1180, S1200). Next, the operation S with the operation number 8 is acquired (steps S1210, S1110, S1120).

  Since the operation S has output variables $ u and $ v, $ u and $ v are added to the output schema 504 and the variable list VL. Furthermore, for $ u and $ v. A reachable number list RL and a use number list UL are prepared (steps S1130 and S1140). Next, the advance execution number is traced, and the operation number 8 of the operation S is stored in the arrival number list RL (steps S1150 and S1160). Next, since there are input variables $ u and $ v, the operation numbers 1-7 executed before S are registered in the use operation numbers UL of $ u and $ v. (Steps S1130, S1170, S1180, S1200). Next, since i exceeds max, 1 is substituted for j, and the number of VL elements 4 is substituted for vmax (steps S1210, S1110, S1220). Next, the variable $ x which is the first element of the variable list is acquired (steps S1230 and S1240).

  $ X is added to the output schema 504 of operation numbers 1, 2, and 4 that appear in common because each element of the usage number list UL of the variable $ x is 1, 2, and 4, and the reaching operation number RL is 1-8. (Steps S1250 and S1260). Next, the second variable $ z of VL is acquired (steps S1270, S1230, S1240).

  Since each element of the usage number list UL of the variable $ z is 1-6 and the reaching operation number RL is 2-8, $ z is added to the output schema 504 of the operation number 2-6 that appears in common (step) S1250, S1260). Next, the third variable $ u of VL is acquired (steps S1270, S1230, S1240).

  Since each element of the usage number list UL of the variable $ u is 1-7 and the reaching operation number RL is 4, 5, 7, 8, the output schema 504 of the operation numbers 4, 5, 7 appearing in common is $ u is added (steps S1250 and S1260). Next, the fourth variable $ v of VL is acquired (steps S1270, S1230, S1240).

  Since each element of the usage number list UL of the variable $ v is 1-7 and the reaching operation number RL is 5, 7, 8, $ v is added to the output schema 504 of the operation numbers 5, 7 that appear in common. (Steps S1250 and S1260). Next, 1 is substituted into i, and the operation S with the operation number 1 is acquired (steps S1270, S1230, and S1280).

  Since the operation number 1 is not input, the variable S and the extended variable $ # e () are added to the output schema 504 to obtain the operation S of the operation number 2 (steps S1300 to S1320, S1280, and S1290).

  Copy the output schema 504 of the operation number 1 to the input schema 1 of the operation number 2, add the variable area and the extension variable $ # e () to the output schema 504, and acquire the operation S of the operation number 3 (step S1300). -S1320, S1280, S1290).

  Copy the output schema 504 of operation number 2 to the input schema 1 of operation number 3, add the variable area and the extension variable $ # e () to the output schema 504, and obtain the operation S of operation number 4 (step S1300). -S1320, S1280, S1290).

  The output schema 504 with the operation number 2 is copied to the input schema 1 with the operation number 4, and the variable area and the extension variable $ # e () are added to the output schema 504 to obtain the operation S with the operation number 5 (step S1300). -S1320, S1280, S1290).

  The output schema 504 with the operation number 4 is copied to the input schema 1 with the operation number 5, the variable region and the extension variable $ # e () are added to the output schema 504, and the operation S with the operation number 6 is acquired (step S1300). -S1320, S1280, S1290).

  The output schema 504 with the operation number 3 is copied to the input schema 1 with the operation number 6, and the variable region and the extension variable $ # e () are added to the output schema 504 to obtain the operation S with the operation number 7 (step S1300). -S1320, S1280, S1290).

  Copy the output schema 504 of operation number 5 to the input schema 1 of operation number 7, copy the output schema 504 of operation number 6 to the input schema 2, and add the variable area and extension variable $ # e () to the output schema 504. Thus, the operation S with the operation number 8 is acquired (steps S1300-S1320, S1280, S1290).

  The output schema 504 with the operation number 7 is copied to the input schema 1 with the operation number 8, the variable area and the extension variable $ # e () are added to the output schema 504, and the process ends (steps S1300 to S1320, S1280, and S1290). An example of the output result of the schema generation process is the input / output schema table 500 shown in FIG. In FIG. 30, when there is only one input schema, it is stored in the input schema 1 item, and when there are two, the second is stored in the input schema 2 item. It may be increased or decreased.

  Here, the process of the master server executed in parallel with step S14 will be described. The distributed plan generation unit 23 performs a distributed plan update process (Step S10), updates the distributed plan, and then executes a distributed plan order determination process that determines a portion whose execution order is non-deterministic based on the updated distributed plan. (Step S13). The distributed plan order determination process in step S13 is the same as step S12 except that the target plan is not a local plan but a distributed plan.

  Next, the schema generation unit 18 generates an input / output schema for each operation in the determined distributed plan (step S15). The schema generation process in step S15 is the same as step S14 except that the target plan is not a local plan but a distributed plan.

  When the schema generation processing is performed in each of the master server and the slave server, each of the master server and the slave server executes a plan based on the generated input / output schema. That is, the local plan execution unit 36 of the slave server executes the local plan based on the input / output schema generated in the schema generation process (step S14) (step S9). Further, the distributed plan execution unit 16 of the master server executes the distributed plan based on the schema generated by the schema generation process (step S15) (step S11).

  In the local plan execution (step S9), the local plan execution unit 33 performs the schema change processing by passing the input data and the prepared input schema to the schema change unit 36 when performing each calculation of the local plan. (Step S16). Similarly, in the distributed plan execution (step S11), when the distributed plan executing unit 16 performs each calculation of the distributed plan, the input data and the prepared input schema are passed to the schema changing unit 19, and the schema changing process is performed. (Step S16).

  Here, with reference to FIG. 31, the schema changing process performed when the schema changing unit 19 of the master server executes the distributed plan in step S16 will be described.

  The schema changing unit 19 acquires the data D having the schema S that is the input of the operation to be executed next by the distributed plan executing unit 16 and the operation input schema T prepared in advance by the schema generating unit 18 (step S1400). Next, it is determined whether the items of the variables of the schema S and the schema T match (step S1410).

  If the items of the variables of the schema S and the schema T do not match (No in step S1410), the variable list VL of the extension variable $ # e of the schema S is acquired, and it is determined whether the list is empty (step S1420). ).

  If the variable list VL of the extended variable $ # e in the schema S is not empty (No in step S1420), each variable in the extended variable list VL is added as a variable item in the schema S, and the VL is changed to empty (step) S1430). Next, a list DL of variable items that exist in the schema S and do not exist in the schema T is acquired (step S1430). Next, the process proceeds to step S1450. If the variable list VL of the extended variable $ # e in the schema S is empty (step S1420 is Yes), the process proceeds to step S1450.

  In step S1450, it is determined whether the variables in the variable item list DL are discontinuously arranged in the schema S (step S1450).

  When the variables in the variable item list DL are discontinuously arranged in the schema S (Yes in step S1450), the data in the schema S and the data D are rewritten so that the variables in the variable item list DL are continuous. (Step S1460). Next, the process proceeds to step S1470. If the variables in the variable item list DL are not discontinuously arranged in the schema S (No in step S1420), the process also proceeds to step S1470.

  In step S1470, the variable in list DL is deleted from the variable item of schema S and added to the variable list of extension variable $ # e (step S1470). Next, the total size of the variables in the list DL is stored in the variable area item of the data D, and the process ends (step S1480). Note that when the items of the variables of the schema S and the schema T match (Yes in step S1410), the process is also ended. Note that the flowchart shown in FIG. 31 operates in the same manner only when the target is a local plan or a distributed plan even when the schema change unit 36 processes a calculation in the local plan execution unit 33.

  Referring to FIG. 31, the schema changing unit 19 applies the input schema of the operation number 7 of the computer 0 and the schema of each data transmitted from the computer 1, the computer 2, and the computer 3 shown in FIG. 26. The operation when the schema change process is performed will be specifically described. This schema change process is performed when the reception plan of the distributed plan operation number 7 in the local plan candidate shown in FIG. 24, computer 1, computer 2, and computer 3 is shown in FIG. 12, FIG. 18, FIG. Is what you do.

  First, the input schema T of operation number 7 of the computer 0 in FIG. 26 and the schema S of the data transmitted from the computer 1 are acquired (step S1400). Since the variable items of the schema S and the schema T match, the process ends (step S1410).

  Next, the input schema T of the calculation number 7 of the computer 0 and the schema S of the data transmitted from the computer 2 are acquired (step S1400). Since the variable items of the schema S and the schema T do not match and the variable list of the extension variable $ # e of S is empty, $ u and $ v are acquired as variables that exist in the schema S and do not exist in the schema T ( Step S1410, Step S1420, Step S1440). Since the variables $ u and $ v are continuously arranged in the schema S, the variables $ u and $ v are deleted from the items of the schema S and added to the variable list of the extended variable $ # e (steps S1450 and S1470). ). Finally, the total size of the variables of $ u and $ v is stored in the extension area (step S1480).

  Next, the input schema T of the calculation number 7 of the computer 0 and the schema S of the data transmitted from the computer 3 are acquired (step S1400). Since the variable items of the schema S and the schema T do not match and the variable list of the extension variable $ # e of S is empty, $ u is acquired as a variable that exists in the schema S and does not exist in the schema T (step S1410, Step S1420, Step S1440). Since the variable $ u is continuously arranged in the schema S, the variable $ u is deleted from the items of the schema S and added to the variable list of the extended variable $ # e (steps S1450 and S1470). Finally, the total size of the variable of $ u is stored in the extension area (step S1480). The result of the schema change process is shown in FIG. FIG. 32 is an example showing items included in the schema after the schema change processing. As shown in FIG. 32, in the present embodiment, after the schema change process, there are items of “variable area” 401, “variable˜” 402, and “extended variable $ # e (V1..., Vn)” 403. .

  Note that the schema change process described above is an example that is performed when data is transferred in the master server's distributed plan calculation and slave server's local plan calculation, but the data is calculated in the same server or between slave servers. It can also be applied when handing over. In FIG. 24, the variable $ z is received before the server-to-server JOIN with the operation number 6.

  However, as can be seen from the local plan candidates in FIGS. 18, 12, and 19, the computer 1 has three sets of data $ z, $ u, and $ v, the computer 2 has the variable $ z, and the computer 3 has the variable $. Two sets of data of z and $ u are transmitted. For this reason, a table with a different number of columns will be handled as it is. Therefore, the schema change unit 18 of the master server changes the schema of the data of each computer shown in FIG. 26 so that the data of all the computers can be regarded as the same schema as shown in FIG. In FIG. 24, since only the variable $ z is necessary in the server-to-server JOIN with the operation number 6, all other variables are handled as columns of the extended variable $ # e storing one variable length data. It has become. The variable area stores the size of the variable length area. As a result, all of the tables can be handled as the same table when executing the JOIN between servers.

  According to the distributed database search apparatus of the present embodiment, a local plan is created for each slave server, so there is a possibility that part of the distributed plan differs for each slave server. That is, the schema of data sent to each slave server may be different. In this case, the present embodiment changes the difference between the schema (input schema) of the data to be transmitted and the schema of the received data (output schema) when the schema changing units 18 and 20 deliver the data. By doing so, it can be handled as data of the same schema.

  That is, when creating an efficient local plan for each slave server, there may be a plurality of different schema data. As described above, when an efficient local plan is created for each slave server, it is necessary to process the data of a plurality of different schemas uniformly.

  As described above, according to the present embodiment, data of a plurality of different schemas can be handled in a unified manner. Further, in the present embodiment, it is possible to realize unified handling of data of a plurality of different schemas only by rewriting only a schema or a partial area of the schema and data.

  As mentioned above, although embodiment of this invention was described, these embodiment is shown as an example and is not intending limiting the range of invention. These novel embodiments can be implemented in various other forms, and various omissions, replacements, and changes can be made without departing from the scope of the invention. These embodiments and modifications thereof are included in the scope and gist of the invention, and are included in the invention described in the claims and the equivalents thereof.

  DESCRIPTION OF SYMBOLS 11 ... Syntax analysis part, 12 ... Query division part, 13 ... Distributed plan production | generation part, 14 ... Distributed plan combination calculation addition part, 15 ... Distributed plan update part, 16 ... Distributed plan execution part, 17 ... Transmission / reception part, 18 ... Schema Generation unit, 19 ... schema change unit, 31 ... local plan selection unit, 32 ... local plan candidate generation unit, 33 ... local plan execution unit, 34 ... transmission / reception unit, 35 ... schema generation unit, 36 ... schema change unit

Claims (7)

A search method for a distributed database search device in which a plurality of slave servers having a database for storing data and a master server for storing management information of the database and searching for the data based on a query query are connected,
Intra-server arithmetic processing that operates on each of the slave servers, or includes inter-server arithmetic processing that collects data from the intra-server arithmetic and the plurality of slave servers and operates on a master server, and is stored in a plurality of databases Generating a distributed plan for retrieving data based on the query query;
In the distributed plan, there is an operation that can be executed in parallel with the inter-server operation processing, and there is an operation that requires both the result of executing the operation and the result of the inter-server operation processing, An operation that can be executed in parallel with the inter-server operation processing and the operation between the servers are executed in parallel, and the data obtained by the operation that can be executed in parallel with the inter-server operation processing and the operation between the servers are obtained. Adding a split query join operation that joins the combined data to the distributed plan;
Extracting a plan related to the slave server from the distributed plan;
Generating local plan candidates in which the transmission / reception operation of data related to the split query join operation and the split query join operation included in the extracted plan is changed;
Generating a new local plan candidate in which the transmission / reception calculation of the data related to the divided query combination calculation and the divided query combination calculation included in the generated local plan candidate is changed;
Calculating a calculation cost of each of the generated local plan candidates and the extracted plan, and selecting a plan that minimizes the calculation cost as a local plan;
Updating the distributed plan based on the selected local plan;
A search method comprising: A distributed database search device to which a plurality of slave servers having a database for storing data and a master server for searching the database based on a query query are connected,
The master server is
A storage unit for storing management information of each database of the slave server;
Intra-server arithmetic processing that operates on each of the slave servers, or includes inter-server arithmetic processing that collects data from the intra-server arithmetic and the plurality of slave servers and operates on a master server, and is stored in a plurality of databases A distributed plan generating unit for generating a distributed plan for searching for data based on the query query;
In the distributed plan, there is an operation that can be executed in parallel with the inter-server operation processing, and there is an operation that requires both the result of executing the operation and the result of the inter-server operation processing, An operation that can be executed in parallel with the inter-server operation processing and the operation between the servers are executed in parallel, and the data obtained by the operation that can be executed in parallel with the inter-server operation processing and the operation between the servers are obtained. A split query join operation addition unit for adding a split query join operation for combining the collected data to the distributed plan;
A distributed plan update unit that updates the distributed plan based on a local plan received from the slave server;
Comprising
The slave server is
A plan related to the slave server is extracted from the distributed plan, and a local plan candidate is generated by changing the split query join operation included in the extracted plan and the data send / receive operation related to the split query join operation. A local plan candidate generator,
A distributed database search device comprising: a local plan selection unit that calculates a calculation cost of each of the generated local plan candidates and the extracted plan, and selects a plan having the minimum calculation cost as a local plan.   The said server calculation WHEREIN: When the column of the data transmitted / received differs in the said master server and the said slave server, the schema change part which makes the said column the column in which the variable-length data was memorize | stored is provided. Distributed database search device. A master server connected to a plurality of slave servers having a database for storing data and constituting a distributed database device for searching the database based on an inputted query query,
A storage unit for storing management information of each database of the slave server;
Intra-server arithmetic processing that operates on each of the slave servers, or includes inter-server arithmetic processing that collects data from the intra-server arithmetic and the plurality of slave servers and operates on a master server, and is stored in a plurality of databases A distributed plan generating unit for generating a distributed plan for searching for data based on the query query;
In the distributed plan, there is an operation that can be executed in parallel with the inter-server operation processing, and there is an operation that requires both the result of executing the operation and the result of the inter-server operation processing, An operation that can be executed in parallel with the inter-server operation processing and the operation between the servers are executed in parallel, and the data obtained by the operation that can be executed in parallel with the inter-server operation processing and the operation between the servers are obtained. A split query join operation addition unit for adding a split query join operation for combining the collected data to the distributed plan;
A master server comprising: a distributed plan update unit that updates the distributed plan based on a local plan received from the slave server. A slave server comprising a database and configured as a distributed database search system connected to a plurality of master servers that search the database based on an input query query;
A local plan in which a plan related to the slave server is extracted from the distributed plan received from the master server, and the transmission / reception calculation of the data related to the divided query join operation and the divided query join operation included in the extracted plan is changed. A local plan candidate generator for generating candidates;
A slave server comprising: a local plan selection unit that calculates a calculation cost of each of the generated local plan candidate and the extracted plan, and selects a plan having the minimum calculation cost as a local plan.   The slave server according to claim 5, wherein the operation cost of the split query join operation added by the split query join operation adding unit is included in the operation cost of the local plan candidate calculated by the local plan selection unit. A program of a distributed database search device to which a plurality of slave servers having a database for storing data and a master server for storing management information of the database and searching for the data based on a query query are connected,
On the computer,
Intra-server arithmetic processing that operates on each of the slave servers, or includes inter-server arithmetic processing that collects data from the intra-server arithmetic and the plurality of slave servers and operates on a master server, and is stored in a plurality of databases A function for generating a distributed plan for retrieving data based on the query query;
In the distributed plan, there is an operation that can be executed in parallel with the inter-server operation processing, and there is an operation that requires both the result of executing the operation and the result of the inter-server operation processing, An operation that can be executed in parallel with the inter-server operation processing and the operation between the servers are executed in parallel, and the data obtained by the operation that can be executed in parallel with the inter-server operation processing and the operation between the servers are obtained. A function for adding a split query join operation to join the distributed data to the distributed plan;
A function of updating the distributed plan based on the local plan received from the slave server;
A plan related to the slave server is extracted from the distributed plan, and a local plan candidate is generated by changing the split query join operation included in the extracted plan and the data send / receive operation related to the split query join operation. Function and
A function of calculating the calculation cost of each of the generated local plan candidate and the extracted plan, and selecting a plan with the minimum calculation cost as a local plan;
A program that realizes

Images