[gelöst] Umstieg von ALS auf Firebird -> Sehr langsam

[Nuclear-Ping]

Hallo,

ich habe die Datenbank unserer Anwendung die letzten Tage mit Firebird 2.0.3 ausgetauscht und vorhin die letzten Konvertierungen abgeschlossen. Vorher lief das Ganze mit Advantage Local Server 7.
Jetzt stell ich allerdings fest, dass das System noch langsamer läuft wie vorher.

Zum Beispiel wenn man in der Anwendung für eine Analyse einen Hauptknoten auswählt, wo so ca. 16.000 Einträge dahinter liegen, dauert das gezählte 13 Sekunden bis er mit dem laden fertig ist. Der Hauptknoten hat noch einige Unterknoten, die alle per "SELECT * FROM DataDB WHERE CategoryID=..." durchgegangen und deren Daten geholt werden.

Mit der alten Datenbank hat das ~7 Sekunden gedauert. Ist zwar auch nicht der Hit, aber deswegen auch der Umstieg, da ich mir einen Geschwindigkeitszuwachs erhofft hatte.

Indize sind soweit ich das beurteilen kann korrekt, es sind keine JOINs in der Query, sondern nur so einfach wie oben angesprochen.

SQL-Code:

CREATE TABLE DataDB (
  Id           INTEGER NOT NULL,
  CategoryId   INTEGER NOT NULL,
  Problem      BLOB SUB_TYPE TEXT,
  ProblemDescription BLOB SUB_TYPE TEXT,
  Solution     BLOB SUB_TYPE TEXT,
  SolutionDescription BLOB SUB_TYPE TEXT,
  SymbolType1  SMALLINT,
  SymbolFile1  VARCHAR(16),
  SymbolType2  SMALLINT,
  SymbolFile2  VARCHAR(16),
  Flags        INTEGER DEFAULT 0,
  PRIMARY KEY (Id)
);
CREATE GENERATOR DataDB_Id_Gen;
CREATE INDEX DataDBOrdinary ON DataDB (CategoryId);

SET TERM & ;
CREATE TRIGGER DATADB_BI FOR DATADB ACTIVE BEFORE INSERT POSITION 0 AS
BEGIN
  IF (NEW.ID IS NULL) THEN
    NEW.ID = GEN_ID(DATADB_ID_GEN, 1);
END
&
SET TERM ; &

Ich bin noch recht frisch im Umgang mit Firebird, daher verzeiht mir bitte eventuell grobe Fahrlässigkeiten.

Hab ich was übersehen oder vergessen? Jemand eine Idee?

[edit]
Vielleicht noch zur Information: Die Datenbank selber ist nur 26MB groß. Sie hat keine Bilder (BLOBs) intern gespeichert, diese sind alle extern abgelegt und es wird nur auf die Dateinamen verwiesen.
Eigentlich sollte das doch ruck-zuck gehen ...
[/edit]

[mkinzler]

-Wie lange braucht di Abfrage ausserhalb von Delphi?
-Ersetze mal * durch die Aufzählung der benötigten Felder

[Bernhard Geyer]

Verwendest du auch schön prepared Statements?
Liegt Firebird auch auf dem gleichen Rechner (Round Trip Delays)?

[RavenIV]

Wie soll die Datenbank einen gescheiten Index verwenden, wenn
a) keiner vorhanden ist (nur CategoryId)?
b) ein SELECT * gemacht wird?
c) perparedStatements nicht verwendet werden?

Überleg Dir doch nochmal das DB-Design und die SQL-Abfrage.

[Nuclear-Ping]

Zitat von mkinzler:

-Wie lange braucht di Abfrage ausserhalb von Delphi?
-Ersetze mal * durch die Aufzählung der benötigten Felder

