An archival storage system and method based on a digital object architecture

Abstract

The application relates to the technical field of archive storage, and discloses an archive storage system and method based on a digital object architecture. The system comprises a unique identification and relationship analysis component for generating a globally unique object identifier; a digital object warehouse for constructing a digital object; a digital object registry for establishing a searchable metadata index; a distributed ledger module for forming on-chain records; and a strategy-driven engine for listening to and receiving broadcast structured transactions, determining affected context scopes, and executing embedded life cycle strategies. The application realizes full-chain trust guarantee of archive data from content to process by constructing an electronic original text into a digital object containing Merkle tree integrity check data and combining the technical solution of recording all key operations in the distributed ledger module, thereby effectively verifying the integrity of data during long-term storage.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of archive storage, in particular to an archive storage system and method based on a digital object architecture. BACKGROUND

[0002] With the rapid development of information technology, the data in various fields of society is growing exponentially. The long-term, secure, reliable preservation and efficient use of electronic archives as key information assets have become a core challenge that organizations must face. How to ensure the authenticity, integrity, availability and security of digital archives throughout their life cycle, and on this basis to balance management efficiency and operating costs, is the focus of current research in the field of archive informatization.

[0003] In existing digital archive management practices, a relatively mature but traditional combination of technologies is usually used to address the above challenges. To ensure data integrity, the system generally uses MD5 or SHA series checksum algorithms to generate a unique hash value for the archive file and store it together. For the traceability of operation behavior, the system relies on a log module deployed on a centralized server to record the user's operations. In terms of archive life cycle management, the management personnel will define the management strategy in advance, and then an independent application will scan the archive library through a timed task to perform operations such as expiration and archiving in batch mode.

[0004] However, the existing archive storage technology in response to the massive and highly correlated modern archive management requirements, the checksum and the log are stored in a system that can be modified, and malicious or erroneous operations can simultaneously tamper with the data and its checksum, making the verification mechanism ineffective, the strategy and data are separated, the execution relies on periodic batch processing, it is difficult to respond to real-time events, and to ensure query efficiency, all indexes are deployed on high-performance storage media, which is costly. Therefore, the present application provides an archive storage system and method based on a digital object architecture to solve the deficiencies in the prior art. SUMMARY

[0005] In view of the deficiencies of the prior art, the present application provides an archive storage system and method based on a digital object architecture, which solves the problems of data integrity verification, life cycle strategy management, operation behavior traceability and multi-object correlation management in existing archive management systems.

[0006] To achieve the above purpose, the present application is implemented by the following technical solutions:

[0007] The present application provides an archive storage system based on a digital object architecture, comprising:

[0008] A unique identifier and relationship analysis component for generating a globally unique object identifier;

[0009] a digital object repository configured to receive externally incoming archival electronic original, structured metadata, relationship topology pointers and embedded lifecycle policies, and atomically encapsulate by the globally unique object identifier to build a digital object containing integrity check data, and to synchronously generate a corresponding structured transaction upon completion of the digital object build;

[0010] a digital object registry configured to extract the structured metadata encapsulated in the digital object, and to establish a searchable metadata index for the digital object based on the extracted structured metadata;

[0011] a distributed ledger module configured to respond to the structured transaction by consensus algorithm to form an immutable on-chain record of the structured transaction, and to broadcast the structured transaction as a trusted event over a bus;

[0012] a policy driven engine configured to listen to and receive the broadcasted structured transaction, invoke the unique identifier and relationship resolution component based on the content of the structured transaction or a policy query request of the metadata index to determine the affected contextual scope, and execute the embedded lifecycle policies on the digital objects within the contextual scope to perform storage management and dynamic governance of the archival information encapsulated as digital objects.

[0013] Preferably, the digital object repository comprises:

[0014] an integrity check data generation module configured to process the received electronic original by a Merkle tree algorithm to generate integrity check data, the integrity check data comprising a Merkle tree root hash value and an authentication path.

[0015] Preferably, the integrity check data generation module is specifically configured to:

[0016] divide the data of the electronic original into n data blocks ;

[0017] calculate a hash value of each data block by an encryption hash algorithm :

[0018] ;

[0019] wherein, represents the hash value of the i-th data block, represents the determined encryption hash algorithm used for calculation, represents the i-th data block obtained after the original data is divided;

[0020] ​​Adjacent hash values ​​are concatenated and hashed recursively until a unique Merkle root hash value is generated. The hash value of any parent node is calculated as follows:

[0021] ;

[0022] in, Represents the hash value of any parent node. and These represent the hash values ​​of the left and right child nodes of the parent node, respectively.

[0023] While generating the root hash value of the Merkle tree, the integrity verification data generation module also records the authentication path from the leaf node of each data block to the root node of the Merkle tree. The authentication path is used to combine the hash value of any data block in the electronic original to reconstruct the root hash value of the Merkle tree and verify the validity of any data block in the electronic original.

