Content version-based data storage and reading method, device and storage medium

Abstract

The application provides a content version-based data storage and reading method and device. The method comprises the following steps: obtaining a change command of file content, wherein the change command comprises an identifier of an aggregate root, a type of the aggregate root and an operation command; querying an event stream information table according to the identifier of the aggregate root and the type of the aggregate root to obtain a historical event version number corresponding to a last state of the aggregate root; generating a new event object according to the change command and the historical event version number, wherein the new event object comprises the identifier of the aggregate root, the type of the aggregate root, a new event version number, an event occurrence time and change content corresponding to the operation command; and serializing the event object into an event table according to the event occurrence time. The application improves the accuracy, reliability and efficiency of data item version management.

Description

Technical Field

[0001] This application relates to the field of data processing, and in particular to a method, device, and storage medium for storing and retrieving data based on content versions. Background Technology

[0002] The current system needs to version control the stored unstructured data for easy rollback and viewing of past revision records, and to create versions for important revisions. It also needs to audit this data and perform multi-scenario queries on the information contained therein.

[0003] Existing version control solutions for unstructured data often rely on fully saving the complete content of each revision; operation records depend on recording the time, operator, and changes in the full log; and querying this unstructured data relies on non-relational databases to retrieve data in order to meet the expected performance requirements, which increases the system's technology stack and risk points.

[0004] Therefore, it is necessary to design a data storage and retrieval method, device, and storage medium based on content version to improve the accuracy, reliability, and efficiency of content version management. Summary of the Invention

[0005] This application provides a content version-based data storage and retrieval method, device, and storage medium to solve the problems of fully preserving the complete content of each revision in version control schemes for unstructured data and the performance issues of unstructured data retrieval.

[0006] Firstly, this application provides a content-version-based data storage method, including:

[0007] A command to obtain changes to file content, wherein the change command includes the identifier of the aggregate root, the type of the aggregate root, and the operation command;

[0008] Based on the identifier and type of the aggregate root, query the event flow information table to obtain the historical event version number corresponding to the last state of the aggregate root. The event flow information table includes the identifier of the aggregate root, the type of the aggregate root, and the latest version number of the aggregate root.

[0009] Based on the change command and the historical event version number, a new event object is generated. The new event object includes the identifier of the aggregate root, the type of the aggregate root, the new event version number, the event occurrence time, and the change content corresponding to the operation command.

[0010] The event object is serialized and stored in the event table according to the event occurrence time. The event table includes the identifier of the aggregate root, the type of the aggregate root, the event type, and the serialization result of the event object.

[0011] In one possible design, prior to the change command for obtaining the file content, the method further includes:

[0012] The command to open the file content is obtained, and the command includes the identifier of the aggregate root and the type of the aggregate root;

[0013] Based on the identifier and type of the aggregate root, query the event table to determine whether the event table stores at least one historical event object corresponding to the operated command;

[0014] If so, then replay processing is performed based on the at least one historical event object to obtain the final state of the aggregate root;

[0015] If not, then the initial state of the aggregate root is taken as the final state;

[0016] Correspondingly, after generating the new event object, the method further includes:

[0017] Based on the new event object, the final state is modified to obtain the new state of the aggregate root.

[0018] In one possible design, generating a new event object based on the change command and the historical event version number includes:

[0019] If the historical event version number exists, then the historical event version number is incremented to obtain a new event version number;

[0020] If the historical event version number does not exist, the initial version number will be used as the new event version number.

[0021] The new event object is generated based on the identifier of the aggregate root, the type of the aggregate root, the new event version number, the event occurrence time, and the change content corresponding to the operation command.

[0022] In one possible design, the step of serializing and storing the event object in the event table according to the event occurrence time includes:

[0023] Add the event object to the temporary event container;

[0024] Based on the event occurrence time, the event object in the temporary event container is serialized and stored in the event table, and the event object is deleted from the temporary event container;

[0025] The identifier of the aggregate root, the type of the aggregate root, and the new event version number are stored in the event flow information table.

[0026] In one possible design, after serializing the event object and storing it in the event table according to the event occurrence time, the method further includes:

[0027] According to the asynchronous snapshot strategy, an aggregate snapshot corresponding to the event object in the event table is generated and stored in the aggregate snapshot table; the aggregate snapshot table includes the identifier of the aggregate root, the type of the aggregate root, and the serialized data of the aggregate snapshot.

[0028] In one possible design, after serializing the event object and storing it in the event table according to the event occurrence time, the method further includes:

[0029] Listen to the database logs to obtain the event objects in the event table;

[0030] The event object is published through an event publisher so that different applications or services can change their state based on the event object and persist the corresponding materialized view.

[0031] Secondly, this application provides a data reading method based on content version, including:

[0032] Obtain a query instruction, which includes the identifier of the aggregate root, the type of the aggregate root, and the target version number to be queried;

[0033] The event stream information table is queried according to the query instruction to determine whether the target version number exists;

[0034] If so, the event table is queried according to the target version number to obtain the serialized event object corresponding to the target version number; wherein, the event table is generated by the method described in the first aspect above;

