Data storage management method, device and storage medium for multi-modal files

Abstract

The application discloses a kind of data storage management methods, equipment and storage medium of multi-modal file, belong to file management technical field.The method includes: when receiving the write request to target file, target file is divided into data block according to predetermined block length and is written into file content table, records the file identification and storage order of each data block, and file identification and the file length of target file are written into file entry table, when receiving the length modification request to target file, the target length in length modification request is compared with the file length in file entry table, when target length is greater than file length, initialize extension data block and record to file content table, target length is less than file length, delete the data block of file content table beyond target length, update the file length in file entry table as target length.

Description

Technical Field

[0001] This application relates to the field of file management technology, and in particular to a data storage management method, device and storage medium for multimodal files. Background Technology

[0002] Files of different modalities differ significantly in size and update patterns. Among them, text and log files are relatively small in size and updated frequently, image files are of moderate size and are mainly read and written as a whole, while audio, video and other multimedia files are huge in size and their length often increases or decreases due to operations such as streaming recording and editing.

[0003] In related technologies, application systems store multimodal files on a disk file system and record information such as the file path and name in a database. Some systems employ a database-based large file storage mechanism, which splits the file into multiple data blocks of a fixed size. One data set stores the file's name, size, and other attribute information, while another data set stores each data block in the order of splitting. When reading the file, each data block is read sequentially according to the splitting order and reassembled to restore the complete file.

[0004] However, the storage mechanism uses a whole-file write approach when saving files; once the file is saved, the content of each data block is fixed. When the business needs to adjust the length of an already saved file, the storage mechanism cannot make partial changes based on the existing data blocks. It can only regenerate all the data of the changed file, split all the data again, and then write it all again. For large files, even a length adjustment involving only a small amount of content changes requires splitting and writing the entire file again. The amount of data transferred and written is comparable to the overall file size. The transmission and storage resources used during the change process continue to increase with the file size, resulting in low efficiency for length changes of large files and making it difficult to meet the frequent file update needs in scenarios with massive numbers of files.

[0005] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0006] The main objective of this application is to provide a data storage and management method, device, and storage medium for multimodal files, aiming to solve the technical problem that inefficiency in changing the length of large files makes it difficult to meet the frequent update requirements of files.

[0007] To achieve the above objectives, this application provides a data storage and management method for multimodal files, the method comprising the following steps: When a write request for a target file is received, the target file is divided into data blocks according to a predetermined block length and written into the file content table. The file identifier and storage order of each data block are recorded, and the file identifier and the file length of the target file are written into the file entry table. When a length modification request for the target file is received, the target length in the length modification request is compared with the file length in the file entry table; When the target length is greater than the file length, an extended data block is initialized and recorded in the file content table; when the target length is less than the file length, data blocks in the file content table that exceed the target length are deleted. Update the file length in the file entry table to the target length.

[0008] In one embodiment, after receiving a write request for a target file, dividing the target file into data blocks according to a predetermined block length and writing them into a file content table, recording the file identifier and storage order of each data block, and writing the file identifier and the file length of the target file into a file entry table, the method further includes: Receive a read request for the target file, the read request carrying the read start position and read length; The target data block to be read is determined based on the read start position and the read length; Each of the target data blocks is read from the file content table in the storage order described; The read target data blocks are concatenated into read data and returned.

[0009] In one embodiment, after the step of receiving a read request for the target file, the read request carrying a read start position and a read length, the method further includes: Receive a length query request for the target file; The file length of the target file is obtained by querying the file entry table based on the file identifier. The obtained file length is returned as the total length of the target file.

[0010] In one embodiment, after the step of updating the file length in the file entry table to the target length, the method further includes: Receive a deletion request for the target file, the deletion request carrying the file identifier; Delete the entry record corresponding to the file identifier from the file entry table; Delete all data blocks corresponding to the file identifier from the file content table.

[0011] In one embodiment, the steps of receiving a write request for a target file, dividing the target file into data blocks according to a predetermined block length and writing them into a file content table, recording the file identifier and storage order of each data block, and writing the file identifier and the file length of the target file into a file entry table include: The target file is divided into at least one data block of a predetermined block length of one megabyte; Generate a corresponding cloud storage file name for each of the data blocks; The data block size of each data block and the cloud storage file name are recorded in the file content table, corresponding to the file identifier and the storage order.

[0012] In one embodiment, prior to the step of dividing the target file into at least one data block of a predetermined block length of one megabyte, the method further includes: Establish a path table, and record the storage paths and the storage type identifiers corresponding to each storage path in the path table; Set the storage type identifier of the target storage path used to store the target file to a first preset value; The target storage path is determined from the path table based on the first preset value; Write the target storage path and the file identifier into the file entry table, and record the file name, directory identifier, creation time, modification time and access time of the target file in the file entry table.

[0013] In one embodiment, the steps of receiving a write request for a target file, dividing the target file into data blocks according to a predetermined block length and writing them into a file content table, recording the file identifier and storage order of each data block, and writing the file identifier and the file length of the target file into a file entry table include: The file operation micro-engine receives the write request and caches the data to be written corresponding to the write request in memory; The file operation micro-engine pre-reads the data blocks of the target file in the background; Following the slow write strategy, the cached data to be written is divided into data blocks and then asynchronously written to the file content table.

[0014] In one embodiment, before the step of receiving the write request by the file operation microengine and caching the data to be written corresponding to the write request in memory, the method further includes: Identify the file type of the target file; When the file type is a compressed file, the target file is decompressed in memory to obtain a decompressed file; The decompressed file is divided into data blocks according to the predetermined block length and written into the file content table, and an entry record of the decompressed file is generated in the file entry table.

