JP4327481B2 - Database system, server, inquiry input method and data update method - Google Patents

Description

[0001]
[Technical field to which the invention belongs]
The present invention relates to a search system including a plurality of database servers that execute queries and a front-end server that inputs queries received from outside to the database server.
[0002]
[Prior art]
In recent years, parallel and distributed databases have been promoted for the purpose of improving performance and reliability. FIG. 22 shows a typical configuration example of a conventional database system.
[0003]
This conventional database system creates a plurality of replica databases 104 for one master database 103, and the front-end server 102 distributes queries to these replica databases 104 to input database search performance. Improvements are being made. In some cases, reliability can be improved by switching one of the active system and the other to the standby system in the event of a failure.
[0004]
As a method of distributing and inquiring queries to a plurality of servers as described above, a method of determining a server to be allocated by round robin, or a method of measuring a load such as a CPU usage rate and allocating it to a server with a light load is conventionally used. It is used.
[0005]
For example, calculate the resource usage of each batch job, execute multiple jobs, calculate the cumulative resources, and if the cumulative resources exceed the server's allowable amount, submit a new job A batch job scheduling method that avoids resource contention by not doing so has been proposed (see, for example, Patent Document 1).
[0006]
In order to further improve the performance of the database system, it is important to avoid resource contention such as database buffer contention and disk contention in the replica database 104.
[0007]
Hereinafter, database buffer contention (cache contention) will be described with reference to FIGS. The disk 201 is connected to the server 200, and the disk 201 stores three tables (205, 206, and 207). When inquiry 1 (220) requesting data in Table 1 (205) is input to the server 200, necessary data is transmitted from Table 1 (205) on the disk 201 to the inquiry.
[0008]
Since disk input / output (disk I / O) requires more processing time than memory input / output, a memory is used as a disk input / output cache. This cache area (database buffer) is created on the memory 203 and is divided into several KB data pages 204. The data page 204 is managed by LRU (Least Recently Used) so that the more frequently used data remains in the memory 203.
[0009]
When a query 1 (220) for obtaining data in Table 1 (205) is issued, the database buffer is searched, and if the data in Table 1 (205) necessary for the database buffer on the memory 203 is stored. It is possible to obtain results without disk I / O.
[0010]
On the other hand, as shown in FIG. 24A, when query 2 (221) for acquiring data in Table 2 (206) is input to the server 200, necessary data is not stored in the memory 300. Disk I / O is performed. Then, as shown in FIG. 24B, a part of the memory 301 is overwritten with the data in Table 2 (206), which is the content of the inquiry.
[0011]
For example, when two queries that are different from each other and require a large result are executed in succession, each other overwrites the database buffer in the memory 300, and the disk I / O is executed each time the query is executed. Arise. On the other hand, in the case of an inquiry that can share the contents, there is a high possibility that the data stored in the cache (database buffer) can be used, and the result can be obtained with less disk I / O. In this way, the queries are compatible, and the performance of the database system changes depending on the order in which the queries are input.
[0012]
As a method of avoiding database buffer contention (cache contention), there is a method of sharing a database buffer among a plurality of queries that request the same data. For example, if two different queries (queries) request the same data, and the data is larger than the database buffer area, the second query (query 2) when the first query has read the data halfway. When the query is called, the first half of the data may have already been erased from the database buffer. That is, when the data required by the query is large, there is a possibility that the first half of the data is overwritten by the second half of the data currently read by the first query (query 1).
[0013]
In such a case, the first half of the data is read again from the disk by query 2 and the buffer is overwritten. However, since the data stored in the overwritten portion (the latter half of the data read by the query 1) is data that is also required by the query 2 thereafter, useless disk I / O occurs. Therefore, in the second reading, instead of reading from the beginning, the method of reading from the same location as the query 1 being executed (merry-go-round scan) while sharing the buffer with the first query (query 1) is a Microsoft database. It has been introduced to SQL Server, which is a product (see Non-Patent Document 1, for example).
[0014]
As another method of effectively using other buffers, there is a method of classifying caches according to the importance of data. Oracle, which is an Oracle database product, classifies buffers into three areas: keep, default, and recycle, and allows specification of size and management method for each area. For example, data that wants to be resident in the buffer is classified into keep, data that may be overwritten is recycled, and others are default. However, the setting requires an understanding of the nature of the data, and the setting needs to be changed whenever the data size or system configuration changes.
[0015]
In a distributed and parallel computer environment, an increase in operation cost in addition to performance becomes a big problem. If the number of computers to be managed increases, the operating cost will increase.
[0016]
In business using IT systems, system downtime leads to enormous loss, so stable system operation is essential. For example, in order to avoid a system down due to concentration of access to the system, a server is added according to the number of accesses.
[0017]
In such an environment where the configuration and settings change frequently, it is not easy to perform management following the change. If the tuning or environment setting is performed manually for each computer every time the environment changes, the operation management cost will increase. As a method for reducing the operation management cost, there is automatic tuning. There are products that can automatically tune the configuration parameters of a single database, such as Microsoft SQL Server. However, the correspondence to the parallel distributed environment is not sufficient.
[0018]
As another method for reducing the operation cost, there is a method in which operation management (all or a part) is outsourced using an MSP (Management Service Provider) undertaking management of the IT system. For example, in the monitoring service provided by MSP, performance information such as the CPU usage rate of the server is monitored and an alarm is issued when a predetermined threshold is exceeded.
[0019]
[Patent Document 1]
JP 9-311795 A
[Non-Patent Document 1]
"Database Architecture", [online], Internet <URL: http://www.microsoft.com/japan/msdn/sqlserver/sql2000/thestorageengine.asp>
[0020]
[Problems to be solved by the invention]
Queries input to the database system have compatibility with other inquiries and servers. In a combination that is not compatible, resource contention occurs and performance decreases. For example, when a database buffer contention occurs, a disk I / O that is slower than the memory is generated, resulting in a large performance problem.
[0021]
In the case of a database alone, automatic tuning technology has been developed, but there is no technology for optimizing the entire system in a parallel / distributed environment.
[0022]
As a method of distributing the inquiry to a plurality of servers, for example, there are a method of selecting a server by land robin or a server having a light load. In such a method, since compatibility between queries and compatibility with the server are not taken into consideration, there is a possibility that resource contention occurs at the time of execution. Therefore, in parallel / distributed environments, it is necessary to avoid resource contention and improve overall system throughput by implementing appropriate scheduling in consideration of compatibility between queries and between queries and servers. .
[0023]
In addition, if parallelization / distribution of servers advances and the number of servers to be managed increases, it is difficult to perform fine tuning individually and the cost increases. In addition, it is not easy to manage not only a single server but the entire system. Therefore, it is necessary to learn the scheduling method autonomously and manage the entire system at a low cost in a parallel / distributed environment.
[0024]
[Means for Solving the Problems]
The present invention has a database capable of searching the same content, a plurality of database servers that search the database according to a query request, and accepts the query request, and inputs a query to the database server using a predetermined rule A management server that manages rules used by the front-end server, and a network that connects the servers and client terminals that request inquiries, the management server executing the database server A log acquisition unit that acquires a log; and a rule generation unit that generates the rule based on compatibility with a query calculated using the acquired log, and the front-end server is generated by the management server The above query Having the query dosing means for introducing allowed.
[0025]
[Action and effect of the invention]
In the present invention, there are databases capable of searching the same content, a plurality of database servers that search the database according to the inquiry request, and the inquiry request is received, and the inquiry is input to the database server using a predetermined rule. In a query input method used in a database system comprising: a front-end server that performs management of a rule used by the front-end server; and a network that connects each server and a client terminal that requests a query. The management server acquires an execution log of the database server, generates the rule based on a compatibility related to an inquiry calculated using the acquired log, and the front-end server generates a rule generated by the management server Using, to introduce the inquiry. That is, a queue and a scheduler are provided in the front-end server, the compatibility between the queries or between the query and the database server is determined, and the queries are input in a combination that is compatible with the scheduler. This scheduling is performed based on rules, and scheduling is performed so as to avoid resource contention, so that the performance of the entire database system can be improved.
[0026]
In addition, the management server acquires the execution log of the database server, and statistically analyzes the acquired execution log, thereby calculating the compatibility between queries or between the query and the database server, and based on the calculated compatibility. Generate a rule and send it to the front-end server. Since this rule is generated based on the execution log, the rule can be learned autonomously even when the environment or the characteristics of the inquiry change.
[0027]
DETAILED DESCRIPTION OF THE INVENTION
FIG. 1 is a configuration diagram of the database system according to the first embodiment of this invention.
[0028]
The client 100 issues an inquiry to the database via the network 101 (intranet or Internet (registered trademark, the same applies hereinafter)).
[0029]
The database includes a database server (front end) 102 and a plurality of database servers 103 and 104 on the back end. The front end 102 receives the inquiry and inputs (dispatch) the inquiry to the back-end database servers 03 and 104.
[0030]
The back-end database server includes one master database server (master) 103 and a plurality of replica database servers (replicas) 104. The master 103 has a storage device 106, and the replica 104 has a storage device 107. The storage device 107 connected to the replica 104 records the same content as the storage device 106 connected to the master 103. Usually, the update processing and search processing of the stored contents are performed in the master 103, but only the search processing is performed in the replica 104. Then, by periodically performing replication, the changed contents of the storage device 106 of the master 103 are reflected in the storage device 107 of the replica 104.
[0031]
The replica 104 includes an inquiry execution unit 111 and a log recording / transmission unit 110. The inquiry execution unit 111 executes the inquiry transmitted by the front end 102. The log recording / transmission unit 110 records an execution log (inquiry type, processing time, etc.) and transmits it to the management server 105.
[0032]
The management server 105 includes a log acquisition unit 120, a compatibility calculation unit 121, a rule generation unit 122, and a rule management unit 123. Further, the management server 105 has a rule database 140.
[0033]
The log acquisition unit 120 receives the execution log transmitted by the replica 104 and acquires the execution log of the replica 104.
[0034]
The compatibility calculation unit 121 analyzes the execution log acquired by the log acquisition unit 120 and calculates the compatibility between the queries and the compatibility between the query and the replica 104 as the compatibility regarding the query. Compatibility can be calculated between query attributes stored in the execution log, between query attributes and replicas, and between users who have issued queries.
[0035]
The rule generation unit 122 generates a rule for scheduling an inquiry based on the calculated compatibility. For example, since the query A and the query B are compatible, a rule that should be input to the same replica 104 is generated. Here, the generated rule is transmitted to the front end 102.
[0036]
The rule management unit 123 stores the rule generated by the rule generation unit 122 and the number of application times of the rule recorded by the front end 102 in the rule database 140. The rule database 140 can also store hardware and software performance information (for example, resource usage rates such as a CPU usage rate and a memory usage rate) of each replica 104. The administrator can manage which rule is actually used by the information regarding the rule and the number of times the rule is applied.
[0037]
The front end 102 has a queue 131 and a scheduler 130, receives an inquiry received from the client 100 by the queue 131, schedules the scheduler 130, distributes the inquiry 104, and inputs it.
[0038]
The scheduler 130 performs scheduling based on the rules generated by the management server 105 and determines the replica 104 to which an inquiry is input. When an inquiry is made to the replica 104, the number of times the rule is applied is recorded for each rule. Information regarding the number of times the rule is applied is transmitted to the management server 105.
[0039]
The replica 104 executes the inquiry. Then, based on the query executed in the replica 104, the management server 105 calculates compatibility and generates a rule. Then, the front end 102 inputs an inquiry to the replica 104 based on the rules generated in the management server. Then, the replica 104 executes an inquiry.
[0040]
By repeating this cycle, autonomous generation of scheduling rules adapted to system changes (for example, server addition, data size increase) and input changes (for example, input load increase, query content change) Is possible. In the front end 102, by using the generated scheduling rule to input a query in a combination that avoids resource competition, it is possible to improve the performance of the entire database system at a low cost.
[0041]
Next, processing of the replica 104, the management server 105, and the front end 102 will be described.
[0042]
FIG. 2 is a flowchart illustrating processing of the database server (replica 104) according to the first embodiment of this invention.
[0043]
First, an inquiry from the client 100 is accepted (step 400). Then, the received inquiry is executed (step 401). Subsequently, an inquiry execution log 410 is recorded (step 402), and the execution log 410 is transmitted to the management server 105. Then, the next inquiry is accepted (step 400).
[0044]
The execution log 410 may be transmitted in real time for each inquiry. For example, an event is transmitted for each execution of an inquiry, and the execution log acquisition destination (management server 105) records the execution log by acquiring the event (for example, Microsoft SQL Server 2000). A plurality of inquiry execution logs 410 may be transmitted together. For example, the execution log 410 is recorded and stored in the replica 104 for a certain period, and batch transferred to the management server 105 at an appropriate timing.
[0045]
The execution log 410 is transmitted in the format shown in FIG. That is, for each inquiry, the inquiry attributes such as the inquiry content (SQL sentence or stored procedure) 700, processing time 701, start time 702, end time 703, user name 704, etc. are recorded.
[0046]
In addition to the execution log 410, other performance information such as hardware and software resource usage rates can be sent to the management server 105. For example, the CPU usage rate and memory usage rate of the replica 104 can be considered. These pieces of performance information are not essential for the compatibility calculation, but are managed as time-series data and are useful for monitoring and analyzing the performance of the replica 104.
[0047]
FIG. 4 is a flowchart showing processing of the management server 105 according to the first embodiment of this invention.
[0048]
The execution log 410 is acquired from the replica 104 (step 500).
[0049]
Then, inquiries are grouped as preprocessing for compatibility calculation (step 501). The compatibility calculation needs to be performed not for each individual query but for each group obtained by classifying a plurality of queries into patterns. When it is performed for each individual inquiry, rules are generated only for the types of inquiry, and the rules are applied only to the same inquiry, so the usability of the rules is lowered. Moreover, if it calculates separately, the number of compatibility combinations will increase and processing burden will increase.
[0050]
After grouping, compatibility is calculated for each group (step 502), and the result of the compatibility calculation is ruled (step 503). Finally, the generated rule 510 is transmitted to the front end 102 (step 504).
[0051]
The front end 102 executes scheduling based on the received rule, and feeds back the rule and the number of times of application to the management server 105 at an appropriate timing (a predetermined interval or when requested by the management server 105). To do.
[0052]
The management server 105 receives the rule and the number of times the rule is applied (step 505), and stores the received information in the rule database 140 (step 506).
[0053]
FIG. 5 is a diagram illustrating inquiry grouping (step 501) according to the first embodiment of this invention.
[0054]
Hereinafter, the grouping will be described using a simple search SQL of “select a from A where b> 3”. Here, A described as an argument of the from clause is a table name. The table is composed of a plurality of rows, and the rows are composed of a plurality of columns. Specify the column name as a search condition in the argument of the where clause. In this case, the condition that the column b of the table A is larger than 3 is specified. Which column is returned as a result is specified by an argument of the select clause (in this example, only column a is acquired).
[0055]
In grouping example 1 shown in FIG. 5A, queries are grouped according to the table used. Queries with the same table used in the search condition are grouped into the same query. Therefore, the inquiry 1011 and the inquiry 1012 that use only the table A are classified into the same group, and the inquiry 1013 and the inquiry 1014 that use only the table B are classified into the same group.
[0056]
In grouping example 2 shown in FIG. 5B, queries are grouped by table name and acquisition column name. Queries having the same table used in the search condition and column names returned as search results are grouped into the same query. Therefore, the query 1021 and the query 1022 that acquire the column a of the table A are classified into the same group, and the query 1023 and the query 1024 that acquire the columns a and c of the table A are classified into the same group. At this time, the search conditions may be different.
[0057]
In the grouping example 3 shown in FIG. 5C, grouping is performed based on the table name, the acquisition column name, and the search condition. Queries that are identical except for constant values in the search condition are grouped into the same query. Therefore, a condition is specified using the column b of the table A, and the query 1031 and the query 1032 for obtaining the column a of the table A are classified into the same group, the condition is specified using the column c of the table A, and the table A The query 1033 and the query 1034 for acquiring the column a are classified into the same group.
[0058]
Although detailed grouping becomes possible in the order of FIGS. 5A, 5B, and 5C, the amount of processing for grouping also increases.
[0059]
Next, the compatibility calculation (step 502) will be described.
[0060]
Here, as the compatibility, consider the degree of improvement in processing time compared to the processing time in the case of executing two queries simultaneously compared to the processing time in the case of executing them individually. For example, if the tables used in the search condition for two queries are the same and the database buffer can be shared, the processing time can be reduced by executing these two queries simultaneously or sequentially. It means that compatibility is good. On the other hand, if the database buffer cannot be shared, the performance is degraded by disk I / O, which means that the compatibility is bad.
[0061]
FIG. 6 is a diagram illustrating an execution state of an inquiry according to the first embodiment of this invention.
[0062]
In the example shown in FIG. 6, Q2 (902) is executed at the same time as Qi (900). A part of the execution time of Q1 (901) overlaps with the execution time of Qi (900).
[0063]
In this embodiment, an inquiry Qj that overlaps with the execution of Qi (900) is searched. In this search, Qj satisfying the condition of the end time of Qj> the start time of Qi (900) and the start time of Qj <the end time of Qi (900) is searched. In the example shown in FIG. 6, Q1 (901) and Q2 (902) meet this condition.
[0064]
In addition, instead of searching only for a query that completely overlaps, a query Qj that overlaps with the time (914) obtained by adding a margin time Δ before and after the execution time of Qi may be searched. In this search, a search is made for Qj satisfying the following condition: Qj end time> Qi (900) start time−Δ (912) and Qj start time <Qi (900) end time + Δ (913). In this way, by performing a search using the allowance time Δ, in addition to queries executed at the same time, queries executed immediately before and after Qi can be included in the target. In the example shown in FIG. 6, Q3 (903) satisfies this condition in addition to Q1 (901) and Q2 (902).
[0065]
FIG. 7 is a diagram for explaining a compatibility matrix used for the compatibility calculation in the first embodiment of the present invention.
[0066]
The compatibility calculation is performed based on a compatibility matrix indicating the compatibility between queries. For example, Cij (803) of the compatibility matrix 800 represents the compatibility between the inquiry Qi (801) and the inquiry Qj (802), and the total processing time of Qi (801) when executed simultaneously with Qj (802). It is. On the other hand, Ai (804) represents the total processing time of Qi (801) in combination with all Qj (802).
[0067]
The call matrix 810 represents how many queries were used to calculate the affinity. For example, Tij (813) represents how many queries were used to calculate Cij (803) (the number of times Qi (801) was called simultaneously with Qj (802) in the execution log). Ti (814) represents the number of inquiries used for the calculation of Ai (804) (the number of executions of Qi (801) included in the execution log).
[0068]
FIG. 8 is a flowchart showing the compatibility calculation (step 502) according to the first embodiment of this invention, and is executed for each log of the replica 104.
[0069]
First, an inquiry executed simultaneously with Qi (900) is searched (step 1101). For example, the search is performed by the method described in FIG.
[0070]
For all j that match the search conditions, the calculations of equations (1) to (3) are performed, and the values of the compatibility matrix 800 and the call matrix 810 are updated (steps 1102 and 1103).
[0071]
Cij = Cij + Qi processing time (1)
Ai = Ai + Qi processing time (2)
Tij = Tij + 1 (3)
Finally, the values of all the elements of the compatibility matrix 800 are updated according to the equation (4) (steps 1104 and 1105).
[0072]
Cij = Ai / Ti-Cij / Tij (4)
The right side of the equation (4) represents (Qi (801) average processing time)-(Qi (801) average processing time when executed simultaneously with Qj (802)). That is, with respect to Qi (801), the performance improvement effect by executing simultaneously with Qj (802) is calculated. This value is compatible between Qi (801) and Qj (802).
[0073]
Next, rule generation (step 503) will be described.
[0074]
In the rule generation (step 503), the attributes recorded in the execution log 410 and the compatibility with respect to the server are ruled. For example, compatibility between queries, compatibility between queries and servers, compatibility between users and servers, and the like can be considered. Here, as an example, generation of rules regarding compatibility between queries and rules regarding compatibility between queries and servers will be described.
[0075]
FIG. 9A is a flowchart illustrating rule generation (step 503) between queries according to the first embodiment of this invention.
[0076]
The calculation of the compatibility matrix 800 and the call matrix 810 has already been completed for each replica 104. Further, the calculation shown in FIG. 9A is performed for each execution log 410 of the replica 104.
[0077]
First, it is determined whether or not all Cij are subject to rule formation, and the rule formation targets are narrowed down (step 1201). Specifically, based on a comparison result between a value obtained by dividing the absolute value of Cij by Ai and a predetermined constant (determination result as to whether or not larger than a predetermined constant P1 (0 ≦ P1 <1)). , Cij is determined as a rule target. Cij that has a small effect on performance in the determination based on this condition is excluded from rule formation. In other words, regardless of whether the compatibility is good or bad, only those having a large influence on performance are subject to rule formation. When P1 = 0, all Cij are subject to rule formation.
[0078]
If | Cij | / Ai is larger than P1, a rule is formed (step 1202) and added to the rule list 1 (step 1203).
[0079]
FIG. 10A shows rule list 1 (1910). In the rule list 1 (1910), a rule is constituted by a query pair condition 1911, a compatibility value 1912, and a number of times 1913. The number of times 1913 represents the number of times the rule has been applied, and is a value set by the front end 102. The initial value is set to 0.
[0080]
The rule list 1 (1910) includes a plurality of rules that satisfy the condition 1201. That is, the rule-making is to add the compatibility value 1912 for Ci, j and the number of times 1913 (initial value = 0) to the rule list 1 as a set 1911 of queries i and j for Ci, j.
[0081]
FIG. 9B is a flowchart showing rule generation (step 503) between the inquiry and the server.
[0082]
First, in step 1220, the average Ave (Ai, s) of the average execution time Ai, s of Qi calculated for each server is calculated (s is the server name). Next, for all Ai, s, the improvement rate | Ai, s−Ave (Ai, s) | / Ave (Ai, s) is greater than a predetermined constant P2 (0 ≦ P2 <1) under the condition 1222. It is determined whether or not. In this determination, Ai, s that has a small effect on performance is excluded from the rule. In other words, regardless of whether the compatibility is good or bad, only those having a large influence on performance are subject to rule formation. When P2 = 0, all Ai, s are subject to rule formation.
[0083]
If | Ai, s-Ave (Ai, s) | / Ave (Ai, s) is larger than P2, a rule is formed (step 1223) and recorded in the rule list 2 (step 1224).
[0084]
FIG. 10B shows rule list 2 (1930). In the rule list 2 (1930), a rule is composed of a query / server set 1931, an affinity value (Ave (Ai, s) −Ai, s) 1932, and a count 1933. The number of times 1934 represents the number of times the rule is applied, and is a value set by the front end 102. The initial value is set to zero.
[0085]
The rule list 2 (1930) includes a plurality of rules that satisfy the condition 1222. That is, the rule-making is a rule for Ai, s as a set 1931 of inquiry i and server s, (Ave (Ai, s) -Ai, s) as compatibility value 1932, and number of times 1933 (initial value = 0). To add to list 2.
[0086]
FIG. 11 is a diagram for explaining a compatibility matrix used for compatibility calculation between a query and a server (replica 104) in the first embodiment of this invention.
[0087]
A compatibility matrix 800 and a call matrix 810 shown in FIG. 7 are provided for each replica 104. Aim (804) of the compatibility matrix 800 is the total value of the processing times of Qi (801) in the combination with all Qj (802) in the replica m. In addition, Tim (814) of the call matrix 810 is the number of inquiries used for calculating Ai (804) in the replica m (the number of times Qi (801) is executed in the log).
[0088]
Then, when the inquiry Qi (801) is input, it is assumed that the replica that gives the minimum value of Aim by comparing Aim (804) for the replica m is the most suitable replica for executing Qi. And compatibility between queries.
[0089]
FIG. 12 is a diagram illustrating data files managed in the rule database 140 by the management server 105 according to the first embodiment of this invention.
[0090]
The data file 2004 includes rules 2000 and 2001, an execution log 2003, and performance information 2002. The rules are constituted by a rule list 1 (2000) indicating compatibility between queries and a rule list 2 (2001) indicating compatibility between queries and servers. There are as many rule lists 1 (2000), execution logs 2003, and performance information 2002 as the number of replicas 104.
[0091]
The execution log 2003 is performance information related to the query executed by each replica 104, and is saved in the format described above with reference to FIG. Based on the execution log 2003, rules 2000 and 2001 are generated.
[0092]
The performance information 2004 is time-series data of performance information related to hardware and software of each replica 104, and records, for example, a CPU usage rate, a memory usage rate, and the like.
[0093]
These data files 2004 may store only the latest data, or may store new data whenever there is a change and manage it as time-series data.
[0094]
Next, processing of the front end 102 will be described.
[0095]
FIG. 13 is a flowchart illustrating processing of the front end 102 according to the first embodiment of this invention.
[0096]
The front end 102 executes scheduling based on the received rule. First, the rule 510 (rule list 1, rule list 2) transmitted by the management server 105 is received (step 600).
[0097]
Then, it is determined whether or not the rule needs to be edited (step 601), and if necessary, editing is executed (step 602). Rules are written in a simple if-then type, so humans (administrators) can understand them. For example, a rule can be added when a rule to be prioritized such as that a certain query is to be executed on a specific server is known in advance. It is also possible to make settings so that a specific rule is preferentially selected by deleting unnecessary rules or editing compatibility values.
[0098]
When an inquiry is received from the client 100 (step 603), scheduling is performed (step 604), and the inquiry is input to the replica 104. At that time, the number of times the rule is applied is recorded in the number-of-rules section 1913, 1933 (see FIG. 10) of the rule list for each rule. Then, it is determined whether or not a certain time has elapsed and whether a request from the management server 105 is detected (step 605). Scheduling (step 604) is repeated until the condition of step 605 is met.
[0099]
At the timing when the condition of step 605 is satisfied, the rule list 520 (rule and the number of times the rule is applied) is transmitted to the management server.
[0100]
FIG. 14 is a flowchart showing scheduling (step 604) according to the first embodiment of this invention.
[0101]
Here, the “number of inputs” is prepared as a variable for recording the number of inquiries executed for each replica. By recording the number of queries entered for each replica 104 and controlling the number of queries not to exceed a predetermined threshold, it is possible to prevent queries from being concentrated on a specific replica 104. is there.
[0102]
Also, a “server list” is prepared as a set of replicas that can be inquired. When the number of inputs to a certain replica 104 exceeds the threshold, the replica is excluded from the server list, and the selection of the server is prevented in the subsequent processing.
[0103]
Furthermore, a “previous query” is prepared as a variable for recording a query executed immediately before each replica.
[0104]
In scheduling, first, initialization processing is performed. The number of inputs of each replica is initialized to 0, and a server list including all replicas is constructed (step 1300). Then, the “immediate query” for all replicas is initialized to a blank (step 1320).
[0105]
Subsequently, it is determined whether or not the queue is blank (step 1301). If the queue is empty, the process returns to step 1301 and waits until the queue is not empty. On the other hand, if the queue is not blank, after adding all servers to the server list, the number of inputs is determined for each replica. If the number of inputs exceeds a predetermined threshold (N), inquiries are concentrated on that replica. Therefore, the replica is excluded from the server list (step 1303).
[0106]
Then, an inquiry is taken out from the queue, and matching with rule list 1 and rule list 2 is performed (step 1304). For example, when the retrieved query is Qi, matching is performed with a rule of the form {Qi, *} (* is arbitrary).
[0107]
When the rule list 2 is used, a rule relating to a replica that matches or is not compatible with Qi is extracted by matching a rule whose * part is a replica name (Sj).
[0108]
If rule list 1 is used, matching is required for every replica that can be entered. First, a query (Qj) input immediately before a certain replica (R1) is examined by examining a “previous query” variable, and a rule relating to {Qi, Qj} exists in the rule list 1 of the replica (R1). Search whether or not. If there is a matching rule and the compatibility value is positive, Qi should be input to the replica (R1) because Qi and Qj have good compatibility with respect to the replica (R1). If no query has been executed on the replica and there is no previous query, matching using the rule list 1 is not performed.
[0109]
Next, it is determined whether or not a rule having a positive compatibility has been matched (step 1305). If there is a rule having a positive compatibility, the process proceeds to step 1306. If there is no rule having a positive compatibility, the process proceeds to step 1308.
[0110]
If there is a rule having a positive compatibility in step 1305, one rule is selected from a plurality of rules, and an inquiry is input to the replica indicated by the rule. At the time of selection, the rule having the largest compatibility value is selected (step 1306). Note that, instead of the rule having the largest compatibility value, a replica may be determined by randomly selecting a rule from among the selected rules and inputting an inquiry.
[0111]
Then, the input number is updated (added 1) to the input replica, and the number of applied rules is updated (added 1) (step 1307). Then, an inquiry designated by the rule is set as the “immediate query” of the replica (step 1326), and the process returns to step 1301.
[0112]
On the other hand, if there is no rule having a positive compatibility in step 1305, it is determined whether there is a rule having a negative compatibility (condition 1308). If there is a rule with negative compatibility, the process proceeds to step 1309, and if there is no rule with negative compatibility, the process proceeds to step 1311.
[0113]
If there is a rule with negative affinity in step 1308, a server list is created by excluding the replica indicated by the rule with negative affinity from the replica included in the server list. Then, a replica is selected stochastically (randomly) from the created server list, and an inquiry is input (step 1309). Subsequently, the input number is updated (added 1) to the input replica, and the number of applied rules is updated (added 1) (step 1310). Then, an inquiry indicated by the rule is set as the “immediate query” of the replica (step 1323), and the process returns to the condition 1301.
[0114]
On the other hand, if there is no negative rule in step 1308, a server is selected probabilistically (randomly) from the server list and an inquiry is entered. Subsequently, the input number is updated (added 1) to the input replica, and the number of applied rules is updated (added 1) (step 1312). Then, an inquiry indicated by the rule is set as the “immediate query” of the replica (step 1322), and the process returns to the condition 1301.
[0115]
As described above, in the first embodiment, in the database system including a plurality of replicas 104 that execute queries and the front end 102 that distributes and inputs queries to the replicas 104, queues 131 and A scheduler 130 is provided to determine compatibility between inquiries or between the inquiry and the replica 104, and the scheduler 130 puts in a combination that is compatible and inputs the inquiry to the replica 104. The scheduler 130 functions based on the rules and performs scheduling so as to avoid resource contention, thereby avoiding resource contention and improving the performance (throughput) of the entire system.
[0116]
In addition, the management server 105 collects the execution log of the replica 104 and statistically analyzes the collected execution log, thereby calculating the compatibility between the queries or between the query and the replica. Based on the calculated compatibility, a rule is generated and transmitted to the front end 102. Since the rule is calculated using the execution log, it is possible to learn autonomously even when the system configuration, the content and frequency of the inquiry change, and low-cost operation is possible.
[0117]
Since compatibility is ruled in a form that can be understood by humans, rules can be edited, added, and deleted, and human intentions can be reflected in autonomous learning.
[0118]
Next, a second embodiment of the present invention will be described. In the second embodiment, determination based on compatibility between users in addition to compatibility between queries and between queries and servers in the first embodiment. You can also In this case, compatibility matrixes 2100 and 2101 between users are used in addition to the compatibility matrix 800 between queries.
[0119]
FIG. 15 is a diagram for explaining a compatibility matrix between users used for compatibility calculation in the second embodiment of the present invention.
[0120]
Cij (2103) of the compatibility matrix 2100 is the compatibility between user i (Ui: 2101) and user j (Uj: 2102), and Ui (when executed simultaneously with an arbitrary query entered by Uj (2102). 2101) represents a total value of processing times of arbitrary inquiries input. Ai (2104) represents the total value of the processing times of all inquiries entered by Ui (2101) regardless of Uj.
[0121]
The call matrix 2110 represents how many queries were used to calculate the affinity. For example, Tij (2113) represents how many queries were used to calculate Cij (2103). That is, it is the number of times that the query entered by Ui (2101) is executed simultaneously with the query entered by Uj (2102) in the log. Ti (2114) represents the number of queries used to calculate Ai (2104) (the number of times Ui (2101) executed a query).
[0122]
The compatibility between users is calculated in the same manner as the compatibility of the inquiry, a rule is generated, and the rule is stored in the rule list 3 (2130). In the rule list 3 (2130), a rule is composed of a user set 2131, a compatibility value 2131, and the number of times 2134.
[0123]
FIG. 16 is a flowchart illustrating scheduling (step 604) in consideration of compatibility between users according to the second embodiment of this invention. The scheduling process shown in FIG. 16 differs from the scheduling process shown in FIG. 14 in steps 2200, 2201, 2202, 2202, 2203, and 2204.
[0124]
Here, “the number of inputs” is recorded as a variable for recording the number of inquiries executed for each replica, “server list” is recorded as a set of replicas to which inquiries can be input, and the most recently executed query is recorded for each replica. Prepare “previous query” as a variable. Furthermore, “immediate user” that is a variable for recording the user who executed the inquiry is prepared.
[0125]
In scheduling, first, initialization processing is performed. The number of inputs of each replica is initialized to 0, and a server list including all replicas is constructed (step 1300). Then, “immediate query” and “immediate user” of all replicas are initialized to blanks (step 2200).
[0126]
Subsequently, it is determined whether or not the queue is blank (step 1301). If the queue is empty, the process returns to step 1301 and waits until the queue is not empty. On the other hand, if the queue is not blank, after adding all servers to the server list, the number of inputs is determined for each replica. If the number of inputs exceeds a predetermined threshold (N), inquiries are concentrated on that replica. Therefore, the replica is excluded from the server list (step 1303).
[0127]
Then, an inquiry is taken out from the queue, and matching with rule list 1 and rule list 2 is performed (step 1304). For example, matching is performed for a user (referred to as Ui) who has input an inquiry taken out from the queue. In this matching, it is checked whether or not there is a rule whose condition part is {Ui, “immediate user”} in the rule list 3 for each replica. That is, it is determined whether there is a user who inputs a query having a good compatibility with a query input by the user (Ui) or a user who inputs a query having a poor compatibility.
[0128]
Next, it is determined whether or not a rule having a positive compatibility has been matched (step 1305). If there is a rule having a positive compatibility, the process proceeds to step 1306. If there is no rule having a positive compatibility, the process proceeds to step 1308.
[0129]
If there is a rule having a positive compatibility in step 1305, one rule is selected from a plurality of rules, and an inquiry is input to the replica indicated by the rule. At the time of selection, the rule having the largest compatibility value is selected (step 1306). Note that, instead of the rule having the largest compatibility value, a replica may be determined by randomly selecting a rule from among the selected rules and inputting an inquiry.
[0130]
Then, the input number is updated (added 1) to the input replica, and the number of applied rules is updated (added 1) (step 1307). Then, an inquiry indicated by the rule is set as the “immediate query” of the replica, the user who entered the inquiry is set as the “immediate user” (step 2204), and the process returns to step 1301.
[0131]
On the other hand, if there is no rule having a positive compatibility in step 1305, it is determined whether there is a rule having a negative compatibility (condition 1308). If there is a rule with negative compatibility, the process proceeds to step 1309, and if there is no rule with negative compatibility, the process proceeds to step 1311.
[0132]
If there is a rule with negative affinity in step 1308, a server list is created by excluding the replica indicated by the rule with negative affinity from the replica included in the server list. Then, a replica is selected stochastically (randomly) from the created server list, and an inquiry is input (step 1309). Subsequently, the input number is updated (added 1) to the input replica, and the number of applied rules is updated (added 1) (step 1310). Then, an inquiry indicated by the rule is set as the “immediate query” of the replica, the user who entered the inquiry is set as the “immediate user” (step 2203), and the process returns to step 1301.
[0133]
On the other hand, if there is no negative rule in step 1308, a server is selected probabilistically (randomly) from the server list and an inquiry is entered. Subsequently, the input number is updated (added 1) to the input replica, and the number of applied rules is updated (added 1) (step 1312). Then, an inquiry indicated by the rule is set as the “immediate query” of the replica, the user who entered the inquiry is set as the “immediate user” (step 2202), and the process returns to step 1301.
[0134]
As described above, in the second embodiment, in a database system including a plurality of replicas 104 that execute queries and the front end 102 that distributes and inputs queries to the replicas 104, queues 131 and A scheduler 130 is provided to determine compatibility between users who input an inquiry, or compatibility between a user who inputs an inquiry and the replica 104, and the scheduler 130 inputs a combination having a good compatibility and inputs an inquiry to the replica 104. The scheduler 130 functions based on the rules and performs scheduling so as to avoid resource contention, thereby avoiding resource contention and improving the performance (throughput) of the entire system.
[0135]
Next, a third embodiment of the present invention will be described. In the third embodiment, an external server is connected to the management server via a network, and the management server can be accessed from the external server. Can be monitored and managed from the outside.
[0136]
FIG. 17 is a configuration diagram of the database system according to the third embodiment of this invention.
[0137]
The management server 105 is connected to a network 1601 (intranet or Internet). The management server 105 is connected 1600 to an MSP (Management Service Provider) monitoring / analysis server that undertakes management via a network 1601. Rules and performance data are stored in the rule database 140 of the management server 105, and the monitoring / analysis server 1600 analyzes them, thereby enabling remote maintenance from outside and system diagnosis.
[0138]
The monitoring / analysis server 1600 includes a performance information management unit 1602 and an analysis report generation unit 1602. The performance information management unit 1602 acquires rules, rule application counts, resource usage rates for each replica, and the like as rule / performance information 1610 from the management server 105. The obtained rule / performance information 1610 is stored in the rule / performance information database 1620. The rule / performance information database 1620 manages information in time series. The analysis report generation unit 1603 generates an analysis report 1612 based on the performance information.
[0139]
The monitoring / analysis server 1600 performs remote maintenance 1613 of the management server 105.
[0140]
The manager or operator of the information system pays the service fee and the maintenance fee 1611 to the MSP as consideration for the monitoring analysis. The manager or operator of the information system can outsource database management (or part of it).
[0141]
FIG. 18 is a flowchart of processing between the monitoring / analysis server 1600 and the management server 105 according to the third embodiment of this invention. In the figure, the left side is the process of the monitoring / analysis server 1600, and the right side is the process of the management server 105.
[0142]
The monitoring / analysis server 1600 transmits an access request to the management server 105 (step 1400).
[0143]
The management server 105 accepts access from the monitoring / analysis server 1600 and performs authentication (step 1410). If the authentication is successful (step 1411), the rule / performance information recorded in the rule database 140 is transmitted (step 1412).
[0144]
The monitoring / analysis server 1600 that has accepted the request (1400) acquires the rule / performance information 1610 (step 1401). The acquired rule / performance information 1610 is stored in the rule / performance information database 1620.
[0145]
Then, the performance information stored in the rule / performance information database 1620 is subjected to time series analysis by a method described later to generate an analysis report (step 1402). Finally, the generated analysis report is transmitted by mail (step 1403). The generated analysis report is stored in a web server (not shown) that can be accessed via the network by the monitoring / analysis server 1600 (or the management server 105), and the management server 105 indicates that the analysis report has been created. You may be notified.
[0146]
The management server 105 receives the analysis report (step 1413).
[0147]
Thereafter, the monitoring / analysis server 1600 determines whether there is a problem with the rule (for example, a decrease in throughput due to a problem with a specific rule) (step 1404). Then, the rule in question is edited (step 1405). For example, the rule application is controlled by deleting the problematic rule or changing the compatibility value of the rule, thereby improving the throughput. Then, the edited rule is transmitted to the management server 105 (step 1406) to maintain the rule.
[0148]
The management server 105 accepts the rule transmitted from the monitoring / analysis server 1600 and stores it in the rule database 140 (step 1414). Then, the rule is transmitted to the front end 102 (step 1415), and scheduling with the new rule is instructed.
[0149]
FIG. 19 is a diagram illustrating data files managed in the performance information database 1620 by the monitoring / analysis server 1600 according to the third embodiment of this invention.
[0150]
The data file 2005 is composed of rules 2000 and 2001 and performance information 2002. A rule is composed of a rule list 1 (2000) and a rule list 2 (2001). There are as many rule lists 1 (2000) and performance information (2002) as there are replicas 104, respectively.
[0151]
The data file 2005 is newly generated every time the rule is changed and is managed as time series data.
[0152]
FIG. 20 is a diagram illustrating an example of an analysis report display screen according to the third embodiment of this invention.
[0153]
As the analysis report 1500, a throughput display 1501, a rule display 1502, and a performance display 1503 are displayed.
[0154]
As the throughput display 1501, a graph of the performance of the entire system is displayed. For example, the inquiry processing amount per unit time is displayed. Through the throughput display 1501, it is possible to grasp a time series change in the performance of the entire system. It is also possible to predict future throughput by extrapolating the graph.
[0155]
In the rule display 1502, for example, information on rules used for scheduling in the front end at a certain time is displayed. The period (time) for analyzing the rule may be directly input by the user or may be specified on the throughput screen 1501. In the rule display 1502, the condition part of the rule, the compatibility value, and the number of applications are displayed. In the rule display 1502, what is displayed in the rule condition part is the ID attached to the query and not the content of the query. Therefore, a rule detail display 1510 is provided separately to display the actual rule content. The rule display 1504 makes it possible to grasp what rules are generated and how many times each is applied.
[0156]
It is also possible to know time-series changes in applied rules. For example, since the rules are learned and change, when the throughput is reduced, it is possible to investigate the cause of the throughput reduction by checking whether the applied rule is changed. If there is a problem with a particular rule, maintenance is performed by editing the rule. For example, by deleting the rule or changing the compatibility value of the rule, the application of the rule can be controlled to improve the throughput.
[0157]
The performance screen 1503 displays information on performance resources such as a CPU usage rate and a disk usage rate for each replica in a graph. From the performance screen, it is possible to grasp the load for each replica and the load balance between replicas. If the bottleneck for each replica is known from this performance screen, it is possible to make a capital investment proposal to avoid the bottleneck. For example, if the memory usage rate is high, it is possible to propose a memory expansion.
[0158]
FIG. 21 is a diagram for explaining the outline of the business model of the monitoring and management service according to the third embodiment.
[0159]
A system administrator or manager of an IT system 1800, such as a database system (eg, FIG. 1), contracts with an external MSP 1801 to outsource management.
[0160]
The IT system 1800 transmits rule / performance information 1802 to the MSP 1801. This rule / performance information 1802 includes rules generated autonomously in the IT system 1800 in addition to performance information such as server resource usage.
[0161]
The MSP 1801 performs rule monitoring / analysis in addition to performance information monitoring / analysis such as resource usage rate that has been conventionally performed. The MSP 1801 receives the rule / performance information 1802, performs an analysis, summarizes the analysis result in a report 1803, and provides it to the IT system 1800. The MSP 1801 performs remote maintenance 1805. Here, in addition to changing the setting parameters of the conventional software, the rules are edited. The rule is described by abstracting a plurality of data (for example, in an if-then format), and is easy to understand by humans because of its high readability, so it can be edited by the administrator of the MSP 1801.
[0162]
In addition, after the diagnosis by the MSP 1801, it is possible to propose a change of hardware such as the replica 104. By managing the rule / performance information 1802 in chronological order and grasping changes in the system, it is possible to take measures before a performance problem occurs.
[0163]
The administrator or manager of the IT system 1800 pays the consideration 1804 to the MSP 1801 for maintenance and service.
[0164]
More specifically, MSP 1801 periodically executes analysis report 1803. The administrator or manager of the IT system 1800 as a user pays a support / maintenance fee to the MSP 1801 as the consideration.
[0165]
As described above, in the third embodiment, since the management server 105 is monitored and managed by the external monitoring / analysis server 1600, the behavior of the system can be grasped by handling the abstract rules. Since it is easy and maintenance by changing rules is easy, it is possible to provide high value-added services.
[Brief description of the drawings]
FIG. 1 is a configuration diagram of a database system according to a first embodiment of this invention.
FIG. 2 is a flowchart of processing of the replica 104 according to the first embodiment of this invention.
FIG. 3 is a configuration diagram of log data recorded by the replica 104 according to the first embodiment of this invention.
FIG. 4 is a flowchart of processing of the management server 105 according to the first embodiment of this invention.
FIG. 5 is an explanatory diagram of inquiry grouping according to the first embodiment of this invention;
FIG. 6 is an explanatory diagram of an inquiry execution state according to the first embodiment of this invention;
FIG. 7 is an explanatory diagram of a compatibility matrix used for compatibility calculation in the first embodiment of the present invention.
FIG. 8 is a flowchart of compatibility calculation (step 502) according to the first embodiment of this invention;
FIG. 9 is a flowchart of rule generation (step 503) between queries according to the first embodiment of this invention;
FIG. 10 is a configuration diagram of a rule list according to the first embodiment of this invention.
FIG. 11 is an explanatory diagram of another compatibility matrix used for compatibility calculation in the first embodiment of the present invention.
FIG. 12 is an explanatory diagram of a data file managed in the rule database 140 by the management server 105 according to the first embodiment of this invention.
FIG. 13 is a flowchart of processing of the front end according to the first embodiment of this invention.
FIG. 14 is a flowchart of scheduling (step 604) according to the first embodiment of this invention;
FIG. 15 is an explanatory diagram of a compatibility matrix between users used for compatibility calculation in the second embodiment of the present invention;
FIG. 16 is a flowchart of scheduling (step 604) according to the second embodiment of this invention;
FIG. 17 is a configuration diagram of a database system according to a third embodiment of this invention.
FIG. 18 is a flowchart of processing between the monitoring / analysis server 1600 and the management server 105 according to the third embodiment of this invention;
FIG. 19 is an explanatory diagram of a data file managed by the monitoring / analysis server 1600 according to the third embodiment of this invention in the performance information database 1620;
FIG. 20 is a diagram illustrating an example of an analysis report display screen according to the third embodiment of this invention.
FIG. 21 is a schematic diagram of a business model of a monitoring and management service.
FIG. 22 is a configuration diagram of a conventional database system.
FIG. 23 is an explanatory diagram of the operation of a database buffer in a conventional database system.
FIG. 24 is an explanatory diagram of the operation of a database buffer in a conventional database system.
[Explanation of symbols]
100 clients
101 network
102 Database server (front end)
103 Database server (master)
104 Database server (replica)
105 Management server
106 Master disk
107 replica disk
110 Log recording / transmission unit
111 Inquiry execution unit
120 Log acquisition unit
121 compatibility calculator
122 Rule generator
123 Rule Management Department
140 rule database
200 servers
201 disks
203 memory
1600 Monitoring / analysis server
1601 network
1602 Performance Information Management Department
1603 Analysis report generator

