Deutsches R-Forum

Meine naive Vermutung war, dass der Plattenzugriff und nicht die Anzahl der Kerne/Threads der Flaschenhals ist.

Aber auch das Einlesen von Daten profitiert (erheblich) von einer größeren Anzahl von Kernen - die vielen Daten, die von der SSD kommen, müssen ja auch verwurstelt werden...

Ich habe praktisch "nur" 200 Dateien, die ähnlich simpel waren wie die von Aaron (aber schon als UTF-8 auf die Welt gekommen sind ), mit jeweils 10 Mio Sätzen (pro Datei ~560MB) in eine einzelne DuckDB-Datei eingelesen.
Die hatte dann interessanterweise nur noch 36GB - Aaron kann also noch hoffen, nicht 1TB durchnudeln zu müssen...

Aaron hat geschrieben: ↑Mi Nov 15, 2023 3:42 pmDie csv Datei hatte eine Größe von 2GB.

Das wird nicht komplett proportional sein aber wahrscheinlich kann man das dann trotzdem ungefähr mal hundert nehmen und dann bei etwa 300 Sekunden, also 5 Minuten ankommen. Es sei denn, die dann größere Maschine hat 28 Rechenkerne...

@Athomas Da wird einem so richtig bewusst, wie ineffizient CSV eigentlich ist.

Müsste nicht auch der Übergang von UTF-16 zu -8 schon eine erhebliche Entlastung bringen, wenn man nur normale Buchstaben und Zffern verwendet?

LG,
Bernhard

Müsste nicht auch der Übergang von UTF-16 zu -8 schon eine erhebliche Entlastung bringen, wenn man nur normale Buchstaben und Zffern verwendet?

Das sind genau dieselben Buchstaben und Ziffern, nur in ein größeres Umfeld eingebettet !
Die Datei 5.csv (!) von Aaron hatte 4.7MB, die konvertierte 5a.csv 2.3MB!

Dürfte kein Zufall sein, dass das eine Halbierung ist. Damit werden aus Aarons Terabyte schon "nur noch" 500GB und nach dem Umwandeln in ein Binärformat nochmal deutlich weniger.

Bleibt die Frage, wieviele der geforderten Auswertungsschritte sich so einfach in SQL umsetzen lassen und ob man für die Schritte, die R erfordern, die Daten vorher ausreichen aggregieren kann.

LG,
Bernhard

Hallo Bernhard

Bleibt die Frage, wie viele der geforderten Auswertungsschritte sich so einfach in SQL umsetzen lassen und ob man für die Schritte, die R erfordern, die Daten vorher ausreichen aggregieren kann.

Du hast den Nagel auf den Kopf getroffen. Ich habe versucht einige Abfragen und entsprechende Berechnungen in SQL durchzuführen. Die Ergebnisse sind wenig plausibel bzw. vertrauenswürdig. Die Frage ist, wie kann ich erreichen, dass ich mit den Daten aus der Datenbank in R rechnen kann? Für meine Berechnungen sind nur die Grundrechenarten und ein wenig Statistik nötig. Das sollte eigentlich auch in SQL funktionieren.

Hallo Aaron,

das verstehe ich wieder nicht. Wenn das alles auch in SQL funktioniert, ist es bestimmt am wenigsten Aufwand, es in SQL zu machen. Wie schon beschrieben, entweder passen die ganzen Daten in den RAM (A) oder man muss immer Teile davon in den RAM laden und dort verarbeiten (B). (A) scheint derzeit nicht erreichbar (man kann bestimmt bei AWS einen Server mit dem entsprechenden RAM mieten). Also (B). Du kannst beispielsweise duckdb sagen, dass Du nur die Daten vom 1. Januar bis 15 Januar in den RAM laden willst. Die passen dann vielleicht in den RAM wo Du sie in R verarbeiten kannst. Dann muss Du das halt immer wieder für mehrere Zeitabschnitte wiederholen. Warum Du Dir diese Mühe machen solltest, wenn es auch in SQL geht, weiß ich nicht. Schneller ist es wahrscheinlich, je weniger R Code darin vorkommt. Oder Du verwendest vorgefertigte Software, die Dir die Orchestrierung abnimmt, die Du dann aber erst erlernen musst. duckdb wäre solche vorgefertigte Software und von allen die, die sich für Dich besonders anbietet, weil Du damit jetzt schon soweit bist. Es gibt bestimmt auch andere Hilfsmittel, die man in R hinzuziehen kann, beispielsweise arrow, wenn Du lieber dply- als SQL-Syntax benutzen möchtest. Die Annahme, dass dplyr leichter zu lernen wäre als SQL würde ich jetzt so nicht treffen. Dass Du jetzt gelerntes SQL auch in zwanzig Jahren noch brauchen kannst erscheint mir wahrscheinlich er als bei dplyr. YMMV.

LG,
Bernhard

Hallo Bernhard

vielen Dank für deine wirklich guten Erklärungen. So langsam beginne ich zu verstehen.