A pre-decisional metadatabase design method and system

Abstract

The application provides a pre-decision quasistate database design method and system, comprising the following steps: each executor generates an SQL statement based on a received external user request; a pre-decision maker makes a decision on the SQL statement sent by each executor, sends the decided SQL statement to a post-decision maker, sends the decision result to a dispatcher, and notifies the normal execution body to send the SQL statement to the corresponding sub-database; the sub-database generates a response result in response to the SQL statement, and sends the response result to the post-decision maker when the SQL statement is an addition statement, a deletion statement or an update statement; the post-decision maker compares the received response result with record data, and obtains difference data of the sub-database; the difference data of each sub-database is decided, the record data is updated according to the decision result, and the record data is forwarded to the dispatcher, so that the dispatcher synchronously updates the sub-database corresponding to the abnormal execution body pre-decided and the abnormal sub-database decided by the post-decision maker based on the record data.

Description

TECHNICAL FIELD

[0001] The present application relates to a mimic system, in particular, to a pre-decision mimic database design method and system. BACKGROUND

[0002] The mimic defense technology changes the game rules of network space defense, and provides a new solution for network security of network application. At present, the mimic defense technology has been successfully applied in network equipment and network application. The current business application is often closely connected with the database, and when the business system is mimicked, the problem of database mimic must be solved. At present, the database mimic is often labeled at the database call of the business program, and then the labeled database protocol packet is parsed through the database agent, the label is used for decision, the label is removed from the database protocol after the decision is completed, and then the database protocol packet is transmitted to the backend database. This method needs to parse the database protocol, and since there are many types of databases on the market at present, and each type of database protocol is different, this method lacks universality.

[0003] In order to solve the above problems, people have been seeking an ideal technical solution. SUMMARY

[0004] The present application aims at the deficiencies of the prior art, and provides a pre-decision mimic database design method and system.

[0005] In order to achieve the above purpose, the technical scheme adopted by the present application is as follows: a pre-decision mimic database design method, comprising the following steps:

[0006] Each execution body generates an SQL statement based on the received external user request;

[0007] The pre-decision device decides the SQL statement sent by each execution body, and sends the decided SQL statement to the post-decision device, and sends the decision result to the dispatcher, so that the dispatcher cleans and recovers the execution body with abnormal decision, and notifies the execution body with normal decision to send the SQL statement to the corresponding sub-database;

[0008] The sub-database generates a response result in response to the SQL statement, returns the response result to the corresponding execution body when the SQL statement is a query statement, and sends the response result to the post-decision device when the SQL statement is an increase statement, a delete statement or an update statement, and returns an operation success message to the corresponding execution body;

[0009] The post-arbiter compares the received response result with the record data to obtain difference data of the sub-databases, arbitrates the difference data of each sub-database, updates the record data according to the arbitration result, and forwards the record data to the dispatcher for synchronously updating the sub-databases corresponding to the pre-arbitrated abnormal execution bodies and the abnormal sub-databases arbitrated by the post-arbiter based on the record data.

[0010] Based on the above, after each execution body generates an SQL statement, the execution body identifier, the external user request identifier and the SQL statement are encapsulated into an SQL request message;

[0011] The pre-arbiter arbitrates the SQL request messages from the same external user request through the external user request identifier.

[0012] After the sub-database receives the SQL request message, the sub-database responds to the SQL statement in the SQL request message and encapsulates the execution body identifier, the external user request identifier and the response result into a response message and sends the response message to the post-arbiter.

[0013] The post-arbiter arbitrates a group of difference data from the same external user request through the external user request identifier.

[0014] Based on the above, the post-arbiter is preset with record data, and the initial obtaining step of the record data is:

[0015] In the initial case, data is read from each sub-database respectively, and the read data is grouped according to a preset grouping rule.

[0016] The data in each group in each sub-database is arbitrated, a group of data arbitrated normally is selected as record data of the group and stored, and the record data is sent to the dispatcher so that the dispatcher updates the arbitrated abnormal sub-databases based on the record data.

[0017] Based on the above, the pre-arbiter sends the SQL statement, the number of execution bodies arbitrated normally and the execution body identifiers of the execution bodies arbitrated normally to the post-arbiter after arbitration.