Claims (17)

A plurality of database servers having databases capable of searching the same content, and searching the databases according to an inquiry request;
A front-end server that accepts the inquiry request and inputs an inquiry to the database server using a predetermined rule;
A management server for managing rules used by the front-end server;
A network system connecting each of the servers and a client terminal that requests an inquiry,
The management server
Log acquisition means for acquiring an execution log of the database server;
Rule generation means for generating the rule based on compatibility with the query calculated using the acquired log,
The database system according to claim 1, wherein the front-end server has inquiry input means for inputting the inquiry using a rule generated by the management server. A server that manages rules used by a front-end server that inputs a query according to a query request using a predetermined rule for a plurality of database servers that search a database capable of searching the same content,
Log acquisition means for acquiring an execution log of the database server;
Rule generation means for generating the rule based on compatibility with the query calculated using the acquired log;
A server having rule transmitting means for transmitting the generated rule to the front-end server in order to cause the front-end server to input the inquiry using the generated rule.   The server according to claim 2, wherein the rule generation unit generates a rule by calculating compatibility between the queries by statistically processing the queries included in the acquired log. The rule generation means groups the queries included in the execution log of the database server,
The average processing time for grouped queries,
Based on the result of comparing the grouped query and the average processing time of the grouped query when the grouped query and other grouped queries are executed in a predetermined time relationship,
The server according to claim 3, wherein a compatibility is calculated between the queries and a rule is generated. The rule generation means includes:
Based on the result of comparing the processing time of the query recorded in the execution log for each database between the databases,
The server according to claim 2, wherein a rule is generated by calculating compatibility between the inquiry and the database. The rule generation means includes:
The average processing time for queries run by a user,
Based on the comparison result of the average processing time of the query submitted by the user when the query executed by the user and the query executed by another user are executed in a predetermined time relationship,
The server according to claim 2, wherein compatibility is calculated between users who issue inquiries, and rules are generated.   The server according to claim 2, further comprising a rule changing unit that changes the rule generated by the rule generating unit. Having external access means for allowing access from outside via the network;
The server according to claim 7, wherein the rule is changed by the rule changing unit via the external access unit. The log acquisition unit acquires an execution log related to an inquiry input based on the rule transmitted by the rule transmission unit,
The rule generation means generates the rule based on compatibility with the query calculated using the acquired log,
The server according to claim 2, wherein the server learns rules autonomously. A plurality of database servers having databases capable of searching the same content, and searching the databases according to an inquiry request;
A front-end server that accepts the inquiry request and inputs an inquiry to the database server using a predetermined rule;
In a query input method used in a database system comprising a management server for managing rules used by the front-end server,
The management server
Acquire the execution log of the database server,
Generating the rule based on affinity for the query calculated using the acquired log;
The front-end server is
An inquiry input method, wherein the inquiry is input using a rule generated by the management server.   11. The inquiry input method according to claim 10, wherein a rule is generated by calculating a compatibility between the inquiries by statistically processing an inquiry included in the acquired log. Grouping the queries included in the execution log of the database server,
An average processing time for the grouped queries;
Based on the result of comparing the grouped query and the average processing time of the grouped query when the grouped query and other grouped queries are executed in a predetermined time relationship,
The inquiry input method according to claim 11, wherein the compatibility between the inquiries is calculated.   The query input method according to claim 10, wherein a rule is generated by calculating compatibility between the query and the database server by statistically processing the query included in the acquired log. .   The query according to claim 10, wherein the query included in the acquired log is statistically processed to calculate a compatibility between users who issue the query and generate a rule. Input method.   11. The inquiry input method according to claim 10, wherein when determining a database server to which the inquiry is input, a database server most compatible with the inquiry is selected. When determining the database server to which the query is to be submitted,
If there is no database server compatible with the inquiry,
After excluding the database server server that is incompatible with the query from the database servers that can input the query,
11. The inquiry input method according to claim 10, wherein a database server to which the inquiry is input is selected stochastically. When determining the database server to which the query is to be submitted,
11. The inquiry input method according to claim 10, wherein the inquiry is selected by selecting a database server in which an inquiry having compatibility with the inquiry is executed immediately before.

Images