AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Datenbanken Fragen bezüglich Performance von Firebird in einer Anwendung

Fragen bezüglich Performance von Firebird in einer Anwendung

Ein Thema von TK8782 · begonnen am 8. Aug 2019 · letzter Beitrag vom 15. Aug 2019
Antwort Antwort
Seite 7 von 8   « Erste     567 8   
hoika

Registriert seit: 5. Jul 2006
Ort: Magdeburg
8.269 Beiträge
 
Delphi 10.4 Sydney
 
#61

AW: Fragen bezüglich Performance von Firebird in einer Anwendung

  Alt 15. Aug 2019, 15:47
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?
Heiko

Geändert von hoika (15. Aug 2019 um 17:05 Uhr)
  Mit Zitat antworten Zitat
jobo

Registriert seit: 29. Nov 2010
3.072 Beiträge
 
Delphi 2010 Enterprise
 
#62

AW: Fragen bezüglich Performance von Firebird in einer Anwendung

  Alt 15. Aug 2019, 15:50

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.
Gruß, Jo
  Mit Zitat antworten Zitat
Benutzerbild von IBExpert
IBExpert

Registriert seit: 15. Mär 2005
642 Beiträge
 
FreePascal / Lazarus
 
#63

AW: Fragen bezüglich Performance von Firebird in einer Anwendung

  Alt 15. Aug 2019, 15:53
Nur ein paar Gedanken, in der Hoffnung, dass ich niemanden auf die Füße getreten bin.
Holger Klemt
www.ibexpert.com - IBExpert GmbH
Oldenburger Str 233 - 26203 Wardenburg - Germany
IBExpert and Firebird Power Workshops jederzeit auch als Firmenschulung
  Mit Zitat antworten Zitat
Benutzerbild von IBExpert
IBExpert

Registriert seit: 15. Mär 2005
642 Beiträge
 
FreePascal / Lazarus
 
#64

AW: Fragen bezüglich Performance von Firebird in einer Anwendung

  Alt 15. Aug 2019, 16:15
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
Holger Klemt
www.ibexpert.com - IBExpert GmbH
Oldenburger Str 233 - 26203 Wardenburg - Germany
IBExpert and Firebird Power Workshops jederzeit auch als Firmenschulung
  Mit Zitat antworten Zitat
Benutzerbild von Codehunter
Codehunter

Registriert seit: 3. Jun 2003
Ort: Thüringen
2.272 Beiträge
 
Delphi 10.4 Sydney
 
#65

AW: Fragen bezüglich Performance von Firebird in einer Anwendung

  Alt 15. Aug 2019, 16:21
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.
Ich mache grundsätzlich keine Screenshots. Schießen auf Bildschirme gibt nämlich hässliche Pixelfehler und schadet der Gesundheit vom Kollegen gegenüber. I und E zu vertauschen hätte den selben negativen Effekt, würde aber eher dem Betriebsklima schaden
  Mit Zitat antworten Zitat
Benutzerbild von IBExpert
IBExpert

Registriert seit: 15. Mär 2005
642 Beiträge
 
FreePascal / Lazarus
 
#66

AW: Fragen bezüglich Performance von Firebird in einer Anwendung

  Alt 15. Aug 2019, 17:02
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!!
Holger Klemt
www.ibexpert.com - IBExpert GmbH
Oldenburger Str 233 - 26203 Wardenburg - Germany
IBExpert and Firebird Power Workshops jederzeit auch als Firmenschulung

Geändert von IBExpert (15. Aug 2019 um 17:05 Uhr)
  Mit Zitat antworten Zitat
Frickler

Registriert seit: 6. Mär 2007
Ort: Osnabrück
557 Beiträge
 
Delphi XE6 Enterprise
 
#67

AW: Fragen bezüglich Performance von Firebird in einer Anwendung

  Alt 15. Aug 2019, 18:22
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?
  Mit Zitat antworten Zitat
mkinzler
(Moderator)

Registriert seit: 9. Dez 2005
Ort: Heilbronn
39.851 Beiträge
 
Delphi 11 Alexandria
 
#68

AW: Fragen bezüglich Performance von Firebird in einer Anwendung

  Alt 15. Aug 2019, 18:23
Dabei handelt es sich um die BLOBID. Die eigentlichen Daten werden ja getrennt von der Tabelle gespeichert.
Markus Kinzler
  Mit Zitat antworten Zitat
Frickler

Registriert seit: 6. Mär 2007
Ort: Osnabrück
557 Beiträge
 
Delphi XE6 Enterprise
 
#69

AW: Fragen bezüglich Performance von Firebird in einer Anwendung

  Alt 15. Aug 2019, 18:42
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!

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
Bekomme ich MSSQL incl. EXE auf einen USB-Stick für den Außendienst?
  Mit Zitat antworten Zitat
hoika

Registriert seit: 5. Jul 2006
Ort: Magdeburg
8.269 Beiträge
 
Delphi 10.4 Sydney
 
#70

AW: Fragen bezüglich Performance von Firebird in einer Anwendung

  Alt 15. Aug 2019, 19:19
Hallo,
Zitat:
Bekomme ich MSSQL incl. EXE auf einen USB-Stick für den Außendienst?
Wenn er groß genug ist
Heiko
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 08:20 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz