Data Acquisition Method and Related Devices Based on Event-Message-Driven Relational Database

Abstract

This invention relates to the field of data processing technology and discloses a data acquisition method and related apparatus based on an event message-driven relational database. The method includes: performing statistical feature analysis on the metadata flow of database change operations to establish a normal baseline model of data change behavior; when the current data change behavior pattern deviates from the baseline model without receiving external business event messages, actively saving a context snapshot containing metadata; and collecting complete fault diagnosis data based on this snapshot. This invention can capture and save causal evidence of latent faults that do not trigger business alarms, extending diagnostic capabilities from passive responses to known faults to proactive perception and evidence preservation of system logical health.

Description

Technical Field

[0001] This invention relates to a data acquisition method and related apparatus based on an event message-driven relational database, belonging to the field of data processing technology. Background Technology

[0002] Currently, in large-scale industrial equipment monitoring systems, such as steam turbine generator diagnostic monitoring and management systems, relational databases are typically used to structure and store measurement point data, equipment ledgers, operation records, and alarm information. This approach provides effective support for data management and routine queries. When a monitoring indicator in the system exceeds a preset threshold and triggers an alarm event, a common approach is to query and retrieve records from one or more predefined data tables within a specified time period before and after the alarm event, based on the timestamp of the alarm event, for fault cause tracing analysis. In complex industrial systems, the actual cause of an alarm event may be the result of a series of discontinuous state changes distributed across different data tables, which, after transmission and accumulation, work together. In this case, the aforementioned tracing method relying on predefined data table ranges has limitations. Since it is impossible to predict in advance which data tables a specific fault will be associated with, data retrieval can only be based on experience and speculation. The resulting dataset is essentially an incomplete subset of the fault's preceding process, leading to the omission of many data rows containing key information because the data tables they belong to were not pre-specified.

[0003] Meanwhile, existing diagnostic methods not only contradict the completeness and economy of data acquisition, but their diagnostic logic also relies heavily on passive responses to physical quantity monitoring indicators, lacking the ability to proactively perceive the root causes of faults. For example, Chinese invention patent CN110553821A discloses a visual diagnostic method and system for turbine generator set faults. This method acquires unit operating parameters and vibration data to establish a benchmark vibration vector for all operating conditions, and then compares the real-time vibration vector with it. When the difference exceeds a preset fault limit, a fault is determined to have occurred. The essence of this method is a delayed and passive fault confirmation mechanism. Its diagnostic trigger point is the manifestation of the physical result of vibration abnormality. However, it cannot proactively perceive or capture the series of preceding events that lead to this result, such as subtle state changes at the database level (e.g., background configuration errors, slow modification of protection settings). Such methods cannot solidify the causal evidence chain of hidden faults that do not trigger business alarms. Their diagnostic capability remains at the level of passive response to known faults, rather than proactive perception and evidence preservation of the system's logical health.

[0004] One direct approach to improvement is to expand the scope of continuous monitoring and data backup, such as capturing and dumping all changed data in the database in real time. However, this method impacts the performance of the production database system, and during most of the system's normal operation, the collected and stored data has no immediate diagnostic value, resulting in continuous occupation of storage and computing resources. This approach struggles to balance diagnostic completeness with system operating costs. Existing technologies have the following problems in application: 1. The data integrity for fault tracing relies on prior estimation of the relevant data table range, making it impossible to guarantee the capture of key event information in non-predefined data tables; 2. The routine full-data continuous backup method has excessively high system operating overhead and resource costs, making it impractical in engineering practice. Therefore, the technical problem this invention aims to solve is how to accurately and completely trace back and solidify all records in the entire relational database that have undergone state changes before an asynchronous alarm event occurs, without increasing the burden of routine system operation, in order to form a diagnostic dataset with transactional consistency. Summary of the Invention

[0005] This invention provides a data collection method and related apparatus based on an event message-driven relational database. Its main purpose is to solve the problems of incomplete data due to prior table range estimation during fault tracing in existing technologies, or excessive system costs due to full continuous backup.

[0006] To achieve the above objectives, this invention provides a data collection method based on an event-message-driven relational database, comprising the following steps: Step a: Monitor data change operations in the relational database in real time, extract metadata related to the data change operations that contains only index information, and continuously write the metadata into a pre-set size circular log maintained in memory to form a real-time updated metadata stream. Step b: Continuously analyze the statistical characteristics of the meta-information flow, and establish a baseline model of data change behavior representing the preset normal state of the relational database based on the analysis results; Step c: When it is determined that the current data change behavior pattern deviates from the data change behavior baseline model and no external event message indicating the occurrence of a key business event is received, actively trigger snapshot solidification: extract all metadata entries in the circular log within the preset time window associated with the deviation time point, and solidify these metadata entries as the first context snapshot; Step d: Based on the table name and primary key contained in the first context snapshot, query and retrieve the complete data of the corresponding data row from the relational database to form a target dataset associated with the deviation event of data change behavior pattern; this target dataset is used for fault diagnosis of the relational database.

[0007] Furthermore, the steps for obtaining metadata also include: determining whether a data change operation is a high-risk operation according to predefined rules; when it is determined to be a high-risk operation, the metadata written to the circular log also includes the complete data of the data row before and after the change; if the metadata entry of the first context snapshot contains complete data, it is extracted directly from it without initiating a query to the relational database. The statistical characteristics of the meta-information flow include at least two categories: the first category is the association between the database transaction identifier and the operated data table within the sliding time window; the second category is the distribution of data change operations on different data tables.

[0008] The deviation from the data change behavior pattern is determined by calculating the probability distribution difference: a measure of the difference between the current data change behavior pattern and the baseline model is calculated. Preset trigger threshold When satisfied When this occurs, it is determined to be a pattern deviation; Complete data retrieved from a relational database query needs to be stored in a dedicated database schema, which is specifically created for the analysis of events that deviate from the data change behavior pattern. After obtaining the target dataset, semantic verification is performed. Specifically, the data in the target dataset is verified based on a set of predefined semantic rules, and a corresponding verification report is generated. The verification report identifies the data points in the target dataset that do not conform to the semantic rules and the specific semantic rules violated by the data points. Among them, the semantic rules are related to the business logic and physical constraints of the relational database.

