Fire protection maintenance data distributed storage method based on blockchain

Abstract

The application discloses a fire-fighting maintenance data distributed storage method based on a block chain and belongs to the technical field of block chain data storage. The method comprises the following steps: acquiring a fire-fighting maintenance data set, decoupling data features of the fire-fighting maintenance data set, and obtaining a plurality of fire-fighting maintenance data feature components; storing path planning of the plurality of fire-fighting maintenance data feature components in a preset block chain node network according to an improved Dijkstra algorithm to obtain a plurality of feature component storage paths, wherein the improved Dijkstra algorithm is based on dynamic adjustment of path edge weight values according to historical storage loads of nodes and network delays between nodes; and storing the plurality of fire-fighting maintenance data feature components to a plurality of target storage nodes in the block chain node network according to the plurality of feature component storage paths to obtain a distributed storage index corresponding to the fire-fighting maintenance data set.

Description

Technical Field

[0001] This invention relates to the field of blockchain data storage technology, specifically a distributed storage method for fire protection maintenance data based on blockchain. Background Technology

[0002] Fire protection maintenance operations generate a large amount of data, including equipment identification, maintenance time, maintenance personnel, maintenance operations, maintenance results, and equipment status. This data needs to be stored securely and reliably for subsequent verification. Existing fire protection maintenance data storage often uses blockchain technology, ensuring data immutability by writing each maintenance record as a whole into a block.

[0003] Writing fire protection maintenance data as a whole into the blockchain has significant drawbacks. Fire protection maintenance data is a typical example of multi-dimensional heterogeneous data. Different dimensions of data vary greatly in access frequency, reading patterns, and update characteristics. The overall storage method bundles heterogeneous data together, lacking fine-grained storage management tailored to the characteristics of different dimensions, resulting in overly coarse-grained distributed storage. When a certain type of maintenance data needs to be frequently retrieved, the complete record containing all dimensions of information must be read, causing a large amount of irrelevant data to be transmitted over the network, wasting the network bandwidth and storage input / output resources of blockchain nodes.

[0004] Existing blockchain storage solutions typically allocate data based on preset fixed rules or simple random selection strategies, failing to consider real-time changes in node load and dynamic fluctuations in network transmission conditions. When some blockchain nodes experience a rapid increase in storage load due to continuous reception of maintenance data, static path planning mechanisms may still continuously direct newly generated data to these high-load nodes, resulting in severely unbalanced storage distribution. Furthermore, the instantaneous increase in network latency between nodes is not incorporated into path selection, potentially causing data to be transmitted via high-latency links, thus prolonging storage confirmation time.

[0005] To address the aforementioned issues, it is necessary to start with the multidimensional differences in the fire protection maintenance data itself, and to perform fine-grained feature decoupling of the data, enabling data from different dimensions to flow independently and be stored separately. It is also necessary to solve the problem of how to plan the optimal storage path for each decoupled feature component in real time under dynamically changing node loads and network latency environments, thereby achieving a dynamic balance in the allocation of storage load and network resources. Summary of the Invention

[0006] The purpose of this invention is to provide a distributed storage method for fire protection maintenance data based on blockchain. By decoupling the fire protection maintenance data with fine-grained features and dynamically adjusting the edge weights of the path planning based on the historical storage load of nodes and network latency, data of different feature components can be independently and distributed along the optimal path. This solves the problems of excessively coarse data storage granularity and path planning that cannot adapt to the dynamic changes of nodes and networks in the prior art, which leads to uneven storage distribution and reduced transmission efficiency.

[0007] The objective of this invention can be achieved through the following technical solutions:

[0008] This invention provides a blockchain-based distributed storage method for fire protection maintenance data. The method includes: acquiring a fire protection maintenance data set; decoupling the data features of the fire protection maintenance data set to obtain multiple fire protection maintenance data feature components; planning storage paths for the multiple fire protection maintenance data feature components in a preset blockchain node network according to an improved Dijkstra algorithm to obtain multiple feature component storage paths, wherein the improved Dijkstra algorithm dynamically adjusts the path edge weights based on the historical storage load of nodes and the network latency between nodes; and distributively storing the multiple fire protection maintenance data feature components to multiple target storage nodes in the blockchain node network according to the multiple feature component storage paths to obtain a distributed storage index corresponding to the fire protection maintenance data set.

[0009] By decoupling fire protection maintenance data into multiple feature components and storing them separately on different blockchain nodes, excessive storage pressure on a single node can be avoided. The improved Dijkstra algorithm dynamically adjusts edge weights by integrating historical load and network latency when planning paths, ensuring that data always tends to be stored on links with lighter loads and lower latency. This balances the storage burden of each node globally, effectively reducing network transmission latency during storage and improving the throughput and reliability of the distributed storage system. The establishment of a distributed storage index ensures the restoreability and retrieval of data after data sharding.

[0010] As a preferred technical solution of the present invention, the process of obtaining and merging the fire protection maintenance dataset and decoupling the data features of the fire protection maintenance dataset specifically includes: serializing and recombining the fire protection maintenance dataset according to timestamps to obtain a fire protection maintenance time-series data sequence; identifying the data type of the time-series data sequence to determine multiple fire protection maintenance data types, such as equipment identification type, maintenance time type, maintenance personnel type, maintenance operation type, maintenance result type, and equipment status type; using the multiple fire protection maintenance data types as decoupling dimensions, extracting the data subset corresponding to each fire protection maintenance data type from the fire protection maintenance time-series data sequence, and taking the data subset corresponding to each fire protection maintenance data type as a fire protection maintenance data feature component to obtain the multiple fire protection maintenance data feature components. In this way, the originally mixed fire protection maintenance records are split into data clusters with independent semantics, which facilitates the allocation of differentiated storage strategies according to the access frequency and importance of the data.

[0011] In the storage path planning stage, this invention uses an improved Dijkstra algorithm for refined path selection. In a preferred implementation, node states are collected from a pre-defined blockchain node network to obtain the current storage load of each blockchain node and the network latency between any two blockchain nodes. A node state vector is constructed for each blockchain node, containing the current storage load and the node's historical storage load. Based on the node state vector and the network latency, dynamic edge weights are dynamically calculated for each link between nodes in the blockchain node network. These dynamic edge weights are positively correlated with both the current storage load and the network latency. The dynamic edge weights are used as inputs to the improved Dijkstra algorithm. Starting from the source node of each fire protection and maintenance data feature component and with all nodes in the blockchain node network as candidate endpoints, the improved Dijkstra algorithm is run to output the storage path that minimizes the cumulative edge weight for each fire protection and maintenance data feature component. Furthermore, the node state vector may also include the available storage capacity and the number of successful storage operations in the node's history. The dynamic edge weights are also negatively correlated with both the available storage capacity and the number of successful storage operations in the node's history. This results in nodes with ample remaining space and a historically high storage success rate having smaller edge weights in path planning, and data will be preferentially directed to these more reliable nodes.

