Distributed power supply transaction data storage method and system based on hybrid database

Abstract

The invention discloses a distributed power supply transaction data storage method and system based on a hybrid database, and relates to the technical field of distributed storage, and the method comprises the steps: receiving a preprocessing transaction request, and extracting a key field; constructing an on-chain and off-chain collaborative storage architecture; partition keys are generated based on the regions, the asset types and the time slices, and data are mapped to corresponding block chain channels according to the partition keys; processing a cross-chain transaction through a service-aware atomic submission protocol; grading the data into hot, warm and cold data based on a dynamic value scoring model, and differentially storing the hot, warm and cold data on a chain or under the chain or coding and archiving the data; nodes are deployed at the edge of the network to process local tasks; based on a network state matrix and a reinforcement learning algorithm, user requests are intelligently scheduled through a load balancer. Through on-chain and off-chain collaborative storage and a multi-chain partition architecture, the data credibility is guaranteed, and meanwhile, the storage efficiency, the query capability and the high-concurrent processing capability of the system are improved.

Description

Technical Field

[0001] This invention relates to the field of distributed storage technology, and more specifically to a distributed power trading data storage method and system based on a hybrid database. Background Technology

[0002] With the large-scale integration of distributed photovoltaic and wind power sources, the power trading model is shifting from centralized to point-to-point, high-frequency distributed trading. Power trading generates massive amounts of data, which places high demands on the system's data storage, processing capabilities, and reliability assurance.

[0003] Currently, electricity trading primarily employs traditional centralized databases or single blockchain technologies. While purely centralized database solutions can handle high concurrency and complex queries using high-performance databases, they suffer from issues such as data tampering, opaque transaction processes, and reliance on a single central authority, making it difficult to establish trust among distrustful parties. Single blockchain storage solutions, while ensuring data reliability through their immutability and traceability, suffer from high storage costs, limited write throughput, and limited query functionality due to the need to store all data on the blockchain. Therefore, there is an urgent need for a new data storage and processing method that can balance data reliability, efficient storage, flexible querying, and strong concurrency support to support the stable and efficient operation of the future large-scale distributed power trading market.

[0004] For example, Chinese patent CN116561097A discloses a big data distributed storage incentive method and system based on blockchain and hybrid database to improve transaction throughput. It uses a distributed hybrid database to store data in a distributed manner and provides efficient real-time analytical query capabilities. Combined with an auction algorithm, it designs an incentive system that encourages numerous users to collect and share data. This application can simultaneously consider the data quality and price for users, obtaining more cost-effective data for big data analysis. Summary of the Invention

[0005] The technical problem to be solved by the present invention is to address the shortcomings of the prior art by providing a distributed power trading data storage method and system based on a hybrid database.

[0006] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0007] The distributed power trading data storage method based on a hybrid database includes the following steps:

[0008] Step S1: Receive and preprocess distributed power transaction requests, and extract key fields;

[0009] Step S2: Construct an on-chain and off-chain collaborative storage architecture, in which the on-chain uses a hybrid state database of LevelDB and CouchDB, and the off-chain is built with a storage cluster consisting of a distributed columnar database cluster and an archive storage network.

[0010] Step S3: Based on the physical region code, asset type code and time slice of the transaction data, generate a joint partition key, and map the data to the corresponding logical blockchain channel for consensus and storage according to the joint partition key;

[0011] Step S4: For cross-chain transactions involving multiple logical blockchain channels, execute a business-aware atomic commit protocol;

[0012] Step S5: Construct a dynamic value scoring model to classify data into hot data, warm data, and cold data. Hot data is stored on the chain, warm data's data fingerprint is stored on the chain, and complete data is stored off-chain in a distributed columnar database cluster. Cold data is encoded with erasure coding and then distributed and archived in an off-chain archive storage network. Encoded metadata used for verification and recovery is stored on the chain.

[0013] Step S6: Deploy edge computing nodes at the network edge close to the data source to handle localized computing tasks;

[0014] Step S7: Based on the network state matrix and reinforcement learning algorithm, dynamically schedule user requests through an intelligent load balancer.

