CN111752909B - Method, system and device for operating multi-version file - Google Patents
Method, system and device for operating multi-version file Download PDFInfo
- Publication number
- CN111752909B CN111752909B CN202010528171.7A CN202010528171A CN111752909B CN 111752909 B CN111752909 B CN 111752909B CN 202010528171 A CN202010528171 A CN 202010528171A CN 111752909 B CN111752909 B CN 111752909B
- Authority
- CN
- China
- Prior art keywords
- target object
- version
- header
- operation log
- logic
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/18—File system types
- G06F16/1873—Versioning file systems, temporal file systems, e.g. file system supporting different historic versions of files
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Abstract
The invention discloses an operation method, a system and a device for multi-version files, wherein the method comprises the following steps: configuring an object logic header for a multi-version file, wherein the object logic header is used for recording metadata of the multi-version file; wherein, different multi-version files have different object logic heads; when the operation is carried out on a target object in the multi-version file, generating an operation log of the target object in the object logic head, and after the target object finishes the operation, executing a finishing action matched with the operation log on an instance of the target object in the object logic head; and updating the version information of the multi-version file in the object logic header, wherein the version information is at least used for representing the number of the latest version and pointing to the object of the latest version. According to the technical scheme, the operation efficiency of the multi-version file can be improved.
Description
Technical Field
The present invention relates to the field of internet technologies, and in particular, to a method, a system, and an apparatus for operating a multi-version file.
Background
In the current distributed object storage system, in order to avoid the deletion and modification of files, the system generally has a file version control function. When a storage space (bucket) version control function is started, historical operations on the file can be saved in the form of historical versions, so that a multi-version file is formed.
At present, when the operation is performed on the multi-version file, the operation log can be written in the socket index, when the operation is completed on the multi-version file, the operation log can be read from the socket index, the head object of the multi-version file can be modified according to the operation log, and when the modification is successful, the corresponding operation log can be deleted from the socket index.
In practical applications, there may be multiple multi-version files at the same time that need to be uploaded or deleted, and each multi-version file needs to be accessed multiple times during the operation. Meanwhile, the operations are usually mutually exclusive, so that when the bucket index is accessed, the operations of different multi-version files are actually serial operations, and the operation efficiency of the multi-version files can be greatly affected.
Disclosure of Invention
The invention aims to provide a method, a system and a device for operating a multi-version file, which can improve the operating efficiency of the multi-version file.
To achieve the above object, in one aspect, the present application provides a method for operating a multi-version file, the method including: configuring an object logic header for a multi-version file, wherein the object logic header is used for recording metadata of the multi-version file; wherein, different multi-version files have different object logic heads; when the operation is carried out on a target object in the multi-version file, generating an operation log of the target object in the object logic head, and after the target object finishes the operation, executing a finishing action matched with the operation log on an instance of the target object in the object logic head; and updating the version information of the multi-version file in the object logic header, wherein the version information is at least used for representing the number of the latest version and pointing to the object of the latest version.
To achieve the above object, another aspect of the present application further provides an operating system for a multi-version file, where the system includes: the object logic header configuration unit is used for configuring an object logic header for the multi-version file, wherein the object logic header is used for recording metadata of the multi-version file; wherein, different multi-version files have different object logic heads; an object operation unit, configured to generate an operation log of a target object in the object logic header when the object logic header performs an operation on the target object in the multi-version file, and perform a completion action matched with the operation log on an instance of the target object in the object logic header after the target object completes the operation; and the version information updating unit is used for updating the version information of the multi-version file in the object logic header, wherein the version information is at least used for representing the number of the latest version and pointing to the object of the latest version.
In order to achieve the above object, another aspect of the present application further provides an operating device for a multi-version file, where the device includes a memory and a processor, and the memory is configured to store a computer program, and when the computer program is executed by the processor, implement the above method for operating a multi-version file.
In view of the foregoing, according to the technical solutions provided in one or more embodiments of the present application, different object logic headers may be configured for different multi-version files, where the object logic header may record metadata of the corresponding multi-version file. Thus, when different multi-version files need to be subjected to file operation, only the own object logic header is required to be accessed, and multiple accesses to the same socket index are not required to be initiated. Specifically, when a target object is operated on a multi-version file, a corresponding operation log may be generated in an object logic header, and after the operation of the target object is completed, a matched completion action may be performed on an instance of the target object in the object logic header. Subsequently, after the current operation of the multi-version file is completed, the version information of the multi-version file may be updated in the object logic header. Therefore, when the operation of the target object occurs, the operation flow of other multi-version files does not need to be waited, so that the operation efficiency of the multi-version files can be greatly improved.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings that are needed in the description of the embodiments will be briefly described below, it being obvious that the drawings in the following description are only some embodiments of the present invention, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.
FIG. 1 is a schematic diagram illustrating steps of a method for operating a multi-version file according to an embodiment of the present invention;
FIG. 2 is a functional block diagram of an operating system for a multi-version file according to an embodiment of the present invention;
fig. 3 is a schematic structural diagram of an operating device for multi-version files according to an embodiment of the present invention.
Detailed Description
For the purpose of making the objects, technical solutions and advantages of the present application more apparent, the technical solutions of the present application will be clearly and completely described below with reference to the specific embodiments of the present application and the corresponding drawings. It will be apparent that the described embodiments are only some, but not all, of the embodiments of the present application. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are within the scope of the present disclosure.
The method for operating the multi-version file can be improved aiming at the existing distributed object storage system, so that the problem of low operating efficiency of the multi-version file is solved.
Referring to fig. 1, the method for operating a multi-version file according to one embodiment of the present application may include the following steps.
S1: configuring an object logic header for a multi-version file, wherein the object logic header is used for recording metadata of the multi-version file; wherein different multi-version files have different object logic headers.
In this embodiment, each multi-version file may be configured with its own object logical header (object logic head, olh) in which metadata of the multi-version file may be recorded. In this way, different multi-version files can have their own object logic header managing metadata without requiring metadata management through a unified interface.
In one embodiment, three data types may be included in the configured object logic header, where a first type of data may be used to store key value pairs for the object, a second type of data may be used to store extended attributes for the object, and a third type of data may be used to store data for the object. For example, the three data types may be an omap type, an attr type, and a data type, respectively. Wherein, the omap type can store key value pairs of the object in a key value to database (RocksDB, mangoDB, etc.), the attr type can store extended attributes of the object, and the data type can store data of the object.
In one embodiment, the first type of data may also include a first sub-data type that may be used to store the number of the latest version and point to the latest version of the object, and a second sub-data type that may be used to store the oplog and version instance of the object. In addition, the extended attribute of the second class data storage may include the number of the latest version, the object of the latest version, and whether the object of the latest version is a deletion instance, so that the second class data may be used to store the number of the latest version, the object pointing to the latest version, and whether the object of the latest version is a deletion instance.
In one specific application example, two sub-types of omap types and the extended attributes stored by attr type may be as shown in tables 1 and 2:
table 1 two sub-data types corresponding to omap types
Table 2 extended attribute description of attr type store
| Extending attribute names | Attribute value description |
| user.olh.latest_version | Numbering of the latest version |
| User.olh.target | Object of latest version |
| user.olh.is_removed | Whether the object of the latest version is a deleted instance |
Of course, in practical application, the object logic header of the multi-version file may further include fewer or more data types, and the functions of each data type may be changed according to the actual scenario. However, those skilled in the art should understand that reasonable changes to the form of the object logic header are also included in the protection scope of the present application.
S3: when the operation is carried out on the target object in the multi-version file, an operation log of the target object is generated in the object logic head, and after the operation is completed on the target object, a completion action matched with the operation log is executed on the instance of the target object in the object logic head.
In this embodiment, after the object logic header is configured for the multi-version file, a plurality of atomic operations (atomic operations) may be further designed to ensure that the object logic header can be operated efficiently. Atomic operations refer to operations that are not interrupted by thread scheduling mechanisms. These atomic operations may perform operations such as deletion, uploading, etc. of objects for multi-version files, and may write operation logs to or from object logic headers, and may perform operations such as version instances of objects in object logic headers.
In one specific application example, the partial atomic operation of the design may be as shown in table 3:
TABLE 3 partial atomic operation description
In the present embodiment, after atomic operations are designed for a multi-version file, processes such as uploading and deleting the file can be performed by using these atomic operations. Specifically, if a target object needs to be added to the current multi-version file, an operation log of the target object may be generated in an object logical header of the multi-version file. Then, when the target object is stored in the multi-version file of the distributed object storage system, it is indicated that the upload operation has been completed on the target object. At this time, the object logic header of the multi-version file needs to be changed correspondingly. Specifically, the operation log of the target object generated before may include information such as the version number of the current operation, whether the current operation is marked with a delete tag, and the like, and through the combination of these information, the operation log may be converted into the version instance of the corresponding object. After the version instance of the object is converted, the version instance of the object can be written into the object logic header, thereby completing the modification of the metadata.
In another application example, if the target object needs to be deleted in the multi-version file, a corresponding operation log is also generated in the object logic header. Subsequently, after deleting the target object from the distributed object storage system, the instance of the target object can be also deleted from the object logic header according to the generated operation log, so that the metadata can be changed.
As can be seen from the above, the completion actions performed in the object logic header are different depending on the type of operation. If the operation log characterizes adding the target object in the multi-version file, the execution of the completion action may be to generate an instance of the target object according to the operation log, and store the instance of the target object in the object logic header. Whereas if the oplog characterizes the deletion of the target object in a multi-version file, the completion action performed may be the deletion of an instance of the target object in the object's logical header. In this way, after the target object completes the operation, a completion action matching the operation log may be performed on the instance of the target object in the object logic header.
In one embodiment, if the oplog characterizes that the target object is deleted in the multi-version file, after the instance of the target object is deleted in the object logic header, if no other instance exists in the object logic header, all the objects in the current multi-version file in the specification are already deleted, at this time, the object logic header of the multi-version file can be deleted together, so that metadata can be kept consistent with the data of the actual multi-version file.
In practical applications, multiple concurrent operations may exist for the same multi-version file at the same time. Taking two concurrent operations as an example, assume that a first target object and a second target object are concurrently operated on a multi-version file, and the second target object completes the operation after the first target object. In an application example, the two concurrent operations are both operations of adding the target objects, and then the concurrent adding process of the two target objects may be as shown in table 4:
TABLE 4 schematic table of concurrent addition of two target objects
After the above concurrent addition, objects VA and VB are newly added in the multi-version file.
In another application example, assuming that two concurrent operations are adding a first target object and deleting a second target object, the procedure of the two concurrent operations may be as shown in table 5:
TABLE 5 concurrent operation schematic table of adding and deleting objects
From the above, through the above two concurrent operations, VA is deleted from the original objects VA and VB in the multi-version file, and meanwhile, the object VC is newly added, where the multi-version file at least includes the objects VB and VC, and the object VA, the object VB, the object VC, the object VE, and the object VF used for illustration in other paragraphs herein and herein all represent different versions of the same multi-version file.
In another application example, assuming that two concurrent operations are both delete operations, the procedure of the two concurrent operations may be as shown in table 6:
TABLE 6 operation schematic table for concurrently deleting two objects
From the above, after deleting the target object, if there is no version instance of other object in the object logic header, the object logic header may be deleted together. In practical application, when at least one of the operation types of the first target object and the second target object is the deleted object type, after deleting the version instance of the object in the object logic header, if no other instance exists in the object logic header, the object logic header may be deleted together.
S5: and updating the version information of the multi-version file in the object logic header, wherein the version information is at least used for representing the number of the latest version and pointing to the object of the latest version.
In this embodiment, after the completion of the execution of the instance of the target object in the object logic header, the version information of the multi-version file may be updated. In general, the version information may include the number of the latest version, and the version information may mark the object to which the latest version points. The number of the latest version can be gradually increased according to the operation times of the objects in the multi-version file. For example, the original version number of the multi-version file is 1, and then after sequentially adding the objects VA and VB to the multi-version file, the number of the latest version may be 3. Then, after deleting the object VB from the multi-version file again and adding the object VC, the number of the latest version may be 5. It can be seen that if the first target object and the second target object are concurrently operated for the multi-version file, the operation for the first target object and the operation for the second target object may increment the version numbers one by one based on the original version numbers to generate the numbers of the latest version. The object to which the latest version points may be determined according to the type of operation of the object. Specifically, the latest version of the object may be determined in the multi-version file according to the operation type of the first target object and the operation type of the second target object, where the latest version of the object may be the object pointed to by the version information. For example, if the operation types of the first target object and the second target object are both added object types, the second target object may be determined to be the object of the latest version since the second target object is added last. For example, in table 4, the latest version of the object may be VB. If one of the operation types of the first target object and the second target object is an added object type and the other is a deleted object type, the target object corresponding to the added object type may be determined to be the object of the latest version. For example, in table 5, the most recent version of the object may be VC. If the operation types of the first target object and the second target object are both the deleted object types, the latest added object can be queried in the rest objects of the multi-version file, and the latest added object is determined to be the latest version object. For example, in Table 6, if after deleting VB, VE and VF remain in the multi-version file, and VF is added after VE, then the object of the latest version may be VF.
In this embodiment, after the number of the latest version is generated and the object to which the latest version points is determined, the information may be recorded in the version information of the updated multi-version file, thereby completing the update process of the version information.
Further, after the operation of the target object is completed, the extended attributes in the object logical header may be updated. For example, after completing the operation of the target object, the latest version is numbered 5, the object pointed to by the latest version is VC, and the object pointed to by the latest version does not have a delete marker, then attr data type may be as shown in table 7:
table 7 schematic table of attr data types
In one embodiment, considering that the distributed object storage system is generally used for managing objects through a socket (storage area), after the distributed object storage system is improved, metadata of the multi-version file may be stored in a corresponding object logic header, but at the same time, metadata of the multi-version file also needs to be recorded in the socket. Since the same metadata needs to be stored in two different areas, there may be a problem in that two pieces of metadata are not identical. In view of this, in the present embodiment, an automatic repair function of metadata needs to be configured.
Specifically, the operation procedure of uploading or deleting the object may be as shown in table 8:
TABLE 8 object operation Process schematic Table
As can be seen from the above, after the operation log of the target object is generated in the object logic header, the operation log in the object logic header may be set to a pending state. Then, after generating the metadata oplog of the target object in the storage area of the multi-version file, the metadata oplog may also be set to a pending state. After the target object completes an operation in the distributed object storage system, the corresponding operation log in the object logical header is deleted and the state of the metadata operation log in the socket is set to the completion state.
In practice, one or more of the steps in table 8 may fail. For example:
1) olh _preparation_op success
2) Pocket_preparation_op success
3) Uploading an object: success of
4) olh _complete_op failure
5) Socket_complete_op failure
In this way, the object in the distributed object storage system has been successfully uploaded, but the metadata in the object logical header and the socket fails to be processed, and at this time, the metadata needs to be repaired.
In one embodiment, the metadata operation log of the target object may be detected in the socket, and according to the current state of the metadata operation log, it is determined whether the metadata of the target object in the storage area and the object logical header needs to be repaired. Specifically, if the current state of the metadata operation log is a pending state, it may be determined in the system whether the target object has completed the operation in the multi-version file, and if the operation has completed, it is determined that the metadata of the target object in the socket and the object logical header needs to be repaired. If the current state of the metadata operation log is the completion state, the metadata is already processed, and it can be determined that the metadata of the target object in the socket and the object logic header does not need to be repaired.
For example, when olh _complete_op and socket_complete_op fail, there is a metadata oplog of the object in the socket, and when the socket is processing the metadata oplog, the storage state of the object can be queried in the system. Indicating that the object has been successfully uploaded in the system, the bucket may proactively repair the metadata of the object in the bucket and the object logical header. Specifically, in the object logic header, a corresponding completion action may be performed according to the operation log in the object logic header, and the operation log may be deleted. In the socket, the metadata operation log may be set to a completion state, thereby completing the repair process of the metadata.
From the above, in the embodiment of the present application, active repair may be performed when metadata is inconsistent, so as to improve availability and correctness of the distributed object storage system.
Referring to fig. 2, the present application further provides an operating system for a multi-version file, where the system includes:
the object logic header configuration unit is used for configuring an object logic header for the multi-version file, wherein the object logic header is used for recording metadata of the multi-version file; wherein, different multi-version files have different object logic heads;
an object operation unit, configured to generate an operation log of a target object in the object logic header when the object logic header performs an operation on the target object in the multi-version file, and perform a completion action matched with the operation log on an instance of the target object in the object logic header after the target object completes the operation;
and the version information updating unit is used for updating the version information of the multi-version file in the object logic header, wherein the version information is at least used for representing the number of the latest version and pointing to the object of the latest version.
In one embodiment, the object operation unit includes:
the object adding module is used for adding the target object in the multi-version file if the operation log represents the operation log, generating an instance of the target object according to the operation log, and storing the instance of the target object into the object logic head;
and the object deleting module is used for deleting the target object in the multi-version file if the operation log characterizes that the target object is deleted, and deleting the instance of the target object in the object logic header.
In one embodiment, the version information updating unit includes:
the number updating module is used for increasing the version numbers one by one on the basis of the original version numbers if a first target object and a second target object are operated concurrently for the multi-version file and the second target object completes operation after the first target object, and the operation of the first target object and the operation of the second target object are operated for generating the number of the latest version;
and the information recording module is used for determining the object of the latest version in the multi-version file according to the operation type of the first target object and the operation type of the second target object, and recording the generated number of the latest version and the determined object of the latest version in the updated version information of the multi-version file.
In one embodiment, the system further comprises:
a state setting unit configured to set the operation log in the object logic header to a pending state; generating a metadata operation log of the target object in a storage area of the multi-version file, and setting the metadata operation log to be in a pending state;
and a log operation unit configured to delete the operation log in the object logic header and set a state of the metadata operation log in the storage area to a completion state after the target object completes an operation.
In one embodiment, the system further comprises:
and the metadata restoration unit is used for detecting the metadata operation log of the target object in the storage area and judging whether the metadata of the target object in the storage area and the object logic head need to be restored according to the current state of the metadata operation log.
Referring to fig. 3, the present application further provides an operating device for a multi-version file, where the device includes a memory and a processor, and the memory is configured to store a computer program, and when the computer program is executed by the processor, implement the above-mentioned operating method for the multi-version file.
In view of the foregoing, according to the technical solutions provided in one or more embodiments of the present application, different object logic headers may be configured for different multi-version files, where the object logic header may record metadata of the corresponding multi-version file. Thus, when different multi-version files need to be subjected to file operation, only the own object logic header is required to be accessed, and multiple accesses to the same socket index are not required to be initiated. Specifically, when a target object is operated on a multi-version file, a corresponding operation log may be generated in an object logic header, and after the operation of the target object is completed, a matched completion action may be performed on an instance of the target object in the object logic header. Subsequently, after the current operation of the multi-version file is completed, the version information of the multi-version file may be updated in the object logic header, so as to point to the latest version object of the multi-version file. Therefore, when the operation of the target object occurs, the operation flow of other multi-version files does not need to be waited, so that the operation efficiency of the multi-version files can be greatly improved. In addition, when the socket processes the metadata operation log, the metadata in the socket and the object logic head can be actively repaired according to the state of the metadata operation log and the actual operation result of the object in the system, so that the availability and the correctness of the distributed object storage system are improved.
In this specification, each embodiment is described in a progressive manner, and identical and similar parts of each embodiment are referred to each other, and each embodiment is mainly described as different from other embodiments. In particular, reference should be made to the description of embodiments of the method described above for both system and apparatus embodiments.
It will be appreciated by those skilled in the art that embodiments of the present invention may be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.
The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
In one typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include volatile memory in a computer-readable medium, random Access Memory (RAM) and/or nonvolatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.
Computer readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of storage media for a computer include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by a computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signals and carrier waves.
It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article or apparatus that comprises the element.
The foregoing is merely an embodiment of the present application and is not intended to limit the present application. Various modifications and changes may be made to the present application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc. which are within the spirit and principles of the present application are intended to be included within the scope of the claims of the present application.
Claims (19)
1. A method of operating a multi-version file, the method comprising:
configuring an object logic header for a multi-version file, wherein the object logic header is used for recording metadata of the multi-version file; wherein, different multi-version files have different object logic heads;
when the operation is carried out on a target object in the multi-version file, generating an operation log of the target object in the object logic head, and after the target object finishes the operation, executing a finishing action matched with the operation log on an instance of the target object in the object logic head;
and updating the version information of the multi-version file in the object logic header, wherein the version information is at least used for representing the number of the latest version and pointing to the object of the latest version.
2. The method of claim 1, wherein the object logic header includes three types of data, wherein the first type of data is used to store key value pairs of the object, the second type of data is used to store extended attributes of the object, and the third type of data is used to store data of the object.
3. The method of claim 2, wherein the first type of data comprises a first sub-data type for storing a number of a latest version and pointing to a latest version of an object, and a second sub-data type for storing an operation log and version instances of the object.
4. The method of claim 2, wherein the second class of data is used to store a number of a latest version of the object, an object that points to the latest version, and whether the object that marks the latest version is a deleted instance.
5. The method of claim 1, wherein performing a completion action in the object logic header on the instance of the target object that matches the oplog comprises:
if the operation log representation adds the target object in the multi-version file, generating an instance of the target object according to the operation log, and storing the instance of the target object into the object logic header;
and if the operation log characterizes that the target object is deleted in the multi-version file, deleting the instance of the target object in the object logic header.
6. The method according to claim 1 or 5, characterized in that the method further comprises:
and if the operation log characterizes that the target object is deleted in the multi-version file, deleting the object logic header if other examples do not exist in the object logic header after deleting the example of the target object in the object logic header.
7. The method of claim 1, wherein if a first target object and a second target object are concurrently operated on the multi-version file and the second target object completes the operation after the first target object, updating version information of the multi-version file in the object logic header comprises:
for the operation of the first target object and the operation of the second target object, increasing the version numbers one by one on the basis of the original version numbers so as to generate the numbers of the latest version;
and determining the latest version of the object in the multi-version file according to the operation type of the first target object and the operation type of the second target object, and recording the generated latest version number and the determined latest version of the object in the updated version information of the multi-version file.
8. The method of claim 7, wherein determining the most current version of the object in the multi-version file comprises:
if the operation types of the first target object and the second target object are both added object types, determining the second target object as the object of the latest version;
if one of the operation types of the first target object and the second target object is an added object type, the other is a deleted object type, and the target object corresponding to the added object type is determined to be the object of the latest version;
and if the operation types of the first target object and the second target object are both the deleted object types, searching the latest added object in the rest objects of the multi-version file, and determining the latest added object as the latest version object.
9. The method of claim 7, wherein the method further comprises:
and when at least one of the operation types of the first target object and the second target object is a deleted object type, deleting the object logic header after deleting the version instance of the object in the object logic header, and if other instances do not exist in the object logic header.
10. The method of claim 1, wherein after generating the operation log of the target object in the object logic header, the method further comprises:
setting the operation log in the object logic header to a pending state;
generating a metadata operation log of the target object in a storage area of the multi-version file, and setting the metadata operation log to be in a pending state;
wherein, after the target object completes an operation, the operation log in the object logic header is deleted, and the state of the metadata operation log in the storage area is set to a completed state.
11. The method of claim 10, wherein after the target object completes an operation, the method further comprises:
and detecting the metadata operation log of the target object in the storage area, and judging whether the metadata of the target object in the storage area and the object logic head need to be repaired or not according to the current state of the metadata operation log.
12. The method of claim 11, wherein determining whether metadata of the target object in the storage area and the object logical header needs to be repaired comprises:
if the current state of the metadata operation log is a pending state, judging whether the target object has completed operation in the multi-version file, and if so, judging that the metadata of the target object in the storage area and the object logic head need to be repaired;
and if the current state of the metadata operation log is a completion state, determining that the metadata of the target object in the storage area and the object logic head does not need to be repaired.
13. The method of claim 11 or 12, wherein repairing metadata of the target object in the storage area and the object logical header comprises:
setting the metadata operation log to a completion state in the storage area;
and executing a completion action matched with the operation log on the instance of the target object in the object logic head, and deleting the operation log in the object logic head.
14. An operating system for a multi-version file, the system comprising:
the object logic header configuration unit is used for configuring an object logic header for the multi-version file, wherein the object logic header is used for recording metadata of the multi-version file; wherein, different multi-version files have different object logic heads;
an object operation unit, configured to generate an operation log of a target object in the object logic header when the object logic header performs an operation on the target object in the multi-version file, and perform a completion action matched with the operation log on an instance of the target object in the object logic header after the target object completes the operation;
and the version information updating unit is used for updating the version information of the multi-version file in the object logic header, wherein the version information is at least used for representing the number of the latest version and pointing to the object of the latest version.
15. The system according to claim 14, wherein the object operation unit includes:
the object adding module is used for adding the target object in the multi-version file if the operation log represents the operation log, generating an instance of the target object according to the operation log, and storing the instance of the target object into the object logic head;
and the object deleting module is used for deleting the target object in the multi-version file if the operation log characterizes that the target object is deleted, and deleting the instance of the target object in the object logic header.
16. The system according to claim 14, wherein the version information updating unit includes:
the number updating module is used for increasing the version numbers one by one on the basis of the original version numbers if a first target object and a second target object are operated concurrently for the multi-version file and the second target object completes operation after the first target object, and the operation of the first target object and the operation of the second target object are operated for generating the number of the latest version;
and the information recording module is used for determining the object of the latest version in the multi-version file according to the operation type of the first target object and the operation type of the second target object, and recording the generated number of the latest version and the determined object of the latest version in the updated version information of the multi-version file.
17. The system of claim 14, wherein the system further comprises:
a state setting unit configured to set the operation log in the object logic header to a pending state; generating a metadata operation log of the target object in a storage area of the multi-version file, and setting the metadata operation log to be in a pending state;
and a log operation unit configured to delete the operation log in the object logic header and set a state of the metadata operation log in the storage area to a completion state after the target object completes an operation.
18. The system of claim 17, wherein the system further comprises:
and the metadata restoration unit is used for detecting the metadata operation log of the target object in the storage area and judging whether the metadata of the target object in the storage area and the object logic head need to be restored according to the current state of the metadata operation log.
19. An operating device for a multi-version file, characterized in that the device comprises a memory and a processor, the memory being arranged to store a computer program which, when executed by the processor, implements the method according to any of claims 1 to 13.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010528171.7A CN111752909B (en) | 2020-06-11 | 2020-06-11 | Method, system and device for operating multi-version file |
| PCT/CN2020/103447 WO2021248640A1 (en) | 2020-06-11 | 2020-07-22 | Multi-version file operation method, system and apparatus |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010528171.7A CN111752909B (en) | 2020-06-11 | 2020-06-11 | Method, system and device for operating multi-version file |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111752909A CN111752909A (en) | 2020-10-09 |
| CN111752909B true CN111752909B (en) | 2023-05-16 |
Family
ID=72675931
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010528171.7A Active CN111752909B (en) | 2020-06-11 | 2020-06-11 | Method, system and device for operating multi-version file |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN111752909B (en) |
| WO (1) | WO2021248640A1 (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112286880A (en) * | 2020-10-23 | 2021-01-29 | 北京金山云网络技术有限公司 | Data storage method, device, equipment and storage medium |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5649200A (en) * | 1993-01-08 | 1997-07-15 | Atria Software, Inc. | Dynamic rule-based version control system |
| JP2000181917A (en) * | 1998-12-18 | 2000-06-30 | Hitachi Ltd | Structured document managing method, executing device therefor and medium recording processing program therefor |
| CN106708734A (en) * | 2016-12-13 | 2017-05-24 | 腾讯科技（深圳）有限公司 | Software abnormality detection method and apparatus |
| CN110612702A (en) * | 2017-05-31 | 2019-12-24 | 思科技术公司 | Intent specification checking for inconsistencies |
| CN111090620A (en) * | 2019-12-06 | 2020-05-01 | 浪潮电子信息产业股份有限公司 | File storage method, device, equipment and readable storage medium |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7363540B2 (en) * | 2002-10-22 | 2008-04-22 | Microsoft Corporation | Transaction-safe FAT file system improvements |
| US20070005874A1 (en) * | 2005-07-01 | 2007-01-04 | Dan Dodge | File system storing transaction records in flash-like media |
| US10552402B2 (en) * | 2014-11-25 | 2020-02-04 | Amarnadh Sai Eluri | Database lockless index for accessing multi-version concurrency control data |
| CN110019134A (en) * | 2017-12-27 | 2019-07-16 | 阿里巴巴集团控股有限公司 | The multi-edition control method and equipment of database |
| CN109271194B (en) * | 2018-08-22 | 2022-07-26 | 五八有限公司 | Branch access method and device based on distributed version control system |
-
2020
- 2020-06-11 CN CN202010528171.7A patent/CN111752909B/en active Active
- 2020-07-22 WO PCT/CN2020/103447 patent/WO2021248640A1/en active Application Filing
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5649200A (en) * | 1993-01-08 | 1997-07-15 | Atria Software, Inc. | Dynamic rule-based version control system |
| JP2000181917A (en) * | 1998-12-18 | 2000-06-30 | Hitachi Ltd | Structured document managing method, executing device therefor and medium recording processing program therefor |
| CN106708734A (en) * | 2016-12-13 | 2017-05-24 | 腾讯科技（深圳）有限公司 | Software abnormality detection method and apparatus |
| CN110612702A (en) * | 2017-05-31 | 2019-12-24 | 思科技术公司 | Intent specification checking for inconsistencies |
| CN111090620A (en) * | 2019-12-06 | 2020-05-01 | 浪潮电子信息产业股份有限公司 | File storage method, device, equipment and readable storage medium |
Non-Patent Citations (1)
| Title |
|---|
| 窦万峰,李春萍.多版本技术中的对象标识及其压缩.软件学报.2004,(第08期),全文. * |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2021248640A1 (en) | 2021-12-16 |
| CN111752909A (en) | 2020-10-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN107391628B (en) | Data synchronization method and device | |
| US6675180B2 (en) | Data updating apparatus that performs quick restoration processing | |
| CN103902623A (en) | Method and system for accessing files on a storage system | |
| TWI730690B (en) | Method and device for simultaneously executing transactions in block chain, computer readable storage medium and computing equipment | |
| CN1983267A (en) | File system having deferred verification of data integrity | |
| US9384202B1 (en) | Gateway module to access different types of databases | |
| CN112487083B (en) | Data verification method and device | |
| CN107016047A (en) | Document query, document storing method and device | |
| US6192376B1 (en) | Method and apparatus for shadowing a hierarchical file system index structure to enable error recovery | |
| CN111752909B (en) | Method, system and device for operating multi-version file | |
| CN113253932B (en) | Read-write control method and system for distributed storage system | |
| CN106874329A (en) | The implementation method and device of database table index | |
| CN102495838B (en) | Data processing method and data processing device | |
| US20110238639A1 (en) | Information processing apparatus | |
| CN116467277A (en) | Metadata processing method, device, equipment, storage medium and product | |
| CN115086757B (en) | Method, device, equipment and storage medium for withdrawing history editing operation | |
| CN113641651A (en) | Business data management method, system and computer storage medium | |
| CN114816509A (en) | Block chain version compatibility verification method and device and electronic equipment | |
| CN113032348A (en) | Spatial data management method, system and computer readable storage medium | |
| CN112579591B (en) | Data verification method, device, electronic equipment and computer readable storage medium | |
| CN115543685A (en) | Database rollback method and device, electronic equipment and storage medium | |
| CN111444114B (en) | Method, device and system for processing data in nonvolatile memory | |
| US9262264B2 (en) | Error correction code seeding | |
| CN111930302A (en) | Data reading method and device, computer readable storage medium and electronic equipment | |
| CN114840545B (en) | Block chain fine-grained editing method supporting rapid state updating |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |