PreparedStatement

[roli_7]

Hallo allerseits.

Ich muss aus einer Excel-Datei Daten in eine DB einlesen. Als DB wird die HSQLDB 1.8 im "In-Prozess"-Mode eingesetzt. Nun, das hat auch funktioniert. Jedoch als ich zum ersten Mal die Testdaten geladen habe, musst ich zu meiner grossen Enttäuschung feststellen, dass für das Laden von Daten ca. 25 Minuten benötigt wurden.

Die Excel-Datei hat etwas über 17000 Zeilen, wobei pro Zeile etwa 19 Spalten enthalten sind. Ich dachte zuerst, dass das Lesen aus der Excel-Datei so langsam ist (jexcel.api wird eingesetzt) und habe es getestet. Es hat sich aber schnell gezeigt, dass das Lesen aus der Excel-Datei nur einige wenige Sekunden benötigt. Weitere Tests haben gezeigt, dass die Codezeile

pStm.executeUpdate();

an sich der Zeitfresser ist.

Ich habe danach weiter optimierten probiert, indem ich mit

pStm.addBatch();

anstatt

pStm.executeUpdate();

gearbeitet habe. Ausserdem habe ich erst nach 1000 Statements das

pStm.executeBatch();

aufgerufen und commit gemacht. So konnte ich das Laden von Daten in etwa einer Hälfte der ursprünglichen Zeit erledigen (etwa 12 Minuten). Für meine Begriffe ist das aber weiterhin sehr lange Zeit. Hat jemand damit Erfahrungen gemacht? Ist das wirklich so? Oder, könnte man da weiter noch optimieren?

Meine Maschine ist zwar nicht die schnellste: habe nur 1 GB RAM und die Applikation wird aus eclipse ausgeführt. Der Speicher ist sicher eher knapp. Aber, trotzdem finde ich es etwas beunruhigend, dass es so lange braucht.

Danke für jeden Hinweis bzw. Meinung.

 

[Kim Stebel]

warum benutzt du keine "richtige" datenbank? postgresql oder mysql zum beispiel? ich kenne zwar hsqldb nicht aber diese "datenbank als jar"-lösungen sind in der regel langsamer.

Und 1gb ram? was kostet mehr, 5 stunden deiner arbeitszeit oder 1 gb ram? ich hoffe ersteres...

 

[Guest]

warum benutzt du keine "richtige" datenbank? postgresql oder mysql zum beispiel? ich kenne zwar hsqldb nicht aber diese "datenbank als jar"-lösungen sind in der regel langsamer.

Ein altbekannter Mythos, der durch den Verbot der Veröffentlichung von Benchmarkergebnisse (Oracle, MSSQL) am Leben erhalten wird.

 

[roli_7]

warum benutzt du keine "richtige" datenbank? postgresql oder mysql zum beispiel? ich kenne zwar hsqldb nicht aber diese "datenbank als jar"-lösungen sind in der regel langsamer.

Und 1gb ram? was kostet mehr, 5 stunden deiner arbeitszeit oder 1 gb ram? ich hoffe ersteres...

Nun, ich brauche eine "In-Prozess" Datenbank. Heisst, es soll nicht extra installiert werden müssen, da sie innerhalb der Applikation ausgeführt wird. In der Regel arbeite ich mit PostgreSQL, aber meines Wissens sind weder PostgreSQL noch MySQL eine "In-Prozess" Datenbank.

Und was Speicher anbelangt: du hast recht. Leider muss ich mit meiner Maschine etwa noch ein Jahr ausharen. Ein wechsel gibt es einmal in drei Jahre! Ausserdem darf ich auch keine all zu hohe Ansprüche an die Zielsysteme stellen. Es kann durchaus sein, dass das Zielsystem auch so wenig Speicher hat.

 

[tuxedo]

H2 soll schneller und besser sein als HSQLDB ... --> http://www.h2database.com/

Probiers doch auch mal damit.

 

[Gast]

Ok, kritisiert mich nun wie ihr wollt aber, ich würde mal folgendes Probieren.(nur um zu sehen ob es klappt und um wieviel es schneller läuft und so...)

Da eine Hsqldb inserts eigentlich sehr simpel in einer Textdatei ablegt (Quasi nur das Statement "as is", einfach mal anschauen). Warum könnte man dann nicht einfach dieser Datei (sofern die DB nicht läuft) einfach die Statements hinzufügen und danach die Datenbank mit allen nun vorhandenen Daten starten?

 

[tuxedo]

Warum sollte das auslesen von 17.000 Zeilen aus einer Datei und automatische laden (was ja auch per java code passiert) in den Speicher schneller gehen als das laden von 17.000 Zeilen direkt über den Programmcode?

Wenn die Grafik stimmt geht's mit H2 rund 3mal schneller ..

- Alex

 

[Gast]

Mir fallen da ein paar gründe ein warum das per Programmcode schneller gehen könnte:

1. "Verbindungs"- "JDBC" Overhead der nicht zwangsläufig sein müßte.
(Fall 1rogramm kommuniziert per jdbc mit der DB, DB schreibt in seine Datei vs. Fall 2 Programm schreibt direkt in Datei)

2. Constraints, PK-Constraints muß die DB-jedesmal prüfen wenn es einen insert gibt. Sollten die Daten aus dem Excelsheet, bereits Constraints-Konform sein, kann ich mir diese Überprüfung sparen. Beim letzten Eintrag in die DB muß ich unter umständen 16999 mal prüfen, ob der PrimaryKey oder ein Unique Constraint verletzt ist.

 

[robertpic71]

1.) Ist Autocommit ausgeschaltet?
2.) Wurde die Datenbank bzw. die Tabelle mit irgendeiner Codepage erstellt?
3.) Gibt es längere Felder? in dem Satz?
4.) Gibt eines primary Key? wenn ja, kommt er aus der Exceltabelle

Ohne jetzt auf HSQL einzugehen, die mir bekannten Bremser bei INSERT:
1.) Autocommit
2.) Charsetkonvertierungen
3.) Lange Felder in CLOB oder BLOB's
4.) Viele Indexfelder bzw. Indexe und Contraints über die Datei
Mit jedem Satz muss geprüft/aktualisiert werden. Bei manchen
Datenbanken ist es schneller die Tabelle zu füllen und erst
nachher die Indexe/Contraints anzulegen.

/Robert

 

[roli_7]

Ich habe auf meine eingene Frage zwar die Antwort schon geschrieben, aber, irgendwie finde ich sie nicht mehr hier. Köntne es sein, dass sie gelöscht wurde? Oder, ich habe ein falsches Forum erwischt.

Es lag offenbar an meinem System. Nach einem Neustart sah die Welt anders aus. Das Laden von Daten aus der Excel-Datei wurde, zu meiner grossen Feude, in weniger als zehn Sekunden erledigt. Mir ist erst danach klar geworden , dass ich mein System etwa drei Tage nicht wirklich ausgeschaltet habe (ein Laaptop) und es immer nur in StandBy versetzt habe . Vermutlich hat sich im Speicher so einiges angesammelt, was nur gestört hat.

Ein grosser Dank an alle, die helfen probiert haben.