[0035] Based on the serialized event object, replay the version content that generated the target version number.

[0036] In one possible design, querying the event table based on the target version number to obtain the serialized event object corresponding to the target version number includes:

[0037] The aggregation snapshot table is searched based on the identifier and type of the aggregation root to determine whether the aggregation snapshot table stores the serialized data of the corresponding aggregation snapshot. The aggregation snapshot table includes the identifier of the aggregation root, the type of the aggregation root, and the serialized data of the aggregation snapshot.

[0038] If so, query the event table based on the target version number to obtain the target serialized event object corresponding to the target version number, excluding the serialized data of the aggregate snapshot;

[0039] Correspondingly, the step of replaying the version content that generates the target version number based on the serialized event object includes:

[0040] Based on the serialized data of the aggregated snapshot and the event object of the target serialization, the version content of the target version number is replayed to generate.

[0041] Thirdly, this application provides a content-version-based data storage device, comprising:

[0042] The acquisition module is used to acquire the modification commands for the file content. The modification commands include the identifier of the aggregate root, the type of the aggregate root, and the operation command.

[0043] The processing module is used to query the event flow information table according to the identifier and type of the aggregate root to obtain the historical event version number corresponding to the last state of the aggregate root. The event flow information table includes the identifier of the aggregate root, the type of the aggregate root, and the latest version number of the aggregate root.

[0044] The processing module is further configured to generate a new event object based on the change command and the historical event version number. The new event object includes the identifier of the aggregate root, the type of the aggregate root, the new event version number, the event occurrence time, and the change content corresponding to the operation command.

[0045] An execution module is used to serialize the event object and store it in an event table according to the event occurrence time. The event table includes the identifier of the aggregate root, the type of the aggregate root, the event type, and the serialization result of the event object.

[0046] In one possible design, the processing module is further specifically used for:

[0047] Before obtaining the change command for the file content, obtain the open command for the file content, wherein the open command includes the identifier of the aggregate root and the type of the aggregate root;

[0048] Based on the identifier and type of the aggregate root, query the event table to determine whether the event table stores at least one historical event object corresponding to the operated command;

[0049] If so, then replay processing is performed based on the at least one historical event object to obtain the final state of the aggregate root;

[0050] If not, then the initial state of the aggregate root is taken as the final state;

[0051] Correspondingly, after generating a new event object, the final state is modified based on the new event object to obtain a new state for the aggregate root.

[0052] In one possible design, the processing module is further specifically used for:

[0053] If the historical event version number exists, then the historical event version number is incremented to obtain a new event version number;

[0054] If the historical event version number does not exist, the initial version number will be used as the new event version number.

[0055] The new event object is generated based on the identifier of the aggregate root, the type of the aggregate root, the new event version number, the event occurrence time, and the change content corresponding to the operation command.

[0056] In one possible design, the processing module is further specifically used for:

[0057] Add the event object to the temporary event container;

[0058] Based on the event occurrence time, the event object in the temporary event container is serialized and stored in the event table, and the event object is deleted from the temporary event container;

[0059] The identifier of the aggregate root, the type of the aggregate root, and the new event version number are stored in the event flow information table.

[0060] In one possible design, the execution module is further specifically used for:

[0061] After serializing the event object into the event table according to the event occurrence time, an aggregate snapshot corresponding to the event object in the event table is generated according to the snapshot asynchronous strategy and stored in the aggregate snapshot table; the aggregate snapshot table includes the identifier of the aggregate root, the type of the aggregate root and the serialized data of the aggregate snapshot.

[0062] In one possible design, the execution module is further specifically used for:

[0063] After serializing the event object into the event table according to the event occurrence time, the database log is monitored to obtain the event object in the event table.

[0064] The event object is published through an event publisher so that different applications or services can change their state based on the event object and persist the corresponding materialized view.

[0065] Fourthly, this application provides a data reading device based on content version, comprising:

[0066] Obtain a query instruction, which includes the identifier of the aggregate root, the type of the aggregate root, and the target version number to be queried;

[0067] The event stream information table is queried according to the query instruction to determine whether the target version number exists;

[0068] If so, the event table is queried according to the target version number to obtain the serialized event object corresponding to the target version number; wherein, the event table is generated by the method described in the first aspect above;

[0069] Based on the serialized event object, replay the version content that generated the target version number.

[0070] In one possible design, the processing module is further specifically used for:

[0071] The aggregation snapshot table is searched based on the identifier and type of the aggregation root to determine whether the aggregation snapshot table stores the serialized data of the corresponding aggregation snapshot. The aggregation snapshot table includes the identifier of the aggregation root, the type of the aggregation root, and the serialized data of the aggregation snapshot.

[0072] If so, query the event table based on the target version number to obtain the target serialized event object corresponding to the target version number, excluding the serialized data of the aggregate snapshot;

[0073] Correspondingly, the execution module is also specifically used to: replay the version content of the target version number based on the serialized data of the aggregated snapshot and the event object of the target serialization.

