Blitzcrank: Fast Semantic Compression for In-memory Online Transaction Processing

Arithmetic coding is one of the most widely used entropy codings for lossless compression (Langdon, 1984; Cleary and Witten, 1984). Unlike Huffman coding (Moffat, 2019) that encodes symbols individually, arithmetic coding compresses the entire message into a single fraction $0\leq q<1$ with arbitrary precision. Compared to Huffman coding, arithmetic coding can achieve a higher compression factor. Arithmetic coding represents the current information as an interval, defined by two numbers (initially $[0,1)$). Each encoding step in arithmetic coding divides the current interval into smaller sub-intervals according to the probability distribution of the alphabet and selects the one that represents the next symbol to be encoded. For example, as shown in Figure 2, the probability distribution of alphabet $\{a,b,c\}$ is 0.2, 0.5, and 0.3, respectively. To encode a message “$bab$”, we divide the initial interval $[0,1)$ into three sub-intervals $[0,0.2)$, $[0.2,0.7)$, and $[0.7,1)$ and select $[0.2,0.7)$ to represent “$b$”. To encode the next symbol “$a$”, we further divide $[0.2,0.7)$ into $[0.2,0.3)$, $[0.3,0.55)$, and $[0.55,0.7)$ based on the symbol probabilities and update the current interval to $[0.2,0.3)$ which now represents “$ba$”. This process continues until we reach the end of the message and obtain the final interval $[0.22,0.27)$. We then select a fraction $q$ within the final interval that has the shortest binary representation (e.g., $q=(\text{.001111})_{2}$) as the message’s code.

Structure learning refers to the process of identifying correlations between columns to achieve better compression (Gao and Parameswaran, 2016; Ilkhechi et al., 2020; Babu et al., 2001; Davies and Moore, 1999). For example, the gender column is often highly correlated with the name column in a relation. As depicted in Figure 3, $80\%$ of Taylors are female, while $50\%$ of Alexes are male. Instead of using static probabilities (e.g., $50\%$ male and $50\%$ female) for the gender column, we model its distribution using probabilities conditioned on the name column: $P_{\text{gender}}(\text{Female}|\text{Name}=\text{Taylor})=0.8$, $P_{\text{gender}}(\text{Female}|\text{Name}=\text{Alex})=0.5$. Then, the more common tuple (Female, Taylor) is mapped to a larger interval $[0,0.56)$ with a short binary code $(.0)_{2}$, thus achieving better compression.

We use a Bayesian network (BN) to learn the best column ordering $S$ (e.g., {name, gender}) for compression. The output also includes a model set $M$, where each model is a probability distribution $P_{x}$ for column $x$ conditioned on the values of all the columns preceding $x$ in $S$. Determining the optimal ordering $S$ is an NP-hard problem (Koller and Friedman, 2009). We, therefore, use a greedy algorithm (Gao and Parameswaran, 2016) that selects the column that produces the smallest compressed size conditioned on the existing columns in $S$ for each iteration.

As in classic entropy encodings, we construct the semantic model for a discrete/categorical column by counting the frequency of each symbol (i.e., value) and computing their cumulative distribution function (CDF). Each symbol is then mapped to its corresponding probability interval on the CDF. For example, the semantic model for column $\{a,b,b,a,c,b,b,b\}$ is $\{a\leftrightarrow[0,0.25),b\leftrightarrow[0.25,0.875),c\leftrightarrow[0.875,1)\}$. Inv-Translate a code (e.g., $(.01)_{2}$) back to its symbol (e.g., “$b$”) requires a binary search to find the interval that contains the code. The logarithmic complexity slows down the decompression, especially when the number of distinct values of a categorical column is large. We, therefore, propose a constant-time algorithm for the Inv-Translate function, inspired by the alias method (Kronmal and Peterson Jr, 1979).

