Fragen bezüglich Performance von Firebird in einer Anwendung

[jobo]

Also ich finde, man kann erstmal niemand vorwerfen, dass er das System nutzt (und dabei überfordert bzw. nicht optimal arbeitet).
Und diese Dataset Klamotten und die datensensitiven Komponenten sind ja immerhin ein Teil der Erfolgsgeschichte. Warum soll ich mit Delphi ein RAD Tool einsetzen, mit dem ich aber lieber nicht RAD Entwicklung mache, sondern die DB schone?

Es gibt eine Geschichte -ich weiß nicht, ob sie stimmt- von einem Deutschen LKW Hersteller in Indien, wo ständig die Wagen zusammengebrochen sind und die Kunden sich beschwert haben. Der Hersteller hat gesagt, Ihr habt den Wagen überladen, das ist gegen die Nutzungs- und Garantiebestimmungen. Und die Kunden haben gesagt: Ich habe den Wagen einfach nur voll geladen.
Da der Hersteller in diesem Markt Fuß fassen wollte, hat er begonnen, seine LKW stärker auszulegen.

Mir ist ehrlich gesagt nicht klar gewesen, dass es so drastische Unterschiede gibt zwischen den System. Zu Delphizeiten habe ich mit Oracle gearbeitet. Nun arbeite ich viel mit Postgres, das sich angeblich ähnlich (schlecht) schlägt, wie Firebird. Das Phänomen ist mir aber in Webprojekten mit Postgres noch nicht aufgefallen.

Die Frage wäre doch nun, wie man dieses Manko aus Datenbanksicht erklären und ausbessern kann, ohne dabei alles umzukrempeln (in den Client Programmen). Denn das ist ja in vielen Fällen clientseitig offenbar aussichtslos (Aufwand).

Und es sind ja auch schon gute Punkte genannt worden.

Wieso nimmt Firebird sich nicht den verfügbaren Hauptspeicher, so dreist wie es MSSQL macht?! Es gibt sicher nichts schnelleres, als alles was geht im Hauptspeicher zu puffern! Vielleicht weil FB auch eine süße, kleine embedded DB ist und das einfach in den Köpfen der Entwickler rumwabert? Welches Feature macht da den Unterschied?
Wieso macht es Postgres nicht? Die Systeme laufen standardmäßig auch auf Raspy & Co und das ist eine Hardwareausrüstung, die vor 20 Jahren noch Desktop/Server Niveau war, heute ein Witz für Server. Teuren Speicher nahm man sich nicht einfach so. Aber, Speicher ist nicht mehr teuer. Warum nicht mal die Schleusentore öffnen? Das großzügiger zu handhaben dürfte doch nicht so ein Riesenfeature sein.

Ganz klar, ich bin nicht dafür, stumpf seinen inperformanten Standard Code abzuliefern, im Gegenteil. An vielen Stellen muss man halt erstmal drauf kommen, wie es besser gehen könnte. Dabei helfen solche Threads ja vielleicht.
Aber ich sag auch:
Wenn man von Delphi Entwicklern fordert, dass sie endlich mal ihre Hausaufgaben machen, dann fordert man das doch am besten auch von den Programmieren der Datenbank oder?

[hoika]

Hallo,
also ich hatte ja schon geschrieben.

Wir benutzen nur FB.

Jede Query bei uns wird geprüft, ob sinnvolle Indices vorhanden sind usw..
Und das bei verschiedenen DB-Größen (Stichwort Selektivität),
Das erfordert einen großen Aufwand, der sich im Endeffekt aber rechnet.
Trotzdem fallen wir manchmal doch rein, wenn z.B. ein Index sogar bei einem Select bremst,
kann passieren, kommt aber selten vor.

Wir benutzen übrigens keine TDB-Komponenten (aka datensensitiv).
Alle Listenanzeigen kommen in <TList>'s und werden über entsprechende Grid-Renderer "bearbeitet".

Viele Queries sind es nicht, die pro Arbeitsschritt (=Workflow) gestartet werden,
vielleicht mal 20/30, aber das sind dann schon viele.

Deshalb komme ich nicht in das Problem "FB viele Queries -> doof".

[IBExpert]

Zitat:

Zitat von jobo (Beitrag 1441222)

Wieso nimmt Firebird sich nicht den verfügbaren Hauptspeicher, so dreist wie es MSSQL macht?! Es gibt sicher nichts schnelleres, als alles was geht im Hauptspeicher zu puffern! Vielleicht weil FB auch eine süße, kleine embedded DB ist und das einfach in den Köpfen der Entwickler rumwabert? Welches Feature macht da den Unterschied?

