re_datastore: component bucketing & statistics

[teh-cmc]

This PR lays out the foundations for bucketing in general, and implements bucketing for components specifically.

Importantly, it specifies, in code, what we precisely mean when we ask "what is the size of this Arrow array?" through a series of tests: look for test_arrow_estimated_size_bytes.

It also computes and exposes the first statistics out of the datastore, as we need those for splitting the buckets to start with.

Integration benchmarks:

datastore/batch/rects/insert
                        time:   [959.38 µs 962.37 µs 965.82 µs]
                        thrpt:  [10.354 Melem/s 10.391 Melem/s 10.423 Melem/s]
                 change:
                        time:   [+3.4968% +4.5792% +5.7706%] (p = 0.00 < 0.05)
                        thrpt:  [-5.4558% -4.3787% -3.3786%]
                        Performance has regressed.
Found 1 outliers among 100 measurements (1.00%)
  1 (1.00%) high severe

datastore/batch/rects/query
                        time:   [11.437 µs 11.593 µs 11.790 µs]
                        thrpt:  [8.4815 Melem/s 8.6256 Melem/s 8.7439 Melem/s]
                 change:
                        time:   [-15.342% -13.558% -11.736%] (p = 0.00 < 0.05)
                        thrpt:  [+13.297% +15.684% +18.122%]
                        Performance has improved.
Found 11 outliers among 100 measurements (11.00%)
  3 (3.00%) high mild
  8 (8.00%) high severe

(Note: benchmarks are pretty much irrelevant at the moment, but I'd like us to get into the habit of always publishing them when modifying store internals, so here ya go)

Closes #437
Partially unblocks #470

[teh-cmc]

TODO:

• add before/after benchmarks to this PR: while this is irrelevant for now, it's a good habit to start asap

[jleibs]

I think we can change this easily enough later, but do we get a significant benefit to sharing component tables across entities vs doing something like:

components: HashMap<(ComponentName, EntityPathHash), ComponentTable>,

My thought is that long-term if we're dealing with disk- or remote- backed storage we may only want to load the data relevant to a subset of the object-tree and so preserving that partitioning could be beneficial.

[teh-cmc]

I think we can change this easily enough later, but do we get a significant benefit to sharing component tables across entities

Right now we definitely don't, since deduplication is done synchronously at write-time, and you can only write to multiple timelines at once at the moment, not multiple entites.
I.e. today you get deduplication across timelines (only within the same insert, though!) but never across entities.

Now I guess the question is: do we want to offer the possibility of writing to multiple entities at once at some point, like we do for timelines?
From an SDK standpoint, it could either mean changing the API so that users can pass in a sequence of entity paths, or automagically coalesce things behind the scenes (whether in the SDK, or on the server-side... or both?!).

[jondo2010]

Being able to batch writes of multiple entities from the SDK would be great, and would involve sending multiple schema's across. This is easy using flight, but currently we already have a lot of overhead with the message serialization.

[emilk]

Niiiice

[jondo2010]

Extract into something like const COMPONENT_BUCKET_SIZE_BYTES_DEFAULT: u64

[emilk]

I disagree - that just adds one extra level of indirection imho

[teh-cmc]

I agree with @emilk here, the source of truth is the default impl

[jondo2010]

General typing question, should we use usize instead of u64 for this?

[teh-cmc]

I've been asking this myself during development and never actually addressed it...

• usize pros: no wasted space and performance on 32-bit systems
• usize cons: all code paths have to properly deal with the very real possibility of overflow, and it can get excruciatingly complex
• u64 pros: wasted space and performance on 32-bit systems
• u64 cons: just panic on overflow, everywhere, all the time

I can't really see any reason to run database software on 32-bit these days, and even if one absolutely had to_ for some obscure reason, they'd still be minority enough that it's not worth holding back every other platform for their use case.
u64 everywhere it is!

[emilk]

I mean, unless you were crazy enough to build something that was running inside of wasm32… ahem.

[teh-cmc]

Not gonna lie: completely forgot about that one lol.

But then again the expected use case is for the viewer to run in the browser, not the database (at least in 99% of cases)... right? 😬

[jondo2010]

lgtm