[0009] Furthermore, in the step of obtaining metadata, the predefined rules include two types of data change operation judgment conditions; The first category is update operations performed on the system configuration table or permission table; The second category is operations where the number of data rows deleted exceeds a preset threshold in a single database transaction.

[0010] Furthermore, it also includes additional target datasets, specifically: Receive external event messages triggered by external systems that indicate the occurrence of critical business events; In response to the external event message, based on the time of the message occurrence, all metadata entries within a preset time window are determined from the circular log, and the metadata entries are solidified as a second context snapshot. Extract table names and primary key information from the second context snapshot. Based on the table names and primary keys, query and retrieve the complete data of the corresponding data rows from the relational database to form an additional target dataset associated with key business events.

[0011] Furthermore, the process between receiving external event messages and responding to external event messages also includes: In response to the first received external event message, an aggregation window of a preset duration is started. During the existence of the aggregation window, all received external event messages are temporarily stored. After the aggregation window ends, analyze the metadata associated with the temporary external event messages in the loop log, and determine whether the external event messages are associated with the same database transaction identifier or the same data entity primary key based on the metadata. Based on the above determination results, it is confirmed whether there is a causal relationship between the temporarily stored external event messages; All steps related to responding to external event messages are executed based on the above causal relationship determination results: if a causal relationship is determined, the multiple temporarily stored external event messages are merged into a single triggering event; for the merged single triggering event, a unified second context snapshot is fixed, which covers the time range of all related external event messages.

[0012] Furthermore, real-time monitoring of data change operations in relational databases also includes: periodically monitoring whether real-time monitoring data change operations are executed normally; if a failure is detected in the real-time monitoring operation and subsequent recovery is completed, checking whether any external event messages were published during the failure period; if there are published external event messages during the failure period, triggering a compensatory data collection to collect all data from all modified data tables during the failure period; the compensatory data collection is based on the timestamps of the external event messages for querying. The specific methods for writing metadata to the circular log are as follows: monitor the actual time span that the circular log can cover, and determine whether the time span is lower than the preset minimum time window threshold; if it is lower than the threshold, dynamically adjust the method of writing metadata to the circular log: the first adjustment method is to merge the records of multiple operations on the same data table to reduce storage usage; the second adjustment method is to transfer the oldest part of the metadata in the circular log from memory to persistent storage. This invention also provides a data acquisition system based on an event message-driven relational database, comprising: The metadata acquisition module is used to monitor data change operations in relational databases in real time, extract metadata related to data change operations that contains only index information, and continuously write the metadata into a pre-set size circular log maintained in memory to form a real-time updated metadata stream. The baseline modeling module is used to continuously analyze the statistical characteristics of the meta-information flow and establish a baseline model of data change behavior representing the preset normal state of the relational database based on the analysis results. The abnormal behavior determination module is used to proactively trigger snapshot solidification when the current data change behavior pattern deviates from the data change behavior baseline model and no external event message indicating the occurrence of a key business event is received: extract all metadata entries in the circular log within a preset time window associated with the deviation time point, and solidify these metadata entries as the first context snapshot; The dataset generation module is used to query and retrieve the complete data of the corresponding data rows from the relational database based on the table names and primary keys contained in the first context snapshot, forming a target dataset associated with the deviation event of data change behavior pattern; this target dataset is used for fault diagnosis of relational databases.

[0013] The present invention also provides a terminal device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described event message-driven relational database acquisition method.

[0014] The present invention also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of the above-described data acquisition method based on an event message-driven relational database.

[0015] The present invention also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the above-described event message-driven relational database acquisition method.

[0016] Compared with the prior art, the beneficial effects of the present invention are: This invention provides a data acquisition method based on event message-driven relational databases. By monitoring data changes in the relational database in real time and writing operation metadata into a preset log, upon receiving a key event message, a context snapshot containing the aforementioned metadata is created in response to the message. Finally, based on the table names and primary key information in the snapshot, a query is performed from the database to obtain the complete corresponding data. This approach changes the process of forming fault diagnosis data. Instead of delivering a subset of data tables selected based on pre-speculation, it delivers a dataset of entities with complete transaction relationships, determined by the actual database transaction history and containing all state changes that occurred within a specified time window before the event. This allows the tracing of fault causes to be based on the complete reproduction of the actual data causal chain, rather than on the correlation analysis of discrete data fragments.

[0017] Furthermore, upon receiving the first event message, a pre-defined aggregation window is initiated, and all subsequent event messages are temporarily stored within the window. Simultaneously, log metadata associated with these stored events is analyzed to determine whether there is a causal relationship between the events based on database transactions or manipulated data entities. Through this mechanism, when faced with dense concurrent alarm events, this method can merge multiple event messages originating from the same physical fault chain and perform only one unified context collection action covering the entire fault evolution process. This avoids generating redundant and fragmented data snapshots for each independent alarm, transforming the originally discrete event point information into a coherent dataset with inherent logical consistency regarding the fault propagation process. This allows the diagnostic focus to be directly concentrated on the complete narrative chain of the fault, rather than discrete event fragments.

[0018] Furthermore, this method performs continuous statistical feature analysis on the metadata stream written to the log in real time, and judges whether the data change behavior pattern of the database deviates from the normal baseline based on the analysis results. By analyzing, for example, the relationship between transactions and data tables or the distribution of change operations on different data tables, this method can identify abnormal states at the system logic level without receiving alarms from external business systems, and actively trigger the solidification of context snapshots. This allows this method to capture and solidify causal evidence of destructive operations that are slow in process and do not trigger clear business thresholds, extending the diagnostic capability from a passive response to declared faults to an active perception and evidence preservation of abnormal system behavior patterns. Attached Figure Description

