Aaron hat geschrieben: Di Nov 07, 2023 3:35 pmDie Frage ist, muss eine Tabelle erstellt werden?
Wie frage ich die Datenbank ab? [...] Bitte gebt mir einmal Starthilfe.
In https://cran.r-project.org/web/packages ... duckdb.pdf gibt es auf Seite 9 ein Beispiel
) etwas gefrickelt, damit was zum Anfassen da ist.Code: Alles auswählen
library(data.table)
#----------------- Simulation von Spielmaterial --------------------------------
Basisverzeichnis <- "P:/R Progis/duckdb"
Anfang <- strptime("01/01/2012 00:00:00.000", "%d/%m/%Y %H:%M:%OS")
Ende <- strptime("01/01/2022 00:00:00.000", "%d/%m/%Y %H:%M:%OS")
test <- data.table(Timestamp = Anfang + runif(10*365*60*4)*(Ende - Anfang))
test[ , tdiff:=as.numeric(Timestamp - Anfang)]
test[ , ":="(Alpha=sin(2*pi*tdiff%%( 24*60)/( 24*60) + 0.27),
Beta =cos(2*pi*tdiff%%(7*24*60)/(7*24*60) + 0.57))
]
test[ , tdiff:=NULL]
setorder(test, Timestamp)
#-------------------------------------------------------------------------------
test[ , Tag:=as.Date(Timestamp, tz="")]
List <- split(test, by="Tag", keep.by=FALSE)
sapply(names(List), function (x) fwrite(List[[x]], file=file.path(Basisverzeichnis, "Daten", paste0(x, ".csv")))) # Verzeichnis Daten muss existieren
#--------------- Workspace wieder plattmachen ----------------------------------
rm(list = ls())
gc(); gc()
#---------------- Einlesen in duckdb--------------------------------------------
library(duckdb)
Basisverzeichnis <- "P:/R Progis/duckdb"
con <- dbConnect(duckdb(
dbdir = file.path(Basisverzeichnis, "DBitself"),
read_only = FALSE,
bigint = "numeric",
config = list()
))
Dateien <- list.files(path = file.path(Basisverzeichnis, "Daten"), pattern = "*.csv", full.names = TRUE)
duckdb_read_csv(con, files=Dateien, tempfile(fileext = ".tmp"))Dann stelle ich mal die Frage, auf die Du anscheinend von Anfang an aus warst und die mich nicht praktisch, sondern nur aus Neugierde interessiert: Was ist denn aus Deiner Sicht der richtige Weg und das richtige Format, 1 Terabyte Messreihen zu verarbeiten? CSV wird es wohl nicht sein, oder?Athomas hat geschrieben: Di Nov 07, 2023 6:10 pm"Schnell" ist das aber auf keinen Fall, ich vermute, dass Du mit Deinem Terabyte Daten auf diese Weise nicht glücklich werden wirst!
Code: Alles auswählen
gc(); gc()Code: Alles auswählen
cleanMem <- function(n=10) { for (i in 1:n) gc() }Dank "fread" würde ich nicht prinzipiell "Nein" zu CSV sagen - aber das ist sicherlich abhängig davon, was man machen möchte!Was ist denn aus Deiner Sicht der richtige Weg und das richtige Format, 1 Terabyte Messreihen zu verarbeiten? CSV wird es wohl nicht sein, oder?
Das ist eine rituelle Formel, die ich seit meiner R-Frühzeit in Verbindung mit rm(list = ls()) verwende, wenn ich den Workspace in einen möglichst jungmenschlichen (korrekt gegendert?) Zustand versetzen will - ohne R komplett zu schließen und neu zu öffnen. Damals hatte ich irgendwo gelesen, dass doppelt besser hält...Meine andere Frage lautet "Hä?" und zwar wegen dieses Code Snippets:
Athomas hat geschrieben: Do Nov 09, 2023 8:44 amDank "fread" würde ich nicht prinzipiell "Nein" zu CSV sagen
Ist bestimmt von vielen Faktoren abhängig. Ich habe in einem Interview mal gehört, dass DuckDB die Daten nicht zeilenweise sondern spaltenweise ablegt, weil man in der Datenanalyse eher spaltenweise Berechnungen ausführt (wie eben Mittelwert und die hundert größten Werte und Filtern nach Spalten). So etwas könnte natürlich schon viel Zeit beim Einlesen langer CSV kosten aber zugleich einen strategischen Vorteil bringen.Um den Mittelwert einer Variable zu bilden oder die hundert größten Werte (aus einer moderaten Zahl großer Dateien) herauszusuchen ist wohl keine Datenbank nötig - und dass deren Verwendung diese einfache Berechnungen beschleunigt, kann ich auch nicht glauben.
Mir persönlich wäre das jetzt entschieden zu speziesistisch, aber da kannst Du ja vielleicht nochmal in Dich gehen.wenn ich den Workspace in einen möglichst jungmenschlichen (korrekt gegendert?)
Dann geht gar nichts mehr, die Daten für data.table müssen schon (locker) in den RAM passen. Deshalb habe ich ja auch die portionsweise Verarbeitung angeregt, die auch nur bei speziellen Aufgaben einfach durchführbar ist - der Mittelwert gehört aber sicherlich dazu...Ich weiß, dass Du ein großer Fan von fread bist aber ich weiß nicht, wie fread sich verhält, wenn die Daten gar nicht mehr in den RAM passen.
Das habe ich nicht verstanden!?1 TB in CSV wird sehr viel weniger als 1 TB in einem Zahlenformat sein aber die meisten von uns bemessen ihren RAM ja eher in GB.
Ok, portionsweise Verarbeitung muss ja die Antwort sein, egal wie. Rechnen kann das DBMS ja auch nur im RAM und nicht auf der Platte. Einen Mittelwert aus Teilmengen zu berechnen wird leichter sein als beispielsweise einen Median. Man müsste halt alle gestellten Teilaufgaben durchgehen mit der Frage, ob der Algorithmus zum Berechnen aus Teilmengen banal ist und selbst gefunden werden kann oder ob darunter komplexe Fragen sind, die man lieber nicht selbst programmiert, sondern sich freut, wenn ein schlauer Mensch schon darüber nachgedacht und etwas optimiert hat.Athomas hat geschrieben: Do Nov 09, 2023 4:08 pmDeshalb habe ich ja auch die portionsweise Verarbeitung angeregt, die auch nur bei speziellen Aufgaben einfach durchführbar ist - der Mittelwert gehört aber sicherlich dazu...
Nun, beispielsweise ist die Timestamp im CSV als String mit 24 Zeichen hinterlegt. Also mindestens 24 Byte. Als Zahl passt so ein Timestamp aber bestimmt in eine 64 Bit Zahl. Die Zahl 0.83987 braucht in CSV sieben Bytes, kann im RAM aber als einfaches float repräsentiert werden. Die Kommas im CSV braucht ein data.table gar nicht und so weiter. Kleine Einsparung pro Zeile mal sehr, sehr viele Zeilen. Wenn ich also eine von fünf 200GB Dateien in den RAM lese und dabei das Datum konvertiere, dann wird das im RAM hoffentlich weniger als 200GB brauchen. Wenn ich wirklich den gesamten Datensatz in den RAM lesen wollte, bräuchte ich hoffentlich weniger als 1 TB freien RAM. Ich wollte also nur anerkennen, dass man weniger als 1 TB RAM bräuchte, aber der Einspareffekt wäre niemals so groß, dass man das in ein paar GB unterbringen kann. Das Problem löst sich also nicht deshalb auf, weil man für 200GB CSV weniger als 200GB im RAM braucht.Das habe ich nicht verstanden!?
Ich weiß nicht, ob diese Konvertierung wirklich so ein großer Performance-Fresser wäre, aber in jedem Fall hast Du soweit Recht, dass man über die 15 Einzelaufgaben im Detail nachdenken muss und das nicht beantworten kann, solange die nicht benannt sind.Ich glaube inzwischen, dass der Knackpunkt in Bezug auf die Performance des vorliegenden Problemchens (in jeder Herangehensweise) die Frage ist, ob der "Zeitstempel" wirklich in ein Datum konvertiert werden muss oder lediglich als Textlabel für bestimmte Messwerte mitgeschleppt werden kann.
) nochmal komplett angeguckt und möchte klarstellen: wenn die Einrichtung und das Handling einer Datenbank sowie die Performance kein Problem darstellen, ist ihre Verwendung hier sicherlich der bessere Weg.In diesem Zusammenhang fand ich diesen Vortrag auf Youtube interessant. Der Vortragende war früher für Google mit dem Google-Tool BigQuery für wirklich große Datenmengen beschäftigt und sagt: "The thing that I rapidly realized was that, you know, none of our customers are acutally running queries like this. [...] A lot of our BigQuery customers don't actually use big data."Athomas hat geschrieben: Fr Nov 10, 2023 10:34 amMeine Vorschläge sind als "Notlösung" bei Performance-Problemen gedacht!