[0024] Preferably, the digital object registry employs a hot / cold data-aware bi-state indexing engine, which physically divides the data into hot and cold index areas and establishes a dynamic migration mechanism.

[0025] The hot index area is used to store index data whose index popularity value is higher than a preset threshold.

[0026] The cold index area is used to store index data whose index popularity value is lower than or equal to the preset threshold.

[0027] The dynamic migration mechanism is used to move index data between the hot index area and the cold index area according to the change of the index popularity value.

[0028] Preferably, the dual-state indexing engine for sensing hot and cold data includes a heat assessment module, which is used to dynamically calculate and update the index at a given time point using the following formula. Popularity value :

[0029] ;

[0030] in, Indicates the index at the current time point Popularity value The time point of the previous event Popularity value It is a time decay constant. This indicates the time interval since the last event. This is to increase the popularity of visits.

[0031] Preferably, the unique identifier and relationship resolution component includes a relationship graph engine, which is used to parse the relationship topology pointers in digital objects and model the archive resource library formed by all digital objects stored in the digital object repository as an attribute graph model. , where the set of nodes Each node in the array corresponds to a digital object, and the edge set... Each directed edge in Represents the logical relationships between digital objects, where Indicates the starting node. Indicates the termination node. Labels representing edges, Represents a collection of attributes.

[0032] Preferably, the structured transactions recorded by the distributed ledger module specifically include event messages with the following fields:

[0033] ;

[0034] in, This represents a structured transaction or event message. Represents the consensus timestamp. Indicates the identifier of the entity initiating the operation. Represents standardized operation type codes, A globally unique identifier for the target digital object , This represents a scalable data payload field. It is the main operating entity Digital signature of transaction content.

[0035] Preferably, when the strategy-driven engine calls the unique identifier and relationship resolution component to determine the affected context scope, it specifically initiates a graph traversal query to the relationship graph engine to obtain the set of all logically affected object identifiers as the context scope.

[0036] Preferably, the strategy-driven engine is also used to generate a new structured transaction describing the current execution operation after the embedded lifecycle strategy is executed, and submit it back to the distributed ledger module for recording and broadcasting.

[0037] This invention also provides a file storage method based on a digital object architecture, comprising the following steps:

[0038] S1. Generate globally unique object identifiers through the unique identifier and relationship resolution component;

[0039] S2, atomically encapsulating the received electronic original, structured metadata, relationship topology pointer and embedded life cycle policy with the globally unique object identifier to build a digital object containing integrity check data;

[0040] S3, extracting the structured metadata encapsulated in the digital object, and establishing a searchable metadata index for the digital object based on the encapsulated structured metadata;

[0041] S4, based on the successful construction of the digital object in the digital object warehouse, generating a structured transaction describing the construction operation, forming an unalterable on-chain record of the structured transaction through a consensus algorithm, and broadcasting the structured transaction as a trusted event through the bus;

[0042] S5, listening to and receiving the broadcasted structured transaction, calling the unique identifier and relationship analysis component based on the content of the structured transaction or the policy query request of the metadata index to determine the affected context scope, and executing the embedded life cycle policy in each digital object in the affected context scope to store and manage the archival information encapsulated as a digital object.

[0043] The present application provides an archival storage system and method based on a digital object architecture, which has the following beneficial effects:

[0044] The present application encapsulates an embedded life cycle policy in a digital object and sets up a policy-driven engine driven by trusted events to automatically and intelligently manage digital object archival information. The policy-driven engine can listen to events broadcast by a distributed ledger module and call a relationship graph engine in the unique identifier and relationship analysis component to obtain the complete logical context of the affected object, thereby realizing dynamic policy execution based on real-time events and associated relationships and improving the intelligent level and efficiency of archival management.

[0045] The present application constructs an electronic original into a digital object containing Merkle tree integrity check data and records all key operations in a distributed ledger module, thereby realizing full-chain trust protection of archival data from content to process, effectively checking the integrity of data during long-term storage, and providing unalterable and traceable audit credentials for each operation, thereby solving the problems of easy data tampering and difficult accountability of operation behavior in traditional archival systems.

[0046] The application adopts a hot and cold data-aware dual-state index engine in a digital object registry, the dual-state index engine dynamically calculates the access hotness of indexes through a built-in hotness evaluation module, and stores hot indexes with high-frequency access in high-performance media and cold indexes with low-frequency access in low-cost media, thereby realizing adaptive optimization balance between storage cost and query performance, and effectively solving the resource allocation problem in a large-scale archive system. BRIEF DESCRIPTION OF DRAWINGS

[0047] Figure 1 A system architecture diagram of an embodiment of the application;

[0048] Figure 2 A digital object diagram of an embodiment of the application;

[0049] Figure 3 A digital object registry diagram of an embodiment of the application;

[0050] Figure 4 A strategy driving engine diagram of an embodiment of the application;

[0051] Figure 5 A method step flowchart of an embodiment of the application. DETAILED DESCRIPTION

