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
MyISAM oder InnoDB? Query-Cache an? Das kann sehr große Unterschiede ausmachen. Als Alternative würde ich auch SQLITE in Erwägung ziehen.
Beide benutze ich in der Grundeinstellung. Also MySQL mit MyIsam. Werde mir SQLite mal naeher anschauen.
MyISAM mit einer richtigen Datenbank zu vergleichen ist ein wenig unfair, das unterstützt noch nicht mal Transaktionen.
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.