[0015] Furthermore, step S1 specifically includes the following steps:

[0016] Step S1.1: Receive the original distributed power transaction request;

[0017] Step S1.2: Verify the legality of the power transaction request format and the identities of both parties involved in the transaction;

[0018] Step S1.3: Extract and standardize the key fields of electricity volume, electricity price, timestamp, and asset type of the transaction.

[0019] Furthermore, in step S3, the method for generating the combined partition key includes:

[0020] The time slice identifier, obtained by dividing the region code, asset type code, and transaction timestamp by the preset time slice length and then rounding down, is then concatenated into strings in sequence.

[0021] Applying a cryptographic hash function to the concatenated string yields the final combined partition key, which is the hash value obtained.

[0022] Furthermore, in step S4, the business-aware atomic commit protocol specifically includes the following steps:

[0023] Step S4.1: Pre-execute transactions on the relevant logical blockchain channels and generate cross-chain locks containing business dependencies;

[0024] Step S4.2: Submit the cross-chain lock to a dedicated coordination chain for global sorting and verification, and generate a global coordination block from the coordination chain;

[0025] Step S4.3: Each logical blockchain channel submits transactions in parallel according to the global coordination block. If the submission fails, a compensation operation is triggered based on the business dependency relationship.

[0026] Furthermore, in step S5, the score value output by the dynamic value scoring model is obtained by weighted summation of four dimensions of indicators: access frequency, credit relevance, time decay factor, and business relevance.

[0027] Further, in step S5, the data is divided into three levels and stored based on the dynamic value score compared with preset hot data thresholds and cold data thresholds, specifically including:

[0028] When the dynamic value score is higher than the hot data threshold, it is determined to be hot data and stored directly in the on-chain CouchDB.

[0029] When the dynamic value score is between the cold data threshold and the hot data threshold, it is determined to be warm data. The warm data fingerprint is stored on the chain, and the complete data is stored off-chain in a distributed columnar database cluster.

[0030] When the dynamic value score is less than or equal to the cold data threshold, it is determined to be cold data. After erasure coding and fragmentation, it is stored in the archive network, and the encoded metadata is stored on the blockchain.

[0031] Furthermore, the erasure coding process is as follows: the original cold data block is encoded into n data fragments and m check fragments, and a Merkle tree is constructed for all check fragments; the encoded metadata stored on the chain includes at least the encoding parameters, the root hash of the Merkle tree, and the fragment position mapping.

[0032] Furthermore, in step S6, the localized real-time computing task includes: power matching calculation based on local cached data of edge nodes, transaction message format compliance verification, and transaction matching calculation within the region.

[0033] Furthermore, in step S7, each element of the network state matrix is ​​used to characterize the comprehensive service capability from a certain request source to a certain edge node, and its value is jointly determined by the network latency, the real-time load of the edge node, and the matching degree between the request characteristics and the node data cache characteristics.

[0034] A distributed power trading data storage system based on a hybrid database, used to implement any one of the distributed power trading data storage methods based on a hybrid database, includes:

[0035] The data access and preprocessing module is used to receive and preprocess distributed power transaction requests and extract key transaction fields;

[0036] The on-chain and off-chain collaborative storage engine is used to build and manage a collaborative storage architecture consisting of an on-chain hybrid state database and an off-chain storage cluster, and to execute hierarchical and differentiated storage strategies for data based on a dynamic value scoring model.

[0037] The partition routing and cross-chain coordination module is used to route transaction data to the corresponding logical blockchain channel based on the federated partition key, and to execute a business-aware atomic commit protocol for cross-chain transactions to coordinate the channels.

[0038] The edge computing and intelligent scheduling module is used to manage edge computing nodes close to the data source to handle localized computing tasks, and to schedule user requests to the optimal edge node based on the network state matrix and reinforcement learning algorithms.

[0039] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0040] 1. This invention utilizes an on-chain + off-chain collaborative storage model and leverages blockchain to ensure the immutability of key data fingerprints and transaction logic, thereby improving storage capacity and query performance on a trustworthy basis.

