Frage zur INSERT INTO Geschwindigkeit



  • kellerassel schrieb:

    und was willst du mit so einem scheiß benchmark? bulk insert's kommen in real world apps doch nie vor 🙄

    Du musst es ja wissen 🙄. Aber deswegen brauchst du es noch lange nicht als "Scheiß" bezeichnen. Hast wohl kein Benehmen gelernt 😉



  • dann ist es eben ein blender benchmark :p



  • je nachdem, wie groß bei dir ein Datensatz sein kann und was dein DBMS zulässt kannst du pro Query paar hundert bis paar tausend Rows gleichzeitig einfügen

    Oh und du solltest wirklich abbrechen, wenn es Fehler gibt



  • kellerassel schrieb:

    und was willst du mit so einem scheiß benchmark? bulk insert's kommen in real world apps doch nie vor 🙄

    Bloedsinn. In vielen Anwendungen kommen die dauernd vor.



  • @MisterX
    Und wenn du gleich alle 2000 Zeilen mit einem INSERT machst, dann wird es vermutlich nochmal schneller.



  • hustbaer schrieb:

    @MisterX
    Und wenn du gleich alle 2000 Zeilen mit einem INSERT machst, dann wird es vermutlich nochmal schneller.

    Ja, das denke ich auch. Ich frage mich nur , ob es eine Beschränkung gibt wieviele Zeilen (Datensätze) mit einem einzigen INSERT gemacht werden dürfen.

    Da ja mit einzelnen INSERTs weniger als 100 Einträge in der Sekunde möglich sind, wäre es da nicht sogar sinvoll, alle Inserts von allen Anwendern eine Sekunde lang zu sammeln und dann in einem einzigen Befehl oder umgeben von TRANSACTION einzutragen?

    Meine Tabelle stellt keine wirkliche Datenbank dar. Ich übe zur Zeit nur den praktischen Umgang mit relationalen Datenbanken, der an der UNI (mehr oder weniger) theoretisch gelehrt wird.



  • MisterX schrieb:

    Ja, das denke ich auch. Ich frage mich nur , ob es eine Beschränkung gibt wieviele Zeilen (Datensätze) mit einem einzigen INSERT gemacht werden dürfen.

    Es gibt eine maximal Länge die ein Statement haben kann.

    Bei mysql ist es zB max_allowed_packet



  • MisterX schrieb:

    Da ja mit einzelnen INSERTs weniger als 100 Einträge in der Sekunde möglich sind

    Das kann man so pauschal nicht sagen.

    wäre es da nicht sogar sinvoll, alle Inserts von allen Anwendern eine Sekunde lang zu sammeln und dann in einem einzigen Befehl oder umgeben von TRANSACTION einzutragen?

    Meistens nicht. Konsistenzbedingungen erschweren dir das. Und Transaktionen haben ja durchaus ihren Sinn und Zweck.

    Meine Tabelle stellt keine wirkliche Datenbank dar. Ich übe zur Zeit nur den praktischen Umgang mit relationalen Datenbanken, der an der UNI (mehr oder weniger) theoretisch gelehrt wird.

    Ohne einen konkreten Anwendungsfall wird es aber sehr schwer sein, sich solche Fragen zu beantworten.



  • MisterX schrieb:

    Da ja mit einzelnen INSERTs weniger als 100 Einträge in der Sekunde möglich sind, wäre es da nicht sogar sinvoll, alle Inserts von allen Anwendern eine Sekunde lang zu sammeln und dann in einem einzigen Befehl oder umgeben von TRANSACTION einzutragen?

    und der user wartet dann eine sek, oder sagst du ihm einfach, dass es funktioniert hat 😕



  • kellerassel schrieb:

    MisterX schrieb:

    Da ja mit einzelnen INSERTs weniger als 100 Einträge in der Sekunde möglich sind, wäre es da nicht sogar sinvoll, alle Inserts von allen Anwendern eine Sekunde lang zu sammeln und dann in einem einzigen Befehl oder umgeben von TRANSACTION einzutragen?

    und der user wartet dann eine sek, oder sagst du ihm einfach, dass es funktioniert hat 😕

    Nennt sich Delayed Insert. Bringt aber gesamtgesehen hier keine Vorteile - delayed insert ist dann nett wenn das insert lange dauert, weil man dann im execution thread nicht auf completion warten muss. hier geht es aber darum alle zeilen so schnell wie möglich einzufügen, da hat ein delayed insert leider keine vorteile.


Anmelden zum Antworten