Handle big data files in processing.

[JesJehle]

We have currently an error in the cog processing, of the files fro bavariannationalpark, with 70 GB.

I think this is a good time to discuss how we should handle such sizes. @cmosig For the current process I would suggest to omit this dataset.

[mmaelicke]

Was genau ist denn der fehler?

[JesJehle]

aus den logs: Error processing COG for dataset 3545: /data/cogs/0c04075b-aadc-4e67-9b1a-b8540ba9405f_bavarianationalpark/0c04075b-aadc-4e67-9b1a-b8540ba9405f_bavarianationalpark_cog_jpeg_ts_web-optimized_q75.tif: No such file or directory

[cmosig]

Komisch. Klingt ja irgendwie nicht so also ob die Dateigröße hier das Problem ist. Ist das reproduzierbar?

[cmosig]

Ich hatte mit Teja etwas gequatscht und wir sind auf den Konsens gekommen dass wir am Besten schauen sollten was der Server maximal handlen kann an Dateigröße und alles größer ist, wird eben aufgeteilt. Das macht an sehr vielen Stellen unser Leben einfacher und es braucht kein gesondertes handling von den riesen (e.g. California) Datensätzen.

32GB sollten es aber mindestens sein können.

Der storage server hat nur 10TB storage, oder? Das ist jetzt schon nicht mehr aussreichend, wir sind bei ~15TB würde ich schätzen. Soll ich dafür ein neues issue öffnen, oder ist das einfach zu erweitern? Denke 50TB sollten wir erstmal allocaten.

[mmaelicke]

Ui. Wo kommen denn die ganzen Bilder her? mein letzter Stand max. 6TB. Evtl brauchen wir hierfür ein Treffen um verschiedene Strategien durchzusprechen. Der Server ist nicht erweiterbar, mir ist auch kein Provider bekannt der mehr als 10TB anbietet. Ich persönlich habe auch wenig Erfahrung, wie ein solcher Server dimensioniert sein muss, was CPU und RAM angeht, damit sich mehr als 10TB effektiv nutzen lässt.

Überlegungen die wir hier anstellen können:

• Cloud Storage: Da übernimmt google die Verwaltung für uns, verglichen mit virtuellen servern kommen aber erhebliche Kosten auf uns zu. Außerdem müssen große Teile der Infrastruktur angepasst werden. Hauptvoteil ist, dass es skaliert.

• Die zweite Möglichkeit ist, dass wir es auf dieser Infrastruktur lassen und dann horizontal skalieren. Das ist jetzt direkt natürlich erstmal weniger Aufwand, allerdings müssen wir auch hier die Infrastruktur mittelfristig anpassen. Das ganze ist vermutlich günstiger. Idee wäre, dass jeder server seine eigene API anbietet und supabase sich ab sofort mitspeichert wo welches bild hingespeichert ist (fürs cogs und download). Aus den metadaten lässt sich relativ einfach ein view generieren, der für den upload schätzt auf welchem rechner noch wie viel platz ist. Hier würde ich dann relativ schnell einen zweiten (oder dritten) aufsetzten, damit wir beim upload der daten die gleich einigermaßen verteilen können.

In jedem Fall müssen wir einen Zeitplan aufstellen, damit ich mir ausreichend Zeit nehmen kann.

[cmosig]

SX65 bei Hetzner hat 4x22TB HDD und 2x1TB SSD. Würde das nicht gehen?

In der SX Reihe geht es sogar es 14x22TB.

https://www.hetzner.com/dedicated-rootserver/sx65/

Wenn man Spaß hat könnte man einen LRU Cache für die COGs auf den SSDs bauen :P

[mmaelicke]

Ah cool, ich hatte die 1TB SSD übersehen. Denn für die COGs ist das denke ich absolut notwendig. die können wir nicht auf die HDD packen.

Dee Sache mit der Zeit bleibt dennoch. Ich spreche mal mit Teja wegen Kohle und dann müssen wir schauen wann wir einen solchen Umbau machen. WOllen wir dann die jetzige Maschine (erstmal) zum entwickeln behalten, denn es sind ja noch wirklich viele issues offen?

[cmosig]

Ok nice. :+1:

Dann muss man das mit dem caching ja tatsächlich machen, wenn die HDDs für die COGs nicht ausreichen. Müsste man wohl mal testen.

Bzgl der aktuellen Maschine müsst ihr sagen ob ihr die für die Entwicklung braucht.

Zeitmäßig drängt es nicht krass. Wenn es bis Anfang nächstes Jahr auf den neuen Server migriert ist würde es von meiner Seite aus reichen. Bis dahin kann ich auch noch nicht so wichtige Datensätze zurückhalten und dann reichen die sicher 10TB bis dahin.

[JesJehle]

Finde ich eine gute Idee. Ich würde jetzt auch erstes Mal die Issues im bestehenden System lösen, bevor wir es so krass skalieren. Anfang nächstes Jahr ist, denke ich, gut machbar.