ref(bigtable): move payload column to new "fpg"/"fpm" column families

[matt-codecov]

RFC

the COGS rollup query we have to break down our Bigtable usage is very slow in large regions (exceeds BigQuery's 6h cutoff) and has significant impact on production latencies while it's running. this PR is a structural change to our Bigtable schema that would solve those problems.

the query groups by usecase and will sum the sizes of:

• the m column and the payload (via m.size, chore(bigtable): write size to metadata #490) for objects
• the t and r columns for tombstones

the query is slow because, as i understand it, the p column is in the same column family which puts it in the same SSTable. so even though the query doesn't actually read the p column, we still have to seek past it, and our query consequently tries to monopolize the disk head for hours for a front-to-back scan.

by moving p to separate fpg/fpm families (payload versions of fg/fm), queries that don't touch p only have to seek over m/t/r which is like 1% of the data

incidentally this may improve the performance of production operations that don't touch the payload (get_metadata())

[matt-codecov]

bugbot run
@sentry review

[codecov]

Codecov Report

❌ Patch coverage is 98.94737% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 87.61%. Comparing base (0bc8c3f) to head (8dcc7e8).

Files with missing lines	Patch %	Lines
objectstore-service/src/backend/bigtable.rs	98.94%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #565      +/-   ##
==========================================
+ Coverage   87.55%   87.61%   +0.06%     
==========================================
  Files          93       93              
  Lines       14969    15059      +90     
==========================================
+ Hits        13106    13194      +88     
- Misses       1863     1865       +2     

Components	Coverage Δ
Rust Backend	92.39% <98.94%> (+0.05%)	⬆️
Rust Client	79.89% <ø> (ø)
Python Client	90.20% <ø> (ø)

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 8dcc7e8. Configure here.}

[cursor]

Orphaned payload after metadata GC

Medium Severity

Splitting payload into fpg while metadata stays in fg means the two cells are garbage-collected independently. After fg compacts away m, an orphaned fpg p cell still reads as a live object: missing metadata defaults to Manual, so expires_before ignores the past fpg timestamp and serves expired payload with default metadata.

Additional Locations (1)

• objectstore-service/src/backend/bigtable.rs#L618-L622

 

^{Reviewed by Cursor Bugbot for commit 8dcc7e8. Configure here.}

[jan-auer]

The metadata and payload columns are in the same column family to ensure they are deleted together on expiry. In the schema design guidelines, Google specifically mentions to put related columns into the same family.

If we separate them now, we have to watch very closely for unintended consequences: Performance, atomicity, consistency. This is not a simple change.

I would advise against doing this.