MySQL/DB2 Storage Engine

[KM]

Hallo,

seit einiger Zeit gibt es ja die Möglichkeit über eine Storage Engine z.B. von PHP über die integrierten MySQL-Befehle direkt auf die DB2-Daten der iSeries zuzugreifen. Wir haben das jedoch noch nicht so implementiert, sondern greifen momentan über ODBC (iSeries Access ODBC-Treiber für Linux) darauf zu. Da diese Zugriffe jedoch nicht sonderlich schnell sind, überlegen wir das evtl. über diese MySQL Storage Engine abzuwickeln.
Hat da zufällig jemand schon Erfahrung damit (vor allem bzgl. Performance)? Ich hatte jedoch teilweise gelesen, dass Stored Procedures bzw. Functions nicht verwendet werden können. Ist das korrekt? Wir rufen derzeit nämlich von PHP aus externe Stored Procedures auf, hinter denen sich ganz normale RPG-Programme verbergen.

Gruß,
KM

[Fuerchau]

Das wird deine Performanceprobleme auch nicht lösen sondern eher verstärken.
Du schiebst nur eine 2. SQL-Ebene dazwischen. MySQL greift wiederum per SQL auf die DB2 zu.

Die Performanceprobleme liegen nicht in der SQL-Kommunikation (Millisekunden) sondern in deinen Prozeduren.

[UFK]

@Fuerchau

kannst Du das denn so mit Bestimmtheit sagen, ohne die SQL-Befehle zu kennen, die per ODBC übertragen werden, und ohne die Stored Procedures vorliegen zu haben ??

Ich habe schon recht komplexe SQL-Stored-Procedures geschrieben, welche intern aus Dutzenden Unter-Prozeduren, UDFs und noch mehr SQL-Befehlen bestanden, mit 1, 2 oder 3 Schleifen verschachtelt und teilweise sogar rekursiv programmiert. Sie wurden mit einem kurzen CALL oder SELECT f(x) from DUAL von außen aufgerufen, und lieferten mal Tabellen als Resultsets, und mal komprimmierte Ergebnisse bzw. hochgerechnete Resultwerte.

Wenn Du diese SQL-Befehle (die da in der SP AS400-intern liefen), von aussen aufgerufen hättest, hattest Du z.B. hundert mal länger warten müssen, allein schon durch den längeren IP-traffic.

Nee, mit Deiner Antwort bin ich also nicht zufrieden.

Stimmt es denn, daß Stored-Procedures über PHP nicht aufgerufen werden können, oder ist es nur noch nicht vorgesehen, reine SQL-stored Procedures über PHP zu erzeugen und dann nutzen zu können ?

Z.B. deswegen, weil die in der AS400 erstmal in ein CLE-Programm kompiliert werden müßten, was noch etwas Programmierarbeit von IBM verlangt ?

Mit Spring & Hibernate und über JDBC haben wir genau das nämlich schonmal ausprobiert, und es strategisch gesehen als Ideal-Lösung betrachtet, also dass die ganze Logik in der Spring & Hibernate-Anwendung stecken könnte ...

[Fuerchau]

Dann hast du mich falsch verstanden.
Das Absetzen eines SQL's per ODBC dauert tatsächlich nur Millisekunden.
Was die SQL-Ausführung dann leisten muss ist ein eigenes Thema.
Der Traffic beim Empfang von Resultsets hängt nun mal immer von der Menge der Daten ab.

Komplexere SQL's in Prozeduren zu verlegen macht eben Sinn, wenn man die Logik einer Anwendung eben in die SQL-Schicht verlegt (Stichwort BusinessLogik, ThreeTier-Application).

PHP kann natürlich SQL-Prozeduren aufrufen, das wird ja schon gemacht.
Allerdings muss man die Implementierung von MySQL mit Zugriff auf die DB/400 betrachten.

Prozeduren und Funktionen lassen sich ja per CREATE PROCEDURE/FUNCTION in SQL-Syntax jederzeit erstellen und sind dann auch aufrufbar.
Das hat nichts mit PHP zu tun sondern gehört eben zu SQL. Dabei ist das unerheblich ob ich das per embedded SQL, STRSQL, REXX, ODBC oder sonstigen SQL-Interfaces mache.

Man kommuniziert mit MySQL und nicht mehr mit der DB/400. Allerdings speichert MySQL seine Daten in der DB/400, so dass ein gemeinsamer Zugriff zwischen MySQL und AS/400-Programmen möglich wird.

Also das Erstellen von Tabellen und Views sowie das Ausführen von SQL's (Select/Insert/Update/Delete) werden per SQL an die DB/400 weitergegeben.

Das Aufrufen von Prozeduren und Funktionen erfolgt aber in der MySQL und werden nicht an die DB/400 weitergegeben, was durchaus Sinn macht, da man ja mit MySQL arbeiten will.

Die oben genannten Performanceprobleme sind damit also nicht lösbar.
Man muss also untersuchen, was die Prozeduren denn so lange treiben bis sie zu einem Ergebnis kommen.

[BenderD]

... ich lasse mal den QUOTE weg.
das sind jetzt aber 2 Ebenen, einmal stored Procedures oder nicht und zum anderen ODBC oder DB2 als storage Engine für MySQL:
Ausgangslage:
PHP Anwendung auf einer Linux Büchse
Datenbank DB2 auf einer AS/400
ODBC oder MySQL mit der DB2/400 als storage Engine?
- von der Geschwindigkeit gibt sich das vom Grundsatz nichts, es sei denn einer der Treiber ist besser!!
Stabilität und Support ist auch beim besseren Treiber zu erwarten.
Konsequenz:
- weiter ODBC nutzen, der anderen Variante fehlt (noch?) die kritische Masse
- strikte Schichtentrennung in der Anwendung (muss man bei PHP sicher Klimmzüge machen), damit ein Wechsel der beiden Varianten mit minimiertem Aufwand möglich ist.

Mit den stored Procedures/Functions, das ist dann noch ein Zusatzaspekt, der momentan auch eher für die ODBC Variante spricht.
Wobei ich das eher kritisch einschätze, Geschäftslogik gehört nicht in die Datenbankschicht und schlechtes Datenbankdesign kann man auch anders als mit stored Procedures heilen. Naja, und so manches als stored Procedure verkleidete RPG Programm klappert auf hunderten von Programmzeilen mit RLA durch die Datenbank und sucht Daten zusammen, was mit einem SQL Statement in 3 Zeilen besser zu erledigen gewesen wäre und selbst wenn das zum Zeitpunkt der Programmierung ein paar Millisekunden, zumindest gefühlte, gebracht hätte, beim übernächsten Release hat sich das messbar in die Gegenrichtung gedreht.

D*B

[KM]

Hallo,

vielen Dank erst mal für die rege Diskussion. Da aber hier diverse Dinge falsch verstanden werden, möchte ich die Situation erst noch ein wenig genauer erläutern.

Es geht hier nicht um die Ausführungszeit der Prozedur, sondern rein um den odbc_connect von PHP (@Fuerchau). Zu diesem Zeitpunkt wird noch keine Prozedur aufgerufen. Die Antwortzeit dabei hält sich zwar noch in Grenzen (ca. 0,5 - 1 sec.), jedoch wollen wir eben prüfen, ob es doch eine Möglichkeit gibt dies zu optimieren. Wir hatten inzwischen auch schon Connection Pooling und odbc_pconnect versucht, was deutlich was gebracht hat. Aber nach einer gewissen Zeit war die Webseite nicht mehr aufrufbar, so dass der Apache jedesmal neu gestartet werden musste und wir das wieder zurückgeändert haben.

Dann ist mir eben die Sache mit der MySQL Storage Engine eingefallen. Und da PHP ja am besten mit MySQL eingesetzt wird, dachte ich ich könnte mit dieser Storage Engine arbeiten, um Daten von der DB2 zu empfangen. Es würde sicher gehen, wenn wir nur die normalen CRUD-Operationen bräuchten. Das ist aber nicht so, sondern wir rufen bisher per SQL-CALL direkt externe Stored Procedures auf, die auf der iSeries erstellt wurden. Per ODBC funktioniert das auch. So wie ich jedoch die Doku zur MySQL Storage Engine verstanden habe, geht es damit offenbar nicht. Ich bin gerade dabei diese Storage Engine mal zu installieren und werde es mal testen. Bin mal gespannt was dabei herauskommt.

Dieter hat es eigentlich auf den Punkt gebracht. Es geht um den Vergleich der Treiber ODBC vs. MySQL Storage Engine. Und ob man über diese Engine eben auch SPs aufrufen kann.

Da diese SPs bzw. die dahinter liegenden RPG-Programme komplexe Daten ermitteln, müssen wir das so beibehalten. In einen SQL 4-Zeiler kann man das leider nicht verpacken.

Ich dachte halt, dass es evtl. schon mal jemand so verwendet hat.

Gruß,
KM

[BenderD]

...habe keine Erfahrungen mit PHP, aber mit Connection Pooling unter Java, da gibt es das Problem auch, kann man aber in den Einstellungen des Pools dran drehen, um das in den Griff zu bekommen.
zum anderen erscheinen mir die Connect Zeiten doch sehr zäh zu sein, das muss m.E einen Grund haben, den man rauskriegen müsste.

D*B

es doch eine Möglichkeit gibt dies zu optimieren. Wir hatten inzwischen auch schon Connection Pooling und odbc_pconnect versucht, was deutlich was gebracht hat. Aber nach einer gewissen Zeit war die Webseite nicht mehr aufrufbar, so dass der Apache jedesmal neu gestartet werden musste und wir das wieder zurückgeändert haben.
KM

[Fuerchau]

Da PHP je eine Scriptsprache ist, muss man bedenken, was für den Verbindungsaufbau vorher bereits geleistet werden muss bis es zum eigentlichen Connect kommt.
Immer, wenn eine Seite neu geladen wird, muss auch der Treiber neu geladen und initialisiert werden.
Und das wird wohl das Hauptproblem sein. Da hilft auch das ConnectionPooling ggf. nicht so besonders.

Was man beim Pooling unbedingt beachten muss ist, dass man hinter sich immer aufräumen muss.
D.h., Cursor müssen geschlossen werden, Statements müssen geschlossen werden.
Unterlässt man dies, bleiben die Ressourcen bestehen und irgendwann sind diese halt erschöpft, was eben den Neustart erzwingt.

Mit meinem Java-Progrämmchen ohne ConnectionPooling dauert eine Aktion von Connect, Select, Update, Insert, Disconnect insgesamt nur 0,5 - 0,8 Sekunden.
Dabei wird sowohl eine Verbindung zur AS/400 als auch zu einer Oracle-DB aufgebaut, also insgesamt alles 2 Mal.

Allerdings bleiben die Treiberressourcen ständig geladen und müssen nicht immer neu gestartet werden.

Vielleicht kann man dem PHP-Script ja einen Serverdienst anbieten der im Hintergrund alle Anfragen per SQL dann weiterleitet.

Ich denke nicht, dass man mit einem anderen Treiber da schneller wird.