[0074] Fifthly, this application provides a content-version-based data storage and retrieval device, comprising: a processor, and a memory communicatively connected to the processor;

[0075] The memory stores computer-executed instructions;

[0076] The processor executes computer execution instructions stored in the memory, causing the processor to perform a content-based data storage and retrieval method as described in any of the possible implementations of any of the above aspects.

[0077] Sixthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement a content-version-based data storage and retrieval method as described in any possible implementation of any of the above aspects.

[0078] This application provides a content-version-based data storage and retrieval method, device, and storage medium. The method obtains a file content modification command, which includes an identifier of the aggregate root, the type of the aggregate root, and an operation command. Based on the identifier and type of the aggregate root, it queries an event stream information table to obtain the historical event version number corresponding to the last state of the aggregate root, thus obtaining the version number of the last historical state of the modified file content. Based on the modification command and the historical event version number, a new event object is generated. The new event object includes the identifier of the aggregate root, the type of the aggregate root, the new event version number, the event occurrence time, and the modification content corresponding to the operation command. This generates the event object to be saved. The event object is serialized and stored in an event table according to the event occurrence time. This achieves file content storage by storing modification objects in the order of event occurrence. Through the recording and replay mechanism of file modification event objects, historical data can be easily traced back. Historical data can be obtained by simply resending the specified version of the event and applying the state change logic. Since all operation events are recorded, database operations can be effectively tracked and audited, thereby improving data security. Attached Figure Description

[0079] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0080] Figure 1 The flow of the content-version-based data storage method provided in the embodiments of this application Figure 1 .

[0081] Figure 2 The flow of the content-version-based data storage method provided in the embodiments of this application Figure 2 .

[0082] Figure 3 The flow of the content-version-based data reading method provided in the embodiments of this application Figure 3 .

[0083] Figure 4 This is a schematic diagram of the structure of a content-based data storage device provided in an embodiment of this application.

[0084] Figure 5 A schematic diagram of the structure of a content-version-based data reading device provided in an embodiment of this application.

[0085] Figure 6 This is a hardware diagram of a content-version-based data storage and retrieval electronic device provided in an embodiment of this application.

[0086] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0087] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0088] The current system requires version control of stored unstructured data for easy rollback and viewing of past revisions, as well as creating versions for important revisions. This data also needs auditing and multi-scenario querying. Existing version control solutions for unstructured data often rely on fully storing the complete content of each revision; operation records depend on full logs recording time, operator, and changes; and querying this unstructured data relies on non-relational databases to achieve the expected performance requirements, increasing the system's technical stack and introducing risks.

[0089] The content-version-based data storage and retrieval method provided in this application reduces redundant storage and database read / write pressure caused by the need to save all data for each change by saving change events. By recording change events, all operations are transformed into events, solving the problem of needing to record different content independently in the full log. Different materialized views are generated through event mapping for querying complex scenarios.

[0090] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0091] Figure 1 The flow of the content-version-based data storage method provided in the application embodiments Figure 1 ,like Figure 1 As shown, the method includes:

[0092] S101. Obtain a change command for the file content, wherein the change command includes the identifier of the aggregate root, the type of the aggregate root, and the operation command;

[0093] In this embodiment, the change command mentioned above can be a document content modification command. The change command includes a unique identifier for the document being modified. This unique identifier refers to the identifier of the aggregate root. The type of the aggregate root refers to the document type, which can be Word, PPT, Excel, etc. The operation command refers to the specific operation performed to modify the document, such as adding the character "a" to the end of the document.

[0094] In an aggregate, the aggregate root is a single, specific entity contained within the aggregate. The aggregate root is the only member within the aggregate that allows external objects to hold references to other aggregate roots. The aggregate root possesses a unique identifier for its associated entities, along with the associated entities and the behaviors associated with them, grouping closely related entities together and providing unified access to the outside world. An aggregate is a cluster of associated objects, which we treat as a unit to handle data changes.

[0095] When a user modifies the content of a file, a change command corresponding to the modified content will be generated for each modification action.

[0096] S102. Based on the identifier and type of the aggregate root, query the event flow information table to obtain the historical event version number corresponding to the last state of the aggregate root. The event flow information table includes the identifier of the aggregate root, the type of the aggregate root, and the latest version number of the aggregate root.

[0097] In this embodiment, the event flow information table is used to record the identifier of the aggregate root, the type of the aggregate root, and the latest version number of the aggregate root. By querying the latest version number of the aggregate root in the event flow information table, the historical event version number corresponding to the last state of the aggregate root can be obtained. This historical event version number of the last state can be used as the version number of the last time the document was saved before the user modified the file content.

[0098] S103. Generate a new event object based on the change command and the historical event version number. The new event object includes the identifier of the aggregate root, the type of the aggregate root, the new event version number, the event occurrence time, and the change content corresponding to the operation command.

[0099] In this embodiment, after obtaining the change command initiated by the user and the last saved version number of the document, the new document content changes initiated by the user can be recorded. This change is recorded in the form of an event object.