[0015] In addition, to achieve the above objectives, this application also provides a data storage management device for multimodal files, the device comprising: a memory, a processor, and a computer program stored on the memory and executable on the processor, the computer program being configured to implement the steps of the data storage management method for multimodal files as described above.

[0016] In addition, to achieve the above objectives, this application also provides a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the data storage management method for multimodal files as described above.

[0017] One or more technical solutions proposed in this application have at least the following technical effects: This application, upon receiving a write request for a target file, divides the target file into data blocks of a predetermined block length and writes them to a file content table, recording the file identifier and storage order of each data block. The file identifier and the target file's length are also written to a file entry table, allowing file attribute information and content data to be stored separately. Upon receiving a length modification request for the target file, the target length in the modification request is compared with the file length recorded in the file entry table. If the target length is greater than the file length, an extended data block is initialized and recorded in the file content table. If the target length is less than the file length, the data block exceeding the target length in the file content table is deleted, and the file length in the file entry table is updated to the target length. Thus, changing the file length is transformed into a partial addition or deletion of data blocks in the file content table and an update of the length information in the file entry table. It eliminates the need to regenerate and write all the data in the entire file. The amount of data involved in the change is only related to the length-changed portion, independent of the overall file size. This reduces the transmission and storage resources consumed by file length changes, enabling efficient length adjustments for large, already saved files and meeting the frequent file update needs in scenarios with massive amounts of data. Attached Figure Description

[0018] 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.

[0019] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a flowchart illustrating the first embodiment of the data storage and management method for multimodal files in this application; Figure 2 This is a flowchart illustrating the second embodiment of the data storage management method for multimodal files in this application; Figure 3 This is a schematic diagram of the structure of a data storage and management device for multimodal files in the hardware operating environment involved in the embodiments of this application.

[0021] The realization of the purpose, functional features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0022] It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit this application.

[0023] To better understand the above technical solutions, the following will provide a detailed explanation of the technical solutions in conjunction with the accompanying drawings and specific implementation methods.

[0024] The main solution of this application embodiment is as follows: When a write request for a target file is received, the target file is divided into data blocks according to a predetermined block length and written into the file content table. The file identifier and storage order of each data block are recorded, and the file identifier and the file length of the target file are written into the file entry table. When a length modification request for the target file is received, the target length in the length modification request is compared with the file length in the file entry table. If the target length is greater than the file length, an extended data block is initialized and recorded in the file content table. If the target length is less than the file length, the data block in the file content table that exceeds the target length is deleted, and the file length in the file entry table is updated to the target length.

[0025] Because the storage mechanism writes files as a whole, the content of each data block is fixed after the file is saved. When the business needs to adjust the length of an already saved file, the storage mechanism cannot make partial changes based on the existing data blocks. It can only regenerate all the data of the changed file, split all the data again, and then write it all again. For large files, even length adjustments involving only a small amount of content change require splitting and writing the entire file again. The amount of data transferred and written is comparable to the overall file size. The transmission and storage resources used during the change process continue to increase with the file size, resulting in low efficiency for length changes of large files and making it difficult to meet the frequent file update needs in scenarios with massive numbers of files.

[0026] Upon receiving a write request for a target file, this application divides the target file into data blocks according to a predetermined block length and writes them to the file content table. It records the file identifier and storage order of each data block and writes the file identifier and the target file's length to the file entry table, thus storing file attribute information and content data in separate tables. Upon receiving a length modification request for the target file, it compares the target length in the length modification request with the file length recorded in the file entry table. If the target length is greater than the file length, it initializes extended data blocks and records them in the file content table; if the target length is less than the file length, it deletes data blocks in the file content table that exceed the target length and updates the file length in the file entry table to the target length. Therefore, changing the file length is transformed into a partial addition or deletion of data blocks in the file content table and an update of the length information in the file entry table. It does not require regenerating and writing all the data of the entire file. The amount of data involved in the change is only related to the part with the changed length and is independent of the overall file size. This reduces the transmission and storage resources occupied by file length changes, enabling large files that have already been saved to be adjusted in length efficiently, meeting the frequent file update needs in scenarios with massive amounts of files.

[0027] To better understand the above technical solutions, exemplary embodiments of this application will be described in more detail below with reference to the accompanying drawings. Although exemplary embodiments of this application are shown in the drawings, it should be understood that this application can be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to enable a more thorough understanding of this application and to fully convey the scope of this application to those skilled in the art.

[0028] It should be noted that the executing entity in this embodiment can be a file storage management system, or a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or multimodal file data storage and management device capable of the above functions. This embodiment does not specifically limit it in this regard. The following uses a file storage management system as an example to describe this embodiment and the following embodiments.

[0029] Based on this, embodiments of this application provide a data storage and management method for multimodal files, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the data storage and management method for multimodal files in this application.

[0030] In this embodiment, the data storage management method for multimodal files includes steps S10 to S40: Step S10: When a write request for a target file is received, the target file is divided into data blocks according to a predetermined block length and written into the file content table. The file identifier and storage order of each data block are recorded, and the file identifier and the file length of the target file are written into the file entry table. It should be noted that the target file involved in this application embodiment can be any of multiple modal files such as text, images, audio, video, and compressed files. Although multimodal files differ in data type and internal encoding format, from a storage management perspective, they can all be abstracted as a continuous binary data segment. Their common characteristics are that they need to be reliably persisted, support sequential or random access, and may change in length during their lifecycle. Text and log files are relatively small in size but frequently updated; image files are mainly read and written as a whole; while audio, video, and other multimedia files are large in size and their length often increases or decreases due to streaming recording, editing, and other operations. In this embodiment, the file storage management system treats any multimodal file as a unified sequence of data blocks divided according to a predetermined block length. It manages their attribute information and content data separately through a file entry table and a file content table, thereby adapting to the storage management needs of different modal files such as text, images, audio, video, and compressed files with a unified storage structure.

