Problem
Die materialized view ahb_hierarchy_materialized hat ~130 Indizes. Das bläht die SQLite DB auf 740 MB für 4 Formatversionen (309k Zeilen Daten, aber der Großteil des Platzes geht für Indizes drauf). Komprimiert sind es ~56 MB als 7z.
Warum das ein Problem ist
Für das Intra-FV-Diff Feature in mcp-bdew-mako (Hochfrequenz/mcp-bdew-mako#56) wollen wir historische DB-Snapshots speichern (einen pro BDEW-Veröffentlichung). Bei 740 MB pro Snapshot ist das nicht wirtschaftlich auf Azure File Share.
Auch ahb-tabellen.de nutzt die gleiche DB — beide Services würden von kleineren DBs profitieren.
Vorschlag
Review welche der ~130 Indizes tatsächlich für Query-Performance gebraucht werden und die restlichen entfernen. Die meisten idx_hierarchy_* Indizes dürften für den typischen Lesezugriff (Suche nach pruefidentifikator, format_version, format) nicht nötig sein.
Kontext
Aufgefallen bei der Analyse für Hochfrequenz/mcp-bdew-mako#56 (Intra-FV Änderungen nach Datum abfragen).
Problem
Die materialized view
ahb_hierarchy_materializedhat ~130 Indizes. Das bläht die SQLite DB auf 740 MB für 4 Formatversionen (309k Zeilen Daten, aber der Großteil des Platzes geht für Indizes drauf). Komprimiert sind es ~56 MB als 7z.Warum das ein Problem ist
Für das Intra-FV-Diff Feature in mcp-bdew-mako (Hochfrequenz/mcp-bdew-mako#56) wollen wir historische DB-Snapshots speichern (einen pro BDEW-Veröffentlichung). Bei 740 MB pro Snapshot ist das nicht wirtschaftlich auf Azure File Share.
Auch ahb-tabellen.de nutzt die gleiche DB — beide Services würden von kleineren DBs profitieren.
Vorschlag
Review welche der ~130 Indizes tatsächlich für Query-Performance gebraucht werden und die restlichen entfernen. Die meisten
idx_hierarchy_*Indizes dürften für den typischen Lesezugriff (Suche nach pruefidentifikator, format_version, format) nicht nötig sein.Kontext
Aufgefallen bei der Analyse für Hochfrequenz/mcp-bdew-mako#56 (Intra-FV Änderungen nach Datum abfragen).