Überarbeiten der Datenstrukturen und Datenreduktion in Datenbank notwendig!

[ralferlebach]

Bereits in der kurzen Zeit unseres Testbetriebes zeigt sich, dass die local_catquiz-Tabellen bereits nach wenigen hundert Testversuchen bereits mehrer Megabyte groß sind.

Für mittelgroße Moodle-Instanzen, die unser Plugin einsetzen, würde dies innerhalb kürzester Zeit Datenbankgrößen von mehreren Terabyte erfordern.

Ich schätze, dass ca. 90 Prozent der Im Moment gespeicherten Daten sind redundant, werden nicht benötigt oder sind durch das verwendete noSQL-Format bedingt und könnten grundsätzlich durch die Nutzung von relationalen Datenbankstrukturen vermieden werden (z.B. Variablennamen oder im String gespeicherte numerische Werte).

Im Moment sehe ich durch diese "convenient storage policy" mittels var dump in ein JSON die langfistige Einsatzfähigkeit extrem gefährdet und schlage vor, dass wir uns am Freitag oder nächste Woche Montag zusammensetzen und gemeinsam überlegen, welche Daten gespeichert werden müssen, welche als Redunanz evtl. noch in der Entwicklungsphase (in einer extra-Column) mitgeschleift werden sollen und welche Werte grundsätzlich in relationaler SQL-Struktur abgelegt werden sollten, damit der Datenberg bestmöglich reduziert, aber die Nachvollziehbarkeit (auch für außenstehende Entwickler oder Anwender) erhalten wird.

[eynimeni]

• [ ] checken welche daten reduziert werden können
• [ ] dokumentieren
• [ ] columnnames nicht "json" sondern sinnvoll zB results
• [ ] angezeigtes feedback soll wiederstellherbar sein - verwendetes datenarray speichern
• [ ] evt. sind nicht die gesamten quizsettings nach rendering von attempt nicht mehr nötig ?
• [ ] speicherung von infos zu fragen ?

[davidszkiba]

Einiges davon ist schon in #437 geschehen, das ist aber noch nicht in der aktuellen release (rc-8) enthalten. Quiz settings werden danach nicht mehr in der attempts Tabelle gespeichert.

[davidszkiba]

Ich denke der Grund war tatsächlich, dass wir noch vor #437 zu viele Daten gespeichert haben.

Damit wir es besser einschätzen können, hab ich jetzt einen Versuch mit der lowest skillgap Strategie und 25 Fragen ausgeführt. Hier komme ich momentan auf 111kb für die JSON Daten. Wenn man eher konservativ rechnet und annimmt, dass im Schnitt ein Versuch 250Kb an Daten generiert, dann kommt man hier bei 1000 Versuchen pro Tag über einen Zeitraum von 1 Jahr auf ca 92 Gb.

Wenn man die debuginfo Daten entfernt, kommt man von 111Kb auf 43Kb

Das JSON der Progress Tabelle: 200 kb Ohne playedquestions und playedquestionsbyscale: 20kb Ich denke hier kann man einiges einsparen, wenn man nur jene Daten der Fragen speichert, die man auch wirklich nochmal benötigt.

[davidszkiba]

• [x] debuginfo in extra Spalte, damit es bei bedarf geleert werden kann