[0019] Figure 1 This is a flowchart illustrating the overall process of the data acquisition method combining active sensing and passive response according to the present invention. Figure 2 This is a quantitative comparison chart showing how the data change behavior of the present invention deviates from the normal baseline model. Figure 3 This is a timing diagram for the aggregation and unified context acquisition of dense alarm events in this invention. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the present invention clearer, the present invention will be described in further detail below. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0021] This invention provides a data acquisition method based on an event-message-driven relational database. When applied to a steam turbine generator diagnostic monitoring and management system, the system configuration mainly includes a log capture agent, a memory circular log, an analysis module, and a data acquisition service. The log capture agent connects to the production database via a non-intrusive interface. The memory circular log is deployed in the agent's memory. The analysis module is used to establish a baseline for data change behavior patterns, while the data acquisition service is deployed independently. During runtime, the log capture agent monitors data change operations in the production database in real time, generates a metadata stream containing only index information, and continuously writes this metadata stream to the memory circular log. The analysis module analyzes the statistical characteristics of the metadata stream to identify abnormal behavior patterns at the system level when there are no external alarms. After receiving the context snapshot frozen by the log capture agent, the data acquisition service queries the production database based on the snapshot content and obtains complete row data, ultimately forming a target dataset with transactional consistency for fault diagnosis. In a specific application scenario, the relational database is a production database used to store the operating conditions of the steam turbine generator set. During its operation, there are... The technical problem is how to provide a complete data causal chain within a sufficient time window before an occasional alarm event, such as indicating excessive vibration of the unit, occurs, without affecting the high-concurrency write performance of the unit's real-time monitoring data. To solve this technical problem, the method of this invention is configured to execute step a, which uses a log capture agent to monitor data change operations such as INSERT, UPDATE, and DELETE in the relational database in real time using the database's own logical replication slot function. For each database transaction, it captures the transaction identifier, transaction commit timestamp, the name of the data table where the operated data row is located, the primary key of the row, and the specific operation type. This metadata, which only contains index information, is continuously written into a circular log with a preset size of 512MB maintained in memory to form a real-time updated metadata stream. Since each metadata entry only occupies tens of bytes, this circular log can completely cover tens of millions of data changes that occur in a high-load system within 15 minutes with low system resource consumption. Thus, a dynamic index of all data changes is constructed without interfering with the reading and writing of the main business data.

[0022] To capture potential faults that are slow-moving and do not trigger explicit business thresholds, such as the continuous and slow modification of protection settings for critical measurement points due to backend configuration errors, the method of this invention is configured to execute steps b and c. Specifically, an analysis module continuously analyzes the statistical characteristics of the aforementioned metadata flow to establish a baseline model representing the data change behavior of a relational database under a preset normal state. The statistical characteristics here specifically refer to the association between database transaction identifiers and the operated data tables recorded within a 60-second sliding time window, as well as the distribution of data change operations across different data tables. For example, during normal system operation, through 24 hours of continuous data learning, the analysis module can define a baseline model characterized by: 95% of transactions only associating with real-time and historical measurement point tables, and the proportion of DELETE operations being less than 0.1%. Correspondingly, after the system enters real-time monitoring, the analysis module continuously calculates the probability distribution difference between the current data change behavior pattern and the data change behavior baseline model. Specifically, a difference measure is obtained using Kullback-Leibler divergence. And set a trigger threshold. ,in The rule is used to determine the occurrence of deviation, where, This is a measure of difference obtained by calculating the probability distribution difference between the current data change behavior pattern and the baseline model of data change behavior. This is a preset trigger threshold; the calibration procedure for this threshold is as follows: during the baseline model learning phase, record all calculated... The value was used, and its 99.9 percentile was taken as the final value. For example, setting When determining the current When the value meets the rule, for example, due to an unauthorized batch data cleanup task, the proportion of DELETE operations rises to 10% within the window period, resulting in the calculated... If the value is 1.2, the system determines that the current data change behavior pattern has deviated from the baseline model. Without receiving an external event message indicating the occurrence of a critical business event, the system proactively saves and dumps all metadata entries in the circular log within a preset time window (e.g., 600 seconds before the deviation point) associated with the time point of deviation of the data change behavior pattern as a first context snapshot. By using the abnormality of the data change behavior pattern itself as a trigger signal, this method can proactively perceive and preserve the state of the system's logical layer.

[0023] Meanwhile, to address clear business-layer faults, the method of this invention is also configured to receive an external event message triggered by an external system, indicating the occurrence of a critical business event. For example, when the vibration monitoring module determines that the vibration intensity of bearing No. 1 exceeds the alarm threshold, it will send an external event message containing the event type and the time of occurrence to the message middleware. After receiving the external event message, the log capture agent will respond to the message and, based on its occurrence time, such as 09:30:00 on XX / XX / 20XX, determine all metadata entries within a preset time window from the cyclic log, such as 09:15:00 to 09:30:00, and solidify these metadata entries as a second context snapshot. In systems such as steam turbine generator sets, an initial physical fault often triggers a series of chain alarms. To avoid repeated data collection for these related events, this method also sets up an alarm event aggregation and delayed triggering procedure between receiving the external event message and solidifying the snapshot. The specific steps are as follows: when the log capture agent receives the first alarm event at 09:30:00... When an external event message indicating that the vibration of bearing No. 1 exceeds the limit is received, a snapshot is not immediately saved. Instead, an aggregation window with a preset duration of 3 seconds is started, and all subsequently received external event messages are temporarily stored in this window. For example, a message indicating low lubricating oil pressure is received at 09:30:01. After the aggregation window ends at 09:30:03, the analysis module analyzes the metadata before and after the time points of these two external event messages to determine whether they are associated with the same database transaction identifier or the same data entity primary key. If the analysis finds that an UPDATE operation for the same primary key ID in the unit master parameter table appears in the metadata near the time points of the two events, it is determined that the two external event messages are causally related. Accordingly, the step of saving the second context snapshot will be executed based on this determination result, that is, the two external event messages are merged into a single triggering event, and a unified second context snapshot covering the entire time range from 09:15:00 to 09:30:01 is saved. This procedure transforms discrete event point information into a coherent dataset about the fault propagation process.

