mysql Update

[AxelM]

Hallo,
ich importiere täglich etwa 500k Datensätze in eine SQL-Datenbank.
Das geht mittels csv import auch ziemlich fix
dabei habe ich jeweils 3mal 1 datum in der Form YYYYMMDD (20130225) und eine Uhrzeit als "Sekunden seid 0 Uhr".
Aus beiden Spalten muss ich einen Unixtimestamp machen.
sämtliche Spalten der Tabelle haben einen INDEX.
Mit PHP ist das an sich kein großes Problem. Aber der Spass braucht fast 3h.
Das ist zu lange.
Ich bin auf der Suche, nach Lösungen, die den Vorgang deutlich beschleunigen können.

Das einlesen der kompletten 500k Datensätze ist nötig um die Daten kosistent zu halten. An der Menge ist also nix zu drehen.

Danke schonmal für eure Antworten.

 

[Duddle]

AW: mysql Update

Mit PHP ist das an sich kein großes Problem.

Wie sieht denn dein Ansatz aus? Nicht dass ich den gleichen Code nochmal vorschlage.

Importierst du die Daten und rechnest sie dann nochmal gesondert um, oder machst du das beim Import schon? Musst du das zwingend mit PHP / serverseitig machen oder könntest du auch eine Phase vorher schon die notwendigen Zeiten berechnen?

Wahrscheinlich wird es auf Parallelisierung hinauslaufen. Ich sehe direkt keinen Grund, warum du bspw. die .csv-Datei nicht aufsplitten und verteilt verarbeiten könntest, bevor die Änderungen zusammengeführt und importiert werden.

Edit: Habe gerade mal ein bisschen rumprobiert und mit ein paar Annahmen versucht deine Umgebung nachzubauen. Wenn ich mir 500k Datensätze erzeuge und dann einfach MySQLs UNIX_TIMESTAMP() (das erkennt schon YYYYMMDD), eine Addition und FROM_UNIXTIME() kombiniere, wird das ganze in ca. 30 Sekunden umgerechnet.


Duddle

 

[rafoldi]

AW: mysql Update

also habe da mal einen anderen Ansatz. hast Du schon mal Analysiert was da so lange Dauert?
Die Umsetzung des Timestamp kann ich mir nicht ganz so vorstellen.
Die Frage währe wieviele Indexe sind auf dem Table? sind Transaktionen vorhanden? Wieviele Datensätze sind in der Tabelle?
Vorschlag :
- Indexe löschen / deaktivieren
- Daten laden
- Indexe erstellen / aktivieren

 

[Duddle]

AW: mysql Update

hast Du schon mal Analysiert was da so lange Dauert?

Ich vermute mal, er holt jeden Datensatz von PHP aus, berechnet dort den Timestamp und updatet eine Zeile.

Wie gesagt, ich habe das mal testweise von MySQL selbst erledigen lassen, da haben 500.000 Zufallsdatensätze weniger als eine Minute gedauert...


Duddle

 

[rafoldi]

AW: mysql Update

Ich vermute mal, er holt jeden Datensatz von PHP aus, berechnet dort den Timestamp und updatet eine Zeile.

Wie gesagt, ich habe das mal testweise von MySQL selbst erledigen lassen, da haben 500.000 Zufallsdatensätze weniger als eine Minute gedauert...


Duddle

Na dann könnte man doch sich das SQL Statement ansehen und das Update über die quere clausel so ändern dass alles zusammen gerast wird. Am besten inkl. Status.

 

[Curanai]

AW: mysql Update

Hängst Du die Table für die Operation aus? Stichwort: LOCK
MyISAM oder eine innoDB?
Könntest Du das CSV vielleicht schon vor dem Import selbst erweitern um besagtes Datum?
LIMIT bei Update je Zeile auf 1 gesetzt und WHERE-Zweig der besagte Index?

 

[rafoldi]

AW: mysql Update

Hängst Du die Table für die Operation aus? Stichwort: LOCK
MyISAM oder eine innoDB?
Könntest Du das CSV vielleicht schon vor dem Import selbst erweitern um besagtes Datum?
LIMIT bei Update je Zeile auf 1 gesetzt und WHERE-Zweig der besagte Index?

Ich würde eventuell die Indexe der Tabelle deaktivieren und später wieder aktivieren. Macht immer dann Sinn wenn Massendaten im Spiel sind. Das aufbauen der Indexe nimmt dann meistens weniger Zeit in Anspruch und ein erneuter Reorg der Indexe wird dabei vermieden.

Leider kann MySQL die Tabellen nicht Partitionieren. das bringt dann noch einen Schub.

@AxelM
Allerdings frage ich warum Du die Daten nicht in eine Zwischentabelle lädst um das Update durchzuführen, Insert in Original Tabelle, Anschließend truncate der Zwischentabelle?

 

[Curanai]

AW: mysql Update

rafoldi, viele Wege führen nach Rom - sind aber nie gleich lang. Der TO wird schon seinen Weg machen/finden ...