[0012] To more accurately reflect the dynamic trend of node load changes, when calculating dynamic edge weights, the first current storage load and the first historical storage load of the first blockchain node, as well as the second current storage load and the second historical storage load of the second blockchain node, can be extracted from the node state vector. The first load change rate between the first current storage load and the first historical storage load is calculated, and the second load change rate between the second current storage load and the second historical storage load is also calculated. The inter-node network latency between the first and second blockchain nodes is obtained. The first load change rate, the second load change rate, and the inter-node network latency are then input into a preset dynamic edge weight calculation model, which outputs the dynamic edge weights of the link between the first and second blockchain nodes. By introducing the load change rate, path planning can predict the future load trend of nodes and promptly increase the path cost for nodes with rapidly increasing loads, thereby avoiding load overshoot caused by subsequent data influx and achieving forward-looking adaptive load adjustment.

[0013] As another preferred dynamic edge weight adjustment scheme, the improved Dijkstra algorithm can also perform more comprehensive cost modeling based on the historical storage load sequence of nodes and network latency statistics. Specifically, the historical storage load sequence of each blockchain node in the blockchain node network is obtained, which includes the storage load values ​​at multiple historical time points within a preset time window; load trend analysis is performed on the historical storage load sequence of each blockchain node to calculate the load growth rate and load fluctuation variance of each blockchain node; simultaneously, the real-time network latency and network latency jitter values ​​between every two blockchain nodes in the network are obtained. For the directed link from the first blockchain node to the second blockchain node, the storage cost factor is calculated based on the load growth rate and load fluctuation variance of the second blockchain node, and the transmission cost factor is calculated based on the real-time network latency and network latency jitter values ​​between the first and second blockchain nodes; the storage cost factor and the transmission cost factor are weighted and summed to obtain the dynamic edge weight of the directed link. Among them, the storage cost factor is positively correlated with the load growth rate and load fluctuation variance of the second blockchain node, and the transmission cost factor is positively correlated with the real-time network latency and network latency jitter values. During the algorithm's operation, whenever a fire protection and maintenance data feature component is successfully stored to the target node, the historical storage load sequence of the affected blockchain nodes is updated, the dynamic edge weights are recalculated, and storage paths are planned for the remaining fire protection and maintenance data feature components using the updated edge weights. This method of gradually updating edge weights ensures that each path decision is based on the latest network-wide load status, effectively avoiding instantaneous congestion caused by multiple paths simultaneously converging on the same node.

[0014] In the actual data storage stage, distributed storage is performed according to the planned feature component storage path, and an index is generated. Preferably, the first fire protection maintenance data feature component is sent to the first target storage node according to the first feature component storage path, and the first storage confirmation information and the first storage location identifier returned by the node are received; the second fire protection maintenance data feature component is sent to the second target storage node according to the second feature component storage path, and the second storage confirmation information and the second storage location identifier returned by the node are received; the first storage confirmation information, the first storage location identifier, the second storage confirmation information, and the second storage location identifier are aggregated to generate a distributed storage index corresponding to the fire protection maintenance data set. Further, the distributed storage index is organized using a Merkle tree structure, and the leaf nodes of the Merkle tree store the hash value of the storage location identifier and the storage confirmation information corresponding to each fire protection maintenance data feature component. Using the Merkle tree structure to store the index can achieve partial data integrity verification and reliable traceability with relatively small storage overhead.

[0015] Upon receiving storage confirmation information from the target storage node, a data storage request carrying a first fire protection maintenance data feature component and a first feature component type tag can be sent to the first target storage node. After completing local storage, the first target storage node returns first storage confirmation information containing its identity certificate and storage timestamp. This confirmation information is parsed to extract the first storage location identifier assigned by the first target storage node to the first fire protection maintenance data feature component. This first storage location identifier includes the block height and transaction hash value. This identification method directly utilizes the blockchain's own addressing capabilities, giving subsequent data retrieval native trust.

[0016] For the generation of data subsets in data decoupling, this invention provides a specific method: Each fire protection maintenance record in the fire protection maintenance time-series data sequence is parsed to obtain the corresponding equipment identifier field value, maintenance time field value, maintenance personnel field value, maintenance operation field value, maintenance result field value, and equipment status field value for each record. The equipment identifier field values ​​of all records are aggregated into a data subset corresponding to the equipment identifier type. Similarly, data subsets corresponding to maintenance time type, maintenance personnel type, maintenance operation type, maintenance result type, and equipment status type are aggregated respectively. This vertical splitting by field dimension results in high aggregation of values ​​of the same type, higher compression efficiency, and facilitates subsequent access control by type.

[0017] After obtaining the distributed storage index, this invention also provides an efficient data retrieval and reorganization mechanism. The mechanism receives a retrieval request for target fire protection maintenance data, which carries the data identifier of the target fire protection maintenance data. Based on the distributed storage index, it queries multiple target storage node addresses and multiple storage location identifiers corresponding to the target fire protection maintenance data. Data retrieval requests carrying the corresponding storage location identifiers are sent in parallel to these target storage node addresses. The system receives fire protection maintenance data feature components returned by each target storage node, and reorganizes all received fire protection maintenance data feature components according to the feature component association relationships recorded in the distributed storage index to obtain the target fire protection maintenance data. Specifically, the reorganization process is as follows: First fire protection maintenance data feature components corresponding to the first storage location identifier and second fire protection maintenance data feature components corresponding to the second storage location identifier are extracted from the distributed storage index; the fire protection maintenance data types of both are identified; the field arrangement order of each data type in the original fire protection maintenance data record is determined according to a preset data type assembly template; the first fire protection maintenance data feature components and the second fire protection maintenance data feature components are concatenated into a single fire protection maintenance data record according to the field arrangement order; this concatenation process is repeated until a complete fire protection maintenance data set is generated as the target fire protection maintenance data. By maintaining type relationships and assembly templates in the index, the original data view can be restored quickly and without loss, even if the data is scattered across different nodes, thus meeting the dual requirements of data integrity and timeliness in scenarios such as fire rescue and maintenance audit.

[0018] The beneficial effects of this invention are:

[0019] Data feature decoupling is performed on the fire protection maintenance dataset. Using multi-dimensional data types such as equipment identification, maintenance time, maintenance personnel, maintenance operations, maintenance results, and equipment status as decoupling dimensions, subsets of each data type are extracted from the fire protection maintenance time-series data sequence, forming multiple independent fire protection maintenance data feature components. This decoupling method changes the coarse-grained processing mode of directly storing maintenance data as a whole record. It decomposes the originally intertwined multi-dimensional data into independent feature component units, allowing maintenance information of different dimensions to exist and flow independently, free from the overall constraints of the original record. Each feature component has independent storage and retrieval attributes and can be scheduled to different blockchain nodes for distributed storage. This avoids the bundled transmission of irrelevant dimension data in a single storage or retrieval operation. The granularity of data storage is refined from the entire record to a single feature dimension, and the amount of data transmitted between nodes is precisely controlled. The distributed storage of each type of data component also means that accessing data for a specific dimension no longer depends on reading the entire record, reducing the network transmission and storage input / output consumption of redundant data.

[0020] In the storage path planning stage, the node status of the pre-defined blockchain node network is collected to obtain the current storage load and historical storage load sequence of each node. Combined with real-time network latency and network latency jitter values ​​between nodes, the edge weights of each link between nodes are dynamically calculated, ensuring that the edge weights are positively correlated with the target node's storage load growth rate, load fluctuation variance, and link network latency. The improved Dijkstra algorithm uses these dynamic edge weights as input to perform path search, outputting the storage path that minimizes the cumulative edge weight for each fire protection and maintenance data feature component. Real-time changes in node storage load and fluctuations in network latency are directly converted into transient adjustment factors for path weights. The storage paths generated by the algorithm can automatically avoid nodes and links with rapidly increasing storage load or sudden increases in network latency. When a node experiences increased load due to storing a large amount of data, the edge weight of the link pointing to that node increases accordingly. In subsequent path planning, the algorithm naturally reduces the priority of allocating data to that node, directing data to nodes with lighter loads and lower latency. This continuously achieves a dynamic balance in the distribution of storage load and network transmission pressure among nodes during continuous storage task execution. Attached Figure Description

[0021] The invention will now be further described with reference to the accompanying drawings.

[0022] Figure 1 This is a flowchart of a blockchain-based distributed storage method for fire protection maintenance data.

[0023] Figure 2 This is a flowchart of the method for extracting feature components from fire protection maintenance data;

[0024] Figure 3 This is a flowchart of the dynamic edge weight calculation and update process of the improved Dijkstra algorithm;

[0025] Figure 4 This is a flowchart of the distributed storage and index generation process for fire protection maintenance data feature components; Detailed Implementation

[0026] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. 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.

[0027] See Figure 1This invention provides a blockchain-based distributed storage method for fire protection maintenance data. The core of this method is as follows: First, a fire protection maintenance data set is acquired, and its data features are decoupled to obtain multiple fire protection maintenance data feature components. Then, based on an improved Dijkstra algorithm, storage paths are planned for these fire protection maintenance data feature components in a pre-defined blockchain node network. This improved Dijkstra algorithm dynamically adjusts the path edge weights based on the historical storage load of nodes and the network latency between nodes, ultimately obtaining multiple feature component storage paths. Finally, according to the planned multiple feature component storage paths, the multiple fire protection maintenance data feature components are distributed and stored to multiple target storage nodes in the blockchain node network, thereby obtaining a distributed storage index corresponding to the fire protection maintenance data set.

[0028] In specific implementation, please refer to Figure 2 The process involves obtaining a fire protection maintenance dataset. This dataset consists of multiple fire protection maintenance records, each containing at least a timestamp field and several attribute fields. When serializing and reassembling the dataset according to its timestamps, the timestamp field value of each record is parsed. All records are then sorted in ascending order based on their timestamp values, resulting in a time-series fire protection maintenance data sequence. If different fire protection maintenance records have different timestamp formats, they are converted to Coordinated Universal Time (UTC) format before the sorting operation.

[0029] In some embodiments, data type identification is performed on the fire protection maintenance time-series data sequence to determine multiple fire protection maintenance data types. The identification process is implemented through a preset data type dictionary, which defines a set of keywords for equipment identification type, maintenance time type, maintenance personnel type, maintenance operation type, maintenance result type, and equipment status type. The field names of each fire protection maintenance record in the fire protection maintenance time-series data sequence are matched with the keywords in the data type dictionary; successfully matched fields are categorized into their corresponding fire protection maintenance data type. After traversing the fire protection maintenance time-series data sequence, all fire protection maintenance data types contained within the sequence are determined. These all fire protection maintenance data types include equipment identification type, maintenance time type, maintenance personnel type, maintenance operation type, maintenance result type, and equipment status type.

[0030] It is understandable that among the multiple identified fire protection maintenance data types, each fire protection maintenance data type corresponds to an independent attribute dimension in the fire protection maintenance record, and the attribute dimensions are different between different types of fire protection maintenance data.

[0031] In practical implementation, using the aforementioned multiple fire protection maintenance data types as decoupling dimensions, a data subset corresponding to each fire protection maintenance data type is extracted from the fire protection maintenance time-series data sequence. The extraction process involves performing field parsing on each fire protection maintenance record in the fire protection maintenance time-series data sequence to obtain the equipment identifier field value, maintenance time field value, maintenance personnel field value, maintenance operation field value, maintenance result field value, and equipment status field value corresponding to each fire protection maintenance record. The data subsets corresponding to the equipment identification field, maintenance time, maintenance personnel, maintenance operation, maintenance result, and equipment status are aggregated from all fire protection maintenance records. Each subset represents a fire protection maintenance data feature component, resulting in multiple fire protection maintenance data feature components.

[0032] Optionally, when performing field parsing, if the fire protection maintenance record uses a structured data format, such as JSON or key-value pair format, the field value is directly extracted from the corresponding field name; if the fire protection maintenance record uses a semi-structured text format, pre-compiled regular expressions are used to match and extract the equipment identification field value, maintenance time field value, maintenance personnel field value, maintenance operation field value, maintenance result field value, and equipment status field value.

[0033] Optionally, during the aggregation process to generate each data subset, the inherent temporal order of the fire protection maintenance time-series data sequence is preserved. This ensures that the order of the equipment identifier field values ​​within the data subset corresponding to the equipment identifier type, the maintenance time field values ​​within the data subset corresponding to the maintenance time type, the maintenance personnel field values ​​within the data subset corresponding to the maintenance personnel type, the maintenance operation field values ​​within the data subset corresponding to the maintenance operation type, the maintenance result field values ​​within the data subset corresponding to the maintenance result type, and the equipment status field values ​​within the data subset corresponding to the equipment status type are all consistent with the chronological order of the fire protection maintenance records in the fire protection maintenance time-series data sequence. Multiple fire protection maintenance data feature components thus retain their original temporal relationships.

[0034] In practice, the pre-defined blockchain node network is monitored to collect node status data, obtaining the current storage load of each blockchain node and the network latency between each blockchain node. A monitoring agent is deployed within the blockchain node network. This agent periodically reads disk usage, memory utilization, and CPU wait queue length from the operating system interface of each blockchain node. The weighted average of these three metrics is used as the current storage load of the corresponding blockchain node. Simultaneously, the monitoring agent controls each blockchain node to periodically send Internet Control Message Protocol (ICP-IP) echo request packets to other blockchain nodes in the network. The round-trip time from sending the request packet to receiving the response packet is recorded, and the round-trip time measured in the most recent period is used as the inter-node network latency between the two blockchain nodes.

