Module mz_persist_client::internal::trace
source · Expand description
An append-only collection of compactable update batches. The Spine below is a fork of Differential Dataflow’s Spine with minimal modifications. The original Spine code is designed for incremental (via “fuel“ing) synchronous merge of in-memory batches. Persist doesn’t want compaction to block incoming writes and, in fact, may in the future elect to push the work of compaction onto another machine entirely via RPC. As a result, we abuse the Spine code as follows:
- The normal Spine works in terms of Batch impls. A
Batch
is added to the Spine. As progress is made, the Spine will merge two batches together by: constructing a Batch::Merger, giving it bits of fuel to incrementally perform the merge (which spreads out the work, keeping latencies even), and then once it’s done fueling extracting the new single outputBatch
and discarding the inputs. - Persist instead represents a batch of blob data with a HollowBatch
pointer which contains the normal
Batch
metadata plus the keys necessary to retrieve the updates. - SpineBatch wraps
HollowBatch
and has a FuelingMerge companion (analogous toBatch::Merger
) that allows us to represent a merge as it is fueling. Normally, this would represent real incremental compaction progress, but in persist, it’s simply a bookkeeping mechanism. Once fully fueled, theFuelingMerge
is turned into a fueled SpineBatch, which to the Spine is indistinguishable from a merged batch. At this point, it is eligible for asynchronous compaction and aFueledMergeReq
is generated. - At any later point, this request may be answered via
Trace::apply_merge_res. This internally replaces the
SpineBatch
, which has no effect on the structure ofSpine
but replaces the metadata in persist’s state to point at the new batch. SpineBatch
is explictly allowed to accumulate a list ofHollowBatch
s. This decouples compaction from Spine progress and also allows us to reduce write amplification by mergingN
batches at once whereN
can be greater than 2.
Structs§
- This is a “flattened” representation of a Trace. Goals:
- Describes the state of a layer.
- Spine 🔒An append-only collection of update batches.
- An append-only collection of compactable update batches.
Enums§
- Spine
Log 🔒A log of what transitively happened during a Spine operation: e.g. FueledMergeReqs were generated.
Constants§
- The maximum number of batches per level in the spine. In practice, we probably want a larger max and a configurable soft cap, but using a stack-friendly data structure and keeping this number low makes this safer during the initial rollout.