MS SQL-Server oder Interbase (Firebird) ?

[Andreas Kosch]

Hallo,
&gt;..dann keinen eigenen Server für die DB hinstellt <br><br>
in der Tat. Dann sollte der Universal-Server aber genug parallel ansteuerbare Festplatten haben, damit man die Filegroups (Daten-Tabellen, Index-Daten, Transaktions-Log) der MS SQL Server-Datenbank auf verschiedene Festplatten (noch besser: Festplatten-Arrays) legen kann. Denn bei den Heute üblichen CPU-Leistungen bzw. dem RAM-Ausbau des Servers sind die mechanischen Festplatten das größte Problem. Wer einmal mit einer SAN (Storage Area Network) mit FibreChannel-Anbindung und aktiviertem Schreib-Cache (die SAN hat eine interne gepufferte Stromversorgung für ihre Controller/Festplatten und garantiert somit die Transaktions-Gültigkeit) hantieren durfte, für den erhält das Wort "Geschwindigkeit" eine völlig neue Bedeutung :-

[Ralf Eberhard]

Hallo,
vielen Dank für euere Antworten.
Ich kann leider keine PraxisTests mal mit der DB, dann wieder mit der DB durchführen.
Auf die Hardware-Konfiguation haben wir keinen Einfluß.
Erst mal darüber schlafen und dann sehen, welche DB zum Einsatz kommt.

Gruß

Ralf Eberhar

[Klemmo]

zur vorherigen mail:

"Wenn FB doppelt so schnell ist, aber nach 2 Stunden aus
irgendeinem Grund irgend ein GarbageCollect machen muss
und dann für 5 Minuten keine Daten liefert, wäre das auch fatal.
Hey, bevor ihr über mich herfällt, das ist nur mal ein theoretischer
Denkanstoss, soll nicht heissen, dass sowas bei FB wirklich passiert, könnte genausogut umgekehrt sein."

Der garbagecollector in firebird 1.5 läuft recht unspektakulär im Hintergrund, ganz anders als noch bei älteren Interbase versionen.

Das Problem ist seltener der durchlaufende Garbagecollector
Thread, sondern eher die neuen Transaktionen, Deletes und Updates, die auf einer "vergurkten" Datenbank ablaufen sollen.

Ein Beipiel von vor einiger Zeit: Ein großer Telefonanlagenhersteller hat ein Programm geschrieben zum Auslesen der Daten und übertragen in einen datenbankserver.

Das ganze geschieht ein mal pro Tag und es wurden über diverese serielle Kanäle mit diversen (10-20) Threads Daten ausgelesen und parallel in die Datenbank geschrieben.

Typische Tagesdatenmenge waren 100000 Datensatzgruppen (master mit ein paar details und relationen zu konstanten stammdatentabellen).

Pro Datensatzgruppe hatte IB6 dabei ca 50ms verbraucht, also wurden ca 20 Gruppen pro Sekunde verarbeitet. Daran liess sich nicht sonderlich viel optimieren, weil die Hardware eh nicht mehr lieferte.

Die automatische Garbagecollection lief gar nicht, weil das sweep interval auf 0 stand. Es konnte also nur die Garbagecollection laufen, wenn im Rahmen von SQL Befehlen pages besucht wurden mit veralteten Transaktionen. das geschieht bei Inserts normalerweise aber nicht, warum auch, denn die werden immer hinten angehängt.

weil man in dem Programm 3 entscheidene Fehler gemacht hat, kam es zu Problemen:

1. weil fast nur inserts gemacht wurden und kam es nicht zum Anstoß des Garbagecollectorthreads

2. weil man autocommit benutzte, wurden pro datensatzgruppe statt einer transaktion ca 50 verbraten

3. Es gab ein einfaches überwachungsprogramm, welches nur beim programmstart ein tquery.open macht und sonst gar nichts gemacht hat

Wie äußerte sich das Problem? nach verarbeitung von mehreren tausend Datensatzgruppen wurde die zeit pro gruppe immer langsamer.

Am ende braucht das System pro Datensatzgruppe ca eine Sekunde. Da ein Tag aber nur 86400 Sekunden hat, kam es zu einem Engpass bei 100000 Sätzen pro Tag. Warum?

1. Wegen fehlender Garbagecollection stand die "oldest transaction" immer auf einem sehr kleinen Wert, der beim Programmstart aktuell war. Für jede neue Transaktion holt sich der Firebird Server immer ein Speicherabbild der globalen Transaktionsinventory Page von der ältesten transaktion bis zur nächsten Transaktion, weil im rahmen der MGA klar sein muss, wer committed ist und wer nicht. Wenn zwsichen diesen Werten sehr viel Platz ist, dann dauert das eben.

Pro Transaktion sind das schon mal einige kB, die beim Starttransactionbefehl kopiert werden müssen, obwohl die bei den inserts nicht gebraucht werden. Nun denn, die engine arbeitet immer so und kann ja nicht raten, ob nicht doch noch andere befehle kommen. Auf diese Weise hätte die Garbagecollection nach dem Durchlauf den Wert der ältesten Transaktion nach oben korrigieren können und beim Start jeder Transaktion einiges an zeit eingespart werden kann.

2. Durch autocommit wird der oben genannte effekt noch deutlicher, weil eben mehr transaktionen als erforderlich verbraten werden.

3. Das Offenhalten einer alten Transaktion blockiert die Garbagecollection komplett. Daher immer drauf achten, das so etwas nicht passiert. Wenn gleichzeitig noch viel Update oder delete Befehle laufen, dann wird der negativer Effekt dieser selbst verursachten Problem noch wesentlich stärker.

