Hi,
könnte mir einer bitte auf einer tieferen Ebene erklären, warum mein SQL-Insert von einer row in eine Tabelle mit vielen Indizes sehr träge ist?
Also ich kann mir oberflächlich vorstellen warum, aber mich würde das gerne auf der tieferen Ebene verstehen. Hat es etwas mit der Heap-Struktur einer Datenbank zutun?
Und kann man ungefähr sagen, um wie viel Sekunden ein Index das Ganze verschleppt?
Viele Grüße und Danke!
Insert und Indizes
-
- User
- Beiträge: 439
- Registriert: Mittwoch 8. August 2018, 16:42
__backjack__: "Jemand der VB oder PHP kann, der also was Programmieren angeht irgendwo im negativen Bereich liegt (...)"
- __blackjack__
- User
- Beiträge: 13117
- Registriert: Samstag 2. Juni 2018, 10:21
- Wohnort: 127.0.0.1
- Kontaktdaten:
@naheliegend: Die relevanten Teile des neuen Datensatzes müssen halt nicht nur in die Tabelle eingetragen werden, sondern auch in alle Indexe. Das sollte aber eher nicht im Bereich von *Sekunden* liegen. Ausser das DBMS speichert auf Floppydisks.
„All religions are the same: religion is basically guilt, with different holidays.” — Cathy Ladman
-
- User
- Beiträge: 439
- Registriert: Mittwoch 8. August 2018, 16:42
Und die Indizes sind Objekte, die wie mit der eigentlichen Tabelle verknüpft sind?
Wie hoch ist die Laufzeit für das Einfügen in das Indexobjekt?
Normale Datenbanken sind doch als B-Baum aufgebaut oder? Und da hat doch das Einfügen O(log(n)) oder?
Wie hoch ist die Laufzeit für das Einfügen in das Indexobjekt?
Normale Datenbanken sind doch als B-Baum aufgebaut oder? Und da hat doch das Einfügen O(log(n)) oder?
__backjack__: "Jemand der VB oder PHP kann, der also was Programmieren angeht irgendwo im negativen Bereich liegt (...)"
Das kann man so überhaupt nicht beantworten. Dazu musst du dich auf ein konkretes Produkt einschiessen, und das en Detail studieren. Und dann gilt das für genau das. Verallgemeinern kann man da nicht viel. Denn neben den groben Details wie du sie selbst nennst gibt es himmelweite Unterschiede in zb Speichernutzung, Anordnung der Daten etc.
-
- User
- Beiträge: 439
- Registriert: Mittwoch 8. August 2018, 16:42
- __blackjack__
- User
- Beiträge: 13117
- Registriert: Samstag 2. Juni 2018, 10:21
- Wohnort: 127.0.0.1
- Kontaktdaten:
@naheliegend: Was sind denn ”normale Datenbanken” und was heisst ein allgemeines „sind als B-Trees aufgebaut“? Ein B-Tree ist ja nur *eine* von vielen möglichen Datenstrukturen. Was konkret für einen Index im Hintergrund verwendet wird wenn man nur die Standard-SQL-DDL verwendet, also nichts DBMS-spezifisches angibt, hängt vom verwendeten DBMS ab und kann natürlich davon abhängen ob es sich um eine „nullable“-Spalte handelt oder nicht und ob die Werte „unique“ sein müssen oder nicht, und welche(n) Typ(en) die indexierten Spalten haben, ob es ein partieller Index ist, und so weiter.
Und wenn man dann zu konkreten DBMS-Produkten kommt, kann man oft ziemlich viel an Indexen herum schrauben. Welche Datenstruktur verwendet werden soll und oft auch noch feinere Einstellungen dazu. Also nicht nur das beispielsweise ein B-Tree verwendet werden soll, sondern auch wie die Blattgrösse ist und ab welchem Füllstand Blätter geteilt werden sollen und/oder unter welchem Füllstand Blätter wieder zusammengefasst werden sollen und ähnliches.
Datenbankspezifisch gibt es eventuell auch Anweisungen um Indexe ”aufzuräumen”. PostgreSQL kennt beispielsweise ein REINDEX. Wobei das so ähnlich ist wie beim optimieren von Code: man sollte erst messen wo die Zeit bleibt bevor man teure Operationen startet die am Ende nur sehr wenig bringen.
Also grundsätzlich: Schau Dir an was Dein verwendetes DBMS an Diagnostikmöglichkeiten bietet und schau wo die meiste Zeit verbraucht wird.
Wenn *ein* Datensatz einfügen spürbar Zeit braucht, dann stimmt IMHO irgendetwas nicht. Das ist sehr ungewöhnlich.
Und wenn man dann zu konkreten DBMS-Produkten kommt, kann man oft ziemlich viel an Indexen herum schrauben. Welche Datenstruktur verwendet werden soll und oft auch noch feinere Einstellungen dazu. Also nicht nur das beispielsweise ein B-Tree verwendet werden soll, sondern auch wie die Blattgrösse ist und ab welchem Füllstand Blätter geteilt werden sollen und/oder unter welchem Füllstand Blätter wieder zusammengefasst werden sollen und ähnliches.
Datenbankspezifisch gibt es eventuell auch Anweisungen um Indexe ”aufzuräumen”. PostgreSQL kennt beispielsweise ein REINDEX. Wobei das so ähnlich ist wie beim optimieren von Code: man sollte erst messen wo die Zeit bleibt bevor man teure Operationen startet die am Ende nur sehr wenig bringen.
Also grundsätzlich: Schau Dir an was Dein verwendetes DBMS an Diagnostikmöglichkeiten bietet und schau wo die meiste Zeit verbraucht wird.
Wenn *ein* Datensatz einfügen spürbar Zeit braucht, dann stimmt IMHO irgendetwas nicht. Das ist sehr ungewöhnlich.
„All religions are the same: religion is basically guilt, with different holidays.” — Cathy Ladman
Von welchem DBMS reden wir hier? Selbst bei indizierten Tabellen mit x*100 Millionen Zeilen habe ich niemals auch nur annähernd eine Sekunde fürs Einfügen gebraucht.naheliegend hat geschrieben: ↑Mittwoch 17. Juni 2020, 20:08 Unter Umständen ja, aber selbst einer ist schon träge
-
- User
- Beiträge: 439
- Registriert: Mittwoch 8. August 2018, 16:42
MySQL, wie viele Indizes hattest du denn?/me hat geschrieben: ↑Mittwoch 17. Juni 2020, 21:42Von welchem DBMS reden wir hier? Selbst bei indizierten Tabellen mit x*100 Millionen Zeilen habe ich niemals auch nur annähernd eine Sekunde fürs Einfügen gebraucht.naheliegend hat geschrieben: ↑Mittwoch 17. Juni 2020, 20:08 Unter Umständen ja, aber selbst einer ist schon träge
__backjack__: "Jemand der VB oder PHP kann, der also was Programmieren angeht irgendwo im negativen Bereich liegt (...)"
Das ist reden um den Quark.
Zeig die entsprechende Struktur der Tabelle und den Code, wie du dort etwas einfügst.
Vorher ist das Rumhumpeln im Dunkeln.
Bei einem "INSERT" von Sekunden zu reden, klingt für mich ausgesprochen ungewöhnlich.
Um das mal ins Verhältnis zu setzen. Auf meinem Laptop (casual, nichts RAM, nichts SSD) braucht ein Insert in eine MariaDB Tabelle (19 Felder, davon 10 Indices) mit mehr als 2 Millionen Datensätzen weniger als 0,02 Sekunden inklusive Commit.
Zeig die entsprechende Struktur der Tabelle und den Code, wie du dort etwas einfügst.
Vorher ist das Rumhumpeln im Dunkeln.
Bei einem "INSERT" von Sekunden zu reden, klingt für mich ausgesprochen ungewöhnlich.
Um das mal ins Verhältnis zu setzen. Auf meinem Laptop (casual, nichts RAM, nichts SSD) braucht ein Insert in eine MariaDB Tabelle (19 Felder, davon 10 Indices) mit mehr als 2 Millionen Datensätzen weniger als 0,02 Sekunden inklusive Commit.
- __blackjack__
- User
- Beiträge: 13117
- Registriert: Samstag 2. Juni 2018, 10:21
- Wohnort: 127.0.0.1
- Kontaktdaten:
Bei MySQL könnte man sich dann Beispielsweise mal für eine problematische SQL-Anweisung den Ablaufplan anzeigen lassen und sich mit dem Performance-Schema beschäftigen und schauen wo die ganze Zeit denn so verbraucht wird.
„All religions are the same: religion is basically guilt, with different holidays.” — Cathy Ladman
-
- User
- Beiträge: 439
- Registriert: Mittwoch 8. August 2018, 16:42
Das Ding ist, dass das nicht meine DB ist. Das kann wahrscheinlich nur der Server-Admin, oder?__blackjack__ hat geschrieben: ↑Donnerstag 18. Juni 2020, 10:17 Bei MySQL könnte man sich dann Beispielsweise mal für eine problematische SQL-Anweisung den Ablaufplan anzeigen lassen und sich mit dem Performance-Schema beschäftigen und schauen wo die ganze Zeit denn so verbraucht wird.
__backjack__: "Jemand der VB oder PHP kann, der also was Programmieren angeht irgendwo im negativen Bereich liegt (...)"