[0041] 2. This invention achieves real-time, multi-dimensional quantitative evaluation of data value through a dynamic value scoring model. It can also implement intelligent storage strategies from on-chain hot storage, off-chain warm storage to distributed cold archiving based on factors such as data popularity, credit association, and business importance, thereby significantly reducing the total storage cost.

[0042] 3. This invention adopts a multi-chain architecture based on multi-dimensional joint partition keys, which distributes the global load to multiple parallel logical blockchain channels for processing, breaking through the performance bottleneck of a single chain; combined with edge computing nodes to process local real-time tasks, and intelligent load balancing based on reinforcement learning, it can flexibly cope with regional and time-period high-concurrency access pressure, ensuring low latency and high availability of services.

[0043] 4. For offline archived cold data, this invention uses verifiable erasure coding technology for fragmented storage and puts the encoded metadata and Merkle root hash on the chain, so that even if the archive node fails, the integrity of the data can still be verified and the original data can be recovered through on-chain evidence storage. Attached Figure Description

[0044] Other features, objects, and advantages of the invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0045] Figure 1 This is a flowchart illustrating an embodiment of the present invention;

[0046] Figure 2 This is a system schematic diagram according to an embodiment of the present invention;

[0047] Figure 3 This is a flowchart illustrating the hierarchical data storage process according to an embodiment of the present invention. Detailed Implementation

[0048] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be described in detail below with reference to the accompanying drawings and specific embodiments.

[0049] like Figure 1 As shown, the distributed power trading data storage method based on a hybrid database includes the following steps:

[0050] Step S1: Receive and preprocess distributed power transaction requests, and extract key fields;

[0051] Step S2: Construct an on-chain and off-chain collaborative storage architecture, in which the on-chain uses a hybrid state database of LevelDB and CouchDB, and the off-chain is built with a storage cluster consisting of a distributed columnar database cluster and an archive storage network.

[0052] Step S3: Based on the physical region code, asset type code and time slice of the transaction data, generate a joint partition key, and map the data to the corresponding logical blockchain channel for consensus and storage according to the joint partition key;

[0053] Step S4: For cross-chain transactions involving multiple logical blockchain channels, execute a business-aware atomic commit protocol;

[0054] Step S5: Construct a dynamic value scoring model to classify data into hot data, warm data, and cold data. Hot data is stored on the chain, warm data's data fingerprint is stored on the chain, and complete data is stored off-chain in a distributed columnar database cluster. Cold data is encoded with erasure coding and then distributed and archived in an off-chain archive storage network. Encoded metadata used for verification and recovery is stored on the chain.

[0055] Step S6: Deploy edge computing nodes at the network edge close to the data source to handle localized computing tasks;

[0056] Step S7: Based on the network state matrix and reinforcement learning algorithm, dynamically schedule user requests through an intelligent load balancer.

[0057] The on-chain state database can flexibly choose between LevelDB or CouchDB based on data type and query requirements. CouchDB is used for transaction details requiring complex JSON queries, while LevelDB is used for index data requiring only key-value access.

[0058] Step S1 specifically includes the following steps:

[0059] Step S1.1: Receive the original distributed power transaction request;

[0060] Step S1.2: Verify the legality of the power transaction request format and the identities of both parties involved in the transaction;

[0061] Step S1.3: Extract and standardize the key fields of electricity volume, electricity price, timestamp, and asset type of the transaction.

[0062] In step S3, the method for generating the combined partition key includes:

[0063] The time slice identifier, obtained by dividing the region code, asset type code, and transaction timestamp by the preset time slice length and then rounding down, is then concatenated into strings in sequence.

[0064] Applying a cryptographic hash function to the concatenated string yields the final combined partition key, which is the hash value obtained.

[0065] The formula for calculating the joint partition key function is:

[0066]

[0067] in, This indicates the generated union partition key. This refers to hash functions, such as SHA-256, used to generate fixed-length, irreversible key-value pairs. The physical area code indicating where the transaction took place. This indicates the asset type code for distributed power sources involved in the exchange. Indicates the timestamp of the transaction initiation. This indicates the preset system time slice length, used to discretize the time dimension. Represents the string concatenation operator. This represents the floor function, which determines the specific time slice to which a timestamp belongs.

