[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. :gruebel:

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. :stupid:

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 ... :gruebel:
[/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:

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 ... :wall:
2) Bringt keine Änderungen

Zitat:

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:

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:

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?

SQL-Code:

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:

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:

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. :gruebel:

Zitat:

Zitat von Bernhard Geyer

Zitat:

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. :stupid: 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ß -> :wall: ;)

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 ...)

[mkinzler]

Um Herauszubekommen, ob das Problem am DBMS, den Zugriffskomponenten oder der Anzeigekomponenten liegt, muss man versuchen, die benötigte Zeit diesen Ebenen zuzuordnen. Du hattest vorher geschrieben: 16.000 Eintrage ~ 13 Sek, ALS ~7 Sek. IBExpert ~ ? Sek.

FB prepared parametrisierte Abfragen automatisch, was Zeos allerdings macht, kann ich auch nicht sagen.

[Nuclear-Ping]

Hab grad mal gegoogelt wg ZEOS und Prepare. Laut Dez 07 wollen die das erst in ner stabileren Version von den Komponenten einbauen.

Zitat:

Zitat von mdaems

No it doesn't (yet). It is one of the first things we want to add once 6.6.X is released as stable, however.

IBExpert ... Hmm ... Meinst du das bringt was, jetzt noch ein RDBMS zu installieren und zu testen?

[RavenIV]

Zitat:

Zitat von Nuclear-Ping

IBExpert ... Hmm ... Meinst du das bringt was, jetzt noch ein RDBMS zu installieren und zu testen?

IBExpert ist ein Verwaltungstool für Firebird / Interbase.
So ähnlich wie der EnterpriseManager für MS SQL.

Wenn Du für Firebird optimierte Komponenten willst, dann benutze ADO oder FIBPlus oder sowas.
ZEOS ist mit dem Gedanken geschrieben, dass es möglichst viele Datenbanken unterstützt.
Daher ist es nicht optimiert.

[mkinzler]

IBExpert ist ein Admin-Tool für IB/FB.

[Union]

Was war jetzt noch mal gleich der Grund für die Umstellung? Vom ADS gibt es doch seit 2 Wochen die 9er Version, die noch schneller ist, MERGE unterstützt, Notifications hat, 64 Bit etc. Aber auch die Vorgängerversionen waren schon immer affenartig schnell.

[Nuclear-Ping]

Oh ... Danke. Hatte den Eindruck, IBExpert wäre wieder irgendein Interbase-Derivat. :mrgreen:

Ich teste mal 'ne andere Zugriffskomponente und schau mir IBE an.

@Union: Grund ist rauszufinden, um wieviel besser / schlechter unser Projekt mit einem anderen Datenbanksystem läuft. Wir arbeiten derzeit noch mit der 7er von ALS, die hat aber schon gut 5 Jahre auf dem Buckel. Den Umstieg von 7 auf 8 hab ich nie machen wollen / können, da ich beim ersten Spielen damit gemerkt habe, dass einige Dinge aufeinmal ziemlich anders waren und ich zu dem Zeitpunkt mich nicht darum hätte kümmern können.

[Bernhard Geyer]

Überleg dir mal ein Brige-Pattern zu aufzusetzen um mehrere DBMS alternativ unterstützen zu können.
Dann kann man alternativen imm schön relaxed austesten.

[Union]

Zitat:

Den Umstieg von 7 auf 8 hab ich nie machen wollen / können, da ich beim ersten Spielen damit gemerkt habe, dass einige Dinge aufeinmal ziemlich anders waren

Was war denn da der Blocker? Wir hatten bei unserer Anwendung (mehr als 200 verschiedene hochoptimierte Queries, manche über 100 Zeilen) kein einziges Problem. Neue Version ADS installiert, fertig. Nur dass die Geschwindigkeit von 7->8 um ca. 10% gestiegen ist.

[Nuclear-Ping]

Ganz genau weiß ich's nicht mehr, habs mir wie schon gesagt nur kurz angeschaut. Aber woran ich mich erinnern kann war, dass ein paar Queries nicht mehr 1:1 liefen, die Query-Komponente ein paar Sachen nicht mehr gekannt hat / anders erwartet hat und er wegen irgendwelcher Einsprungspunkte in 'ner DLL ständig gemeckert hat, obwohl ich das ganze System nach den 7er-DLLs durchkämmt und gelöscht hab.

Aber wer weiß, wenn ich merke, dass das mit FB nichts wird, schau ich mir mal die 9er von ADS an. ;)

[hoika]

Hallo,

zu Zeos:
Es wird automatisch prepared.
Natürlich darf der SQL-Text der Query zwischen 2 Aufrufen nicht geändert werden
-> prepared Queries