[0052] The technical solutions in the embodiments of the application will be described clearly and completely below with reference to the accompanying drawings of the application. Obviously, the described embodiments are only part of the embodiments of the application, rather than all the embodiments. Based on the embodiments in the application, all other embodiments obtained by those skilled in the art without creative work fall within the scope of protection of the application.

[0053] Reference Figures 1 to 4 , Figure 1 FIG. 1 is an archive storage system architecture diagram based on a digital object architecture according to an embodiment of the application. The embodiment of the application provides an archive storage system based on a digital object architecture, which includes a unique identification and relationship analysis component 100, a digital object warehouse 200, a digital object registry 300, a distributed ledger module 400, and a strategy driving engine 500.

[0054] In an embodiment of the present application, the overall operation mechanism of the system is developed around the atomization life cycle of digital objects. The digital object repository 200 is used to perform the atomic encapsulation, physical storage and integrity maintenance of archival information. The digital object registry 300 and the unique identification and relationship resolution component 100 together provide efficient data positioning, metadata retrieval and logical relationship discovery capabilities for upper-layer applications. The distributed ledger module 400 provides tamper-proof evidence for key operations of the system and serves as a trusted event source. The policy-driven engine 500 serves as the intelligent governance core of the system, which realizes the automatic execution of the archival life cycle policy by listening to the trusted events and combining the associated context of the object.

[0055] When the system receives an external archival request, the archival request is first directed to the digital object repository 200. The digital object repository 200 obtains a unique object identifier from the unique identification and relationship resolution component 100 and performs an atomic encapsulation operation to integrate the electronic original, metadata, relationship topology pointer and embedded life cycle policy into a single digital object. The Merkle tree root hash and metadata digest generated during the encapsulation process will be used for subsequent processing.

[0056] After encapsulation, the digital object repository 200 sends the structured metadata of the digital object to the digital object registry 300 to build or update the retrieval index. At the same time, the identifier of the object and its relationship topology pointer are sent to the unique identification and relationship resolution component 100 to create corresponding nodes and associated edges in the internal relationship graph. The digital object body is then distributed to the appropriate physical storage medium according to its life cycle policy.

[0057] At the same time as the above data persistence and index construction, a transaction record describing this archival operation is generated. The transaction record contains information such as operation timestamp, operation type, object identifier and content digest. This transaction record is submitted to the distributed ledger module 400 and recorded on the chain through a consensus algorithm, forming an unalterable traceable certificate. The working process is as follows: the received to-be-processed archival transaction (and other operation transactions) is packaged into a candidate block, and broadcast to all verification nodes in the network. Each verification node independently verifies the validity of all transactions in the block (such as checking the signature and content legality). After verification, these nodes will communicate and vote according to the pre-set consensus rules to determine the common recognition of the candidate block, and when the candidate block obtains the recognition of the majority or a predetermined proportion of nodes in the network, the candidate block is formally appended to the end of the block chain. Since each new block contains the hash value of the previous block, this chain structure ensures that the block cannot be tampered with once it is chained, thus forming an unalterable traceable certificate.

[0058] The policy-driven engine 500 continuously listens to new blocks on the distributed ledger module 400. When the transaction record of the archiving operation is confirmed on-chain, the policy-driven engine 500 parses the transaction record of the archiving operation as a trusted system event. According to the content of the trusted system event, the policy-driven engine 500 calls the unique identifier and relationship parsing component 100 to query the context information of the new archiving object and other objects associated therewith.

[0059] Based on the acquired event and context, the policy-driven engine 500 evaluates the lifecycle policy embedded in each object in the set of affected objects. If the policy condition is met, the policy-driven engine 500 will generate corresponding instructions, for example, sending instructions to the digital object registry 300 to update the state metadata of a certain associated object, or sending instructions to the digital object warehouse 200 to trigger a high-priority integrity check. These operations automatically executed by the policy-driven engine 500, the results of which will also be submitted to the distributed ledger module 400 as new transaction records, thus forming a dynamic, closed-loop, automated archive governance process.

[0060] The unique identifier and relationship parsing component 100 is a pivotal component in the embodiments of the present application for providing global unique identity for digital objects and modeling and parsing the logical association relationship between digital objects. The unique identifier and relationship parsing component 100 provides the object positioning and context discovery capability for other parts of the system, especially the policy-driven engine 500.

[0061] In a specific embodiment, the unique identifier and relationship parsing component 100 includes a unique identifier service module. The unique identifier service module is used to generate and manage the unique identifier of the digital object. When the digital object warehouse 200 needs to create a new digital object, it requests an identifier from the unique identifier service module. The identifier generated by the unique identifier service module is a 128-bit globally unique identifier , which can be specifically constructed in a combination of Universally Unique Identifier (UUID) and object core metadata hash value to ensure its uniqueness and stability in a distributed environment. The unique identifier service module also maintains a mapping table of identifiers to physical locations to respond to basic object positioning requests.