[0018] After the post-arbiter receives the response message, the external user request identifier and the execution body identifier are extracted from the response message, the number of response messages belonging to the same external user request identifier is accumulated within a preset time, and the received execution body identifiers are recorded; if the number of response messages is greater than or equal to half of the number of execution bodies arbitrated normally, a group of difference data from the same external user request is arbitrated, and when the arbitration is successful, the abnormal sub-databases are determined according to the recorded execution body identifiers and the execution body identifiers sent by the pre-arbiter, and the abnormal sub-databases are synchronously updated based on the record data.

[0019] The application also provides a pre-decision quasistate database, comprising

[0020] An SQL generation module is embedded in each executor and is configured to generate an SQL statement based on a received external user request;

[0021] A pre-decider is configured to make a decision on the SQL statement sent by each executor to the pre-decider, send the decided SQL statement to a post-decider, and send the decision result to the dispatcher, so that the dispatcher cleans up and recovers the execution body with a decision exception and informs the execution body with a normal decision to send the SQL statement to the corresponding sub-database;

[0022] A plurality of sub-databases are each configured to be connected with an execution body, receive and respond to the SQL statement sent by the corresponding execution body, return the response result to the corresponding execution body when the SQL statement is a query statement, send the response result to the post-decider when the SQL statement is an addition statement, a deletion statement or an update statement, and return an operation success message to the corresponding execution body;

[0023] The post-decider is configured to compare the received response result with the record data, obtain the difference data of the sub-database, make a decision on the difference data of each sub-database, update the record data according to the decision result, and forward the record data to the dispatcher, so that the dispatcher synchronously updates the sub-database corresponding to the execution body with a pre-decision exception and the sub-database with a decision exception made by the post-decider based on the record data.

[0024] The application also provides a quasistate system, comprising an input agent, an execution body, a dispatcher and the quasistate database.

[0025] The application has outstanding substantial features and significant progress compared with the prior art, specifically, the SQL statement generation module is introduced in the execution body to generate the SQL statement, the pre-decision module makes a pre-decision first, and after the pre-decision is successful, the execution body is informed to issue the SQL statement to the sub-database, the whole interaction process is based on the standard SQL statement, and the SQL protocol does not need to be processed, so that the generality in the implementation process of the quasistate database is improved; meanwhile, each execution body separately occupies one sub-database, and the sub-databases are independent of each other; the threat is further identified by judging whether the contents of the sub-databases are consistent.

[0026] The post-decider of the application does not make a decision on the database query result, but makes a decision on the database modification result such as addition, deletion and update by using a decision algorithm to combine and select one modification result, and uses the modification result to keep all the sub-databases synchronized. BRIEF DESCRIPTION OF DRAWINGS

[0027] Figure 1is a structural schematic diagram of the present application. DETAILED DESCRIPTION

[0028] The technical solutions of the present application are described in further detail below through a specific embodiment.

[0029] Embodiment 1

[0030] The present embodiment provides a pre-decision type mimic database design method, as shown in the following steps: Figure 1

[0031] Each executor generates a SQL statement based on the received external user request;

[0032] The pre-decider makes a decision on the SQL statement sent by each executor and sends the decided SQL statement to the post-decider, while sending the decision result to the dispatcher, so that the dispatcher cleans and recovers the executor with a decision exception and notifies the executor with a normal decision to send the SQL statement to the corresponding sub-database;

[0033] The sub-database generates a response result in response to the SQL statement, returns the response result to the corresponding executor when the SQL statement is a query statement, and sends the response result to the post-decider and returns an operation success message to the corresponding executor when the SQL statement is an addition statement, a deletion statement or an update statement;

[0034] The post-decider compares the received response result with the record data to obtain the difference data of the sub-database, makes a decision on the difference data of each sub-database, updates the record data according to the decision result, and forwards the record data to the dispatcher for synchronously updating the sub-database corresponding to the pre-decided exception executor and the sub-database decided by the post-decider

[0035] The present application introduces a sql statement generation module in the executor to generate a sql statement, so that the pre-decision module makes a pre-decision first, and then notifies the executor to issue the sql statement to the sub-database after the pre-decision is successful. The entire interaction process is based on a standard sql statement, without the need to process the sql protocol, improving the generality in the implementation process of the mimic database. Meanwhile, each executor occupies one sub-database independently, and the sub-databases are independent of each other. By determining whether the contents of each sub-database are consistent, the threat is further identified.

