Distributed database inspection system, method, equipment and medium

Abstract

The invention discloses a distributed database inspection system, method and device and a medium, and relates to the technical field of database management and operation and maintenance, and the system comprises a data collection module used for database operation data, node states and service association data; the federated learning module generates a global model by encrypting and aggregating local model parameters of each node; the semantic network module analyzes and reasones the multi-source data based on the ontology model to generate a fault risk tag; the reinforcement learning module combines the global / local model difference value, the operation data and the fault label to construct a state space, and generates an action instruction packet; the voiceprint recognition module triggers a mandatory authentication process before the instruction is executed; an execution result is fed back to the reinforcement learning module to update the strategy, and the semantic network module is driven to optimize and update data of the target database. By fusing federal cooperative training, autonomous decision and semantic reasoning are enhanced, and the operation and maintenance efficiency and safety of the distributed database are remarkably improved.

Description

Technical Field

[0001] The present invention relates to the technical field of database management and operation and maintenance, and in particular to a distributed database inspection system, method, equipment and medium. Background Art

[0002] With the rapid development of information technology, databases are increasingly used across various industries and their scale continues to expand. Traditional database inspection methods, which primarily rely on manual operations and simple monitoring tools, suffer from numerous shortcomings. On the one hand, manual inspections are inefficient and difficult to handle for large-scale databases and complex business scenarios. They are also prone to human negligence, leading to delayed fault detection. On the other hand, existing monitoring tools lack intelligent analytical capabilities, are unable to accurately predict and diagnose potential problems, and are unable to adjust inspection strategies based on dynamic database changes. In a distributed database environment, data is stored and managed in a decentralized manner, making it difficult for traditional methods to achieve collaborative data analysis and unified operations and maintenance. Furthermore, data security and privacy issues are becoming increasingly prominent, making it difficult for traditional inspection methods to effectively ensure the integrity and security of data during collection, transmission, and storage. Furthermore, the single authentication method for operations and maintenance personnel presents security risks. Furthermore, existing systems fail to fully leverage the vast amount of operational knowledge and experience in knowledge management and reasoning, making it difficult to provide comprehensive and accurate solutions. Summary of the Invention

[0003] In view of this, the purpose of the present invention is to provide a distributed database inspection system, method, device and medium that can improve the efficiency, accuracy and security of database inspection and ensure the stable operation of the database. The specific solution is as follows:

[0004] In the first aspect, the present application discloses a distributed database inspection system, including: a data acquisition module, a federated learning module, a reinforcement learning module, a voiceprint recognition module, and a semantic web module, wherein:

[0005] The data collection module is used to collect the running data of the distributed database, the local data of the distributed nodes and the business data to obtain the target database data;

[0006] The federated learning module is used to use the received structured target database data to perform collaborative inspection training of local models among distributed nodes, so as to output and upload local model parameters to the central server so that the local model parameters can be aggregated by the central server to obtain global model parameters of the global model;

[0007] The semantic web module is used to generate fault risk labels based on the operation data and local data of distributed nodes through ontology model reasoning;

[0008] A reinforcement learning module is used to construct a state space based on global model parameters, parameter differences between local model parameters, operating data, distributed node local data, business data, and fault risk labels, and to generate an action instruction package based on the target instruction corresponding to the maximum reward value in the state space and reward value table;

[0009] The voiceprint recognition module is used to trigger the compulsory authentication process when receiving the action instruction package to obtain the compulsory authentication result, and select the instruction execution process or the authentication failure process according to the compulsory authentication result;

[0010] The reinforcement learning module is used to calculate the reward value generated after the instruction is executed and update the reward value table;

[0011] The semantic web module is used to analyze the action effects produced after the execution of instructions and update the target database data based on the action effect analysis results.

[0012] Optional, distributed database inspection system also includes:

[0013] The digital watermark module is used to embed a digital watermark into the action log generated after the instruction is executed, and transmit the action log carrying the digital watermark to the blockchain module.

[0014] Optionally, the digital watermark module is specifically used to embed a digital watermark containing the operation time and node identifier into the action log generated after the instruction is executed, and detect the integrity of the digital watermark through the Hamming distance, so as to transmit the action log that has passed the watermark integrity verification to the blockchain module.

[0015] Optional, distributed database inspection system also includes:

[0016] The blockchain module is used to obtain the action effect analysis results, package the action logs and action effect analysis results with digital watermarks, and store them in the operation and maintenance database.

[0017] Optionally, the ontology model includes a triple relationship of data field, sensitivity level, and business impact;

[0018] Correspondingly, the semantic web module is specifically used to generate fault risk labels through SWRL rules and based on the triple relationship of the ontology model, operation data and distributed node local data.

[0019] Optionally, the voiceprint recognition module is specifically used to extract the current voiceprint features using Mel-frequency cepstral coefficients when receiving an action instruction packet, and calculate the similarity between the current voiceprint features and the voiceprint feature template through a dynamic time warping algorithm to determine the mandatory authentication result based on the similarity.

[0020] Optionally, a semantic web module is used to convert the action effect analysis results into target triples containing performance indicator changes caused by the action type and timestamps, and use the target triples to update the target database data.

[0021] In a second aspect, the present application discloses a distributed database inspection method, comprising:

[0022] Collect the operating data of the distributed database, local data of distributed nodes and business data to obtain the target database data;

[0023] Using the received structured target database data to conduct collaborative inspection training of local models among the distributed nodes, so as to output and upload local model parameters to the central server, so as to aggregate the local model parameters through the central server to obtain global model parameters of the global model;

[0024] Generate fault risk labels through ontology model reasoning based on operational data and local data of distributed nodes;

[0025] A state space is constructed based on global model parameters, parameter differences between local model parameters, operating data, distributed node local data, business data, and fault risk labels to generate an action instruction package based on the target instruction corresponding to the maximum reward value in the state space and reward value table;

[0026] When receiving an action instruction package, the mandatory authentication process is triggered to obtain the mandatory authentication result, and the instruction execution process or the authentication failure process is selected according to the mandatory authentication result;

[0027] Calculate the reward value generated after the instruction is executed and update the reward value table;

[0028] Analyze the action effect produced after the instruction is executed to update the target database data based on the action effect analysis results.

[0029] In a third aspect, the present application discloses an electronic device, comprising:

[0030] Memory, used to store computer programs;

[0031] The processor is used to execute the computer program to implement the steps of the aforementioned distributed database inspection method.

[0032] In a fourth aspect, the present application discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, the steps of the aforementioned distributed database inspection method are implemented.

