Repository wird unnötig riesig

[kohlrabi]

Hallo,

statt in "Archiv" alle vorherigen Daten zu speichern, müsste nur das CSV im Hauptordner ge-updated werden, und dann würde nur das winzig kleine Diff gespeichert werden. So wächst das Repository jeden Tag um mind. 100MB. Wozu? Die Daten sind redundant, da sie bereits in den vorherigen Commits/Tags enthalten sind. Statt vielleicht 200MB ist das Repo bei mir auf der Platte 48GB groß:

$ du -sh SARS-CoV-2_Infektionen_in_Deutschland/
48G SARS-CoV-2_Infektionen_in_Deutschland/

Grüße, Christoph

[HannesWuensche]

Hallo Christoph,

danke für deine Rückmeldung. Wir sind uns des Problems bewusst haben aber gleichzeitig noch keine gute Lösung gefunden. Denn:

Du hast zwar recht, dass über die Commits/Tags die History abrufbar ist, jedoch wird es dann aufwendig eine Zusammenstellung des Archivs, wie es derzeit bereitsteht, zu erhalten. Insbesondere für die wissenschaftliche Nachnutzung wollen dieses aber anbieten.

Eine Möglichkeit wäre, einen weiteren Branch zu erstellen, der dann nur die "Aktuell_*" Datei enthält. Du könntest dann nur diesen clonen und pullen:

$ git clone -b aktuell_de --single-branch https://github.com/robert-koch-institut/SARS-CoV-2_Infektionen_in_Deutschland.git

Was hältst du von der Idee?

Mit besten Grüßen @HannesWuensche für das Team RKI | Open Data

[kohlrabi]

Hallo Hannes,

danke für die Antwort. Vielleicht wäre es praktischer, ein Skript berietzustellen, das iteratirv aus allen Commits die aktuellen CSVs in einen Unterordner kopiert, damit kann man ja den 48GB-Ordner lokal erstellen lassen, ohne ihn herunterladen zu müssen.

Ich schaue mal, ob ich ein Beispiel erstellen kann.

Grüße, Christoph

[HannesWuensche]

Hallo Christoph,

Das wäre auch ein denkbarer Weg. Allerdings sehe ich hier die Barriere für Nachtnutzende die nicht so fit auf der "Comandozeile" sind. Darüber hinaus stellen wir die Daten ja auch auf Zenodo.org bereit: Da würde ich das Archiv auch so belassen wollen.

Ich nehme deinen Vorschlag aber definitiv in unser nächstes Teamtreffen mit. Magst du noch kurz Feedback zu meinem Vorschlag geben? Siehst du größere Probleme?

Dank und Grüße, Hannes

[kohlrabi]

Hallo Hannes,

das mit dem Extra-Branch klingt wie eine gute Idee. Wenn der am root-Knoten ansetzt, und von dort jeden einzelnen Tag bekommt, müsste der ja schlank werden.

Zenodo werde ich mal anschauen, das kannte ich bisher gar nicht.

Das Skript wäre ja klein, in etwas sowas, aber ich verstehe schon, dass das "abschreckend" sein kann.

#!/bin/bash

# copy all daily files to archive directory

targetdir=new_archive
tags=$(git tag)
postfix=_Deutschland_SarsCov2_Infektionen.csv

mkdir -p $targetdir
for tag in $tags; do
        newfile=${targetdir}/${tag::10}${postfix}
        if [ ! -f "${newfile}" ]; then
                git checkout ${tag}
                cp *${postfix} ${newfile}
        fi
done

viele Grüße, Christoph

[fnogatz]

Shameless self-promotion, vielleicht interessant für Mitlesende: Am DFKI haben wir ein Script entwickelt, das ausgehend von der Tages-CSV den minimalen Diff zum vorigen Tag bestimmt: DFKI/RKI-Data-Diff. Im Ergebnis werden für jeden Tag nur die circa 0,5% bis 2% neuen CSV-Zeilen identifiziert und abgespeichert. In meinem privaten Namensraum unter fnogatz/RKI-Data-Diff findet sich der so täglich aktualisierte Gesamt-Dump. Wir geben das zwecks Indizierung als SQL-Dump aus, die Tabelle folgt aber genau dem Format der täglichen CSV-Dateien. In der Datei RKI-Data-Diff.log findet sich eine Info, wieviele Zeilen der CSV sich von einem auf den anderen Tag geändert haben.