1) Einen genauen Wert kann ich da auf die schnelle nicht ermitteln, da es eine Menge einzelner Querys sind und er mir in einem SQL-Tool gleich die Ergebnisse dieser auflistet. Stichprobenweise sind aber da zB Ergebnisse wie: Query OK, 480 rows in set (2,75 sec), Query OK, 314 rows in set (1,58 sec) ... Also er braucht für 794 Einträge 4,33sec ... Wenn da nicht die Zeit für die Darstellung mit drin ist, ist das ziemlich lange ...
2) Bringt keine Änderungen

Zitat von Bernhard Geyer:

Verwendest du auch schön prepared Statements?
Liegt Firebird auch auf dem gleichen Rechner (Round Trip Delays)?

1) Nicht dass ich wüßte. Wie mache ich sowas?
2) Ja, läuft als Embedded.

Zitat von RavenIV:

Wie soll die Datenbank einen gescheiten Index verwenden, wenn
a) keiner vorhanden ist (nur CategoryId)?
b) ein SELECT * gemacht wird?
c) perparedStatements nicht verwendet werden?

Überleg Dir doch nochmal das DB-Design und die SQL-Abfrage.

a) Alle Einträge aus dieser Tabelle werden nur nach CategoryId ermittelt. Daher ging ich davon aus, dass ein Index auf diese Spalte ausreichen sollte, da die Tabelle eben nicht anders angesprochen wird. Wie kann ich's besser machen?
b) Es werden auch alle Felder aus der Tabelle benötigt. Und wenn ich die einzelnen Spalten alle angebe, wird es davon leider nicht schneller.
c) Wie oben schon geschrieben: Ich beschäftige mich seit ~1 Woche mit Firebird. In der Zeit ist es heute das erste mal, dass ich auf diesen Begriff stoße. Daher: Wie verwende ich sowas?

[exilant]

Zitat von RavenIV:

Wie soll die Datenbank einen gescheiten Index verwenden, wenn
a) keiner vorhanden ist (nur CategoryId)?
b) ein SELECT * gemacht wird?
c) perparedStatements nicht verwendet werden?

Überleg Dir doch nochmal das DB-Design und die SQL-Abfrage.

Er hat einen "primary key" auf ID, einen Index auf CategoryID. Was willst Du mehr.
Die "where" Klausel verweist klar auf CategoryID. Das ist für den Optimizer kein Problem.
Preparen (es dürfte weniger als 20ms dauern) bringt nur was bei ständiger Wiederholung der gleichen Abfrage
und auch dann eher wenig. habe ich mal gemessen. Bei mir dauert das abholen von 800 Sätzen aus einer Tabelle mit 27.000.000 (27 Millionen) Sätzen unter 40ms - inklusive "prepare".
Beim dem "select *" wäre allerdings zu klären was ZEOS mit den Blobs macht (immerhin 4 Stück).
Wenn ZEOS die für jede Zeile "fetcht" und die noch sehr umfangreich sind kann
das schon ziemlich bremsen. Ich kenne ZEOS allerdings nicht.
Ich würde mir eher überlegen ob es sinnvoll ist, eine Datenstruktur zu basteln die alle 16.000 Zeilen beinhaltet.

[mkinzler]

Zitat:

1) Nicht dass ich wüßte. Wie mache ich sowas?

SELECT <Feldliste> FROM DataDB WHERE CategoryID=:KatID; Gib doch genau mal im Admintool genau die abfrage an, welche du im Programm durchführst. Die Abfrage mit Parametern sollte aber auf jedenfall schneller sein.
Versuch mal eine Neuindizierung.

[Bernhard Geyer]

Zitat von Nuclear-Ping:

1) Nicht dass ich wüßte. Wie mache ich sowas?

Delphi-Quellcode:

qry.text := 'SELECT * FROM DataDB WHERE CategoryID = :CategoryId';
qry.prepared := True;

<meine Schleife>
  qry.Close;
  qry.ParamByName('CategoryId').AsString := ...;
  qry.Open;
<meine Schleife>

Aber ADS ist schon gut schnell. Ob du hier viel mit Firebird Embedded gewinnst?
Aktuell bin ich auch auf der Suche nach einem DesktopDB-Ersatz für ADS Local Server.