[0035] In some embodiments, the current storage load is calculated as follows: The weighting factor for disk utilization is... The weighting factor for memory usage is The weighting factor for the length of the central processing unit's wait queue is The three weighting coefficients satisfy Weighting coefficients The value is 0.5, and the weighting coefficient is... The value is 0.3, and the weighting coefficient is... The value is set to 0.2. The basis for the above weighting coefficient is that disk input / output performance has a greater impact on the storage process of blockchain nodes than memory resource usage and central processing unit scheduling pressure. Disk utilization is the core indicator of storage load, so it is given the highest weight.

[0036] In practice, a node state vector is constructed for each blockchain node. This vector includes the current storage load and the node's historical storage load. The historical storage load is extracted from the historical load time series of the blockchain node: multiple historical load samples within past time windows are read from the load log maintained locally by the blockchain node, and the arithmetic mean of these samples is calculated. This result is used as the node's historical storage load. The node state vector also includes each blockchain node's available storage capacity and the number of successful storage operations in the past. Available storage capacity is obtained from the blockchain node's local storage management module, representing the remaining allocatable storage space. The number of successful storage operations in the past is statistically obtained from the operation log maintained by the blockchain node, representing the cumulative number of times the blockchain node has successfully completed data storage tasks within past time windows.

[0037] Based on the node state vector and network latency, dynamic edge weights are dynamically calculated for each link between nodes in the pre-defined blockchain node network. Dynamic edge weights are positively correlated with current storage load and network latency, negatively correlated with available storage capacity, and negatively correlated with the number of successful storage operations in a node's history.

[0038] Optionally, the calculation process for dynamic edge weights includes the following steps:

[0039] Extract the first current storage load and the first historical storage load from the node state vector of the first blockchain node, and extract the second current storage load and the second historical storage load from the node state vector of the second blockchain node.

[0040] Calculate the first load change rate between the first current storage load and the first node's historical storage load. The first load change rate is calculated as follows: the ratio obtained by subtracting the first node's historical storage load from the first current storage load and then dividing by the first node's historical storage load.

[0041] The second load change rate is calculated by subtracting the second node's historical storage load from the second current storage load and then dividing by the second node's historical storage load.

[0042] Obtain the inter-node network latency between the first blockchain node and the second blockchain node;

[0043] Extract the available storage capacity and the number of successful storage operations in the history of the node from the node state vector of the second blockchain node;

[0044] Input the first load change rate, the second load change rate, the network latency between nodes, the available storage capacity, and the number of successful storage records in the history of the node into the preset dynamic edge weight calculation model. The dynamic edge weight calculation model outputs the dynamic edge weight of the link between the first blockchain node and the second blockchain node.

[0045] The expression for the dynamic edge weight calculation model is:

[0046]

[0047] in, This represents the dynamic edge weight of the directed link from the first blockchain node i to the second blockchain node j; Indicates the first load change rate; Indicates the second load change rate; This represents the inter-node network latency between the first blockchain node i and the second blockchain node j; This represents the available storage capacity of the second blockchain node j; This represents the number of times the second blockchain node j has successfully stored data in its history. The first load change rate weighting factor has a value range between 0 and 1, specifically 0.15. It is obtained by analyzing the influence of edge weights on the single variable of load change rate in offline testing and selecting the value that maximizes the accuracy of path selection. The second load change rate weighting factor ranges from 0 to 1, specifically 0.25. It is obtained by analyzing the impact of edge weights on the single variable of target node load change rate during offline testing, selecting the value that maximizes path selection accuracy. The value is greater than The basis for this is that the load change of the target node, i.e. the second blockchain node, has a greater impact on the quality of the storage path than the load change of the source node, i.e. the first blockchain node. This is a latency weighting factor, ranging from 0 to 1, specifically 0.35. It is obtained by measuring the storage success rate of multiple links in the blockchain node network under different latency conditions, and selecting the value that maximizes the storage success rate. The value is taken as the maximum value among all weight factors, based on the fact that the network latency between nodes has the greatest impact on data block transmission and consensus integrity. This is the capacity weighting factor, with a value between 0 and 1, specifically 0.15. It is obtained by statistically analyzing the probability distribution of target nodes being successfully selected as storage nodes under different available capacities, and selecting the value that makes the probability distribution closest to the ideal load balancing target. The success rate weighting factor ranges from 0 to 1, specifically 0.10. It is obtained by analyzing the correlation coefficient between the node's historical successful storage count and node stability, selecting the weight value that maximizes the correlation coefficient. All five weighting factors satisfy the following constraints. .

[0048] It is understandable that dynamic edge weights In the calculation, the first load change rate Second load change rate All coefficients are positive, indicating a positive correlation between the current storage load and dynamic edge weights; inter-node network latency. The coefficient is positive, indicating a positive correlation between network latency and dynamic edge weights; available storage capacity The coefficient is negative, indicating a negative correlation between available storage capacity and dynamic edge weights; the number of successful storage operations in the node's history. The coefficient is negative, indicating that the number of successful historical storages of a node is negatively correlated with the dynamic edge weight.

[0049] In practical implementation, dynamic edge weights are used as the input edge weights for the improved Dijkstra algorithm. The source node of each fire maintenance data feature component is taken as the starting point, and the source node is the blockchain node initiating the storage operation; all nodes in the blockchain node network are candidate endpoints. When running the improved Dijkstra algorithm, the algorithm maintains a set of nodes with determined shortest paths and a set of nodes with undetermined shortest paths. In each iteration, a node with the smallest cumulative edge weight from the undetermined shortest path node set to the starting point is selected and added to the set of nodes with determined shortest paths. The cumulative edge weights of its adjacent nodes to the starting point are updated based on this node. The updated adjacent link weights are the dynamic edge weights calculated using the dynamic edge weight calculation model. For each fire maintenance data feature component, the algorithm outputs the storage path that minimizes the cumulative edge weight, which is used as the feature component storage path. This process is repeated to obtain multiple feature component storage paths corresponding to multiple fire maintenance data feature components.

[0050] In specific implementation, please refer to Figure 3 The improved Dijkstra algorithm dynamically adjusts path edge weights based on node historical storage load and inter-node network latency, and includes the following implementation steps:

[0051] This process retrieves the historical storage load sequence for each blockchain node in the blockchain node network. Each blockchain node maintains a local load log database, which records the storage load value of the blockchain node at various past moments, indexed by timestamps. The storage load value is expressed as a percentage of the node's storage space usage. With a preset time window set to the past 24 hours and a sampling period set to 5 minutes, the historical storage load sequence contains the storage load values ​​for 288 sampling points within the preset time window. If a blockchain node has been running for less than 24 hours, the historical storage load sequence includes the storage load values ​​for all sampling periods from the node's startup time to the current time. When retrieving the historical storage load sequence, all storage load values ​​within the preset time window are read from the load log database in ascending chronological order, forming an ordered numerical sequence.

[0052] Load trend analysis is performed on the historical storage load sequence of each blockchain node to calculate the load growth rate and load volatility variance of each node. The load growth rate reflects the long-term trend of the storage load of the blockchain node, while the load volatility variance reflects the short-term stability of the storage load.

[0053] In practice, the load growth rate is calculated using a linear regression method. Each sampled data point in the historical storage load sequence is represented as a two-dimensional coordinate, with the horizontal axis representing the sampling sequence number and the vertical axis representing the storage load value. The sampling sequence number starts from 1 and increases in ascending order according to the sampling time. A least-squares linear fit is performed on all 288 two-dimensional coordinate points, and the slope of the fitted line is the load growth rate. Let the load growth rate be... When the slope of the fitted line is positive, it indicates that the storage load of the blockchain node is increasing; when the slope of the fitted line is negative, it indicates that the storage load of the blockchain node is decreasing.

[0054] Load fluctuation variance is calculated using the variance formula. First, the arithmetic mean of 288 storage load values ​​in the historical storage load sequence is calculated. Then, the deviation of each storage load value from the arithmetic mean is calculated. The squares of the 288 deviations are then summed, and the result is divided by 288. The result is the load fluctuation variance. The larger the load fluctuation variance value, the more unstable the storage load of the blockchain node is within the preset time window.

[0055] This program obtains the real-time network latency and network latency jitter between any two blockchain nodes in the blockchain node network. Real-time network latency is obtained as follows: the source blockchain node sends a timestamped probe data packet to the target blockchain node; the target blockchain node immediately sends back an acknowledgment data packet upon receiving the probe data packet; the source blockchain node records the round-trip time from sending the probe data packet to receiving the acknowledgment data packet, and uses the most recently measured round-trip time as the real-time network latency between the two blockchain nodes. Network latency jitter is obtained as follows: the source blockchain node maintains the most recent 30 round-trip time measurements within a sliding window, calculates the standard deviation of these 30 measurements, and uses the calculated result as the network latency jitter between the two blockchain nodes. When the number of historical measurements is less than 30, the standard deviation of all currently recorded round-trip time measurements is used as the network latency jitter value.

[0056] For the directed link from the first blockchain node to the second blockchain node, a storage cost factor is calculated based on the load growth rate and load fluctuation variance of the second blockchain node. The storage cost factor is positively correlated with both the load growth rate and load fluctuation variance of the second blockchain node. The storage cost factor is calculated as follows: multiply the load growth rate of the second blockchain node by a preset first storage adjustment coefficient to obtain a first intermediate value; multiply the load fluctuation variance of the second blockchain node by a preset second storage adjustment coefficient to obtain a second intermediate value; add the first intermediate value and the second intermediate value to obtain the storage cost factor. The first storage adjustment coefficient ranges from 0.3 to 0.5, specifically 0.4; the second storage adjustment coefficient ranges from 0.1 to 0.3, specifically 0.2. The first storage adjustment coefficient is set at 0.4 because, through analysis of load change data of different types of nodes in the blockchain network during historical storage tasks, it was found that the linear influence coefficient of the load growth rate on the success rate of storage tasks is approximately 0.38 to 0.42, and the median value is taken as the coefficient. The second storage adjustment coefficient is set at 0.2 because the impact of load fluctuation variance on the success rate of storage tasks is about half that of the impact of load growth rate.

[0057] Simultaneously, a transmission cost factor is calculated based on the real-time network latency and network latency jitter values ​​between the first and second blockchain nodes. The transmission cost factor is positively correlated with both real-time network latency and network latency jitter. The calculation method is as follows: multiply the real-time network latency by a preset first transmission adjustment coefficient to obtain a third intermediate value; multiply the network latency jitter value by a preset second transmission adjustment coefficient to obtain a fourth intermediate value; and add the third and fourth intermediate values ​​to obtain the transmission cost factor. The first transmission adjustment coefficient ranges from 0.6 to 0.8, specifically 0.7; the second transmission adjustment coefficient ranges from 0.2 to 0.4, specifically 0.3. The reason for choosing a first transmission adjustment coefficient of 0.7 is that real-time network latency is a core factor affecting data transmission time and block consensus efficiency. By analyzing the attenuation relationship between network latency and data transmission success rate, it is determined that the weight allocation should reflect the dominant role of real-time network latency.

[0058] The dynamic edge weights of the directed link from the first blockchain node to the second blockchain node are obtained by weighted summation of the storage cost factor and the transmission cost factor. The expression for the weighted summation is:

[0059]

[0060] in, This represents the dynamic edge weight of the directed link from the first blockchain node p to the second blockchain node q; This represents the load growth rate of the second blockchain node q; This represents the variance of the load fluctuation of the second blockchain node q; This represents the real-time network latency between the first blockchain node p and the second blockchain node q. This represents the network latency jitter value between the first blockchain node p and the second blockchain node q; The first storage adjustment coefficient has a value of 0.4. This is the second storage adjustment coefficient, with a value of 0.2; The first transmission regulation coefficient is set to 0.7. This is the second transmission regulation coefficient, with a value of 0.3; The storage cost weighting factor is set to 0.35. It is obtained by adjusting the storage cost weighting factor from 0.1 to 0.9 in an offline simulation environment, with the node load balancing after path planning as the optimization objective, and selecting the weight value corresponding to the optimal load balancing. The transmission cost weighting factor is set to 0.65. It is obtained by adjusting the transmission cost weighting factor from 0.1 to 0.9 in an offline simulation environment. The optimization objective is to select the weighting value corresponding to the highest comprehensive score, with the data storage success rate and transmission completion time as the combined score. and satisfy , Value greater than The basis for this is that network transmission factors have a greater impact on the quality of the blockchain distributed storage path than the impact of target node storage status factors.