[0024] After the first or second context snapshot is fixed, an independent data acquisition service is triggered and begins executing step d, which involves initiating a series of SELECT queries to the relational database based on all table names and primary keys contained in the snapshot to obtain the complete data for the corresponding data rows. To ensure the integrity and transaction consistency of the diagnostic data, the obtained complete data is stored in an isolated database schema specifically created for the analysis of data change behavior pattern deviation events or key business events, thus forming a target dataset associated with the specific event for fault diagnosis. It should be noted that, to address the issue of the database itself running out of storage space... To mitigate the risk of data becoming inaccessible due to various reasons, this method includes a risk response mechanism in step a. This mechanism predefines a set of high-risk operation rules, such as any update operation to the system configuration table or permission table, and operations that delete more than 1000 data rows in a single database transaction. When the log capture agent detects a data change operation that matches these rules, in addition to recording its standard metadata, it immediately queries and captures the complete data of the affected data rows before and after the change from the database, and writes this entity data along with the metadata into the circular log. Correspondingly, when the data acquisition service executes step d, if it finds data in the snapshot... If a metadata entry already contains complete data, it is extracted directly from that entry without needing to query a potentially unresponsive relational database. This mechanism ensures the integrity of core diagnostic evidence in specific risk scenarios. When performing causal correlation determination for alarm event aggregation, the analysis module sets a metadata search window with a radius of 500 milliseconds, centered on the timestamp recorded in the message header, for each external event message. It then searches only within this window for database transaction identifiers and data entity primary keys recorded in the circular log. The radius of this window is determined based on the end-to-end network between the business system and the database server during the system deployment phase. The communication delay is determined by multiple measurements to determine the maximum round-trip time. For capturing complete data before and after changes in high-risk operations, the log capture agent parses the transaction content output by the logical replication slot. Before the database transaction commit instruction is received, it identifies that the transaction contains high-risk operations and extracts the primary key of the data row being operated on. Then, it uses the primary key to initiate a snapshot read query to the database to obtain the data row before the change before the current transaction started. The changed data is obtained directly from the transaction content. This metadata entry containing the data before and after the change is written to the memory circular log only after the final commit confirmation message of the transaction is received.

[0025] Example 1: This embodiment describes the specific application of a data acquisition method based on an event message-driven relational database in a large-scale steam turbine generator diagnostic monitoring and management system. In this continuously operating system, the relational database stores dozens of data tables recording measurement point data, equipment ledgers, operation records, and alarm information. At 09:30:00 on [Date], the monitoring system sends an external event message to the message middleware, indicating that the vibration intensity of bearing number one exceeds a preset alarm threshold. The operations engineer then uses the timestamp of the alarm event to capture data records from the vibration sensor real-time value table and the unit main parameter table for the 15 minutes prior to the alarm, i.e., from 09:15:00 to 09:30:00. However, analysis of these two data tables did not reveal any abnormal operating conditions that could cause the vibration to exceed the limit. Meanwhile, the log capture agent in this invention, due to its... Subscribed to the same topic of the message middleware also received this external event message at 09:30:00. The agent then did not execute a database query, but instead solidified the circular log maintained in memory, which recorded all database transaction metadata from 09:15:00 to 09:30:00, as a second context snapshot, and passed this snapshot to the independent data acquisition service. This solidification action effectively separated the real-time metadata monitoring step, which has a very low impact on system performance under normal operating conditions, from the data entity acquisition step, which is only started after a failure occurs. This resolved the technical contradiction between the completeness of diagnostic data and the overhead of normal system operation. After receiving the second context snapshot, the data acquisition service no longer depends on the predefined table range, but is uniquely determined by the index information of all data rows that have actually changed within the 15-minute window before the failure, as recorded in the snapshot.

[0026] The data acquisition service parses the second context snapshot and identifies that within the aforementioned 15-minute window, in addition to the vibration sensor real-time value table and the unit main parameter table, several other data tables have also undergone data changes. Specifically, these include: an INSERT operation with primary key 85742 in the operation log table at 09:17:25; an UPDATE operation with primary key CFG_1021 in the lubricating oil pressure sensor configuration table at 09:18:40; an UPDATE operation with primary key P_OIL_03 in the sensor real-time value table at 09:21:05; and an UPDATE operation with primary key AUX_PUMP_02 in the equipment status table at 09:28:15. The data acquisition service then uses this series of indexes composed of metadata to access the relational database. A precise SELECT query was initiated, and the four complete rows of data belonging to four different data tables were stored together with the data previously collected in the conventional way into a database schema specifically created for this vibration over-limit event. The final product delivered to the operations engineer was a target dataset containing all the data that had undergone state changes, spanned multiple tables, and had transactional relationships within a specific time window before the failure. By performing correlation queries on this dataset, the engineer was able to reconstruct the complete fault propagation chain: an operator performed a routine lubrication circuit switching operation, after which the low-pressure alarm threshold of the circuit was temporarily lowered due to a background configuration error. Subsequently, the pressure of the circuit experienced an abnormal fluctuation that did not trigger an alarm. Finally, the start-up and shutdown of another related device caused pipeline resonance. These events together led to the bearing vibration exceeding the limit.

[0027] Example 2: To objectively verify the technical effectiveness of the method of the present invention in terms of the integrity of fault data acquisition and system resource consumption, this embodiment builds an experimental platform to simulate the actual operating conditions of a real steam turbine generator diagnostic monitoring and management system, and designs a test group using the method claimed in this invention and a control group using the prior art for comparative testing.

[0028] The experimental platform was built on a server equipped with an Intel Xeon E5-2680v4 processor, 128GB of memory, and an NVMe solid-state drive. This server hosted a PostgreSQL relational database to simulate a production database and a RabbitMQ message middleware. The database contained 38 pre-created tables, including real-time measurement point tables, historical measurement point tables, operation log tables, equipment status tables, and various configuration tables. During the experiment, a data load generation script was used to simulate the database write pressure during normal operation of the steam turbine generator. This script concurrently wrote data to the real-time measurement point table at a rate of 5000 transactions per second and randomly wrote to other data tables at a frequency of 1 to 5 times per minute. The test group was configured to deploy the log capture agent of the present invention, which uses PostgreSQL's logical decoding function to monitor all data change operations in real time and write metadata into a 512MB memory circular log. The control group was configured to use a polling collection method commonly used in the prior art, that is, to use a script to query and dump the full data of the real-time measurement point table and the unit master parameter table at a fixed period of 10 seconds. The core parameter of the test, namely the fault injection window, was set to 15 minutes. The choice of this duration is to balance the backtracking time depth required for fault diagnosis with the execution efficiency of the simulation test. 15 minutes is a typical time window recognized in this field that can cover most fault propagation processes.

