Data saving method, system and storage medium for procedure program running record

Abstract

The present application relates to the technical field of data compression, and discloses a data saving method, system and storage medium for process program running records, which comprises the following steps: S1: extracting a running record text during process program running, reading the running record text, and determining fixed strings; S2: removing the fixed strings of the running record text by using a maximum matching algorithm, and retaining variable strings of the running record text; S3: constructing the variable strings and the fixed strings by using a Huffman tree to obtain Huffman coding; and S4: compressing the running record text by using the Huffman coding and saving it to a database. The present application realizes lossless compression technology, reduces the text volume of the running record, reduces the storage space occupation of the database, and relieves the data storage pressure. In addition, the present application adopts a split table storage strategy to separate the compressed coding data from the dictionary data, thereby avoiding single table data expansion and big data field operation bottlenecks.

Description

Technical Field

[0001] This invention relates to the technical field of data compression, and in particular to a method, system, and storage medium for saving process operation records. Background Technology

[0002] In manufacturing management systems (MES), the operation records of processes are stored and managed. The operation records of different product processes, regardless of their data size, are stored directly and completely in a single data table in the database in the form of raw text.

[0003] However, as production time increases and output accumulates, especially for batch production with complex operation records, directly storing large text data into a single table will result in excessive data table storage. Furthermore, due to the presence of a large number of large field records, the I / O load is high and the data throughput efficiency is low when performing CRUD operations, leading to a continuous decline in system performance and a significant increase in response time.

[0004] Chinese invention patent CN1267963A discloses a data compression device and a data recovery device. It searches for the document data to be compressed using a static dictionary and an auxiliary dictionary, and converts the character data input into the static dictionary or auxiliary dictionary into fixed-length codes to achieve compression. The problem is that the compression process of the two dictionaries is more complicated, and Huffman coding is not implemented for sorting. In contrast, this application only uses a fixed dictionary to search for fixed characters and uses different encoding rules. It uses a variable-length code composed of a fixed code and an intermediate code, and finally adds Huffman coding to compress the fixed characters and variable characters. Summary of the Invention

[0005] The purpose of this invention is to improve the problem of excessive data volume in the storage of process operation records in the prior art, and to provide a method, system and storage medium for saving process operation records.

[0006] To achieve the above-mentioned objectives, the embodiments of the present invention provide the following technical solutions:

[0007] A method for saving process operation records includes the following sub-steps:

[0008] S1: Extract the running record text of the process program, read the running record text, and determine a fixed string;

[0009] S2: Remove the fixed strings from the running record text using the maximum matching algorithm, and retain the variable strings in the running record text;

[0010] S3: Construct Huffman codes by combining variable characters and fixed strings using a Huffman tree;

[0011] S4: Use Huffman coding to compress the runtime record text and save it to the database.

[0012] Currently, the storage of process operation records faces challenges in terms of storage efficiency and flexibility. Existing methods typically use general compression algorithms (such as LZ series and GZIP) to directly compress the operation record text. However, these methods have significant shortcomings: First, general compression algorithms do not consider the structured characteristics of operation records, which consist of a large number of repetitive fixed strings (such as instructions and status codes) and a small amount of variable data (such as parameters and timestamps), resulting in low compression efficiency and high computational resource consumption. Second, in terms of fixed string recognition, existing methods mostly rely on a pre-set, complete fixed dictionary for matching. Once the process program is updated or the workstation is adjusted, resulting in the appearance of new fixed strings, the dictionary must be manually updated; otherwise, it cannot be correctly recognized, resulting in poor adaptability and high maintenance costs. Third, even after separating the fixed and variable parts, fixed-length encoding or independent dictionaries are often used for compression, failing to perform global optimization encoding based on the actual frequency of occurrence of variable characters, resulting in further encoding redundancy and limiting the limit of compression efficiency.

[0013] However, to address the problem that general compression algorithms cannot achieve differentiated and efficient compression, this invention uses the maximum matching algorithm to accurately separate fixed strings and variable characters, and combines them with a Huffman tree constructed for both for encoding. This fully exploits the structured features of the running record text, achieving a compression ratio far higher than that of general compression algorithms, significantly reducing storage space usage, and solving the shortcomings of general compression algorithms.

[0014] To address the issue that fixed strings rely entirely on a fixed dictionary for recognition, this invention, when a fixed dictionary match fails, automatically identifies a new fixed string by finding identical lines, performing character-by-character comparisons, generating a comparison string, and extracting consecutive identical positions. This eliminates the need to rely entirely on a preset dictionary, significantly improving the method's adaptability and flexibility, reducing maintenance costs, and resolving the defect that fixed strings must rely on dictionary updates for matching.

[0015] To address the issue of redundancy in fixed and variable character encoding, this invention overcomes this limitation by constructing a unified Huffman tree. It incorporates variable characters and fixed strings into the character set, constructs an optimal binary tree based on statistical frequency, assigns short codes to high-frequency characters and long codes to low-frequency characters, and achieves globally optimal average code length from an information theory perspective. This completely eliminates the redundancy caused by fixed-length encoding and separate dictionaries, thereby maximizing compression efficiency.

[0016] Compared with existing technologies, the beneficial effects of this invention are as follows: By dividing the running record text into fixed strings and variable characters, a reasonable Huffman tree can be constructed, assigning short codes to frequently occurring characters and long codes to infrequently occurring characters, achieving the optimal average code length under lossless compression conditions, reducing the text volume of running records, reducing the storage space occupied by the database, and alleviating data storage pressure; through automated inter-line comparison and fixed string extraction mechanisms, it adapts to changes in process procedures, eliminating the need for frequent manual updates to the fixed dictionary, and reducing the long-term maintenance cost of the system; by adopting a table-based storage strategy, the compressed encoded data is separated from the dictionary data, avoiding the bottleneck of single-table data expansion and large data field operations; storing the compressed encoded data and the record dictionary (fixed strings, variable characters, and their Huffman codes) separately not only compresses the data but also forms an efficient encoding and decoding system, facilitating subsequent data retrieval, transmission, and decoding recovery.

[0017] Furthermore, a method for saving process operation records, wherein step S1 includes the following sub-steps:

[0018] S11: Establish a fixed vocabulary for different workstations, match the string in each row with the fixed words in the fixed vocabulary, and when a string in a row is found to match a fixed word, determine that string as the fixed string for that row;

[0019] S12: If no string in a row matches a fixed word in the fixed dictionary, search for rows with the same string and compare them one by one in pairs.

[0020] S13: Starting from the first character of each line, when the characters at the same position in the two lines are the same, the position is recorded as 1; otherwise, the position is recorded as 0. When the lengths of the two lines are different, empty positions are padded with 0 to obtain the comparison string for each group.

[0021] S14: Add the same positions of the comparison strings in each group, extract the consecutive strings whose values ​​are the same as the number of rows in the string, remove special characters and spaces, and obtain a fixed string.

[0022] The above scheme constructs a two-stage fixed string recognition mechanism that combines matching with a pre-set fixed dictionary with position-by-position comparison within the same line. This solves the problem of existing methods relying entirely on a pre-set dictionary and being unable to adaptively recognize newly added or unrecorded fixed strings, resulting in poor system flexibility and high maintenance costs. By comparing the same line, marking bits, and extracting consecutive identical bits, the mechanism achieves automatic discovery and accurate location of fixed strings, effectively overcoming the bottleneck of having to manually update the dictionary due to process updates. This significantly improves the method's adaptability and robustness in real industrial scenarios, laying a solid foundation for efficient data compression in the future.

[0023] Furthermore, in a method for saving data of process operation records, step S2 includes the following sub-steps:

[0024] S21: Compose a vocabulary from fixed strings and convert the running record text into word-segmented text;

[0025] S22: Use the forward maximum matching algorithm to match several consecutive characters in the segmented text with a fixed string in the vocabulary from left to right;

[0026] S23: If a match is successful, remove the fixed string from the running record text until all fixed strings are removed;

[0027] S24: After removing all fixed strings, retain the numbers, letters, and symbols in the running log text, and set them as variable characters individually.