[0033] It can be seen that the present application discloses a distributed database inspection system, including: a data acquisition module, a federated learning module, a reinforcement learning module, a voiceprint recognition module, and a semantic web module, wherein the data acquisition module is used to collect the operating data of the distributed database, the local data of the distributed nodes, and the business data to obtain the target database data; the federated learning module is used to use the received structured target database data to perform collaborative inspection training of the local model between each distributed node, so as to output and upload the local model parameters to the central server, so that the local model parameters can be aggregated by the central server to obtain the global model parameters of the global model; the semantic web module is used to generate fault risk information based on the ontology model reasoning and the operating data and the local data of the distributed nodes. risk label; the reinforcement learning module is used to construct a state space based on the global model parameters, the parameter difference value between the local model parameters, the operating data, the local data of the distributed nodes, the business data, and the fault risk label, so as to generate an action instruction package according to the target instruction corresponding to the maximum reward value in the state space and the reward value table; the voiceprint recognition module is used to trigger the mandatory authentication process when receiving the action instruction package to obtain the mandatory authentication result, and select the instruction execution process or the authentication failure process according to the mandatory authentication result; the reinforcement learning module is used to calculate the reward value generated after the instruction is executed and update the reward value table; the semantic web module is used to analyze the action effect generated after the instruction is executed, so as to update the target database data based on the action effect analysis result. It can be seen that autonomous operation and maintenance strategy optimization is achieved through reinforcement learning, distributed database collaboration problems are solved by using federated learning, operation authentication security is improved by combining voiceprint recognition, and operation and maintenance automation and knowledge reasoning capabilities are improved with the help of semantic web technology, thereby ensuring the stable operation of the database and reducing operation and maintenance costs. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are merely embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.

[0035] Figure 1 This is a schematic diagram of the structure of a distributed database inspection system disclosed in this application;

[0036] Figure 2 This is a flow chart of a distributed database inspection method disclosed in this application;

[0037] Figure 3 This is a structural diagram of an electronic device disclosed in this application. DETAILED DESCRIPTION

[0038] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the embodiments described are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0039] With the rapid development of information technology, databases are increasingly used across various industries and their scale continues to expand. Traditional database inspection methods, which primarily rely on manual operations and simple monitoring tools, suffer from numerous shortcomings. On the one hand, manual inspections are inefficient and difficult to handle for large-scale databases and complex business scenarios. They are also prone to human negligence, leading to delayed fault detection. On the other hand, existing monitoring tools lack intelligent analytical capabilities, are unable to accurately predict and diagnose potential problems, and are unable to adjust inspection strategies based on dynamic database changes. In a distributed database environment, data is stored and managed in a decentralized manner, making it difficult for traditional methods to achieve collaborative data analysis and unified operations and maintenance. Furthermore, data security and privacy issues are becoming increasingly prominent, making it difficult for traditional inspection methods to effectively ensure the integrity and security of data during collection, transmission, and storage. Furthermore, the single authentication method for operations and maintenance personnel presents security risks. Furthermore, existing systems fail to fully leverage the vast amount of operational knowledge and experience in knowledge management and reasoning, making it difficult to provide comprehensive and accurate solutions.

[0040] To this end, the present invention provides a distributed database inspection solution that can improve the efficiency, accuracy and security of database inspection and ensure the stable operation of the database.

[0041] Reference Figure 1 As shown, the embodiment of the present invention discloses a distributed database inspection system, including: a data acquisition module 11, a federated learning module 12, a reinforcement learning module 13, a voiceprint recognition module 14, and a semantic network module 15, wherein:

[0042] The data collection module 11 is used to collect the running data of the distributed database, the local data of the distributed nodes and the business data to obtain the target database data;

[0043] a federated learning module 12 for performing collaborative inspection training of local models among distributed nodes using the received structured target database data, so as to output and upload local model parameters to a central server, so as to aggregate the local model parameters through the central server to obtain global model parameters of a global model;

[0044] The semantic web module 15 is used to generate fault risk labels based on the operation data and local data of distributed nodes through ontology model reasoning;

[0045] A reinforcement learning module 13 is configured to construct a state space based on global model parameters, parameter differences between local model parameters, operating data, distributed node local data, business data, and fault risk labels, and to generate an action instruction packet based on the state space and the target instruction corresponding to the maximum reward value in the reward value table;

[0046] The voiceprint recognition module 14 is configured to trigger a mandatory authentication process upon receiving an action instruction packet to obtain a mandatory authentication result, and select an instruction execution process or an authentication failure process according to the mandatory authentication result;

[0047] Reinforcement learning module 13, used to calculate the reward value generated after the instruction is executed and update the reward value table;

[0048] The semantic web module 15 is used to analyze the action effects produced after the instruction is executed, so as to update the target database data based on the action effect analysis results.

[0049] It is understood that the data collection module 11 is used for multi-source data collection, wherein the multi-source data collection includes distributed database operation data collection, distributed node local data collection and business data collection, wherein the database operation data collection is as follows:

[0050] Resource usage metrics: CPU usage, memory usage, and disk I / O read / write rates are collected periodically (for example, every five minutes) using the database management system's built-in monitoring interface (such as the SHOW STATUS statement in MySQL or the V$ view in Oracle). For CPU usage, the CPU time slices used by the database process are obtained from the operating system and compared to the total CPU time slices to calculate the percentage. Memory usage is calculated by measuring the actual physical and virtual memory used by the database process. Disk I / O rate is calculated by monitoring the number of read and write operations and the amount of data in the database data and log files to calculate the I / O throughput per second.

[0051] Connection and Transaction Metrics: This tool tracks the number of concurrent database connections in real time, distinguishing between active and waiting connections. By querying the database connection pool status table, it obtains the number of connections currently executing SQL statements and the number of connections in the queue awaiting resource allocation. It also records transaction processing status, including the number of transaction commits and rollbacks per second. When a transaction is committed or rolled back, the database log records the relevant operations. By parsing the log file, the number of transactions per unit time can be counted.

[0052] Use database query analysis tools (such as SQL Server's Query Store) to capture SQL statements that take a long time to execute. For each SQL statement, record information such as execution time, number of executions, number of rows scanned, and indexes used. Analyze the execution plan to obtain query resource overhead, such as CPU consumption, memory usage, and number of disk reads, to evaluate query performance.

[0053] The local data collection of distributed nodes is as follows:

[0054] Node status data: A heartbeat monitoring mechanism is established for each node in the distributed database. Each node periodically (e.g., every 10 seconds) sends a data packet containing its status information to the central coordinator. This data includes the node's operating status (normal, busy, faulty) and load (CPU, memory, and disk I / O usage). The node collects this information using its own system monitoring tools and then encapsulates it in a specially formatted data packet for transmission.

[0055] Local data consistency indicators: Utilize the log records of distributed transaction protocols (such as the two-phase commit protocol) to check the consistency of data synchronization between nodes. During each transaction commit, the version number and timestamp of the data update are recorded. Data consistency is determined by comparing the version numbers and timestamps of the same data on different nodes. If the version numbers are inconsistent or the timestamp difference exceeds a threshold, a data consistency issue is flagged.

[0056] Network communication metrics: Deploy network monitoring tools (such as SNMP agents) on network links between nodes to collect metrics such as network latency, bandwidth utilization, and packet loss. Network latency is measured by sending ICMP echo request packets and recording the round-trip time. Bandwidth utilization is calculated as the ratio of the actual data transmission rate of the network interface to the interface bandwidth. Packet loss is calculated by comparing the number of packets sent and received.

[0057] The business data collection of the business system is as follows:

[0058] Business request volume and response time: Target the business system's API gateway to capture all business requests that operate on the database. Record the initiation and end time of each request to calculate the business response time. Also, count the number of business requests per unit time (e.g., per hour). Categorize and aggregate this data by business module and request type to analyze the impact of different businesses on database load.

[0059] Data related to key business indicators: For e-commerce systems, correlate order creation volume and product query volume with database insert and query operations. By combining the operation logs of the business system's order and product tables with the database's transaction logs, analyze the relationship between business operations and database transactions. For example, every time an order is created, the database performs an insert operation into the order table. By correlating the timestamps and operation IDs of these two tables, we can identify the impact of business operations on the database.

[0060] User behavior data: Use user behavior analysis tools (such as Google Analytics) to collect user operations within business systems, such as page views, searches, and clicks. Correlate these behaviors with database queries to analyze their impact on database load. For example, a large number of users simultaneously searching for a certain product category may lead to a high level of concurrent execution of related product queries in the database. This correlation analysis can help predict database load peaks in advance.

[0061] In this way, multi-source data of the distributed database is collected through the data collection module 11 to obtain the target database data, so as to build a multi-dimensional perception system and realize all-round real-time monitoring of the distributed database operation status, underlying resources, business load and security risks.

[0062] In this embodiment, after obtaining the target database data, the reinforcement learning module 13 uses a reinforcement learning strategy to quantify the performance indicators, service load, and fault status in the target database data into a multidimensional vector, that is, to define a state space. The process of defining the state space is as follows:

[0063] Database performance status: Database performance metrics such as CPU usage, memory usage, disk I / O rate, and query response time are quantified into status values. For example, CPU usage is divided into three intervals: low (0-30%), medium (30%-70%), and high (70%-100%), each corresponding to a different status code. Metrics such as memory usage and disk I / O rate are similarly divided and coded, forming a multi-dimensional performance status vector.

[0064] Business load status: The business load status is defined based on the changing trend of business request volume (increasing, stable, decreasing) and the quality of business response time (fast, normal, slow). Business request volume is determined by comparing the number of requests over a period of time (e.g., the past hour) with the same period in history to determine the changing trend. Business response time is compared with the pre-set service level agreement (SLA) to determine the quality of response time, which is also encoded as part of the state vector.

[0065] Fault and exception status: Various database faults and exceptions (such as connection timeouts, deadlocks, and insufficient disk space) are considered as a state dimension. Each fault or exception is assigned a unique code. When the corresponding problem occurs, the corresponding code position in the state vector is set to 1; otherwise, it is set to 0.

[0066] Action instructions are designed while defining the state space. This is also called determining the action space. Action instruction design includes parameter tuning (caching / connection pooling), load balancing scheduling, and data maintenance (cleaning / index rebuilding). The process of determining the action space is as follows:

[0067] Database configuration adjustments include adjusting database cache size, maximum connection pool connections, and thread pool thread count. For example, if CPU usage is high and there's enough memory, you can increase the cache size to reduce disk I / O and improve data read speed. The cache size is adjusted in increments (e.g., 10MB), while the maximum connection pool connections and thread pool thread count can be increased or decreased in integer increments.

[0068] Resource scheduling: In a multi-node database system, load balancing is performed between nodes. For example, traffic can be shifted from a highly loaded node to a less loaded node. This is accomplished by modifying the load balancer's configuration rules and adjusting the traffic distribution weights. Dynamic resource allocation can also be performed, such as adding CPU and memory resources to highly loaded nodes (if the underlying infrastructure supports dynamic resource allocation, such as in a cloud computing environment).

[0069] Data maintenance operations: Perform data cleanup tasks to delete expired or useless data. For example, for log tables, periodically delete log records older than a certain period (e.g., three months). Perform index rebuilds to improve query efficiency when index fragmentation is severely impacting query performance. Index rebuilds can be performed online to minimize business impact.

[0070] Design the reward function in the reinforcement learning process. The specific setting process of the reward function is as follows:

[0071] Performance Improvement Rewards: When database performance metrics (such as reduced CPU utilization, shorter query response times, and optimized disk I / O rates) move in the desired direction, positive rewards are awarded. For example, a 5% decrease in CPU utilization results in a 10-point bonus. Rewards are weighted based on the magnitude and importance of the performance metric change, with higher weights assigned to metrics with greater business impact (such as query response time).

[0072] Fault Reduction Reward: Each time a database fault (such as a deadlock or connection timeout) is avoided, a higher reward (e.g., 50 points) is awarded. When a fault occurs, a negative reward (e.g., -100 points) is given, and the negative reward value is adjusted based on the severity of the fault. Faults that severely impact business (such as database crashes) receive a larger negative reward value.

[0073] Business Satisfaction Rewards: Based on feedback from the business system, rewards are given when business response times meet or exceed SLA standards. Rewards are also given when business request volume increases while the system operates stably, encouraging the system to support greater business loads. The reward value is related to the degree of improvement in business response time and the magnitude of the increase in business request volume.

[0074] The reinforcement learning module 13 uses the DQN algorithm to implement iterative optimization of reinforcement strategies through a three-dimensional reward mechanism of performance improvement, fault reduction, and business satisfaction, combined with an experience replay pool. The specific optimization strategies of the reinforcement learning algorithm are as follows:

[0075] Algorithm Selection and Initialization: We use the Deep Q-Network (DQN) algorithm to construct a neural network consisting of an input layer, hidden layers, and an output layer. The input layer receives the state space vector, and the output layer outputs the Q value for each action. We initialize the Q-network weights and randomly generate an experience replay pool to store the four-tuple data of state, action, reward, and next state during the reinforcement learning process.

[0076] Policy execution and learning process: At each time step, the Q-network selects the action with the highest Q-value based on the current state. (For example, a greedy strategy randomly selects an action with probability ε and selects the action with the highest Q-value with probability 1-ε, with ε gradually decreasing as learning progresses.) After executing the action, the state changes of the database and business system are observed to obtain the reward value. The four-tuple data of state, action, reward, and next state is stored in the experience replay pool. When the experience replay pool reaches a certain number of data (e.g., 1000), a batch of data is randomly sampled from the experience replay pool for learning. By calculating the error between the target Q-value and the current Q-value, the backpropagation algorithm is used to update the weights of the Q-network to continuously optimize the policy.

[0077] Model evaluation and update: The reinforcement learning model is evaluated regularly (e.g., every 100 time steps). In a test environment, a series of operations are executed using the current policy to observe indicators such as database performance, number of failures, and business satisfaction. If the evaluation results are better than the previous model, the current model is saved; otherwise, learning and optimization continue. At the same time, the weights of the target Q network are regularly updated to maintain a certain degree of synchronization with the weights of the current Q network to prevent excessive deviation in Q value estimation.

[0078] In this embodiment, the federated learning module 12 is used for collaborative inspection. Before the federated learning module 12 inspects, the target database data is preprocessed using the node local training model. The preprocessing process is as follows: Each distributed node preprocesses the locally collected data, including data cleaning, normalization, feature engineering and other operations. For numerical data (such as CPU usage and memory usage), it is mapped to the [0, 1] interval through normalization to facilitate model training. For categorical data (such as database status and fault type), it is converted using methods such as one-hot encoding. In terms of feature engineering, some representative features are extracted based on the characteristics of local data, such as taking the CPU usage change trend over a period of time as a new feature, so that structured target database data is obtained.

[0079] Next, model selection and initialization are performed. The model selection process involves each node selecting an intelligent inspection model (local model) that is suitable for the local data characteristics, such as a decision tree, random forest, or neural network. Model parameters are initialized. For neural networks, hyperparameters such as initial weights, learning rate, and number of iterations are set. Each node can adjust these hyperparameters based on factors such as local data size and computing resources. Local model training is performed as follows: the model is trained using locally preprocessed data. During training, cross-validation and other techniques are used to evaluate model performance and prevent overfitting. For decision tree models, the optimal splitting attribute is selected using metrics such as information gain and the Gini coefficient. For neural networks, weights are updated using optimization algorithms such as gradient descent. During training, metrics such as the model's training loss and accuracy are recorded. Training is terminated when model performance reaches a certain threshold (e.g., accuracy stops improving) or the maximum number of iterations is reached. After training is complete, each node extracts model parameters, such as the weight matrix and bias vector for the neural network and the node splitting rule for the decision tree. These parameters are packaged in a specific format to form a parameter data packet. To protect data privacy, parameter data packets are encrypted using an asymmetric encryption algorithm (such as RSA) and the central server's public key. The encrypted local model parameter data packets are uploaded to the central server via a network channel (such as an SSL / TLS encrypted connection). During the upload process, digital signature technology is used to ensure data integrity and source authenticity. Each node signs the parameter data packet with its own private key. Upon receipt, the central server verifies the validity of the signature using the node's public key. The central server receives the encrypted parameter data packets uploaded by each node and decrypts them using its own private key. The integrity of the parameter data packets and the validity of the signatures are verified to ensure that the data has not been tampered with during transmission and that the source is reliable. Aggregation strategies such as the Federated Averaging Algorithm (FedAvg) are used to aggregate the local model parameters transmitted by each node. For neural network weight parameters, the average of all node weights is calculated as the updated weight. For models such as decision trees, aggregation is performed based on statistical information from the node splitting rule. During the aggregation process, different weights can be assigned to the parameters of different nodes. For example, nodes with larger data volumes or better model performance can be given higher weights. The aggregated model parameters are applied to the global model, updating the global model parameters. The updated global model undergoes simple validation, such as calculating the model's loss and accuracy on a small amount of validation data, to ensure the validity of the model update. The central server encapsulates the updated global model parameters in the same format as the uploaded parameters and encrypts them using each node's public key. The encrypted global model parameters are then distributed to each node via a secure network channel.After receiving the model parameters, the node uses its own private key to decrypt them, obtains the updated global model parameters, and applies them to the local model, replacing the original local model parameters, thereby achieving synchronization between the local model and the global model.

[0080] In this embodiment, the reinforcement learning module 13 constructs a state space based on the above-mentioned global model parameters, parameter difference values ​​between local model parameters, operation data, distributed node local data, business data, and fault risk labels to generate an action instruction package according to the target instruction corresponding to the maximum reward value in the state space and reward value table.

[0081] The distributed database inspection system also includes:

[0082] The digital watermark module 16 is configured to embed a digital watermark in the action log generated after the instruction is executed and transmit the action log carrying the digital watermark to the blockchain module. Specifically, the digital watermark module 16 is configured to embed a digital watermark containing the operation time and node identifier in the action log generated after the instruction is executed. The integrity of the digital watermark is then verified using the Hamming distance, and the action log, which has passed the watermark integrity verification, is then transmitted to the blockchain module 17. Specifically, the digital watermark embedding and verification process is as follows: a digital watermark is generated based on information such as the data source, collection time, and data version. This information is encoded, for example, by hashing it using a hash algorithm (such as SHA-256) to generate a fixed-length hash value as the watermark information. To enhance the security of the watermark, the hash value can be encrypted using a key, shared by the data collector and verifier, and used to generate the digital watermark. A watermark embedding algorithm suitable for the database data type is selected. For structured data (such as numeric or string fields in database tables), a least significant bit (LSB) replacement algorithm can be used. For example, the least significant bit (LSB) of the data can be replaced with the binary representation of the watermark information. For unstructured data (such as text fields and image fields in databases), transform-domain watermark embedding algorithms, such as the discrete cosine transform (DCT), are used. Data is converted to the DCT domain, and the watermark is embedded in the low-frequency coefficients, as these have less visual or semantic impact on the data. Embedding locations are selected based on the importance and sensitivity of the data. For critical data fields (such as sensitive user information and financial data), watermarks are embedded in multiple locations to increase robustness. For general data fields, watermarks are embedded in fixed locations such as the beginning, middle, or end of the data. The watermark embedding location is recorded for verification purposes. During data transmission to the destination or during periodic watermark detection during storage, the watermark is extracted from the data based on the recorded watermark embedding location information. For watermarks embedded using the LSB replacement algorithm, the watermark is extracted directly from the lowest-order binary bits of the data. For watermarks embedded in the transform domain, the data is converted to the corresponding transform domain (such as the DCT domain), and the watermark is extracted from the low-frequency coefficients. The extracted watermark is compared with the original watermark (stored in a secure location). Encrypted watermark information is first decrypted using the shared key. During the comparison process, a similarity calculation algorithm (such as Hamming distance or cosine similarity) is used to calculate the similarity between the two. If the similarity reaches a certain threshold (such as 0.9), the watermark is considered intact and the data has not been tampered with; otherwise, the data is considered likely tampered with. If watermark verification fails, further tampering location is determined. For structured data, watermark information can be checked field by field and record by record to determine the location of tampered data. For unstructured data, a block-based watermark detection method is used to divide the data into multiple small blocks. The watermark information of each small block is tested separately to locate the location of the tampered small block.When data is found to have been tampered with, relevant information should be recorded in a timely manner and the data owner or administrator should be notified.

[0083] Then the voiceprint recognition module 14 is specifically used to extract the current voiceprint features using the Mel-frequency cepstral coefficients when receiving the action instruction packet, and calculate the similarity between the current voiceprint features and the voiceprint feature template through the dynamic time warping algorithm to determine the mandatory authentication result based on the similarity.

[0084] Specifically, the authentication and identification steps of the voiceprint recognition module 14 are as follows: registering a voiceprint template, collecting voiceprint features, and comparing voiceprint features. The specific process of registering a voiceprint template is as follows:

[0085] Prepare the voiceprint collection environment: Provide a quiet, interference-free environment for operation and maintenance personnel. Use high-quality microphones to ensure clear and accurate voice collection. Before collection, explain the collection requirements to the operation and maintenance personnel, such as maintaining a stable speaking speed and volume and reading aloud specific text content.

[0086] Voiceprint feature extraction: Operations and maintenance personnel are instructed to read aloud pre-set text (e.g., a combination of numbers, letters, and special characters), and the device records the sound signal. The recorded sound signal undergoes preprocessing, including denoising and filtering. Voiceprint features are then extracted using algorithms such as Mel-Frequency Cepstral Coefficients (MFCC). MFCC algorithms convert the sound signal into a set of feature vectors that capture the unique characteristics of the human voice.

[0087] Template storage: The extracted voiceprint feature vectors are encoded and associated with the operator's identity information (such as username and employee ID), and stored in a secure database. To improve voiceprint recognition accuracy, multiple voiceprints of operators can be collected, averaged, or fused before being stored as a voiceprint template. Furthermore, the voiceprint template database is encrypted and stored using database encryption technologies (such as Transparent Data Encryption (TDE)) to prevent the template from being stolen.

[0088] The process of collecting voiceprint features is as follows:

[0089] Real-time audio collection: When maintenance personnel need to perform critical operations (such as modifying core database configurations or starting or stopping database services), the system uses a connected microphone to collect their voices in real time. This ensures that the personnel speak within the specified distance and their voices are clearly audible.

[0090] Feature extraction and preprocessing: The real-time sound signal undergoes the same preprocessing and feature extraction as when registering a voiceprint template. The same denoising and filtering algorithms are used to remove environmental noise interference, and algorithms such as MFCC are used to extract voiceprint feature vectors. During the feature extraction process, algorithm parameters are dynamically adjusted based on the characteristics of the real-time sound signal to improve feature extraction accuracy.

[0091] The process of comparing voiceprint features is as follows:

[0092] Feature matching algorithm: The voiceprint feature vectors collected and extracted in real time are compared with the voiceprint templates stored in the database. The dynamic time warping (DTW) algorithm is used to calculate the similarity between the two. The DTW algorithm aligns the two voiceprint feature sequences on the time axis, finds the optimal matching path, and calculates the similarity score.

[0093] Threshold judgment and decision-making: Set a similarity threshold (e.g., 0.8). If the calculated similarity score is greater than or equal to the threshold, the voiceprint match is considered successful, allowing the operator to perform key operations. Otherwise, the voiceprint match is considered a failure, the operation is denied, and an alert is sent to the operator and administrator. In actual applications, the similarity threshold can be dynamically adjusted based on system security requirements and statistical results of false positive and false negative rates.

[0094] The blockchain module 17 is used to obtain the action effect analysis results, package the action logs and action effect analysis results with digital watermarks, and store them in the operation and maintenance database. It can be understood that the blockchain module 17 is used for evidence storage and smart contract execution. The first step of packaging information and storing it in the blockchain is as follows:

[0095] Data collation and summary generation: Key information such as database inspection records, fault reports, and optimization recommendations is organized. Inspection records include the time of each inspection and the collected database metrics. Fault reports detail the time of occurrence, symptoms, diagnostic process, and results of the fault. Optimization recommendations include specific action plans for different issues. A unique summary is generated from this information using a hash algorithm (such as SHA-256) to ensure data integrity. For example, inspection records are arranged chronologically into a specific format and their hash value is calculated.

[0096] Transaction Construction and Signature: A blockchain transaction is constructed, containing a message summary, timestamp, and relevant metadata (such as the node identifier of the data source). The operation and maintenance node signs the transaction using its own private key, ensuring the authenticity and non-repudiation of the transaction source. The signing process utilizes asymmetric encryption technology, performing a specific operation on the transaction content and the private key to generate the signature data.

[0097] Broadcast and Consensus: Signed transactions are broadcast to other nodes in the blockchain network. Using consensus algorithms such as Practical Byzantine Fault Tolerance (PBFT), transactions are packaged into a new block after a certain number (more than 2 / 3) of nodes verify the transaction signature, timestamp, and other information. The PBFT algorithm uses inter-node messaging to quickly reach consensus, confirm the legitimacy of the new block, and ensure blockchain data consistency.

[0098] The smart contract is designed as follows:

[0099] Trigger Condition Setting: Smart contract trigger conditions can be set based on database performance metrics and business requirements. For example, if database CPU utilization exceeds 80% for 15 consecutive minutes, or if business response time exceeds twice the set SLA (Service Level Agreement) duration, the corresponding smart contract will be triggered. By precisely defining performance thresholds and timeframes, automated operations can be initiated promptly when critical situations occur.

[0100] Operational Logic Writing: Smart contract operational logic is written for different trigger conditions. If triggered by high CPU usage, the smart contract can perform actions such as adjusting the database thread pool size and shutting down non-critical business queries. If triggered by insufficient disk space, the smart contract can automatically clean up expired log files and initiate data archiving. Operational logic is coded in the smart contract to ensure accurate and automated execution.

[0101] Security Audit and Testing: Before smart contracts are deployed, rigorous security audits are conducted. Formal verification tools are used to check the code for security vulnerabilities (such as reentrancy attacks and improper permission control). Furthermore, smart contracts are extensively tested in a simulated environment, inputting various boundary values ​​and abnormal values ​​to verify the accuracy of trigger conditions and the correctness of operational logic execution, ensuring the stability and security of smart contracts in actual operation.

[0102] The steps to execute the smart contract are as follows:

[0103] Conditional Monitoring and Triggering: Nodes in the blockchain network continuously monitor database performance metrics. This data is collected in real time by the data acquisition module and synchronized to relevant blockchain components. Once the trigger conditions set by the smart contract are met, the system automatically invokes the corresponding smart contract. For example, the monitoring module collects CPU usage data once a second. If this data exceeds a threshold for 15 consecutive minutes, the corresponding smart contract execution process is immediately triggered.

[0104] Contract Execution and Status Update: Smart contracts execute within a blockchain's virtual machine (such as the Ethereum EVM), performing database operations and maintenance according to pre-set logic. Upon completion, the relevant blockchain status data is updated, recording information such as the smart contract execution time and results. For example, after a database thread pool adjustment is completed, the successful operation is recorded on the blockchain, and the corresponding database status is updated to "Thread pool adjusted, current CPU usage monitoring."

[0105] Results Feedback and Recording: Smart contract execution results are fed back to operations personnel and relevant business systems. Operations personnel are informed of the progress of the operation via push notification mechanisms (e.g., SMS, email, system notifications), and the execution results are recorded on the blockchain for subsequent audit and analysis. For example, if log file cleanup is successful, a notification email is sent to the operations personnel, and detailed information such as the number of files cleaned and the amount of freed disk space is recorded on the blockchain.

[0106] In this way, blockchain evidence storage ensures the tamper-proof and auditability of inspection records and operation and maintenance operations, and the automatic execution of smart contracts improves the automation level of the operation and maintenance process and reduces human errors.

[0107] In this embodiment, the semantic web module 15 generates fault risk labels by integrating knowledge and reasoning through ontology model reasoning based on operational data and local data from distributed nodes. The ontology model includes a triplet relationship between data field, sensitivity level, and business impact. Accordingly, the semantic web module 15 is specifically configured to generate fault risk labels based on the triplet relationship in the ontology model, operational data, and local data from distributed nodes using SWRL rules. The semantic web module 15 is specifically configured to convert the results of action effect analysis into target triples containing performance indicator changes and timestamps caused by the action type, and to use these target triples to update the target database data. Specifically, the ontology model is constructed as follows: Database domain knowledge is organized, covering database architecture (e.g., tables, fields, and indexes in relational databases; document structures and key-value storage in non-relational databases), operational operations (configuration parameter adjustment, backup and recovery, performance optimization), and fault types (connection anomalies, data loss, query timeouts). Key concepts, such as "database index," "transaction rollback," and "insufficient disk space failure," are extracted from database-related standard documents, professional books, academic papers, and internal enterprise operational manuals. Clarify the hierarchical and associative relationships between concepts. For example, "database index" is part of the "database schema," a "part-whole" relationship; "query timeout failure" is caused by "missing index," a "causal" relationship. Use ontology modeling languages ​​(such as OWL or WebOntology Language) to precisely describe these relationships. In OWL, hierarchical relationships are expressed by defining rdfs:subClassOf, such as <missing index>rdfs:subClassOf <database performance issue>. Causal relationships are described using custom object properties, such as <cause>rdf:type owl:ObjectProperty, and a triple relationship of <missing index> <cause> <query timeout failure> is established. Assign properties to each concept, including data properties and object properties. Data properties describe the inherent characteristics of a concept. For example, the properties of "database table" can include "table name" (data type: string) and "number of records" (data type: integer). Object properties are used to associate different concepts. For example, "database instance" is associated with "database table" through the "contains" object property. In OWL, define the data property rdf:type owl:DatatypeProperty and the object property <contains> rdf:type owl:ObjectProperty, and add attribute values ​​to the concepts, such as "user_info".

[0108] Furthermore, the Semantic Web module 15 forms a knowledge graph through semantic annotation. First, the data annotation tool is selected as follows. A professional semantic annotation tool is adopted, which provides a graphical interface to facilitate annotators to add semantic annotations to database-related data (such as log files, configuration files, and fault reports). For example, when opening a database fault report document in the semantic annotation tool, the annotator can select the fault type mentioned in the text (such as "deadlock") and then associate it with the "deadlock fault" concept defined in the ontology model. Unified annotation rules are formulated to ensure the accuracy and consistency of annotations. It is stipulated that for the annotation of database configuration parameters, information such as the parameter name, the database component to which it belongs, the current value, and the recommended value should be specified. For example, when annotating the innodb_buffer_pool_size parameter of the MySQL database, it is annotated as <innodb_buffer_pool_size> <parameter name> "innodb_buffer_pool_size", <innodb_buffer_pool_size> <database component> <MySQL storage engine>, <innodb_buffer_pool_size> <current value> "128M", <innodb_buffer_pool_size> <recommended value> "512M" (based on performance evaluation). The annotated data is converted into a knowledge graph. Each annotated concept, attribute, and relationship is stored in the form of triples, such as ("a certain database fault report", "contains fault type", "deadlock fault"), ("deadlock fault", "fault cause", "transaction concurrency conflict"). A graph database (such as Neo4j) is used to store these triples and construct a visual knowledge graph. In Neo4j, nodes and relationships are created through Cypher statements, such as CREATE (n:fault report{name: 'a certain database fault report'})-[:contains fault type]->(m:deadlock fault{description: 'lock dead phenomenon caused by transaction concurrency'}). An efficient reasoning engine, such as Pellet, is selected and integrated into the database intelligent patrol inspection system. The operating environment of the reasoning engine is configured to enable it to read the ontology model and knowledge graph data. The ontology model file path, the knowledge graph storage address, and the reasoning engine parameters (such as reasoning algorithm, reasoning depth) are specified in the system configuration file. For example, in a Java project, the Pellet API is used to load the ontology model, OntModel model = ModelFactory.createOntologyModel(PelletReasonerFactory.THE_SPEC); model.read("file:database_ontology.owl"); Reasoning rules are written according to database domain knowledge and operation and maintenance experience.For example, Rule 1 states: If the database's CPU usage is consistently above 80% and its memory usage is above 70%, then a resource contention issue may exist. This can be expressed in an inference rule language (such as SWRL, Semantic Web Rule Language) as follows: CPU usage (?cpu,?value1) ^ swrlb:greaterThan(?value1, 80) ^ Memory usage (?mem,?value2) ^ swrlb:greaterThan(?value2, 70) -> Resource contention issue (?db), where ?cpu, ?mem, and ?db are variables. The system collects database operation data in real time and, combined with existing information in the knowledge graph, triggers the inference engine to execute inference. The inference engine derives new knowledge based on the ontology model, knowledge graph, and inference rules. For example, according to the above rules, when the system detects CPU and memory usage data that meets the requirements, the inference engine concludes that a resource contention issue exists. The inference results are fed back to operations personnel and used to optimize database operations strategies. For example, the system automatically generates resource optimization suggestions based on the inference results, such as adjusting database cache configuration, optimizing query statements, etc.

[0109] In this way, the semantic web module realizes the deep integration and reasoning of operation and maintenance knowledge. The system can quickly and accurately obtain solutions from massive knowledge, improving the ability to diagnose and handle faults.

[0110] It can be seen that the present application discloses a distributed database inspection system, including: a data acquisition module, a federated learning module, a reinforcement learning module, a voiceprint recognition module, and a semantic web module, wherein the data acquisition module is used to collect the operating data of the distributed database, the local data of the distributed nodes, and the business data to obtain the target database data; the federated learning module is used to use the received structured target database data to perform collaborative inspection training of the local model between each distributed node, so as to output and upload the local model parameters to the central server, so that the local model parameters can be aggregated by the central server to obtain the global model parameters of the global model; the semantic web module is used to generate fault risk information based on the ontology model reasoning and the operating data and the local data of the distributed nodes. risk label; the reinforcement learning module is used to construct a state space based on the global model parameters, the parameter difference value between the local model parameters, the operating data, the local data of the distributed nodes, the business data, and the fault risk label, so as to generate an action instruction package according to the target instruction corresponding to the maximum reward value in the state space and the reward value table; the voiceprint recognition module is used to trigger the mandatory authentication process when receiving the action instruction package to obtain the mandatory authentication result, and select the instruction execution process or the authentication failure process according to the mandatory authentication result; the reinforcement learning module is used to calculate the reward value generated after the instruction is executed and update the reward value table; the semantic web module is used to analyze the action effect generated after the instruction is executed, so as to update the target database data based on the action effect analysis result. It can be seen that autonomous operation and maintenance strategy optimization is achieved through reinforcement learning, distributed database collaboration problems are solved by using federated learning, operation authentication security is improved by combining voiceprint recognition, and operation and maintenance automation and knowledge reasoning capabilities are improved with the help of semantic web technology, thereby ensuring the stable operation of the database and reducing operation and maintenance costs.

[0111] Reference Figure 2 As shown, the embodiment of the present invention further discloses a distributed database inspection method, including:

[0112] Step S11: collecting the distributed database's operating data, distributed node local data, and business data to obtain target database data;

[0113] Step S12: using the received structured target database data to perform collaborative inspection training of local models among the distributed nodes, so as to output and upload local model parameters to the central server, so as to aggregate the local model parameters through the central server to obtain global model parameters of the global model;

[0114] Step S13: Generate a fault risk label based on the operation data and the local data of the distributed nodes through ontology model reasoning;

[0115] Step S14: constructing a state space based on global model parameters, parameter differences between local model parameters, operating data, distributed node local data, business data, and fault risk labels, and generating an action instruction packet according to the state space and the target instruction corresponding to the maximum reward value in the reward value table;

[0116] Step S15: When the action instruction packet is received, the compulsory authentication process is triggered to obtain the compulsory authentication result, and the instruction execution process or the authentication failure process is selected according to the compulsory authentication result;

[0117] Step S16: Calculate the reward value generated after the instruction is executed and update the reward value table;

[0118] Step S17: Analyze the action effect generated after the instruction is executed, and update the target database data based on the action effect analysis result.

[0119] It can be seen that the present application discloses a distributed database inspection system, including: a data acquisition module, a federated learning module, a reinforcement learning module, a voiceprint recognition module, and a semantic web module, wherein the data acquisition module is used to collect the operating data of the distributed database, the local data of the distributed nodes, and the business data to obtain the target database data; the federated learning module is used to use the received structured target database data to perform collaborative inspection training of the local model between each distributed node, so as to output and upload the local model parameters to the central server, so that the local model parameters can be aggregated by the central server to obtain the global model parameters of the global model; the semantic web module is used to generate fault risk information based on the ontology model reasoning and the operating data and the local data of the distributed nodes. risk label; the reinforcement learning module is used to construct a state space based on the global model parameters, the parameter difference value between the local model parameters, the operating data, the local data of the distributed nodes, the business data, and the fault risk label, so as to generate an action instruction package according to the target instruction corresponding to the maximum reward value in the state space and the reward value table; the voiceprint recognition module is used to trigger the mandatory authentication process when receiving the action instruction package to obtain the mandatory authentication result, and select the instruction execution process or the authentication failure process according to the mandatory authentication result; the reinforcement learning module is used to calculate the reward value generated after the instruction is executed and update the reward value table; the semantic web module is used to analyze the action effect generated after the instruction is executed, so as to update the target database data based on the action effect analysis result. It can be seen that autonomous operation and maintenance strategy optimization is achieved through reinforcement learning, distributed database collaboration problems are solved by using federated learning, operation authentication security is improved by combining voiceprint recognition, and operation and maintenance automation and knowledge reasoning capabilities are improved with the help of semantic web technology, thereby ensuring the stable operation of the database and reducing operation and maintenance costs.

[0120] Furthermore, the embodiment of the present application also discloses an electronic device, Figure 3 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content in the diagram should not be considered as any limitation to the scope of application of the present application.

[0121] Figure 3 This is a schematic diagram of the structure of an electronic device 20 provided in an embodiment of the present application. The electronic device 20 may specifically include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 is used to store a computer program, which is loaded and executed by the processor 21 to implement the relevant steps of the distributed database inspection method disclosed in any of the aforementioned embodiments. Furthermore, the electronic device 20 in this embodiment may specifically be an electronic computer.

[0122] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and the external device. The communication protocol it follows is any communication protocol that can be applied to the technical solution of this application and is not specifically limited here; the input and output interface 25 is used to obtain external input data or output data to the outside world. Its specific interface type can be selected according to specific application needs and is not specifically limited here.

[0123] Among them, the processor 21 may include one or more processing cores, such as a 4-core processor, an 8-core processor, etc. The processor 21 can be implemented in at least one hardware form of DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). The processor 21 may also include a main processor and a coprocessor. The main processor is a processor for processing data in the awake state, also known as a CPU (Central Processing Unit); the coprocessor is a low-power processor for processing data in the standby state. In some embodiments, the processor 21 may be integrated with a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the display screen. In some embodiments, the processor 21 may also include an AI (Artificial Intelligence) processor, which is used to process computing operations related to machine learning.

[0124] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk or CD, etc. The resources stored thereon can include an operating system 221, a computer program 222, etc., and the storage method can be temporary storage or permanent storage.

[0125] The operating system 221 is used to manage and control the hardware devices and computer programs 222 on the electronic device 20, enabling the processor 21 to operate and process the massive amounts of data 223 in the memory 22. It can be Windows Server, NetWare, Unix, Linux, etc. In addition to including computer programs capable of implementing the distributed database inspection method performed by the electronic device 20 as disclosed in any of the aforementioned embodiments, the computer programs 222 may further include computer programs capable of performing other specific tasks. Data 223 may include data received by the electronic device from external devices, as well as data collected by its own input / output interface 25.

[0126] Furthermore, this application also discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, the distributed database inspection method disclosed above is implemented. For the specific steps of this method, please refer to the corresponding content disclosed in the above embodiments and will not be repeated here.

[0127] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from the other embodiments. Reference can be made to the descriptions of the identical or similar parts between the various embodiments. For the devices disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple, and the relevant parts can be referred to the descriptions of the methods.

[0128] Professionals may further appreciate that the units and algorithmic steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in terms of function in the above description. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application. The steps of the method or algorithm described in conjunction with the embodiments disclosed herein can be implemented directly using hardware, a software module executed by a processor, or a combination of the two. The software module can be placed in a random access memory RAM (Random Access Memory), memory, read-only memory ROM (Read Only Memory), electrically programmable EPROM (Electrically Programmable Read Only Memory), electrically erasable programmable EEPROM (Electric Erasable Programmable Read Only Memory), registers, hard disk, removable disk, CD-ROM (Compact Disc-Read Only Memory), or any other form of storage medium known in the technical field.