[0031] In this embodiment, after receiving a write request for a target file, the file storage management system collaboratively completes persistent file storage through two independent data tables: a file content table and a file entry table. The file content table is a structured table in the database used to store file data block information. Each record is bound to a file identifier and a storage sequence number. This table manages the storage of file content data in units of data blocks. The file identifier is a globally unique identifier generated by the file storage management system for each file. It is generated using an algorithm based on timestamps and random numbers and is used to associate all records of the same file between the file content table and the file entry table, ensuring that identifiers are not duplicated between different files. The storage sequence represents the sequence number of data blocks in the file, starting from the beginning and incrementing from 1. Its value determines the concatenation order of each data block when reading the file. The reading process retrieves the corresponding data blocks sequentially in ascending order of storage sequence to restore the file. The file entry table is a structured table in the database used to store file attribute information. Each record corresponds to a file and contains two basic fields: file identifier and file length. This table is associated with the file content table through the file identifier, forming a storage architecture that manages file attribute information and content data separately. When querying the file length, the caller can directly obtain it from the file entry table without traversing the file content table. The predefined block length is a fixed number of bytes preset by the file storage management system for each data partition. It serves as the basic unit for splitting the file into data blocks, and the size of each data block does not exceed the predefined block length. A data block is an independent data unit obtained after the file is divided according to the predefined block length. Except for the data block at the end of the file, the size of each data block is equal to the predefined block length.

[0032] Specifically, after receiving a write request for a target file, the file storage management system extracts the file identifier and the binary data content to be written from the message body of the request. The file identifier is either carried by the caller in the request or automatically assigned by the file storage management system based on an identifier generation algorithm after receiving the request and returned to the caller in the response. The system divides the data content to be written into segments according to a predetermined block length. The segmentation operation starts from the first byte of the data content, and each time a predetermined block length of bytes is truncated, a storage sequence number is assigned to the current data block. The numbering starts from 1, and automatically increments by 1 after each data block is truncated, until all bytes of the data content have been allocated to their respective data blocks. For the remaining portion at the end of the data content, if its byte count is less than the predetermined block length, the system does not pad it; the actual remaining bytes are used as the effective data volume of the data block. The system generates a record in the file content table for each data block. The record includes the file identifier of the file to which the data block belongs and the storage order number of the data block. The binary content of the data block is written along with the record to the storage space of the file content table, ensuring that any data block can be uniquely located and retrieved in the file content table by combining the file identifier and storage order. After all data block records are written to the file content table, the system queries the file entry table using the file identifier as the query condition to determine if an entry record corresponding to that file identifier already exists. If the query result is empty, the system determines that the target file is being written for the first time, creates a new entry record in the file entry table, and writes the file identifier and the total length of the target file in bytes after this write operation to this record. If an existing entry record is found, the system reads the file length value of the current record from the file entry table, adds the number of bytes written this time to obtain the new total length, and updates the file length field of that record in the file entry table to the new total length value.

[0033] In this embodiment, the file storage management system internally includes a file operation micro-engine. This micro-engine serves as the unified access module and scheduling core for file write requests, transforming the traditional mode of direct synchronous write triggered by the caller into a micro-engine-managed write mode. The file operation micro-engine is an independently running software component within the file storage management system, maintaining a memory cache and a set of background scheduling threads, responsible for receiving, buffering, and asynchronously executing file write requests. The data to be written refers to the binary data content carried in the write request that needs to be persistently stored in the file content table. Background pre-reading refers to the micro-engine reading the contents of existing data blocks in the target file from the file content table into the memory cache in advance, based on historical access patterns or a preset pre-reading strategy, before receiving the write request, so that subsequent write operations can use them together. The slow write strategy refers to the micro-engine using a controlled write rate execution method when writing data to the file content table, splitting a large write operation into multiple time slices for step-by-step completion or smoothing the input / output load by limiting the number of bytes written per unit time. Asynchronous writing means that the message sending of the write request is decoupled from the actual persistence of the data in time; the caller receives a response immediately after sending the request without waiting for the disk write to complete.

[0034] Specifically, after an external caller sends a write request to the file storage management system for a target file, the file operation micro-engine intercepts the request and parses it into the data to be written and the file identifier of the target file. The micro-engine extracts the data to be written from the request message body and writes it to a memory cache maintained internally by the micro-engine. This memory cache is a circular buffer or a page-based cache structure, supporting multi-threaded concurrent writes and reads. After completing the caching of the data to be written, the micro-engine immediately returns an acknowledgment response to the caller, indicating that the write request has been received. The caller can continue to perform subsequent operations without waiting for the data to be actually written to the file content table. The background scheduling thread of the micro-engine retrieves the cached data to be written from the memory cache. Before persisting the data, the micro-engine queries the file content table for existing data block records based on the file identifier of the target file and pre-reads the contents of the existing data blocks in the target file into the memory cache. The pre-read data blocks include data blocks adjacent to the current write interval to maintain the continuity of the storage order between data blocks during the write operation. The scheduling thread executes data block partitioning and file content table writing operations according to a slow write strategy. This slow write strategy spreads the write load across the time axis by setting a maximum limit on the number of bytes written per unit time or by setting a fixed waiting interval between each file content table write operation, preventing large file writes from exhausting the system's input / output bandwidth in a short period. The scheduling thread divides the data to be written in the cache into data blocks according to a predetermined block length, assigns a corresponding storage sequence number to each data block, generates file content table records one by one, and writes them to the file content table asynchronously. After the write is complete, the microengine updates the write completion flag in the memory cache.