Uns war es aus den hier schon im Issue genannten Punkten (Stichwort: wissenschaftliche Nachnutzung) wichtig, die täglichen Daten in Rohform zu erhalten, gleichzeitig aber nicht unnötig redundante Daten vorzuhalten. Über den durch das Script erzeugten SQL-Dump lassen sich so leicht Fragen beantworten wie »Wieviele Fälle gab es im SK Kaiserslautern bis 23.07.2021?«. Aber eben auch: »Wieviele Fälle gab es im SK Kaiserslautern bis 23.07.2021, mit all den Korrekturen, die bis 28.07.2021 bekannt waren?« Dadurch soll es ermöglicht werden, Entscheidungen rückblickend nicht nur anhand der Realdaten (also inklusive aller späteren Korrekturen) zu bewerten, sondern anhand der Daten, die an diesem Tag bekannt waren. Ohne dafür die RKI-CSV eines jeden Tags separat vorhalten zu müssen. Mögliche Beispielanfragen an die SQL-Tabelle haben wir in der Datei Queries.md zusammengetragen.

Ausgehend von unserem SQL-Dump lässt sich übrigens auch die CSV des RKI jedes beliebigen Tages wiederherstellen, siehe Beispielaufruf. Das Ergebnis unterscheidet sich dann einzig durch die Sortierreihenfolge der CSV-Zeilen.

[volviq]

macht doch bitte ein extra archiv repository (also eine Kopie/umbenennung dieses repositories) , und ein neues nur für die aktuellen Daten. Dann braucht es dort auch kein git-lfs. Historie für das Haupt-CSV wäre zwar nett, aber wohl nicht dringend nötig. Shallow Clones dieses Repositories wären dann wirklich sehr klein. Vielen Dank.

[Stenway]

Hallo zusammen, das Datenformat SML (https://www.simpleml.com) könnte für die Historie verwendet werden, um statt vieler CSVs eine einzelne Datei zu haben, in der die Differenzen von Tag zu Tag gespeichert sind. Habe hierfür mal einen Prototypen entwickelt und zeige das Konzept in folgendem Video: https://www.youtube.com/watch?v=I1th3Yf8Tlo Die Rohdaten können somit von aktuell 33 GiB auf 0,86 GiB reduziert werden (-97,4 %). Gepackt ist die SML-Datei dann 81 MiB. CSVs lassen sich daraus auch wieder rekonstruieren. Der Prototyp ist in Java geschrieben und Links zu den Source-Repositories sind in der Videobeschreibung enthalten. Vielleicht könnte das ja weiterhelfen.

Viele Grüße Stefan

PS: Auf https://entwickler.de/experten/stefan-john stehen zwei meiner Artikel zu SML zur Verfügung

[HannesWuensche]

Liebe Alle,

wir haben uns noch einmal Gedanken bezüglich der Größe des Datensatzes (Repros) und möglicher Lösungen gemacht: Da jeder Datenstand auf seine Weise einzigartig ist, würden wir das Archiv definitiv weiterführen. (Die Lösung des DFKI kommt für uns leider nicht in Frage.)

• derzeitige Größe ca. 70 GB
• ohne Archiv ca. 35GB

Um die Größe auf der eigenen Festplatte zu verringern, wäre daher in jedem Fall ein Shallow Clone ohne Archiv nötig. Wir sehen derzeit zwei Möglichkeiten das Archiv zu migrieren:

• Archiv als eigenen Datensatz (eingebunden als Sub-Module)
• Archiv als eigenen Branch (Single Branch Clone)

Derzeitiger Favorit ist die Einbindung über Sub-Module. Welche wir die nächsten Tage testen werden. Falls wir etwas übersehen haben und es bei einem der beiden Wege Probleme gesehen werden freuen wir uns über Feedback.

Beste Grüße @HannesWuensche für das Team | RKI Open Data

[kohlrabi]

Danke @HannesWuensche, ich schließe dieses Issue mal.