[0068] Generate a union partition key Then, the system determines the logical blockchain channel to which a given channel belongs through a routing mapping function, maintains a virtual ring on which virtual nodes representing each logical blockchain channel are evenly distributed. Perform a hash calculation and map it to a point on the ring. The channel represented by the first virtual node found from this point in a clockwise direction along the ring is the target channel for the data.

[0069] In step S4, the business-aware atomic commit protocol specifically includes the following steps:

[0070] Step S4.1: Pre-execute transactions on the relevant logical blockchain channels and generate cross-chain locks containing business dependencies;

[0071] Step S4.2: Submit the cross-chain lock to a dedicated coordination chain for global sorting and verification, and generate a global coordination block from the coordination chain;

[0072] Step S4.3: Each logical blockchain channel submits transactions in parallel according to the global coordination block. If the submission fails, a compensation operation is triggered based on the business dependency relationship.

[0073] The cross-chain lock is a data structure that includes: a transaction ID, a list of involved channels, hashes of the state read / write sets generated by the pre-execution of each channel, and a business dependency graph. This graph is represented as a directed graph, where nodes are key asset accounts on each channel, and edges represent the direction of asset transfer caused by this transaction.

[0074] The coordination chain is a simplified blockchain deployed specifically for cross-chain transaction ordering, employing the Raft consensus algorithm. Each business chain submits a cross-chain lock by calling the chaincode named Coordinator on the coordination chain. After verifying that there are no circular dependencies in the business dependency graph, the Coordinator chaincode generates a global, linear ordering sequence for all cross-chain transactions and packages it into a global coordination block. The header of this block contains the IDs and order numbers of all relevant cross-chain transactions.

[0075] Once a global coordination block containing its own transaction ID is received and confirmed, the local transaction is formally submitted. If a channel fails to submit, the remaining successful channels will automatically trigger a reverse compensation transaction based on the business dependency graph, rolling back the asset state to the state before the transaction, thereby ensuring eventual consistency of the business.

[0076] In step S5, the score output by the dynamic value scoring model is obtained by weighted summation of indicators from four dimensions: access frequency, credit relevance, time decay factor, and business relevance.

[0077] The calculation formula for the dynamic value scoring model is as follows:

[0078]

[0079] in, This represents the dynamic value score of data t at decision time d. Represents the logarithmic function. This indicates the frequency with which data t was accessed within a past time window W. This represents the real-time credit score of the transaction entity associated with data t. The system timestamp representing the decision time d. This indicates the time when data t was last updated. This indicates the system's preset maximum decay period. This represents the correlation coefficient between data t and current core business activities. , , and These represent the corresponding weighting coefficients. The time window and maximum decay period can be preset according to the business cycle, such as setting the time window to 24 hours and the maximum decay period to 90 days.

[0080] Among them, credit score The model is calculated by an independent credit sub-model, using features such as the previous day's fulfillment rate, historical complaint count, and cumulative transaction amount. It is trained using a logistic regression model with training data derived from labeled data in historical transaction records.

[0081] Weighting coefficient , , and The initial value is determined by expert experience and can be fine-tuned during system operation using online gradient descent based on the data classification effect.

[0082] The business relevance coefficient The business rules engine calculates in real time, receives a list of currently active trading instruments from the market operations module, and matches the asset type of data t. At the same time, it queries the activity of counterparties related to t recently. Finally, it maps the activity and asset type matching degree to a business relevance coefficient through a predefined mapping function. The closer the value is to 1, the stronger the relevance of the data to the current core business activities.

[0083] like Figure 3 As shown, in step S5, the data is divided into three levels and stored based on the dynamic value score compared with preset hot data thresholds and cold data thresholds. Specifically, this includes:

[0084] When the dynamic value score is higher than the hot data threshold, it is determined to be hot data and stored directly in the on-chain CouchDB.

[0085] When the dynamic value score is between the cold data threshold and the hot data threshold, it is determined to be warm data. The warm data fingerprint is stored on the chain, and the complete data is stored off-chain in a distributed columnar database cluster.