[0035] As an optional implementation, the file storage management system also includes a data block size field and a cloud storage filename field in each record of the file content table. The data block size field records the actual number of valid bytes in the current data block, used to accurately define the valid data boundary of each data block during reading, avoiding the reading of invalid bytes beyond the actual data range. The cloud storage filename field generates a globally unique string value based on a combination of file identifier and storage order using a hash algorithm. This string value serves as the physical filename of the corresponding data block on the cloud storage device, pointing to the actual storage location of the data block on the cloud storage device. When generating the file content table record, the file storage management system simultaneously calculates the actual number of bytes in the current data block, writes the calculation result into the data block size field of the record, and simultaneously generates the corresponding cloud storage filename using the file identifier and storage order number as input parameters for the hash algorithm, writing it into the cloud storage filename field. When reading data blocks subsequently, the system determines the exact range of bytes to be read from the storage device using the data block size field. It then directly locates the corresponding data unit file on the cloud storage device using the cloud storage filename field. This eliminates the need for sequential traversal of multiple records in the file content table based on file identifiers and storage order, reducing the number of file content table queries from multi-record scans dependent on storage order traversal to precise location of a single record. The hash generation rule for the cloud storage filename uses the file identifier as the core input, ensuring that different files with the same storage order number produce different hash output values ​​due to different file identifiers. This achieves uniqueness of the name for each data block within the global namespace of the cloud storage device.

[0036] As an alternative implementation, before receiving a write request for a target file, the file storage management system pre-establishes a path table in the database. This path table records the hierarchical structure of all storage paths in the file storage system and the type of each path. Each record in the path table contains a path string and a storage type identifier. The storage type identifier distinguishes the function of the path using a preset integer value. Paths used for file storage have their storage type identifier set to a first preset value to differentiate them from paths used for other types of data storage. Upon receiving a write request, the file storage management system queries the path table, filtering all path records for all file storage types based on the first preset value of the storage type identifier. It then matches the corresponding target storage path from the filtered results based on the directory affiliation of the target file. The system associates the path information of the target storage path with the file identifier of the target file and writes it into the corresponding record in the file entry table. Simultaneously, the file entry table records four attribute fields for the target file: filename, file identifier of its directory, creation time, modification time, and access time. The creation time and modification time are set to the current system time of the server where the file storage management system is located when the file is first written. The values ​​of the two are the same at this moment. The access time is also consistent with the creation time and modification time when the file is written. Subsequently, the system updates the access time to the system time when the read operation occurred each time the file is read.

[0037] Optionally, the communication protocol type of the database instance to be accessed is identified, a communication connection is established with the database instance according to the communication protocol corresponding to the communication protocol type, the instance information of the database instance is obtained through the communication connection, the instance information is written into the database instance table, a file content table and the file entry table are created in the database instance, and management operations on the file content table and the file entry table are recorded in the operation log table.

[0038] For example, taking a scenario where the predetermined block length is 1 megabyte, the file storage management system receives a write request for a target file of 5.5 megabytes. After extracting the file identifier, the system divides the data starting from the beginning of the data content. For the first five writes, 1 megabyte of data is extracted each time as a data block, and storage sequence numbers 1, 2, 3, 4, and 5 are assigned sequentially. For the sixth write, the remaining 0.5 megabytes of data are extracted as the sixth data block and assigned storage sequence number 6. The system writes these six records one by one into the file content table. Each record contains the same file identifier, its own storage sequence number, and the corresponding binary content of the data block. This write is the first write to the target file. Since there is no entry record corresponding to this file identifier in the file entry table yet, the system creates a new record in the file entry table, writing the file identifier and the total number of bytes corresponding to 5.5 megabytes.

[0039] Step S20: When receiving a length modification request for the target file, compare the target length in the length modification request with the file length in the file entry table; In this embodiment, after receiving a length modification request for a target file, the file storage management system performs a numerical comparison operation between the target length and the file length already recorded in the file entry table. The comparison result is used to determine the direction and magnitude of subsequent data block adjustment operations. The length modification request is an operation message sent by an external caller to the file storage management system to adjust the total length of the target file. The message body of this request carries a target length parameter, which represents the total number of bytes the caller expects the target file to reach after modification. Its value is set by the caller according to the actual needs of the business scenario, and the value range is an integer greater than or equal to 0. The file length is the current total length value of the target file that has been persistently stored in the file entry table. It is stored in bytes in the file length field of the corresponding entry record of the target file in the file entry table. This field value is generated when the target file completes its first write and is updated to the new length value after each length modification operation of the target file, maintaining strict consistency with the total number of bytes of the currently actually stored data blocks in the file content table.

[0040] Specifically, after receiving a length modification request for a target file, the file storage management system extracts the target length parameter and the target file's file identifier from the structured message body of the request, according to predefined field names. Using the extracted file identifier as a query condition, the system performs a precise single-record lookup in the file entry table. After locating the entry record uniquely corresponding to that file identifier, it reads the current file length value stored in the file length field of that record. This value represents the total number of bytes of the target file confirmed before receiving this length modification request. The system performs a byte-by-byte integer comparison between the extracted target length value and the read file length value in memory. The comparison result falls into three categories: if the integer value of the target length is greater than the integer value of the file length, the system determines that the target file needs to be extended, and the subsequent processing flow is directed to the extension branch; if the integer value of the target length is less than the integer value of the file length, the system determines that the target file needs to be shortened, and the subsequent processing flow is directed to the truncation branch; if the two integer values ​​are equal, the system determines that the target file does not need to be changed in length, and the subsequent data block addition / deletion process is not entered. The comparison operation is performed in memory using the processor's basic comparison instructions. The entire comparison process does not generate any input / output requests to the file content table. Its execution time is a constant time for a single memory fetch and integer comparison, and is independent of the actual storage volume of the target file on the disk and the number of data block records already stored in the file content table. Even if the target file stores thousands of data blocks in the file content table, the response time of the comparison operation remains stable.

