Fragen bezüglich Performance von Firebird in einer Anwendung

[hoika]

Hallo,
ja, Multi-Insert wäre eine schönes Sprach-Feature.

Zitat:

extrapoliere man das auf 50.000 Rows hoch

Du kennst aber schon die SQL-Grenze von FB? ;)

[jobo]

Zitat:

Zitat von tsteinmaurer (Beitrag 1441485)

Aus Sicht der Anwendungsentwicklung wäre es natürlich schön, wenn jede DB gleich tickt. Tut es leider - oder vielleicht Gott sei Dank - nicht?

Nur ein paar Gedanken, in der Hoffnung, dass ich niemanden auf die Füße getreten bin. :twisted:

Naja, der Smiley sieht für mich zumindest so aus, als ob Du eher sagen wolltest, falls sich jemand auf die Füße getreten fühlt, sein Problem. Egal, das ist nicht der Punkt. Denn wir sind ja zum Austausch hier.

Dass jede DB anders ist bzw. funktioniert liegt in der Natur der Sache. Hier wäre mal bei fb record versioning zu nennen. Solche konzeptionellen Unterschiede bringen Vorteile und teilweise auch Nachteile, und wie so oft, sind bestimmte technische Ansätze ein Kompromiss... ich hab ja schon von der Tischdecke geschrieben. Z.B. sowas wie Locking und MS SQL, ich habe zuletzt auch noch von der 2014er "tolle" Sachen gehört.
Manchmal glaube ich MS hat die ganze dot Net Datenhaltung nur erfunden, um seine DB zu schonen. Jedes System hat offenbar seine Schwächen, manche sogar kostenpflichtige.

Die Argumente:
Ich bin Entwickler, Firebird Nutzer, und sehe bestimmte Defizite bei der Implementierung der Datenbank
Ich bin Berater, Firebird Fachmann und sehe bestimmte Defizite bei der Nutzung bzw. dem Entwickler-KnowHow

Freibier oder "nem geschenkten Gaul, schaut man nicht ins Maul"!
Man kann natürlich kritiklose Dankbarkeit erwarten, wenn man etwas verschenkt. Oder man hält Geschenke für selbstverständlich.

Beides Extrempositionen, die hier durchklingen, aber nicht wirklich ernst gemeint sein können. Also wieso entschuldigt man sich, wenn man die Dinge so benennt, wie man sie sieht? Das hier ist doch kein Kindergarten. Der entscheidende Punkt ist doch, die Juckepunkte darzustellen und zu lernen.

[IBExpert]

Zitat:

Zitat von tsteinmaurer (Beitrag 1441485)

Nur ein paar Gedanken, in der Hoffnung, dass ich niemanden auf die Füße getreten bin. :twisted:

:thumb:

[IBExpert]

Zitat:

Zitat von jobo (Beitrag 1441503)

Die Argumente:
Ich bin Entwickler, Firebird Nutzer, und sehe bestimmte Defizite bei der Implementierung der Datenbank
Ich bin Berater, Firebird Fachmann und sehe bestimmte Defizite bei der Nutzung bzw. dem Entwickler-KnowHow

Ich bin Entwickler, Firebird Nutzer, Berater, und Firebird Fachmann und sehe bestimmte Defizite bei der Nutzung bzw. dem Entwickler-KnowHow, aber auch bestimmte Defizite bei der Implementierung der Datenbank.

So seh ich das, das eine widerspricht dem anderen nicht und auch keineswegs den Erkenntnissen der vorherigen Beiträge anderer Autoren.

Und bewahrt mich davor, das mir irgendjemand irgendeinen 20 Jahre alten Delphi/Interbase Code von mir unter die Nase hält und sagt, modernisiere das mal bitte eben nach deinen aktuellen Erkenntnissen. Aber es gibt eben sehr große Unterschiede in meinen Projekten von vor 20 Jahren und der generellen Architektur, mit der ich heute meine Software aufbaue. Vor 25 Jahren war der Weg auch in meinen Augen super, weil man unglaublich schnell zum funktionierenden Prototypen kam. Das lief aber schon sehr schnell an Grenzen, die mich zwangen, vieles zu hinterfragen.