[0061] In the improved Dijkstra algorithm, whenever a fire protection maintenance data feature component is successfully stored, the historical storage load sequence of the affected blockchain nodes in the blockchain node network is updated. The affected blockchain node refers to the target storage node on the current feature component storage path that actually received and stored the feature component. The update method is as follows: read the latest storage load value from the load log database of the affected blockchain node, append the latest storage load value to the end of the historical storage load sequence of the affected blockchain node, and simultaneously delete the earliest storage load value in the historical storage load sequence, ensuring that the sequence length of the historical storage load sequence remains the number of sampling points within a preset time window. Based on the updated historical storage load sequence of the affected blockchain nodes, the load growth rate and load fluctuation variance of the affected blockchain nodes are recalculated, and the dynamic edge weights of all directed links with the affected blockchain nodes as target nodes are recalculated. When the improved Dijkstra algorithm plans storage paths for the remaining fire protection maintenance data feature components, the updated dynamic edge weights are used as the edge weight input. Throughout the entire path planning process, the above update operation is performed once after the storage of each fire protection maintenance data feature component is completed, so that the storage path of subsequent fire protection maintenance data feature components is always planned based on the latest node load status and network status.

[0062] In specific implementation, please refer to Figure 4 The following method is used to distribute and store multiple fire protection maintenance data feature components to multiple target storage nodes in the blockchain node network according to multiple feature component storage paths, and generate a distributed storage index:

[0063] According to the storage path of the first feature component, the first fire protection maintenance data feature component is sent to the first target storage node on the storage path of the first feature component. The sending process is as follows: a data storage request is sent to the first target storage node, and the data storage request carries the first fire protection maintenance data feature component and the first feature component type label. The first feature component type label is used to identify the fire protection maintenance data type to which the first fire protection maintenance data feature component belongs. The fire protection maintenance data type includes one of the following: equipment identification type, maintenance time type, maintenance personnel type, maintenance operation type, maintenance result type, or equipment status type. The data storage request is encapsulated using the peer-to-peer communication protocol in the blockchain node network. The request message header includes the source node address and the first target storage node address, and the request message body carries the serialized data of the first fire protection maintenance data feature component and the first feature component type label in binary format.

[0064] After the first target storage node completes local storage, it receives the first storage confirmation information and the first storage location identifier returned by the first target storage node. When completing the local storage operation, the first target storage node writes the first fire protection maintenance data feature component to the local storage partition and generates a corresponding storage transaction, which is then submitted to the blockchain ledger. After the consensus mechanism confirms the storage transaction, it is packaged into a new block. The first target storage node constructs the first storage location identifier based on the block height of the new block and the transaction hash value of the storage transaction. The first storage location identifier includes the block height and the transaction hash value. Simultaneously, the first target storage node uses its private key to sign the storage completion event, generating the first storage confirmation information, which includes the node's identity certificate and a storage timestamp. The specific process of receiving the first storage confirmation information and the first storage location identifier returned by the first target storage node is as follows: After sending a data storage request to the first target storage node, listen for the response message from the first target storage node; upon receiving the response message, extract the first storage confirmation information carried within it. The first storage confirmation information includes the node identity certificate and storage timestamp of the first target storage node. The node identity certificate is issued by a certificate authority in the blockchain node network and is used to verify the legitimacy of the first target storage node's identity; parse the first storage confirmation information, verify the signature using the public key in the node identity certificate, and after successful verification, extract the first storage location identifier assigned by the first target storage node to the first fire protection maintenance data feature component from the fields corresponding to the first storage confirmation information. The first storage location identifier includes the block height and transaction hash value. The block height indicates the block sequence number in the blockchain ledger where the first fire protection maintenance data feature component is recorded, and the transaction hash value is a unique identifier for the storage transaction, used for subsequent retrieval.

[0065] Following the storage path of the second feature component, the second fire protection maintenance data feature component is sent to the second target storage node on that path. The sending process is consistent with that of the first fire protection maintenance data feature component; that is, a data storage request is sent to the second target storage node, carrying the second fire protection maintenance data feature component and a second feature component type tag. The system then receives the second storage confirmation information and the second storage location identifier returned by the second target storage node. The second storage confirmation information includes the node identity certificate and storage timestamp of the second target storage node, and the second storage location identifier includes the block height and transaction hash value corresponding to the second fire protection maintenance data feature component.

[0066] The first storage confirmation information, the first storage location identifier, the second storage confirmation information, and the second storage location identifier are aggregated to generate a distributed storage index corresponding to the fire protection maintenance data set. During aggregation, an index record entry is created, containing the following fields: feature component sequence number, fire protection maintenance data type, target storage node address, storage location identifier, and hash value of the storage confirmation information. The relevant information of the first and second fire protection maintenance data feature components is sequentially filled into the corresponding index record entries. When there are more than two fire protection maintenance data feature components obtained from decoupling the fire protection maintenance data set, the above storage and information collection process is repeated for all fire protection maintenance data feature components, aggregating the storage confirmation information and storage location identifier of each fire protection maintenance data feature component into the index record.

[0067] In some embodiments, the distributed storage index is organized using a Merkle tree structure. A Merkle tree is a binary tree, constructed as follows: The storage location identifier and storage confirmation information corresponding to each fire protection and maintenance data feature component are hashed to obtain the leaf hash value corresponding to each feature component. Each leaf hash value serves as a leaf node in the Merkle tree. Specifically, the block height and transaction hash value in the storage location identifier are concatenated with the node identity certificate sequence number and storage timestamp in the storage confirmation information in a fixed order to form a byte string. A preset cryptographic hash function is applied to this byte string to obtain the leaf hash value. The cryptographic hash function uses the SHA-256 algorithm. If the total number of leaf nodes is odd, the last leaf node is copied to make it even. Adjacent leaf hash values ​​are concatenated and hashed again to generate the intermediate node hash value for the next layer. This concatenation and hashing process is repeated layer by layer upwards until a unique Merkle tree root hash value is generated. The Merkle tree structure allows the distributed storage index to verify the integrity and tamper-proof nature of the stored information for each fire protection and maintenance data feature component through the Merkle tree root hash value. The mapping relationship between index entries and Merkle tree leaf nodes is recorded in the index description file, which is stored locally on the blockchain node that initiated the storage operation and provides a query interface for subsequent retrieval.

[0068] It is understood that the above process is illustrated using the first and second fire protection maintenance data feature components as examples. In actual processing, the number of fire protection maintenance data feature components is equal to the number of fire protection maintenance data types obtained by decoupling, that is, a maximum of six fire protection maintenance data feature components, namely equipment identification type, maintenance time type, maintenance personnel type, maintenance operation type, maintenance result type, and equipment status type. Each fire protection maintenance data feature component is sent according to the corresponding feature component storage path and receives the storage confirmation information and storage location identifier returned by the corresponding target storage node. Finally, all of them are incorporated into the construction of the distributed storage index.

[0069] In practice, after obtaining the distributed storage index corresponding to the fire protection maintenance data set, a retrieval request for the target fire protection maintenance data is received. The retrieval request is issued by the client application, and the message body of the retrieval request carries the data identifier of the target fire protection maintenance data. The data identifier is a unique identifier assigned by the system to the fire protection maintenance data set when it is stored in a distributed manner. The data identifier adopts a universally unique identifier format, and the mapping relationship between the data identifier and the distributed storage index is recorded in the metadata management module.