[0129] Finally, it should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of additional identical elements in the process, method, article, or device comprising the element.

[0130] The above is a detailed introduction to the solution provided by the present invention. Specific examples are used herein to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only used to help understand the method of the present invention and its core ideas. At the same time, for those skilled in the art, according to the ideas of the present invention, there may be changes in the specific implementation methods and application scopes. In summary, the contents of this specification should not be understood as limiting the present invention.

Claims

1. A distributed database inspection system, characterized in that: include: Data acquisition module, federated learning module, reinforcement learning module, voiceprint recognition module, semantic network module, among which, The data acquisition module is used to collect the operating data of the distributed database, the local data of the distributed nodes and the business data to obtain the target database data; The federated learning module is configured to use the received structured target database data to perform collaborative inspection training of local models among the distributed nodes, so as to output and upload local model parameters to a central server, so that the local model parameters are aggregated by the central server to obtain global model parameters of the global model; The semantic web module is configured to generate a fault risk label based on the operation data and the local data of the distributed nodes through ontology model reasoning; The reinforcement learning module is configured to construct a state space based on the global model parameters, the parameter difference values ​​between the local model parameters, the operating data, the distributed node local data, the service data, and the fault risk label, so as to generate an action instruction packet according to the state space and the target instruction corresponding to the maximum reward value in the reward value table; The voiceprint recognition module is configured to trigger a compulsory authentication process upon receiving the action instruction packet to obtain a compulsory authentication result, and select an instruction execution process or an authentication failure process according to the compulsory authentication result; The reinforcement learning module is used to calculate the reward value generated after the instruction is executed and update the reward value table; The semantic web module is used to analyze the action effects produced after the instruction is executed, so as to update the target database data based on the action effect analysis results.

