## 4 The Algorithm  
The original algorithm that was proposed in [21] works as follows. First, we employ a template miner, i.e., an algorithm that obtains the event types corresponding to the processed log entries. A message template is made up of constant tokens and \"\(<\)\(<\)\" wildcards that indicate the location of a parameter token. For example \"NPU Software \(<\)\(>\)\(<\)\" is the message type of the second log entry in Figure 1. Then, we assign an ID to each of the message templates, hence, a template dictionary is constructed. After this, each message is assigned to its associated template. We use the aforementioned dictionary to encode our log entries as follows. From a log line that corresponds to \(M_{ID}\) event type, and consists of \(log=(c_{1},c_{2},\ldots,c_{r})\cup(p_{1},p_{2},\ldots,p_{q})\), where \(c_{1},c_{2},\ldots,c_{r}\) are the constant tokens of the entry, and \(p_{1},p_{2},\ldots,p_{q}\) are the parameters, a new log line \(log=ID,p_{1},p_{2},\ldots,p_{q}\) is created with the use of only the parameters and the \(ID\). With this technique, we were able  
It can be seen that there are only a few event types with a large number of occurrences and plenty that appear only once or twice. Based on this principle, we decided to assign the IDs based on the repetition of the template. Events with higher frequencies would obtain a smaller ID, which can be stored on fewer bits, while higher IDs would be assigned to rare message types. The IDs are stored as integers with a 32-bit fixed size, that are later encoded using the Huffman coding. While a parameter of a message type could have more than one value, these values are usually chosen from a finite set of values. To further reduce the size of the compressed log file, we also apply the previously used method to the parameters. A dictionary is created where each parameter value has a unique ID. For example, the parameter \"CXP9029630_4\" would be stored as '1', where '1' is the ID of the token \"CXP9029630_4\". After this, the encoded log file would only contain numbers and spaces. As a final step, we also employ Huffman coding on the log file. It is a method that is commonly used in data compression and was proposed in [33]. It can be used to create a prefix-free binary code that has a minimum expected codeword length. The algorithm analyses the frequencies of the characters that appear. Commonly appearing symbols would be encoded as shorter bit strings, while uncommon characters are encoded as longer strings. For example, a common symbol such as \"a\" would be encoded as a single \"0\", while rare characters such as \"x\" would be encoded as \"11,000\". The use of Huffman coding is very profitable in our case; since our log file only contains numbers and spaces at this point, we only have to store an additionall fixed-sized Huffman codec, since the alphabet size is always 12 (numbers 0-9, space, and EOF character). The entire IDs are then encoded. There are three compression models that are widely studied. The first type is where the same model is used for all texts by the static model; this performs badly if the text that was used to build the model and the text to be compressed are different. The second type is the semi-static which works in two runs; a unique model that can be based on occurrence probabilities is built for the text, which is then used to compress the data. The last model is the adaptive model that is initially empty and updates when a new symbol is found [34]. General compressors are not suited for stream-like data, since the compression relies upon the preceding messages and the initial state. Once the template and parameter dictionaries are created, our algorithm is capable of updating them at any time when a new template or parameter is found, which means it can compress stream-like data as well. Many compression algorithms handle data on a block level. In such cases, it can happen that multiple blocks have to be decompressed to acquire the desired log entry.