[0062] To realize the in-depth management and utilization of complex logical relationships among archives, the unique identifier and relationship parsing component 100 internally has a relationship graph engine. The relationship graph engine avoids the limitations of traditional metadata flat management and uses graph database technology to represent the entire archive resource library as an attribute graph model which can be defined as:

[0063] ;

[0064] wherein, is a set of nodes in the property graph. Each node in the set corresponds to an independent digital object, and uses the unique identifier of the digital object as its unique identification. The node itself can be attached with attributes, such as a type attribute (e.g. report, drawing or approval letter) identifying the type of the object. is a set of edges in the property graph, representing the directed logical relationships between digital objects. Each edge in the set is a tuple, which can be represented as .

[0065] In the definition of an edge, is the starting node (source object) of the relationship, is the terminating node (target object) of the relationship. is the label of the edge, used to define the specific type of the relationship, whose value can be a semantic string such as version evolution relationship, main-attachment relationship, reference relationship or approval relationship. is an optional set of attributes, used to describe the characteristics of the relationship itself, such as the timestamp of the establishment of the relationship or the weight of the relationship, etc.

[0066] The relationship graph engine contains a graph construction and maintenance module. The graph construction and maintenance module is triggered when a digital object is created or updated. It parses the set of relationship topology pointers encapsulated inside the digital object , wherein represents each relationship topology pointer in the set . For each relationship topology pointer in the set, the graph construction and maintenance module looks up the source object node and the target object node in the graph database, and creates a directed edge with the corresponding label between the two nodes according to the pre-set business logic. This process ensures that the graph model can accurately reflect all the declared logical relationships between objects in the system in real time.

[0067] The relationship graph engine also provides a high-level query interface. The high-level query interface supports complex graph traversal queries, and is the technical basis for the strategy-driven engine 500 to implement context-aware decisions. The types of queries that can be performed by the high-level query interface include but are not limited to:

[0068] Given a node of a project object, query all the attachment object nodes directly connected through edges representing the main-attachment relationship type;

[0069] Given an approval letter object node, traverse the edges representing the approval relationship type in reverse direction to find all the drawing object nodes it has approved;

[0070] Given a report object's latest version node, recursively traverse all the edges representing the version evolution relationship type in reverse direction to trace and return all the object nodes on its complete version evolution path.

[0071] When the policy driving engine 500 listens to an event targeting a specific object , it invokes this high-level query interface. The query request is no longer a simple "find ", but for example "find all the object collections that have a direct or indirect representation reference relationship with , and whose object type is report". The relationship graph engine executes the corresponding graph traversal algorithm and returns the set of node identifiers that satisfy the condition to the policy driving engine 500, thus providing an accurate and complete context scope for its execution policy.

[0072] Please refer to Figure 2 , the digital object warehouse 200 is a component in the embodiment of the present application for the construction, persistent storage and integrity guarantee of digital object entities. It integrates multiple functional modules inside, and cooperates to complete the whole process from receiving discrete archive information to generating, storing and maintaining an atomized digital object with endogenous management capabilities.

[0073] In a specific embodiment, the digital object warehouse 200 contains an atomization encapsulation module. The atomization encapsulation module is used to receive externally transmitted archive electronic original text, structured metadata describing the archive, and combine the system generated relationship topology pointer used to describe the logical relationship between objects, and an embedded life cycle strategy defining the management rules of the object itself, to aggregate and encapsulate these heterogeneous information, forming a logically indivisible, self-contained digital object.

[0074] The relationship topology pointer refers to the structured data field encapsulated in the digital object, which is used to declare the logical relationship between the digital object and other digital objects in the archive resource library. It serves as an explicit link to guide the relationship graph engine in the unique identification and relationship analysis component 100 to build and maintain a complete archive resource relationship network.

[0075] The atomic encapsulation module of the Digital Object Repository 200 also integrates a unit for generating and implanting an Embedded Lifecycle Policy (ELP). This embedded lifecycle policy is a structured, machine-readable policy file, which can be implemented as a JSON or YAML text file. This file defines a series of rules and parameters that guide the behavior of the digital object throughout its entire lifecycle.

[0076] Embedded Lifecycle Policy (ELP) refers to an intrinsic set of management rules atomically encapsulated within digital object entities. It decouples file management policies from external, independent management systems, treating them as an integral part of the digital object. ELP ensures a permanent binding between management rules and data entities, maintaining consistency in inherent management requirements and behavioral logic regardless of the environment in which the digital object is stored or migrated. This consistency allows for real-time, automated interpretation and execution by the policy-driven engine.

[0077] To achieve efficient and accurate verification and maintenance of the integrity of archival data during long-term storage, the Digital Object Repository 200 includes an integrity verification data generation module. This module uses the Merkle Tree algorithm to process the original electronic data before encapsulation. Specifically, this module generates a set of original electronic data... Divided into n data blocks of a preset size .

[0078] The integrity verification data generation module uses a deterministic cryptographic hash algorithm. (For example, the national cryptographic algorithm SM3) performs independent hash calculations on each data block to generate a set of leaf nodes of a Merkle tree. .

[0079] ;