[0029] The experimental process is as follows: After the data load generation script started and ran stably, a 15-minute test run was performed on both the experimental group and the control group. During this period, a fault injection script would write four key data changes that led to the final fault to the database at preset time points, following the fault propagation chain in Example 1. At the end of the 15-minute test window, an external event message indicating that the vibration of bearing No. 1 exceeded the limit was published through the message middleware. During the entire test run, the average CPU utilization and average disk write rate of the database server were continuously recorded at a sampling interval of 1 second using the operating system monitoring tool. After the test, the performance of the experimental group and the control group on three core indicators were statistically analyzed and compared, namely, diagnostic data integrity, system resource overhead, and data storage overhead. Diagnostic data integrity was defined as the ratio of the number of key data changes collected to the total number of the four key data changes actually injected. Specific experimental data are shown in Table 1.

[0030] Table 1: Comparison of performance indicators between the experimental group and the control group.

[0031]

[0032] Analysis of the data in Table 1 shows that the experimental group achieved 100% completeness in diagnostic data. This is because the data acquisition service queries data based on a context snapshot containing all transaction records within the window period. Therefore, the four key changes involved in Example 1, distributed across the operation log table, sensor configuration table, sensor real-time value table, and device status table, were all collected. The control group, however, had 0% completeness because its collection scope was pre-limited to two data tables, thus omitting all key information occurring in other data tables. Regarding system resource consumption, the experimental group, within a 15-minute monitoring cycle, consumed less CPU and less resources from the database server. The disk write load was much lower than that of the control group, indicating that the method of recording only metadata in this invention has a smaller normal operating overhead. In terms of data storage overhead, the experimental group did not need to continuously dump any business data before fault analysis. Only after receiving external event messages did it generate a target dataset of 3.2MB containing only relevant change data. In contrast, the control group accumulated 859MB of data within 15 minutes. The experimental results show that using the method of this invention for data collection can provide a more complete data context for asynchronously triggered fault events than existing technologies without excessively consuming production system resources.

[0033] To further illustrate the inherent limitations of existing technical solutions from the perspective of engineering practice in fault diagnosis, the following comparative examples are provided.

[0034] Comparative Example 1: To objectively verify the technical advantages of the method claimed in this invention in dealing with complex fault chains, this comparative example was set up. The test environment, data load generation script, fault injection window duration (15 minutes), and fault injection script of this comparative example are completely consistent with the test platform and test conditions in the aforementioned Example 2 to ensure the fairness of the comparison. The core difference of this comparative example is that it adopts a typical data acquisition scheme in the prior art, based on fixed-period polling and preset table range. This scheme aims to simulate the fault tracing method in the background technology that relies on prior inference of the relevant data table range. Specifically, it is configured as follows: through a data acquisition script, with a fixed acquisition cycle of 10 seconds, the full data is continuously processed on the real-time measurement point table and the unit main parameter table. According to the query, the query results were dumped to a local diagnostic database. The test process is as follows: After the data load generation script started and ran stably, the data acquisition script of this comparative example was started, and a test run lasting 15 minutes was executed synchronously. During this period, the fault injection script, which is the same as in Example 2, wrote four key data changes that caused the vibration of the final bearing to exceed the limit across different data tables to the database at preset time points, according to the fault propagation chain in Example 1. At the end of the 15-minute test window, the external event message was published through the message middleware. After the test, the performance of this comparative example in the three core indicators of diagnostic data integrity, system resource overhead and data storage overhead was statistically analyzed. The results and analysis are shown in the table below.

[0035] Table 2: Performance index statistics for Comparative Example 1.

[0036]

[0037] The test results show that the typical polling data collection scheme in the existing technology has limitations in its technical principle due to the in advance prediction of the range of fault-related data tables. When faced with unexpected and complex fault chains that span multiple tables, it is unable to collect complete diagnostic data, resulting in the failure of root cause analysis.

[0038] Example 3: This embodiment combines Figures 1 to 3 This section describes a data collection method based on an event-message-driven relational database, such as... Figure 1As shown, the process begins with real-time monitoring and metadata recording of a relational database, such as a steam turbine monitoring system production database. Meta-information of change operations is written to a memory loop log. Subsequently, the method executes along two parallel logical paths: one is the proactive perception and evidence preservation path, which uses a data change behavior baseline model analysis module to continuously analyze the metadata flow and determine whether the current behavior pattern deviates from the baseline. If so, a context snapshot is proactively fixed. The other is the passive response and fault tracing path, which triggers an alarm event aggregation procedure when external event messages, such as alarm events, are received from external business systems. This procedure aims to integrate densely concurrent events with causal relationships and subsequently fixes a unified context snapshot. The outputs of both paths, the fixed context snapshots, are passed to the next step for fault diagnosis data collection. This step queries complete row data based on table names and primary key information in the snapshot, forming a target dataset with transactional consistency for fault diagnosis. Selectively, data semantic verification is performed on this dataset according to business logic rules, ultimately generating a verification report.

[0039] like Figure 2 As shown in the figure, the bar chart compares the percentage of data change operations on different data tables, such as the real-time measurement point table, historical measurement point table, operation log table, device status table, and configuration table, under normal and abnormal distribution conditions. Under the normal distribution condition, most operations are concentrated on the real-time measurement point table, while under the abnormal distribution condition, the proportion of operations on the real-time measurement point table decreases, while the proportion of operations on low-frequency change tables such as the operation log table, device status table, and configuration table increases significantly.

