WO2023245893A1 - 一种监控方法、设备以及存储介质 - Google Patents

一种监控方法、设备以及存储介质 Download PDF

Info

Publication number
WO2023245893A1
WO2023245893A1 PCT/CN2022/120541 CN2022120541W WO2023245893A1 WO 2023245893 A1 WO2023245893 A1 WO 2023245893A1 CN 2022120541 W CN2022120541 W CN 2022120541W WO 2023245893 A1 WO2023245893 A1 WO 2023245893A1
Authority
WO
WIPO (PCT)
Prior art keywords
target
rules
rule
engine
database
Prior art date
Application number
PCT/CN2022/120541
Other languages
English (en)
French (fr)
Inventor
董琼
徐山凌
张晶
江旻
杨杨
Original Assignee
深圳前海微众银行股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 深圳前海微众银行股份有限公司 filed Critical 深圳前海微众银行股份有限公司
Publication of WO2023245893A1 publication Critical patent/WO2023245893A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0793—Remedial or corrective actions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3089—Monitoring arrangements determined by the means or processing involved in sensing the monitored data, e.g. interfaces, connectors, sensors, probes, agents
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G06F16/2282—Tablespace storage structures; Management thereof
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25—Integrating or interfacing systems involving database management systems

Definitions

  • This application relates to the field of data processing technology, and in particular, to a monitoring method, equipment and storage medium.
  • Cross-region, cross-server, and cross-database table rules When monitoring two types of rules, a and b, you can directly execute Structured Query Language database (Structured Query Language, SQL) rules. When monitoring type c rules, you can access multiple libraries at the same time by applying for database user permissions. The execution is essentially the same as monitoring rules of type a and b.
  • monitoring type d rules since the databases are deployed in different server clusters, it is impossible to directly query the tables.
  • the current production technology is to extract the data from the databases that need to be accessed in different server clusters to the data warehouse tool (hive). ), and then execute the network object-oriented query language (Hibernate Query Language, HQL) to perform joint table query monitoring.
  • Hibernate Query Language, HQL Hibernate Query Language
  • the embodiments of the present application are expected to provide a monitoring method, device and storage medium, which solves the current problem of low monitoring and analysis efficiency for cross-server and cross-database monitoring processes, and realizes a real-time cross-server monitoring and analysis process.
  • the cross-database monitoring method eliminates the need to extract data from different databases into hive, which reduces the consumption of computing resources and improves the efficiency of the monitoring and analysis process.
  • a monitoring method includes:
  • the type is a target type, obtain the database attribute information of the corresponding at least one target database based on the database identification to be accessed and the data table identification to be accessed;
  • the rules to be run are executed against at least one of the target databases to implement monitoring of the target product.
  • a monitoring device includes: a memory, a processor and a communication bus; wherein:
  • the memory is used to store executable instructions
  • the communication bus is used to realize the communication connection between the processor and the memory
  • the processor is configured to execute the monitoring program stored in the memory to implement the steps of the monitoring method described in any one of the above.
  • a third aspect is a storage medium, a monitoring program is stored on the storage medium, and when the monitoring program is executed by a processor, the steps of the monitoring method as described in any one of the above are implemented.
  • the rules to be run are parsed to obtain the database identifier to be accessed and the data table identifier to be accessed, and then based on the database identifier to be accessed and the data table to be accessed Identity, determine the type of the rule to be run. If the type is the target type, obtain the database attribute information of at least one corresponding target database based on the database identification to be accessed and the data table identification to be accessed, and generate the target engine based on the database attribute information. And through the target engine, the rules to be run are executed against at least one target database to monitor the target product.
  • the type of the rule to be run is determined after parsing the rule to be run for monitoring, and when the type is a target type, a target is generated based on the database attribute information of at least one target database involved in the rule to be run.
  • the engine uses the target engine to execute the rules to be run and implement monitoring operations. It solves the current problem of low monitoring and analysis efficiency for cross-server and cross-database monitoring processes, and implements a real-time cross-server and cross-database monitoring method. There is no need to extract data from the database into hive, which reduces the consumption of computing resources and improves the efficiency of the monitoring and analysis process.
  • Figure 1 is a schematic flow chart of a monitoring method provided by an embodiment of the present application.
  • FIG. 2 is a schematic flow chart of another monitoring method provided by an embodiment of the present application.
  • FIG. 3 is a schematic flow chart of another monitoring method provided by an embodiment of the present application.
  • Figure 4 is a schematic flow chart of a monitoring method provided by another embodiment of the present application.
  • FIG. 5 is a schematic flow chart of another monitoring method provided by another embodiment of the present application.
  • Figure 6 is a schematic flow chart of another monitoring method provided by another embodiment of the present application.
  • Figure 7 is a schematic diagram of an application scenario provided by the embodiment of the present application.
  • Figure 8 is a schematic structural diagram of a monitoring device provided by an embodiment of the present application.
  • the embodiment of the present application provides a monitoring method. As shown in Figure 1, the method is applied to monitoring equipment. The method includes the following steps:
  • Step 101 Determine the rules to be run for abnormal monitoring of the target product.
  • the monitoring device may be a server device or a service cluster.
  • the target product may be a business product, for example, it may be a business product in the financial field.
  • the rules to be run are existing rules used to monitor the target product. In some application scenarios, they can be called stock rules.
  • Step 102 Parse the rules to be run and obtain the database identifier to be accessed and the data table identifier to be accessed.
  • the rules to be run are parsed and analyzed, the databases involved in the rules to be run that need to be accessed are determined, the database identifiers to be accessed are obtained, and the data tables specifically involved in the rules to be run are obtained, so that the databases to be accessed are obtained.
  • Data table identifier the databases involved in the rules to be run that need to be accessed are determined.
  • Step 103 Determine the type of the rule to be run based on the identifier of the database to be accessed and the identifier of the data table to be accessed.
  • the identification of the database to be accessed and the identification of the data table to be accessed are analyzed to determine the type of the rule to be run.
  • the rules to be run can be divided according to whether the database they access crosses service areas. Specifically, they can be divided into two categories: one is non-cross-service area type, and the other is cross-service area type.
  • Step 104 If the type is a target type, obtain the database attribute information of at least one corresponding target database based on the identification of the database to be accessed and the identification of the data table to be accessed.
  • the target type is a cross-service area type.
  • the type of the rule to be run is a cross-service area type
  • at least one corresponding target database is determined based on the identification of the database to be accessed and the identification of the data table to be accessed, and the database attribute information of the corresponding at least one target database is obtained.
  • the database attribute information of the target database may be information required for accessing the database, environmental information to which the target database belongs, etc.
  • Step 105 Generate a target engine based on the database attribute information.
  • a target engine is generated based on the database attribute information of at least one target database corresponding to the rule to be run, so that the rule to be run is subsequently executed through the target engine to achieve real-time monitoring.
  • Step 106 Use the target engine to execute the rules to be run against at least one target database.
  • the rules to be run are executed against at least one target database to monitor the target product.
  • the generated target engine converts the rules to be run into runnable rules, and executes the runnable rules to implement the execution of the rules to be run, so as to monitor the target product.
  • the rules to be run are parsed to obtain the database identifier to be accessed and the data table identifier to be accessed, and then based on the database identifier to be accessed and the data table to be accessed Identity, determine the type of the rule to be run. If the type is the target type, obtain the database attribute information of at least one corresponding target database based on the database identification to be accessed and the data table identification to be accessed, and generate the target engine based on the database attribute information. And through the target engine, the rules to be run are executed against at least one target database to monitor the target product.
  • the type of the rule to be run is determined after parsing the rule to be run for monitoring, and when the type is a target type, a target is generated based on the database attribute information of at least one target database involved in the rule to be run.
  • the engine uses the target engine to execute the rules to be run and implement monitoring operations. It solves the current problem of low monitoring and analysis efficiency for cross-server and cross-database monitoring processes, and implements a real-time cross-server and cross-database monitoring method. There is no need to extract data from different databases into hive, which reduces the consumption of computing resources and improves the efficiency of the monitoring and analysis process.
  • embodiments of the present application provide a monitoring method.
  • the method is applied to monitoring equipment.
  • the method includes the following steps:
  • Step 201 Determine the rules to be run for abnormal monitoring of the target product.
  • the monitoring device obtains the existing rules to be run for abnormality monitoring of the target product.
  • Step 202 Parse the rules to be run and obtain the identifier of the database to be accessed and the identifier of the data table to be accessed.
  • the monitoring device parses the rules to be run and determines to obtain the database identifier to be accessed and the data table identifier to be accessed included in the rule to be executed.
  • the database identifier to be accessed is identification information used to uniquely identify the corresponding database, for example, it may be a database name, database number, etc.
  • the data table identifier to be accessed is identification information used to uniquely identify the corresponding data table, for example, it may be data Table name, data table number, etc.
  • Step 203 Determine the type of the rule to be run based on the identifier of the database to be accessed and the identifier of the data table to be accessed.
  • the identification of the database to be accessed and the identification of the data table to be accessed are analyzed to determine the service area to which the corresponding database and data table belong. If the database corresponding to the database ID to be accessed and the data table corresponding to the data table ID to be accessed are both in the same service area, determine that the type of the rule to be run is a non-cross-service area type; if the database corresponding to the database ID to be accessed and the data to be accessed are The data table corresponding to the table identifier is in multiple service areas, and the type of the rule to be run is determined to be a cross-service area type.
  • Step 204 If the type is a target type, determine at least one target database to be accessed based on the identifier of the database to be accessed and the identifier of the data table to be accessed.
  • the rules to be run can be directly executed.
  • the type is a target type, that is, a cross-service area type
  • Step 205 Traverse the test environment corresponding to at least one target database to obtain database attribute information.
  • the test environment corresponding to at least one target database is traversed and analyzed to obtain database attribute information of each target database.
  • the database attribute information of each target database can be, for example, the test environment, data center node (DCN) area, Internet Protocol (IP), port, and user name corresponding to each target database. (User), password (Password), etc.
  • Step 206 Generate a target engine based on the database attribute information.
  • a target engine is generated based on database attribute information of at least one target database, and the target engine may be a federated engine.
  • Step 207 Use the target engine to execute the rules to be run against at least one target database to monitor the target product.
  • the target engine is used to convert the rules to be run into executable rule codes for execution, thereby achieving monitoring of the target product.
  • step 208 after the monitoring device performs step 206, it is also used to perform step 208:
  • Step 208 Generate an engine data table corresponding to the target engine based on the database attribute information.
  • the engine data table is used to record the characteristic information of the data table corresponding to the rule to be run.
  • an engine data table corresponding to the target engine is generated based on the database attribute information of at least one target database, which is used to record the characteristic information of all data corresponding to the rules to be run and ensure that the target engine can access the source data.
  • step 207 is implemented by step 207a:
  • Step 207a Execute the rules to be run through the target engine and based on the engine data table.
  • the target engine accesses the access data source recorded in the engine data table, executes the rules to be run, and implements the monitoring operation.
  • step 207 after the monitoring device performs step 207, it is also used to perform steps 209 to 210:
  • Step 209 If it is detected that the rules to be run are updated at a preset time interval, the target engine updates the engine data table based on the updated rules to be run.
  • the monitoring device detects the rules to be run at preset time intervals and detects whether there are updates.
  • the updates include new rules, reduced rules, and/or modified rules.
  • the target engine is based on the updated rules to be run.
  • the process of updating the engine data table may be: the target engine parses the updated rules to be run, determines to obtain at least one reference database corresponding to the updated rules to be run, and determines at least A reference database's database property information is used to update the engine data table.
  • Step 210 Record and update the update time of the engine data table through the target engine.
  • the update time of the engine data table is recorded and updated through the target engine. In this way, whether the rules to be run are updated can be detected through the update time of the engine data table.
  • Step 211 Execute the updated rules to be run through the target engine based on the updated engine data table.
  • step 211 may refer to the specific implementation process of step 207a, which will not be described in detail here.
  • step 207a can be implemented by steps a11 to a13:
  • Step a11 Use the target engine to generate an operation strategy based on the rules to be run and the engine data table.
  • the target engine analyzes the rules to be run and the engine data table according to the requirements for generating the run policy, and then generates the run policy.
  • Step a12 Generate target execution statements based on the operation strategy through the target engine.
  • the target engine generates corresponding target execution statements based on the generated operation policy. It should be noted that the running policies are generated for different service areas, so the generated target execution statements include execution statements for different service areas.
  • Step a13 Execute the target execution statement through the target engine to implement the execution of the rules to be run.
  • the target engine when the target engine executes the target execution statement, it distributes the execution statements of different service areas to the nodes corresponding to the different service areas, and executes the corresponding execution statements through the corresponding nodes to implement the execution of the rules to be run.
  • step a11 can be implemented by steps a111 to a116:
  • Step a111 Determine at least one first data table belonging to at least one database corresponding to the same virtual area under the same service area from the engine data table.
  • the data tables recorded in the engine data table are grouped.
  • One grouping method is to determine at least one first data table in at least one database corresponding to the same virtual area under the same service area.
  • Step a112 Combine at least one first data table based on the rules to be run to obtain a first policy.
  • At least one first data table is combined according to the relationship in at least one first data table in the rule to be run to obtain the first policy.
  • Step a113 Determine at least one second data table belonging to at least one database corresponding to different virtual areas under different service areas from the engine data table.
  • the data tables recorded in the engine data table are grouped. Another grouping method is to determine at least one second data table belonging to at least one database corresponding to different virtual areas under different service areas.
  • Step a114 Combine at least one second data table based on the rules to be run to obtain a second strategy.
  • At least one second data table is combined according to the relationship in the at least one second data table in the rule to be run to obtain the second policy.
  • Step a115 From the engine data table, determine a third data table that has only one service area corresponding to the virtual area.
  • a third data table under different virtual areas belonging to only one service area is determined.
  • Step a116 Based on the rules to be run, determine the third data table as the third strategy.
  • the operation strategy includes a first strategy, a second strategy and a third strategy.
  • the third data table is directly determined as the third strategy without the need for combination processing.
  • step 207 after the monitoring device performs step 207, it is also used to perform steps 212 to 214:
  • Step 212 Output the execution results through the target engine.
  • the execution result is obtained by the target engine executing the rules to be run.
  • the target engine executes the target execution statement
  • the corresponding execution result is obtained.
  • the target engine outputs the execution result, and the execution result can be displayed and processed.
  • Step 213 If it is determined that the target product is abnormal based on the execution results, at least one abnormal data rule is determined through the target engine.
  • the execution results are analyzed, and it is determined that the execution results indicate that the target product is abnormal or that the execution results indicate that the target product is abnormal.
  • the target engine determines the abnormal rules among the rules to be run, and obtains at least one abnormal data rule.
  • Step 214 The target engine performs an exception repair operation based on at least one exception data rule and a preset exception repair method.
  • the preset abnormal repair method is a preset repair method for data, for example, it can be a repair method, a cleaning method, or a repair method and a cleaning method, wherein the repair method
  • the numerical method is a method for correcting data
  • the cleaning method is a method for cleaning abnormal data.
  • step 214 can be implemented by steps 214a to 214d:
  • Step 214a Determine at least one list object involved in each abnormal data rule through the target engine.
  • each abnormal data rule is analyzed and at least one list object involved in each abnormal data rule is determined.
  • the list object may be the list identification information of the list.
  • Step 214b Use the target engine to determine the association rules that each list object has an association relationship with from at least one target database to obtain the target association rules.
  • At least one target database is analyzed to determine the associated objects that are associated with each list object, and the corresponding association rules are determined based on the associated objects. In this way, it is possible to determine that all the rules corresponding to at least one abnormal data rule are obtained. Association rules are recorded as target association rules.
  • Step 214c Obtain the rule to be repaired through the target engine based on at least one abnormal data rule and the target association rule.
  • At least one abnormal data rule and the target association rule are analyzed and processed to determine the rule to be repaired.
  • Step 214d Use the target engine to perform an exception repair operation based on the rules to be repaired and the preset exception repair method.
  • the target engine uses a repair method corresponding to a preset exception repair method to process the data corresponding to the rule to be repaired to implement the exception repair operation.
  • step 214d the data corresponding to the rules to be repaired can be backed up first, so that when a subsequent failure occurs, a roll-up operation can be performed, or a failure in the abnormal repair operation can be performed. Repair failure analysis and processing.
  • step 214c can be implemented by the following steps: classifying at least one abnormal data rule and the target association rule through the target engine into a group according to the rules belonging to the same service area. Group them to get the rules to be repaired.
  • the target engine groups at least one abnormal data rule and the target association rule according to the grouping relationship that groups rules belonging to the same service area to obtain the rules to be repaired. Among them, when there are duplicate rules in at least one abnormal data and target association rules, deduplication processing is required.
  • step 214d can be implemented by steps b11 to b12, or steps b13 to b14, or step b15:
  • Step b11 If the default abnormality repair method is the repair method, obtain the default repair rule corresponding to the rule to be repaired through the target engine.
  • the target engine obtains the preset repair rules corresponding to the rules to be repaired, where the preset repair rules are preset for each rule in the rules to be repaired.
  • the rules for updating the corresponding data is the preset abnormality repair method.
  • Step b12 Execute preset repair rules through the target engine to implement abnormality repair operations.
  • the target engine executes the preset repair rules corresponding to the rules to be repaired, and performs corresponding repair processing on the data corresponding to the rules to be repaired.
  • the abnormal data corresponding to the rule to be repaired is replaced with the data specified in the preset repair rule.
  • Step b13 If the preset exception repair method is the cleanup method, perform the data cleanup operation corresponding to the rule to be repaired through the target engine.
  • exception repair operations include data cleaning operations.
  • the target engine when the preset exception repair mode is the cleanup mode, performs an operation for cleaning the data corresponding to the rule to be repaired, which may be, for example, an operation to delete the data corresponding to the rule to be repaired.
  • Step b14 If the preset abnormality repair method includes a repair method and a cleanup method, obtain the preset repair rule corresponding to the rule to be repaired through the target engine.
  • Step b15 After executing the preset repair rules through the target engine, perform data cleaning operations.
  • the preset abnormality repair method when the preset abnormality repair method includes a correction method and a cleaning method, these two repair methods usually have a processing priority order to ensure the accuracy of the final processed data, and are usually set to the correction method.
  • the processing priority is higher than that of the cleanup method, that is, during the execution process, the repair processing corresponding to the repair method needs to be performed on the rules to be repaired, and then the repair processing corresponding to the cleanup method needs to be performed.
  • the priority of the cleaning method can also be set to be higher than the priority of the number correction method, which can be determined according to the actual application scenario.
  • step 214e after the monitoring device performs step 214d, it is also used to perform step 214e:
  • Step 214e If an abnormality in the target product is detected, the target engine repeatedly executes the step "If it is determined that the target product is abnormal based on the execution results, determine at least one abnormal data rule through the target engine" until it is detected that the target product is normal, and the abnormality repair operation ends.
  • the abnormality repair operation ends. Otherwise, if the target product is detected If the product still has abnormalities, you need to repeat the corresponding content of steps 213 to 214 until no abnormalities are detected in the target product before the abnormality repair operation is completed.
  • the embodiments of the present application provide a monitoring method, including:
  • Step c11 The inventory rule determines whether there is a cross-service area. If it crosses a service area, perform step c12. Otherwise, perform step c14.
  • the schematic diagram of an application scenario across service areas can be shown in Figure 7.
  • the Tc1 connection is obtained, realizing cross-region access between service area 1 and service area 2.
  • Rbc is obtained by connecting Tb1 in service area 1 and Tc1 in service area 2.
  • Step c12 engine initialization.
  • DB information at least includes test environment, DCN area, IP, Port, User, Password and other information. Normally, this information can be obtained from the configuration center of the Configuration Management Database (CMDB). When it is also stored locally, it can be obtained directly from the local area.
  • CMDB Configuration Management Database
  • cross-service area inventory rules involve 1 Application Data Management (ADM) area and 2 DCN areas.
  • ADM Application Data Management
  • DBSET1 and DBSET2 When deployed in different service areas DBSET1 and DBSET2, the corresponding DB information can be recorded as: DBSET1: source environment K, area ADM, library glpdb, IP: 10.1.1.1, PORT: 3301, USER: user1, PASSWD: xxx, table T1; DBSET2: source environment K, area DCN, library cpsdb, IP: 10.1.1.2 ,PORT:3302,USER:user2,PASSWD:xxx,Table T2.
  • Step c13 Execute the inventory rules through the engine.
  • a federated engine is created based on the environment information and DCN area information.
  • the federated engine includes a master node for decision-making and a slave node corresponding to multiple service areas.
  • the federated engine is also created based on the environment information. and DCN information, create a federated table corresponding to the federated engine, where the mapping rule of the federated table can be source database name_source table name_region name.
  • a mapping relationship is established between the federated engine and each database corresponding to the inventory rule.
  • the federated engine generates different operating strategies based on the inventory rules and federated tables. The steps are as follows:
  • T1 table indicates that it is in the virtual area A0, which has only one logical area
  • T2 table indicates that it is in the virtual area B0, and this virtual area has two logical areas
  • T3 table and T4 table indicates that it is in the same virtual area C0 ,There are two different service databases.
  • the generated running strategies include: strategy 1, strategy 2 and strategy 3; among them, strategy 1 is the combination of the same virtual area, the same logical area under different service areas, such as when T3 and T4 tables are joined, the generated combinations are ( C1, C1) and (C2, C2); Strategy 2 is different virtual areas. Under different service areas, logical areas need to be combined separately. For example, when T2 and T3 tables are joined, the generated combinations are (B1, C1), (B1,C2), (B2,C1) and (B2,C2); Strategy 3 is that if there is only one logical area of the virtual area corresponding to the table, only one combination is required. For example, when the T1 table is queried separately, The generated combination is (A1).
  • the iterative replacement method is consistent with the federated table creation principle.
  • the stock rules before replacement are as follows:
  • the federated engine runs the engine executable statements in parallel to implement the execution process of the stock rules.
  • Step c14 Execute the inventory rules.
  • step c13 after the federated engine executes step c13, it is also used to execute the following steps:
  • Step c15 Check whether the inventory rules are updated at preset time intervals. If the inventory rules are updated, the federated engine and federated table are also updated synchronously, and then the updated inventory rules are executed.
  • step c13 or step c15 after the federated engine performs step c13 or step c15, it is also used to perform the following steps:
  • Step c16 Output the rule running results.
  • the federated engine is cross-displayed according to the intersection areas of the generated policy combinations. If the running result of any combination does not meet the abnormal verification conditions, the rule running result is determined to be a rule check failure. For example, if the above two split rule combinations (A1, B1) and (A1, B2) fail to verify the running results of (A1, B1) and succeed in running the verification of (A1, B2), it will still be determined that The inventory rule verification failed.
  • Step c17 If the rule running result is verification failure, determine at least one abnormal data rule.
  • the keywords (KEY) corresponding to the rules are found through step-by-step iterative anti-association of the table fields involved in the abnormal rules in the existing rules.
  • the specific process of searching for the associated primary key and index of table T1, and then back-checking all the associated keyword KEY, associated tables, and abnormal field value list sets under the database to which the table list T1 belongs, to obtain the association rules in a single database It can be expressed as: 1) According to the keyword set t: [k1, k2, k3] found in the T1 table; 2) According to the keyword k set and the original field set sc[c1, c2, c3] in R1, the abnormality Field set c: [c1, c2], search for the association table set involved in similar association rules in the rule base: [t1, t2, t3].
  • the determination method of similar association rule tables is: 1 First generate a table linked list, the current rule R1 T1 is used as the vertex, 2 Find the first-level association rule node list L1r[R2, R3,...] containing the T1 table, and obtain the intersection set L1t[t1,t2,t3] of its association rule table. It should be noted that in order To avoid scanning the entire rule library, search for the number of nodes taken down from the association rule linked list equal to the initial T_num. Repeat this until all nodes in the generated table linked list have been traversed, and the association rule determination search is completed, and the final single database corresponding to T1 can be obtained.
  • the association rules are: ⁇ k: [k1, k2, k3], t: [t1, t2, t3], c: [c1, c2] ⁇ .
  • association rules of multiple databases corresponding to the existing rules are combined to obtain at least one final abnormal data rule.
  • Step c18 Determine the abnormality repair method including repair method and cleaning method.
  • Step c19 Determine the preset repair rule corresponding to at least one abnormal data rule.
  • Step c20 Before executing the preset repair rules, in order to preserve the scene or trace the abnormal scenario, first back up the abnormal data corresponding to at least one abnormal data rule.
  • Step c21 Execute the preset repair rule corresponding to at least one abnormal data rule.
  • step c17 when executing the preset repair rule corresponding to at least one abnormal data rule, it is necessary to determine whether the association affects other data tables. If an abnormality is found, continue to repeat step c17.
  • the preset repair rules determined in step c19 are executed first until all the preset repair rules are finally determined to be executed and the detection result is successful.
  • Step c22 After the execution of the number repair mode is completed, the cleaning mode continues to be automatically executed until the detection and monitoring is successful after the cleaning mode is executed and the abnormal data is repaired this time. Otherwise, steps c17 to c22 are repeated.
  • the rules to be run are parsed to obtain the database identifier to be accessed and the data table identifier to be accessed, and then based on the database identifier to be accessed and the data table to be accessed Identity, determine the type of the rule to be run. If the type is the target type, obtain the database attribute information of at least one corresponding target database based on the database identification to be accessed and the data table identification to be accessed, and generate the target engine based on the database attribute information. And through the target engine, the rules to be run are executed against at least one target database to monitor the target product.
  • the type of the rule to be run is determined after parsing the rule to be run for monitoring, and when the type is a target type, a target is generated based on the database attribute information of at least one target database involved in the rule to be run.
  • the engine uses the target engine to execute the rules to be run and implement monitoring operations. It solves the current problem of low monitoring and analysis efficiency for cross-server and cross-database monitoring processes, and implements a real-time cross-server and cross-database monitoring method. There is no need to extract data from different databases into hive, which reduces the consumption of computing resources and improves the efficiency of the monitoring and analysis process.
  • the monitoring device 3 can include: processing 31, memory 32 and communication bus 33, where:
  • Memory 32 used to store executable instructions
  • Communication bus 33 is used to realize the communication connection between the processor 31 and the memory 32;
  • the processor 31 is configured to execute the monitoring program stored in the memory 32 to implement the method implementation process provided with reference to the embodiments corresponding to Figures 1 to 6, which will not be described again here.
  • embodiments of the present application provide a computer-readable storage medium, referred to as a storage medium for short.
  • the computer-readable storage medium stores one or more programs, and the one or more programs can be used by one or more
  • the processor executes to implement the monitoring method implementation process provided by the embodiments corresponding to Figures 1 to 6, which will not be described again here.
  • Embodiments of the present application provide a monitoring method, equipment and storage medium.
  • the method includes: determining rules to be run for abnormal monitoring of target products; parsing the rules to be run to obtain the database identification to be accessed and the data table to be accessed. identification; based on the identification of the database to be accessed and the identification of the data table to be accessed, determine the type of the rule to be run; if the type is a target type, based on the identification of the database to be accessed and the data to be accessed Table identification, obtain the corresponding database attribute information of at least one target database; generate a target engine based on the database attribute information; use the target engine to execute the to-be-run rules for at least one of the target databases to achieve all
  • the monitoring of the target product described above solves the problem of low efficiency of monitoring and analysis of the current cross-server and cross-database monitoring process, and implements a real-time cross-server and cross-database monitoring method without the need to extract data from the database. In hive, the consumption of

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Quality & Reliability (AREA)
  • Data Mining & Analysis (AREA)
  • Computational Linguistics (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Software Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

一种监控方法、监控设备和存储介质，该方法包括：确定用于对目标产品进行异常监控的待运行规则（101）；解析待运行规则，得到待访问数据库标识和待访问数据表标识（102）；基于待访问数据库标识和待访问数据表标识，确定待运行规则的所属类型（103）；若所属类型为目标类型，基于待访问数据库标识和待访问数据表标识，获取对应的至少一个目标数据库的数据库属性信息（104）；基于数据库属性信息，生成目标引擎（105）；通过目标引擎，针对至少一个目标数据库执行待运行规则（106），以实现对目标产品的监控。

Description

一种监控方法、设备以及存储介质
相关申请的交叉引用
本申请基于申请号为202210731206.6、申请日为2022年6月24日的中国专利申请提出，并要求该中国专利申请的优先权，该中国专利申请的全部内容在此引入本申请作为参考。
技术领域
本申请涉及数据处理技术领域，尤其涉及一种监控方法、设备以及存储介质。
背景技术
随着计算机技术的飞速发展，越来越多的技术应用在金融领域，传统金融业正在逐步向金融科技(Fintech)转变，但由于金融行业的安全性和实时性要求，也对技术提出了更高的要求。在数据处理领域中，通常通过对不同应用系统对应的数据库中的数据是否存在异常来确定产品全链路应用系统的可靠性。目前，不同的产品全链路应用系统可对应同一区域同一服务器下的同一数据库或不同数据库，或不同区域不同服务器下的不同数据库，因此，异常数据监控规则常分为以下几类：a.单表内规则；b.同库跨表规则；c.同同一区域同一服务器下跨库跨表规则；d.跨区域跨服务器跨库表规则。针对a和b两种类型的规则进行监控时，可以直接执行结构化查询语言数据库(Structured Query Language，SQL)规则。针对c类型的规则进行监控时，通过申请数据库用户权限即可同时访问多个库，执行时本质同a和b两种类型的规则监控是一样的。而针对d类的规则进行监控时，由于数据库部署在不同服务器集群，无法直接联表查询，目前生产上的技术是通过将不同服务器集群下需要访问的数据库中的数据抽取到数据仓库工具(hive)中，然后执行网络面向对象的查询语言(Hibernate Query Language，HQL)进行联表查询监控。
但是，目前针对d类规则进行监控时，由于需要从多个不同数据库中分别抽取数据至hive中，才能进行数据分析，导致数据分析的实时性较差，且数据抽取过程中消耗的运算资源较高，使监控分析过程的效率较低。
发明内容
为解决上述技术问题，本申请实施例期望提供一种监控方法、设备以及存储介质，解决了目前针对跨服务器跨数据库的监控过程的监控分析效率较低的问题，实现了一种实时对跨服务器跨数据库的监控方法，无需将数据从不同数据库中抽取至hive中，降低了运算资源的消耗，提高了监控分析过程的效率。
本申请的技术方案是这样实现的：
第一方面，一种监控方法，所述方法包括：
确定用于对目标产品进行异常监控的待运行规则；
解析所述待运行规则，得到待访问数据库标识和待访问数据表标识；
基于所述待访问数据库标识和所述待访问数据表标识，确定所述待运行规则的 所属类型；
若所述所属类型为目标类型，基于所述待访问数据库标识和所述待访问数据表标识，获取对应的至少一个目标数据库的数据库属性信息；
基于所述数据库属性信息，生成目标引擎；
通过所述目标引擎，针对至少一个所述目标数据库执行所述待运行规则，以实现对所述目标产品的监控。
第二方面，一种监控设备，所述设备包括：存储器、处理器和通信总线；其中：
所述存储器，用于存储可执行指令；
所述通信总线，用于实现所述处理器和所述存储器之间的通信连接；
所述处理器，用于执行所述存储器中存储的监控程序，实现如上述任一项所述的监控方法的步骤。
第三方面，一种存储介质，所述存储介质上存储有监控程序，所述监控程序被处理器执行时实现如上述任一项所述的监控方法的步骤。
本申请实施例中，通过确定用于对目标产品进行异常监控的待运行规则后，解析待运行规则，得到待访问数据库标识和待访问数据表标识，然后基于待访问数据库标识和待访问数据表标识，确定待运行规则的所属类型，若所属类型为目标类型，基于待访问数据库标识和待访问数据表标识，获取对应的至少一个目标数据库的数据库属性信息，基于数据库属性信息，生成目标引擎，并通过目标引擎，针对至少一个目标数据库执行待运行规则，以实现对目标产品的监控。这样，通过对用于进行监控的待运行规则进行解析后确定得到的待运行规则的所属类型，并在所属类型为目标类型时，根据待运行规则涉及的至少一个目标数据库的数据库属性信息生成目标引擎，以通过目标引擎来执行待运行规则，实现监控操作，解决了目前针对跨服务器跨数据库的监控过程的监控分析效率较低的问题，实现了一种实时对跨服务器跨数据库的监控方法，无需将数据从不通过数据库中进行抽取至hive中，降低了运算资源的消耗，提高了监控分析过程的效率。
附图说明
图1为本申请实施例提供的一种监控方法的流程示意图；
图2为本申请实施例提供的另一种监控方法的流程示意图；
图3为本申请实施例提供的又一种监控方法的流程示意图；
图4为本申请另一实施例提供的一种监控方法的流程示意图；
图5为本申请另一实施例提供的另一种监控方法的流程示意图；
图6为本申请另一实施例提供的又一种监控方法的流程示意图；
图7为本申请实施例提供的一种应用场景示意图；
图8为本申请实施例提供的一种监控设备的结构示意图。
具体实施方式
为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述，所描述的实施例不应视为对本申请的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。
除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。
本申请的实施例提供一种监控方法，参照图1所示，方法应用于监控设备，该方法包括以下步骤：
步骤101、确定用于对目标产品进行异常监控的待运行规则。
在本申请实施例中，监控设备可以是服务器设备，也可以是服务集群。目标产品可以是业务产品，例如可以是金融领域中的各业务产品，示例性的，可以是金融领域中的贷款业务产品。待运行规则为用于对目标产品进行监控的已有规则，在一些应用场景下，可以称为存量规则。
步骤102、解析待运行规则，得到待访问数据库标识和待访问数据表标识。
在本申请实施例中，对待运行规则进行解析分析，确定待运行规则中涉及到的需要进行访问的数据库，得到待访问数据库标识，以及待运行规则中具体涉及到的数据表，从而的待访问数据表标识。
步骤103、基于待访问数据库标识和待访问数据表标识，确定待运行规则的所属类型。
在本申请实施例中，对待访问数据库标识和待访问数据表标识进行分析，确定待运行规则的所属类型。待运行规则可以根据其访问的数据库是否跨服务区域来进行划分，具体可以划分为两类：一类为非跨服务区域类型，另一种为跨服务区域类型。
步骤104、若所属类型为目标类型，基于待访问数据库标识和待访问数据表标识，获取对应的至少一个目标数据库的数据库属性信息。
在本申请实施例中，目标类型为跨服务区域类型。在待运行规则的所属类型为跨服务区域类型时，根据待访问数据库标识和待访问数据表标识，确定对应的至少一个目标数据库，并获取对应的至少一个目标数据库的数据库属性信息。目标数据库的数据库属性信息可以是用于访问数据库时所需的信息，以及目标数据库所属的环境信息等。
步骤105、基于数据库属性信息，生成目标引擎。
在本申请实施例中，根据待运行规则对应的至少一个目标数据库的数据库属性信息，生成目标引擎，以便后续通过目标引擎执行待运行规则，实现实时监控。
步骤106、通过目标引擎，针对至少一个目标数据库执行待运行规则。
其中，通过目标引擎，针对至少一个目标数据库执行待运行规则，以实现对目标产品的监控。
在本申请实施例中，通过生成的目标引擎，将待运行规则转换为可运行规则，并执行可运行规则，实现待运行规则的执行，以对目标产品的进行监控。
本申请实施例中，通过确定用于对目标产品进行异常监控的待运行规则后，解析待运行规则，得到待访问数据库标识和待访问数据表标识，然后基于待访问数据库标识和待访问数据表标识，确定待运行规则的所属类型，若所属类型为目标类型，基于待访问数据库标识和待访问数据表标识，获取对应的至少一个目标数据库的数据库属性信息，基于数据库属性信息，生成目标引擎，并通过目标引擎，针对至少一个目标数据库执行待运行规则，以实现对目标产品的监控。这样，通过对用于进行监控的待运行规则进行解析后确定得到的待运行规则的所属类型，并在所属类型为目标类型时，根据待运行规则涉及的至少一个目标数据库的数据库属性信息生成目标引擎，以通过目标引擎来执行待运行规则，实现监控操作，解决了目前针对跨服务器跨数据库的监控过程的监控分析效率较低的问题，实现了一种实时对跨服务器跨数据库的监控方法，无需将数据从不同数据库中抽取至hive中，降低了运算资源的消耗，提高了监控分析过程的效率。
基于前述实施例，本申请的实施例提供一种监控方法，参照图2所示，该方法应用于监控设备，该方法包括以下步骤：
步骤201、确定用于对目标产品进行异常监控的待运行规则。
在本申请实施例中，监控设备获取当前针对目标产品的已有的用于异常监控的待运行规则。
步骤202、解析待运行规则，得到待访问数据库标识和待访问数据表标识。
在本申请实施例中，监控设备对待运行规则进行解析，确定得到待运行规则中包括的待访问数据库标识和待访问数据表标识。其中，待访问数据库标识是用于唯一标识对应的数据库的标识信息，例如可以是数据库名称、数据库编号等；待访问数据表标识是用于唯一标识对应的数据表的标识信息，例如可以是数据表名称、数 据表编号等。
步骤203、基于待访问数据库标识和待访问数据表标识，确定待运行规则的所属类型。
在本申请实施例中，对待访问数据库标识和待访问数据表标识进行分析，确定对应的数据库和数据表所属的服务区域。若待访问数据库标识对应的数据库和待访问数据表标识对应的数据表均在同一服务区域，确定待运行规则的所属类型为非跨服务区域类型；若待访问数据库标识对应的数据库和待访问数据表标识对应的数据表在多个服务区域，确定待运行规则的所属类型为跨服务区域类型。
步骤204、若所属类型为目标类型，基于待访问数据库标识和待访问数据表标识，确定待访问的至少一个目标数据库。
在本申请实施例中，在所属类型为非跨服务区域类型时，直接执行待运行规则即可。在所属类型为目标类型即跨服务区域类型时，确定待访问数据表标识所属的数据库和待访问数据库标识对应的数据库，然后对确定的数据库进行去重处理，得到待访问的至少一个目标数据库。
步骤205、遍历至少一个目标数据库对应的测试环境，得到数据库属性信息。
在本申请实施例中，对至少一个目标数据库对应的测试环境进行遍历分析，获取每一目标数据库的数据库属性信息。每一目标数据库的数据库属性信息例如可以是每一目标数据库对应的测试环境、数据中心节点(Data center node，DCN)区域、网际互连协议(Internet Protocol，IP)、端口(Port)、用户名(User)、密码(Password)等。
步骤206、基于数据库属性信息，生成目标引擎。
在本申请实施例中，基于至少一个目标数据库的数据库属性信息，生成目标引擎，目标引擎可以是联合(federated)引擎。
步骤207、通过目标引擎，针对至少一个目标数据库执行待运行规则，以实现对目标产品的监控。
在本申请实施例中，通过目标引擎，将待运行规则转换为可执行规则代码来进行运行，实现对目标产品的监控。
基于前述实施例，在本申请其他实施例中，参照图3所示，监控设备执行步骤206之后，还用于执行步骤208：
步骤208、基于数据库属性信息，生成与目标引擎对应的引擎数据表。
其中，引擎数据表用于记录待运行规则对应的数据表的特征信息。
在本申请实施例中，基于至少一个目标数据库的数据库属性信息，生成目标引擎对应的引擎数据表，用于记录待运行规则对应的全部数据的特征信息，保证目标引擎可以访问的源数据。
对应的，步骤207由步骤207a来实现：
步骤207a、通过目标引擎，基于引擎数据表，执行待运行规则。
在本申请实施例中，通过目标引擎访问引擎数据表中记录的访问数据源，执行待运行规则，实现监控操作。
基于前述实施例，在本申请其他实施例中，参照图4所示，监控设备执行步骤207之后，还用于执行步骤209～210：
步骤209、若按照预设时间间隔检测到待运行规则存在更新的情况，通过目标引擎基于更新后的待运行规则，更新引擎数据表。
在本申请实施例中，监控设备按照预设时间间隔对待运行规则进行检测，检测是否有更新，更新包括规则新增、规则减少、和/或规则修改等情况。目标引擎基于更新后的待运行规则，更新引擎数据表的过程具体可以是：目标引擎对更新后的待运行规则进行解析，确定得到更新后的待运行规则对应的至少一个参考数据库，并确定至少一个参考数据库的数据库属性信息来更新引擎数据表。
步骤210、通过目标引擎记录更新引擎数据表的更新时间。
在本申请实施例中，通过目标引擎记录更新引擎数据表的更新时间，这样，可以通过引擎数据表的更新时间来检测待运行规则是否存在更新的情况。
基于前述实施例，在本申请其他实施例中，参照图5所示，监控设备执行捕捉209之后，还用于执行步骤211：
步骤211、通过目标引擎，基于更新后的引擎数据表，执行更新后的待运行规则。
在本申请实施例中，步骤211的实现过程可以参照步骤207a的具体实现过程，此处不再详细赘述。
基于前述实施例，在本申请其他实施例中，步骤207a可以由步骤a11～a13来实现：
步骤a11、通过目标引擎基于待运行规则和引擎数据表，生成运行策略。
在本申请实施例中，目标引擎对待运行规则和引擎数据表，根据运行策略生成 的要求，对待运行规则和引擎数据表进行分析，进而生成得到运行策略。
步骤a12、通过目标引擎基于运行策略，生成目标执行语句。
在本申请实施例中，目标引擎根据生成的运行策略，生成对应的目标执行语句。需说明的是，运行策略是针对不同的服务区域生成的，因此，生成的目标执行语句包括针对不同服务区域的执行语句。
步骤a13、通过目标引擎，执行目标执行语句，以实现待运行规则的执行。
在本申请实施例中，目标引擎执行目标执行语句时，将不同服务区域的执行语句分发至不同服务区域对应的节点，通过对应的节点执行对应的执行语句，实现待运行规则的执行。
基于前述实施例，在本申请其他实施例中，步骤a11可以由步骤a111～a116来实现：
步骤a111、从引擎数据表中，确定属于同一服务区域下同一虚拟区域对应的至少一个数据库的至少一个第一数据表。
在本申请实施例中，对引擎数据表中记录的数据表进行分组，一种分组方式为确定属于同一服务区域下同一虚拟区域对应的至少一个数据库中的至少一个第一数据表。
步骤a112、基于待运行规则，对至少一个第一数据表进行组合，得到第一策略。
在本申请实施例中，按照待运行规则中至少一个第一数据表中的关系，对至少一个第一数据表进行组合，得到第一策略。
步骤a113、从引擎数据表中，确定属于不同服务区域下，不同虚拟区域对应的至少一个数据库的至少一个第二数据表。
在本申请实施例中，对引擎数据表中记录的数据表进行分组，另一种分组方式为确定属于不同服务区域下不同虚拟区域对应的至少一个数据库中的至少一个第二数据表。
步骤a114、基于待运行规则，对至少一个第二数据表进行组合，得到第二策略。
在本申请实施例中，按照待运行规则中至少一个第二数据表中的关系，对至少一个第二数据表进行组合，得到第二策略。
步骤a115、从引擎数据表中，确定虚拟区域对应的服务区域只有1个的第三数据表。
在本申请实施例中，确定只属于1个服务区域的不同虚拟区域下的第三数据表。
步骤a116、基于待运行规则，确定第三数据表为第三策略。
其中，运行策略包括第一策略、第二策略和第三策略。
在本申请实施例中，直接将第三数据表确定为第三策略，无需进行组合处理。
基于前述实施例，在本申请其他实施例中，参照图6所示，监控设备执行步骤207之后，还用于执行步骤212～214：
步骤212、通过目标引擎，输出执行结果。
其中，执行结果为目标引擎执行待运行规则得到的。
在本申请实施例中，目标引擎执行目标执行语句后，得到对应的执行结果，目标引擎输出执行结果，可以将执行结果进行显示处理。
步骤213、若基于执行结果确定目标产品存在异常，通过目标引擎确定至少一个异常数据规则。
在本申请实施例中，对执行结果进行分析，确定执行结果表明目标产品存在异常或执行结果指示目标产品存在异常，通过目标引擎确定待运行规则中出现异常的规则，得到至少一个异常数据规则。
步骤214、通过目标引擎基于至少一个异常数据规则和预设异常修复方式，执行异常修复操作。
在本申请实施例中，预设异常修复方式为用于对数据进行预设的修复方式，例如可以是修数方式，也可以是清理方式，还可以是修数方式和清理方式，其中，修数方式是对数据进行修正的方式，清理方式是对异常数据进行清理的方式。这样，目标引擎确定得到至少一个异常数据规则后，采用预设异常修复方式对至少一个异常数据规则对应的数据进行处理，实现异常修复操作。
基于前述实施例，在本申请其他实施例中，步骤214可以由步骤214a～214d来实现：
步骤214a、通过目标引擎确定每一异常数据规则涉及的至少一个列表对象。
在本申请实施例中，对每一异常数据规则进行分析，确定每一异常数据规则中涉及的至少一个列表对象。例如列表对象可以是列表的列表标识信息。
步骤214b、通过目标引擎从至少一个目标数据库中确定每一列表对象具有关联关系的关联规则，得到目标关联规则。
在本申请实施例中，对至少一个目标数据库进行分析，确定与每一列表对象具有关联关系的关联对象，根据关联对象确定对应的关联规则，这样，可以确定得到 至少一个异常数据规则对应的全部关联规则，记为目标关联规则。
步骤214c、通过目标引擎基于至少一个异常数据规则和目标关联规则，得到待修复规则。
在本申请实施例中，对至少一个异常数据规则和目标关联规则进行分析处理，确定得到待修复规则。
步骤214d、通过目标引擎基于待修复规则和预设异常修复方式，执行异常修复操作。
在本申请实施例中，目标引擎针对待修复规则对应的数据采用预设异常修复方式对应的修复方式进行处理，实现异常修复操作。
需说明的是，在一些应用场景中，在执行步骤214d之前，可以先将待修复规则对应的数据进行备份处理，以便后续出现故障时，进行上滚操作，或者针对异常修复操作出现的故障进行修复故障分析处理。
基于前述实施例，在本申请其他实施例中，步骤214c可以由以下步骤来实现：通过目标引擎按照属于同一服务区域的规则分为一组的关系，对至少一个异常数据规则和目标关联规则进行分组，得到待修复规则。
在本申请实施例中，目标引擎按照将属于同一服务区域的规则分为一组的分组关系，将至少一个异常数据规则和目标关联规则进行分组处理，得到待修复规则。其中，至少一个异常数据跪着和目标关联规则中有重复的规则时，需进行去重处理。
基于前述实施例，在本申请其他实施例中，步骤214d可以由步骤b11～b12，或步骤b13～b14，或步骤b15来实现：
步骤b11、若预设异常修复方式为修数方式，通过目标引擎获取待修复规则对应的预设修复规则。
在本申请实施例中，在预设异常修复方式为修数方式时，目标引擎获取待修复规则对应的预设修复规则，其中，预设修复规则是待修复规则中针对每一规则预先设定的对其对应的数据进行更新(Update)的规则。
步骤b12、通过目标引擎执行预设修复规则，以实现异常修复操作。
在本申请实施例中，目标引擎执行待修复规则对应的预设修复规则，实现对待修复规则对应的数据进行对应的修复处理。例如，是将待修复规则对应的异常数据替换为预设修复规则中规定的数据。
步骤b13、若预设异常修复方式为清理方式，通过目标引擎执行针对待修复规 则对应的数据清理操作。
其中，异常修复操作包括数据清理操作。
在本申请实施例中，在预设异常修复方式为清理方式时，目标引擎执行用于对待修复规则对应的数据进行数据清理的操作，例如可以是将待修复规则对应的数据进行删除的操作。
步骤b14、若预设异常修复方式包括修数方式和清理方式，通过目标引擎获取待修复规则对应的预设修复规则。
步骤b15、通过目标引擎执行预设修复规则后，执行数据清理操作。
在本申请实施例中，在预设异常修复方式包括修数方式和清理方式时，这两种修复方式通常具有处理优先级顺序，以保证最终处理的数据的准确性，通常设置为修数方式的处理优先级高于清理方式，即在执行过程中，需针对待修复规则执行修数方式对应的修复处理，然后再执行清理方式对应的修复处理。但在一些应用场景下，也可以设置清理方式的优先级高于修数方式的优先级，具体可以根据实际应用场景来确定。
基于前述实施例，在本申请其他实施例中，监控设备执行步骤214d之后，还用于执行步骤214e：
步骤214e、若监测到目标产品异常，通过目标引擎重复执行步骤“若基于执行结果确定目标产品存在异常，通过目标引擎确定至少一个异常数据规则”，直至测到目标产品正常，结束异常修复操作。
在本申请实施例中，若监控设备执行步骤214d之后，检测到目标产品正常，即针对目标产品的监控无异常情况，表明异常已排除，则此次异常修复操作结束，否则，若检测到目标产品仍然存在异常时，还需重复执行步骤213～214对应的内容，直至检测到目标产品无异常才结束异常修复操作。
基于前述实施例，在本申请其他实施例中，本申请实施例提供一种监控方法，包括：
步骤c11、存量规则判断是否出现跨服务区域，若跨服务区域，执行步骤c12，否则，执行步骤c14。
其中，跨服务区域的一种应用场景示意图可以参照图7所示，对应的存量规则可以记为Rac＝Ta1join Tc1；Rbc＝Tb1join Tc1，其中，Rac为服务区域1中的Ta1和服务区域2中的Tc1连接得到，实现了服务区域1和服务区域2的跨区域访问，同 理Rbc为服务区域1中的Tb1和服务区域2中的Tc1连接得到。在确定存量规则为跨服务区域的规则时，可以采用预设的标识信息对其进行标识，以便后续进行分析。
步骤c12、引擎初始化。
其中，确定存量规则对应的各个数据库后，对各个数据库的测试环境进行遍历，获取数据库(Data Base，DB)信息。DB信息至少包括测试环境、DCN区域、IP、Port、User、Password等信息。通常情况下，这些信息可以从配置管理数据库(Configuration Management Database，CMDB)的配置中心获取得到，在本地也进行存储时，可以直接从本地获取得到。
示例性的,跨服务区域的存量规则涉及1个应用程序数据管理(Application Data Management,ADM)区域和2个DCN区域，部署在不同服务区域DBSET1和DBSET2上时,对应的DB信息可以记为：DBSET1:源环境K,区域ADM,库glpdb，IP:10.1.1.1,PORT:3301,USER:user1，PASSWD:xxx，表T1；DBSET2：源环境K,区域DCN，库cpsdb，IP:10.1.1.2,PORT:3302,USER:user2，PASSWD:xxx，表T2。
步骤c13、通过引擎执行存量规则。
其中，首先，根据环境信息和DCN区域信息，创建federated引擎，其中，federated引擎包括用于决策的主(master)节点和与多个服务区域对应的从(slave)节点，同时，还根据环境信息和DCN信息，创建了federated引擎对应的federated表，其中，federated表的映射规则可以为源库名_源表名_区域名。在此过程中，federated引擎与存量规则对应的各数据库之间建立有映射关系。
其次，federated引擎根据存量规则和federated表生成不同的运行策略，步骤如下：
1)解析存量规则生成规则区域列表，得到federated表。例如，存量规则涉及的federated表中部分区域数据库如下表所示。
逻辑区域 虚拟区域 库 表
A1 A0 db1 T1
B1 B0 db2 T2
B2 B0 db2 T2
C1 C0 db3 T3
C2 C0 db3 T3
C1 C0 db4 T4
C2 C0 db4 T4
其中，T1表：表示在虚拟区域A0，该虚拟区域只有1个逻辑区域；T2表：表示在虚拟区域B0，该虚拟区域有2个逻辑区域；T3表和T4表：表示在同一虚拟区域C0,有两个不同服务数据库。
2)根据federated表生成运行策略。其中，生成运行策略包括：策略1、策略2和策略3；其中，策略1为同一虚拟区域，不同服务区域下，同一逻辑区域的组合，如T3和T4表进行join时，生成的组合有(C1,C1)和(C2,C2)；策略2为不同虚拟区域，不同服务区域下，需要分别进行逻辑区域的组合，如T2和T3表进行join时，生成的组合有(B1,C1)、(B1,C2)、(B2,C1)和(B2,C2)；策略3为如果该表对应的虚拟区域的逻辑区域只有1个，则只需进行1次组合，如T1表单独查询时，则生成的组合有(A1)。
3)基于运行策略，迭代替换存量规则，生成引擎可执行语句。
其中，在迭代替换存量规则，生成引擎可执行语句时，迭代替换的方式和federated表创建原则保持一致。示例性的，替换前的存量规则如下所示：
select count(1)from
(select a,b from db1.T1)t1
join
(select a,b from db2.T2)t2
on t1.a＝t2.a
where t1.c＝‘xx’；
对应的，替换后，按照策略组合拆分出2个组合(A1,B1)和(A1,B2)，两条规则对应的引擎可执行语句如下所示：
select count(1)from
(select a,b from fedlink_db1_A1.T1)t1
join
(select a,b from fedlink_db2_B1.T2)t2
on t1.a＝t2.a
where t1.c＝‘xx’；
select count(1)from
(select a,b from fedlink_db1_A1.T1)t1
join
(select a,b from fedlink_db2_B2.T2)t2
on t1.a＝t2.a
where t1.c＝‘xx’；
需说明的是，在生成引擎可执行语句时，需对存量规则涉及的每个虚拟区域的库表都进行遍历，直至生成所有策略组合对应的引擎可执行语句。
最后，federated引擎并行运行引擎可执行语句，实现存量规则的执行过程。
步骤c14、执行存量规则。
基于前述实施例，在本申请其他实施例中，federated引擎执行步骤c13之后， 还用于执行以下步骤：
步骤c15、每隔预设时间间隔检测存量规则是否更新，若存量规则存在更新，对federated引擎和federated表也进行同步更新，然后执行更新后的存量规则。
基于前述实施例，在本申请其他实施例中，federated引擎执行步骤c13或步骤c15之后，还用于执行以下步骤：
步骤c16、输出规则运行结果。
其中，federated引擎根据生成策略组合交分区域交叉展现，如果有任一组合运行结果不满足异常校验条件，则确定规则运行结果为规则检查失败。示例性的，上述拆分出的两个规则组合(A1,B1)和(A1,B2),如果(A1,B1)运行结果校验失败，(A1,B2)运行校验成功，则仍判定该存量规则校验失败。
步骤c17、如果规则运行结果为校验失败，确定至少一个异常数据规则。
首先，通过存量规则中涉及异常规则的表字段逐步迭代反关联查找出规则对应的关键字(KEY)。
其次，先进行单库多KEY提取，并查找单库中相似的关联规则。示例性的，假设跨服务区域的存量规则为R1，则对应的1)提取R1涉及的表列表T_num；2)如果T_num的数量为1，假设表列表T_num为T1时，查找表T1的关联主键、索引，然后反查该表列表T1所属的数据库下关联的所有关键字KEY、关联表和异常字段值列表集合，得到单库中的关联规则；如果T_num的数量大于1,则将规则R1拆分为多个子查询，如R1涉及表T1、T2和T3时，可以拆分为针对表T1、T2和T3的3个子查询规则，每个子查询获取关联规则的过程与T_num的数量为1时的过程相同。
示例性的，查找表T1的关联主键、索引，然后反查该表列表T1所属的数据库下关联的所有关键字KEY、关联表和异常字段值列表集合，得到单库中的关联规则的具体过程可以表示为：1)按照T1表反查出的关键字集合t:[k1，k2，k3]；2)根据关键字k集合和R1中的原始字段集合sc[c1,c2,c3]，异常字段集合c:[c1,c2]，查找规则库相似的关联规则涉及的关联表集合:[t1,t2,t3],其中，相似关联规则表判定方法为：①首先生成表链表，当前规则R1的T1作为顶点，②查找包含T1表的第一层关联规则节点列表L1r[R2,R3,…]，及其关联规则表取交集集合L1t[t1,t2,t3]，需说明的是，为了避免扫描全量规则库，查找关联规则链表的向下取的节点数等于初始T_num，如此重复，直到生成的表链表的节点都遍历完，关联规则判定查找完成，即可得到最终单库T1对应的关联规则为：{k：[k1，k2，k3]，t：[t1，t2，t3]，c:[c1，c2]}。
最后，对存量规则对应的多个数据库的关联规则取并集，得到最终的至少一个异常数据规则。
步骤c18、确定异常修复方式包括修数方式和清理方式。
步骤c19、确定至少一个异常数据规则对应的预设修复规则。
其中，查找规则库中，匹配k值的预设修复规则集合Rk，匹配t值的预设修复规规则集合Rt，再根据异常字段集合c{c1,c2}在Rk和Rt中过滤出单表T1的预设修复规则。示例性的，R1规则记为：SELECT COUNT(1)FROM cpsdb.T1 WHERE c1 IS NULL and c2＝0 AND c3＝'A'；对应的，R1规则对应的预设修复规则为：UPDATE cpsdb.T1set c1＝0,c2＝1 where c1 IS NULL and c2＝0 AND c3＝'A'；R1规则对应的预设修复规则表明的是在检测到c1为空、c2为0，c3为A时，将c1更新为0，c2更新为1。
步骤c20、在执行预设修复规则之前，为了保留现场或追溯异常场景，先将至少一条异常数据规则对应的异常数据进行备份。
步骤c21、执行至少一条异常数据规则对应的预设修复规则。
其中，执行至少一条异常数据规则对应的预设修复规则时，需确定是否关联影响到其他数据表，如果发现异常，继续重复步骤c17。优先执行步骤c19中确定得到的预设修复规则，直至最终确定得到的全部被预设修复规则执行后，使检测结果成功为止。
步骤c22、修数方式执行完成后，继续自动执行清理方式，直至清理方式执行完成后检测监控成功，本次异常数据修复完成，否则，重复执行步骤c17至c22。
需要说明的是，本实施例中与其它实施例中相同步骤和相同内容的说明，可以参照其它实施例中的描述，此处不再赘述。
本申请实施例中，通过确定用于对目标产品进行异常监控的待运行规则后，解析待运行规则，得到待访问数据库标识和待访问数据表标识，然后基于待访问数据库标识和待访问数据表标识，确定待运行规则的所属类型，若所属类型为目标类型，基于待访问数据库标识和待访问数据表标识，获取对应的至少一个目标数据库的数据库属性信息，基于数据库属性信息，生成目标引擎，并通过目标引擎，针对至少一个目标数据库执行待运行规则，以实现对目标产品的监控。这样，通过对用于进行监控的待运行规则进行解析后确定得到的待运行规则的所属类型，并在所属类型为目标类型时，根据待运行规则涉及的至少一个目标数据库的数据库属性信息生成目标引擎，以通过目标引擎来执行待运行规则，实现监控操作，解决了目前针对跨服务器跨数据库的监控过程的监控分析效率较低的问题，实现了一种实时对跨服务器跨数据库的监控方法，无需将数据从不同数据库中抽取至hive中，降低了运算资源的消耗，提高了监控分析过程的效率。
基于前述实施例，本申请的实施例提供一种监控设备，该监控设备可以应用于图1～6对应的实施例提供的监控方法中，参照图8所示，该监控设备3可以包括：处理器31、存储器32和通信总线33，其中：
存储器32，用于存储可执行指令；
通信总线33，用于实现处理器31和存储器32之间的通信连接；
处理器31，用于执行存储器32中存储的监控程序，以实现参照图1～6对应的实施例提供的方法实现过程，此处不再赘述。
基于前述实施例，本申请的实施例提供一种计算机可读存储介质，简称为存储介质，该计算机可读存储介质存储有一个或者多个程序，该一个或者多个程序可被一个或者多个处理器执行，以实现如图1～6对应的实施例提供的监控方法实现过程，此处不再赘述。
以上，仅为本申请的实施例而已，并非用于限定本申请的保护范围。凡在本申请的精神和范围之内所作的任何修改、等同替换和改进等，均包含在本申请的保护范围之内。
工业实用性
本申请实施例提供一种监控方法、设备以及存储介质，该方法包括：确定用于对目标产品进行异常监控的待运行规则；解析所述待运行规则，得到待访问数据库标识和待访问数据表标识；基于所述待访问数据库标识和所述待访问数据表标识，确定所述待运行规则的所属类型；若所述所属类型为目标类型，基于所述待访问数据库标识和所述待访问数据表标识，获取对应的至少一个目标数据库的数据库属性信息；基于所述数据库属性信息，生成目标引擎；通过所述目标引擎，针对至少一个所述目标数据库执行所述待运行规则，以实现对所述目标产品的监控，解决了目前针对跨服务器跨数据库的监控过程的监控分析效率较低的问题，实现了一种实时对跨服务器跨数据库的监控方法，无需将数据从不通过数据库中进行抽取至hive中，降低了运算资源的消耗，提高了监控分析过程的效率。