[mkinzler]

Der große Vorteil von FB embedded ist die gute Skalierungsfähigkeit.
In einem Test der der Zeitschrift Toolbox konnte man im Vergleich sehen, dass FB (embedded) Vorteile bei komplexen Abfragen bietet, bei einfachen aber etwas langsamer als SQlite u.ä. ist.

Zitat:

Preparen (es dürfte weniger als 20ms dauern) bringt nur was bei ständiger Wiederholung der gleichen Abfrage

Was hier wohl der Fall ist (Haupt-/Unterknoten)

[Nuclear-Ping]

Zitat von mkinzler:

Gib doch genau mal im Admintool genau die abfrage an, welche du im Programm durchführst.
Versuch mal eine Neuindizierung.

1) Es sind vielleicht 1000 einzelne Abfragen, je nachdem wieviel Unter(-unter)knoten der gewählte Eintrag hat.
2) So?

SQL-Code:

SET TERM & ;
CREATE PROCEDURE REINDEX
AS
declare variable SQL VARCHAR(200);
BEGIN
  FOR
    select rdb$index_name from rdb$indices
    INTO :SQL
  DO
  BEGIN
    SQL='SET STATISTICS INDEX '||SQL||';';
    execute statement :sql;
  END
END &
SET TERM ; &

EXECUTE PROCEDURE REINDEX;
>Query OK, -1 rows affected (0,08 sec)

Wenn der mit -1 das Gesamtergebnis meint, hat das scheinbar nicht geklappt? Denn schneller finde ich's danach auch nicht.

Zitat von Bernhard Geyer:

Zitat von Nuclear-Ping:

1) Nicht dass ich wüßte. Wie mache ich sowas?

Delphi-Quellcode:

qry.text := 'SELECT * FROM DataDB WHERE CategoryID = :CategoryId';
qry.prepared := True;

<meine Schleife>
  qry.Close;
  qry.ParamByName('CategoryId').AsString := ...;
  qry.Open;
<meine Schleife>

Aber ADS ist schon gut schnell. Ob du hier viel mit Firebird Embedded gewinnst?
Aktuell bin ich auch auf der Suche nach einem DesktopDB-Ersatz für ADS Local Server.

Ja, den ALS hast du mir damals bei Spotlight (spectrumizer) empfohlen. Das war glaube vor 5-6 Jahren. War seit dem ersten Tag auch ziemlich zufrieden damit, nur nach der Zeit wollte ich mir auch mal was aktuelles anschauen.

Und grad hats wieder Klick gemacht, über ein Konzept was ich die ganze Zeit missverstanden hab. Ich habs die ganze Zeit (auch bei ADS) so gemacht:

Delphi-Quellcode:

<meine Prozedur>
  qry.text := 'SELECT * FROM ... WHERE CategoryId = :CategoryId';
  qry.Prepare;
  qry.Open;
    <fetch></fetch>
  qry.Close;
</meine Prozedur>

<meine Schleife>
  meine Prozedur
</meine Schleife>

Jaja ... Ich weiß ->

ZEOS hat in der Version allerdings kein Prepare / Prepared. Hab da aber mal kurz zum testen 'ne globale Boolean-Variable angelegt und den qry.Text-Teil darein gepackt, wenn sie nicht TRUE ist.

Delphi-Quellcode:

<meine Prozedur>
  if not QueryPrepared then
    begin
      qry.text := 'SELECT * FROM ... WHERE CategoryId = :CategoryId';
      QueryPrepared := TRUE;
    end;
  qry.ParamByName ('CategoryId') := CategoryId;
  qry.Open;
    <fetch></fetch>
  qry.Close;
</meine Prozedur>

QueryPrepared := FALSE;
<meine Schleife>
  meine Prozedur (CategoryId)
</meine Schleife>

Muss aber sagen, dass ich keinen Geschwindigkeitsunterschied feststelle.

(Ich hasse neue Systeme ...)