Fragen bezüglich Performance von Firebird in einer Anwendung

[Schokohase]

Zitat von hoika:

mir ging es um testbaren Code in einem RAD-System.
Der (angedachte) Service wäre dann über einen Unit-Test testbar.

Der ist nicht testbar im Sinne von Unit-Tests.

Denn dort erstellt man sich Instanzen mit gemockten Abhängigkeiten und überprüft das Zusammenspiel mit diesen Abhängigkeiten.

Der angedachte Service muss sich von irgendwo die Daten holen und genau dieses irgendwie erstetzt man für den Test damit man eben nicht auf die Datenbank zugreifen muss. Natürlich muss man irgendwann auch Tests mit der Datenbank durchführen, aber das ist Teil eines anderen Test-Komplexes und passiert niemals innerhalb der Unit-Tests.

https://de.wikipedia.org/wiki/Softwaretest#Teststufen

[tsteinmaurer]

Zitat:

Letztendlich verdiene ich aber nicht mit Firebird und Dienstleistungen drumherum sondern mit Businessanwendungen, die Firebird nutzen. Heißt, das DBMS muss arbeiten. Effizient und zügig.

Verständlich, dass Freibier (ah, sorry: kostenloser Firebird) performen soll wie Sau, wenn möglich. Böse Zungen behaupten, da deutschsprachige Kollegen bei der Gründung dabei waren, dass sich Firebird (Fb) von Freibier (Fb) ableitet, aber vielleicht war es dann doch der Phönix (Vogel) aus der Asche. Aber das ist eine andere Geschichte ...

Ich bin in der glücklichen Lage, dass mir Firebird nicht meine Familie ernährt. Darum muss ich auch nicht Firebird (+ meine Dienste) bei jeder Gelegenheit verteidigen bzw. an den Mann / die Frau bringen, sondern auch kritisch hinterfragen. So zB finde ich, dass Firebird viel zu spät auf den SMP-Zug in der SuperServer Architektur aufgesprungen ist. Da hatte InterBase definitiv die Nase vorne, aber vielleicht auch nur, weil ein paar größere Kunden diese Skalierbarkeitsthema einfach eingefordert hatten (reine Mutmaßung, in der Hoffnung, dass ich von InterBase-Insidern nicht gesteinigt werde ). Firebird punktete mit einer massiven Flotte an SQL-Spracherweiterungen, um auf die anderen Hersteller aufzuschließen.

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

Vor allem die Read/Write-Concurrency Fähigkeit war ein beliebtes Beispiel was z.b. MSSQL ja bis Version 2005 gar nicht konnte bzw. auch dort by Default OFF war, weil dann die tempdb ein echter Flaschenhals wurde. Ich möchte nicht wissen, wieviel clientseitiger Code fürs Locking-Exception-Handling mit Re-Try Mechanismen notwendig war, um das stabil zu bekommen. Aber gut, die Zeit verging und MSSQL ist da mit Sicherheit viel besser geworden. Andere böse Zungen (TM) behaupteten, dass in der MSQL Welt deswegen auch so stark die Trennung von OLTP und OLAP auf einer Datenbasis forciert wurde, weil dir mit einer MSSQL Datenbank Reads auf nicht committeten Writes mit Locks nur so um die Ohren geflogen ist. Und vom Thema "Lock Escalation" von Locking auf Datensatz in Richtung Page-Ebene sprechen wir noch gar nicht. Die Leute haben halt dann angefangen mit dem NOLOCK Hint zu arbeiten. ACID Eigenschaften Goodbye.

Holger hat ja schon das Problem mit der SELECT COUNT(*) ... Performance geschildert. Ist dem Record Versioning und der hohen Read/Write-Concurrency Fähigkeit geschuldet. Aber man darf da hier schon den Anwendungsentwickler (oder Komponentenhersteller) in die Pflicht nehmen und z.b. folgendes
hinterfragen (Pseudocode unten):

Code:

...
anzahl = SELECT COUNT(*) FROM ... [WHERE ...];
IF (anzahl > 0) THEN
BEGIN
  ...
END

Großes Potential für eine Optimierung zB mit:

Code:

...
IF (EXISTS(SELECT 1 FROM ... [WHERE ...])) THEN
BEGIN
  ...
END
...

Oben war nur ein kleines Negativbeispiel aus der Praxis, das ich in dieser Form oft gesehen haben. Zusätzlich bin ich persönlich der Meinung, dass man sich mit jedem DBMS und dessen Eigenschaften auseinandersetzen MUSS, bevor man mit der Anwendungsentwicklung startet. Bei Firebird sind es halt dann so Eigenheiten wie die Wichtigkeit des Transaktionshandlings, OIT/OAT etc ... Da fährt der Zug drüber . Des Weiteren bin ich auch der Meinung, dass es nicht umsonst Software Engineering auf der Uni, Fachhochschule gibt und Leute dort 5+ Jahre verbringen, um das Rüstzeug für solide Architekturen und testbaren Code zu bekommen. Danach hat es auch sehr, sehr viel mit Erfahrung zu tun und mit Fehlern, die man hoffentlich machen darf, sofern man daraus lernt. Letztendlich ist es ein Handwerk, das man von der Pike lernen muss und über die Jahre verbessert/verfeinert.

Ein weiteres Thema mit massiven negativen Auswirkungen auf Datenbank-Backends sind O/R Mapper. In Bezug auf Performance und Optimierung haben O/R Mapper einen ganzen Industriezweig geprägt. Hersteller von Performance-Monitoring-Tools haben hier sehr gut verdient. O/R Mapper falsch eingesetzt, haben für mich immer folgende Analogie: Ein Rennpferd sieht einen 300kg Aushilfs-Jockey auf sich zukommen und denkt sich: "Shit, und jetzt muss ich genau so performen wie vor einer Woche mit einem 40kg Jockey?". Wenn man dann mal die Anwendungsentwicklung und einen fähigen DBA an einem Tisch bringt, wirds interessant, weil der DBA einfach nicht glauben will, was da alles für ein Sch... ausgeführt wird. Gut aber das ist jetzt hier nicht wirklich das Thema, aber O/R Mapper, falsch eingesetzt, sind eine tolle Spielwiese für inperformanten SQL Code.

Weil das Thema Caching gefallen ist. Ein herrliches und zugleich furchtbares Thema. Für mich ist der beste Cache der, den man nicht benötigt. Ein Cache ist eigentlich nur dann effektiv, wenn es sich um stabile Daten handelt, zB einmal beim Startup geladen und sich dann über die Programmlaufzeit nicht mehr verändert. Nur so wird man vermutlich eine hohe Cache-Hitrate von > 95% erhalten. Zum Beispiel Länder-ISO-Codes und deren Länderbezeichnungen oder etwas interessanter - da größer - Geo-Datenbanken (Mapping von Geo-Koordinaten auf Orte/Städte ...). Ab dem Zeitpunkt wo Daten im Cache verändert werden, wirds bedeutend kniffliger. Cache-Aktualität, Invalidierung, Lock Contention beim Updaten etc. werden dann wichtige Themen. Noch viel, viel schlimmer wirds bei verteilten Caches über Prozesse/Maschinen hinweg. zB ein Broadcast von Cacheänderungen hat gleich mal eine O(n2) Komplexität, was nicht skaliert. Es sind Projekte am (verteilten) Caching als Allheilmittel für Probleme in der Architektur böse gescheitert. Vor allem im Java-Umfeld. Im Delphi-Umfeld gehe ich jetzt nicht auf TClientDataset und CachedUpdates im Detail ein (bzw. ist auch schon sehr lange her). Man stelle sich vor, dass 50 Anwender/Maschinen Updates lokal cachen (uh, Caching) und dann auf die DB losgehen. Performance ist ev. das eine. Das andere sind dann Themen mit Datenintegrität (FK-Constraints), wo es ev. wieder Exceptions schmeißt, weil in einem cached Update ein Datensatz gelöscht wurde, den ein anderer Benutzer voraussetzt, dass es diesen gibt und was passiert dann mit dem Rest der gecachten Änderungen ...

Zurück zum Thema, warum mich dieser Thread interessiert. Firebird und Performance. Vor allem habe ich dann > 80K IOPS gelesen. Ist schon abartig was man 2019 alles zur Verfügung hat und dann trotzdem nichts hilft.

Aus Firebird-Sicht finde ich es toll wo das Projekt steht, vor allem auch weil die Entwicklung Geld kostet. Gut, wünschenwert wäre natürlich immer "mehr und besser". Aber es gibt ein stabiles 2.5/3.0er Release. Erste 4.0er Dev Builds sind verfügbar.
Es gibt eine 2019er Konferenz (https://firebirdsql.org/en/firebird-conference-2019/), wo auch 5.0 erwähnt wird. Macht irgendwo Bock nach Berlin zu fahren.

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.

[mkinzler]

@Thomas

[Codehunter]

Hat ja auch jeder eine andere Perspektive aufgrund ganz unterschiedlicher Anforderungen. Ich hatte ja geschrieben, ich brauche möglichst einfache Mittel, um einfach nur Daten zu pumpen. Bei MariaDB hatte ich A) wesentlich größere Blöcke und B) sowas simples wie Multi-Row-Inserts:

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

Jetzt extrapoliere man das auf 50.000 Rows hoch, dann erkennt man den Overhead bei Firebird. Einfaches sprachliches Defizit würde ich sagen. In Kombination mit der geringen Blockgröße provoziert Firebird unnötig viele Requests und damit genau das Laster wo es ohnehin seine größte Schwäche hat (TCP).

PS: Kommentare wie "Dann nimm doch wieder MariaDB" wären überflüssig. Es sind zwei völlig verschiedene Projekte und eine Migration steht nicht zur Debatte.

[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 von tsteinmaurer:

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.

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 von jobo:

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 von hoika:

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.

[TurboMagic]

Zitat von 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?

Hallo,

soweit ich mal wo gelesen habe kann Firebird "Array-DML", was genau für den Anwendungszweck
geeignet sein dürfte und FireDAC beherrscht das auch, wenn man weiß wie es zu benutzen ist.
Es gab da mal irgendwann ein EMBT Webinar dazu und da war auch die rede davon, das FireDAC
das Array-DML auf den DBs die das nicht von Haus aus können emuliert. Auch nett, oder?

Vielleicht fällt da dem IBExpert Experten was dazu ein?

Grüße

Turbo Magic

[mlc42]

Array DML funktioniert wirklich gut und ziemlich fix auf allen Plattformen mit denen ich
arbeite. Ich benutze das z.B.: um Tabellen oder ganze DB´s von einem Server auf einen anderen
zu kopieren. Als Anwendungsprogrammierer muss ich mich nicht drum kümmern was auf dem jeweligen
SQL Server dahintersteckt. Ein tolles Featuren von FireDAC.