[0080] in, This represents the hash value of the i-th data block; This refers to a specific cryptographic hash algorithm used for computation. This represents the i-th data block obtained after the original data has been divided.

[0081] After generating the leaf nodes, the integrity verification data generation module recursively constructs the remaining levels of the tree. It concatenates two adjacent hash values ​​(using symbols...). (represented by the symbol), and then perform hash calculation again on the concatenated results to generate their parent nodes. This process continues until a unique Merkle root hash value is finally calculated. The calculation of any parent node can be expressed as:

[0082] ;

[0083] wherein, represents the hash value of any parent node; and represent the hash values of the left child node of the parent node and the right child node of the parent node, respectively. The "||" symbol is a standard operator in cryptography and computer science to represent byte concatenation. The final generated root hash value and the authentication path necessary to verify a specific data block together constitute the integrity verification data of the digital object, and are encapsulated together inside the digital object. This structure makes it unnecessary to read and calculate the entire original text during subsequent verification, and only needs to verify a hash path to verify the integrity of a specific data block, and can accurately locate the specific damaged data block when the data is damaged.

[0084] The atomization encapsulation module of the digital object warehouse 200 also integrates a generation and implantation unit of an embedded lifecycle policy (ELP). The embedded lifecycle policy is a structured, machine-readable policy file, and its implementation can be a JSON or YAML format text file. The file defines a series of rules and parameters for guiding the entire lifecycle behavior of the digital object.

[0085] These rules and parameters are not broad functional descriptions, but specific, directly parseable and executable instructions by the system. Specifically, the ELP file can include but is not limited to the following fields: a retention period field defining the minimum archival period of the archive; a security level field identifying the data security level; a storage tier preference field specifying where the data should be stored, whose value can be a specific type such as a high-performance layer, a low-cost archival layer, or a WriteOnce, Read Many (WORM) medium; and an access control policy field defining which role or condition can access the object. The ELP file, as one of the metadata of the digital object, is encapsulated within the logical boundary of the object and stored, migrated with the object, ensuring the permanent binding of the management policy and the data.

[0086] The digital object repository 200 also contains a physical storage distribution module. The function of this module is tightly coupled with the embedded life cycle policy described above. After a digital object is encapsulated, the physical storage distribution module is configured to parse the ELP file embedded in the object. The physical storage distribution module reads the policy fields defined in the ELP, such as security level, storage tier preference, etc., and dynamically selects the most suitable physical storage node or pool for data persistence according to these policy rules.

[0087] In one embodiment, if the storage tier preference field value in the ELP of a digital object is "WORM media", the physical storage distribution module will invoke the corresponding storage interface to write the data shards of this digital object to an archival Blu-ray disc library or a WORM-enabled tape library. If the security level field value in the ELP of another object is "Top Secret", the physical storage distribution module will route it to a dedicated storage cluster that is physically isolated and highly encrypted. Meanwhile, the physical storage distribution module will also distribute the data shards of a digital object to different physical nodes with the specified number of redundant copies according to the availability requirements defined in the ELP through distributed algorithms such as consistent hashing, thereby achieving differentiated and intelligent storage management driven by data endogenous policies.

[0088] Referring to Figure 3 , the digital object registry 300 is a key component in the present embodiment to provide centralized management and efficient retrieval services for archival metadata. The digital object registry 300 receives structured metadata from the digital object repository 200 when a digital object is created or updated and indexes it. It is used to quickly locate the unique identifier set of the target digital object according to the user's search conditions without directly storing the electronic original of the archive.

[0089] In a specific implementation, the digital object registry 300 can integrate multiple index structures internally to support different types of queries. For example, a B+ tree index can be used to support range queries based on specific attributes of the archive (e.g., creation date), while an inverted index can be used to support full-text retrieval or multi-key combination queries based on the title, abstract, etc. of the archive.

[0090] To address the highly uneven data access frequency in massive archive storage scenarios, the digital object registry 300 of this invention employs a hot / cold data-aware dual-state indexing engine. This dual-state indexing engine physically divides the data into hot and cold index areas and establishes a dynamic migration mechanism. The hot index area stores index data with an index popularity value higher than a preset threshold; the cold index area stores index data with an index popularity value lower than or equal to the preset threshold. The dynamic migration mechanism moves index data between the hot and cold index areas based on changes in index popularity values, thereby achieving an optimized balance between storage costs and query performance.

[0091] This bimorphic indexing engine includes a popularity evaluation module for dynamically calculating the popularity value of each metadata index. The popularity value is a quantifiable metric representing the likelihood of that index being accessed in the future. The calculation can comprehensively consider multiple dimensions, and its time point value The update can be performed using the following formula:

[0092] ;

[0093] in, Indicates the index at the current time point Popularity value; This indicates the index at the time of the previous event. Popularity value; It is a preset time decay constant. This is used to reflect the timeliness of popularity, that is, the popularity of an index that has not been accessed for a long time will naturally decrease over time. It is the time interval since the last incident; It is an access popularity increment. When the numeric object corresponding to the index is accessed, its value is a fixed positive number; if no access event occurs, and only periodic popularity decay calculation is performed, its value is 0.

