Firebird 4 bulk api

Themen rund um den praktischen Einsatz von Firebird. Fragen zu SQL, Performance, Datenbankstrukturen, etc.

Moderator: thorben.braun

Antworten
vr2
Beiträge: 8
Registriert: Fr 13. Apr 2018, 00:13

Mo 16. Apr 2018, 01:08

Hallo,

hat hier schon jemand Firebird 4 im Test und das bulk api genutzt? Dann würde ich mich gerne austauschen. Nutze im Moment den snapshot 959, finde aber keinen Hinweis, ob das bulk api dort enthalten ist bzw wie man das prüfen kann.

Grüße, Volker
Benutzeravatar
martin.koeditz
Beiträge: 27
Registriert: Sa 31. Mär 2018, 14:35

Mo 16. Apr 2018, 15:14

Hi Volker,

ich wusste gar nicht, dass dies in der Pipe ist. Aber nach allem was ich gelesen habe, ist dies wohl JDBC-spezifisch. Oder irre ich mich da? Mich würde interessieren was die Intension hiervon ist.

Gruß
Martin
Martin Köditz
it & synergy GmbH
vr2
Beiträge: 8
Registriert: Fr 13. Apr 2018, 00:13

Mo 16. Apr 2018, 18:55

Hi Martin,

die Anforderung kam aus dem jdbc-Umfeld, ist aber auch für andere Clients interessant. Dass es so spezifisch ist, dass man es nur von jdbc aus nutzen kann, glaub ich noch nicht. Über die neue Firebird3-Plugin-Schnittstelle müsste es eigentlich universell nutzbar sein.

Die Intention - Du meinst die für bulk api oder die Einschränkung auf jdbc? Das bulk api ist eine Möglichkeit, eine große Menge von Datensätzen performant in die DB zu bekommen. Bisher wurde das kaum unterstützt, außer durch external tables, die sind aber so eingeschränkt und sperrig, die sind dafür unbrauchbar. Auswertungssysteme haben diese Anforderung ständig.

Typischer Anwendungsfall ist der Import einer großen csv-Datei (1 Mio Sätze oder so) - oder ODBC oder Excel. Bisher hat man immer ordentlich overhead pro insert, selbst wenn man mit prepared statements arbeitet, egal ob von außen bspw über php oder von innen mit einem remote execute statement. Das bulk api soll diesen overhead aufs Minimum reduzieren, indem es (beim insert) nur noch ein insert gibt, dem alle Daten mitgegeben werden, vom Effekt her so:

insert into tbl values ((1,2,3), (4,5,6), (7,8,9))

Ich hab den bisherigen insert-Durchsatz mal auf einem brauchbar ausgestatteten (i7-CPU, SSD) Rechner gemessen, insert von 100 K Sätzen mit 40 Spalten, keine Indizes auf der Zieltabelle:
1. php -> DB: 4,7 K Sätze/sek
2. crossdb (remote execute statement): 13,9 K Sätze/sek

Schon wenn man diese beiden vergleicht, wird klar, wie sich der overhead für ein insert auswirkt. Zum Vergleich ein

3. einfaches Kopieren der 100K Sätze innerhalb der DB mit insert into ... select: 62,1 K Sätze/sek
Das bulk api sollte irgendwo zwischen 2. und 3., dem maximal möglichen insert-Durchsatz liegen

Grüße, Volker
Antworten