Wie bekomme ich einen performanten Firebird?

[Perlsau]

Zitat von Union:

Es geht doch. Dazu im Kontextmenü der Datenbank Tasks->Scripts generieren auswählen und im "Erweitert" Dialog auch auswählen, dass man Daten exportieren möchte. Nur wass Du mit TSQL in FB anfangen willst....

Stimmt, die SQL-Dialekte sind nicht kompatibel Umgekehrt geht's aber schon ... glaube ich ... ungetestet

Tatsächlich hatte ich jedoch auch eine FB-Version dieser Tabelle (als View), deren Daten ich exportieren konnte. Dabei wurden 923168 Datensätze mit dieser Struktur exportiert:

Code:

    P_IDX      BIGINT NOT NULL,
    P_LAND     VARCHAR(100),
    P_PLZ      VARCHAR(50),
    P_ORT      VARCHAR(180),
    P_STATE    VARCHAR(100),
    P_PROVINZ  VARCHAR(100),
    P_KOMMUNE  VARCHAR(100),
    P_LAT      NUMERIC(7,4),
    P_LON      NUMERIC(7,4),
    P_GENAU    SMALLINT

Nun hab ich mir in FB eine ebensolche Tabelle in einer Testdatenbank angelegt, wobei P_IDX auf AutoInc steht und daher automatisch erzeugt wird. Selbstverständlich hab ich zuvor im Export P_IDX nicht ausgewählt. Der Import via Script-Editor (von Datei ausführen) dauerte knapp 7 Minuten (6:55), das war eine knapp 206 MB große SQL-Datei. Berechnungen, wie lange ein DS benötigte, könnt ihr sicher selbst anstellen.

[mkinzler]

Interessant wäre es jetzt, wie lange ein Import der selben Daten als EXTERNAL TABLE dauern würde:
Anlage externe Tabelle

SQL-Code:

CREATE TABLE _IMPORT EXTERNAL FILE '<Pfad zur externen Datei>' (
    P_IDX     BIGINT NOT NULL,
    P_LAND    CHAR(100),
    P_PLZ     CHAR(50),
    P_ORT     CHAR(180),
    P_STATE   CHAR(100),
    P_PROVINZ CHAR(100),
    P_KOMMUNE CHAR(100),
    P_LAT     NUMERIC(7,4),
    P_LON     NUMERIC(7,4),
    P_GENAU   SMALLINT,
    CRLF CHAR(2)
);
COMMIT;

Testexport in externe Datei:

SQL-Code:

INSERT INTO _IMPORT
    SELECT <Felder vorhande Tabelle>, ascii_char(13) || ascii_char(10) FROM <vorhandene Tabelle>;

Import:

SQL-Code:

INSERT INTO <geleerte Tabelle/neue Tabelle im identischer Struktur>
  SELECT <Felder ohne CRLF> from _IMPORT;

[Union]

So, nachdem ich die Daten importiert bekam, habe ich einen Test gemacht. Die Lesegeschwindigkeit ist wirklich gut. Aber das Schreiben. Ich habe es jetzt mal mit IBExpert probiert. Da ist die Geschwindigkeit genauso schlecht bei Insert.

Bei jedem Commit hängt er eine ganze Weile - es ändert auch nichts wenn ich das ganze ohne Indizes mache. Das eigentliche Senden der Datensätze an den Server geht rasend schnell. Was muß ich denn nun wo drehen damit das besser wird?

@perlsau: Danke für Deinen Test. Wie ist denn Deine Konfiguration?

edit:

Ich habe das Performanceproblem nun gelöst indem ich

Code:

gfix -write async

auf die Datenbank losgelassen habe. Daraufhin wurden die 50000 Testdatensätze in 50 Sekunden geschrieben.

Wie stelle ich das beim Erzeugen der Datenbank ein oder als Standard im Dienst? Und in der Doku wird davor gewarnt, dass es sein kann dass die Daten dann nie geschrieben werden und es Verluste bei einem Serverabstirz geben kann.

[Perlsau]

Hab gleich einen Arzttermin und daher keine Zeit mehr. DB und SQL-Datei kann man sich dort herunterladen.

[RWarnecke]

Zitat von Union:

Bei jedem Commit hängt er eine ganze Weile - es ändert auch nichts wenn ich das ganze ohne Indizes mache. Das eigentliche Senden der Datensätze an den Server geht rasend schnell. Was muß ich denn nun wo drehen damit das besser wird?

Suche mal nach dem Forum-Mitglied IBExpert, der hat hier im Forum schon des öfteren was zu Firebird und Performance geschrieben und in seinen Beträgen auch einige Links zu anderen Seiten gesetzt, wo es auch über das Thema Performance und Firebird ging.

[Union]

Das mit dem async ist leider auch keine allgemeingültige Lösung. Wahrscheinlich fehlen irgendwelche Buffer. Ich importiere nun gerade eine Tabelle mit > 8 Mio. records und ab ca. 300000 wird es wieder ekelhaft langsam beim Commit.

[tsteinmaurer]

Welche Art von Commit machst du?

[tsteinmaurer]

Verwendest du auch die üblichen Praktiken wie Prepared Statements etc.?

[Union]

Nichts von alledem. Ich führe nur ein Script aus, das aus 8 Mio einzelnen Inserts besteht und nach jeweils 100 Inserts ein commit. Leider wird von FB ja (soweit ich weiss) die Syntax von meheren Value-Gruppen nicht untertstützt (Values (Values-1) [, (Values-n)]).


Es sind auch nicht sonderlich große Datensätze:

Code:

Insert into buchung values(147393, null, null, 23, 14299, '1', '35842011', 0, null, null, null, 0, null, '2005-05-02', null, 21, 145646, '2005-05-02', '17:46:55', 'ZUG', null, null, 'BWirth', null);
Insert into buchung values(147396, null, null, 23, 14302, '2', '35842011', 1, null, null, null, 0, null, '2005-05-02', null, 21, 145647, '2005-05-02', '18:03:21', 'ZUG', null, null, 'BWirth', null);
Insert into buchung values(147399, null, null, 23, 14302, '3', '35842011', 1, null, null, null, 0, null, '2005-05-02', null, 21, 145648, '2005-05-02', '18:03:42', 'ZUG', null, null, 'BWirth', null);

Momentan habe ich über gfix async und buffers 8000 eingestellt. Damit komme ich auf ca. 1 Mio records / h = ~ 300/s. Und je mehr es werden, desto länger dauert das commit, wobei dier Performance ab ca. 300000-500000 Sätzen schlagartig in den Keller geht. Die Übertragung der Daten ist aber schnell.

[Perlsau]

Zitat von Union:

... ab ca. 300000 wird es wieder ekelhaft langsam beim Commit.

Nach je 100 Datensätzen ein Commit? Probier's doch mal damit, nur alle 5000 DS ein Commit zu machen. In meinem Beispiel scheint das Insert mit vollkommen gleichmäßiger Geschwindigkeit zu verlaufen. Soweit ich das erkennen kann, ist da nach 1000 DS jeweils ein Commit Work; eingebaut. Die Geschwindigkeit lag bei mir bei 0,45 Sekunden für 1000 Datensätze, und zwar auf einem Win7/64 ohne SSD, Double Core Intel à 3 GHz und mit 4 GB Arbeitsspeicher. FB-Server:

Server Version: WI-V2.5.2.26540 Firebird 2.5
Server Implementation: Firebird/x86-64/Windows NT
Service Version: 2

Lade dir das Beispiel doch mal runter und probier's selber aus.