[0070] Based on the distributed storage index, the system queries multiple target storage node addresses and multiple storage location identifiers corresponding to the target fire protection maintenance data. The query process involves parsing the data identifiers carried in the retrieval request and locating the corresponding distributed storage index description file from the metadata management module. The index description file records the mapping relationship between Merkle tree leaf nodes and each fire protection maintenance data feature component. Each index record entry in the index description file is traversed; each entry contains the feature component sequence number, fire protection maintenance data type, target storage node address, storage location identifier, and hash value of storage confirmation information. The target storage node addresses and storage location identifiers are extracted from each index record entry. All extracted target storage node addresses are aggregated into an address list, and all extracted storage location identifiers are aggregated into a location identifier list. The number of addresses in the target storage node address list corresponds to the number of fire protection maintenance data feature components corresponding to the target fire protection maintenance data, and each target storage node address corresponds to one storage location identifier.

[0071] Data retrieval requests are sent in parallel to multiple target storage node addresses. The parallel sending is implemented as follows: A number of threads equal to the number of target storage node addresses are created, and each thread is responsible for sending a data retrieval request to one target storage node address. Each data retrieval request carries a corresponding storage location identifier, which includes the block height and transaction hash value. Upon receiving a data retrieval request, the target storage node parses the block height and transaction hash value from the request, locates the target block in the blockchain ledger based on the block height, retrieves the corresponding storage transaction from the transaction list of the target block based on the transaction hash value, extracts the serialized data of the stored fire protection maintenance data feature components from the storage transaction, and encapsulates the serialized data into a response message and returns it.

[0072] Receive the fire protection maintenance data feature components returned by each target storage node, and reorganize all the received fire protection maintenance data feature components according to the feature component association relationship recorded in the distributed storage index to obtain the target fire protection maintenance data.

[0073] In some embodiments, the specific steps for data restructuring are as follows:

[0074] Extract the first fire protection maintenance data feature component corresponding to the first storage location identifier and the second fire protection maintenance data feature component corresponding to the second storage location identifier from the distributed storage index. The extraction method is as follows: traverse all index record entries in the distributed storage index, sort each index record entry by feature component number, and read the fire protection maintenance data feature components corresponding to each index record entry in the sorted order.

[0075] Identify the first fire protection maintenance data type of the first fire protection maintenance data feature component and the second fire protection maintenance data type of the second fire protection maintenance data feature component. Each fire protection maintenance data feature component carries a corresponding feature component type tag in distributed storage. The feature component type tag records the fire protection maintenance data type to which the fire protection maintenance data feature component belongs. The fire protection maintenance data type includes equipment identification type, maintenance time type, maintenance personnel type, maintenance operation type, maintenance result type, and equipment status type. The first fire protection maintenance data type is read from the feature component type tag carried by the first fire protection maintenance data feature component, and the second fire protection maintenance data type is read from the feature component type tag carried by the second fire protection maintenance data feature component.

[0076] Based on a pre-defined data type assembly template, the field order of the first and second fire protection maintenance data types in the original fire protection maintenance data record is determined. The data type assembly template is a predefined field order mapping table, which specifies that the equipment identification type field is in the first position, the maintenance time type field in the second position, the maintenance personnel type field in the third position, the maintenance operation type field in the fourth position, the maintenance result type field in the fifth position, and the equipment status type field in the sixth position. The data type assembly template is searched based on the first fire protection maintenance data type to obtain its first position in the original fire protection maintenance data record; similarly, the data type assembly template is searched based on the second fire protection maintenance data type to obtain its second position in the original fire protection maintenance data record.

[0077] Following the field arrangement order, the first and second fire protection maintenance data feature components are concatenated into a single fire protection maintenance data record. During concatenation, a field array with the same number of fields as the complete fire protection maintenance data record is created, and the length of the field array equals the total number of fire protection maintenance data types defined in the data type assembly template. The first fire protection maintenance data feature component is placed in the field position corresponding to the first arrangement in the field array, and the second fire protection maintenance data feature component is placed in the field position corresponding to the second arrangement in the field array. After all received fire protection maintenance data feature components have been placed in the field array according to their respective arrangement order, each field position in the field array is filled with the corresponding fire protection maintenance data feature component.

[0078] In practical implementation, when the first fire protection maintenance data feature component is a subset of data corresponding to the equipment identification type, the subset of data corresponding to the equipment identification type contains the equipment identification field values ​​of all fire protection maintenance records. The k-th equipment identification field value and the k-th field value in the second fire protection maintenance data feature component belong to the same record in the original fire protection maintenance record. During splicing, following the original order of records in the fire protection maintenance time-series data sequence, the field values ​​with the same sequence number in each fire protection maintenance data feature component are extracted sequentially. The extracted field values ​​are then combined into a complete fire protection maintenance data record according to the field arrangement order specified in the data type assembly template.

[0079] Repeatedly concatenate all received fire protection maintenance data feature components until a complete fire protection maintenance dataset is generated. This complete dataset is then used to form the target fire protection maintenance data. When there are more than two fire protection maintenance data feature components, perform the above-mentioned operations of identifying data type, determining sorting order, and filling in field arrays for each feature component extracted according to its sequence number. After all fire protection maintenance data feature components have been processed, output the concatenated fire protection maintenance data records one by one. All concatenated fire protection maintenance data records are then sorted in ascending order by timestamp to form the target fire protection maintenance data.

[0080] The foregoing has provided a detailed description of one embodiment of the present invention, but this description is merely a preferred embodiment and should not be construed as limiting the scope of the invention. All equivalent variations and modifications made within the scope of the claims of this invention should still fall within the patent coverage of this invention.

Claims

1. A blockchain-based distributed storage method for fire protection maintenance data, characterized in that, The method includes: Obtain a fire protection maintenance data set, and decouple the data features of the fire protection maintenance data set to obtain multiple fire protection maintenance data feature components; Based on the improved Dijkstra algorithm, storage path planning is performed on the multiple fire protection and maintenance data feature components in a preset blockchain node network to obtain multiple feature component storage paths. The improved Dijkstra algorithm dynamically adjusts the path edge weights based on the node's historical storage load and the network latency between nodes. According to the storage paths of the multiple feature components, the multiple fire protection maintenance data feature components are distributed and stored to multiple target storage nodes in the blockchain node network to obtain the distributed storage index corresponding to the fire protection maintenance data set. 2.The blockchain-based fire maintenance data distributed storage method according to claim 1, wherein, The process of acquiring a fire protection maintenance data set involves decoupling the data features of the fire protection maintenance data set to obtain multiple fire protection maintenance data feature components, including: The fire protection maintenance data set is serialized and reassembled according to timestamps to obtain a fire protection maintenance time-series data sequence; The data type of the fire protection maintenance time sequence is identified to determine multiple fire protection maintenance data types, including equipment identification type, maintenance time type, maintenance personnel type, maintenance operation type, maintenance result type, and equipment status type. Using the multiple fire protection maintenance data types as decoupling dimensions, a data subset corresponding to each fire protection maintenance data type is extracted from the fire protection maintenance time series data sequence, and each data subset corresponding to a fire protection maintenance data feature component is used as a fire protection maintenance data feature component to obtain the multiple fire protection maintenance data feature components.

