DBMS gesucht

Wutz

40 Sekunden für das Einfügen von 100.000 Zeilen zu langsam

Kaum zu glauben.
Wie wärs mit SQLite oder Oracle-XE?
Für Oracle-XE gibts ODBC&Co, einige fertige OCI Wrapper sowie ein fertiges Docker-Image. Ich kann mir nicht vorstellen, dass dein 100.000er Insert mehr als 2 Sek. dauert, selbst bei dem 2-CPU-Limit.

SeppJ

@Wutz sagte in DBMS gesucht:

@DocShoe sagte in DBMS gesucht:

40 Sekunden für das Einfügen von 100.000 Zeilen zu langsam

Kaum zu glauben.
Wie wärs mit SQLite oder Oracle-XE?

@DocShoe sagte in DBMS gesucht:

Ich habe jetzt Bulk Inserts mit 2.500 Einträgen per INSERT, damit komme ich auf etwas über 3 Sekunden für 100K Zeilen, das ist schon ganz gut und damit können wir leben, denke ich.

Ja, nee. Gleich andere Systeme empfehlen, anstatt erst einmal zu gucken, ob der Fragesteller nicht vielleicht einen Anfängerfehler bei der Benutzung gemacht hat…

Wutz

@SeppJ
Naja, was soll man beim einfachen Insert denn groß verkehrt machen können, die Persistierung erfolgt doch sowieso erst beim Commit. Sowas muss ein DBMS einfach können und im Zweifelsfall auch schon mal glattbügeln.
Ich habe bei Oracle noch nie ein 40 Sek. Commit gesehen, und ich mach das schon ne ganze Weile, auch schon zu Zeiten, bei denen die Manager noch nichts von BigData gefaselt haben.

Th69

@Wutz: Du verstehst anscheinend nicht wie Datenbanken bzgl. Commit und Rollback arbeiten. Ein Commit ist immer sehr schnell, weil die ganzen Transaktionen schon während des Einfügens (sowie Updates oder Löschen) vorgenommen werden - nur ein Rollback dauert dann länger, weil dieser dann anhand des Transaction-Logs diese wieder umgekehrt rückgängig macht (ein Rollback sollte ja nur in Ausnahmesituationen auftreten).

s. z.B. Overview of Transaction Management (auch wenn es dort etwas anders ausgedrückt wird).

hustbaer

Lieber @Wutz, Programmierer wie du sind schuld daran dass so viele Datenbank-gestützte Systeme so langsam sind. Danke.

Wenn du ernsthaft meinst es wäre für gute Performance nicht nötig Batch-Processing zu machen... naja, weiss nicht was man dazu noch gross sagen soll.

ps:

Ich kann mir nicht vorstellen, dass dein 100.000er Insert mehr als 2 Sek. dauert, selbst bei dem 2-CPU-Limit.

Falls du es nicht überzuckert haben solltest: Er hat nicht "ein 100.000er Insert" gemacht, er hat 100.000 Insersts mit je einer Zeile gemacht.

Wutz

@hustbaer
Witzbold.
Ich hab noch nie ein Bulk-Insert gebraucht, das ist auch praxisirrelevant, da hierfür gleichgelagerte Inserts vorliegen müssten, und solch stupide Aktionen sind für mich wie gesagt irrelevant, ich rede von verschiedenen Joins >20 in jedem Statement; das wird alles von Oracle glattgebügelt, und zwar ohne irgendwelche Optimizer-Hints.
Die wesentliche Zeit geht dabei im Netzwerk verloren, wenn der Client eben nicht in der Cloud steht; noch viel mehr bei selects statt inserts.
Und auch dabei sind 40 Sek bei nur 100.000 Statements (oder wie du es zu belieben ausdrückst: Zeilen) unglaubwürdig, wenn es nicht gerade BLOBs sind.
Ich kümmere mich um das Wesentliche, nämlich um die (möglichst fachliche) Optimierung der Joins und nicht um profanes Tagesgeschäft eines DBMS wie das Zusammenfassen gleichartiger Statements, die auch noch direkt hintereinander erfolgen.

DocShoe

Danke an alle für die Hinweise!

Ich glaube, ich fasse noch mal zusammen
Ich schrub oben, dass jeder Eintrag prinzipiell ein Key/Value Paar ist. Aber auch nur prinzipiell, im Grunde soll sich der Parameter selbst beschreiben und bekommt noch ein paar Zusatzinformationen mit (Anzeigename, Kanonischer Name, Beschreibung, Minimum, Maximum, Defaultwert, Datentyp und Formatanweisungen), das sind insgesamt 13 Felder. Das ist wahrscheinlich auch der Grund, warum einige Leute hier meinen, das sei mit max. 2 Sekunden abgefrühstückt, weil sie halt nur von Key/Value ausgehen konnten. 100K Zeilen sind jetzt auch der worst case, in der Regel werden es sehr viel weniger sein. Ich bin deshalb von 100K Zeilen ausgegangen, weil´s dann nicht mehr "schlimmer" werden kann.

