ref(metrics): Implement more efficient sorted distributions

[jan-auer]

Implements a dedicated type for representing distributions in memory. Internally, it uses a B-Tree map to store values deduplicated with counters for how often they occur. In the serialized payloads, it is still a flat list of values.

---

[jan-auer]

We still need to perform a benchmark to decide between the following two approaches:

1. (current) Keep duplicates also in the set. This makes lookups slightly easier and avoids rebalancing the trees when removing values. However, it creates a theoretical worst case when a large number of values is inserted exactly twice, since they now need 3 slots (key, key, count).

2. Remove duplicates from the set. This can make the lookup code more straight forward, but requires shrinking the set on insert.

[untitaker]

this looks ok, some ideas:

• if singles ever gets too large we may want to consider rounding values such that we can have more duplicates
• singles could be some sort of bloom filter contraption

one unsolved question:

• may want to add some tests for NaN since those can have different bit reprs and I am not sure if float_ord gets equality right. The code looks like it does... something but there are no testcases on what happens with different nans. Maybe I am missing something and nans are normalized somewhere else. The other option is to drop nans on the floor.

[untitaker]

do we ever want to use platform-specific integer sizes here? seems like almost all uses of usize in this file should be u64

[jan-auer]

You're right. I chose usize since I thought it doesn't matter and since we can't handle more than usize individual values in one bucket anyway. Will change to u64 or maybe even u32 to clarify intent, however.

[jjbayer]

Should we declare the iterators before DistributionValue?

[jan-auer]

Thanks for the review, @untitaker!

• if singles ever gets too large we may want to consider rounding values such that we can have more duplicates

We can consider of lowering precision, although I'm not sure what reasonable thresholds should be. At the time, we're committed to keeping full precision in Relay.

• singles could be some sort of bloom filter contraption

This is the form of lossy aggregation we currently leave to storage. Potentially, we add this to Relay in future, too, although then using the same sketching algorithm also used in storage.

may want to add some tests for NaN since those can have different bit reprs and I am not sure if float_ord gets equality right.

Good point, reporting NaN doesn't make sense on any of our metrics. @jjbayer this is something we can catch at an earlier stage before merging into the aggregation.

[jan-auer]

We removed the split between singles and duplicates now. Original implementation was commented with this:

Internally, it uses a B-Tree set and a B-Tree map for storing values:

• Single values are stored in the set. This optimizes for cases where values are spread out far and there is a low duplication ratio.
• Duplicate values are stored in the map with a counter. The second time a value is inserted, it remains in the set but is added to the map with a counter of 2. From there on, the counter is incremented.

Runtime complexity for inserts and lookups is slightly worse than a plain B-Tree map with 2 * log n as compared to log n. Space complexity is better on average, significantly for sparse distributions, with the worst case being every element is inserted exactly twice.

In benchmarking, we noticed that there is only a marginal gain for sparse values with no duplication, but a massive penalty for dense distributions. Using these maps, we can beat a raw BTreeMap by roughly 20% in uncommon cases, but not without side effects. Therefore, keeping it simple is better here.