[0100] The content of this event object specifically includes the aggregate root identifier, the aggregate root type, the new event version number, the event occurrence time, and the changes corresponding to the operation command. Here, the aggregate root identifier refers to the unique identifier of the document whose content was changed by the user, the aggregate type refers to the document type, the new event version number refers to the version number that generated the new event, the event occurrence time is the time when the event was generated, and the changes corresponding to the operation command refer to those obtained through the operation command.

[0101] In a specific embodiment, if the historical event version number exists, the historical event version number is incremented to obtain a new event version number; if the historical event version number does not exist, the initialization version number is used as the new event version number; the new event object is generated based on the identifier of the aggregate root, the type of the aggregate root, the new event version number, the event occurrence time, and the change content corresponding to the operation command.

[0102] The version number of the new event is calculated by querying the event flow information table to obtain the version numbers of historical events. If a historical event version number corresponding to the aggregate root identifier and aggregate root type in the user-initiated change command is found, then this historical event version number is incremented by 1 and used as the version number of the new event. If no historical event version number corresponding to the change command is found, an initialization version number is defined as the version number of the new event. For example, 0.0.1 can be used as the initial version number. After determining the new event version number, all preparation work for the new event object is completed, and the new event object can then be generated.

[0103] S104. Serialize the event object and store it in the event table according to the event occurrence time. The event table includes the identifier of the aggregate root, the type of the aggregate root, the event type, and the serialization result of the event object.

[0104] In this embodiment, each change command for the file content corresponds to an event object. By re-executing the change operation on these event objects in chronological order, the state of the file content after any change operation can be obtained. Therefore, these event objects are recorded in an event table. The event table includes the unique identifier of the aggregate root, the type code of the aggregate root, the event type code, and the serialization result of the event object.

[0105] In a specific example, the event object is added to a temporary event container; according to the event occurrence time, the event object in the temporary event container is serialized and stored in the event table, and the event object is deleted from the temporary event container; the identifier of the aggregate root, the type of the aggregate root, and the new event version number are stored in the event flow information table.

[0106] In this embodiment, newly generated event objects are added to the container for temporary events. The purpose is to quickly restore any version of the file content during the change process through an event replay mechanism before saving the document after the user submits changes to the file content. Here, the event replay mechanism refers to replaying the events in chronological order to restore the state of any version of the file content.

[0107] In the implementation process, after the user confirms the version of the file content to be saved and clicks save, all event objects from the initial modification to the time of clicking save are retrieved from the temporary event container. These are then serialized sequentially into a storage format and stored in the event table. The serialization format can be JSON. For example, the event temporary container might contain three event objects, corresponding to version numbers 0.0.1, 0.0.2, and 0.0.3. These three event objects represent three change commands made by the user to the file content. The latest version number of the current file content is 0.0.3. The user deems the third change unnecessary and wants to save version 0.0.2. When the user cancels or switches to version 0.0.2, the event replay mechanism is triggered, presenting version 0.0.2 to the user. After the user confirms the content and clicks save, the 0.0.1 and 0.0.2 event objects in the temporary event container are serialized and submitted to the event table.

[0108] Before adding an event object to the temporary event container, it is necessary to validate the event object's validity and sort it. After storing the event object in the event table, the event object is then deleted from the temporary event container.

[0109] In the implementation process, while saving the event table, the event flow information table also needs to be updated. The event flow information table records the latest version number of the file content for which a change operation was performed, along with the identifier, type, and latest version number of the aggregate root in the event flow information table. By updating the event flow information table, the system provides the historical event version number of the last state when the user initiates a change operation on the file content again.

[0110] This invention provides a content version-based data storage method. It obtains a file content modification command, which includes an aggregate root identifier, an aggregate root type, and an operation command. Based on the aggregate root identifier and type, it queries an event flow information table to obtain the historical event version number corresponding to the last state of the aggregate root, thus obtaining the version number of the last historical state of the modified file content. Based on the modification command and the historical event version number, it generates a new event object, which includes the aggregate root identifier, aggregate root type, a new event version number, the event occurrence time, and the modified content corresponding to the operation command. This generates the event object to be saved. The event object is serialized and stored in an event table according to the event occurrence time. This achieves file content storage by storing modification objects in the order of event occurrence. Through the recording and replay mechanism of file modification event objects, historical data can be easily traced back. Historical data can be obtained by simply resending the specified version of the event and applying the state change logic. Since all operation events are recorded, database operations can be effectively tracked and audited, thereby improving data security.

[0111] Figure 2 The flow of the content-version-based data storage method provided in the application embodiments Figure 2 ,like Figure 2 As shown, in this embodiment... Figure 1 Based on the aforementioned embodiments, a content-version-based data storage method will be described in detail. This method includes:

[0112] S201. Obtain the open command for the file content, wherein the open command includes the identifier of the aggregate root and the type of the aggregate root.

[0113] In this embodiment, the file, its associated change events, and version number are combined to form a unified aggregate structure, and the aggregate root of the aggregate structure manages the entire lifecycle and business logic of the aggregate structure.