[0028] The above scheme constructs a precise fixed string separation mechanism based on the forward maximum matching algorithm, which solves the problems of large compression redundancy and low efficiency caused by the inability of existing general compression methods to effectively distinguish between fixed content and variable data. By integrating fixed strings into a dedicated vocabulary and using forward maximum matching for scanning and matching, the longest fixed string is identified first and completely stripped, achieving efficient deconstruction of the text structure. By setting the remaining characters after stripping as individual variable characters, accurate input is provided for the subsequent construction of frequency statistical models using Huffman coding. Under the premise of ensuring information losslessness, the redundancy caused by fixed strings is eliminated to the greatest extent.

[0029] Furthermore, in a method for saving data of process operation records, step S3 includes the following sub-steps:

[0030] S31: Count the frequency of occurrence of variable characters and construct a Huffman tree by arranging them in ascending order;

[0031] S32: Add the fixed string to the bottom node of the Huffman tree to generate a new Huffman tree;

[0032] S33: Find the node paths in the Huffman tree to obtain the Huffman codes for variable characters and fixed strings.

[0033] The above scheme constructs an integrated Huffman tree structure for variable characters and fixed strings, solving the problems of coding redundancy and limited compression efficiency caused by the separate processing of fixed content and variable data in structured text by traditional compression methods. By first constructing an initial Huffman tree based on the frequency of variable characters, and then adding the fixed string as a whole unit to the bottom layer of the tree, a globally optimal code is finally generated. This integrates discrete variable characters and complete fixed strings into the same coding system, allocating short codes for high-frequency variable characters and ensuring that the fixed string as a whole also obtains the optimal code. This overcomes the shortcomings of traditional compression methods that repeatedly encode fixed strings or use fixed-length codes, achieving optimal allocation of coding space, significantly improving overall compression efficiency, and ensuring the uniformity of the coding structure and the reliability of decoding.

[0034] Furthermore, a method for saving process operation records, wherein step S31 includes the following sub-steps:

[0035] S311: Assemble variable characters into a character set, and find the two variable characters with the lowest frequency of occurrence in the character set;

[0036] S312: Construct a new node using the two variable characters with the lowest frequency of occurrence. The frequency of the new node is the sum of the frequencies of the two variable characters.

[0037] S313: Add the new node to the character set and remove the two variable characters under the new node in the character set;

[0038] S314: Repeat steps S311-S313 until no new nodes exist in the character set.

[0039] In the above scheme, a frequency-sorted Huffman algorithm is constructed to solve the problems of low compression efficiency and high computational resource consumption in traditional encoding methods. By iteratively executing the operation process of selecting the minimum frequency node, constructing the parent node, and updating the character set, it is always ensured that the two nodes with the lowest frequency in the current character set are merged each time, following the core principle of the Huffman algorithm. This ensures that the final generated binary tree has an optimal structure. By accurately statistically analyzing and responding to the frequency of variable characters, short codes are automatically generated for high-frequency characters, and long codes are assigned to low-frequency characters, thus maximizing the encoding efficiency of the variable character part at the algorithm level.

[0040] Furthermore, in a method for saving data of process operation records, step S33 includes the following sub-steps:

[0041] S331: Starting from the root node of the Huffman tree, the leftward direction is 0 and the rightward direction is 1, until the leaf node of the character is reached, to obtain the path of each character;

[0042] S332: Obtain the Huffman encoding of fixed strings and variable characters through the path of each character.

[0043] The above scheme establishes a unified encoding generation mechanism based on tree path traversal, solving the problems of inconsistent encoding rules and high decoding ambiguity risk in traditional encoding methods when processing single characters and fixed strings. By traversing left and right paths starting from the root node, the tree structure is transformed into a binary encoding sequence. Leveraging the inherent characteristic of Huffman trees as optimal prefix code trees, a unique shortest prefix-free code is generated for all data units, ensuring that no code is a prefix of another code. This fundamentally eliminates ambiguity in the decoding process and guarantees absolute reliability for data compression and decompression.