[0086] When the dynamic value score is less than or equal to the cold data threshold, it is determined to be cold data. After erasure coding and fragmentation, it is stored in the archive network, and the encoded metadata is stored on the blockchain.

[0087] The hot data threshold and cold data threshold are initialized based on the storage capacity target of the on-chain CouchDB and the statistical percentile of the historical data access distribution. For example, the hot data threshold is set to the historical 75th percentile of the score, and the cold data threshold is set to the 25th percentile. Administrators can also dynamically adjust these thresholds based on system performance monitoring data.

[0088] The erasure coding process involves encoding the original cold data block into n data fragments and m check fragments, and constructing a Merkle tree for all n+m fragments. The encoded metadata stored on the chain includes at least the encoding parameters (k, n), the root hash of the Merkle tree, and the fragment position mapping. During data retrieval, at least k fragments must be obtained, and the integrity of each fragment must be verified through Merkle tree path proofs for successful decoding.

[0089] After encoding, the encoding parameters, Merkle root hash, and the list of node addresses stored in each shard are stored on the blockchain as metadata. When data needs to be retrieved, the metadata is first obtained from the blockchain, then a sufficient number of shards are obtained based on the address list, and the integrity of the shards is verified by comparing the Merkle root hash. Finally, the original data is decoded and restored.

[0090] In step S6, the localized real-time computing tasks include: power matching calculation based on local cached data of edge nodes, transaction message format compliance verification, and transaction matching calculation within the region.

[0091] The power matching calculation refers to the rapid balancing calculation of the real-time generation power of distributed power sources and the real-time power consumption of loads within a local power network. Specifically, this includes: receiving second-level or minute-level power generation and consumption data streams from smart meters; calculating in real-time the adjustment needs for insufficient power or the consumption suggestions for surplus power, and generating corresponding pre-trading instructions. This calculation is completed at the edge, enabling rapid response and providing a basis for real-time trading.

[0092] Transaction message format compliance verification refers to the pre-verification of transaction data's format, field integrity, and business logic compliance at the edge before it is uploaded to the blockchain network. This includes: syntax verification to confirm whether the message conforms to a predefined format; field validity verification to check whether values ​​such as electricity volume and price are within reasonable ranges and whether the timestamp is valid; and initial business logic screening based on simple rules cached locally for rapid filtering. Only requests that pass verification are forwarded, significantly reducing unnecessary load on the core on-chain network.

[0093] Regional transaction matching calculation refers to the rapid and preliminary matching and optimization of buy and sell orders within a smaller geographical or logical scope below the provincial or local trading center level. Specifically, this includes: aggregating buyer bids and seller quotes within the region; running a simplified matching algorithm under a simplified model that satisfies local network flow constraints; and performing matching calculations. The output is not the final globally optimal solution, but rather a high-quality candidate matching set. This set will be sent to a higher-level trading center for final verification, thereby significantly reducing the solution space of the global optimization problem and improving overall market clearing efficiency.

[0094] In step S7, each element of the network state matrix is ​​used to characterize the comprehensive service capability from a certain request source to a certain edge node. Its value is determined by the network latency, the real-time load of the edge node, and the matching degree between the request characteristics and the node data cache characteristics.

[0095] The formula for calculating the elements of the network state matrix is ​​as follows:

[0096]

[0097] in, This represents the overall service capability score from user request source i to edge node j. Indicates the current network latency. This represents the real-time CPU load rate of edge node j. This indicates the system's maximum latency. This indicates the maximum load rate of the edge node. Represents the cosine similarity function. This represents the feature vector of user request i. This represents the feature vector of locally cached data at edge node j. , and These represent the corresponding weighting coefficients.

[0098] The weighting coefficients are preset based on business strategies. For example, during peak transaction periods, to ensure overall throughput, they can be set... =0.4, =0.5, =0.1, prioritizing node load balancing; during normal operation, to optimize user experience, it can be set to... =0.6, =0.2, =0.2, prioritize reducing network latency.

[0099] The reinforcement learning algorithm in step S7 employs a dynamic scheduling method based on Q-learning, specifically implemented as follows: The intelligent load balancer is modeled as a reinforcement learning agent, whose optimization objective is to minimize the system's global request response time. The scheduling process is formalized as a Markov decision process, specifically including:

[0100] State s: The aggregated representation of the states of all edge nodes at the current time, including the joint features of their load vectors and the network state matrix;

[0101] Action a: A decision to assign the current user request to a specific edge node;

[0102] Reward r: Defined as the negative of the actual response time after the request is processed, used to guide the agent to learn efficient scheduling strategies.

[0103] The reinforcement learning agent continuously interacts with the environment and updates its state-action value function through an online Q-learning algorithm, thereby dynamically optimizing the scheduling strategy.

[0104] In the initial stage of system deployment, the intelligent load balancer can be pre-trained offline using training data generated based on historical access logs to initialize the Q-table or neural network model, thereby obtaining a basic scheduling strategy and ensuring basic performance in the initial stage of system launch.

[0105] The above method can adapt to the dynamic changes in transaction access patterns. For example, during the peak photovoltaic transaction period at noon, more computing requests are automatically scheduled to the edge nodes where the photovoltaic data partition is located and the load is low, so as to achieve optimal resource allocation and continuous improvement of response efficiency.

[0106] like Figure 2 As shown, a distributed power trading data storage system based on a hybrid database is used to implement any of the distributed power trading data storage methods based on a hybrid database, including:

[0107] The data access and preprocessing module is used to receive and preprocess distributed power transaction requests and extract key transaction fields;

[0108] The on-chain and off-chain collaborative storage engine is used to build and manage a collaborative storage architecture consisting of an on-chain hybrid state database and an off-chain storage cluster, and to execute hierarchical and differentiated storage strategies for data based on a dynamic value scoring model.

[0109] The partition routing and cross-chain coordination module is used to route transaction data to the corresponding logical blockchain channel based on the federated partition key, and to execute a business-aware atomic commit protocol for cross-chain transactions to coordinate the channels.

[0110] The edge computing and intelligent scheduling module is used to manage edge computing nodes close to the data source to handle localized computing tasks, and to schedule user requests to the optimal edge node based on the network state matrix and reinforcement learning algorithms.

[0111] Once a cross-regional transaction request arrives at the data access and preprocessing module and completes verification, it is sent to the partition routing and cross-chain coordination module to generate a cross-chain lock and invoke the coordination chain service. After coordination, on-chain transactions in each region are triggered, and transaction data is sent to the on-chain and off-chain collaborative storage engine for value assessment and hierarchical storage. Simultaneously, the real-time verification request related to the transaction is allocated to the edge nodes of the corresponding region by the edge computing and intelligent scheduling module for processing. Edge nodes subscribe to the event stream of their respective logical blockchain channels to synchronize core data such as account status and transaction rules related to their region to their local cache in real time. After completing local computation, the edge nodes package the results, their digital signatures, and input data proofs to generate a notarized transaction and submit it to the corresponding logical blockchain channel.

[0112] The examples described herein are merely preferred embodiments of the invention and are not intended to limit the concept and scope of the invention. Any modifications and improvements made by those skilled in the art to the technical solutions of the invention without departing from the design concept of the invention should fall within the protection scope of the invention.

Claims

1. A distributed power trading data storage method based on a hybrid database, characterized in that, Includes the following steps: Step S1: Receive and preprocess distributed power transaction requests, and extract key fields; Step S2: Construct an on-chain and off-chain collaborative storage architecture, in which the on-chain uses a hybrid state database of LevelDB and CouchDB, and the off-chain is built with a storage cluster consisting of a distributed columnar database cluster and an archive storage network. Step S3: Based on the physical region code, asset type code and time slice of the transaction data, generate a joint partition key, and map the data to the corresponding logical blockchain channel for consensus and storage according to the joint partition key; Step S4: For cross-chain transactions involving multiple logical blockchain channels, execute a business-aware atomic commit protocol; Step S5: Construct a dynamic value scoring model to classify data into hot data, warm data, and cold data. Hot data is stored on the chain, warm data's data fingerprint is stored on the chain, and complete data is stored off-chain in a distributed columnar database cluster. Cold data is encoded with erasure coding and then distributed and archived in an off-chain archive storage network. Encoded metadata used for verification and recovery is stored on the chain. Step S6: Deploy edge computing nodes at the network edge close to the data source to handle localized computing tasks; Step S7: Based on the network state matrix and reinforcement learning algorithm, dynamically schedule user requests through an intelligent load balancer.

