Performance der Datenbank testen

[ak1]

Hallo Leute,

Ich möchte die Performance von Paradox (BDE) und Firebird (IB-Komponenten) in einer Delphi-Anwendung miteinander vergleichen. Dafür werde ich jeweils die Zeit in einer Datei speichern.
Da ich das nur abends zu Hause mache, wollte ich euch mal fragen ob ihr eine gute Idee habt, mit was für einer Procedure ich das am besten testen könnte.
Es müssen Table-Komponenten und Query's verwendet werden und diese Procedure sollte bei Paradox mind. ein paar Minuten dauern. Immer her mit euren Ideen. Irgendwelche Berechnungen oder sowas.

[Robert_G]

Ich würde das Ganze trennen:

• INSERT
• UPDATE
• DELETE
• SELECT
• Transaktionen

Lass dir in einer Delphi Anwendung 5 Statement-Listen zufällig erzeugen.
Die Tabellen sollten die gleichen Spalten haben und die max. mögliche Optimierung, die die DB zulässt (z.B.: Indizes).
Die Statements lässt du dann auf beiden DBs laufen.

Für den Transaktionsaktionstest würde ich zuerst ein Menge DML auf die DB loslassen (die ersten 3 Statementlisten, nur wenige Transaktionen dazwischen) und zwischendurch mal ein Commit, Rollback,... absetzen.
Danach viele Transaktionen nach wenigen Statements (das kann auch aus den ersten drei gebastelt werden).

[ak1]

Ich habe es mir mal etwas einfach gemacht und folgende Schleife durchlaufen lassen:
Es werden 2,5 Millionen Zufallszahlen (5*500.000) erzeugt und in die Tabelle eingefügt.

Delphi-Quellcode:

ParaList.Add('Anfang: '+timetostr(now));
  tblpara.Open;

  for i := 1 to 500000 do begin

    tblpara.Insert;
    tblpara.FieldByName('Zahl1').AsInteger:=Random(10000);
    tblpara.FieldByName('Zahl2').AsInteger:= tblpara.FieldByName('Zahl1').AsInteger + Random(100);
    tblpara.FieldByName('Zahl3').AsInteger:= tblpara.FieldByName('Zahl2').AsInteger + Random(500);
    tblpara.FieldByName('Zahl4').AsInteger:= tblpara.FieldByName('Zahl3').AsInteger + Random(1200);
    tblpara.FieldByName('Zahl5').AsInteger:= tblpara.FieldByName('Zahl2').AsInteger + Random(3300);
  end;

  tblpara.Close;
  ParaList.Add('Ende: '+timetostr(now));

  ParaList.SaveToFile('parazeit.txt');

Was soll ich sagen, die Paradoxtabelle hat 13 Sekunden gebraucht.
Bei der Firebird habe ich nach einiger Zeit abgebrochen, weil sich nichts tat. Die Prozedure funktioniert bei der Firebird-DB aber bei einer Schleife die nur 5-6 mal durchläuft. Es geht also. Hmm woran könnte das liegen? Ist Paradox als lokale Tabelle in Puncto Performance doch besser, oder hat Firebird sich nur aufgehängt?

Gruß

[Robert_G]

Wie groß sind die REDO Tablespaces in der FB-Datenbank?
Manche DBs mögen es gar nicht, wenn sie die temp. Daten einer laufenden Transaktion nicht mehr unterkriegen.
Außerdem sagt dir eine Integerspalte rein gar nix über die Performance!
Du solltest auch ein größeres Charakterfeld (200+ Zeichen) verwenden.

[ak1]

Wie kann ich die "REDO Tablespaces" in der FB-Datenbank einstellen? Ich habe IB-Expert zur Verfügung.
Dieser Test wird natürlich noch ausgebaut, war nur quick and dirty für einen Firebird-Anfänger wie mich, mal zum testen.

[Robert_G]

Ich kenne mich leider nur mir Oracle aus.
Schau mal in einem Unterordner von FB oder bei den Tablespaces deiner Datenbank.

p.s.: mit Oracle wären die IntegerINSERTs nur von der Netzwerkgeschwindigkeit eingeschränt worden :twisted:
Stichworte: Array DML, FORALL, BULK Collect, Objektprojektion, Direct Path Loading

[ak1]

@robert, ich werd mir das mal genauer anschauen....

Für 25.000 (5*5000) Zahlen braucht Firebird ca. 43 Sekunden. Habe ja schon gelsenen, dass die Interbase-Table-Komponente sehr langsam sein soll, das ist dann wohl die Bestätigung. Hat vielleicht jemand eine Idee wie ich das schneller hinbekomme, aber mit Table-Komponente.

Gruß

[Robert_G]

Table-Komponente & Performance???
Das ist ja wie Seifenkiste & Formel1 ;)


Nimm dir die rudimentärste Kompo, mit der man SQL an den server schicken kann.
Gibt es kein IBQuery oder IBScript?

[kiar]

du kannst sowieso nicht äpfel und birnen vergleichen.

paradox ist datensatzorientiert und fb ist mengenorientiert.

paradox hat in seiner Datendatei einen Header, wodurch das DBMs, wenn man es so nennen kann die positon berechnen kann.

bei fb wird der DS immer über eindeutige Feldwerte definiert.

also wie gesagt äpfel und birnen.

raik

@robert ---> die gibt es :mrgreen:

[ak1]

Ihr habt natürlich recht. Deswegen will ich das etwas konkreter erläutern:

Wir haben in unserer kleinen aber feinen Firma bis jetzt nur dbase (EXCEL lässt grüßen) und Paradox benutzt, was eigentlich völlig ausreichend ist. Wir nutzen diese Tabellen um mit Delphi komplizierte Berechnungen und Auswertungen von Zahlen und Strings vorzunehmen. Da geht es eher weniger um Verwaltung. Jetzt haben wir ein Projekt, in dem die Berechnungs- und Auswertungsprozeduren mehrere Stunden dauern (auf einem sehr schnellen Rechner), da habe ich mir gedacht, dass ich mal eine Firebird-DB ausprobiere. Auf die Table-Komponente kann ich nicht verzichten, da diese Auswertungen nicht nur aus Abfragen bestehen sondern sehr viel in den Tabellen "rumgehüpft", gerechnet und editiert wird.
Und ob ich nun in einer "select * from table1" Query rumhüpfe oder in einer table-Komponente dürfte ja wohl von der Performance her egal sein, oder?
Ausserdem kann ich einer Query schlecht editieren, da muss ich dann in jedem Feld und in jedem Datensatz den ich editieren will eine komplizierte update-Anweisung losschicken, von daher ist die table-Komponente wirklich sehr sehr hilfreich.

Vielleicht kennt ja jemand von Euch eine schnellere Alternative zu Paradox, welche derzeit ausschließlich lokal genutzt wird.