[GH#549] [Pre-MVP] Storage write throttling und SQLite-Write-Budget absichern #14

New issue

Open

opened 2026-05-19 22:15:30 +02:00 by Max · 0 comments

Max commented

2026-05-19 22:15:30 +02:00

Owner

Migrated from GitHub #549
Originally created by @Bio1988 on 2026-05-17T13:24:57Z

Context

Strategy Desktop soll lokal SQLite nutzen. Bei echter iRacing-Telemetrie kann ein naiver 60-Hz-Schreibpfad schnell unnötig groß und potenziell störend werden.

Problem

Auch wenn die App stabil baut, kann SQLite unter echter Session-Last unnötig viele Writes bekommen. Das kann Datenbankwachstum, I/O-Spikes oder Race-Performance-Probleme erzeugen.

Required behavior

SQLite speichert keine kompletten 60-Hz-Rohdaten als Default.
Writes folgen der zentralen Sampling- und Delta-Policy.
StrategyState, FieldState und EngineerCalls werden sinnvoll komprimiert/persistiert.
Session/Roster-Daten werden nicht redundant pro Frame geschrieben.
DB-Größe bleibt nach längerer Session plausibel.

Tasks

Alle RecordTelemetryFrame, RecordStrategyState, RecordSession, RecordEngineerCall Pfade prüfen.
Sicherstellen, dass TelemetryFrame-Writes über SamplingPolicy laufen.
Sicherstellen, dass StrategyState-Writes nicht jedes Frame laufen.
Sicherstellen, dass Session/Roster-Daten nur bei Änderung geschrieben werden.
DB-Wachstum bei 30/60 Minuten simulierter 60-Hz-Session messen.
Testdaten oder Benchmark ergänzen.
Optional: Batch-Writes oder Transaktionsstrategie prüfen.

Definition of Done

60-Hz-Input erzeugt reduzierte SQLite-Writes.
DB-Wachstum ist dokumentiert.
Keine redundanten Session-Metadaten pro Frame.
Tests oder Benchmark zeigen die erwartete Reduktion.

Migrated from [GitHub #549](https://github.com/Bio1988/strategy-desktop/issues/549) Originally created by @Bio1988 on 2026-05-17T13:24:57Z --- ## Context Strategy Desktop soll lokal SQLite nutzen. Bei echter iRacing-Telemetrie kann ein naiver 60-Hz-Schreibpfad schnell unnötig groß und potenziell störend werden. ## Problem Auch wenn die App stabil baut, kann SQLite unter echter Session-Last unnötig viele Writes bekommen. Das kann Datenbankwachstum, I/O-Spikes oder Race-Performance-Probleme erzeugen. ## Required behavior - SQLite speichert keine kompletten 60-Hz-Rohdaten als Default. - Writes folgen der zentralen Sampling- und Delta-Policy. - StrategyState, FieldState und EngineerCalls werden sinnvoll komprimiert/persistiert. - Session/Roster-Daten werden nicht redundant pro Frame geschrieben. - DB-Größe bleibt nach längerer Session plausibel. ## Tasks - [ ] Alle `RecordTelemetryFrame`, `RecordStrategyState`, `RecordSession`, `RecordEngineerCall` Pfade prüfen. - [ ] Sicherstellen, dass TelemetryFrame-Writes über SamplingPolicy laufen. - [ ] Sicherstellen, dass StrategyState-Writes nicht jedes Frame laufen. - [ ] Sicherstellen, dass Session/Roster-Daten nur bei Änderung geschrieben werden. - [ ] DB-Wachstum bei 30/60 Minuten simulierter 60-Hz-Session messen. - [ ] Testdaten oder Benchmark ergänzen. - [ ] Optional: Batch-Writes oder Transaktionsstrategie prüfen. ## Definition of Done - 60-Hz-Input erzeugt reduzierte SQLite-Writes. - DB-Wachstum ist dokumentiert. - Keine redundanten Session-Metadaten pro Frame. - Tests oder Benchmark zeigen die erwartete Reduktion.

Max added the

labels

2026-05-19 22:15:30 +02:00