durable-streams-rust: log-structured per-stream data store to eliminate O(N) checkpoint fdatasync

Aperta
  • Qualcosa non va?
#4,695 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
rust
Ambito
backend, data, performance

Direzione di ricerca

Inizia da packages/durable-streams-rust/CARDINALITY_CLIFF_FIX.md e segui il percorso del checkpoint WAL descritto. Definisci il layout dei segmenti, il comportamento di recupero/indicizzazione e il percorso di compattazione prima dell’implementazione. Il lavoro è completato quando la durabilità usa un numero limitato di fsync dei segmenti invece di un fdatasync per ogni stream coinvolto, mentre le letture e il recupero rimangono funzionanti.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Context

Investigation of the write cardinality cliff (throughput collapsing from ~279k ops/s at 100 streams to ~11k at 100k streams) traced the root cause to the WAL checkpoint: it makes each touched stream's data file durable via one fdatasync per stream — O(N_touched) device barriers (measured ~29s at 200k streams). That storm saturates the disk and stalls the commit-path fsyncs, which is the cliff.

Multi-lane hardware does NOT fix it: on c4d-standard-64-lssd with one physical NVMe device mounted per shard, throughput at 100k streams was flat across 1/2/4/6 lanes (~10-11k), because all shards' checkpoints fire simultaneously (shared ticker) and saturate every device at once.

Proposal

The O(N) cost exists because there is one file per stream. Move stream data into a bounded set of shared append-only segments (log-structured, like the WAL itself). Durability then costs O(segments) fsyncs, independent of stream count. Recovery replays/indexes the segments; a background compaction reclaims space via sequential rewrites + a handful of fsyncs.

  • Pro: structurally eliminates the per-stream checkpoint storm; the cliff goes away.
  • Con: per-stream reads become indexed segment lookups; requires a compaction path.

Alternatives tracked separately

  • Incremental/staggered checkpoint + --wal-checkpoint-syncfs (cheaper, amortize/coalesce the storm) — being prototyped now.
  • Reuse the existing cold tier as the durable bulk store (#COLD_TIER_ISSUE).

Findings: packages/durable-streams-rust/CARDINALITY_CLIFF_FIX.md.

Lingua principale
TypeScript
Stelle
10.4k
Fork
399
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di electric-sql/electric

Tutte le issue di electric-sql/electric

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.