[0041] As an optional implementation, the file storage management system incorporates a file operation micro-engine module. This micro-engine serves as the unified access layer and scheduling core for all file operation requests within the system, responsible for receiving and coordinating the execution of various file operation requests from external callers. Internally, the micro-engine maintains a task queue and a set of background scheduling threads. When an external caller sends a length modification request to the system, the micro-engine intercepts the request and packages it into a task object, placing it in the task queue. The task object encapsulates the complete parameter content of the request. The background scheduling threads retrieve the task objects to be processed from the task queue according to the order in which tasks arrive and a preset priority strategy. After retrieving the length modification task, the scheduling thread does not directly enter the comparison stage between the target length and the file length. Instead, it first initiates a query to the file entry table based on the file identifier in the task object, completely caching the retrieved target file entry record in the memory space of the scheduling thread. This caching operation allows subsequent comparison operations to directly read the file length value from memory, avoiding sending another database query request to the file entry table during the comparison stage.

[0042] As an alternative implementation, the file storage management system provides an independent file length query function to external callers before receiving a length modification request. Before deciding to modify the length of the target file, the external caller sends a length query request to the file storage management system, with the file identifier of the target file carried in the message body. Upon receiving the length query request, the file storage management system locates the entry record in the file entry table using the file identifier as the query condition, reads the current value of the file length field, and returns it as the query result to the external caller. After obtaining the accurate current file length of the target file, the caller determines whether to increase or decrease the file length based on this accurate value, and determines the specific target length value. Subsequently, it constructs a length modification request and sends it to the file storage management system. Upon receiving the length modification request, the system enters the comparison operation process.

[0043] Step S30: When the target length is greater than the file length, initialize the extended data block and record it in the file content table; when the target length is less than the file length, delete the data block in the file content table that exceeds the target length. In this embodiment, the file storage management system performs data block addition and deletion operations on the file content table according to the comparison results of the aforementioned steps, aligning the total length of the data blocks actually stored in the file content table with the target length. Initializing an extended data block refers to creating a new data block record in the file content table. This record contains the file identifier of the target file and a newly added storage sequence number. The addition of the new record increases the total number of data block records corresponding to the target file in the file content table, logically extending the sum of the lengths of all data block records to the target length. The data content portion of the newly added data block record can be filled with empty bytes or system-preset placeholder bytes. A data block exceeding the target length refers to a data block record whose starting byte position corresponding to the storage sequence number falls after the ending byte position of the target length. Specifically, the target length is divided by the predetermined block length and rounded down to obtain a cutoff storage sequence number. All data block records in the file content table corresponding to the target file whose storage sequence number is greater than this cutoff number are considered data blocks exceeding the target length and need to be removed from the file content table.

[0044] Optionally, in expansion scenarios where the target length is greater than the file length, the file storage management system enters the expansion processing flow. The system calculates the total number of bytes to be expanded as the difference between the target length and the file length. It then divides this number by the predetermined block length to obtain the basic addition quantity. If a remainder exists after division, it indicates that the last data block after expansion is not a complete block, and the system increments the basic addition quantity by 1 to obtain the final number of data blocks to be added. The system queries the file content table using the file identifier as a condition to determine the current range of storage order numbers for the target file. It then determines the currently allocated maximum storage order number and, starting from the position of the maximum storage order number plus 1, assigns an incrementing storage order number to each data block to be added. For each data block to be added, the system constructs a new data block record in the file content table. In this record, the file identifier field is filled with the target file's file identifier, the storage order field is filled with the currently allocated incrementing number, and the data content is filled with zero bytes or a preset placeholder byte sequence. After construction, the new record is written to the file content table one by one.

[0045] Optionally, in truncation scenarios where the comparison result indicates the target length is less than the file length, the file storage management system enters the truncation process. The system divides the target length by the predetermined block length and performs a floor operation, the result of which is the cutoff storage order number of the retained data block. The data block corresponding to this cutoff number is the data block with the largest storage order number within the target length range. The system retrieves all data block records exceeding the target length in the file content table using the file identifier and storage order greater than the cutoff number as joint query conditions, and performs deletion operations one by one in descending order of storage order, or marks these records in batches as deleted and then reclaims them uniformly by a background cleanup task. If the target length is not an integer multiple of the predetermined block length, that is, the end byte position of the target length falls exactly inside the data block corresponding to the cutoff number rather than at the end, the system performs a truncation operation on the data block corresponding to the cutoff number, retaining the valid byte portion from the start position of the data block to the end position of the target length in the binary content of the data block, clearing the tail bytes of the excess portion, and updating the byte size recorded in the file content table of the data block to the actual number of bytes retained after truncation.

[0046] As an optional implementation, when the file storage management system receives a write request for a target file, it first performs file type identification of the target file before data partitioning. File type identification is achieved by parsing the magic number feature bytes within a preset byte range in the header of the target file or by parsing the file extension. The system matches the identified feature byte sequence with a preset compressed file type feature library. When a match is successful, the system determines that the target file is a compressed file and does not directly partition the compressed file itself into data blocks according to the predetermined block length. The system allocates a data buffer in memory, reads the complete binary data of the compressed file into the buffer, and calls the system's built-in decompression program module to perform decompression operations on the compressed file. The decompression program parses the directory structure and file list according to the internal format specifications of the compressed file, and sequentially decompresses each original file in the compressed file and temporarily stores it in the memory buffer. The entire decompression operation is completed in memory, and the intermediate data and decompression result data generated during the decompression process are not written to persistent storage devices. The system takes the decompressed original file data as input and performs data block partitioning for each original file. It divides the file into data blocks according to a predetermined block length and writes the data to the file content table. Simultaneously, it generates an independent entry record for each original file in the file entry table, recording the file identifier and file length. The original directory hierarchy within the compressed archive is preserved through path records in the path table and directory identifier fields in the file entry table. After decompression, each original file forms the same hierarchical organization structure in the file storage management system as before compression.