2. The distributed database inspection system according to claim 1, characterized in that: Also includes: The digital watermark module is used to embed a digital watermark into the action log generated after the instruction is executed, and transmit the action log carrying the digital watermark to the blockchain module.

3. The distributed database inspection system according to claim 2, characterized in that: The digital watermark module is specifically used to embed a digital watermark containing the operation time and node identifier into the action log generated after the instruction is executed, and detect the integrity of the digital watermark through the Hamming distance, so as to transmit the action log that has passed the watermark integrity verification to the blockchain module.

4. The distributed database inspection system according to claim 2, characterized in that: Also includes: The blockchain module is used to obtain the action effect analysis results, package the action logs carrying digital watermarks and the action effect analysis results as evidence, and store them in the operation and maintenance database.

5. The distributed database inspection system according to claim 1, characterized in that: The ontology model includes a triple relationship of data field, sensitivity level, and business impact; Correspondingly, the semantic web module is specifically configured to generate a fault risk label through SWRL rules and based on the triple relationship of the ontology model, the operation data and the distributed node local data.

6. The distributed database inspection system according to claim 1, characterized in that: The voiceprint recognition module is specifically used to extract the current voiceprint features using Mel-frequency cepstral coefficients when receiving the action instruction package, and calculate the similarity between the current voiceprint features and the voiceprint feature template through a dynamic time warping algorithm to determine the mandatory authentication result based on the similarity.

7. The distributed database inspection system according to claim 1, characterized in that: The semantic web module is specifically used to convert the action effect analysis results into target triples containing performance indicator changes caused by the action type and timestamps, and use the target triples to update the target database data.

8. A distributed database inspection method, characterized in that: include: Collect the operating data of the distributed database, local data of distributed nodes and business data to obtain the target database data; Using the received structured target database data to perform collaborative inspection training of local models among the distributed nodes, so as to output and upload local model parameters to a central server, so as to aggregate the local model parameters through the central server to obtain global model parameters of the global model; generating a fault risk label based on the operation data and the local data of the distributed nodes through ontology model reasoning; A state space is constructed based on the global model parameters, the parameter difference value between the local model parameters, the operating data, the distributed node local data, the business data, and the fault risk label, so as to generate an action instruction packet according to the state space and the target instruction corresponding to the maximum reward value in the reward value table; When the action instruction packet is received, a compulsory authentication process is triggered to obtain a compulsory authentication result, and an instruction execution process or an authentication failure process is selected according to the compulsory authentication result; Calculate the reward value generated after the instruction is executed and update the reward value table; Analyze the action effect produced after the instruction is executed to update the target database data based on the action effect analysis results.

9. An electronic device, characterized in that: include: Memory, used to store computer programs; A processor is configured to execute the computer program to implement the steps of the distributed database inspection method according to claim 8.

10. A computer-readable storage medium, characterized in that Used to store computer programs; wherein, when the computer program is executed by a processor, the steps of the distributed database inspection method according to claim 8 are implemented.

Images