MySQL PreparedStatedment ist zu langsam?

[keram]

Hey Leute,
ich habe auf meinen Rechner lokal eine Datenbank mit XAMPP aufgebaut.
Nun schreibe ich mit meiner Java Application in diese Datenbank einen Haufen an Daten.
Inerhalb des Programmes wird eine PreparedStatement mit 100.000 Datensätzen zum Batch hinzugefügt. Lasse ich nun die Batch ablaufen, schreibt das Programm die Daten nur sehr langsam in die DB ( 5-10 Datensätze pro Sekunde ). Nun wundere ich mich das die Daten so langsam geschrieben werden und ich wundere mich ob dieses nicht schneller geht...

Ich habe in der Tabelle nur 2 Spalten, diese werden ohne Index geführt.

Ich würde mich um eure hilfe freuen

 

[Flown]

Code + Query wären hilfreich, dann kann man sich das mal ansehen.

 

[kneitzel]

Wenn es darum geht, schnell viel neue Daten in eine Datenbank zu schrk eiben, so ist das Bulk Insert meist das Mittel der Wahl. Das wird auch von MariaDB (die Teil von XAMPP ist) unterstützt:
https://mariadb.com/kb/en/mariadb/how-to-quickly-insert-data-into-mariadb/

Ansonsten kann man natürlich den Code anschauen und dort evtl. noch das eine oder andere optimieren, aber erfahrungsgemäß kommt man an das Bulk Insert nicht heran.

 

[thecain]

5-10 Datensätze pro sekunde scheinen mir ein Grundlegenderes Problem zu sein...

 

[keram]

Hey Leute, danke erstmal für eure Antworten.

An meinen Sourcecode liegen keine Probleme vor, die Daten werden inerhalb von 1-2 Sekunden geladen.
Momentan kann ich nicht auf meine Sourcen zugreifen, ich werde nachher mal den Bulk Insert testen und einige Einstellungen an meiner Connection vornehmen.

Habt ihr noch ein paar Tipps für mich um meine Connection zu verschneller? Habe bis jetzt gelesen das es vom Vorteil sein soll rewriteBatchedStatements auf true zu setzen...

Mfg Marek S.

 

[Joose]

An meinen Sourcecode liegen keine Probleme vor, die Daten werden inerhalb von 1-2 Sekunden geladen.

Ja du schreibst aber von Problemen beim Schreiben schreiben!=laden

Habt ihr noch ein paar Tipps für mich um meine Connection zu verschneller? Habe bis jetzt gelesen das es vom Vorteil sein soll rewriteBatchedStatements auf true zu setzen...

Die "Connection" schneller machen geht nicht. Man kann aber eben die Statements und Tabellen optimieren.

Natürlich kommt es auch darauf an wo wirklich die Zeit liegen bleibt.
Was wurde von dir gemessen das du auf 5-10 Datensätze/Sekunde gekommen bist? Wirklich nur die Datenbankzeit oder auch etwas von deinem Code?

 

[keram]

@Joose
Meine Daten packe ich alle in eine Map<String, String>, dabei werden die Daten ausreichend schnell dort hinein geschmissen.
Nachdem ich die Daten in die Map gepackt habe und die Map eine Größe von >100000 hat, schreibe ich die Daten in meine Batch des PreparedStatements.

Die Engine meiner Tabelle wollte ich später auf MyISAM ändern, da diese doch wesentlich performanter sein soll.

Ich muss meine Connection jedoch noch optimieren das sie momentan nur auf dem Defaultmodell des JDBC liegt, meine Frage bezieht sich auf Packetgrößen und weitere Optimierungen die euch noch einfallen.

Habt ihr eine Guide der mir beschreibt wie ich die Tabelle noch optimieren kann? Die Tabelle beinhaltet lediglich zwei Strings pro Zeile.

Die 5-10 Datensätze sind nur ein Schätzwert, jedoch benötigt das Schreiben in die Datenbank die meiste Zeit des Durchlaufes.

 

[kneitzel]

Also ehe ich anfangen würde wild zu optimieren würde ich die Schwachstelle heraus suchen. Ist der Datenbankserver voll funktionsfähig und hat er die erwartete IO Leistung? Ich kenne MariaDB nicht im Detail. Bei MS SQL Server wären das die Tools SQLIO und SQLIOSIM, die den Server testen und die IO Leistung messen würden.

Und dann sollten Datenbanken auch offenbaren können, wie diese Anfragen ausführen. MS SQL bringt dazu einen Profiler mit. Und man kann sich Execution Plans ansehen und all sowas.

Dann ist die Frage nach vorhandenen Indices (die es Deiner Aussage nach nicht gibt) und ggf. der Einfüge-Reihenfolge sowie der Einstellungen für die Behandlung der Datenbank-Seiten. (Nicht, dass man die Datenbank auffordert, ständig in bestehenden Seiten einzufügen und dabei dann durch mangelhafte Einstellungen Optimierungen antriggert, so dass durch Inserts ständig viele Seiten neu geschrieben werden müssen)

Dann kann auch das Recovery Model / verwendete Transaktionen eine Rolle spielen. Wobei da dann eher die Frage ist, wieviele Zugriffe gleichzeitig durchgeführt werden und wie die sich gegenseitig beeinflussen.

Ist also alles nicht unbedingt ganz trivial. Aber das macht den Job der Datenbank Administrators auch erst interessant.

 

[thecain]

Ich behaupte immer noch das da was sonst falsch ist. 1000 inserts pro Sekunde sollten keine Probleme darstellen. v.a. bei so geringen Datenmengen.

 

[kneitzel]

@thecain Damit wirst Du auch bestimmt richtig liegen, es sei denn, das System ist aus irgend welchen Gründen unter sehr hoher Last / generell wenig Leistungsstark.