[0047] As an alternative implementation, in extended scenarios where the target length is greater than the file length, the file storage management system does not immediately allocate actual persistent storage space for each newly added data block record. Instead, it employs a delayed allocation mechanism using reserved records. The system creates a record for each newly added data block in the file content table. This record contains two standard fields: file identifier and storage sequence number, and an additional status identifier field. The system sets the value of this status identifier field to a preset value corresponding to the reserved status. Records in the reserved status occupy a valid record position in the file content table structure, and the allocation operation for the storage sequence number is completely consistent with that of formal records. However, the data content portion of the reserved status record does not point to any actual storage space; its data segment on the persistent storage device is empty or only occupies the metadata space in the record header. When an external caller initiates a new write request to the target file at some later time, and the starting position of the write request happens to cover the storage order range corresponding to a reserved status record, the file storage management system locates the reserved status record in the file content table based on the file identifier and storage order, switches its status identifier field from reserved status to official status, writes the actual binary data provided by the caller to the data content part of the record, and allocates corresponding persistent storage space to accommodate this data.

[0048] Step S40: Update the file length in the file entry table to the target length.

[0049] In this embodiment, after the data block add / delete operation is completed, the file storage management system performs an overwrite operation on the file length field of the entry record corresponding to the target file in the file entry table, replacing the previously stored current file length value in the field with the target length value in the length modification request. The essence of the update operation is an atomic replacement of a single field value in the database record. After the replacement, the length record in the file entry table is realigned with the total length of the data blocks actually stored in the file content table. The file length subsequently queried by the external caller through the file entry table is the updated target length value.

[0050] Specifically, after the data block addition / deletion process is completed and confirmed as successful, the file storage management system obtains the file identifier of the target file involved in this operation. Using the file identifier as a query condition, the system performs precise location of a single record in the file entry table. After finding the unique entry corresponding to that file identifier, it reads the currently stored file length field value of that entry and temporarily stores this value in a memory variable as a historical record value for this change operation. The system then uses the target length value carried in the length modification request as the new value and, through the atomic update primitives provided by the database, overwrites the file length field position of that entry in the file entry table with the new value.

[0051] The atomic update operation of the file length field and the insert / delete operation of data block records in the file content table are encapsulated within the same database transaction. The transaction start flag is set at the beginning of the data block insert / delete operation, and the transaction commit flag is set at the completion of the file length field update. The transaction mechanism ensures that the changes in the two tables have atomic commit semantics. After the transaction is committed, the changes in the two tables are simultaneously visible to the outside world. If the transaction is rolled back due to abnormal interruption at any stage before the commit, the data block insert / delete already performed in the file content table will be undone, and the file length field will remain unchanged with its old value before the update. There will be no intermediate inconsistency state where data blocks have been added or deleted in the file content table but the length in the file entry table is still the old value. If it is determined during the comparison phase that the target length is equal to the file length and no data block insert / delete operation has been triggered, the system can directly skip the field update of the file entry table and return a response indicating that the operation is complete to the caller, or, to maintain the consistency of the processing path, still perform an overwrite write to refresh and write the file length field with the same value. The scope of this update operation is limited to a single field of a target record in the file entry table. Its execution overhead is a single record and single field update at the database level. The execution time is not related to the overall disk space occupied by the target file or the number of data block records in the file content table.

[0052] As an optional implementation, after the file length field update operation in the file entry table is submitted, the file storage management system checks whether the updated file length field value, i.e., the target length value, is equal to 0. When the target length is equal to 0, the system determines that the external caller intends to completely erase all stored data of the target file, triggering a cascading deletion process for the target file. The system locates the entry record of the target file in the file entry table using the file identifier as a condition, and executes the deletion operation of that entry record. After the entry record is deleted, there are no longer any entries corresponding to that file identifier in the file entry table. At the same time, the system retrieves all data block records corresponding to that file identifier in the file content table using the file identifier as a condition, and performs deletion operations sequentially or in batches according to the storage order from smallest to largest, clearing all data block records of the target file in the file content table. The deletion of the entry record and the deletion of all data block records are within the same database transaction as the file length field update operation. The atomicity of the transaction binds the three into an indivisible unit of operation. When the transaction is committed, the entry record and the data block records are removed from their respective tables at the same time. When the transaction is rolled back, the entry record and the data block records are restored to their state before deletion at the same time. There will be no residual state where the entry record has been deleted but some data block records are still retained in the file content table, nor will there be an orphan record state where all data block records have been deleted but the entry record has not been deleted.

[0053] As an alternative implementation, after updating the file length field in the file entry table, the file storage management system synchronously generates an operation log record and writes it to the operation log table. The operation log table is a third table in the database, independent of the file content table and the file entry table, specifically used to persistently record detailed metadata for each file operation event. The operation log record includes an operation type identifier field, a target file identifier field, a length field before change, a length field after change, and an operation timestamp field. The operation type identifier field uses preset enumeration values ​​to distinguish different operation types such as write, length modification, and deletion. The length field before change stores the old value of the file length field before the update, and the length field after change stores the target length value after the update. The operation timestamp field records the current system time of the server where the file storage management system resides when the update operation is committed, accurate to milliseconds. The write action recorded in the operation log table and the update action of the length field in the file entry table are within the same database transaction context. When the transaction is committed, the operation log record and the updated file length value are persisted together. There is no situation where the operation log is recorded but the actual file length has not been updated, nor is there a situation where the file length has been updated but the operation log is not recorded. By filtering and querying the operation log table by file identifier or by operation timestamp range, the auditing system can completely restore the entire operation history of any target file from its creation time to the current time, and the state before and after any length change can be traced independently.