Claims (14)

  1. 一种监控方法，所述方法包括：
    确定用于对目标产品进行异常监控的待运行规则；
    解析所述待运行规则，得到待访问数据库标识和待访问数据表标识；
    基于所述待访问数据库标识和所述待访问数据表标识，确定所述待运行规则的所属类型；
    若所述所属类型为目标类型，基于所述待访问数据库标识和所述待访问数据表标识，获取对应的至少一个目标数据库的数据库属性信息；
    基于所述数据库属性信息，生成目标引擎；
    通过所述目标引擎，针对至少一个所述目标数据库执行所述待运行规则，以实现对所述目标产品的监控。
  2. 根据权利要求1所述的方法，其中，所述若所述所属类型为目标类型，基于所述待访问数据库标识和所述待访问数据表标识，获取对应的至少一个目标数据库的数据库属性信息，包括：
    若所述所属类型为目标类型，基于所述待访问数据库标识和所述待访问数据表标识，确定待访问的至少一个目标数据库；
    遍历至少一个所述目标数据库对应的测试环境，得到所述数据库属性信息。
  3. 根据权利要求1所述的方法，其中，所述基于所述数据库属性信息，生成目标引擎之后，所述方法还包括：
    基于所述数据库属性信息，生成与所述目标引擎对应的引擎数据表；其中，所述引擎数据表用于记录所述待运行规则对应的数据表的特征信息；
    对应的，所述通过所述目标引擎，针对至少一个所述目标数据库执行所述待运行规则，包括：
    通过所述目标引擎，基于所述引擎数据表，执行所述待运行规则。
  4. 根据权利要求3所述的方法，其中，所述通过所述目标引擎，针对至少一个所述目标数据库执行所述待运行规则之后，所述方法还包括：
    若按照预设时间间隔检测到所述待运行规则存在更新的情况，通过所述目标引擎基于更新后的所述待运行规则，更新所述引擎数据表；
    通过所述目标引擎记录更新所述引擎数据表的更新时间。
  5. 根据权利要求4所述的方法，其中，所述若按照预设时间间隔检测到所述待运行规则存在更新的情况，基于更新后的所述待运行规则，更新所述引擎数据表之后，所述方法还包括：
    通过所述目标引擎，基于更新后的所述引擎数据表，执行更新后的所述待运行规则。
  6. 根据权利要求3所述的方法，其中，所述通过所述目标引擎，基于所述引擎数据表，执行所述待运行规则，包括：
    通过所述目标引擎基于所述待运行规则和所述引擎数据表，生成运行策略；
    通过所述目标引擎基于所述运行策略，生成目标执行语句；
    通过所述目标引擎，执行所述目标执行语句，以实现所述待运行规则的执行。
  7. 根据权利要求6所述的方法，其中，所述基于所述待运行规则和所述引擎数据表，生成运行策略，包括：
    从所述引擎数据表中，确定属于同一服务区域下同一虚拟区域对应的至少一个数据库的至少一个第一数据表；
    基于所述待运行规则，对至少一个第一数据表进行组合，得到第一策略；
    从所述引擎数据表中，确定属于不同服务区域下，不同虚拟区域对应的至少一个数据库的至少一个第二数据表；
    基于所述待运行规则，对至少一个所述第二数据表进行组合，得到第二策略；
    从所述引擎数据表中，确定虚拟区域对应的服务区域只有1个的第三数据表；
    基于所述待运行规则，确定所述第三数据表为第三策略；其中，所述运行策略包括所述第一策略、所述第二策略和所述第三策略。
  8. 根据权利要求1至7任一项所述的方法，其中，所述通过所述目标引擎，针对至少一个所述目标数据库执行所述待运行规则之后，所述方法还包括：
    通过所述目标引擎，输出执行结果；其中，所述执行结果为所述目标引擎执行所述待运行规则得到的；
    若基于所述执行结果确定所述目标产品存在异常，通过所述目标引擎确定至少一个异常数据规则；
    通过所述目标引擎基于至少一个所述异常数据规则和预设异常修复方式，执行异常修复操作。
  9. 根据权利要求8所述的方法，其中，所述通过所述目标引擎基于至少一个所述异常数据规则和预设异常修复方式，执行异常修复操作，包括：
    通过所述目标引擎确定每一所述异常数据规则涉及的至少一个列表对象；
    通过所述目标引擎从至少一个所述目标数据库中确定每一所述列表对象具有关联关系的关联规则，得到目标关联规则；
    通过所述目标引擎基于至少一个所述异常数据规则和所述目标关联规则，得到待修复规则；
    通过所述目标引擎基于所述待修复规则和所述预设异常修复方式，执行异常修复操作。
  10. 根据权利要求9所述的方法，其中，所述通过所述目标引擎基于至少一个所述异常数据规则和所述目标关联规则，得到待修复规则，包括：
    通过所述目标引擎按照属于同一服务区域的规则分为一组的关系，对至少一个所述异常数据规则和所述目标关联规则进行分组，得到所述待修复规则。
  11. 根据权利要求9或10所述的方法，其中，所述通过所述目标引擎基于所述 待修复规则和所述预设异常修复方式，执行异常修复操作，包括：
    若所述预设异常修复方式为修数方式，通过所述目标引擎获取所述待修复规则对应的预设修复规则；
    通过所述目标引擎执行所述预设修复规则，以实现所述异常修复操作；
    若所述预设异常修复方式为清理方式，通过所述目标引擎执行针对所述待修复规则对应的数据清理操作；其中，所述异常修复操作包括所述数据清理操作；
    若所述预设异常修复方式包括所述修数方式和所述清理方式，通过所述目标引擎获取所述待修复规则对应的所述预设修复规则；
    通过所述目标引擎执行所述预设修复规则后，执行所述数据清理操作。
  12. 根据权利要求8所述的方法，其中，所述通过所述目标引擎基于至少一个所述异常数据规则和预设异常修复方式，执行异常修复操作之后，所述方法还包括：
    若监测到所述目标产品异常，通过所述目标引擎重复执行步骤“若基于所述执行结果确定所述目标产品存在异常，通过所述目标引擎确定至少一个异常数据规则”，直至测到所述目标产品正常，结束所述异常修复操作。
  13. 一种监控设备，所述设备包括：存储器、处理器和通信总线；其中：
    所述存储器，用于存储可执行指令；
    所述通信总线，用于实现所述处理器和所述存储器之间的通信连接；
    所述处理器，用于执行所述存储器中存储的监控程序，实现如权利要求1至12中任一项所述的监控方法的步骤。
  14. 一种存储介质，所述存储介质上存储有监控程序，所述监控程序被处理器执行时实现如权利要求1至12中任一项所述的监控方法的步骤。