[0044] Furthermore, a method for saving process program execution records involves using Huffman coding to encode each line of execution record according to a fixed string and a variable character when the execution record text is saved, saving the encoded execution record data to an encoding table, and saving the fixed string, the variable character and its corresponding Huffman code to a dictionary table.

[0045] The above scheme establishes an architecture that separates the storage of encoded data and dictionary data, solving the problems of low retrieval efficiency and high storage redundancy caused by the mixed storage of encoded information and compressed data in traditional compression methods. By storing the compressed binary stream in the encoding table and the complete Huffman coding mapping relationship in the dictionary table, the logical separation of compressed data and decompression key is achieved. The separate storage architecture avoids the repeated storage of encoded information and eliminates the storage redundancy caused by the repeated occurrence of fixed strings in traditional methods.

[0046] Furthermore, a method for saving process operation records involves using dictionary codes to decode the operation record data in the encoding table and restoring each line of operation record text when the operation record text is viewed.

[0047] Through the above technical solution, an instant decoding mechanism based on dictionary mapping was established, which solved the problems of high resource consumption and slow response speed caused by the need for overall decompression during data retrieval in traditional compression methods. Through the collaborative working mechanism of dictionary table and encoding table, the encoding mapping relationship in dictionary table can be directly used to accurately decode specific encoded data when viewing the running record.

[0048] A data storage system for process program execution records includes a memory and a processor. The memory stores a computer program, and the processor is configured to run the computer program to execute the data storage method for the process program execution records.

[0049] A computer-readable storage medium storing instructions, wherein when a computer executes the instructions, the computer executes the process program execution record data saving method. Attached Figure Description

[0050] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0051] Figure 1 A flowchart illustrating a method for saving data records of a process procedure.

[0052] Figure 2 This is a flowchart for extracting a fixed string.

[0053] Figure 3 This is a schematic diagram of a Huffman tree in an embodiment.

[0054] Figure 4 This is a schematic diagram of the new Huffman tree in the embodiment.

[0055] Figure 5 This is a schematic diagram of the path of the Huffman node in the embodiment. Detailed Implementation

[0056] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0057] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this invention, the terms "first," "second," etc., are used only for distinguishing descriptions and should not be construed as indicating or implying relative importance, or suggesting any such actual relationship or order between these entities or operations. Additionally, the terms "connected," "linked," etc., can refer to a direct connection between elements or an indirect connection via other elements.

[0058] This invention is achieved through the following technical solutions, such as... Figure 1 As shown, a method for saving process operation records includes the following sub-steps:

[0059] S1: Extract the running record text of the process program, read the running record text, and determine a fixed string.

[0060] In this embodiment, the runtime log text is set as follows:

[0061] Time: 2025-06-17 01:57:53

[0062] Operator: 3141

[0063] SWID: 01-000D-06-00-36

[0064] Station: 4IN1_Test

[0065] LotID: E250415R-034

[0066] PN: A000292

[0067] It is important to note that the runtime log text is divided into fixed strings and variable strings. Usually, adding spaces before and after a meaningful string in the program makes it easier to read and separate fixed strings from variable strings, such as "Time:", "Operator:", "SWID:", "Station:", "LotID:", "PN:".

[0068] Specifically, S1 includes the following sub-steps:

[0069] S11: Establish a fixed vocabulary for different workstations, match the string in each row with the fixed words in the fixed vocabulary, and when a string in a row is found to match a fixed word, determine that string as the fixed string for that row;

[0070] S12: If no string in a row matches a fixed word in the fixed dictionary, search for rows with the same string and compare them one by one in pairs.

[0071] S13: Starting from the first character of each line, when the characters at the same position in the two lines are the same, the position is recorded as 1; otherwise, the position is recorded as 0. When the lengths of the two lines are different, empty positions are padded with 0 to obtain the comparison string for each group.

[0072] S14: Add the same positions of the comparison strings in each group, extract the consecutive strings whose values ​​are the same as the number of rows in the string, remove special characters and spaces, and obtain a fixed string.

[0073] It should be noted that in the running log, each line generally contains only one fixed character.

[0074] In the example, lines with the same string are assumed to be str1="PowerInit = 3463.70uW", str2="PowerInit = 1882.90uW", and str3="PowerInit = 4321.45uW".