[0054] Optionally, after the file length is updated, the file storage management system provides a cascading deletion function for the target file to the external caller. Cascading deletion refers to simultaneously deleting the entry record in the file entry table and the corresponding data block records in the file content table in a single request. The two deletion operations form an inseparable whole, and after deletion, no record associated with the file identifier remains in the database. After receiving a deletion request for the target file, the file storage management system extracts the file identifier of the target file from the request message body. The system performs an exact query in the file entry table based on the file identifier, locates the entry record uniquely corresponding to the file identifier, and performs a deletion operation on that entry record. The system performs a batch query in the file content table based on the same file identifier, retrieves all data block records corresponding to that file identifier, and performs deletion operations sequentially or in batches according to the storage order from smallest to largest. The deletion operation of the entry record and the deletion operation of all data block records are encapsulated within the same database transaction. When the transaction is committed, the entry record and the data block records are simultaneously removed from their respective tables; when the transaction is rolled back, both deletion operations are simultaneously undone. After the database transaction for the deletion operation is committed, the system returns a successful response to the external caller.

[0055] Optionally, after receiving a length query request for a target file, the file storage management system extracts the file identifier of the target file from the request message body. Using the file identifier as the query key, the system performs a precise query on a single record in the file entry table. The file entry table has an index structure based on the file identifier field, allowing the query operation to quickly locate the unique entry record via the index instead of scanning the entire table row by row. The system reads the current stored value of the file length field from this entry record and encapsulates this value as the total length of the target file in the response message, returning it to the external caller. The entire length query processing path involves only one index query on the file entry table. The query process does not access the file content table, nor does it trigger any data block-level input / output operations. The time overhead of the query operation is independent of the disk space occupied by the target file and the number of data block records already stored in the file content table.

[0056] This embodiment of the application, upon receiving a write request for a target file, divides the target file into data blocks of a predetermined block length and writes them to a file content table, recording the file identifier and storage order of each data block. The file identifier and the target file's length are also written to a file entry table, allowing file attribute information and content data to be stored separately. Upon receiving a length modification request for the target file, the target length in the length modification request is compared with the file length recorded in the file entry table. If the target length is greater than the file length, an extended data block is initialized and recorded in the file content table. If the target length is less than the file length, the data block exceeding the target length in the file content table is deleted, and the file length in the file entry table is updated to the target length. Thus, changing the file length is transformed into a partial addition or deletion of data blocks in the file content table and an update of the length information in the file entry table. It eliminates the need to regenerate and write all the data of the entire file. The amount of data involved in the change is only related to the length-changed portion, independent of the overall file size. This reduces the transmission and storage resources occupied by file length changes, enabling efficient length adjustments for large, already saved files and meeting the frequent file update needs in scenarios with massive amounts of data.

[0057] Based on the same inventive concept, this application also provides a second embodiment, referring to... Figure 2 , Figure 2 This is a flowchart illustrating the second embodiment of the data storage and management method for multimodal files in this application.

[0058] In this embodiment, the data storage management method for multimodal files includes steps S11 to S14: Step S11: Receive a read request for the target file; Step S12: Determine the target data block to be read based on the reading start position and the reading length; Step S13: Read each target data block from the file content table in storage order; Step S14: Concatenate the read target data blocks into read data and return it.

[0059] In this embodiment, after completing the writing of the target file and generating the file entry table record, the file storage management system provides file content reading functionality to external callers. A read request is an operation message sent by the external caller to the file storage management system to obtain data content within a specified range of the target file. This message carries three parameters: the file identifier of the target file, the read start position, and the read length. The read start position, in bytes, indicates which byte in the file to start reading from, and the read length, in bytes, indicates the total number of bytes to be read. Target data blocks refer to those data block records whose position range corresponding to the storage sequence number in the file content table intersects with the start-to-end range of the read request. The system calculates the range of data blocks involved based on the read start position and read length and extracts the data from it. Concatenation refers to linking the binary data segments read from multiple target data blocks sequentially in ascending order of storage to form a continuous binary data sequence. The number of bytes in this sequence equals the read length and is completely identical to the content within the corresponding range of the original file.

[0060] Specifically, after receiving a read request for a target file, the file storage management system extracts three parameter values ​​from the request message body: the file identifier, the start position, and the read length. Based on the start position and read length, the system calculates the byte range to be covered in this read operation. The starting byte number of this range is the value of the start position, and the ending byte number is the start position plus the read length minus 1. Using a predetermined block length as the standard span for each data block, the system obtains the storage sequence number of the starting data block by dividing the start byte number by the predetermined block length and rounding down, and obtains the storage sequence number of the ending data block by dividing the end byte number by the predetermined block length and rounding down. The system then retrieves all data block records falling within this range from the file content table using a joint query condition where the file identifier and storage sequence number are between the start and end numbers. The retrieved data blocks are sorted in ascending order of storage sequence and read one by one. For the starting data block, the system skips the content before the starting byte number and reads only the valid data starting from the corresponding offset. For intermediate data blocks, the system reads the entire content of the data block. For the ending data block, the system reads only up to the offset corresponding to the ending byte number within the data block. The system then concatenates the binary data segments read from each data block into a contiguous binary array in memory according to storage order. The total number of bytes in this array equals the read length value in the read request. After concatenation, the array is returned to the external caller as the read data.

[0061] Since the system described in Embodiment 2 of this application is a system used to implement the method of Embodiment 1 of this application, those skilled in the art can understand the specific structure and variations of the system based on the method described in Embodiment 1 of this application, and therefore will not be described again here. All systems used in the method of Embodiment 1 of this application fall within the scope of protection of this application.

[0062] This application provides a data storage management device for multimodal files, the device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the data storage management method for multimodal files in Embodiment 1 described above.