Wenn jedoch diese Punkte vom Programmierer berücksichtigt werden, läuft so eine Firebird oder IB Datenbank (wie bei o.a. Kunden) auch nach 100000 Sätzen mit der gleichen Geschwindigkeit, weil die Garbagecollection das Aufräumen im Hintergrund erledigt.

Wir haben auch Kunden die 500000-1000000 Datensätze pro Tag in die Datenbank schreiben und auch das problemlos rund um die uhr geht, obwohl mehrere prozesse lesend darauf zugreifen mit verschiedenen sql befehlen.

Die interne Schreibgeschwindigkeit liegt je nach Tabellenstruktur bei ca 20000-30000 records pro Sekunde hier auf meinem 1,7Ghz
Laptop, Lesen funktioniert mit bis zu 50000 Records pro Sekunde
(entweder mit index von größeren Tabellen oder eben auch ohne index, dann sequentiell auf der Tabelle, werte in einer 1,5GB Datenbank mit FB15). Wie schnell man das nach außen bekommt, hängt von vielen Faktoren ab. Nutzt man Stored Procedures, Netzwerkbelastung, Schnittstelle, Datenmodell, ....

Der Ansatz mit einem SAN ist ja ganz ok, ich hab auch schon komplette Datenbanken alternativ auf RAM Disk betrieben (die bisher größte hatte 5GB), ist zwar gefährlicher, aber wenn Geschwindigkeit wichtiger als alles andere ist und man durch Replikation immer noch eine aktuelle physikalisch auf platte hat, ist das selten ein Problem gewesen. War jedenfalls wesentlich preiswerter als ausgewachsene SAN Systeme.

Und 1 GB geht bei FB15 als Cache auch ohne tricksereien, das reicht für typische Datenbankanwendungen schon sehr oft aus, auch ohne irgendwas über Filegroups, Position der Indexdaten und Transaktionslogs zu wissen.

Größere Datenbanken sind auch selten ein Problem mit 1GB Cache, wenn man bei SQL Befehle nicht nach dem Motto erzeugt, das geht bei MSSQL oder Oracle auch so, also muß das bei Firebird genauso gehen (ich hatte vor einigen Wochen ein SQL von einem Kunden, welches ausgedruckt 5 DINA4 Seiten in 10 Punkt Courier war. Das lief zwar auch auf firebird, aber braucht die dreifache zeit verglichen mit dem Oracle Server. Nach Umsetzung als Stored Procedure in FB war es 10 mal schneller und wesentlich einfacher zu verstehen. Jetzt versucht der Kunde das in der Oracle Version von seinem Spezi dort auch auf ein ähnliches Tempo zu bringen, noch hab ich von dem nichts dazu gehört).

Gerade wenn die Hardware der Kunde bestimmt, wird der ein SAN oder teures Array mit diversen Platten nur dann akzeptieren, wenn es zwingend erforderlich ist und auch zum Preis des Gesamtprojekts passt. Wer eine Software liefert, die im 4-stelligen Eurobereich liegt, macht sich unglaubwürdig, wenn nur Hardware und Lizenzkosten im oberen 5-stelligen Eurobereich gut genug sein soll.

Da ich aber euer Projekt nicht kenne, kann ich nur auf Basis meiner Erfahrungen sagen, das so manches 5-stellige Projekt mit Datenbankhardware aus dem unteren 4-stelligen Eurobereich problemlos arbeiten kann, jedenfalls mit Firebird und wenn eben gewisse Fehler nicht gemacht werden. Und fehlerhafte Programmierung kann auch die beste Hardware nicht ausgleichen.

Holger
www.h-k.de/fbct/fbct.pdf

p.s.:

1000 sätze pro Sekunde zu senden, gut vorbereitet durch eine Stored Procedure in der Datenbank, sollte erst mal kein Problem darstellen. Wenn der Auswahlgenerator dann eben statt eines SQLs gleich passende Stored Procedures erstellt, weil die ja wahrscheinlich auch mehr als einmal benutzt werden, macht das für den Server schon deutliche Vorteile. Es könnte je nach SQL aber auch ohne SP klappen. Und die 300000 Sätze liegen locker ständig im Cache

[Klemmo]

noch etwas: bei den Datenmenge würde ich über ADO aber erst mnach diversen Tests nachdenken, ich gehe fest davon aus, das der Flaschenhals dort euch zukünftig einige Probleme machen wird. Das ist nur meine persönliche erfahrung mit ADO. Übertragungsverfahren für SQL Befehle und optionale Abholung von Resultsets gehen mit anderen Techniken wesentlich schneller.

Holge

[hwoess]

Da hat sich dann wohl bei Firebird in den letzten 3 Jahren viel getan. Du machst mir Gusto, FB wieder mal ernsthaft für meinen Einsatzbereich auszutesten. Vor allem, da SQL 2005 auf Framework2 beruht und ich nicht sicher bin, wie schnell ich dann damit wieder bei allen Kunden glücklich werde.
Allerdings hat mir dein Beispiel gezeigt, dass ein eigener Test auch komplett falsch ausgehen kann, wenn man im Testprogramm Fehler im Datenbankzugriff macht. Ich werde also auf dein Buch bzw. deine Doku warten ;-))
Mein Schwerpunkt liegt nicht in der Geschwindigkeit, da ich jetzt nicht mehr mit Maschinen zu tun habe. Allerdings spielen dafür Unicode, lange Strings, starker Einsatz von stored procs und Triggern zur Protokollierung und Kontrolle der Geschäftslogik sowie eine stabile und fehlertolerante Verbindung des Clients über Internet die wesentliche Rolle.

bye,
Helmu