[0094] Based on the heat assessment results, the dual-state index engine stores index data in two different physical storage areas. The hot index area is configured on high-performance storage media, such as system main memory (RAM) or high-speed non-volatile memory, to support extremely low-latency index queries. The cold index area is configured on lower-cost, higher-capacity conventional storage media, such as Serial Advanced Technology Attached (SATA) solid-state drives or hard disk drives (HDDs).

[0095] The dual-state indexing engine also includes a dynamic migration module that moves index data between hot and cold zones based on preset thresholds. The mechanism of this dynamic migration module includes: when an index located in the cold index zone experiences a query that increases its popularity value... Rise and exceed a preset promotion threshold When this happens, the dynamic migration module will migrate the index data from the cold index area to the hot index area. Conversely, a background scanning process will periodically perform a heat decay calculation on all indexes in the hot index area, and when the heat value of a certain index... The number of users has fallen below a preset degradation threshold due to prolonged inactivity. When this happens, the index data will be migrated from the hot index area to the cold index area, thereby freeing up valuable high-performance storage resources.

[0096] When processing user search requests, the query process of the Digital Object Registry 300 is optimized. The system first searches in the hot index area. If the query is successful (i.e., an index that meets the criteria is found in the hot index area), the corresponding object identifier is immediately returned, completing an efficient query. If no match is found in the hot index area, the system continues searching in the cold index area. If a match is found in the cold index area, the system, while returning the result, triggers a popularity assessment of the index and a potential promotion operation to the hot index area. This query path is transparent to the user; the system automatically handles on-demand index loading and hot data management.

[0097] The distributed ledger module 400 is a component that builds the system's trust foundation in this embodiment of the invention. In one specific implementation, the distributed ledger module 400 can be implemented using a consortium blockchain architecture, where multiple trusted nodes jointly maintain a unified, shared ledger. This distributed ledger module 400 provides persistent, immutable records for critical operations in the system and serves as a trusted event source for triggering automated governance processes.

[0098] The distributed ledger module 400 primarily functions as an immutable audit log. Critical operations performed on digital objects within the system, such as object creation, significant changes to metadata, modifications to access permissions, adjustments to security levels, and governance actions automatically executed by the policy-driven engine 500, are all encapsulated as transactions and submitted to the distributed ledger module 400. The distributed ledger module 400 then uses a consensus algorithm to link these transactions chronologically into blocks, forming an immutable and traceable historical record of operations to meet the needs of compliance auditing and post-event accountability.

[0099] In this embodiment, the function of the distributed ledger module 400 is further extended and designed as an active, system-wide, trusted event bus. The distributed ledger module 400 is the root driver of the automated workflow of the policy-driven engine 500. The policy-driven engine 500 is configured as a subscriber of the distributed ledger module 400, which listens and receives transaction records packaged into new blocks after consensus confirmation in real time.

[0100] To realize this event bus function, the transaction submitted to the distributed ledger module 400 is designed as a structured, machine-readable event message, which can include the following fields:

[0101] ;

[0102] Among them, represents a structured transaction or event message; represents a consensus timestamp generated by the ledger system, which ensures the authority of the event time; is the subject identifier of the operation; represents a standardized operation type code, which is used to define the nature of the event, such as creating an object, updating metadata, changing a secret level, or policy execution; is the globally unique identifier of the target digital object , which is the starting point for the policy-driven engine 500 to trace the relationship; is an extensible data payload field that carries the specific parameters of the event in a structured format (such as JSON). For example, for an operation of updating metadata, may include the field name modified, the value before modification, and the value after modification; is the operation subject is the digital signature of the above transaction content, which is used to ensure the authenticity and non-repudiation of the event.

[0103] When a new block containing structured transactions is confirmed by the consensus algorithm (such as Practical Byzantine Fault Tolerance PBFT) of the distributed ledger module 400 and permanently attached to the ledger chain, the distributed ledger module 400 immediately broadcasts the transactions in this new block to all subscribers (including the policy-driven engine 500). After receiving these transactions, the policy-driven engine 500 parses them into explicit, trusted system governance events. This design transforms an operation record originally used for evidence into a high-trust trigger signal that drives system state transitions, thereby forming the basis of the automated governance process.

[0104] Referring to Figure 4, the policy-driven engine 500 has two driving modes: one is to analyze the trusted events provided by the distributed ledger module 400 dynamically; the other is to actively respond to the policy query request based on the digital object registry 300. No matter which mode, the policy-driven engine 500 will eventually combine the inter-object association context provided by the unique identification and relationship analysis component 100 to interpret and execute the life cycle policy embedded in the digital object in real time and dynamically.