[0114] When a user initiates a command to modify file content, they must first open the document to check the latest version of its content. Once the file is opened, the corresponding aggregate root is determined. Therefore, all file content modification operations are performed based on the aggregate root.

[0115] S202. Based on the identifier and type of the aggregate root, query the event table to determine whether the event table stores at least one historical event object corresponding to the operated command. If yes, execute S203; otherwise, execute S204.

[0116] In the actual implementation, before modifying the file content, it is necessary to open the document and check the latest version status of the file content. This latest version status corresponds to the last status of the aggregate root of this file. By querying the event table, the historical event objects corresponding to this file are retrieved, preparing for the next step of event replay and obtaining the last status of the aggregate root.

[0117] S203. Perform replay processing based on the at least one historical event object to obtain the final state of the aggregate root;

[0118] S204. Take the initial state of the aggregate root as the final state;

[0119] In the actual implementation, if historical event objects exist, they are replayed in chronological order to restore the final state of the file content. If no historical event objects exist, it means the file has been newly opened, and the initial state is taken as its final state.

[0120] S205. Obtain a change command for the file content, wherein the change command includes the identifier of the aggregate root, the type of the aggregate root, and the operation command;

[0121] S206. Based on the identifier and type of the aggregate root, query the event flow information table to obtain the historical event version number corresponding to the last state of the aggregate root. The event flow information table includes the identifier of the aggregate root, the type of the aggregate root, and the latest version number of the aggregate root.

[0122] S207. Generate a new event object based on the change command and the historical event version number. The new event object includes the identifier of the aggregate root, the type of the aggregate root, the new event version number, the event occurrence time, and the change content corresponding to the operation command.

[0123] The implementation methods of steps S205 to S207 above can be found in [reference needed]. Figure 1 The embodiment shown is not described in detail here.

[0124] S208. Modify the final state according to the new event object to obtain the new state of the aggregate root.

[0125] In the implementation, a new event object is retrieved from the container where events are temporarily stored in the aggregate root. The corresponding event application method is then called based on the event object's type. This application method is typically predefined and modifies the aggregate root's state according to the event object's content. This modification process may involve multiple operations, such as updating aggregate root properties and calling aggregate root methods. After processing all temporarily stored event objects, the aggregate root's state is committed to persistent storage for later querying and use.

[0126] S209. According to the snapshot asynchronous strategy, generate an aggregate snapshot corresponding to the event object in the event table and store it in the aggregate snapshot table; the aggregate snapshot table includes the identifier of the aggregate root, the type of the aggregate root and the serialized data of the aggregate snapshot.

[0127] In this embodiment, since generating a snapshot takes some time, this process is handled asynchronously. This process can be implemented using message queues, background tasks, or other methods. The aggregate snapshot table includes the unique identifier of the aggregate root, its type encoding, and the serialized data of the snapshot.

[0128] In the specific implementation process, before generating a snapshot, the state of the aggregate root needs to be checked to determine if the conditions for generating a snapshot are met. This includes checking the aggregate root's version number, last modification time, etc. If the aggregate root meets the conditions for generating a snapshot, then a snapshot of the aggregate root is generated and saved to the aggregate snapshot table. By saving aggregate snapshots, the entire file content can be archived. Furthermore, when restoring file content through event objects, a version state based on the process aggregate root state rather than the initial aggregate root state can be provided for replaying events, improving the efficiency of file content recovery.

[0129] S210. Listen to the database logs to obtain the event objects in the event table.

[0130] In this embodiment, a database listener is set up to monitor all data change events. When data is modified in the database (mainly insert operations), these changes are captured by the listener. Since file content versions are stored in the database as event objects, and insert operations are the primary focus while update and delete operations are rarely involved, the event objects are naturally ordered by the event occurrence time and event version number. It can be assumed that no concurrent conflicts will occur when operating on the data. Only during update operations is it checked whether other transactions have modified the data in the meantime. If other transactions have modified the data, the update operation is abandoned; otherwise, the update operation is performed. This optimistic locking approach improves request performance.

[0131] S211. Publish the event object through the event publisher so that different applications or services can change their state according to the event object and persist the corresponding materialized view.

[0132] In this embodiment, once the listener receives database operation events, these events are encapsulated into a specific message format (e.g., JSON or XML) and then published through an event publisher. The event publisher may be a message queue or a service bus. Different applications or services can subscribe to these events and process them according to their respective needs and application logic. This processing is often called event mapping. Event mapping transforms published events into specific state change operations. A materialized view is a pre-computed and stored query result that can quickly provide complex query services. For complex query operations on a large dataset, the query results can be pre-computed and stored in a materialized view. When querying, the system can directly retrieve the results from the materialized view without needing to compute the query results in real time.

[0133] In the application logic, subscribers apply the received state change operations to the state of the underlying data, and then these changed data states are persisted to the materialized view.

[0134] By using event objects to shift the storage of full data for each revision to event storage, data redundancy is reduced. Historical events and snapshots are compressed and cached based on the principle of historical immutability. Optimistic locking is used for CRUD operations in scenarios involving querying historical and latest data based on event identifiers, resulting in improved system performance. Changing the data capture method decouples database operations from specific business logic. The primary responsibility of the database is data storage, while specific business logic (such as data processing and state changes) can be implemented in subscribers, making the system more flexible and scalable. Materialized views enable faster and more efficient complex query operations.

[0135] Figure 3 The flow of the content-version-based data reading method provided in the application embodiments Figure 3 ,like Figure 4 As shown, the method includes:

[0136] S301. Obtain a query instruction, wherein the query instruction includes the identifier of the aggregate root, the type of the aggregate root, and the target version number to be queried;

[0137] In this embodiment, the query instruction includes the identifier of the aggregate root, the aggregate root type, and the target version number to be queried.

[0138] Since the files are saved based on event objects, the content of the corresponding version of the file can be retrieved by obtaining the version number and the target file.

[0139] S302. Query the event flow information table according to the query instruction to determine whether the target version number exists. If yes, execute S303; otherwise, execute S304.

[0140] In the specific implementation, the event flow information table is queried based on the aggregate root identifier and aggregate root type in the query command to determine whether the event object corresponding to the queried version file exists. If the version number in the query command does not exist, the file is in an initial version state.

[0141] S303. Query the event table according to the target version number to obtain the serialized event object corresponding to the target version number;

[0142] In the specific implementation process, the target version number is retrieved based on the aggregate root identifier and aggregate root type in the query command, and the historical event object of the file corresponding to the aggregate root identifier from the initial version to the query target version is obtained by querying the event table.

[0143] In a specific example, when an aggregate snapshot table exists, it can be searched based on the identifier and type of the aggregate root to determine whether the aggregate snapshot table stores the serialized data of the corresponding aggregate snapshot. The aggregate snapshot table includes the identifier of the aggregate root, the type of the aggregate root, and the serialized data of the aggregate snapshot. If so, the event table is queried based on the target version number to obtain the target serialized event object corresponding to the target version number, excluding the serialized data of the aggregate snapshot.

[0144] In this embodiment, since the number of file change event objects increases with file size and the number of file changes, replaying the event objects from the initial version of the file to the target version to restore the aggregate root target version state takes a long time, which also affects system performance. The aggregate snapshot table records the state of the aggregate root during the file change process. By obtaining the state of the aggregate root during the file change process, the aggregate root state of the target version can be quickly restored. By querying the aggregate snapshot table, the maximum version number less than the target version number and the aggregate snapshot serialization data corresponding to this maximum version number are obtained. At this time, it is not necessary to obtain all event objects less than the target version number, but only the event objects between the maximum version number and the target version number need to be obtained.

[0145] S304. Based on the serialized event object, replay the version content generated for the target version number.

[0146] In the specific implementation process, after obtaining the serialized event objects, replaying these existing event objects will yield the aggregate root state of the target version number, which is the content of the target version file.

[0147] In a specific example, after obtaining the serialized data of the aggregated snapshot, the version content of the target version number can be replayed and generated based on the serialized data of the aggregated snapshot and the event object of the target serialization.

[0148] In the specific implementation process, when the queried file has archived aggregate snapshot information in the aggregate snapshot table, the serialized data of the aggregate snapshot and the event object between the aggregate snapshot version and the target version are obtained. The content of the target version file can be obtained by replaying the event.

[0149] By recording and replaying file change events, historical data can be easily traced back. Historical data can be obtained simply by resending the specified version of the event and applying the state change logic. The application of an aggregated snapshot strategy improves the efficiency of file recovery. Since all operation events are recorded, database operations can be effectively tracked and audited, thereby enhancing data security.

[0150] Figure 4 This is a schematic diagram of the structure of a content-version-based data storage device provided in an embodiment of this application. For example... Figure 5 As shown, the data storage device 40 includes: an acquisition module 401, a processing module 402, and an execution module 403.

[0151] The acquisition module 401 is used to acquire the change command of the file content. The change command includes the identifier of the aggregate root, the type of the aggregate root, and the operation command.

[0152] The processing module 402 is used to query the event flow information table according to the identifier and type of the aggregate root to obtain the historical event version number corresponding to the last state of the aggregate root. The event flow information table includes the identifier of the aggregate root, the type of the aggregate root, and the latest version number of the aggregate root.

[0153] The processing module 402 is further configured to generate a new event object based on the change command and the historical event version number. The new event object includes the identifier of the aggregate root, the type of the aggregate root, the new event version number, the event occurrence time, and the change content corresponding to the operation command.

[0154] The execution module 403 is used to serialize the event object and store it in an event table according to the event occurrence time. The event table includes the identifier of the aggregate root, the type of the aggregate root, the event type, and the serialization result of the event object.

[0155] In one possible design, the processing module 402 is further specifically used for:

[0156] Before obtaining the change command for the file content, obtain the open command for the file content, the open command including the identifier of the aggregate root and the type of the aggregate root;

[0157] Based on the identifier and type of the aggregate root, query the event table to determine whether the event table stores at least one historical event object corresponding to the operated command;

[0158] If so, then replay processing is performed based on the at least one historical event object to obtain the final state of the aggregate root;