Gerne ein wenig Erklärung dazu: stell dir mal vor du hast eine 100GB DB mit 100 tabellen die jeweils 1GB belegen, deine Abfrage beziehen sich aber ausschliesslich auf Daten einer Tabelle, deren Rohdaten 1GB belegen (nennt man bei firebird datenpages, indexpages, und noch ein wenig krams aus kleineren Systemtabellen und transaktionsdaten).

Ein ganz banaler select count() auf dieser Tabelle kann von Firebird nur dann beantwortet werden, wenn jede Recordversion auf sichtbarkeit/gelöscht geprüft wurde für den Transaktionskontext, aus dem das aufgerufen wurde. Repeatableread connections können zB andere Anzahlen sehen als Readcommitted usw.

Wie behandelt firebird nun deine Abfrage:

Es lädt sich alle erforderlich Pages von der Platte in den RAM und im RAM wird das dann auseinandergefrickelt.

Nehmen wir an, deine DB benutzt den Superserver 2x oder 30, bei dem es einen gemeinsamen Cache für alle gibt. In Tools wie IBExpert siehst du dann das zB der Wert Reads beim ersten Zugriff ziemlich hoch ist, reads sind die pages, die von platte in den RAM geladen wurden. Gehen wir mal davon aus das du 16k Pagegröße beim Anlegen der DB benutzt hast und als cache buffers 100000 eingestellt hast. Damit weiss firebird, es kann bis zu 1,6 GB RAM fest benutzen. Deine komplette Tabelle belegt aber gerade mal 1GB, also ca 65000 pages. In den Reads wirst du sehen, das zu deinem SQL 65000 pages in reads stehen und die wurden auch im Speicher in etwa nun physikalisch belegt +x für das was der prozess eh braucht.

Warum aber Firebird irgendwas in den RAM packen sollte was keiner wissen will, erschliesst sich mir nicht.

Nun kommt der zweite Client und will auch noch mal einen Count wissen. Was passiert? Firebird nimmt das SQL entgegen,analysiert dazu wie schon beim ersten Mal die erforderlichen Pages und merkt beim Superserver, huch, die sind ja schon im Speicher, also brauch nix nachgeladen werden, sondern es kann gleich im RAM losgehen. In den Reads liest du nun übrigens auch 0 , d.h. alles was gebraucht wird, war schon im ram.

Solange nicht alle zugewiesenen CachePages belegt sind und für andere Pages weiterer RAM gebraucht wird, wird firebird superserver die daten auch nicht mehr aus dem ram rausschmeissen, es sei denn, die letzte Connection meldet sich dann auch noch ab und es ist kein Client mehr verbunden. Sobald jemand dann neu kommt geht das wieder von vorne los, wenn man das vermeiden möchte lässt man immer einen client aktiv.

Es ergibt aber immer noch keinen sinn, die nächten 100GB RAM mit Tabellen vollzumüllen, die keiner braucht. Schon gar nicht auf einer Maschine, die eben nicht 1GB RAM frei hat (Bedenke, es gab bis vor einigen Jahren und auch heute noch 32bit Versionen von Datenbanksystemen, die bei 2GB dicke backen machen. Firebird kann auch als 32bit Version im Gegensatz zum Beispiel zu MS Access mdb auch eine 10TB Datenbankdatei öffnen und sauber verwalten, aber prozesstechnisch gehen da nicht mehr als 2GB RAM in der 32 Bit Welt).

Und spätestens bei der 2TB Datenbank könnte es eng werden mit alles im RAM.

Sicherlich erfordern komplexe Abfrage mit group by etc einiges mehr an RAM, Global Temp Tables arbeiten komplett im RAM oder Recordversionen, Tempspace ist zunächst ram, wenn aber mehr gebraucht wird, ausgelagert, aber das ist alles konfigurierbar, wen man es braucht und der RAM da ist. Firebird läuft aber auch heute noch auf minimal Hardware mit vollem Funktionsumfang und insbesondere mit Betriebssystemen wie Linux ist das sehr gut skalierbar. Und die Standard Konfiguration ist nicht so schlecht, mit falschen Parametern kann man auch viel falsch machen.

Zu viel RAM muss übrigens kein Vorteil sein, weil dann ggf zu ändernde Pages wesentlich länger im RAM bleiben und erst mit dem Commit auf den Datenträger geschrieben werden (das aber eben mit forced writes in einer extrem robusten reihenfolge, die bei windows ohne forced writes verändert wird und ein servercrash ohne forced writes auf windows gerne mal in einer kaputten datenbank enden kann. Unter linux kann ich das auf filesystemeben vermeiden und deutlich besser optimieren, als das was windows in ntfs das selber macht. Bei Dialogsoftware kommt dann unglücklicherweise beim speichern eine Wartezeit zustande, die der Anwender merkt, aber bei kleinerem Cache wären die Pages ggf zum Teil schon vorher wieder auf dem Datenträger.

Microsoft SQL Server ist von Microsoft und hat halt unter Windows die Angewohnheit zu sagen, der Rechner gehört mir und nur wenn was übrig bleibt, kann das jemand anders haben.
Welche Tricks da laufen weiß ich nicht, aber ein von mir mal auf Linux gemachter tpc Benchmark mit Firebird30 und MSSQL auf Linux brachte eine überraschend ähnliche Leistung, bei der Firebird aber sogar noch besser war, der erreichte tpc Wert für den MSSQL Server auf dieser Maschine (Kosten ca 4000€) aber laut Vergleichstabelle dieses tpc benchmarks in Bereichen lag, die ansonsten kein aktueller Windows mssql server unter 40000 US$ gebracht hat.

Leider hab ich das nicht gut dokumentiert und müsste das ggf ncoh mal zusammensuchen, aber wer weiß, wenn ich zeit hab mach ich das noch mal.

Wie schon geschildert, MSSQL mag scheinbar mit dataset/datasource/lookup/master-detail Delphi Applikationen wie besser klarkommen, es ist aber für optimierte Anwendung nicht annähernd 4-10 mal schneller.

btw: RAM und x4 m.2 SSDs sind vom Speed her nicht mehr so unterschiedlich, Ram ist bei größeren Blöcken oft gerade mal doppelt so schnell, wenn überhaupt. Mach einfach mal benchmarktests auf ssd und auf Ramdisk, das ist je nach Aufgabenstellung meiste nähere aneinander als man erwarten würde.

[Codehunter]

Also wenn man die Changelogs zu FB 4.0 liest merkt man schon, dass die Entwickler eine Flaschenhälse im Netzwerkinterface von FB angegangen sind. Speziell bei vielen kleinen Anfragen trennt FB sehr früh die TCP-Verbindung, sodass die neu ausgehandelt werden muss. Insofern würde ich sagen, schaukeln sich hier die Eigenarten von FB und Delphi gegenseitig zu einem Problem hoch.

Aus den o.g. Gründen bewirken Einstellungen am DB-Cache auch verhältnismäßig wenig. Und umso stärker wirkt sich das Problem aus, je mehr Clients am Server hängen und je schlechter das Netzwerk konstruiert ist (z.B. billige Switches mit minimalem ARP-Cache, Mesh-WLAN etc.).

In der Konsequenz müssen Delphientwickler die FB nutzen, einen erhöhten Aufwand betreiben, performante Clients zu schreiben. Damit wird der Gedanke, der hinter RAD mal stand, ad absurdum geführt. Die Tatsache, dass es Spezialisten (neudeutsch "Berater") braucht, die Delphientwickler coachen, bestätigt das ja ein Stück weit. Klar kann man mit FB performante Anwendungen schreiben. Kann man wohl mit jedem aktuellen, auf heutige Multicore-CPUs optimierten DBMS.

Die entscheidende Frage ist: Mit welchem DBMS kann man mit Delphi am schnellsten das RAD-Konzept umsetzen? Intuitiv so, wie es mal von Borland gedacht war. Die Antwort möge jeder sich selbst geben...

[Schokohase]

Dieses RAD ist ja ganz nett für ein Prototyping, "schnell mal was darstellen" oder wirklich einfache Projekte.

Aber sobald das Projekt anfängt ernsthafter zu werden und eine gewisse Komplexität erreicht, dann sollte man sich von RAD verabschieden und die Anwendung in Schichten aufbauen.

Bei RAD bekommt man keinen (unabhängig) testbaren Code (Unit-Tests) und das sollte ab einer bestimmten Komplexität ein NO-GO sein.

[hoika]

Hallo,

Zitat:

Bei RAD bekommt man keinen (unabhängig) testbaren Code (Unit-Tests)

Einspruch Euer Ehren.

Delphi-Quellcode:

procedure TForm1.Btn1Click (OK, Btn1 ist schon mal doof ;) )
begin
  TMeinController.MacheWasWichtiges()
end;

class procedure TMeinController.MacheWasWichtiges();
begin
  if IrgendEineAbfrage() then
  begin
    TMeinService.NuAber().
  end;
end;