[0040] like Figure 3 As shown, this process involves the interaction of five core components: message middleware, log capture agent, analysis module, memory circular log, and data acquisition service. When the log capture agent receives the first external event message from the message middleware, it starts an aggregation window of a preset duration and temporarily stores all subsequent event messages received during this period. After the aggregation window ends, the log capture agent requests the analysis module to perform correlation analysis on the relevant metadata of the temporarily stored events to check whether there are identical database transaction IDs or primary keys. If the analysis module confirms that the events have a causal relationship, the log capture agent merges multiple events into a single trigger and instructs the memory circular log to solidify a unified context snapshot. Otherwise, if there is no causal relationship, the events are treated as independent, and their respective context snapshots are solidified separately. One or more solidified snapshots are then passed to the data acquisition service to execute subsequent data acquisition tasks.

[0041] Example 4: This embodiment aims to provide a specific and reproducible dynamic adjustment procedure for maintaining a stable and effective diagnostic backtracking time window when faced with drastic fluctuations in database transaction rates using a memory circular log. In a practical application of this method in a steam turbine generator diagnostic monitoring and management system, one engineering problem encountered is that the time span covered by a statically configured memory circular log fluctuates inversely with changes in database load. During normal system operation, a 512MB circular log can store 60 minutes of metadata. However, during peak business periods such as equipment start-up / shutdown or system debugging, the database transaction rate may increase more than tenfold. In such cases, the time span covered by the same circular log may be compressed to less than 6 minutes. This time span is lower than the 15-minute backtracking window typically required for fault diagnosis, resulting in the loss of crucial diagnostic evidence during the busiest and most error-prone times of the system. To address this issue, the method of this invention is configured to execute an adaptive log management procedure based on time span monitoring. In this procedure, the system no longer sets a fixed physical log capacity, but instead sets a logical minimum time window threshold. In this embodiment, this threshold is set to 900 seconds. A monitoring service within the log capture agent continuously calculates and monitors the time difference between the timestamp of the oldest metadata stored in the current loop log and the current system time, with a period of 1 second. This difference is the actual time span that the log can cover. At the same time, the system presets a warning time window, the value of which is 1.2 times the minimum time window threshold, i.e., 1080 seconds. When the monitoring service detects that the actual time span of the loop log starts to decrease from the original 3600 seconds due to the occurrence of business peaks, and falls below 1080 seconds for the first time, the system automatically triggers the first level of dynamic adjustment, i.e., online log compression.

[0042] Under online log compression, the log capture agent changes its method of writing metadata. For multiple data change operations of the same type occurring within a tiny 100-millisecond time batch targeting the same data table, instead of recording metadata for each operation individually, it merges them into a single aggregated metadata entry. A specific example of an aggregated record is as follows: if 10 UPDATE operations occur on a real-time measurement table within a batch, the agent will no longer write 10 separate metadata entries, but instead write an aggregated record in the format [start timestamp, real-time measurement table, UPDATE_MERGED, operation count: 10]. This method reduces the log storage space occupied by high-frequency operations while preserving key transaction activity information, thus slowing down the rate of decrease in the time span. If the database transaction rate remains high, causing issues after online compression... Subsequently, the actual time span of the circular log is further compressed and falls below the minimum time window threshold of 900 seconds. The system then automatically triggers the second-level dynamic adjustment method, namely, log hierarchical archiving. In this method, the system serializes and dumps the oldest 25% of metadata entries in the circular log from memory to a temporary archive file located on a local high-speed solid-state drive, freeing up memory space for new metadata. When a context snapshot needs to be fixed after receiving an external event message, the fixed content will consist of the remaining metadata in memory and the collection of all relevant archive files. The data acquisition service is also configured to parse this hybrid snapshot composed of memory and disk files. Through this series of dynamic adjustment procedures automatically triggered based on time span monitoring, the diagnostic data backtracking capability of this method is maintained at a level not lower than the preset minimum time window threshold.

[0043] Example 5: This embodiment aims to illustrate the specific engineering procedures configured to ensure system stability and diagnostic data reliability when the method of the present invention faces boundary conditions such as failure of its core component, the log capture agent, or errors in the collected data at the transaction level but at the business semantic level. To address the risk of the log capture agent failing due to server downtime or software malfunction, the method of the present invention also includes a procedure for agent health status monitoring and compensatory data collection executed by a monitoring service. Under this procedure, a normally functioning log capture agent is configured to publish a heartbeat message containing its own identifier and current timestamp to a dedicated topic in the message middleware every 5 seconds. An independent monitoring service continuously subscribes to this heartbeat topic. If the monitoring service fails to publish the message for more than 15 seconds, the agent will be notified to update the message. If no new heartbeat message is received after the time threshold, the log capture agent is deemed to have failed and a system alarm is immediately triggered. When the operations and maintenance personnel respond to the alarm and restart the log capture agent, the agent will execute a compensation logic upon startup. This logic first determines the start and end time window of the failure, then queries the message middleware to determine whether any external event messages were published during the failure window. If an external event message indicating a critical business event was indeed published during the failure period, a compensatory data collection is immediately triggered. This collection is not based on the lost metadata, but on the timestamp of the external event message. It queries and collects all data from all modified data tables during the failure period, thus providing a compensatory context dataset for failure analysis in the event of core component failure.

[0044] To further enhance the credibility of the data in the final delivered target dataset and avoid misleading fault diagnosis due to data semantic pollution caused by sensor failures, the method of this invention includes a data semantic verification procedure after generating the target dataset in step d. This procedure performs offline verification of the data in the target dataset based on a set of predefined semantic rules related to the business logic or physical constraints of the relational database. The semantic rule base is configured during system deployment, and the rules include that the value range of the return oil temperature in the real-time measurement point table should be between 0 and 200 degrees Celsius, and the single change of the main steam pressure in the unit's main parameter table should be within the range of 0 to 200 degrees Celsius. The efficiency should not exceed 0.5 MPa per second, and when the status field value of the main oil pump in the equipment status table is "Running", the status field value of its inlet valve in the valve status table cannot be "Closed". After the target dataset is generated, a verification service will load these semantic rules and traverse the relevant data in the dataset. When a data point is detected that does not conform to the rules, the service will not modify the original data, but will generate a verification report. This report will identify the data points in the target dataset that do not conform to the semantic rules and the specific semantic rules they violate, and will be delivered together with the target dataset to assist the operations engineer in judging the data quality.