[0036] The post-decider of the present application does not make a voting process on the database query result, but adopts a voting algorithm to combine the modification results of addition, deletion and update to select one modification result, and uses the modification result to keep all sub-databases synchronized.

[0037] ​Further, each executor generates a SQL statement, and encapsulates the executor identifier, the external user request identifier and the SQL statement into a SQL request message;

[0038] The pre-decider identifies the SQL request messages from the same external user request through the external user request identifier, and makes a decision;

[0039] The sub-database receives the SQL request message, responds to the SQL statement in the SQL request message, encapsulates the executor identifier, the external user request identifier and the response result into a response message, and sends the response message to the post-decider or the corresponding executor;

[0040] The post-decider identifies a set of difference data from the same external user request through the external user request identifier, and makes a decision.

[0041] Through the identifier, the post-decider and the pre-decider can identify a set of encapsulated SQL instructions or response messages from the same external user request.

[0042] In the specific implementation, the post-decider is pre-stored with record data, and the initial acquisition step of the record data is as follows:

[0043] In the initial case, for example, when the system is just running and the executor does not write data to the database, data is read from each sub-database, and the read data is grouped according to the preset grouping rule;

[0044] The data in each group of the sub-database is decided, and a set of data from the normal data is selected as the record data of the group and is stored, and the record data is sent to the dispatcher, so that the dispatcher updates the abnormal sub-database based on the record data.

[0045] Specifically, the data in the database is often in the form of a table structure, and since the executors have the same business, the databases at the backends of all the executors have the same number, type and structure of tables.

[0046] Suppose there are 3 sub-databases, and each sub-database has 3 tables (A1, B1, C1), and each table has 100 data; the data read from sub-database A is marked as {A-A1-data0, A-A1-data1,..., A-A1-data100}, {A-B1-data0, A-B1-data1,..., A-B1-data100}, {A-C1-data0, A-C1-data1,..., A-C1-data100}; the data read from sub-database B is marked as {B-A1-data0, B-A1-data1,..., B-A1-data100}, {B-B1-data0, B-B1-data1,..., B-B1-data100}, {B-C1-data0, B-C1-data1,..., B-C1-data100}; the data read from sub-database C is marked as {C-A1-data0, C-A1-data1,..., C-A1-data100}, {C-B1-data0, C-B1-data1,..., C-B1-data100}, {C-C1-data0, C-C1-data1,..., C-C1-data100}.

[0047] After reading the data from each sub-database, the obtained data is grouped; for example, for table A1, grouping is performed according to a specific step N, for example, grouping is performed with N=10; table A1 has 100 data, and after grouping according to the step 10, it is divided into 10 groups, each group has 10 data; after grouping, table A1 in sub-database A is marked as A-G0{N, A-A1-data0, A-A1-data1,..., A-A1-data9},..., A-G9{N, A-A1-data0, A-A1-data1,..., A-A1-data9}; after grouping, table A1 in sub-database B is marked as B-G0{N, B-A1-data0, B-A1-data1,..., B-A1-data9},..., B-G9{N, B-A1-data0, B-A1-data1,..., B-A1-data9}; after grouping, table A1 in sub-database C is marked as C-G0{N, C-A1-data0, C-A1-data1,..., C-A1-data9},..., C-G9{N, C-A1-data0, C-A1-data1,..., C-A1-data9}; N in the grouping represents the number of elements in this grouping.

[0048] After grouping, the data in {A-G0, A-G1, …, A-G9}, {B-G0, B-G1, …, B-G9}, {C-G0, C-G1, …, C-G9} is compared, A-G0, B-G0, C-G0 are compared, and so on; one group of data is selected from the normal data as the record data of the group and stored, for example, record A-G0, A-G1, …, A-G9.