Constant-Time Inv-Translate. Let $\pi_{1},\pi_{2},\cdots,\pi_{N}$ be the interval length (i.e., probability) of each of the $N$ symbols. Given a code $0\leq s<1$, if $\pi_{1}=\pi_{2}=\cdots=\pi_{N}$, then $s$ belongs to the $\lfloor s\cdot N\rfloor$th interval. Therefore, the key to achieving constant-time Inv-Translate is to “create” a uniform distribution. The core idea of the algorithm is to pair the intervals so that the combined probability of each pair forms a uniform distribution.

Suppose we want to create $N$ pairs, each having a combined interval length of $1/N$. At each iteration of the algorithm, we pair the shortest interval with the longest one in the remaining intervals. When their combined interval length is greater than $1/N$, we split the longer interval in two and put the exceeded part back into the interval collection for further pairing. The algorithm terminates when there is $\leq 1$ interval left in the collection. Figure 5 shows an example where the interval for symbol “$b$” is divided and mapped to three pairs. The following theorem proves the validity of this algorithm for any discrete probability distribution.

The constant-time Inv-Translate function is presented in Algorithm 1. Given the binary mixtures $\{Y^{(j)}\}$ with parameters $\{(\alpha_{N},\beta_{N})\}$ and $\{w_{N}\}$ defined in 1, Inv-Translate first computes the index (i.e., $j=\lfloor s\cdot N\rfloor+1$) of the binary mixture $Y^{(j)}$ that contains the input code $s$. Then the function determines the code’s position within $Y^{(j)}$ and returns the corresponding symbol.

Previous semantic compression algorithms use a bisection method (Witten et al., 1987; Gao and Parameswaran, 2016) to compress continuous values such as floating-point numbers. This approach, however, generates many low-entropy intervals, thus affecting the efficiency of the subsequent Tuple Encoding. Blitzcrank, therefore, introduces a novel two-level quantization model for continuous-value columns. This model not only supports arbitrary precision to guarantee lossless compression but also leverages the distribution skew in the column for better compression.

Two-Level Quantization Model. The first-level quantization is based on an equi-width histogram of the values in a column. The goal at this level is to maximize compression by assigning larger intervals (i.e., shorter codes) to more frequent value ranges. Specifically, we divide the values into a predefined $T$ (e.g., $T=512$) disjoint value ranges, each having a bucket width of $w=(\hat{v}_{\text{max}}-\hat{v}_{\text{min}})/T$, where $\hat{v}_{\text{max}}$/$\hat{v}_{\text{min}}$ is the estimated (or obtained directly from table statistics) maximum/minimum value of the column. We then obtain the frequency of each bucket by scanning the column once, and we assign each bucket $i$ an interval $[l_{i},r_{i})$ proportional to its frequency, similar to the categorical model.

To guarantee a lossless compression (i.e., to distinguish between the values within a bucket), we apply a second-level quantization where we divide the value range of the bucket equally into $G$ segments so that the width of each segment is smaller than or equal to the column’s required precision $p$. We set $p=10^{-7}$ and $p=10^{-17}$ for the float and double types, respectively. Besides the bucket’s interval $[l_{i},r_{i})$, each segment $j$ in the bucket is assigned another interval $[l_{{\epsilon}_{j}},r_{{\epsilon}_{j}})$ with an equal length of $1/G$. If the user specifies a precision requirement for a float/double column (e.g., $2$ decimal places), we enable lossy compression by adjusting $p$ accordingly (e.g., $p=10^{-2}$) to achieve better compression.

Given a value $\hat{v}_{\text{min}}\leq v<\hat{v}_{\text{max}}$, the Translate function computes its first-level bucket index $i$ and its second-level offset $j$ according to the value-range division because $v$ can be uniquely decomposed as $i\cdot w+j\cdot p\leq v-\hat{v}_{\text{min}}<i\cdot w+(j+1)\cdot p$, where $j\cdot p<w$. $v$ is then converted into two intervals: $[l_{i},r_{i})$ and $[l_{{\epsilon}_{j}},r_{{\epsilon}_{j}})$. In cases where $v$ is an outlier (i.e., $v<\hat{v}_{\text{min}}$ or $v\geq\hat{v}_{\text{max}}$), the algorithm falls back to the slow traditional bisection method. Such a fall back has negligible impact on performance because outliers are usually rare. To recover a value (a value range $\leq$ the column precision $p$, to be precise), we invoke the Inv-Translate function twice on $[l_{i},r_{i})$ and $[l_{{\epsilon}_{j}},r_{{\epsilon}_{j}})$, respectively.

Our foundational models can be combined to compress complex attributes. We implement a string model as the example, as shown in Figure 6. It includes a prefix dictionary and a global dictionary. For words not covered by either dictionary, we use a Markov model to encode them letter-by-letter (Matthew, 2005).

Efficient Blitzcrank Integration with Intervals. The prefix dictionary compresses strings with similar prefixes and keeps a queue of the latest $K$ (e.g., $K=4$) strings. Each string is analyzed to find the index $i$ (ranging from 0 to $K-1$) of a previous string in the queue that shares the longest common prefix, and the count $h$ (an indefinite integer) of identical characters. We use a categorical model and a numeric model to estimate $i$ and $h$ distributions, respectively. Given a new string, the two models output intervals representing $i$ and $h$. This approach of interval-based representation integrates smoothly with the Blitzcrank Framework.

Adaptive Base Models for Enhanced Compression. Following the prefix dictionary, the remaining substring is split into words using delimiters like spaces and commas. This process involves two models: (1) using a numerical model to count the words in the given substring, and (2) using a categorical model to identify each delimiter. Our model can leverage the skewed distribution of word count and delimiter usage patterns for compression. For example, most sentences have 3-10 words, and the space character is the most frequent delimiter. The final technique is the global dictionary, implemented as a categorical model. It stores words that frequently occur in sentences and is used for dictionary encoding.

Besides the string model, we also design two models: one for encoding JSON collections and another for time-series column encoding, with the latter utilizing the Autoregressive Moving Average (ARMA) (Box et al., 2015). When applied to the data set Jena Climate (Mnassri, 2020), our time-series model achieved a 38% better compression factor than our standard numeric model.

We begin by investigating fast algorithms to represent and compute with probability intervals. Arithmetic coding is slow due to the many interval product operations required. Recall the example in Section 2.1, when entering a sub-interval of the current interval based on the next symbol’s probability, we need to compute a product of intervals. If we use a floating-point number to represent the probability, the interval product $\boxtimes$ is defined as:

where $0\leq l_{a}<r_{a}\leq 1$, $0\leq l_{b}<r_{b}\leq 1$. However, this design leads to floating-point calculations and the risk of floating-point underflow. An alternative is to use two integers $U,d$ to represent the probability $U/2^{d}$. In this way, checking for underflow is simply inspecting the exponent of the denominator $d$.

Integer-based Probability Intervals. In Blitzcrank, a probability is presented as a 16-bit integer $U$, which logically represents the probability $U/2^{16}$. In this paper, we use $[L,R)$, where $0\leq L,R\leq 2^{16}$ are integers, to logically represent the interval $[L/2^{16},R/2^{16})$. We choose to use 16 bits because using shorter integers increases the decoding overhead while using 32-bit or 64-bit integers must handle integer overflow during multiplication. For an interval whose length is smaller than $1/2^{16}$ (e.g. $[0,1/2^{32})$), we use the product of two or more intervals to represent it, i.e.

Inv-Translate Becomes Faster. Although the code-to-symbol in Algorithm 1 has constant time complexity, the “floor” operation slows it down. The integer-based probability can make the Inv-Translate faster, replacing the “floor” operation with bitwise operations. Algorithm 2 gives the new Inv-Translate algorithm with integer-based probability. Note that both the $\{w_{N}\}$ and the input $s$ in Algorithm 2, using the integer-based probability, are 16-bit unsigned integers. Also, $N$ is always a power of two, a condition that can be satisfied by adding placeholder symbols with a frequency of 0 if necessary.