[0045] Example 6: This embodiment aims to establish a baseline model for proactively identifying silent faults based on data change behavior, and to define key parameters, namely trigger thresholds. The calibration provides a standardized engineering procedure. When the method of this invention is first deployed in a new steam turbine generator diagnostic monitoring and management system, a baseline model calibration procedure needs to be executed to enable it to accurately identify the unique normal data change behavior patterns of this specific system. The initial state of this procedure is defined as selecting a 24-hour continuous historical database change log that can represent the typical operating conditions of the steam turbine generator set as input data. This log contains the metadata of all data change operations during this period. The goal of the calibration procedure is to generate a baseline model of data change behavior for online monitoring and quantification based on this input data, and to determine a reasonable trigger threshold for triggering anomaly judgment. The specific steps of the calibration procedure are as follows: First, the system divides the 24-hour metadata stream into 1440 consecutive sliding time windows with a step size of 60 seconds. Second, within each time window, statistical features are extracted from the metadata, namely, two core feature vectors are calculated. One is the association between the database transaction and the operated data table, specifically quantified as the average number of data tables associated with a transaction. The other is the distribution of data change operations on different data tables, specifically quantified as the distribution vector formed by the proportion of write operations to the total number of write operations for each data table. Subsequently, the system inputs the feature vectors of the 1440 samples into a Gaussian mixture model for unsupervised learning clustering, and solidifies the statistical feature distribution represented by the cluster center with the largest sample proportion as the baseline model of data change behavior for the system. To quantify the statistical features of the metadata stream to establish the baseline model of data change behavior, the system adopts a feature vectorization procedure.

[0046] Within a 60-second sliding time window, the system generates a feature vector V of length N+M, where N is the total number of monitored data tables and M is the preset number of transaction complexity bins, for example, M equals 5. The first N dimensions of vector V are filled with the total number of INSERT, UPDATE, and DELETE operations occurring on each data table within the window, respectively. The last M dimensions are filled with the total number of database transactions within the window, corresponding to 1, 2, 3, 4, and 5 or more associated data tables, respectively. Subsequently, by normalizing all counts in vector V (i.e., dividing each item by the sum of all items), a probability distribution vector P with a sum of 1 is generated. The baseline model is the mean vector of multiple probability distribution vectors collected during normal system operation. The probability distribution of the current window during real-time monitoring is as follows: Finally, the difference measure used to determine deviation. Using the Kullback-Leibler divergence formula Perform the calculation, where Let be the i-th component of the probability distribution vector, and let be the trigger threshold. The calibration is then taken from all the values ​​calculated during the baseline model learning phase. The 99.9 percentile of the value set; after the baseline model is established, the system again traverses 1440 samples, calculating the Kullback-Leibler divergence between the statistical characteristics of each sample and the baseline model, i.e., the measure of difference. This results in a set containing 1440 A set of values; ultimately, the trigger threshold. The determination is to take that The 99.9 percentile of the value set, in this embodiment, is calculated to be 0.85, and the system then... Set it to 0.85 and save the configuration; through this procedure, the system completes the automated calibration of a baseline model and trigger threshold with clear statistical significance for a specific monitoring object.

[0047] Example 7 The following are embodiments of the apparatus of the present invention, which can be used to execute embodiments of the method of the present invention. For details not disclosed in the apparatus embodiments, please refer to the embodiments of the method of the present invention.

[0048] This invention also provides a data acquisition system based on an event message-driven relational database, comprising: The metadata acquisition module is used to monitor data change operations in relational databases in real time and continuously write metadata related to data change operations, which only contains index information, into a preset-size circular log maintained in memory to form a real-time updated metadata stream. The baseline modeling module is used to establish a baseline model representing the data change behavior of a relational database under a preset normal state by continuously analyzing the statistical characteristics of the meta-information flow. The abnormal behavior determination module is used to, when it is determined that the current data change behavior pattern deviates from the data change behavior baseline model, and without receiving an external event message indicating the occurrence of a critical business event, proactively solidify all metadata entries in the circular log within a preset time window associated with the time point of deviation of the data change behavior pattern as a first context snapshot. The dataset generation module is used to query and retrieve the complete data of the corresponding data rows from the relational database based on the table names and primary keys contained in the first context snapshot, forming a target dataset for fault diagnosis that is associated with the deviation event of data change behavior pattern.

[0049] The processor stores a computer program, which includes program instructions, and executes the program instructions stored in the computer storage medium. The processor may be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. It is the computing and control core of the terminal, suitable for implementing one or more instructions, specifically suitable for loading and executing one or more instructions to achieve a corresponding method flow or corresponding function. The processor described in this embodiment of the invention can implement an operation of a data acquisition method based on an event message-driven relational database.

[0050] In another embodiment of the present invention, a storage medium is provided, specifically a computer-readable storage medium (Memory), which is a memory device in a terminal device used to store programs and data. It is understood that the computer-readable storage medium here can include both the built-in storage medium in the terminal device and extended storage media supported by the terminal device. The computer-readable storage medium provides storage space that stores the terminal's operating system. Furthermore, the storage space also stores one or more instructions suitable for loading and execution by a processor. These instructions can be one or more computer programs (including program code). It should be noted that the computer-readable storage medium here can be high-speed RAM or non-volatile memory, such as at least one disk storage device. The processor can load and execute one or more instructions stored in the computer-readable storage medium to implement the corresponding steps of the data acquisition method for an event-message-driven relational database described in the above embodiments.

[0051] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0052] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0053] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0054] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0055] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation of the present invention. Any modifications or equivalent substitutions that do not depart from the spirit and scope of the present invention should be covered within the scope of protection of the claims of the present invention.

Claims

