Struct mz_persist_client::internal::compact::Compactor

pub struct Compactor<K, V, T, D> {
    cfg: PersistConfig,
    metrics: Arc<Metrics>,
    sender: Sender<(Instant, CompactReq<T>, Machine<K, V, T, D>, Sender<Result<ApplyMergeResult, Error>>)>,
    _phantom: PhantomData<fn() -> D>,
}

A service for performing physical and logical compaction.

This will possibly be called over RPC in the future. Physical compaction is merging adjacent batches. Logical compaction is advancing timestamps to a new since and consolidating the resulting updates.

Fields

cfg: PersistConfig

metrics: Arc<Metrics>

sender: Sender<(Instant, CompactReq<T>, Machine<K, V, T, D>, Sender<Result<ApplyMergeResult, Error>>)>

_phantom: PhantomData<fn() -> D>

Implementations

impl<K, V, T, D> Compactor<K, V, T, D>

where K: Debug + Codec, V: Debug + Codec, T: Timestamp + Lattice + Codec64 + Sync, D: Semigroup + Ord + Codec64 + Send + Sync,

pub fn new( cfg: PersistConfig, metrics: Arc<Metrics>, write_schemas: Schemas<K, V>, gc: GarbageCollector<K, V, T, D>, ) -> Self

pub fn compact_and_apply_background( &self, req: CompactReq<T>, machine: &Machine<K, V, T, D>, ) -> Option<Receiver<Result<ApplyMergeResult, Error>>>

Enqueues a CompactReq to be consumed by the compaction background task when available.

Returns a receiver that indicates when compaction has completed. The receiver can be safely dropped at any time if the caller does not wish to wait on completion.

pub(crate) async fn compact_and_apply( machine: &Machine<K, V, T, D>, req: CompactReq<T>, write_schemas: Schemas<K, V>, ) -> Result<(ApplyMergeResult, RoutineMaintenance), Error>

pub async fn compact( cfg: CompactConfig, blob: Arc<dyn Blob>, metrics: Arc<Metrics>, shard_metrics: Arc<ShardMetrics>, isolated_runtime: Arc<IsolatedRuntime>, req: CompactReq<T>, write_schemas: Schemas<K, V>, ) -> Result<CompactRes<T>, Error>

Compacts input batches in bounded memory.

The memory bound is broken into pieces: 1. in-progress work 2. fetching parts from runs 3. additional in-flight requests to Blob

1. In-progress work is bounded by 2 * BatchBuilderConfig::blob_target_size. This usage is met at two mutually exclusive moments:

• When reading in a part, we hold the columnar format in memory while writing its contents into a heap.
• When writing a part, we hold a temporary updates buffer while encoding/writing it into a columnar format for Blob.

2. When compacting runs, only 1 part from each one is held in memory at a time. Compaction will determine an appropriate number of runs to compact together given the memory bound and accounting for the reservation in (1). A minimum of 2 * BatchBuilderConfig::blob_target_size of memory is expected, to be able to at least have the capacity to compact two runs together at a time, and more runs will be compacted together if more memory is available.

3. If there is excess memory after accounting for (1) and (2), we increase the number of outstanding parts we can keep in-flight to Blob.

fn chunk_runs<'a>( ordered_runs: &'a [(&'a Description<T>, &'a RunMeta, Cow<'a, [RunPart<T>]>)], cfg: &CompactConfig, metrics: &Metrics, run_reserved_memory_bytes: usize, ) -> Vec<(Vec<(&'a Description<T>, &'a RunMeta, &'a [RunPart<T>])>, usize)>

Sorts and groups all runs from the inputs into chunks, each of which has been determined to consume no more than run_reserved_memory_bytes at a time, unless the input parts were written with a different target size than this build. Uses Self::order_runs to determine the order in which runs are selected.

async fn order_runs<'a>( req: &'a CompactReq<T>, target_order: RunOrder, blob: &'a dyn Blob, metrics: &'a Metrics, ) -> Result<Vec<(&'a Description<T>, &'a RunMeta, Cow<'a, [RunPart<T>]>)>>

With bounded memory where we cannot compact all runs/parts together, the groupings in which we select runs to compact together will affect how much we’re able to consolidate updates.

This approach orders the input runs by cycling through each batch, selecting the head element until all are consumed. It assumes that it is generally more effective to prioritize compacting runs from different batches, rather than runs from within a single batch.

ex.

       inputs                                        output
    b0 runs=[A, B]
    b1 runs=[C]                           output=[A, C, D, B, E, F]
    b2 runs=[D, E, F]

pub(crate) async fn compact_runs( cfg: &CompactConfig, shard_id: &ShardId, desc: &Description<T>, runs: Vec<(&Description<T>, &RunMeta, &[RunPart<T>])>, blob: Arc<dyn Blob>, metrics: Arc<Metrics>, shard_metrics: Arc<ShardMetrics>, isolated_runtime: Arc<IsolatedRuntime>, write_schemas: Schemas<K, V>, ) -> Result<HollowBatch<T>, Error>

Compacts runs together. If the input runs are sorted, a single run will be created as output.

Maximum possible memory usage is (# runs + 2) * [crate::PersistConfig::blob_target_size]

fn validate_req(req: &CompactReq<T>) -> Result<(), Error>

Trait Implementations

impl<K, V, T, D> Clone for Compactor<K, V, T, D>

fn clone(&self) -> Self

Returns a copy of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl<K: Debug, V: Debug, T: Debug, D: Debug> Debug for Compactor<K, V, T, D>

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.