Da ich in den letzten 25 Jahren eben auch oft als externer Softwarearchitekt bei mehrjährigen Projekten gebucht wurde (meistens für 40-80 Tage pro Jahr) und dort mit entsprechenden Teams, bestehend aus Mitarbeitern des Kunden, die Möglichkeit hatte, immer wieder Projekte komplett neu aufzubauen und den immer wieder einen neuen Stempel aufzudrücken, war es für mich immer ein guter Weg, meine Kenntnisse aus der vorherigen Projekt zu verbessern und für die erkannten Probleme neue Lösungsstrategien aufzubauen. Diesen Vorteil haben die meisten Entwickler in Ihren Angestelltenverhältnissen leider meistens nicht, sondern sind vom eigenen Projekt oder den Vorgaben der Unternehmensleitung im System gefangen.

Wir sind übrigens in Berlin auf der Firebird Konferenz auch mit dabei

[Codehunter]

Zitat:

Zitat von hoika (Beitrag 1441502)

Du kennst aber schon die SQL-Grenze von FB? ;)

Davon red ich ja die ganze Zeit. Stichwort Blockgröße. Ich musste mir noch einen eigenen Scripter basteln, weil der von FIBplus aus irgendeinem Grund die Blockgröße falsch berechnet. Auch so ein Fall von zusätzlichem Aufwand. Irgendwie muss man ja ein langes SQL-Script in für Firebird verdauliche Häppchen filetieren.

[IBExpert]

Zitat:

Zitat von Codehunter (Beitrag 1441494)

SQL-Code:

INSERT INTO Tabelle (Feld1, Feld2) VALUES (1, 1), (2, 2), (3, 3), (4, 4), (5,5);

Macht in Summe genau 80 Zeichen. Bei Firebird habe ich stattdessen Execute-Blocks, womit für das selbe Ergebnis folgendes zu notieren wäre:

SQL-Code:

EXECUTE BLOCK AS BEGIN
INSERT INTO Tabelle (Feld1, Feld2) VALUES (1, 1);
INSERT INTO Tabelle (Feld1, Feld2) VALUES (2, 2);
INSERT INTO Tabelle (Feld1, Feld2) VALUES (3, 3);
INSERT INTO Tabelle (Feld1, Feld2) VALUES (4, 4);
INSERT INTO Tabelle (Feld1, Feld2) VALUES (5, 5);
END

Konstruktiver Vorschlag aus der Praxis, wie wir das gar nicht mal selten machen (unter anderen täglich mit ca 15mb CSV Wetter Daten aus den weltweiten WMO Synop und Forecast Daten)

Der Inhalt wird per Upload in eine Tabelle mit einem Blob Feld inserted und dann per Execute Procedure mit Hilfe diverse Substring, Position, oder eigener Stored Functions serverseitig auseinander genommen , in Execute Statements übersetzt und von da in die realen Tabellen verteilt. Die Rohdaten sind dabei ca 150.000 zeilen und das geht auf dem Weg wesentlich schneller als man denkt, insbesondere weit schneller als 150.000 Einzelinserts.