[0105] In the first event-driven mode, the policy-driven engine 500 contains a trusted event listener module. As a client node or subscriber of the distributed ledger module 400, the trusted event listener module continuously listens to and receives the latest block confirmed by consensus. When a new block is added to the chain, the trusted event listener module obtains all structured transaction records in it and transmits these records as raw trigger signals to the decision core of the policy-driven engine 500.

[0106] The core of the policy-driven engine 500 is the context analysis and decision module. This context analysis and decision module is the key to intelligent governance, and its workflow can flexibly handle the input of the above two driving modes.

[0107] For the event-driven mode, the context analysis and decision module receives structured transaction records from the trusted event listener module , and parses them into a standardized internal event object . This event object contains the operation type, operation subject, target object identifier and related parameter load that triggered the event. Then, the context analysis and decision module takes as the starting point to call the relationship graph engine of the unique identification and relationship analysis component 100 to initiate a context association query and obtain a set of all logically affected object identifiers, which is defined as the context scope .

[0108] For the query-driven mode, the context analysis and decision module can also receive and process policy query requests from administrators or external systems. Such requests are not triggered by on-chain events, but are based on the metadata attributes of the archive for batch governance scenarios, such as "perform a storage medium check policy on all archives with a permanent preservation period and a creation time earlier than five years ago". At this time, the context analysis and decision module will call the digital object registry 300 to quickly retrieve all object identifiers that meet the query conditions using its metadata index. This retrieval result set will be directly used as the initial context scope .

[0109] After obtaining the context scope Next, the context resolution and decision-making module begins to evaluate the policy for each object within the scope. Any object identifier in The context resolution and decision-making module reads the corresponding digital object and extracts the embedded lifecycle strategy (ELP) file within it. The decision-making logic of the context resolution and decision-making module is implemented through a policy execution function. To achieve this, the strategy execution function will execute the object's static strategy. and dynamic execution context As input, calculate the set of actions to be performed on the object. :

[0110] ;

[0111] in, Represents a set of actions; This represents the policy execution function; Indicates the first Static strategy for each object; For index; execution context For containing the triggering source (e.g., the original event) Or strategy query request and the entire context scope A combined data structure.

[0112] The Policy-Driven Engine 500 also includes a policy execution and governance closed-loop module. This module is used to process the action set output by the context resolution and decision-making module. This translates into specific operation instructions for other components of the system. For example, updating metadata is translated into a write operation request to the digital object registry 300; migrating storage media is translated into a data migration task to the digital object repository 200.

[0113] After successfully executing one or more governance actions, the strategy execution and governance closed-loop module will generate one or more new, structured transaction records based on the execution results. These new transaction records detail the operations automatically executed by the Strategy-Driven Engine 500, including the executor (i.e., the engine itself), the operation type (such as strategy execution), the operated object, and the specific operation content. Subsequently, these... The signed and submitted back to the distributed ledger module 400. These new transaction records are also part of the chain after consensus, which is not tamperable, not only provides irrefutable audit evidence for automated governance behavior, but also may be captured as a new trusted event by the trusted event listener module of the strategy-driven engine 500, thereby triggering the next round of context analysis and policy execution.

[0114] Referring to Figure 5 , Figure 5 is a flow chart of a digital object architecture-based archive storage method according to an embodiment of the present application. The present application provides a digital object architecture-based archive storage method, comprising the following steps:

[0115] S1, generating a globally unique object identifier by a unique identifier and relationship analysis component;

[0116] S2, using the globally unique object identifier, atomically encapsulating the received electronic original, structured metadata, relationship topology pointer and embedded life cycle policy to construct a digital object containing integrity check data;

[0117] S3, extracting the structured metadata encapsulated in the digital object, and establishing a searchable metadata index for the digital object based on the encapsulated structured metadata;

[0118] S4, based on the successful construction of the digital object in the digital object warehouse, generating a structured transaction describing the construction operation, forming an unalterable on-chain record of the structured transaction through a consensus algorithm, and broadcasting the structured transaction as a trusted event through the bus;

[0119] S5, listening to and receiving the broadcasted structured transaction, calling the unique identifier and relationship analysis component based on the policy query request of the structured transaction content or metadata index to determine the affected context scope, and executing the embedded life cycle policy in each digital object in the affected context scope to store and manage the archive information encapsulated as a digital object.

[0120] Although embodiments of the present application have been shown and described, it is to be understood that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the present application, the scope of which is defined by the appended claims and their equivalents.

Claims

