Skip to main content

rudb_encoding/
chooser.rs

1//! How the encoder decides which candidate to keep.
2//!
3//! The encoders in [`crate::string`] and [`crate::integer`] are the work. This is the search. They
4//! are separate things and until now they were the same thing, because `encode` both offered every
5//! candidate and encoded every candidate it offered, and there was no way to have one without the
6//! other.
7//!
8//! # Why it is worth separating
9//!
10//! `cargo xtask encode` over a million rows of ClickBench `hits` says where the encoder's seconds
11//! go. String `FRONT` is 32.2 percent of them and is kept once in 142 chunks. String `FSST` is 11.2
12//! percent and is kept twice in 223. Integer `DELTA` is 10.8 percent and is kept never in 607.
13//! String `PLAIN` is 8.7 percent and is kept four times in 223. Those four are 62.9 percent of the
14//! encoder's time and they were kept seven times out of 1,195 offers.
15//!
16//! That is not a bug in any encoder. It is what an exhaustive search costs, and the search is worth
17//! something: the shapes it arrives at are five to one on `hits` and nobody wrote them down in
18//! advance. The question is how much of the search is needed, which is a question about the data
19//! and therefore a question to measure rather than argue about. F2 asks for exactly this, as "the
20//! encoder chooser as a seam, with exhaustive and sampled implementations", with the ablation being
21//! how much size the sampled one gives up.
22//!
23//! # What a chooser sees and what it does not
24//!
25//! A chooser is asked once per chunk per level of the cascade, never once per value. It is handed
26//! the values and the candidates that apply and it returns the ones worth encoding in full. It
27//! cannot invent a candidate that does not apply, so nothing it does can produce a chunk that will
28//! not decode, and the worst a bad chooser can do is pick a bigger encoding than another one would
29//! have. That is the property that makes this safe to swap.
30//!
31//! # Not a `rudb-seam` seam yet, and why
32//!
33//! `SeamId::StorageEncoder` exists and says "how a block of values is encoded on the way to disk",
34//! and this is what belongs behind it. It cannot be registered here: `rudb-seam` is rank 2 and so is
35//! this crate, so the `Strategy` supertrait every seam trait needs is not visible from here. The
36//! registry goes in `rudb-storage` at rank 5, next to the write path, and there is no write path
37//! yet. Until there is, this is a plain trait with two implementations and an ablation, which is
38//! the part that can be measured today.
39
40use crate::{integer, string};
41
42/// Which of the candidates that apply are worth encoding in full.
43///
44/// Crossed once per chunk per level of the cascade. No method here sees a single value on its own,
45/// which is the rule that lets the decision be indirect at all.
46pub trait Chooser: std::fmt::Debug + Sync {
47    /// The name that goes in a report.
48    fn name(&self) -> &'static str;
49
50    /// Which of `offered` to encode in full, for a chunk of strings at `depth`.
51    ///
52    /// `offered` is what applies, in the order the exhaustive chooser would try them. The return
53    /// has to be a subset of it and has to be non empty, because a chunk with no candidate is a
54    /// chunk that cannot be written.
55    fn narrow_strings(
56        &self,
57        values: &[&[u8]],
58        offered: &[string::Kind],
59        depth: u8,
60    ) -> Vec<string::Kind>;
61
62    /// Which of `offered` to encode in full, for a chunk of integers at `depth`.
63    fn narrow_integers(
64        &self,
65        values: &[i64],
66        offered: &[integer::Kind],
67        depth: u8,
68    ) -> Vec<integer::Kind>;
69}
70
71/// Encode every candidate that applies and keep the smallest.
72///
73/// The reference, and what `encode` has always done. It is the thing to beat rather than the thing
74/// to ship: every size this crate has ever reported came out of it, so an alternative's ablation is
75/// against this and a build that wants the old bytes exactly asks for this.
76#[derive(Debug, Clone, Copy, Default)]
77pub struct Exhaustive;
78
79/// The one of these that does not have to be constructed, since it holds nothing.
80pub const EXHAUSTIVE: Exhaustive = Exhaustive;
81
82impl Chooser for Exhaustive {
83    fn name(&self) -> &'static str {
84        "exhaustive"
85    }
86
87    fn narrow_strings(
88        &self,
89        _values: &[&[u8]],
90        offered: &[string::Kind],
91        _depth: u8,
92    ) -> Vec<string::Kind> {
93        offered.to_vec()
94    }
95
96    fn narrow_integers(
97        &self,
98        _values: &[i64],
99        offered: &[integer::Kind],
100        _depth: u8,
101    ) -> Vec<integer::Kind> {
102        offered.to_vec()
103    }
104}
105
106/// Encode every candidate on a sample, then encode only the winner on the whole chunk.
107///
108/// The bet is that a chunk of 122,880 values and a sample of 8,192 drawn from it agree about which
109/// encoding suits them, which is a bet about the data and is what the ablation settles. Where it is
110/// wrong the cost is size and never correctness, because the winner still has to apply to the whole
111/// chunk and is still encoded over all of it.
112///
113/// The sample is windows of consecutive values rather than values picked one at a time, because
114/// three of the candidates are about what a value has in common with the value before it. A sample
115/// of scattered singletons would show `FRONT` and `RLE` nothing to find and would rule them out on
116/// every column, which is the wrong answer arrived at quickly.
117///
118/// There are two guards on whether to sample at all and both of them are there because a measurement
119/// said so. A chunk with fewer values than the sample is not sampled, because encoding every
120/// candidate on something the size of the chunk and then encoding the winner on the chunk is more
121/// work than the exhaustive chooser for the same answer. A chunk holding less than a page of bytes is
122/// not sampled either, because the cost of the search scales with the bytes in the chunk and not
123/// with how many values they are spread over, so on a narrow column there is nothing to save and a
124/// sample that misses the structure gives up real size for it.
125#[derive(Debug, Clone, Copy)]
126pub struct Sampled {
127    window: usize,
128    regions: usize,
129}
130
131/// How many consecutive values one window of the sample holds.
132///
133/// The tile, which is what a bit packing kernel works in and is the smallest run of a column that
134/// has the column's local structure in it rather than one value's worth of accident.
135const WINDOW: usize = 1024;
136
137/// How many windows the sample is drawn from.
138///
139/// Eight windows of a tile each is 8,192 values, a fifteenth of a chunk. Spread across the chunk
140/// rather than taken off the front, because the front of a sorted column is one value repeated and
141/// a chooser that saw only that would pick `CONSTANT` for everything.
142const REGIONS: usize = 8;
143
144/// How few bytes a chunk can hold before sampling it is not worth the risk.
145///
146/// The ablation in #559 found `Params` at a million rows encoding to 21,782 bytes exhaustively and
147/// 128,455 bytes sampled, which is 490 percent for a column that is almost entirely empty strings.
148/// It passed the value count guard because it has a million values, and then the sample missed what
149/// little structure it had. The exhaustive search over a column that small costs almost nothing,
150/// which is the same fact from the other side, so a floor on bytes takes the whole class of column
151/// out of the sampler's hands and gives up nothing to do it.
152///
153/// 256 KiB is one page, which is the smallest unit the format moves. Below that the search is not
154/// where the time is.
155const FLOOR: usize = 256 * 1024;
156
157impl Default for Sampled {
158    fn default() -> Self {
159        Self { window: WINDOW, regions: REGIONS }
160    }
161}
162
163impl Sampled {
164    /// The default sample, which is eight windows of 1,024 values.
165    #[must_use]
166    pub fn new() -> Self {
167        Self::default()
168    }
169
170    /// A sample of a size somebody else picked, which is what the ablation sweeps.
171    #[must_use]
172    pub fn over(window: usize, regions: usize) -> Self {
173        Self { window: window.max(1), regions: regions.max(1) }
174    }
175
176    /// How many values the sample holds, which is one of the two things that decide whether
177    /// sampling is worth doing.
178    #[must_use]
179    pub fn size(self) -> usize {
180        self.window * self.regions
181    }
182
183    /// Whether a chunk of `count` values holding `bytes` bytes is worth sampling.
184    fn worth_it(self, count: usize, bytes: usize) -> bool {
185        count > self.size() && bytes >= FLOOR
186    }
187}
188
189impl Chooser for Sampled {
190    fn name(&self) -> &'static str {
191        "sampled"
192    }
193
194    fn narrow_strings(
195        &self,
196        values: &[&[u8]],
197        offered: &[string::Kind],
198        depth: u8,
199    ) -> Vec<string::Kind> {
200        let bytes = values.iter().map(|value| value.len()).sum();
201        if offered.len() < 2 || !self.worth_it(values.len(), bytes) {
202            return offered.to_vec();
203        }
204        let sample = sample(values, self.window, self.regions);
205        let mut best: Option<(string::Kind, usize)> = None;
206        for &kind in offered {
207            let Ok(Some(size)) = string::size_as(kind, &sample, depth) else {
208                continue;
209            };
210            if best.is_none_or(|(_, smallest)| size < smallest) {
211                best = Some((kind, size));
212            }
213        }
214        // Nothing applied to the sample, which should not happen and is not worth a wrong answer
215        // if it does. Hand back everything and let the exhaustive path sort it out.
216        best.map_or_else(|| offered.to_vec(), |(kind, _)| vec![kind])
217    }
218
219    fn narrow_integers(
220        &self,
221        values: &[i64],
222        offered: &[integer::Kind],
223        depth: u8,
224    ) -> Vec<integer::Kind> {
225        if offered.len() < 2 || !self.worth_it(values.len(), values.len() * 8) {
226            return offered.to_vec();
227        }
228        let sample = sample(values, self.window, self.regions);
229        let mut best: Option<(integer::Kind, usize)> = None;
230        for &kind in offered {
231            let Ok(Some(size)) = integer::size_as(kind, &sample, depth) else {
232                continue;
233            };
234            if best.is_none_or(|(_, smallest)| size < smallest) {
235                best = Some((kind, size));
236            }
237        }
238        best.map_or_else(|| offered.to_vec(), |(kind, _)| vec![kind])
239    }
240}
241
242/// `regions` windows of `window` consecutive values each, spread evenly across the input.
243///
244/// The starts are spread over the whole range a window can start at, so the first window begins at
245/// the first value and the last one ends at the last value. A chunk of 122,880 values sampled at
246/// eight windows of 1,024 gives windows starting at 0, 17,408, 34,816 and so on up to 121,856, which
247/// crosses every part of the chunk including both ends of it.
248///
249/// Spreading to the end rather than striding by `len / regions` matters on the columns this is for.
250/// A stride would leave the last stride minus one window of the chunk unsampled, and the tail of a
251/// chunk is exactly where a column that is sorted or clustered stops looking like its front.
252pub(crate) fn sample<T: Copy>(values: &[T], window: usize, regions: usize) -> Vec<T> {
253    let wanted = window * regions;
254    if values.len() <= wanted {
255        return values.to_vec();
256    }
257    let last = values.len() - window;
258    let mut out = Vec::with_capacity(wanted);
259    for region in 0..regions {
260        let from = if regions == 1 { 0 } else { region * last / (regions - 1) };
261        out.extend_from_slice(&values[from..from + window]);
262    }
263    out
264}
265
266#[cfg(test)]
267mod tests {
268    use super::{Chooser, EXHAUSTIVE, Sampled, sample};
269    use crate::{integer, string};
270
271    #[test]
272    fn a_sample_covers_the_whole_input_and_not_one_end_of_it() {
273        let values: Vec<i64> = (0..8000).collect();
274        let taken = sample(&values, 10, 4);
275        assert_eq!(taken.len(), 40);
276        assert_eq!(taken[0], 0);
277        assert_eq!(taken[10], 2663);
278        assert_eq!(taken[20], 5326);
279        assert_eq!(taken[30], 7990);
280        assert_eq!(taken[39], 7999);
281    }
282
283    #[test]
284    fn an_input_no_bigger_than_the_sample_is_the_sample() {
285        let values: Vec<i64> = (0..30).collect();
286        assert_eq!(sample(&values, 10, 4), values);
287    }
288
289    #[test]
290    fn the_last_window_does_not_run_off_the_end() {
291        // Two windows of 40 over 100 values puts the second one at 60, which is the last start that
292        // fits. Windows that overlap because there are more of them than the input has room for is
293        // fine and double counts a few values. Reading past the end is not.
294        let values: Vec<i64> = (0..100).collect();
295        let taken = sample(&values, 40, 2);
296        assert_eq!(taken.len(), 80);
297        assert_eq!(*taken.last().expect("the sample is not empty"), 99);
298    }
299
300    #[test]
301    fn the_exhaustive_chooser_hands_back_exactly_what_it_was_offered() {
302        let offered = [string::Kind::Plain, string::Kind::Fsst, string::Kind::Dict];
303        assert_eq!(EXHAUSTIVE.narrow_strings(&[b"a".as_slice()], &offered, 0), offered);
304        let offered = [integer::Kind::Packed, integer::Kind::Delta];
305        assert_eq!(EXHAUSTIVE.narrow_integers(&[1, 2], &offered, 0), offered);
306    }
307
308    #[test]
309    fn a_chunk_no_bigger_than_the_sample_is_not_narrowed_at_all() {
310        // Sampling a chunk that is smaller than the sample would encode every candidate on
311        // something the size of the chunk and then encode the winner on the chunk, which is more
312        // work than the exhaustive chooser for the same answer.
313        let sampled = Sampled::over(4, 2);
314        let values: Vec<i64> = (0..8).collect();
315        let offered = [integer::Kind::Packed, integer::Kind::Delta];
316        assert_eq!(sampled.narrow_integers(&values, &offered, 0), offered);
317    }
318
319    #[test]
320    fn a_sampled_chooser_returns_one_of_what_it_was_offered() {
321        let sampled = Sampled::over(16, 2);
322        let values: Vec<i64> = (0..40_000).map(|index| index / 200).collect();
323        let offered = [integer::Kind::Packed, integer::Kind::Rle, integer::Kind::Dict];
324        let narrowed = sampled.narrow_integers(&values, &offered, 0);
325        assert_eq!(narrowed.len(), 1);
326        assert!(offered.contains(&narrowed[0]), "{narrowed:?}");
327    }
328
329    #[test]
330    fn a_chunk_with_plenty_of_values_and_hardly_any_bytes_is_not_sampled() {
331        // ClickBench Params at a million rows: a value per row and almost all of them empty. It
332        // passes the value count guard and the exhaustive chooser encodes it in 21,782 bytes while
333        // the sampler took 128,455, so the byte floor is what keeps it out of the sampler's hands.
334        let sampled = Sampled::over(16, 2);
335        let empty = Vec::new();
336        let values: Vec<&[u8]> = vec![empty.as_slice(); 40_000];
337        let offered = [string::Kind::Plain, string::Kind::Fsst, string::Kind::Dict];
338        assert_eq!(sampled.narrow_strings(&values, &offered, 0), offered);
339    }
340}