[0075] Step 1: Compare each pair of lines, i.e., compare str1, str2, and str3. Starting from the first character, if the characters in the same position are the same, write 1 for that position; otherwise, write 0 for that position. If the lengths are inconsistent, pad the empty spaces with 0s until the maximum length is reached.

[0076] Step 2: Obtain three comparison strings:

[0077] "1111111111110000101"

[0078] "111111111110000100"

[0079] “1111111111110000100”;

[0080] Step 3: Add the common positions of the three comparison strings to get: "3333333333330000301";

[0081] Step 4: Extract the consecutive strings at positions equal to 3: "PowerInit = ".

[0082] Step 5: Remove special characters (such as =, \, etc.) and spaces to obtain the fixed string: "PowerInit".

[0083] like Figure 2 As shown, S2: The fixed strings in the running record text are removed by the maximum matching algorithm, and the variable strings in the running record text are retained;

[0084] S21: Compose a vocabulary from fixed strings and convert the running record text into word-segmented text;

[0085] S22: Use the forward maximum matching algorithm to match several consecutive characters in the segmented text with a fixed string in the vocabulary from left to right;

[0086] S23: If the match is successful, remove the fixed string from the running record text until all fixed strings are removed;

[0087] S24: After removing all fixed strings, retain the numbers, letters, and symbols in the running record text and set each one as a variable character.

[0088] In the embodiment, assume the segmented text is content[] = {"计", "算", "语", "言", "学", "课", "程", "有", "意", "思"}; vocabulary list And dict[] = {"计算", "计算语言学", "课程", "有", "意思"}

[0089] Step 1: Starting from content[1], when scanning content[2], it is found that "计算" is a word in the word list dict[], but it cannot be segmented. It is necessary to check whether the subsequent words match through the maximum matching algorithm and continue scanning;

[0090] Step 2: Continuing to scan content[3], it is found that "计算语" is not a word in dict[], because "计算语" is the prefix , continue scanning;

[0091] Step 3: Scanning content[4], it is found that "计算语言" is not a word in dict[], because "计算语言" is a prefix of dict[2], continue scanning:

[0092] Step 4: Scanning content[5], it is found that "计算语言学" is a word in dict[] but cannot be segmented. It is necessary to check whether the subsequent words match through the maximum matching algorithm and continue scanning;

[0093] Step 5: When scanning content[6], it is found that "计算语言学课" is not a word in dict[] nor a prefix of dict[], so the largest word scanned previously is segmented as Computational Linguistics .

[0094] In the above embodiment, after removing the fixed strings from the running record text, the remaining text is as follows:

[0095] 2025-06-17 01:57:53 3141

[0097] 01-000D-06-00-36

[0098] 4IN1_Test

[0099] E250415R-034

[0100] A000292.

[0101] S3: Construct the variable characters and fixed strings using a Huffman tree to obtain the Huffman code.

[0102] Specifically, S3 includes the following sub-steps:

[0103] S31: Count the frequency of occurrence of variable characters and construct a Huffman tree by arranging them in ascending order.

[0104] More specifically, S31 includes the following sub-steps:

[0105] S311: Assemble variable characters into a character set, and find the two variable characters with the lowest frequency of occurrence in the character set;

[0106] S312: Construct a new node using the two variable characters with the lowest frequency of occurrence. The frequency of the new node is the sum of the frequencies of the two variable characters.

[0107] S313: Add the new node to the character set and remove the two variable characters under the new node in the character set;

[0108] S314: Repeat steps S311-S313 until no new nodes exist in the character set.

[0109] In the embodiments, such as Figure 3 As shown, A and 9, E and R, N and "_", e and T, D and I, s and t appear twice in total. Create a new node 2 above each of them. Delete A and 9, E and R, N and "_", e and T, D and I, s and t from the character set. Make A and 9, E and R, N and "_", e and T, D and I, s and t the bottom-level nodes of the tree.