Wer stur den Code in TForm1.Btn1Click reinschreibt
-> OK, Vorredner hat Recht

[Jumpy]

Der eine sagt, wenn der Entwickler vernünftig arbeitet klappt es auch mit der Datenabank.
Der andere sagt, wenn die bei der Datenbank was ändern wäre die vielleicht besser mir Delphi, ander könnens ja auch.

Es hat aber noch keiner gesagt: Wenn die DB-Controls verbessert würden, könnte auch vieles besser werden, oder?


Es kann natürlich sein, dass da keiner mehr Arbeit rein stecken will, weil der Trend ja eh von RAD/DB-Controls weg geht, wegen der Dinge die Schokohase gesagt hat und weil die DB-Controls ja auch andere Probleme haben. Aber ich wollte trotzdem die dritte Ecke dieses Spannungsdreiecks erwähnt haben.

[jobo]

Muss man wirklich den Nutzen von Cache Mechanismen bezweifeln oder die Nachteile von Chaching als Argument gegen eine Optimierung nehmen? Muss man angesichts von tausenden Libs, Komponenten und Frameworks in Frage stellen, ob RAD eine Berechtigung hat?
Ich hab es sicher schon mal irgendwo geschrieben, aber ich habe an Delphi immer die Kontinuität geschätzt, die durch die VCL möglich wurde. Egal ob und was MS erfunden oder in die Tonne gehauen hat, es war mit Delphi meist kein Weltuntergang.

Ich finde es super, wenn in Threads wie diesen Potential für Verbesserungen aufgedeckt wird. Keine Ahnung, wieviel Firebird Entwickler hier mitlesen-vielleicht keiner-, aber was Delphi selbst und das Verbesserungspotential seiner Komponenten angeht, sehe ich da schon Potential. Über die gemeinsame Geschichte mit Interbase gibt es ja vielleicht auch an der Ecke eine Wahrnehmung. Die Hinweise von Codehunter zeigen so oder so, dass man offenbar einige Probleme wahrnimmt und angeht.

Und wir alle wissen, was passiert, wenn man an einer Seite der Tischdecke zieht. Spannend wird es doch, wenn solche Diskussion zeigen, wo Falten in der Tischdecke sind und man sich damit auseinandersetzen kann, diese glatt zu ziehen, aus welcher Ecke auch immer. (Oder künftig wenigstens sein Geschirr neben die Falten stellen zu können, wem es reicht)

[IBExpert]

Zitat:

Zitat von Codehunter (Beitrag 1441267)

Also wenn man die Changelogs zu FB 4.0 liest merkt man schon, dass die Entwickler eine Flaschenhälse im Netzwerkinterface von FB angegangen sind. Speziell bei vielen kleinen Anfragen trennt FB sehr früh die TCP-Verbindung, sodass die neu ausgehandelt werden muss. Insofern würde ich sagen, schaukeln sich hier die Eigenarten von FB und Delphi gegenseitig zu einem Problem hoch.

sorry, vielleicht bin ich ja auch nur zu blöd, das zu verstehen, aber Firebird trennt gar keine TCP/IP Verbindung, ohne das der Client das verursacht. Wo die Info also her kommt ist mir neu. Und wenn eine TCP Verbindung bzw Socketconnection z.B. durch den tcpipe.exe connected ist, wird da weder was ab- noch ungefragt wieder aufgebaut, es sei denn, der Client möchte das oder der Server ist der Meinung, der Client ist dauerhaft nicht erreichbar. Ich für meinen Teil sehe keine technische Grundlage für die o.a. Aussage und ich hab schon mehr als genug Socketconnections auf dem Wege damit untersucht.

Das Flaschenhälse im Netzwerkinterface existieren ist unbestritten und das die in fb4 im Fokus stehen, ist auch ok, aber das sich da irgendwas ohne Grund auf und wieder abbaut ist mir neu.

[Frickler]

Zitat:

Zitat von hoika (Beitrag 1440085)

Es gab mal bei HK Software einen DB-Monitor,
wo man die einzelnen SQL-Befehle protokollieren konnte,
ohne das es die eigentliche Anwendung mitbekommt ...
Ich finde den Monitor aber nicht mehr (habe den damals sogar selber gekauft).

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.

[tsteinmaurer]

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

[Schokohase]

Zitat:

Zitat von hoika (Beitrag 1441283)

Hallo,

Zitat:

Bei RAD bekommt man keinen (unabhängig) testbaren Code (Unit-Tests)

Einspruch Euer Ehren.

Delphi-Quellcode:

procedure TForm1.Btn1Click (OK, Btn1 ist schon mal doof ;) )
begin
  TMeinController.MacheWasWichtiges()
end;

class procedure TMeinController.MacheWasWichtiges();
begin
  if IrgendEineAbfrage() then
  begin
    TMeinService.NuAber().
  end;
end;

Ja, nee ... das ist auf jeden Fall nicht das was ich meinte ... das ist (nein, ich sage es nicht).

[mlc42]

Weiß jemand ob FireDAC schon mit FB4 klar kommt? Dann würde ich gerne mal Tests machen
ob sich da etwas grundsätzlich verbessert hat.

Ich finde es ein bischen Schade das seitens der Firebirdanhänger meist argumentiert wird,
FB ist super, da muss man nix verbessern, der Anwendungsprogrammierer hat die falschen Werkzeuge
benutzt oder schlicht keine Ahnung. So trivial ist es in der Praxis nicht.
Wenn man vor der Wahl steht Berge von altem Code zu ändern, die geprüfte Verläßlichkeit dabei
aufzugeben oder einfach ein dafür geeigneteres Werkzeug zu verwenden liegt es auf der Hand
welchen Weg man aus wirtschaftlichen, zeitlichen und Stabilitätsgründen geht.

Der Threaderöffner fragte ja nach der Anwendungsperformance die man von Firebird erwarten kann.
Er kann aus dem Thread die Erkenntniss mitnehmen das FB eine gute Performance liefert wenn man
passend programmiert und gewisse Fallstricke vermeidet.

Ich für meinen Teil habe kein Problem damit , da ich bei den Kunden einfach umschalten kann.
Ich würde mich freuen wenn die 4.0 das besser macht. Warum nicht ein gutes Produkt verbessern :)

[Codehunter]

Ich muss sagen, ich finde dieser Thread hier ist eine der Sternstunden der DP. Hier kommt so viel Knowhow zusammen. Wenn man als Frontend-Entwickler aufmerksam mitliest, sieht man das es nicht den einen golden Weg gibt. Es ist nie verkehrt, Dinge zu hinterfragen, selbst wenn man etwas schon 20 Jahre auf eine bestimmte Weise gemacht hat.

Zur "Firebird-Sentimentalität": In gewisser Weise verhält sich Firebird zu Interbase so, wie MariaDB zu MySQL. Der Community-Fork gegen den kommerziellen Platzhirsch. Stellenweise ist die Community flexibler, liberaler und manchmal einfach auch schneller mit der Einführung neuer Features.

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. Entscheidend ist also vor allem: Wie viel Aufwand muss ich treiben, um meine Milestones zu erreichen? In dem Punkt scheint FB doch eine recht teure Gratis-Lösung zu sein.

[p80286]

Zitat:

Zitat von Codehunter (Beitrag 1441376)

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. Entscheidend ist also vor allem: Wie viel Aufwand muss ich treiben, um meine Milestones zu erreichen? In dem Punkt scheint FB doch eine recht teure Gratis-Lösung zu sein.

Gut gebrüllt Löwe, aber bei den Platzhirschen O&M wird zähneknirschend ein DB-Admin mit ein paar Kursen akzeptiert, bei FB,Postgres und Konsorten soll das vom Himmel fallen?
Eine Einführung welche Schrauben was bewirken, sollte schon dabei sein, aber ein notwendiges Tuning für z.B. stark BLOB-lastige DB darf schon etwas kosten, aber dann sollte auch klar darauf hingewiesen werden, das die gewünschten Fähigkeiten eben nicht so einfach als Standardinstallation verfügbar sind.


Gruß
K-H

P.S.
Auch ich begrüße es, wenn durch Selbststudium das Wissen erweitert werden kann, aber irgendwann muß man auch fragen ob tagelanges Suchen und Basteln wirklich biliger ist als 2*8Stunden intensive Fortbildung.

[hoika]

Hallo,
#Schokohase

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

[Schokohase]

Zitat:

Zitat von hoika (Beitrag 1441410)

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 :-D). 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. :thumb:

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

[mkinzler]

@Thomas :thumb:

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

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

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:

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

[Codehunter]

Zitat:

Zitat von hoika (Beitrag 1441532)

Hallo,

Zitat:

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

Wenn er groß genug ist ;)

https://www.amazon.de/dp/B07PLWKBVJ

+

https://www.amazon.de/dp/B07JHGMNC5

Geht noch als "Stick" durch und müsste knapp drauf passen :twisted:

[TurboMagic]

Zitat:

Zitat von hoika (Beitrag 1441502)

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.