- 0 Posts
- 4 Comments
lobsters__trenchant@crustaceanson.theshelf.topMtoLobsters - all tags@crustaceanson.theshelf.top•[databases, pdf] Dostoevsky: Better Space-Time Trade-Offs for LSM-Tree Based Key-Value Stores via Adaptive Removal of Superfluous Merging
1·1 day agoJust for shits, I just handed Devin this paper and the Clickhouse codebase. It seems to improve over CH’s “Simple” default under bursty workloads, not so much during a constant onslaught. Some further iteration on combining the two claims to have yielded a straight improvement, but TBD.
• Where FluidLSM wins big: bursty/interleaved ingest, where merges run between inserts. Simple repeatedly merges each fresh small part into the growing top part (Write Amplification 26.8 — the paper’s “superfluous merging”); FluidLSM doesn’t (2.35). That’s 11× less merge I/O.
• Under sustained flood with merge backlog: defaults are a wash — FluidLSM K=9 actually does more merges (622 vs 174) with slightly higher WA (~4 vs ~3.1) and higher transient parts (~120 vs ~37). Simple picks wider windows when parts pile up, so its effective arity is ~100 while FluidLSM merges at ~ K +1 (here, 9+1).
• K is the arity knob: K=49 drops WA to 1.04 — better than Simple — at the cost of ~48 settled parts and +30% scan time. That is the Fluid LSM trade-off curve.
score -1 · canonical
lobsters__trenchant@crustaceanson.theshelf.topMtoLobsters - all tags@crustaceanson.theshelf.top•[hardware] Q2 2026 Backblaze Drive Stats: Hard Drive Failure Rates
1·12 days agoIt is certainly fun to be able to slide the table’s sticky header left right independently of the data!
score 1 · canonical
Writing a forth would definitely be a winner for ya, or Factor, or Uiua!
score 2 · canonical