[0110] After the bottom-level nodes are constructed, construct the second-to-last level nodes: new nodes 2 and 7, new node 2 and ":", and new node 2 and 2, which appear a total of 4 times. Construct new node 4 above them, new node 2 and \0 (a space), which appear a total of 3 times. Construct new node 3 above them, and new nodes 2 and 6, which appear a total of 5 times. Construct new node 5 above them. Delete 2 and 7, 2 and ":", 2 and 2, 2 and \0, and 2 and 6 from the string. Make 2 and 7, 2 and ":", 2 and 2, 2 and \0, and 2 and 6 the second-to-last level nodes of the tree.

[0111] After the second-to-last level of nodes is constructed, the third-to-last level of nodes is constructed. New nodes 4 and 4, and 4 and 3 appear a total of 8 times. New node 8 is constructed above them. New nodes 3 and 4 appear a total of 7 times. New node 7 is constructed above them. New nodes 5 and 5 appear a total of 10 times. New node 10 is constructed above them. 4 and 4, 4 and 3, 3 and 4, 5 and 5 are deleted from the string. 4 and 4, 4 and 3, 3 and 4, 5 and 5 are used as the third-to-last level of nodes in the tree.

[0112] After the third-to-last level of nodes is constructed, the fourth-to-last level of nodes is constructed. "-" and new node 8, 1 and new node 8 appear a total of 15 times. A new node 15 is constructed above them. New nodes 7 and 2 appear a total of 12 times. A new node 12 is constructed above them. New nodes 10 and 0 appear a total of 25 times. A new node 25 is constructed above them. "-" and 8, 1 and 8, 7 and 2, 10 and 0 are deleted from the string. "-" and 8, 1 and 8, 7 and 2, 10 and 0 are used as the fourth-to-last level of nodes in the tree.

[0113] After the fourth-to-last level of nodes in the tree is constructed, the fifth-to-last level of nodes is constructed. New nodes 15 and 12 appear a total of 27 times, so new node 27 is constructed above them. New nodes 15 and 25 appear a total of 40 times, so new node 40 is constructed above them. 15 and 12, 15 and 25 are deleted from the string, and 15 and 12, 15 and 25 are used as the fifth-to-last level of nodes in the tree.

[0114] After the fifth-to-last level of nodes in the tree is constructed, the sixth-to-last level of nodes is constructed, with new nodes 27 and 40 appearing a total of 67 times. A new node 67 is constructed above it. 27 and 40 are deleted from the string. 27 and 40 are the sixth-to-last level nodes in the tree. Only the new node 67 remains in the string. Let 67 be the vertex of the tree, and delete 67 from the string.

[0115] S32: Add the fixed string to the bottom node of the Huffman tree to generate a new Huffman tree.

[0116] In the embodiments, such as Figure 4 As shown, fixed strings have a low frequency of occurrence but a large character length, so they are placed on the bottom-level node. Therefore, “Time:”, “Operator:”, “SWID:”, “Station:”, “LotID:”, and “PN:” are placed on the bottom-level node and their occurrence frequency is set to 0 to reduce the length of the Huffman code.

[0117] S33: Find the node paths in the Huffman tree to obtain the Huffman codes for variable characters and fixed strings.

[0118] Specifically, S33 includes the following sub-steps:

[0119] S331: Starting from the root node of the Huffman tree, the leftward direction is 0 and the rightward direction is 1, until the leaf node of the character is reached, to obtain the path of each character;

[0120] S332: Obtain the Huffman encoding of fixed strings and variable characters through the path of each character.

[0121] In the embodiments, such as Figure 5 As shown, the encoding of the first line of text string is as follows:

[0122] "Time:": 00100110

[0123] “0”: 111

[0124] "2": 011

[0125] "5": 1101

[0126] "-": 000

[0127] "6": 11001

[0128] "1": 100

[0129] "7": 00101

[0130] “:”:00111

[0131] “3”: 1011

[0132] “\0”: 01001.

[0133] S4: Use Huffman coding to compress the runtime record text and save it to the database.

[0134] When the running record text is saved, Huffman coding is used to encode each line of running record according to a fixed string and a variable character. The encoded running record data is saved to the encoding table, and the fixed string, variable character and their corresponding Huffman code are saved to the dictionary table.