PCT/CN2022/120541 2022-06-24 2022-09-22 一种监控方法、设备以及存储介质 WO2023245893A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202210731206.6A CN115129498A (zh) 2022-06-24 2022-06-24 一种监控方法、设备以及存储介质
CN202210731206.6 2022-06-24

Publications (1)

Publication Number Publication Date
WO2023245893A1 true WO2023245893A1 (zh) 2023-12-28

Family

ID=83380424

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/120541 WO2023245893A1 (zh) 2022-06-24 2022-09-22 一种监控方法、设备以及存储介质

Country Status (2)

Country Link
CN (1) CN115129498A (zh)
WO (1) WO2023245893A1 (zh)

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104008349A (zh) * 2014-04-28 2014-08-27 国家电网公司 数据库安全访问控制方法和系统
CN106371984A (zh) * 2016-08-31 2017-02-01 广州品唯软件有限公司 一种数据监控方法、设备和系统
CN107506451A (zh) * 2017-08-28 2017-12-22 泰康保险集团股份有限公司 用于数据交互的异常信息监控方法及装置
CN111259036A (zh) * 2020-01-10 2020-06-09 苏州达家迎信息技术有限公司 一种跨库跨表查询方法、设备、服务器及存储介质
CN112052138A (zh) * 2020-08-31 2020-12-08 平安科技（深圳）有限公司 业务数据质量检测方法、装置、计算机设备及存储介质
CN112231181A (zh) * 2020-12-08 2021-01-15 平安科技（深圳）有限公司 数据异常更新检测方法、装置、计算机设备及存储介质
US20210042302A1 (en) * 2019-08-09 2021-02-11 Couchbase, Inc. Cost-based optimization for document-oriented database queries
CN113157671A (zh) * 2021-05-17 2021-07-23 深圳前海微众银行股份有限公司 一种数据监控方法及装置
CN113868288A (zh) * 2021-10-12 2021-12-31 北京家源树科技有限公司 一种基于引擎驱动的数据库解析技术
CN114328119A (zh) * 2021-12-31 2022-04-12 深圳昂楷科技有限公司 一种数据库监控方法、系统以及服务器

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104008349A (zh) * 2014-04-28 2014-08-27 国家电网公司 数据库安全访问控制方法和系统
CN106371984A (zh) * 2016-08-31 2017-02-01 广州品唯软件有限公司 一种数据监控方法、设备和系统
CN107506451A (zh) * 2017-08-28 2017-12-22 泰康保险集团股份有限公司 用于数据交互的异常信息监控方法及装置
US20210042302A1 (en) * 2019-08-09 2021-02-11 Couchbase, Inc. Cost-based optimization for document-oriented database queries
CN111259036A (zh) * 2020-01-10 2020-06-09 苏州达家迎信息技术有限公司 一种跨库跨表查询方法、设备、服务器及存储介质
CN112052138A (zh) * 2020-08-31 2020-12-08 平安科技（深圳）有限公司 业务数据质量检测方法、装置、计算机设备及存储介质
CN112231181A (zh) * 2020-12-08 2021-01-15 平安科技（深圳）有限公司 数据异常更新检测方法、装置、计算机设备及存储介质
CN113157671A (zh) * 2021-05-17 2021-07-23 深圳前海微众银行股份有限公司 一种数据监控方法及装置
CN113868288A (zh) * 2021-10-12 2021-12-31 北京家源树科技有限公司 一种基于引擎驱动的数据库解析技术
CN114328119A (zh) * 2021-12-31 2022-04-12 深圳昂楷科技有限公司 一种数据库监控方法、系统以及服务器

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
YANG HUI, DING ZHIGANG, ZHENG SHUQUAN: "DESIGN AND IMPLEMENTATION OF A RULE-BASED MESSAGE PROCESSING ENGINE", JISUANJI-YINGYONG-YU-RUANJIAN : SHUANGYUEKAN COMPUTER APPLICATIONS AND SOFTWARE, SHANGHAI : SHANGHAISHI JISUAN JISHU YANJIUSUO, CN, vol. 30, no. 10, 15 October 2013 (2013-10-15), CN , pages 67 - 70, XP093120743, ISSN: 1000-386X, DOI: 10.3969/j.issn.1000-386x.2013.10.018 *