[0159] If not, then the initial state of the aggregate root is taken as the final state.

[0160] Correspondingly, after the new event object is generated, the final state is modified based on the new event object to obtain the new state of the aggregate root.

[0161] In one possible design, the processing module 402 is further specifically used for:

[0162] When generating a new event object based on the change command and the historical event version number, if the historical event version number exists, the historical event version number is incremented to obtain a new event version number.

[0163] If the historical event version number does not exist, the initial version number will be used as the new event version number.

[0164] The new event object is generated based on the identifier of the aggregate root, the type of the aggregate root, the new event version number, the event occurrence time, and the change content corresponding to the operation command.

[0165] In one possible design, the processing module 402 is further specifically used for:

[0166] When the event object is serialized and stored in the event table according to the event occurrence time, the event object is added to the temporary event container.

[0167] Based on the event occurrence time, the event object in the temporary event container is serialized and stored in the event table, and the event object is deleted from the temporary event container;

[0168] The identifier of the aggregate root, the type of the aggregate root, and the new event version number are stored in the event flow information table.

[0169] In one possible design, the execution module 403 is further specifically used for:

[0170] After serializing the event object into the event table according to the event occurrence time, an aggregate snapshot corresponding to the event object in the event table is generated according to the snapshot asynchronous strategy and stored in the aggregate snapshot table; the aggregate snapshot table includes the identifier of the aggregate root, the type of the aggregate root and the serialized data of the aggregate snapshot.

[0171] In one possible design, the execution module 403 is further specifically used to: serialize the event object into an event table according to the event occurrence time, and then listen to the database log to obtain the event object in the event table;

[0172] The event object is published through an event publisher so that different applications or services can change their state based on the event object and persist the corresponding materialized view.

[0173] Figure 5 This is a schematic diagram of the structure of a content-version-based data reading device provided in an embodiment of this application. Figure 6 As shown, the data reading device 50 includes: an acquisition module 501, a processing module 502, and an execution module 503.

[0174] The acquisition module 501 is used to acquire a query instruction, which includes the identifier of the aggregate root, the type of the aggregate root, and the target version number to be queried.

[0175] The processing module 502 is used to query the event stream information table according to the query instruction to determine whether the target version number exists.

[0176] The processing module 502 is further configured to query the event table based on the target version number to obtain the serialized event object corresponding to the target version number;

[0177] The execution module 503 is used to replay the version content of the target version number based on the serialized event object.

[0178] In one possible design, the processing module 502 is further specifically used for:

[0179] When querying the event table based on the target version number to obtain the serialized event object corresponding to the target version number, the aggregation snapshot table is searched based on the identifier of the aggregation root and the type of the aggregation root to determine whether the aggregation snapshot table stores the serialized data of the corresponding aggregation snapshot. The aggregation snapshot table includes the identifier of the aggregation root, the type of the aggregation root, and the serialized data of the aggregation snapshot.

[0180] If so, the event table is queried based on the target version number to obtain the target serialized event object corresponding to the target version number, excluding the serialized data of the aggregated snapshot.

[0181] The corresponding execution module 503 is further used for:

[0182] Based on the serialized data of the aggregated snapshot and the event object of the target serialization, the version content of the target version number is replayed to generate.

[0183] Figure 6 This is a hardware diagram of a content-version-based data storage and retrieval device provided in an embodiment of this application. For example... Figure 6 As shown, the content-version-based data storage and retrieval device 60 provided in this embodiment includes at least one processor 601 and a memory 602. The device 60 also includes a communication component 603. The processor 601, memory 602, and communication component 603 are connected via a bus 604.

[0184] In a specific implementation, at least one processor 601 executes computer execution instructions stored in the memory 602, causing at least one processor 601 to execute the above-described storage and retrieval methods for content-based data storage and retrieval devices.

[0185] The specific implementation process of processor 601 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0186] In the above ​ In the illustrated embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0187] The memory may include high-speed RAM, and may also include non-volatile storage (NVM), such as at least one disk storage.

[0188] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0189] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described content-version-based data storage and retrieval device method.

[0190] The aforementioned computer-readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0191] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an application-specific integrated circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in device 60.

[0192] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0193] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0194] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0195] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or in the form of software program modules.

[0196] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as these combinations of technical features do not contradict each other, they should be considered within the scope of this specification.

[0197] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0198] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A content-version-based data storage method, characterized in that, include: A command to obtain changes to file content, wherein the change command includes an identifier of the aggregate root, the type of the aggregate root, and an operation command; wherein the type of the aggregate root refers to the document type, and the operation command refers to the specific operation to modify the document; Based on the identifier and type of the aggregate root, query the event flow information table to obtain the historical event version number corresponding to the last state of the aggregate root. The event flow information table includes the identifier of the aggregate root, the type of the aggregate root, and the latest version number of the aggregate root. Based on the change command and the historical event version number, a new event object is generated. The new event object includes the identifier of the aggregate root, the type of the aggregate root, the new event version number, the event occurrence time, and the change content corresponding to the operation command. The event object is serialized and stored in the event table according to the event occurrence time. The event table includes the identifier of the aggregate root, the type of the aggregate root, the event type, and the serialization result of the event object. The step of serializing and storing the event object in the event table according to the event occurrence time includes: Add the event object to the temporary event container; Based on the event occurrence time, the event object in the temporary event container is serialized and stored in the event table, and the event object is deleted from the temporary event container; The identifier of the aggregate root, the type of the aggregate root, and the new event version number are stored in the event flow information table.