2. The method according to claim 1, characterized in that, Step S1 specifically includes the following steps: Step S1.1: Receive the original distributed power transaction request; Step S1.2: Verify the legality of the power transaction request format and the identities of both parties involved in the transaction; Step S1.3: Extract and standardize the key fields of electricity volume, electricity price, timestamp, and asset type of the transaction.

3. The method according to claim 2, characterized in that, In step S3, the method for generating the combined partition key includes: The time slice identifier, obtained by dividing the region code, asset type code, and transaction timestamp by the preset time slice length and then rounding down, is then concatenated into strings in sequence. Applying a cryptographic hash function to the concatenated string yields the final combined partition key, which is the hash value obtained.

4. The method according to claim 3, characterized in that, In step S4, the business-aware atomic commit protocol specifically includes the following steps: Step S4.1: Pre-execute transactions on the relevant logical blockchain channels and generate cross-chain locks containing business dependencies; Step S4.2: Submit the cross-chain lock to a dedicated coordination chain for global sorting and verification, and generate a global coordination block from the coordination chain; Step S4.3: Each logical blockchain channel submits transactions in parallel according to the global coordination block. If the submission fails, a compensation operation is triggered based on the business dependency relationship.

5. The method according to claim 4, characterized in that, In step S5, the score output by the dynamic value scoring model is obtained by weighted summation of indicators from four dimensions: access frequency, credit relevance, time decay factor, and business relevance.

6. The method according to claim 5, characterized in that, In step S5, the data is divided into three levels and stored based on the dynamic value score compared with preset hot data thresholds and cold data thresholds. Specifically, this includes: When the dynamic value score is higher than the hot data threshold, it is determined to be hot data and stored directly in the on-chain CouchDB. When the dynamic value score is between the cold data threshold and the hot data threshold, it is determined to be warm data. The warm data fingerprint is stored on the chain, and the complete data is stored off-chain in a distributed columnar database cluster. When the dynamic value score is less than or equal to the cold data threshold, it is determined to be cold data. After erasure coding and fragmentation, it is stored in the archive network, and the encoded metadata is stored on the blockchain.

7. The method according to claim 6, characterized in that, The erasure coding process is as follows: the original cold data block is encoded into n data fragments and m check fragments, and a Merkle tree is constructed for all check fragments; the encoded metadata stored on the chain includes at least the encoding parameters, the root hash of the Merkle tree, and the fragment position mapping.

8. The method according to claim 7, characterized in that, In step S6, the localized real-time computing tasks include: power matching calculation based on local cached data of edge nodes, transaction message format compliance verification, and transaction matching calculation within the region.

9. The method according to claim 8, characterized in that, In step S7, each element of the network state matrix is ​​used to characterize the comprehensive service capability from a certain request source to a certain edge node. Its value is determined by the network latency, the real-time load of the edge node, and the matching degree between the request characteristics and the node data cache characteristics.

10. A distributed power trading data storage system based on a hybrid database, used to implement the distributed power trading data storage method based on a hybrid database as described in any one of claims 1-9, characterized in that, include: The data access and preprocessing module is used to receive and preprocess distributed power transaction requests and extract key transaction fields; The on-chain and off-chain collaborative storage engine is used to build and manage a collaborative storage architecture consisting of an on-chain hybrid state database and an off-chain storage cluster, and to execute hierarchical and differentiated storage strategies for data based on a dynamic value scoring model. The partition routing and cross-chain coordination module is used to route transaction data to the corresponding logical blockchain channel based on the federated partition key, and to execute a business-aware atomic commit protocol for cross-chain transactions to coordinate the channels. The edge computing and intelligent scheduling module is used to manage edge computing nodes close to the data source to handle localized computing tasks, and to schedule user requests to the optimal edge node based on the network state matrix and reinforcement learning algorithms.

Images