Wegen den Lizensbestimmungen muss ich eines meiner Programme von MySQL
auf Firebird umschreiben.
Vorher hatte ich mich im Internet nach der Leistungsfaehigkeit von
FireBird erkundigt; und diese schien nicht schlecht zu sein.
Als dann die ersten Datenbank zugriffe liefen, schien mir FireBird doch
recht langsam zu sein. Worauf ich 2 kleine tests machte (localhost, also
kein Netzwerkzugriff auf einen Server):
1. Test: in einer Schleife 20.000 Inserts
2. Test: in einer Schleife 10.000 Selects wobei nach einem indiziertem
Feld gesucht wurde.
1. Test: MySQL: 8,6 sec. FireBird: 58,2 sec
2. Test: MySQL: 6,9 sec. FireBird: 29,6 sec
Bin schlichtweg ernüchtert. Werde nun PostgreSQL testen. Hoffe, dass
dieser etwas besser ist.
PS:
MySQL: v5.0.24
FB: v2.0.1
PC: XP P4 512 MB
Hallo Mehmet,
wie hast Du den die Transactionsklammern beim Firebird gesetzt?
Wenn Du bei jedem Insert ein Commit machst mußt Du Dich nicht wundern.
Man kann ein Rennpferd (Firebird) nicht mit einem Spielzeug (mysql)
vergleichen, wenn die Parameter des Tests nicht stimmen.
Gruß
Frank
Servus
Beim Firebird setze ich keine Transactions ein. Habe sie zwar nirgends
expliziet ausgeschaltet, aber auch nirgendswo mit "SET TRANSACTION" und
dann mit "COMMIT" diese aktiviert.
Selbst dann, wenn Transaction beim Firebird aktiviert waere: bei einem
simplen SELECT, wo es ja keine Transaktion gibt, haetten doch die Werte
nicht so weit auseinanderklaffen dürfen.
Gruss
Hallo,
Transaction sind beim Firebird immer aktiviert. Wenn Du mit
Starttransaction nicht eine Transaction öffnest, bzw. der verwendete
Treiber auf Autocommit steht, ist dem so.
Den Fehler den die meisten Leute machen, die eine Datenbank testen, sind
so ähnlich wie Deiner "mache mal zig-Tausend inserts oder selects" und
die dann schnellste nehmen wir.
Eine Datenbank muss danach ausgewählt werden was gebraucht wird! Wenn Du
Trigger benötigst Teile Deine Businesslogik in stored procedure ablegen
willst kommen nicht mehr viele Datenbanken in Frage. Hast Du ein
umfangreiches Beziehungsgeflecht, mußt Du mit vielen Joins arbeiten,...
Wieviele User müssen parallel arbeiten, mußt Du mehr selects als inserts
bearbeiten. Wie sieht es mit dem Transactionsverhalten aus.
Willst Du jedoch nur einen Container mit ein oder zwei Tabellen um
Massendaten abzufackeln, nimm MySQL reicht dann allemal.
Du siehst, viele Fragen und keine Antwort.
Ich arbeiten seit Jahren mit Firebird / Interbase, MSSQL, Oracle sowie
einigen Object-Datenbanken. Für jeden Anwendungsfall gibt es eine Lösung
und jede Datenbank hat ihre Stärken und Schwächen.
Am Beispiel Firebird: Unser größtes Umfeld knapp 500 User verteilt auf 5
Standorte mit einer zentralen Datenbank. Anbindung über Internet via
TCP-IP. Mehrschichtige Architektur. Die Datenbank muß hier jeden Tag
tausende von Zugriffen performant verarbeiten. Da spielt die Performance
der Datenbank und deren Threadfähigkeit eine große Rolle. In diesem
Umfeld haben wir MSSQL, ORACLE und Firebird getestet. Wir haben uns für
Firebird entschieden, weil das Kosten / Nutzen-Verhältnis stimmte. Mit
der ORACLE wären wir etwas performanter gewesen aber auch wesentlich
teurer. Da wir aber mit der Performance weiter über den Anforderungen
des Kunden liegen (Maskenaufbau innerhalb von 2 Sekunden), ist das gut
so. MSSQL ist ausgeschieden, weil der Datenbank-Server auf einem
UNIX-Rechner laufen muss. Von der Performance her war MSSQL an letzter
Stelle.
Gruß
Frank
Servus Frank
Der Grund, warum ich den Test so simple gehalten habe, ist der, dass
die Database Anforderung mehr oder weniger simple ist. Die Anwendung,
die auf Rund 20 Table zugreift (max. 5 user und die auch sehr selten
gleichzeitig), lief anfaenglich jahrelang als XBase Anwendung.
Als dann die Geraete, welche die Daten für die Database lieferten, auch
ausserhalb des localen Netzwerks plaziert werden mussten, wich ich auf
MySQL aus, da ich damit schon Erfahrung hatte.
Als dann mehrere Kunden die Daten nicht beim ISP sondern bei sich selbst
haben wollten, hatte ich natürlich ein Problem mit der Lizens.
Deshalb wich ich auf Firebird aus; aber damit habe ich ein Problem mit
der Geschwindigkeit.
Gibt es eine Möglichkeit, bei Firebird die Transaction abzuschalten? Ich
hab' nichts dergleichen gefunden.
MfG aus Istanbul
Hi nach Istanbul,
dann musst Du mir etwas über Deine Entwicklungsumgebung erzählen, das
Autocommit schaltet man in der Regel im verwendeten Treiber ab.
Aus Deinen Ausführungen entnehme ich, dass Du PHP programmierst stimmt
das?
Gruß
Frank
Servus Frank
Ich programmiere meist mit Visual FoxPro, wobei ich versuche, die
Datenbank wenn möglich auf einen Linuxserver zu plazieren. Der Zugriff
erfolgt dann wie üblich mit ODBC.
Beim ODBC, den ich verwende (runtergelanden von www.firebirdsql.org)
konnte ich keine Einstellmöglichkeit für Transaktionen finden. Bei der
Lektüre des Help-Files bestaetigte sich aber meine Vermutung:
"Firebird performs optimistic locking. Your transaction does not attempt
to lock a record until you issue an update operation that affects that
record."
Deshalb verstehe ich nicht, warum bei einem simplen SELECT FireFox 4x
langsamer ist als MySQL.
MfG
Mehmet
Hi Mehmet,
warum, verwendest Du MySQL nicht weiter, wenn Du bisher damit gearbeitet
hast?
Die MySQL ist OpenSource und steht Dir in Kombination mit Apache oder
IIE kostenlos zur Verfügung.
Kommen wir zum Firebird. Hier hast Du leider die schlechtest aller mir
bekannten Kombinationen gewählt. Ich habe bisher noch nichts über eine
gute Qualität und Performance gehört.
Lies Dir mal den folgenden Artikel durch, dann verstehst Du sicher was
ich meine:
http://derentwickler.de/itr/online_artikel/psecom,id,243,nodeid,56.html
Betrachten wir Dein Problem mal von einer anderen Seite. Du schreibst 5
User selten parallel. Dann brauchst Du Dir über Performance keine Sorgen
machen.
Rechne mal rückwärts, 10000 Selects in knapp 30sec. wo ist da das
Problem?
Implementiere das ganze mit Firebird, Deine Kunden werden keinen
Unterschied feststellen.
Wenn Du dann mal Zeit hast, überlege Dir ob Du die Anwendung nicht mit
einer anderen Sprache wie z.B. Delphi neu machst. Hier findest Du die
entsprechenden nativen Treiber für eine Vielzahl von DBs.
Wenn Du eine Oberfläche mit wenig Interaktionen hast würde ich sogar
eine Reimplementierung in PHP ins Auge fassen.
Gruß
Frank
Guten Tag Frank
Danke für den Artikel-Link. Haette nie gedacht, dass die Treiber einen
dermassen grossen Einfluss auf die Performanz haben.
Ich habe dann einen anderen (erstbesten) ODBC Treiber genommen (der
Firma XTG Sytems) und wau ....
.... mit diesen Ergenissen kann ich leben, da für mich ein schnelles
SELECT ausreicht.
Insert Test: Mysql (8,6 sec) / Firebird (30,6 sec) vorher waren's 58,2
sec.
Select Test: Mysql (6,9 sec) / Firebird ( 8,2 sec) vorher waren's 29,6
sec.
"Rechne mal rückwärts, 10000 Selects in knapp 30sec. wo ist da das
Problem?"
Es ist ja nie ein SELECT allein. Oft werden, um ein Resultat anzuzeigen,
die Werte von mehreren zusaetzlichen Tables abgefragt.
Ich werde bei Gelegenheit noch andere Treiber testen und dann die
Resultate hier festhalten.
MfG
Mehmet
Hallo Mehmet,
freut mich, dass ich Dir helfen konnte.
Aber Du brauchst Dir trotzdem keine Gedanken zu machen, auch wir
befüllen unsere Dialoge nicht nur aus einer Tabelle. Je nach
Bezugspunkt, kommen da ganz schnell bis zu 30 Tabellen für einen Dialog
zusammen.
Unser Kundendialog (CRM) ist so umfangreich, dass wir die Daten nur
seitenweise landen. D.h. je nach Tabulator (Pagecontrol) werden die
Daten geladen.
Da Problem ist auch Visual Foxpro als eine Art 4GL-Sprache bist Du
natürlich auf die Möglichkeiten von FoxPro angewiesen. Bei mir ist es
schon ca. 10 Jahre her, dass ich das letztemal damit programmiert habe.
Gruß
Frank
Eine eigene Frage?
Dieser Thread ist über 19 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.