Einleitung Einleitung W ie und w as w urde getestet W ie

Einleitung
Page 1 of 7
Betrifft: Java oder PL/SQL?
Art der Info: Technische Background Info
Autor: Guido Schmutz ([email protected])
Quelle: Aus unserer Schulungs- und Beratungstätigkeit
Mit Oracle8.1 besteht neu die Möglichkeit, neben der Sprache PL/SQL auch Java zum Entwickeln
von serverseitigem Code zu verwenden. Java-Code wird wie PL/SQL in der Datenbank gespeichert
und ausgeführt.
Oracle wird die zwei Sprachen parallel weiterentwickeln und viele von uns werden in Zukunft beide
Sprachen verwenden, um Datenbank-Applikationen zu entwickeln. Die Kernfrage lautet deshalb:
Wann soll welche Sprache eingesetzt werden ?
Oracle selbst positioniert PL/SQL als robuste, prozedurale Datenbank-Sprache. Java wird als die
Sprache für die Implementierung von Komponenten bezeichnet. Ein wichtiges Kriterium, um
entscheiden zu können, ob Java oder PL/SQL verwendet werden soll, ist bei serverseitigen
Applikationen sicher die Performance von Datenzugriffen.
Im Rahmen der Vorbereitung unserer neuen Kurse „Java-DB“ und „PL/SQL-B“ haben wir einen
Performance-Test mit beiden Sprachen durchgeführt. Dieser Artikel präsentiert einen Ausschnitt
dieser Resultate und soll aufzeigen, was von Java und PL/SQL bezüglich Performance erwartet
werden kann.
Getestet haben wir bei beiden Sprachen eine SELECT und eine INSERT Operation jeweils auf
unterschiedlichen Datenmengen (100, 500, 1'000, 10'000, 50'000 und 100'000 Rows). Jeder einzelne
Test wurde 7 mal wiederholt, und es wurde immer nur das beste Resultat der 7 Versuche in die
Auswertung übernommen.
Die Tests wurden auf einer Oracle8.1.5 Datenbank jeweils auf einem NT Server, einmal mit 1, 2,
und 4 CPU’s vorgenommen. Die hier gezeigten Resultate stammen von der 4 CPU Maschine mit
256M Memory. Es wurden alle neuen Features von Oracle 8.1.5 verwendet, insbesondere für
PL/SQL gibt es einige neue Features, welche die Performance wesentlich verbessern.
Es gibt sowohl mit PL/SQL wie auch mit JAVA mehrere Varianten, um die SELECT- bzw.
INSERT-Operationen auszuführen. In diesem Artikel beschränken wir uns auf die jeweils beste und
die schlechteste Lösung für beide Sprachen.
Folgendes PL/SQL Codefragment zeigt das grundlegende Statement für diesen Test:
FOR rec IN (SELECT person_id, name, vorname, ... FROM person)
LOOP
tab(i) := rec;
i = i
END LOOP;
Java
http://www.trivadis.com/Images/JavaPerf_tcm16-7133.htm
15.09.2004
Einleitung
Page 2 of 7
Als beste Variante hat sich der SELECT über JDBC erwiesen, wobei das schnellste Resultat mittels
prepareStatement und der Oracle-spezifische JDBC-Methode defineColumnType
erreicht wurde.
PreaparedStatement stmt =
con.prepareStatement ("SELECT person_id, name, vorname,... FROM person");
((OraclePreparedStatement)stmt).defineColumnType (1, Types.INTEGER);
((OraclePreparedStatement)stmt).defineColumnType (2, Types.VARCHAR2);
...
ResultSet rs = stmt.executeQuery();
while (rs.next()) {
...
}
Die schlechtesten Resultate ergaben sich mit der Verwendung von JSQL. Bei JSQL werden die SQL
Befehle über embedded SQL in den Java Code aufgenommen und von einem Precompiler übersetzt.
#sql public static iterator SelectTestIter (int person_id, String name...);
...
#sql rs = {SELECT person_id, name, voranme, ... FROM person};
while (rs.next()) {
...
}
PL/SQL
Bei PL/SQL wurden die besten Resultate mit der neuen PL/SQL8.1 Bulk-Operation erreicht. Beim
SELECT wird das Bulk-Binding mit dem Schlüsselwort BULK COLLECT INTO ausgelöst.
OPEN c_per FOR SELECT person_id, name, vorname, ... FROM person;
FETCH c_per BULK COLLECT INTO person_id_tab, name_tab, vorname_tab, ...;
CLOSE c_per;
Die schlechteste Performance bringt die Verwendung von dynamischem SQL mit dem Package
DBMS_SQL.
cur := DBMS_SQL.open_cursor();
stmt := 'SELECT person_id, name, vorname, ... FROM person';
DBMS_SQL.parse (cur, stmt, DBMS_SQL.native);
DBMS_SQL.define_column (cur, 1, rec.person_id);
...
ret := DBMS_SQL.execute (cur);
WHILE (DBMS_SQL.fetch_rows (cur) <> 0)
LOOP
DBMS_SQL.column_value (cur, 1, rec.person_id);
...
END LOOP;
Folgendes PL/SQL Codefragment zeigt das grundlegende Statement für diesen Test:
FOR i IN 1 .. tab.COUNT()
http://www.trivadis.com/Images/JavaPerf_tcm16-7133.htm
15.09.2004
Einleitung
Page 3 of 7
LOOP
INSERT INTO person VALUES (person_id_tab(i), name_tab(i), ...);
i := i + 1;
END LOOP;
Java
Als beste Variante hat sich der INSERT über JDBC erwiesen, wobei das schnellste Resultat mit der
Verwendung der Oracle-spezifischen setExecuteBatch Funktionalität erreicht wurde. Dabei
werden einzelne INSERT Befehle zuammengefasst und mittels Bulk-Operation in die Datenbank
geschrieben. Vorbereitet wurde das Statement auch hier mit der prepareStatement Methode
und zusätzlich wurden Bind-Variablen verwendet, die jeweils im Insert-Loop mit den
entsprechenden Werten bestückt werden.
PreaparedStatement stmt =
con.prepareStatement ("INSERT INTO person VALUES (?, ?, ?, ... ");
((OraclePreparedStatement)stmt).setExecuteBatch(count)
...
for (int i=0; i<count; i++) {
stmt.setInt (1, person_id);
stmt.setString (2, name);
...
}
Die schlechtesten Resultate ergaben sich hier nicht mit JSQL, sondern mit Standard-JDBC, d.h. ohne
die obengezeigten Optionen. Zudem wurde das Statement jeweils im Loop, analog zum PL/SQL
Grundcode, aufgebaut und abgesetzt, aber ohne Verwendung von Bind-Variablen.
for (int i=0; i<count; i++) {
Statement stmt = con.createStatement();
String sql =
"INSERT INTO person VALUES ( " + person_id + ", " + name + ", " + ...;
stmt.executeUpdate(sql);
stmt.close();
}
PL/SQL
Bei PL/SQL werden wiederum die besten Resultate mit der neuen PL/SQL8.1 Bulk-Operation
erreicht. Beim INSERT wird dies mit dem Schlüsselwort FORALL ausgelöst.
FORALL I IN person_id_tab.FIRST() .. person_id_tab.LAST()
INSERT INTO person VALUES person_id_tab(i),name_tab(i),vorname_tab(i)...;
Die schlechteste Performance bringt auch hier, gleich wie beim SELECT, die Verwendung von
dynamischem SQL über das Package DBMS_SQL. Dies obwohl das Statement optimiert
abgearbeitet wird, d.h. nur einmal geparsed wird und Bind-Variablen eingesetzt werden.
cur := DBMS_SQL.open_cursor();
stmt := 'INSERT INTO person VALUES (:person_id, :name, :vorname, ...');
DBMS_SQL.parse (cur, stmt, DBMS_SQL.native);
FOR i IN 1 .. count
LOOP
DBMS_SQL.bind_variable (cur, 'person_id', person_id);
...
http://www.trivadis.com/Images/JavaPerf_tcm16-7133.htm
15.09.2004
Einleitung
Page 4 of 7
ret = DBMS_SQL.execute (cur);
END LOOP;
http://www.trivadis.com/Images/JavaPerf_tcm16-7133.htm
15.09.2004
Einleitung
Page 5 of 7
Die folgenden Graphiken zeigen die Resultate der einzelnen Tests. Es wurden jeweils die
schlechteste Lösung einer Sprache der besten Lösung der anderen Sprache gegenübergestellt und
umgekehrt. Die Lösungen entsprechen den vorgängig besprochenen Varianten.
Es sind nur die Resultate der Test mit Datenmenge 10'000, 50'000 und 100'000 Rows gezeigt. Die
Resultate mit den kleineren Datenmengen ergeben jedoch das gleiche Bild.
Die Y-Achse zeigt die Ausführungszeit in Sekunden, die X-Achse die Anzahl Rows. Das JavaResultat ist als Balken dargestellt, das PL/SQL-Resultat als Linie.
Beste Java vs. schlechteste PL/SQL Variante für SELECT
60
49.4
51.1
50
40
30
jdbc_sel_defined
24.81
25.45
plsql_sel_dbms_sql
20
10
4.98
5.14
0
ROWS_10000
ROWS_50000 ROWS_100000
Schlechteste Java vs. beste PL/SQL Variante für SELECT
70
57.31
60
50
40
sqlj_sel
28.59
30
plsql_sel_bulk_collect
20
10
0
5.7
0.53
ROWS_10000
8.67
2.59
ROWS_50000 ROWS_100000
Die Resultate zeigen, dass die schnellste Java-Lösung für den SELECT nur geringfügig schneller ist,
als die schlechteste PL/SQL-Lösung. Die beste PL/SQL-Lösung ist die absolut schnellste Variante,
sie ist bis zu 10x schneller als die Java-Lösung. Die beste und die schlechteste Java-Variante
http://www.trivadis.com/Images/JavaPerf_tcm16-7133.htm
15.09.2004
Einleitung
Page 6 of 7
unterscheiden sich nur wenig.
Es muss bei diesem Vergleich berücksichtigt werden, dass die schnellste PL/SQL-Lösung nur mit
statischem SQL (SQL-Statement muss bereits zur Kompilierungszeit bekannt sein) erreicht werden
kann, Java hingegen immer mit dynamischem SQL arbeitet. Die schnellste Variante für ein
dynamisches SELECT in PL/SQL (DBMS_SQL mit Array-Binding) ergibt für 50'000 Rows eine
Zeit von 12.22 Sekunden, was aber immer noch 2x schneller ist als Java.
Beste Java vs. schlechteste PL/SQL Variante für INSERT
350
310.73
300
250
200
jdbc_ins_batched
157.58
150
90.6
100
50
plsql_ins_dbms_sql
44.4
8.130.9
0
ROWS_10000
ROWS_50000 ROWS_100000
Schlechteste Java vs. beste PL/SQL Variante für INSERT
800
720.6
700
600
500
jdbc_ins
348.62
400
plsql_ins_forall
300
200
100
0
65.58
5.35
ROWS_10000
36.66
77.56
ROWS_50000 ROWS_100000
Die Resultate beim INSERT zeigen ein anderes Bild als beim SELECT. Hier ist die beste JavaLösung viel schneller, als die schlechteste PL/SQL-Lösung (mehr als 3x schneller). Die optimalste
PL/SQL-Variante ist auch hier besser als jede Java-Lösung, der Unterschied zur besten Java-Lösung
ist aber viel kleiner als beim SELECT.
Der Unterschied zwischen der besten und der schlechtesten Java-Lösung ist hier viel grösser.
Auch beim INSERT muss berücksichtigt werden, dass die beste PL/SQL-Variante wiederum nur
über statisches SQL erreicht werden kann. Die schnellste Variante für einen dynamischen INSERT
http://www.trivadis.com/Images/JavaPerf_tcm16-7133.htm
15.09.2004
Einleitung
Page 7 of 7
mit PL/SQL (BULK COLLECT INTO über Native Dynamic SQL) ergibt für 50'000 Rows eine Zeit
von 46.2 Sekunden, was praktisch identisch ist mit der besten Java-Variante.
Die Performance-Tests zeigen wie wichtig es ist, die jeweiligen Features der Sprache und deren
Eigenschaften genau zu kennen. Sowohl mit PL/SQL wie auch mit Java können LaufzeitUnterschiede von mehreren Faktoren (5x – 10x) erreicht werden. Es kann aber nicht immer die beste
Variante in der Praxis auch wirklich eingesetzt werden. Gerade bei PL/SQL sind die besten
Varianten immer gekoppelt mit statischem SQL.
Uns hat überrascht, wie gut Java bei diesen ersten Tests abschneidet. Insbesondere beim INSERT
sind die Unterschiede zu PL/SQL nur noch gering bzw. nicht vorhanden (bei dynamischem SQL).
Beim SELECT sieht es nicht ganz so gut aus, es kann aber erwartet werden, dass in einem nächsten
Release auch hier Verbesserungen folgen werden (insbesondere bei der Variante mit SQLJ).
Falls Sie den Code zu den Performance-Test wünschen, schreiben Sie mir bitte ein Mail und ich
werde Ihnen diesen zusenden.
Gute Performance mit PL/SQL und/oder Java wünscht
Trivadis AG
Guido Schmutz
Papiermühlestrasse 159
CH 3063 Ittigen b. Bern
Tel:
+41 31 928 09 50
Fax:
+41 31 928 09 51
http://www.trivadis.com/Images/JavaPerf_tcm16-7133.htm
15.09.2004