[0049] If the result of A-G1 is inconsistent with one of B-G1 and C-G1, the inconsistent data item is A-G1-data1, the data of B-G1 is recorded, and the arbitration information is sent to the dispatcher for processing; the arbitration information sent includes the abnormal data item A-G1-data1 and the normal data item B-G1-data1; after receiving the arbitration information, the dispatcher replaces the A-G1-data1 item in the sub-database A with B-G1-data1; thus, the consistency of the data in the initial state of each sub-database is ensured.

[0050] Embodiment 2

[0051] The difference between this embodiment and embodiment 1 is that:

[0052] After the arbitration, the pre-arbitrator sends the SQL statement, the number of execution bodies that pass the arbitration, and the execution body identifier of the execution body that passes the arbitration to the post-arbitrator;

[0053] After receiving the response message, the post-arbitrator extracts the external user request identifier and the execution body identifier from the response message, accumulates the number of response messages belonging to the same external user request identifier within a preset time, and records the received execution body identifier; if the number of response messages is greater than or equal to half of the number of execution bodies that pass the arbitration, a group of different data belonging to the same external user request is arbitrated, and when the arbitration is successful, the abnormal sub-database is determined according to the recorded execution body identifier and the execution body identifier sent by the pre-arbitrator, and the abnormal sub-database is updated based on the record data.

[0054] Specifically, when the abnormal sub-database is determined according to the recorded execution body identifier and the execution body identifier sent by the pre-arbitrator, the recorded execution body identifier and the execution body identifier of the execution body that passes the arbitration are compared to find the unrecorded execution body identifier, and the corresponding sub-database of the execution body corresponding to the execution body identifier is determined as the abnormal sub-database.

[0055] Embodiment 3

[0056] The difference between this embodiment and embodiment 1 is that:

[0057] When the SQL statement is a delete statement or an update statement, the post-arbitrator reads data from each sub-database in turn and compares the data with the record data to obtain difference data; arbitrates a group of difference data from the same external user request, if the arbitration is successful, subtracts the difference data from the record data to obtain new record data, and synchronizes the new record data to the sub-databases that failed in the post-arbitration through the dispatcher; if the arbitration fails, synchronizes the record data to all sub-databases through the dispatcher.

[0058] The specific steps are as follows: the post-arbitrator first reads data from the sub-database A, then compares the data with the record data, and records the difference data as δ1; then reads data from the sub-database B, compares the data with the record data, and records the difference data as δ2; similarly, the difference data of the sub-database C is δ3; then, δ1, δ2 and δ3 are compared, if they are all equal, the record data is subtracted by the deletion δ1 to obtain new record data. If they are all not equal, the record data is used as a reference, and the data in the three sub-databases is restored. If only two are equal, the equal difference data is used as a reference, the record data is subtracted by the deletion of the equal difference data to obtain new record data. Then the new record data is synchronized to the other sub-database through the dispatcher.

[0059] When the SQL statement is an increase statement, the post-arbitrator obtains the data entries in the record data, and obtains the data outside the data entries from each sub-database in turn, and groups the read data according to the preset grouping rule; arbitrates the data of each group from the same external user request in each sub-database, selects one group of data from the normal data as the record data of the group, and merges the original record data as new record data, and synchronizes the new record data to the sub-database that failed in the post-arbitration through the dispatcher; if the arbitration fails, the record data is synchronized to all sub-databases through the dispatcher.

[0060] For example: the record data has been recorded to G10 group data, when reading data from the sub-database, data after 100 data in the sub-database is read, if 5 data is taken out, the 5 data is grouped separately, A-G11{5, A-A1-data0, …, A-A1-data4}; then compare the data of G11 group of all sub-databases, the process is the same as above.

[0061] Embodiment 4

[0062] The embodiment provides a pre-arbitration pseudo-database, comprising:

[0063] The SQL generation module is embedded in each execution body and is configured to generate a SQL statement based on a received external user request;

[0064] The pre-decider is configured to make a decision on the SQL statements sent by each executor and send the decided SQL statements to the post-decider, and send the decision result to the dispatcher, so that the dispatcher cleans up and recovers the execution body with a decision exception and informs the execution body with a decision normality to send the SQL statement to the corresponding sub-database;

[0065] The plurality of sub-databases are each configured to be connected with an execution body, receive and respond to the SQL statement sent by the corresponding execution body, return the response result to the corresponding execution body when the SQL statement is a query statement, send the response result to the post-decider when the SQL statement is an addition statement, a deletion statement or an update statement, and return an operation success message to the corresponding execution body;

[0066] The post-decider is configured to compare the received response result with the record data to obtain the difference data of the sub-database, make a decision on the difference data of each sub-database, update the record data according to the decision result, and forward the record data to the dispatcher for synchronously updating the sub-database corresponding to the abnormal execution body pre-decided and the abnormal sub-database post-decided by the post-decider based on the record data.

[0067] Specifically, the SQL generation module encapsulates the execution body identifier, the external user request identifier and the SQL statement into a SQL request packet after generating the SQL statement;

[0068] The pre-decider identifies the SQL request packets from the same external user request through the external user request identifier to make a decision;

[0069] The sub-database receives the SQL request packet, responds to the SQL statement in the SQL request packet, and encapsulates the execution body identifier, the external user request identifier and the response result into a response packet and sends the response packet to the post-decider;

[0070] The post-decider identifies a group of difference data from the same external user request through the external user request identifier to make a decision.

[0071] Further, the post-decider further includes a recorder, and the recorder is pre-provisioned with record data, and the initial obtaining step of the record data is:

[0072] In the initial case, data is read from each sub-database respectively, and the read data is grouped according to a preset grouping rule;

[0073] The data in each group of the sub-database is decided, a group of data from the decided normal data is selected as the record data of the group and stored in the recorder, and the record data is sent to the dispatcher, so that the dispatcher updates the abnormal sub-database decided based on the record data.

[0074] Embodiment 5

[0075] The embodiment provides a mimic system, comprising an input agent, an executor, a scheduler and the mimic database in embodiment 4.

[0076] After the input agent receives the external user request, the input agent marks the external user request with an external user request identification ID, and then forwards the external user request with the external user request identification ID to the three executors respectively.

[0077] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present application rather than limit the same; although the present application has been described in detail with reference to the preferred embodiments, it should be understood by those skilled in the art that the specific embodiments of the present application can be modified or some technical features can be replaced by equivalent ones; without departing from the spirit of the technical solutions of the present application, all of them should be covered in the technical solution range of the present application.

Claims

1. A pre-decisional quasipattern database design method characterized by, The method comprises the following steps: Each executor generates an SQL statement based on the received external user request; wherein each executor separately occupies one database, and the sub-databases are independent of each other; The pre-decider makes a decision on the SQL statements sent by each executor, and sends the decided SQL statements to the post-decider, and sends the decision result to the dispatcher, so that the dispatcher cleans and recovers the execution body with a decision exception, and notifies the execution body with a normal decision to send the SQL statement to the corresponding sub-database; The sub-database generates a response result in response to the SQL statement, and returns the response result to the corresponding execution body when the SQL statement is a query statement, and sends the response result to the post-decider and returns an operation success message to the corresponding execution body when the SQL statement is an addition statement, a deletion statement or an update statement; The post-decider compares the received response result with the record data to obtain the difference data of the sub-database; makes a decision on the difference data of each sub-database, updates the record data according to the decision result, and forwards the record data to the dispatcher for synchronously updating the sub-database corresponding to the pre-decided abnormal execution body and the abnormal sub-database decided by the post-decider based on the record data.

2. The pre-decisional quasistate database design method of claim 1, wherein: Each executor encapsulates the execution body identifier, external user request identifier and SQL statement into an SQL request packet after generating the SQL statement; The pre-decider identifies the SQL request packets from the same external user request through the external user request identifier to make a decision; The sub-database receives the SQL request packet, responds to the SQL statement in the SQL request packet, and encapsulates the execution body identifier, external user request identifier and response result into a response packet to send to the post-decider or the corresponding execution body; The post-decider identifies a group of difference data from the same external user request through the external user request identifier to make a decision.

3. The method of claim 1, wherein: The post-decider is pre-provisioned with record data, and the initial acquisition step of the record data is: In the initial state, data is read from each sub-database, and the read data is grouped according to a pre-set grouping rule; The data in each group of each sub-database is decided, and a group of data from the decided normal data is selected as the record data of the group for storage, and the record data is sent to the dispatcher to update the abnormal sub-database decided based on the record data.