2. The method according to claim 1, characterized in that, Before the command to obtain the file content, the method further includes: The command to open the file content is obtained, and the command includes the identifier of the aggregate root and the type of the aggregate root; Based on the identifier and type of the aggregate root, query the event table to determine whether the event table stores at least one historical event object corresponding to the operated command; If so, then replay processing is performed based on the at least one historical event object to obtain the final state of the aggregate root; If not, then the initial state of the aggregate root is taken as the final state; Correspondingly, after generating the new event object, the method further includes: Based on the new event object, the final state is modified to obtain the new state of the aggregate root.

3. The method according to claim 1, characterized in that, The step of generating a new event object based on the change command and the historical event version number includes: If the historical event version number exists, then the historical event version number is incremented to obtain a new event version number; If the historical event version number does not exist, the initial version number will be used as the new event version number. The new event object is generated based on the identifier of the aggregate root, the type of the aggregate root, the new event version number, the event occurrence time, and the change content corresponding to the operation command.

4. The method according to claim 1, characterized in that, After serializing the event object and storing it in the event table according to the event occurrence time, the method further includes: According to the asynchronous snapshot strategy, an aggregate snapshot corresponding to the event object in the event table is generated and stored in the aggregate snapshot table; the aggregate snapshot table includes the identifier of the aggregate root, the type of the aggregate root, and the serialized data of the aggregate snapshot.

5. The method according to claim 1, characterized in that, After serializing the event object and storing it in the event table according to the event occurrence time, the method further includes: Listen to the database logs to obtain the event objects in the event table; The event object is published through an event publisher so that different applications or services can change their state based on the event object and persist the corresponding materialized view.

6. A data reading method based on content version, characterized in that, include: Obtain a query instruction, which includes the identifier of the aggregate root, the type of the aggregate root, and the target version number to be queried; The event stream information table is queried according to the query instruction to determine whether the target version number exists; If so, the event table is queried according to the target version number to obtain the serialized event object corresponding to the target version number; wherein, the event table is generated by the method described in any one of claims 1 to 5; Based on the serialized event object, replay the version content that generated the target version number.

7. The method according to claim 6, characterized in that, The step of querying the event table based on the target version number to obtain the serialized event object corresponding to the target version number includes: The aggregation snapshot table is searched based on the identifier and type of the aggregation root to determine whether the aggregation snapshot table stores the serialized data of the corresponding aggregation snapshot. The aggregation snapshot table includes the identifier of the aggregation root, the type of the aggregation root, and the serialized data of the aggregation snapshot. If so, query the event table based on the target version number to obtain the target serialized event object corresponding to the target version number, excluding the serialized data of the aggregate snapshot; Correspondingly, the step of replaying the version content that generates the target version number based on the serialized event object includes: Based on the serialized data of the aggregated snapshot and the event object of the target serialization, the version content of the target version number is replayed to generate.

8. A content-version-based data storage device, characterized in that, include: The acquisition module is used to acquire the modification command of the file content. The modification command includes the identifier of the aggregate root, the type of the aggregate root, and the operation command; wherein, the type of the aggregate root refers to the document type, and the operation command refers to the specific operation to modify the document. The processing module is used to query the event flow information table according to the identifier and type of the aggregate root to obtain the historical event version number corresponding to the last state of the aggregate root. The event flow information table includes the identifier of the aggregate root, the type of the aggregate root, and the latest version number of the aggregate root. The processing module is further configured to generate a new event object based on the change command and the historical event version number. The new event object includes the identifier of the aggregate root, the type of the aggregate root, the new event version number, the event occurrence time, and the change content corresponding to the operation command. An execution module is used to serialize and store the event object into an event table according to the event occurrence time. The event table includes the identifier of the aggregate root, the type of the aggregate root, the event type, and the serialization result of the event object. The execution module is specifically used to add the event object to the temporary event container; Based on the event occurrence time, the event object in the temporary event container is serialized and stored in the event table, and the event object is deleted from the temporary event container; The identifier of the aggregate root, the type of the aggregate root, and the new event version number are stored in the event flow information table.

9. A data reading device based on content version, characterized in that, include: The acquisition module is used to acquire query instructions, which include the identifier of the aggregate root, the type of the aggregate root, and the target version number to be queried; The processing module is used to query the event stream information table according to the query instruction to determine whether the target version number exists; The processing module is further configured to query the event table based on the target version number to obtain the serialized event object corresponding to the target version number; wherein the event table is generated by the method described in any one of claims 1 to 5; The execution module is used to replay the version content that generated the target version number based on the serialized event object.

10. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 7.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 7.

Images