[0135] When the runtime log text is viewed, the runtime log data in the encoding table is decoded using dictionary codes to restore each line of runtime log text.

[0136] Embodiments of this application provide a data storage system for process program execution records, including a memory and a processor. The memory stores a computer program, and the processor is configured to run the computer program to execute the data storage method for the process program execution records.

[0137] Embodiments of this application provide a computer-readable storage medium storing instructions, which, when executed by a computer, enable the computer to perform a method for saving data recordings of process program execution.

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

Claims

1. A method for saving data of process operation records, characterized in that, Includes the following sub-steps: S1: Extract the running record text of the process program, read the running record text, and determine a fixed string; S2: Remove the fixed strings from the running record text using the maximum matching algorithm, and retain the variable strings in the running record text; S3: Construct Huffman codes by combining variable characters and fixed strings using a Huffman tree; S4: Compress the execution log text using Huffman coding and save it to the database; S1 includes the following sub-steps: S11: Establish a fixed vocabulary for different workstations, match the string in each row with the fixed words in the fixed vocabulary, and when a string in a row is found to match a fixed word, determine that string as the fixed string for that row; S12: If no string in a row matches a fixed word in the fixed dictionary, search for rows with the same string and compare them one by one in pairs. S13: Starting from the first character of each line, when the characters at the same position in the two lines are the same, the position is recorded as 1; otherwise, the position is recorded as 0. When the lengths of the two lines are different, empty positions are padded with 0 to obtain the comparison string for each group. S14: Add the same positions of the comparison strings in each group, extract the consecutive strings whose values ​​are the same row numbers of the strings, remove special characters and spaces, and obtain a fixed string; S3 includes the following sub-steps: S31: Count the frequency of occurrence of variable characters and construct a Huffman tree by arranging them in ascending order; S32: Add the fixed string to the bottom node of the Huffman tree to generate a new Huffman tree; S33: Find the node paths in the Huffman tree to obtain the Huffman codes for variable characters and fixed strings.

2. The data storage method for process program execution records according to claim 1, characterized in that, S2 includes the following sub-steps: S21: Compose a vocabulary from fixed strings and convert the running record text into word-segmented text; S22: Use the forward maximum matching algorithm to match several consecutive characters in the segmented text with a fixed string in the vocabulary from left to right; S23: If a match is successful, remove the fixed string from the running record text until all fixed strings are removed; S24: After removing all fixed strings, retain the numbers, letters, and symbols in the running log text, and set them as variable characters individually.

3. The data storage method for process program execution records according to claim 1, characterized in that, S31 includes the following sub-steps: S311: Assemble variable characters into a character set, and find the two variable characters with the lowest frequency of occurrence in the character set; S312: Construct a new node using the two variable characters with the lowest frequency of occurrence. The frequency of the new node is the sum of the frequencies of the two variable characters. S313: Add the new node to the character set and remove the two variable characters under the new node in the character set; S314: Repeat steps S311-S313 until no new nodes exist in the character set.

4. The data storage method for process program execution records according to claim 1, characterized in that, S33 includes the following sub-steps: S331: Starting from the root node of the Huffman tree, the leftward direction is 0 and the rightward direction is 1, until the leaf node of the character is reached, to obtain the path of each character; S332: Obtain the Huffman encoding of fixed strings and variable characters through the path of each character.

5. The data storage method for process program execution records according to claim 1, characterized in that, When the running record text is saved, Huffman coding is used to encode each line of running record according to a fixed string and a variable character. The encoded running record data is saved to the encoding table, and the fixed string, variable character and their corresponding Huffman code are saved to the dictionary table.

6. The method for saving data of process program execution records according to claim 5, characterized in that, When the runtime log text is viewed, the runtime log data in the encoding table is decoded using dictionary codes to restore each line of runtime log text.

7. A data storage system for process operation records, characterized in that, It includes a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to execute the data storage method for process program execution records as described in any one of claims 1-6.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed by a computer, enable the computer to perform the data saving method for process program execution records as described in any one of claims 1-6.

Images