Performance gut?

[Verjigorm]

Hallo,

ich komme jetzt in die Endphase meines Projekts.
Beim heutigen Test wurden knapp 1Mio Datensätze testweise von Superbase per ODBC-Treiber in Access importiert.
Das Ganze dauerte etwa 6Stunden.
Jeder Datensatz wurde mindestens 2mal angefasst, 1mal lesend und 1mal schreibend.
Mit diversen Plausibilitätsprüfungen waren es etwa 2,5Mio SQL-Anweisungen in 6h.
Lustigerweise sind das gradmal 154MB reine Daten.
So im Schnitt sind das also 2500000/(360*60) ~ 100 Anweisungen pro Sekunde.

Was ich für den ODBC-Treiber unglaublich schnell finde.
Naja wie das so ist, Chef hat gesagt es ist zu langsam .....

Bin allerdings nicht der Meinung, dass sich da irgendwas "performanter" programmieren lässt, was wirklich was bringt.
Die 2 Treiber sind imho einfach nicht schneller.
Wobei das 2-3mal schneller ist, als ich vorher vermutet habe.

Denkt ihr, der Treiber schafft mehr und es lohnt sich wirklich nach mehr Performance im Code zu suchen?

mfg Verjigorm

 

[Gast]

>>Denkt ihr, der Treiber schafft mehr und es lohnt sich wirklich nach mehr Performance im Code zu suchen?

Denkst du, dass irgendjemand eine vernünftige Anwort geben kann ohne deine App zu profilen?

schnell, langsam

Alles so subjektiv..

 

[AlArenal]

Lass mich raten, beide DBs liefen auf derselben Karre, einem Pentium 3 mit 500 MHz und 128 MB RAM und du hast brav jeden Datensatz einzelen ausgelesen, einzeln abgespeichert und commitet...

Gast hat völlig Recht: Auf ungenaue Fragen kannst du keine präzise Antworten erwarten.

 

[Verjigorm]

SuperbaseDatenbank mit Superbase 32-bit Driver (*.sbf)
Access 2002 mit dem Standardtreiber WinXP-Treiber Microsoft Access Driver (*.mdb)
1 Rechner mit WinXP mit 2GHz und 2GB Ram (sonst lief nicht wirklich ein anderes Programm)
Java 6 Update 10

.. und du hast brav jeden Datensatz einzelen ausgelesen, einzeln abgespeichert und commitet...

Ja, genauso isses
Von Superbase in Access.

 

[foobar]

Benutzt du denn Batchupdates zum Schreiben der Datensätze?

 

[Verjigorm]

Nö.

Das Ganze läuft nach einer Nummernliste ab, die abgearbeitet wird.
Jeder Datensatz wird einzeln gelesen, auseinandergenommen, überprüft, neu zusammengesetzt und geschrieben.
Nach jedem datensatz kommt ein Commit, falls irgendwo unerwartete Fehler auftreten wird genau da abgebrochen.

 

[foobar]

Dann brauchste dich auch net zu wundern, daß die Anwendung lahm ist.

 

[Verjigorm]

Wie gesagt, ich finds eigentlich nicht lahm *schulterzuck*

 

[GilbertGrape]

Wie gesagt, ich finds eigentlich nicht lahm *schulterzuck*

Warum fragst du dann hier überhaupt?
Du wolltest nur hören, dass dein Chef ne Meise hat und du alles genau richtig gemacht hast? :wink:

 

[foobar]

Machst du für jeden Datensatz einen Select und einen Insert oder wie läuft das?

 

[-MacNuke-]

Lustigerweise sind das gradmal 154MB reine Daten.

Äh, warum holst du dir nicht auf einen Schlag alle Daten in den RAM, bearbeitest sie und haust sie in ein paar Batch-Arbeiten in die andere Datenbank?

6 Stunden, um 154MB Daten zu bewegen ist etwas... naja.... lahm.

 

[Verjigorm]

Machst du für jeden Datensatz einen Select und einen Insert oder wie läuft das?

Ja natürlich, ohne Select krieg ich das Ding net aus der DB und ohne Insert nicht wieder in die andere rein :?:

Äh, warum holst du dir nicht auf einen Schlag alle Daten in den RAM, bearbeitest sie und haust sie in ein paar Batch-Arbeiten in die andere Datenbank?

6 Stunden, um 154MB Daten zu bewegen ist etwas... naja.... lahm.

Es ist ja keine 1:1 Kopie, sondern eine Migration von A nach B.
Sämtliche Werte, sämtlicher Spalten, sämtlicher Tabellen werden anhand von Listen/Bedingungen verglichen, geändert etc.

 

[Gast]

Deswegen musst du es trotzdem nicht für jeden Datensatz einzeln machen...

 

[AlArenal]

Jeder Datensatz wird einzeln gelesen, auseinandergenommen, überprüft, neu zusammengesetzt und geschrieben.

Und das ist ein Fehler, weil du damit sowohl lesend als auch schreibend einen riesigen Overhead erzeugst. Pass die Programmierung an, dass du blockweise immer x Zeilen ausliest, verdengelst und in einer (!) Transaktion wegschreibst. Setz für x mal 1, 50, 200, 500, 1000... und schau dir die Permance an..
Ein Briefträger holt auch nicht jeden Brief einzeln bei der Post ab, stellt ihn zu, holt den nächsten Brief, liefert ihn aus, holt den nächsten, ...

Wenn du nicht jeden zweiten Datensatz nen Fehler hast (es sollte ja nur während der Entwicklung mal einer vorkommen), ist der evtl. Overhead für ein Rollback vernachlässigbar. Von daher ist mir nciht wirklich begreiflich,w arum du dein Prog so eine Stückelarbeit machen lässt.

Zu meine Anfangszeiten habsch noch auch proprietären Datenbanken, die kein Mensch lesen konnte, gedruckt, den Druck in eine Datei umgeleitet (damals noch indirekt via Abfangen der Druckdaten an der seriellen Schnittstelle), habe die Druckdaten mit Sed und Perl durchgeahst und ein schmuckes CSV zum direkten Access Import erzeugt.
Ach ja, die guten alten Zeiten...

 

[Verjigorm]

Ich wüsste nicht, wie ich da x Zeilen auf einmal auslesen sollte ...

 

[homer65]

Nach jedem Insert ein Commit zu machen ist tödlich für die Performance. Nebenbei bemerkt sind 6 Stunden für den insert von einer Millionen Sätze mehr als lahm. Ich würde bei einem brauchbaren Datenbanksystem Zeiten von ca 1 Minute für normal halten.

 

[tfa]

Wer tatsächlich Access als Datenbank einzusetzen versucht bekommt ganz genau das, was er verdient.

 

[Verjigorm]

Naja das Problem ist eher Superbase ...
Der letzte Treiber ist von 1999.
Alleine die 75.000 Nummern auszulesen dauert etwa 90sek und das ist eine einfache Select-Anweisung ohne irgendwas

"SELECT EquipmentNr FROM DBESTAND ORDER BY EquipmentNr"

Selbst ohne Order BY dauerts 75sek


edit: Ihr habt ja keine Vorstellung davon, wie schlecht Superbase ist und wieviel schlechter der ODBC-Treiber ist

 

[AlArenal]

Ein Grund mehr alles in einem Rutsch auszulesen, loakl zu verarbeiten und dann in einem Schwung in die Ziel-DB zu schreiben.

Zur Not:
Musst du zwingend über den Treiber direkt auf die Quelle zugreifen? Reichen nicht auch exportierte Files? Das sagt einem doch der gesunde Menschenverstand, dass es schneller wäre den Scheiß lieber lokal in eine temporäre DB zu klatschen und damit zu arbeiten. Ob das nun ne HSQL ist, oder CSV Dateien mit passendem Treiber, oder oder.. ist ja ein anderes Thema.

 

[Verjigorm]

Ich würde liebend gerne exportierte Dateien nehmen.
Aber das müsste der User dann von Hand machen.
Jedes "Modul" sind 80 Tabellen, sprich 80 Dateien.
Es gibt 4 Module, also ca. 300Tabellen pro Migrationsimport.
Der User müsste also erst 300mal die Tabellen Exportieren und irgendwo horten.

Von diesen Migrationsimporten gibt es ca. 200
Sind also geschätzte 50.000 Tabellen, die es gilt mit dem Tool gilt von Superbase in Access zu migrieren.

Viel Spaß beim vorherigen Exportieren

 

[AlArenal]

Verstehe ich nicht wirklich, aber ich kenne ja auch eure Umgebung nicht.

Wenn ich mirgirere, dann doch nur einmal. Und es wird dem DBA doch wohl möglich sein alles auf einmal zu exportieren...

 

[tfa]

Sehe ich genauso. Es ist doch egal, wielange die Migration dauert. Meinetwegen ein ganzes Wochenende. Oder soll diese Aktion regelmäßig stattfinden?

 

[Verjigorm]

Verstehe ich nicht wirklich, aber ich kenne ja auch eure Umgebung nicht.

Wenn ich mirgirere, dann doch nur einmal. Und es wird dem DBA doch wohl möglich sein alles auf einmal zu exportieren...

Nö, Superbase kann immer nur eine Tabelle nacheinander exportieren, sonst würden wir es ja anders machen ...
Das scheiss Tool ist halt von 1987 oder so

Die Migration ist (hoffentlich) ne einmalige Angelegenheit, aber man weiss ja nie ....