We then introduce an algorithm to extract the code from an interval based on our integer-based probability representation and analyze the bits wasted in terms of code options. In Section 2.1, we explained that for the final interval $[0.22,0.27)$ in arithmetic coding, using just enough fractional digits to keep the number within this interval is sufficient for encoding. However, this results in variable-length codes, which can slow down decoding due to the inconsistent number of digits across intervals, requiring more branch predictions and checks (Said, 2004).

An approach to simplify the decoding process is to utilize a fixed number of bits, such as 16 bits, for encoding each interval. In this scenario, adopting integer-based probability, we define the bidirectional map** of a semantic model as follows:

where $v_{i}$ denotes a unique symbol in this model, allocated with a disjoint interval $[L_{i},R_{i})$, $L_{i}$ being the lower bound and $R_{i}$ being the upper bound of the interval, for $1\leq i\leq N$. By converting the interval $[0.22,0.27)$ to $[14418,17694)$ using integer-based probability, we can encode it using any 16-bit integer within this range. However, this method requires more than the 6 bits we use in the example of Section 2.1. In fact, for an interval $[L,R)$, the probability of the event it represents is $(R-L)/2^{16}$. Thus, its entropy is $16-\log_{2}(R-L)$ bits, and we waste $\log_{2}(R-L)$ bits if using 16 bits to encode it. Notice that we have $R-L$ code options for this interval. The selection of a specific code option itself carries information. Since any of these options can represent the interval $[L,R)$, we can use the options to represent another interval partially.

Leveraging the concept of code options, we formalize the code extraction problem as follows. Given a series of intervals $[L_{1},R_{1}),\cdots,$ $[L_{n},R_{n})$ with $n>0$ and $0\leq L_{i}<R_{i}\leq 2^{16}$, we can select a 16-bit integer $s_{i}\in[L_{i},R_{i})$ to encode each interval. Then, can we represent a distinct interval $[L^{*},R^{*})$ using a sequence $(s_{1},\cdots,s_{n})$?

Consider a special case where each interval is of length 2 (i.e., $R_{i}-L_{i}=2$), we have two encoding options per interval: either $L_{i}$ or $L_{i}+1$. These options can uniquely represent their respective intervals. Using this binary decision for each interval, we can represent parts of the distinct interval $[L^{*},R^{*})$. To fully encode $[L^{*},R^{*})$, we need a sufficient number of intervals. If we have at least 16 intervals, matching the 16 bits of $L^{*}$, complete representation is possible. The encoding rule is simple: Let the code $s_{i}=L_{i}$ if the $i$-th bit of $L^{*}$ is 0; otherwise, $s_{i}$ takes the value $L_{i}+1$. This way, the sequence $(s_{1},\cdots,s_{n})$ encodes both the series of intervals and the interval $[L^{*},R^{*})$, leveraging the binary encoding options of each interval.

Consider a general case where each interval’s length $k_{i}=R_{i}-L_{i}$ varies within the range $[1,2^{16})$. This means each interval $[L_{i},R_{i})$ has $k_{i}$ coding options: $\{L_{i},L_{i}+1,\cdots,L_{i}+(k_{i}-1)\}$. Any of these codes can uniquely represent its interval. Moreover, these codes can represent the distinct interval $[L^{*},R^{*})$ partially as well. In this case, the $i$-th interval offers a digit in a base $k_{i}$ system. With $n$ such intervals, they collectively form a mixed radix (base) numeral system (Fraenkel, 1985), with bases $\{k_{n}\}$. Assuming $\prod_{i=1}^{n}k_{i}\geq 2^{16}$, the 16-bit number $L^{*}$ can be converted into this mixed-base system as follows:

for $i=n,\cdots,1$ in a loop. The resulting value is $a_{1}a_{2}\cdots a_{n}$. Setting $s_{i}$ to $L_{i}+a_{i}$ gives a valid code, as $a_{i}<k_{i}$ ensures $L_{i}+a_{i}<R_{i}$. Hence, the sequence $(s_{1},\cdots,s_{n})$ effectively encodes both the series of intervals and the interval $[L^{*},R^{*})$.