3. The distributed storage method for fire protection maintenance data based on blockchain according to claim 1, characterized in that, The improved Dijkstra algorithm is used to plan the storage paths for the multiple fire protection maintenance data feature components in a preset blockchain node network, resulting in multiple feature component storage paths, including: The node status of the preset blockchain node network is collected to obtain the current storage load of each blockchain node and the network latency between each blockchain node. A node state vector is constructed for each blockchain node, the node state vector including the current storage load and the node's historical storage load; Based on the node state vector and the network latency, a dynamic edge weight is dynamically calculated for each link between nodes in the preset blockchain node network. The dynamic edge weight is positively correlated with the current storage load and the network latency. Using the dynamic edge weights as the edge weight inputs of the improved Dijkstra algorithm, and taking the source node of each fire maintenance data feature component as the starting point and all nodes in the blockchain node network as candidate endpoints, the improved Dijkstra algorithm is run. For each fire maintenance data feature component, the storage path that minimizes the cumulative edge weights is output as the feature component storage path corresponding to each fire maintenance data feature component, thus obtaining the multiple feature component storage paths.

4. The distributed storage method for fire protection maintenance data based on blockchain according to claim 3, characterized in that, The node state vector also includes the available storage capacity and the number of successful storage operations in the history of each blockchain node. The dynamic edge weight is also negatively correlated with the available storage capacity and the number of successful storage operations in the history of the node.

5. The distributed storage method for fire protection maintenance data based on blockchain according to claim 3, characterized in that, Based on the node state vector and the network latency, dynamically calculate the dynamic edge weights for each inter-node link in the preset blockchain node network, including: Extract the first current storage load and the first historical storage load of the first blockchain node from the node state vector; extract the second current storage load and the second historical storage load of the second blockchain node from the node state vector. Calculate the first load change rate between the first current storage load and the historical storage load of the first node, and calculate the second load change rate between the second current storage load and the historical storage load of the second node; Obtain the inter-node network latency between the first blockchain node and the second blockchain node; The first load change rate, the second load change rate, and the network latency between nodes are input into a preset dynamic edge weight calculation model, and the dynamic edge weight calculation model outputs the dynamic edge weight of the link between the first blockchain node and the second blockchain node.

6. The distributed storage method for fire protection maintenance data based on blockchain according to claim 1, characterized in that, According to the storage paths of the multiple feature components, the multiple fire protection maintenance data feature components are distributed and stored to multiple target storage nodes in the blockchain node network to obtain the distributed storage index corresponding to the fire protection maintenance data set, including: According to the storage path of the first feature component, the first fire protection maintenance data feature component is sent to the first target storage node on the storage path of the first feature component; Receive the first storage confirmation information and the first storage location identifier returned by the first target storage node; According to the second feature component storage path, the second fire protection maintenance data feature component is sent to the second target storage node on the second feature component storage path; Receive the second storage confirmation information and the second storage location identifier returned by the second target storage node; By aggregating the first storage confirmation information, the first storage location identifier, the second storage confirmation information, and the second storage location identifier, a distributed storage index corresponding to the fire protection maintenance data set is generated.

7. The distributed storage method for fire protection maintenance data based on blockchain according to claim 6, characterized in that, The distributed storage index is organized using a Merkle tree structure. The leaf nodes of the Merkle tree store the storage location identifier and the hash value of the storage confirmation information corresponding to each fire protection maintenance data feature component.

8. The distributed storage method for fire protection maintenance data based on blockchain according to claim 1, characterized in that, The improved Dijkstra algorithm dynamically adjusts path edge weights based on node historical storage load and inter-node network latency, specifically including: Obtain the historical storage load sequence of each blockchain node in the blockchain node network, wherein the historical storage load sequence includes storage load values ​​at multiple historical time points within a preset time window; Perform load trend analysis on the historical storage load sequence of each blockchain node, and calculate the load growth rate and load fluctuation variance of each blockchain node; Obtain the real-time network latency and network latency jitter value between every two blockchain nodes in the blockchain node network; For the directed link from the first blockchain node to the second blockchain node, the storage cost factor is calculated based on the load growth rate and load fluctuation variance of the second blockchain node, and the transmission cost factor is calculated based on the real-time network latency and network latency jitter value between the first blockchain node and the second blockchain node. The storage cost factor and the transmission cost factor are weighted and summed to obtain the dynamic edge weight of the directed link from the first blockchain node to the second blockchain node. During the operation of the improved Dijkstra algorithm, whenever a fire protection maintenance data feature component is successfully stored, the historical storage load sequence of the affected blockchain nodes in the blockchain node network is updated, the dynamic edge weight is recalculated, and the storage path is planned for the remaining fire protection maintenance data feature components based on the updated dynamic edge weight.

9. The distributed storage method for fire protection maintenance data based on blockchain according to claim 8, characterized in that, The storage cost factor is positively correlated with the load growth rate and load fluctuation variance of the second blockchain node, and the transmission cost factor is positively correlated with the real-time network latency and the network latency jitter value.

10. The distributed storage method for fire protection maintenance data based on blockchain according to claim 2, characterized in that, Using the multiple fire protection maintenance data types as decoupling dimensions, a data subset corresponding to each fire protection maintenance data type is extracted from the fire protection maintenance time-series data sequence, including: Each fire maintenance record in the fire maintenance time-series data sequence is parsed to obtain the equipment identifier field value, maintenance time field value, maintenance personnel field value, maintenance operation field value, maintenance result field value, and equipment status field value corresponding to each fire maintenance record; Aggregate the values ​​of the equipment identification field in all fire protection maintenance records to generate a data subset corresponding to the equipment identification type; Aggregate the maintenance time field values ​​of all fire protection maintenance records to generate a data subset corresponding to the maintenance time type; Aggregate the values ​​of the maintenance personnel field in all fire protection maintenance records to generate a data subset corresponding to the maintenance personnel type; Aggregate the values ​​of the maintenance operation field in all fire protection maintenance records to generate a data subset corresponding to the maintenance operation type; Aggregate the values ​​of the maintenance result field in all fire protection maintenance records to generate a data subset corresponding to the maintenance result type; Aggregate the equipment status field values ​​from all fire protection maintenance records to generate a data subset corresponding to the equipment status type.

Images