1. An archival storage system based on a digital object architecture, characterized by, include: Unique Identifier and Relationship Resolution Component, used to generate globally unique object identifiers; The digital object repository is used to receive externally input electronic archives, structured metadata, relational topology pointers, and embedded lifecycle strategies, and to atomically encapsulate them using the globally unique object identifier to construct digital objects containing integrity verification data. After the digital objects are constructed, corresponding structured transactions are generated synchronously. A digital object registry is used to extract the structured metadata encapsulated in the digital object and to build a searchable metadata index for the digital object based on the extracted structured metadata. The distributed ledger module is used to respond to the structured transaction, form an immutable on-chain record of the structured transaction through a consensus algorithm, and broadcast the structured transaction as a trusted event through the bus; The strategy-driven engine is used to listen for and receive broadcast structured transactions, and invoke the unique identifier and relationship resolution component based on the content of the structured transaction or the strategy query request of the metadata index to determine the affected context scope, and execute the embedded lifecycle strategy on the digital objects within the context scope to perform storage management and dynamic governance of the archive information encapsulated as digital objects. The digital object registry employs a dual-state indexing engine that is aware of both hot and cold data. This dual-state indexing engine physically divides the data into a hot index area and a cold index area, and establishes a dynamic migration mechanism. The hot index area stores index data with an index popularity value higher than a preset threshold; the cold index area stores index data with an index popularity value lower than or equal to the preset threshold. The dynamic migration mechanism moves index data between the hot and cold index areas based on changes in the index popularity value. The unique identifier and relationship resolution component includes a relationship graph engine, which is used to parse the relationship topology pointers in digital objects and model the archive resource library formed by all digital objects stored in the digital object repository as an attribute graph model. , where the set of nodes Each node in the array corresponds to a digital object, and the edge set... Each directed edge in Represents the logical relationships between digital objects, where Indicates the starting node. Indicates the termination node. Labels representing edges, This represents a set of attributes, and the labels on the edges are used to define the specific types of logical relationships. Specifically, when the strategy-driven engine calls the unique identifier and relationship resolution component to determine the affected context scope, it initiates a graph traversal query based on a graph traversal algorithm to the relationship graph engine to obtain the set of all logically affected object identifiers as the context scope.

2. The digital object architecture based archival storage system as claimed in claim 1, wherein, The digital object repository includes: The integrity verification data generation module is used to process the received electronic original text using the Merkle tree algorithm to generate integrity verification data, which includes the Merkle tree root hash value and the authentication path.

3. An archival storage system based on a digital object architecture according to claim 2, wherein, The integrity verification data generation module is specifically used for: Data of the electronic original Split into n data blocks ; Using a cryptographic hash algorithm For each data block Compute to generate the hash value of the leaf node: ； wherein, denotes a hash value of the i-th data block, denotes a determined cryptographic hash algorithm for the calculation, denotes the i-th data block obtained after the original data is divided. concatenating and hashing adjacent hash values in a recursive manner until a unique merkle tree root hash value is generated wherein the hash value of any parent node is calculated as ； wherein, represents a hash value of an arbitrary parent node, and respectively represent a hash value of a left child node of the parent node and a hash value of a right child node of the parent node; While generating the root hash value of the Merkle tree, the integrity verification data generation module also records the authentication path from the leaf node of each data block to the root node of the Merkle tree. The authentication path is used to combine the hash value of any data block in the electronic original to reconstruct the root hash value of the Merkle tree and verify the validity of any data block in the electronic original.

4. The archive storage system based on a digital object architecture according to claim 1, characterized in that, The cold-hot data-aware dual-state index engine comprises a hotness evaluation module, which is configured to dynamically calculate and update the hotness value of the index at a time point t by the following formula :​ ； wherein, represents an index of the heat value at the current time point , is the heat value at the previous event time point , is a time decay constant, represents the time interval since the last event, is the access heat increment.

5. The digital object architecture based archival storage system as claimed in claim 1, wherein, The structured transactions recorded by the distributed ledger module specifically include event messages with the following fields: ； in, This represents a structured transaction or event message. Represents the consensus timestamp. Indicates the identifier of the entity initiating the operation. Represents standardized operation type codes, A globally unique identifier for the target digital object , This represents a scalable data payload field. It is the main operating entity Digital signature of transaction content.

6. The archive storage system based on a digital object architecture according to claim 1, characterized in that, The strategy-driven engine is also used to generate a new structured transaction describing the current operation after the embedded lifecycle strategy is executed, and submit it back to the distributed ledger module for recording and broadcasting.

7. A method for storing archives based on a digital object architecture, characterized in that, The method is applied to an archive storage system based on a digital object architecture as described in any one of claims 1-6, and the method includes the following steps: S1. Generate globally unique object identifiers through the unique identifier and relationship resolution component; S2. Using the globally unique object identifier, the received electronic plaintext, structured metadata, relational topology pointers, and embedded lifecycle strategies are atomically encapsulated to construct a digital object containing integrity verification data. S3. Extract the structured metadata encapsulated in the digital object, and establish a searchable metadata index for the digital object based on the encapsulated structured metadata; S4. Based on the successful construction of digital objects in the digital object repository, generate a structured transaction describing the construction operation, form an immutable on-chain record of the structured transaction through a consensus algorithm, and broadcast the structured transaction as a trusted event through the bus. S5. Listen to and receive the broadcast structured transactions, and call the unique identifier and relationship resolution component based on the content of the structured transactions or the policy query request of the metadata index to determine the affected context scope, and execute the embedded lifecycle policy of each digital object in the affected context scope to perform storage management and dynamic governance of the archive information encapsulated as digital objects.

Images