Example: 3-Digit Mixed Radix Numeral System. Given intervals $[1,4)$, $[2,6)$, $[3,10)$, forming a 3-digit mixed radix numeral system with bases $(3,4,7)$. This system can encode up to $3\times 4\times 7=84$ distinct states. Assume we use 4 bits to encode each interval. To encode the interval $[13,14)$, we select $x=13$ from this range. Decomposing 13 with the bases $(3,4,7)$ using Equation 2 gives $13=\underline{0}\times(4\times 7)+\underline{1}\times 7+\underline{6}$, leading to the indices $(0,1,6)$. To determine $s_{1}$, we select the value at index 0 in the first interval $[1,4)$, resulting in $s_{1}=1$. Similarly, $s_{2}=3$ and $s_{3}=9$. Therefore, the encoded bit stream for the four intervals is $($0001 0011 1001$)_{2}$.

Inspired by the mixed radix numeral system introduced above, the encoding procedure of delayed coding is essentially transforming decimal numbers into mixed radix numbers. The encoding of delayed coding has two steps. First, we mark all intervals that can be represented by their former intervals’ options. An interval can be marked if and only if the current option number is larger than $\lambda$ (it takes $2^{16}$ by default). Second, for each marked interval, we convert its 16-bit code into a mixed-radix number, represented using code options of the intervals that precede it.

Step 1: Mark Intervals. In Figure 7, we illustrate the encoding process of a tuple (“b”, 1,“@”, 3) using four categorical models that convert the tuple into intervals. We use an option counter $k$, initially set to one, to track redundant information. The 1st interval provides $2^{15}$ options, updating $k$ to $2^{15}$. Next, the 2nd interval cannot be marked because the current option counter $k\leq\lambda=2^{16}$. Note that we use fixed-length code (i.e., 16-bit) to encode each interval, and the current numeral system cannot represent a 16-bit integer. The 2nd interval increases $k$ to $2^{19}$ due to its option of 16. Currently, it is enough to mark the third interval, it consumes $2^{16}$ options and updates $k=k/2^{16}=2^{3}$. The 3rd interval contributes $32769$ options, updating $k=2^{3}(2^{15}+1)$. The marking process continues; finally, the last two intervals are marked and will be transformed into mixed radix numbers, represented by their preceding intervals.

Step 2: Convert Intervals From the End. We convert each marked interval into a mixed-radix number in a recursive manner, as illustrated in Figure 8. Specifically, the last two intervals are marked in the marking step. First, we convert the rightmost interval into a mixed-radix number using bases $(k_{1},k_{2},k_{3})$. Then, the last-second interval holds the partial code of the last interval. Since the last-second interval is also marked, it is converted into a mixed-radix number with bases $(k_{1},k_{2})$. This approach highlights the necessity of processing intervals from the end.

We use a 64-bit integer $V_{\text{info}}$ to store the codes for marked intervals temporarily, starting with $V_{\text{info}}=0$. We use a loop to process each interval $[L,R)$ from the end. For each step, the decimal number to be converted is $V_{\text{info}}$, and the current interval $[L,R)$ provides $k=R-L$ options, as a base-$k$ digit. We compute the digit value $a$ and the left decimal number, using Equation 2:

Therefore, the 16-bit code for the interval $[L,R)$ is computed as $c=L+a$, i.e., we use the code options of it to store a digit value $a$. For the first processed interval, we get $a=0$ because $V_{\text{info}}=0$, but $V_{\text{info}}$ can be updated. If the interval $[L,R)$ is marked, $V_{\text{info}}=V_{\text{info}}\cdot k+c$. Otherwise, output the 16-bit code $c$ to the bit stream. The loop continues; finally, we encode the four intervals into 4 bytes.