> Der Hauptknoten hat noch einige Unterknoten

Wo in der Tabelle steht denn die Verknüpfung Unterknoten -> Hauptknoten ?

Wenn es eine gibt, kannst du die Unterknoten doch in einem Rutsch (1 Query) laden.
Das spart ne Menge Queries.

1000 Queries sind schon ziemlich viel für ein paar Knoten.

Zeos hat doch auch nen SQL-Monitor.
Schau doch mal nach, was dort alles an Queries gestartet wird.


Heiko

[Nuclear-Ping]

Hallo Heiko,

der Baum selber wird nicht in der Datenbank gespeichert, sondern per SaveToFile auf die Platte geschrieben.

Für den oben genannten Fall läuft das so, dass der Benutzer aus einer übergeordneten Auswal einen Knoten anhaken kann, die Analyse startet, die SW sammelt dann alle CategoryIds der angehakten (Unter-)Knoten in einer Liste und erstellt daraus die Querys

SELECT * FROM ... WHERE CategoryId=200
SELECT * FROM ... WHERE CategoryId=205
SELECT * FROM ... WHERE CategoryId=6544

... 1000 sind es nicht, das war nur Pi*Daumen. Es sind für diese Datenbank 239 Querys dieser Art.

[edit]
Aber gute Neuigkeiten ... :mrgreen: ... Hab den jetzt auf gezählte 3-4sek zum laden für diese DB mit den 16.000 Einträgen runtergebracht. Hab mit IBExpert die Datenbank nochmal neu indiziert, die Abfrage per Prepared-Query gemacht und noch bischen ausgemistet. :)
[/edit]

[mkinzler]

Dann würde ich das Ergebnis in einem Rutsch anfordern

SQL-Code:

SELECT * FROM ... WHERE CategoryId in (200, 205, ...)

[Nuclear-Ping]

Oh das geht? Super, mal testen. :)

[edit]
Cool, danke, geht. :D Dauert aber auch zw. 3-4 Sekunden. Aber ich denke damit kann ich leben, denn das ist auf jeden Fall schneller als die 7sek vom ADS.
[/edit]

[hoika]

Hallo,

versuche das IN mal durch OR zu ersetzen.
vielleicht ist das schneller.


Heiko

[Union]

Zitat:

Dauert aber auch zw. 3-4 Sekunden. Aber ich denke damit kann ich leben, denn das ist auf jeden Fall schneller als die 7sek vom ADS

Hast Du es beim ADS auch mit der neuen Logik probiert? Ansonsten vergleichst Du ja Pflaumen mit Orangen ;)

[Nuclear-Ping]

Zitat:

Zitat von hoika

versuche das IN mal durch OR zu ersetzen.
vielleicht ist das schneller.

Ne, geht nicht. Da meckert er - wie erwartet, dass er OR dort nicht haben will.

Zitat:

Zitat von Union

Hast Du es beim ADS auch mit der neuen Logik probiert? Ansonsten vergleichst Du ja Pflaumen mit Orangen ;)

Ja, so wie in Beitrag #10 auf Seite 1. Hat aber keinen Unterschied gemacht.

[mkinzler]

Heiko meint

SQL-Code:

SELECT * FROM ... WHERE CategoryId = 200 or CategoryId = 205 or ...

[Peinhard]

Was auch noch eine Rolle spielen mag - kommt die Liste der CategoryID sortiert daher?

Und 'Union' meint, wenn ich's recht verstehe, die Abfrage mit IN-Syntax auf dem Advantage.

[Nuclear-Ping]

Zitat:

Zitat von mkinzler

Heiko meint

SQL-Code:

SELECT * FROM ... WHERE CategoryId = 200 or CategoryId = 205 or ...

Achso, ja, logisch. Sorry, stand auf dem Schlauch. War glaube zuviel neues die letzten Tage, da landet jeder Vorschlag irgendwie in der Ecke. :mrgreen:
Hab ich grad probiert, geht nicht schneller.

Zitat:

Zitat von Peinhard

Was auch noch eine Rolle spielen mag - kommt die Liste der CategoryID sortiert daher?

Nein. Macht aber auch keinen Unterschied, wenn ich sie vorher sortiere.

Zitat:

Zitat von Peinhard

Und 'Union' meint, wenn ich's recht verstehe, die Abfrage mit IN-Syntax auf dem Advantage.

Falls das, dann nein. Aber wie schon gesagt, macht es bei Firebird nun auch keinen Unterschied mehr, ob ich die Daten per IN oder per einzelner Querys abrufe. Braucht beides ~4 Sekunden, was im Vergleich zu vorher ne absolut tolle Verbesserung ist.