Delta Compression

Whereas data deduplication targets identity, delta compression leverages similarity to achieve data reduction. The goal is to generate a patch with zeros on most positions – using XOR (⊕) – so it can be encoded more efficiently than the original data. On this route we have to tackle three primary design questions:

Reference Selection Delta compression always depends on a reference against

which the delta is computed. This reference (1) must be available during de- compression, (2) should produce as many zeros as possible, that is, its degree of similarity should be high, and (3) the process of selecting it should be fast. For the first requirement, we must ensure that the simulation node that eventually loads a checkpoint with a delta compressed page is also in possession of the corresponding reference page. Employing delta compression in a network is thus always challenging as it must only be applied within the set of pages that are local to a certain simulation node. This requires a directed simulation scheduling with a scheduling-aware reference page selection. Otherwise, decompression necessitates supplementary network accesses to retrieve missing reference pages,

which is counterproductive for reducing network traffic10. Nevertheless, for local operation as well as for the multicast network distribution proposed in § 7.3, delta compression is applicable and beneficial without having to consider the physical storage location of pages. In the following, we hence assume that all pages are available on all nodes, that is, all pages are potential candidates for reference.

The requirements (2) and (3) are tightly intertwined as finding the optimal reference page from the set of all previously seen pages is a computationally non-trivial task. Difference Engine[107] as well as Gerofi et al. [100] utilize hash tables and specifically designed hash functions which provoke hash collisions for similar page contents. We initially envisioned a similar approach, but eventually dismissed it in favor of a simpler and faster design: Under the assumption that on average pages are only marginally modified between successive checkpoints, we can generally expect the previous version of the same page to be a good candidate. This entirely eliminates the search for a reference page at the cost of a potentially lower compression ratio. Considering that we employ further data reduction mechanisms besides delta compression, we see this an appropriate tradeoff.

Decision Function Delta compression is only effective if the delta can be encoded

more efficiently than the original data. However, if changes are too extensive, the encoding efficiency can quickly shift to the detriment of delta compression. If, for example, a randomly filled page R gets cleared by the guest (i.e., all zeros), the delta will contain the original page contents, as∆ = R ⊕ 0 = R. Encoding the new (zero) page is thus more efficient than encoding the delta. In consequence, we need a decision function which determines if delta compression should be applied. The optimal decision function computes both the fully compressed version (i.e., LZ4) of the delta and the original page and compares the resulting sizes. While this gives the best compression quality it also consumes the most time. We therefore opted for a heuristic based on the Hamming distance between the page’s current and previous contents as a measure of similarity.

We calculate the Hamming distance by deriving the delta and counting the number of non-zero 64-bit words11_{. If the number exceeds a fixed threshold, we dismiss}

the delta and keep the original data. Compared to the optimal decision function, we save the costly compression of the delta or the original data, respectively. Figure 7.10 illustrates that selecting the right threshold is crucial for the quality of the heuristic. With a threshold of at most 25% non-zero words (i.e., 75% similarity) we achieve the best performance and reach between 79% and 100% conformity with the optimal decision function.

10_{Note that this is not the case for data deduplication because no additional data such as the delta} must travel the network.

11_{Although current x86 CPUs implement fast bit counting with the SSE 4.2popcntinstruction} [125], we found word-level counting to be faster and sufficiently precise.

Best Choice (8/10) L = 100 ms 0 20 40 60 80 100 0 20 40 60 80 100 Similarity Threshold [%] Decision Qualit y [%] postmark_specjbb kernel build sqlite apache encode-mp3 pybench povray phpbench idle

Figure 7.10: Choosing a similarity threshold of 75% – i.e., 25% of the delta are non-zero – gives the best average performance, where decisions match the optimal decision function in between 79% and 100% of cases. The shapes denote the maximum of each curve.

Chain Length Conceptually, there is nothing preventing a reference page to be

itself delta-encoded. However, each time SimuBoost delta-encodes a page, it also has to load the corresponding reference page during decompression. This creates additional overhead not only for checkpoint loading, but also for deduplication and delta compression, where SimuBoost accesses (compressed) pages in the database. Although a page cache as in Remus[72, 180] and others [118, 187] could generally relax the situation, it is favorable to avoid long dependency chains in the first place. We therefore limit delta compression to non-reference pages. As detailed above, we only consider the previous contents of the same page as a reference to avoid costly reference identification. In consequence, the limitation of delta compression to non-reference pages leads to a constant alteration between delta and non-delta encoding12, wasting potential for compression. We therefore lock the reference until the decision function rejects the delta compression:

R Δ R Δ R Δ R Δ R Δ Δ Δ Δ R Δ Δ Δ R Non-Zero Words (b) (a)

Figure 7.11: (a) Alternating between delta and non-delta encoding for a certain PFN. (b) The reference remains fixed until the decision function rejects delta encoding using this reference.

Delta Compression Ratio

Evaluating the compression ratio of all pages that passed data deduplication (i.e., they contain new contents), reveals that delta compression can be applied on average in between 20% and 80% of cases (see Figure 7.12a). The benchmarks again skip the first checkpoint to better reflect workload characteristics. As expected, short intervals are better suited for delta compression because they accumulate fewer changes.

In addition, Figure 7.12b shows that delta compression significantly reduces the storage size of the corresponding pages. This also confirms the effectiveness of our selection heuristic. Somewhat counterintuitively, the compression ratio for delta pages increases with the interval length. However, this is conclusive because for longer intervals only those pages with seldom and little modification remain, whereas the pages with more extensive modifications and thus less compressible deltas are already filtered out.

(a) 0 20 40 60 80 100 postmarksp ecjbb kernel

buildsqlite_apache

enco

de-mp3_pybenc

h povra y phpb enc h idle Delta Application Ratio [%] Interval Length 100 ms 1 s 8 s (b) 0 20 40 60 80 100 postmarksp ecjbb kernel

buildsqlite_apache

enco

de-mp3_pybenc

h povra y phpb enc h idle P age Size Reduction [%] Interval Length 100 ms 1 s 8 s

Figure 7.12: (a) As expected, short intervals and lightweight workloads provide higher potential for delta compression. The values relate to the remaining pages after deduplication. The black points denote results for L∈ {200, 400, 800, 2000, 4000} ms. (b) Delta compressed pages are typically at least 50% smaller than before.