Conversely, the decoding procedure transforms the mixed radix numerals back into decimal numbers. There are two sources of bits to decode a tuple: the bit stream or the virtual input $V_{\text{info}}$. The decoding of each symbol has three steps: (1) retrieve a 16-bit code from $V_{\text{info}}$ if the current option number $V_{\text{size}}$ is larger than $2^{16}$; otherwise from the bit stream; (2) obtain the desired symbol and its interval $[L,R)$ by calling the Inv-Translate function; (3) Update $V_{\text{info}}$ and $V_{\text{size}}$ accordingly.

The bottom part of Figure 7 shows the decoding process. We want to decode a tuple from the bit stream 0x8040 271D, at first, $V_{\text{info}}=0$ , and $V_{\text{size}}=1$. For the first attribute value, We fetch 16 bits from the bit stream, getting 0x8040. The function Inv-Translate receives it and returns the symbol “b”. We use the symbol-to-interval map** to determine its interval, resulting in $[L,R)=[2^{15},2^{16})$. Next, we compute the digit base $k=R-L=2^{15}$, and the digit number $a=\text{16bits}-L=64$. Using them, we update $V_{\text{info}}$, and $V_{\text{size}}$:

This is just the inverse formula of Equation 3. It is necessary to use $V_{\text{size}}$ to record the amount of information in $V_{\text{info}}$. For instance, with $V_{\text{info}}=1$, a $V_{\text{size}}$ of 4 results in two virtual bits $01_{2}$, while a $V_{\text{size}}$ of 8 yields three virtual bits $001_{2}$. The second interval decodes to the symbol “1”. When $V_{\text{size}}=2^{19}$ ($\geq\lambda=2^{16}$), we fetch the next 16-bit code from the virtual input, resulting in 0x0402 for the third symbol, as shown in the decoding table Loop 3 of Figure 7. This decoding process repeats for all symbols, getting (“b”, 1, “@”, “3”).

Up to this point, we assume that each symbol is represented by a single continuous interval. In this section, we modify our algorithm by relaxing this constraint to allow a symbol to be represented by the union of multiple non-continuous intervals. A non-continuous interval example is shown in Figure 5, where the symbol “$b$” is assigned to the interval $[1/8,1/3)\cup[7/12,1)$, or its integer representation $[8192,21845)\cup[38229,65536)$.

Non-continuous intervals, offering the same number of options as continuous ones but with different option positions, require slight modifications in delayed coding. Take a non-continuous interval with two segments $[L^{(1)},R^{(1)})\cup[L^{(2)},R^{(2)})$. It provides $k=(R^{(1)}-L^{(1)})+(R^{(2)}-L^{(2)})$ options. To store a number $a\in[0,k]$ using these options, we modify the selection of the 16-bit code $c$ as follows:

In other words, we choose the a-th optional code of the symbol, regardless of its integer value. Decoding involves the reverse process. For a 16-bit code within this non-continuous interval, we retrieve the stored number $a$ as follows: if $\text{16bits}\in[L^{(1)},R^{(1)})$, then $a=\text{16bits}-L^{(1)}$. Otherwise, $a=\text{16bits}-L^{(2)}+(R^{(1)}-L^{(1)})$. In other words, the 16-bit code is the $a$-th item in this non-continuous interval. This method can be extended to manage intervals with more than two segments, generating two piecewise linear functions for the computation of $c$ and $a$. Importantly, this modification has no effect on the correctness and efficiency of delayed coding, as shown in the appendix.

We show the effectiveness and optimality of delayed coding in this section. In Figure 7, there are 20 unused options (i.e., $k=20$) after the encoding, resulting in a waste of $\log_{2}20=4.32$ bits. The number of wasted bits can be bounded by $\log_{2}\lambda$ (note that we mark an interval once the number of options is larger than $\lambda$). 2 shows that as the number of intervals grows, the effectiveness of delayed coding improves, approaching the entropy.

Summary: Delayed coding uses a fixed number of bits to encode each interval. It is based on the insight that altering the redundant information in an interval does not affect its symbol retrieval. 2 reveals that delayed coding has a near-entropy compression factor with fine compression granularity.