1. A data acquisition method based on an event-message-driven relational database, characterized in that, Includes the following steps: Real-time monitoring of data change operations in relational databases; extraction of metadata related to data change operations that contains only index information; continuous writing of metadata into a pre-defined circular log maintained in memory to form a real-time updated metadata stream. Continuously analyze the statistical characteristics of the meta-information flow, and establish a baseline model of data change behavior representing the pre-set normal state of the relational database based on the analysis results; When it is determined that the current data change behavior pattern deviates from the data change behavior baseline model, and no external event message indicating the occurrence of a critical business event is received, a snapshot is proactively triggered for solidification: extract all metadata entries in the circular log that are associated with the deviation time point within a preset time window, and solidify these metadata entries as the first context snapshot; Based on the table names and primary keys contained in the first context snapshot, complete data of the corresponding data rows is queried from the relational database to form a target dataset associated with the deviation event of data change behavior pattern; this target dataset is used for fault diagnosis of relational database.

2. The data acquisition method based on an event-message-driven relational database according to claim 1, characterized in that, The steps for obtaining metadata also include: determining whether a data change operation is a high-risk operation based on predefined rules; when it is determined to be a high-risk operation, the metadata written to the circular log also includes the complete data of the data row before and after the change; if the metadata entry of the first context snapshot contains complete data, it is extracted directly from it without initiating a query to the relational database. The statistical characteristics of the meta-information flow include at least two categories: the first category is the association between the database transaction identifier and the operated data table within the sliding time window; the second category is the distribution of data change operations on different data tables. The deviation from the data change behavior pattern is determined by calculating the difference in probability distribution: a measure of the difference between the current data change behavior pattern and the baseline model is calculated. Preset trigger threshold When satisfied When this occurs, it is determined to be a pattern deviation; Complete data retrieved from a relational database query needs to be stored in a dedicated database schema, which is specifically created for the analysis of events that deviate from the data change behavior pattern. After obtaining the target dataset, semantic verification is performed. Specifically, the data in the target dataset is verified based on a set of predefined semantic rules, and a corresponding verification report is generated. The verification report identifies the data points in the target dataset that do not conform to the semantic rules and the specific semantic rules violated by the data points. Among them, the semantic rules are related to the business logic and physical constraints of the relational database.

3. The data acquisition method based on an event-message-driven relational database according to claim 2, characterized in that, In the step of obtaining metadata, the predefined rules include two types of data change operation judgment conditions; The first category is update operations performed on the system configuration table or permission table; The second category is operations where the number of data rows deleted exceeds a preset threshold in a single database transaction.

4. The data acquisition method based on an event-message-driven relational database according to claim 1, characterized in that, It also includes an additional target dataset, specifically: Receive external event messages triggered by external systems that indicate the occurrence of critical business events; In response to the external event message, based on the time of the message occurrence, all metadata entries within a preset time window are determined from the circular log, and the metadata entries are solidified as a second context snapshot. Extract table names and primary key information from the second context snapshot. Based on the table names and primary keys, query and retrieve the complete data of the corresponding data rows from the relational database to form an additional target dataset associated with key business events.

5. The data acquisition method based on an event-message-driven relational database according to claim 4, characterized in that, Between receiving external event messages and responding to external event messages, there is also: In response to the first received external event message, an aggregation window of a preset duration is started. During the existence of the aggregation window, all received external event messages are temporarily stored. After the aggregation window ends, analyze the metadata associated with the temporary external event messages in the loop log, and determine whether the external event messages are associated with the same database transaction identifier or the same data entity primary key based on the metadata. Based on the above determination results, it is confirmed whether there is a causal relationship between the temporarily stored external event messages; All steps related to responding to external event messages are executed based on the above causal relationship determination results: if a causal relationship is determined, the multiple temporarily stored external event messages are merged into a single triggering event; for the merged single triggering event, a unified second context snapshot is fixed, which covers the time range of all related external event messages.

6. The data acquisition method based on an event-message-driven relational database according to claim 1, characterized in that, Real-time monitoring of data change operations in relational databases also includes: periodically monitoring whether the real-time monitoring data change operations are executed normally; if a failure is detected in the real-time monitoring operation and subsequent recovery is completed, checking whether any external event messages were published during the failure period; if there are published external event messages during the failure period, triggering a compensatory data collection to collect all data from all modified data tables during the failure period; the compensatory data collection is based on the timestamps of the external event messages for querying. The specific methods for writing metadata to the circular log are as follows: monitor the actual time span that the circular log can cover, and determine whether the time span is lower than the preset minimum time window threshold; if it is lower than the threshold, dynamically adjust the method of writing metadata to the circular log: the first adjustment method is to merge the records of multiple operations on the same data table to reduce storage usage; the second adjustment method is to transfer the oldest part of the metadata in the circular log from memory to persistent storage.

7. A data acquisition system based on an event-message-driven relational database, characterized in that, include: The metadata acquisition module is used to monitor data change operations in relational databases in real time, extract metadata related to data change operations that contains only index information, and continuously write the metadata into a pre-set size circular log maintained in memory to form a real-time updated metadata stream. The baseline modeling module is used to continuously analyze the statistical characteristics of the meta-information flow and establish a baseline model of data change behavior representing the preset normal state of the relational database based on the analysis results. The abnormal behavior determination module is used to proactively trigger snapshot solidification when the current data change behavior pattern deviates from the data change behavior baseline model and no external event message indicating the occurrence of a key business event is received: extract all metadata entries in the circular log within a preset time window associated with the deviation time point, and solidify these metadata entries as the first context snapshot; The dataset generation module is used to query and retrieve the complete data of the corresponding data rows from the relational database based on the table names and primary keys contained in the first context snapshot, forming a target dataset associated with the deviation event of data change behavior pattern; this target dataset is used for fault diagnosis of relational databases.

8. A terminal device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the data acquisition method based on an event message-driven relational database as described in any one of claims 1 to 6.

9. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the data acquisition method based on an event message-driven relational database as described in any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the data acquisition method based on an event message-driven relational database as described in any one of claims 1 to 6.

Images