[0063] The following is for reference. Figure 3 This document illustrates a structural schematic diagram of a data storage management device suitable for implementing the embodiments of this application. The data storage management device for multimodal files in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 3 The data storage and management device for multimodal files shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0064] like Figure 3As shown, the multimodal file data storage management device may include a processing unit 1001 (e.g., a core processor, a graphics processor, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. The random access memory 1004 also stores various programs and data required for the operation of the multimodal file data storage management device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the multimodal file data storage management device to communicate wirelessly or wiredly with other devices to exchange data. Although a multimodal file data storage management device with various systems is shown in the figure, it should be understood that it is not required to implement or possess all the systems shown. More or fewer systems can be implemented alternatively.

[0065] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0066] The multimodal file data storage management device provided in this application, employing the multimodal file data storage management method described in the above embodiments, can solve the technical problem of low efficiency in handling large file length changes, leading to difficulties in meeting frequent file update needs. Compared with the prior art, the beneficial effects of the multimodal file data storage management device provided in this application are the same as those of the multimodal file data storage management method described in the above embodiments, and other technical features of this multimodal file data storage management device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0067] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0068] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0069] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the data storage management method for multimodal files in the above embodiments.

[0070] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, radio frequency (RF), etc., or any suitable combination thereof.

[0071] The aforementioned computer-readable storage medium may be included in a data storage and management device for multimodal files; or it may exist independently and not be assembled into a data storage and management device for multimodal files.

[0072] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by a multimodal file data storage management device, the multimodal file data storage management device: upon receiving a write request for a target file, divides the target file into data blocks according to a predetermined block length and writes them into a file content table, records the file identifier and storage order of each data block, and writes the file identifier and the file length of the target file into a file entry table; upon receiving a length modification request for the target file, compares the target length in the length modification request with the file length in the file entry table; if the target length is greater than the file length, initializes extended data blocks and records them in the file content table; if the target length is less than the file length, deletes data blocks in the file content table that exceed the target length, and updates the file length in the file entry table to the target length.

[0073] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0074] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation that may be implemented in systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0075] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0076] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described multimodal file data storage management method. This solves the technical problem of low efficiency in handling large file length changes, leading to difficulties in meeting frequent file update needs. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the multimodal file data storage management method provided in the above embodiments, and will not be repeated here.

[0077] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A method for data storage and management of multimodal files, characterized in that, The method includes the following steps: When a write request for a target file is received, the target file is divided into data blocks according to a predetermined block length and written into the file content table. The file identifier and storage order of each data block are recorded, and the file identifier and the file length of the target file are written into the file entry table. When a length modification request for the target file is received, the target length in the length modification request is compared with the file length in the file entry table; When the target length is greater than the file length, an extended data block is initialized and recorded in the file content table; when the target length is less than the file length, data blocks in the file content table that exceed the target length are deleted. Update the file length in the file entry table to the target length; Receive a read request for the target file, the read request carrying the read start position and read length; determine the target data block to be read according to the read start position and read length; read each of the target data blocks from the file content table according to the storage order; concatenate the read target data blocks into read data and return it; Receive a deletion request for the target file, the deletion request carrying the file identifier; delete the entry record corresponding to the file identifier in the file entry table; delete all the data blocks corresponding to the file identifier in the file content table.

2. The data storage and management method for multimodal files as described in claim 1, characterized in that, After the step of receiving a read request for the target file, wherein the read request carries the read start position and read length, the method further includes: Receive a length query request for the target file; The file length of the target file is obtained by querying the file entry table based on the file identifier. The obtained file length is returned as the total length of the target file.

3. The data storage and management method for multimodal files as described in claim 1, characterized in that, When receiving a write request for a target file, the steps of dividing the target file into data blocks according to a predetermined block length and writing them into a file content table, recording the file identifier and storage order of each data block, and writing the file identifier and the file length of the target file into a file entry table include: The target file is divided into at least one data block of a predetermined block length of one megabyte; Generate a corresponding cloud storage file name for each of the data blocks; The data block size of each data block and the cloud storage file name are recorded in the file content table, corresponding to the file identifier and the storage order.

4. The data storage and management method for multimodal files as described in claim 3, characterized in that, Before the step of dividing the target file into at least one data block according to the predetermined block length of one megabyte, the method further includes: Establish a path table, and record the storage paths and the storage type identifiers corresponding to each storage path in the path table; Set the storage type identifier of the target storage path used to store the target file to a first preset value; The target storage path is determined from the path table based on the first preset value; Write the target storage path and the file identifier into the file entry table, and record the file name, directory identifier, creation time, modification time and access time of the target file in the file entry table.

5. The data storage and management method for multimodal files as described in claim 1, characterized in that, When receiving a write request for a target file, the steps of dividing the target file into data blocks according to a predetermined block length and writing them into a file content table, recording the file identifier and storage order of each data block, and writing the file identifier and the file length of the target file into a file entry table include: The file operation micro-engine receives the write request and caches the data to be written corresponding to the write request in memory; The file operation micro-engine pre-reads the data blocks of the target file in the background; Following the slow write strategy, the cached data to be written is divided into data blocks and then asynchronously written to the file content table.

6. The data storage and management method for multimodal files as described in claim 5, characterized in that, Before the step of receiving the write request by the file operation microengine and caching the data to be written corresponding to the write request in memory, the method further includes: Identify the file type of the target file; When the file type is a compressed file, the target file is decompressed in memory to obtain a decompressed file; The decompressed file is divided into data blocks according to the predetermined block length and written into the file content table, and an entry record of the decompressed file is generated in the file entry table.

7. A data storage and management device for multimodal files, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the data storage management method for multimodal files as described in any one of claims 1 to 6.

8. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the data storage management method for multimodal files as described in any one of claims 1 to 6.

Images