Also Published As

Publication number Publication date
CN115129498A (zh) 2022-09-30

Similar Documents

Publication Publication Date Title
CA2562281C (en) Partial query caching
US10073885B2 (en) Optimizer statistics and cost model for in-memory tables
US7877376B2 (en) Supporting aggregate expressions in query rewrite
US8676821B2 (en) Summary filter transformation
CN109559231B (zh) 一种面向区块链的追溯查询方法
Aboutorabiª et al. Performance evaluation of SQL and MongoDB databases for big e-commerce data
US10769147B2 (en) Batch data query method and apparatus
US8423569B2 (en) Decomposed query conditions
US20070156736A1 (en) Method and apparatus for automatically detecting a latent referential integrity relationship between different tables of a database
US20130346429A1 (en) Systems and Methods for Analyzing Existing Data Models
US20180144004A1 (en) Global column indexing in a graph database
CN110659327A (zh) 实现异构数据库之间数据交互式查询的方法和相关装置
US20140250040A1 (en) Correlating data from multiple business processes to a business process scenario
US20140019454A1 (en) Systems and Methods for Caching Data Object Identifiers
WO2024021362A1 (zh) 一种流量回放的数据验证方法及装置
US7908267B2 (en) Automatic use of a functional index as a primary filter
WO2021031583A1 (zh) 执行语句的方法、装置、服务器及存储介质
CN113934750A (zh) 基于编译方式的数据血缘关系分析方法
US7693845B2 (en) Database systems, methods and computer program products using type based selective foreign key association to represent multiple but exclusive relationships in relational databases
US20070033178A1 (en) Quality of service feedback for technology-neutral data reporting
WO2023245893A1 (zh) 一种监控方法、设备以及存储介质
US8548980B2 (en) Accelerating queries based on exact knowledge of specific rows satisfying local conditions
US20220215021A1 (en) Data Query Method and Apparatus, Computing Device, and Storage Medium
CN114090558A (zh) 针对数据库的数据质量管理方法和装置
US20210034616A1 (en) Query optimization

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22947633

Country of ref document: EP

Kind code of ref document: A1