4. The pre-decision pseudo-state database design method of claim 2, wherein: After making a decision, the pre-decider sends the SQL statement, the number of execution bodies with a normal decision and the execution body identifier of the execution body with a normal decision to the post-decider; After receiving the response packet, the post-decider extracts the external user request identifier and the execution body identifier from the response packet, accumulates the number of response packets belonging to the same external user request identifier within a pre-set time, and records the received execution body identifier. If the number of response messages is greater than or equal to half of the number of normal execution bodies, a group of difference data belonging to the same external user request is judged, and when the judgment is successful, an abnormal sub-database is determined according to the recorded execution body identifier and the execution body identifier sent by the pre-judger, and the abnormal sub-database is synchronously updated based on the recorded data.

5. The pre-judgment pseudo-state database design method according to claim 2 or 4, wherein: When the SQL statement is a delete statement or an update statement, the post-judger reads data from each sub-database in turn and compares the data with the recorded data to obtain difference data; a group of difference data from the same external user request is judged, and if the judgment is successful, the recorded data is subtracted by the difference data as new recorded data, and the new recorded data is synchronized to the sub-database where the post-judgment fails through the dispatcher; if the judgment fails, the recorded data is synchronized to all sub-databases through the dispatcher.

6. The pre-judgment pseudo-state database design method according to claim 3, wherein: When the SQL statement is an add statement, the post-judger obtains data entries in the recorded data, and obtains data other than the data entries from each sub-database in turn, and groups the read data according to a preset grouping rule; Each group of data from the same external user request in each sub-database is judged, and a group of data from the normal data is selected as the recorded data of the group, and the new recorded data is synchronized to the sub-database where the post-judgment fails through the dispatcher; If the judgment fails, the recorded data is synchronized to all sub-databases through the dispatcher.

7. A data processing apparatus having disposed thereon a pre-decided quasistate database, characterized by: The pre-judgment pseudo-state database comprises a SQL generation module embedded in each execution body and configured to generate a SQL statement based on a received external user request; a pre-judger configured to judge the SQL statement sent by the pre-judger to each execution body, and send the judged SQL statement to the post-judger, and send the judgment result to the dispatcher to clean up and restore the execution body where the judgment is abnormal, and notify the execution body where the judgment is normal to send the SQL statement to the corresponding sub-database; a plurality of sub-databases, each sub-database being configured to be connected with an execution body, the sub-databases being independent of each other, each execution body occupying a sub-database alone, receiving the SQL statement sent by the corresponding execution body and responding, returning the response result to the corresponding execution body when the SQL statement is a query statement, and sending the response result to the post-judger and returning an operation success message to the corresponding execution body when the SQL statement is an add statement, a delete statement or an update statement; a post-judger configured to compare the received response result with the recorded data to obtain difference data of the sub-database; judge the difference data of each sub-database, update the recorded data according to the judgment result, and forward the recorded data to the dispatcher for synchronously updating the sub-database corresponding to the abnormal execution body pre-judged and the abnormal sub-database post-judged.

8. The data processing apparatus according to claim 7, characterized in that: the SQL generation module encapsulates the execution body identifier, the external user request identifier and the SQL statement into a SQL request packet after generating the SQL statement; the pre-decider identifies the SQL request packets from the same external user request through the external user request identifier and makes a decision; the sub-database receives the SQL request packet, responds to the SQL statement in the SQL request packet, encapsulates the execution body identifier, the external user request identifier and the response result into a response packet and sends the response packet to the post-decider; the post-decider identifies a group of difference data from the same external user request through the external user request identifier and makes a decision.

9. A data processing apparatus according to claim 8, wherein, The post-decider further comprises a recorder, and the recorder is pre-provisioned with record data, and the initial acquisition step of the record data is: initially, data is read from each sub-database respectively, and the read data is grouped according to a pre-set grouping rule; the data in each group of the sub-databases is decided, and a group of data from the decided normal data is selected as the record data of the group and stored in the recorder, and the record data is sent to the dispatcher, so that the dispatcher updates the decided abnormal sub-database based on the record data.

10. A mimic system, characterized by: The data processing apparatus comprises an input agent, an execution body, a dispatcher and any one of claims 7-9.

Images