Ich habe anfangs jeden Datensatz einzeln in die DB geschrieben, weil ich den INSERT so formuliert habe, dass er mir den vom DBMS zugeteilten Primary Key dem Objekt zugeordnet hat, sowas in der Art wie:

void SomeDBInterface::insert_parameter( Parameter& param )
{
   auto stmt = somedbmsobj.prepare( ... );
   stmt.execue();
   param.ID = stmt.field_value<unsigned int>( 0 );
}

Mit Bulk Insertions geht das jetzt nicht mehr, dazu muss ich erst alle Parameter zurücklesen, aber das macht erst mal nichts.

SQLite scheidet aus, weil es eine zentrale DB werden soll, auf die von verschiedenen Rechnern aus zugegriffen wird. SQLIte hat kein dedizierten Server, sondern steuert Transaktionen und Concurrency über Mutexes, das geht, soweit ich weiß, nicht, wenn verschiedene Rechner auf das gleiche DB File zugreifen.

Mit Oracle unter Windows habe ich keine guten Erfahrungen gemacht, das war viel Frickelei, musste mich aber auch nur oberflächlich damit beschäftigen. Und ich weiß auch nicht, ob die XE Variante nicht irgendwelche Einschränkungen hat, die uns hinter Probleme bereiten.

hustbaer

@Wutz sagte in DBMS gesucht:

Ich hab noch nie ein Bulk-Insert gebraucht, das ist auch praxisirrelevant, da hierfür gleichgelagerte Inserts vorliegen müssten, und solch stupide Aktionen sind für mich wie gesagt irrelevant,

Na schön dass du anscheinend gerne auf Fragen über Dinge antwortest die für dich irrelevant sind, und dabei dann völlig ignorierst dass deine Antwort dadurch irrelevant wird.

Ich kümmere mich um das Wesentliche, nämlich um die (möglichst fachliche) Optimierung der Joins und nicht um profanes Tagesgeschäft eines DBMS wie das Zusammenfassen gleichartiger Statements, die auch noch direkt hintereinander erfolgen.

Du verwendest JOINs statt 1+N SELECTs, verstehst aber nicht dass es wichtig ist mehrere INSERTs zusammenzufassen. Interessant.

*john 0

@DocShoe sagte in DBMS gesucht:

Ich schrub oben, dass jeder Eintrag prinzipiell ein Key/Value Paar ist. Aber auch nur prinzipiell, im Grunde soll sich der Parameter selbst beschreiben und bekommt noch ein paar Zusatzinformationen mit (Anzeigename, Kanonischer Name, Beschreibung, Minimum, Maximum, Defaultwert, Datentyp und Formatanweisungen), das sind insgesamt 13 Felder.

Das ist Objektserialisierung nach Schema-F, und Dein Grund für die Probleme. Keys brauchst Du bei korrekter Nutzung des RDBMS gar nicht, weil die Keys die Struktur in der DB ist. Die Prüfung der Werte übernimmt ebenfalls das RDBMS. Es macht Arbeit die DB Struktur zu pflegen, aber dafür gewinnt man sehr viel mehr Performance.

Ich habe anfangs jeden Datensatz einzeln in die DB geschrieben, weil ich den INSERT so formuliert habe, dass er mir den vom DBMS zugeteilten Primary Key dem Objekt zugeordnet hat, sowas in der Art wie:
void SomeDBInterface::insert_parameter( Parameter& param )
{
   auto stmt = somedbmsobj.prepare( ... );
   stmt.execue();
   param.ID = stmt.field_value<unsigned int>( 0 );
}

Autsch, mit MySQL gelernt? Richtige RDBMs haben Sequenzen, daraus holt man sich die IDs für die Primary Keys vor dem INSERT und führt dann den INSERT mit der geholten ID durch.

DocShoe

@john-0
Irgendwie erinnern mich deine Antworten immer an MS-Doku. Technisch korrekt, aber irgendwie nicht zu gebrauchen.

*john 0

@DocShoe sagte in DBMS gesucht:

@john-0
Irgendwie erinnern mich deine Antworten immer an MS-Doku. Technisch korrekt, aber irgendwie nicht zu gebrauchen.

Du bist auf einem Tripp der die Dich in die komplett falsche Ecke führt, sehen willst Du das aber nicht. Weshalb nutzt Du überhaupt ein RDBMS, wenn es eine simple Textdatei auf einem Fileserver auch täte bzw. ein Blob im RDBMs? Die Vorteile eines RDBMS nutzt Du durch Deiner Art und Weise der Nutzung des selben definitiv nicht. Key-Value-Paare legt man in keinem RDBMS ab, denn die „Keys“ gehören in die Tables d.h. der Struktur der Datenbank.

Anstatt nun die Bohrhammer dafür zu nutzen ein Loch zu bohren, dieses anschließend aus zu saugen, dann einen Dübel rein zu stecken und anschließend die Schraube einzuschrauben, hast Du Dich dazu entschlossen mit dem Hammer die Schraube in die Wand zu schlagen. Ja, das geht, aber sinnvoll ist es nicht.