Performanceüberlegungen "Zeitberechnung"

[dgr243]

Moin zusammen,

gegeben ist folgendes Konstrukt:

- Quelldaten liegen in einer MS-SQL Datenbank

- Ich kann aus dieser DB exportieren, am Datenbankdesign jedoch nichts ändern

- Zieldaten kommen in eine My-SQL Datenbank per "LOAD DATA INFILE....."

Nun habe ich das Problem, dass in den Quelldaten 2 "DateTime" Felder für Start und Ende enhalten sind und ich für die Applikation die auf die My-SQL Daten zugreift nach eben jenen Feldern suchen muss. Ist ja soweit auch kein Thema.

Jetzt wird zusätzlich gefordert, dass die Applikation Datensätze einer bestimmten Länge suchen können soll.

Da hab ich ja jetzt 3 (oder mehr?) Möglichkeiten:

1. Beim Export wird ein zusätzlich berechnetes Feld "Dauer" pro Datensatz in die Exportdatei geschrieben und damit beim Import in die Mysql bereits fertig mit importiert. So als Pseudocode:

select to file xyz.csv Start, Ende, (Ende-Start) as Dauer from table;

2. Ich erstell mir einen on insert Trigger mit dem Ziel beim Import via LOAD DATA die Dauer zu berechnen auf der MySQL Datenbank.

3. Ich lasse alles wie es ist und berechne die Dauer on the Fly in der Applikation.

Was ist eurer Meinung nach hier die beste Vorgehensweise oder hat jemand gar noch eine bessere Idee?

Gruss

dgr

[Goos]

Mit den Infos laesst sich eine "beste Loesung" nicht aufzeigen.

Viel haengt wohl an der Frage, wie oft die Daten von MSSQL nach MySQL exportiert werden, wieviel Datensaetze bei der Suche betrachtet werden, von welcher Hardware man ausgeht.

Goos

[dgr243]

Na die Fragen lassen sich ja beantworten

- Export wird täglich ausgeführt

- täglich fallen zwischen 10.000 und 20.000 neue Datensätze an

- die Suche findet immer über alle Datensätze statt, kann aber ggf. weiter eingeschränkt worden sein, in dem man zum Beispiel nur Datensätze vom 1. bis 3. eines Monats sucht deren Dauer über x Minuten lag

- pro Tag fallen zwischen 15.000 und 25.000 Suchanfragen an

- Suchanfragen werden teilweise parallel erfolgen

- auf allen "DateTime" Feldern in der My-SQL sitzt ein Index

- Hardware ist in beiden Fällen ein 2-fach P4 Xeon Quadcore (@2,66 GHz pro Core) mit 8GB RAM und RAID-1 (2*146GB SAS @ 15.000UPM)

- Im MS-SQL Fall läuft das ganze unter Windows Server 2003 Datacenter

- Im My-SQL Fall unter Debian 4.0 (My-SQL 5.1)

Zum Fall 3 (on the Fly Berechnung): Hier würde ich wenn dann die Berechnung mittels Timediff() im SQL Statement machen.

Wenn noch weitere Fragen sind, gern raus damit

[Goos]

Vom Fall 3 wuerd ich grundsaetzlich schonmal abraten, es sei denn die Dauer ist immer nur ein zusaetzliches Kriterium und wird dann ueber einen sehr beschraenkten Zeitraum ausgewertet (nicht mehr als ein paar hundert Datensaetze).

Da sowas in der Regel aber nicht garantiert werden kann, solltest dich zwischen Loesung 1 und 2 entscheiden.

Prinzipiell wuerde ich zu Loesung 1 raten. Es kommt aber nun darauf an was auf dem MSSQL System sonst noch laeuft.

Du nimmst damit auf jeden Fall die Last der Berechnung vom MySQL System, welches ja zur Zeit des Imports wahrscheinlich möglichst produktiv bleiben soll.

Ein Index auf die "Dauer"-Spalte wuerd ich zusaetzlich zu den Indizes auf "Start" und "Ende" natuerlich als Pflicht ansehen.

Goos

[dgr243]

Hab da grad mal auf dem Development System ausprobiert wie sich das Lasttechnisch verhält.

Export und (Re-)Import von ~1gbyte Daten (knapp 10 Millionen Datensätze).

Export auf MS-SQL dauert mit zusätzlicher Berechnung der Dauer Spalte knapp 23 Sekunden länger. (Ohne weitere Systemlast)

Import auf My-SQL dauert mit zusätzlicher Berechnung der Dauer Spalte knapp 17 Sekunden länger. (Ohne weitere Systemlast)

Batchabfrage (10000 Abfragen jeweil 100 parallel; Variation in den Suchparametern Start, Ende, Dauer sowie der Sortierung) dauert mit zusätzlicher Berechnung der Dauer Spalte (je Abfrage) knapp 25 Sekunden länger.

Alles in allem nimmt sich das nicht wirklich viel. Einzig die Berechnung erst beim Import auf die MySQL ist etwas performanter. *grübel* Blöde Entscheidung .. Am besten ich bau einfach alle 3 Möglichkeiten ein und setz im Adminpanel ne neue Option rein, dass der Import / Exportadmin sich da gefälligst entscheiden soll wie er es gern hätte :bimei:

[Goos]

Nuja, der Fall mit der Berechnung haengt aber dann auch stark von der Selektivität deiner Suchabfrage ab

Goos

[dgr243]

Berechnet wird in jedem Fall.. Entweder beim Export, beim Import oder zur Laufzeit.. Welchen Fall meinst du nun? :confused:

[Goos]

Na ich mein den Fall 3. Da wird berechnet ueber die Datensaetze welche durch Start-Ende eingeschraenkt wurden und nicht ueber alle 10 Millionen.

Wenn du also Start auf 1900 setzt und Ende auch 2010, dann wirds etwas langsam werden mit den Berechnungen. Immerhin wirds ja fuer jede Abfrage neu berechnet und nicht nur einmal beim Export/Import.

Goos

[dgr243]

Das ist wohl wahr. War aber in der Batchabfrage auch so enthalten, dass teils sehr kurze, teils längere und teils keine Start/Ende Beschränkungen drin waren.

Zudem werden ähnliche Abfragen scheinbar Mysql seitig gecached. Änder ich "nur" den Filter auf Dauer, lasse aber die Start/Ende Begrenzung wie in der vorhergehenden Abfrage hab ich die Ergebnisse sofort.

Habs jetzt so umgesetzt, dass sich das ganze halb automatisch regelt. Es wird beim Import einfach geprüft ob eine "Dauer" Spalte vorhanden ist. Wenn ja wird für 10 Random Datensätze geprüft ob der Dauer Wert korrekt ist und wenn ja angenommen, dass Dauer sauber importiert werden kann.

Darüber hinaus kann man dann noch administrativ entscheiden ob man annehmen will, dass eine Dauerspalte vorhanden ist..

So kann unser Admin dann machen was er will und ich hab meine Ruhe

Thx für die Gedankenanstöße auf jeden Fall