Ein anderer Weg: Du baust deine Execute Blocks lokal wie vermutlich auch schon jetzt in deiner Clientumgebung zusammen und berücksichtigst einfach nur die Limits, die Firebird da hat (maximal 32k source pro Block, maximal ca. 250 inserts oder max ca. 125 updates oder max ca. 83 update or inserts, etc. Die Blöcke kannst du dann mit einem Trenner deiner Wahl zum Beispiel auch in einen Blob auf den Server hochladen oder dort mit einer ähnlichen SP (siehe oben) dann serverseitig mit einzelnen execute statement der aufgeteilten execute blocks ausführen. Läuft alles in einem Transaktionskontext und rollback ist rollback etc.

Wir haben in Ibexpert scripten eine Möglichkeit eingebaut, einen Reinsert zu integrieren, was ein simpler Ersatz für das vorher benutzte voll ausformuliert Insert ist. Das macht Scripte schon wesentlich kleiner.

Und in einer für unserer Zwecke erweiterte Firebird Version auf Basis der 304 ist ein Vorabparser eingebaut, der Sqls serverseitig auseinandernehmen kann, bevor die firebird internen Instanzen den SQL Text überhaupt sehen.

Mit dem ist auch deine Multirow insert syntax möglich, aber aus welchen gründen auch immer ist das aktuell nicht in der Public Firebird Version implementiert, obwohl die eben als Datenpumpe durchaus für kleinere Scripte sorgen kann. Technisch ist aber der weg upload als blob und execute auf dem Server nicht so viel anders und auch nicht wirklich langsamer, weil egal wie der text lautet, in dem man die Operationen zum Server sendet, am ende physikalisch inserts auf der db gemacht werden.

Und auch da am Ende meine Zustimmung: Die von dir erwähnte Syntax für Massenimporte bietet viel potential und ist bei der Implementation für die Firebird Entwickler sicherlich keine Raketenwissenschaft, aber da es durchaus gleichschnelle Workarounds gibt, scheinbar auch nicht ganz so wichtig, aber es steht dir offen, das bei Bedarf im Bugtracker vom Firebird Projekt als Feature einzutragen oder falls schon vorhanden, deine Interesse zu bekunden, das du es für Wichtig hältst.

Wenn es aber darum geht, möglichst schnell daten in die Datenbank zu bekommen, oder auch Daten aus der Datenbank zu exportieren, dann nimm besser ein Verfahren über external file tables, damit geht das auf schnellen Servern problemlos 50000-100000 import/export records pro Sekunde!!

[Frickler]

Zitat:

Zitat von tsteinmaurer (Beitrag 1441348)

Zitat:

So ein Tool suche ich auch noch. Der SQL-Monitor von DevArt ist leider auf einem Auge blind, wenn es um von IBDAC generierten SQL-Code wie beim IBCLoader oder Array-DML geht.

Falls es über die Firebird Trace API sein darf (benötigt Firebird 2.5 oder höher), dann z.B.: https://www.upscene.com/fb_tracemanager/

IBExpert hat auch eine Firebird Trace API Integration: https://www.ibexpert.net/ibe/pmwiki.....TraceAndAudit

Der IBExpert zeigt dabei BLOB (Sub Typ 1 = Text) nicht an (statt dessen nur eine Nummer). Ist das eine Begrenzung vom Trace API oder von IBExpert?

[mkinzler]

Dabei handelt es sich um die BLOBID. Die eigentlichen Daten werden ja getrennt von der Tabelle gespeichert.

[Frickler]

Zitat:

Zitat von tsteinmaurer (Beitrag 1441485)

Grundsätzlich soll jeder das nehmen, was am Besten funktioniert. Warum ist dann Firebird weiterhin im Rennen, wenn es so viel schlechter als Oracle oder MSSQL performt?
Vielleicht sind es dann doch so Dinge wie:
* kostet nix (auch wenn die Entwicklung an Firebird vor 10 Jahren sich in der Gegend von 5-stelligen USD pro Monat abspielte)
* klein und handlich mit einfacher Installation
* Multi-OS Support
* wenig Administration (ein bisschen automatisiertes gbak, gfix)
* enormer SQL-Sprachumfang, sowohl client- als auch serverseitig
* hohe Read/Write-Concurrency Fähigkeit (record versioning)
* Repeatable Read / Snapshot Isolation für eine stabile Sicht auf die Daten z.b. bei Reporting Use-Cases
* etc ...

Jaaaa! :-D

Einfache Installation! Ne ZIP auspacken, Batch starten, drauf isser - und runter genau so schnell. Wer mal MSSQL deinstallieren musste, weiß, dass Microsoft das vermutlich nicht ernsthaft vorgesehen hat :-D
Bekomme ich MSSQL incl. EXE auf einen USB-Stick für den Außendienst?

[hoika]

Hallo,

Zitat:

Bekomme ich MSSQL incl. EXE auf einen USB-Stick für den Außendienst?

Wenn er groß genug ist ;)