Performance Probleme in SQL

Es gibt 16 Antworten in diesem Thema. Der letzte Beitrag () ist von LucaWelker.

    Performance Probleme in SQL

    Hallo Community,

    ich habe eine SQL-Datenbank, die ca. 10 GB Daten umfasst.

    Jetzt habe ich das Problem, dass die Datenbank bei einer wirklich einfachen SELECT COUNT Abfrage in die Knie geht und die Abfrage auf einen TimeOut läuft.

    Das selbe passiert mir an einer anderen Stelle mit einer Abfrage, welche 3 JOINS beinhaltet. Wobei sich diese mit sicherheit noch optimieren lässt.

    Allerdings macht mir die Select COUNT abfrage mehr Probleme.

    Hat vielleicht irgendjemand eine Idee dazu?

    lg.

    LucaWelker
    lg.

    LucaWelker

    Ich brauche leider eine genau Anzahl.

    Es ist im Moment eine "SELECT COUNT(*) " Abfrage mit einer einfachen WHERE Clause, wo ein Feld auf einen Wert abgefragt wird.

    Ich werde jetzt versuchen mal den Stern mit einem Spaltennamen zu ersetzten. Ich denke dass könnte schon noch einige Vorteile bringen.
    lg.

    LucaWelker

    Du meinst deine Datenbank besteht aus wenigen Tabellen und hat 10 GB an Daten?
    Variante -- schnellerer Rechner --> Variante b -> Teil deine Datenbank in Kategorien auf und versuch die Datenbank aufzuteilen.
    (bei nem Duden könnte man beispielsweise alle Wörter in eine Tabelle schreiben oder alle Wörter mit Anfangsbuchstaben "a" in eigene Tabelle) ->evtl auch nach Abfragekatgorien aufteilen.


    Ansonsten poste mal deinen Quelltext wo du die Abfrage machst :) - evtl bremst auch die Darstellung deine Abfrage

    Also hab ich vielleicht vergessen dazu zu sagen :D

    Die Datenbank liegt auf einem Server welcher bei 1und1 steht.
    Intel Core i7 (6 Kerne); 16 GB ram. An der Leistung des Rechners darf bzw. sollte es definitiv nicht liegen.

    Die Datenbank besteht aus 17 Tabellen. Das letzte Backup von heute Morgen hat genau 9,86 GB.
    Ansonsten würde ich behaupten die Datenbank ist Modellierungsmäßig "perfekt" (in wie fern etwas perfekt sein kann.. Ich weiß man kann immer etwas besser machen). Die Datenbank wurde auch nicht von mir modelliert sondern von einem Kollegen mit der Informatik mit ich sag jetzt mal "Schwerpunkt" Datenbanken studiert hat. Daran sollte es ebenfalls nicht liegen.


    Vielleicht noch zur Info. Die Datenbank wird über das Spring.NET Framework abgefragt, wobei auch hier m.M.n. keine Geschwindigkeit verloren geht, da die Statements auch direkt im SQL-Managementstudio so langsam sind.

    @bastimw: Was meinst du mit "Darstellung der Abfrage?"

    lg.
    lg.

    LucaWelker

    LucaWelker schrieb:

    Es ist im Moment eine "SELECT COUNT(*) " Abfrage

    SQL-Abfrage

    1. SELECT COUNT(1) AS `count` FROM `tabelle` WHERE ...

    Man beachte die 1.

    Alternativ:

    SQL-Abfrage

    1. SELECT 1 FROM `tabelle` WHERE ...

    Danach eine MySQL-API-Funktion á la mysql_num_rows.

    Alternative 2:

    SQL-Abfrage

    1. SELECT 1 FROM `tabelle` WHERE ...; SELECT FOUND_ROWS() AS `count`


    Dabei sollte eine Datenbank definitiv nicht in die Knie gehen, besonders nicht bei nur 10GB an Daten.
    Deutet auf die falsche Verwendung von Indizes hin.
    Ohne mehr Informationen können wir dir nicht helfen.
    Möglicherweise ist dein SQL-Server auch falsch konfiguriert, beispielsweise dass er nur 100MB im RAM hält oder so etwas.

    Kommen die 10GB zu Stande, weil du BLOB-Spalten verwendest? Oder sind es wirklich reine, strukturelle Informationen?
    To make foobar2000 a real random music player, I figured out the only way to achieve this is to use Windows Media Player.

    “At some point in time, you recognize that knowing more does not necessarily make you more happy.”

    Hey Leute,

    sorry dass ich mich erst jetzt zu Worte melde, aber ich war das ganze Wochenende Arbeiten und bin einfach nicht früher dazu gekommen.

    Erstmal danke für eure Mühen.
    Ich hab mal wieder gemerkt dass ich es scheinbar total vergessen hab die wichtigen Infos raus zu lassen.

    Es handelt sich beim Datenbanksystem um MS-SQL.
    Die 10 GB sind keine reinen Informationen, es sind auch "Dateien" darin enthalten.

    Das COUNT-Statement habe ich schon optimiert bekommen, logischerweiße einfach den "*" durch den Spaltennamen der GUID ausgetauscht.

    Wegen den Indizes bin ich mir nicht so sicher. Hab die am Samstag nochmal kontrolliert und eigentlich sind m.M.n. alle Indizes richtig gesetzt. Wie gesagt der jenige der die Datenbank modelliert hat, hat den Spaß studiert(ich weiß, dass hat nicht zwingend was zu heißen).

    Ich werde jetzt versuchen das Statement mit den 3 Joins auf drei Statements auf zu teilen und dann via DataSet zusammen zu joinen. Die DataSets sind was das angeht tatsächlich schneller als der SQL-Server.

    lg.
    lg.

    LucaWelker

    Ich glaube es geht eher darum, dass du die entsprechenden Indizes in die Abfrage integrierst.
    Wenn bei einer Abfrage eine indizierte Spalte herangezogen wird, sucht das DBMS anhand der Zeiger (aus denen so nen Index besteht), was wesentlich schneller geht.
    Es war einmal ein kleiner Bär... der wollte eine Geschichte hörn... Da erzählte ihm seine Mutti:
    Es war einmal ein kleiner Bär... der wollte eine Geschichte hörn... Da erzählte ihm seine Mutti:
    Es war einmal ein kleiner Bär... der wollte eine Geschichte hörn... Da erzählte ihm seine Mutti:
    ... Nun solltest es selber wissen. :'D

    LucaWelker schrieb:

    Die 10 GB sind keine reinen Informationen, es sind auch "Dateien" darin enthalten.
    Das könnte das Problem sein. Datenbanken unterstützen zwar BLOBs, aber das heißt nicht, dass es auch gut ist, sowas zu benutzen. Statt diesem Layout

    Quellcode

    1. ID | FileName | FileContent
    ist dieses sehr viel besser, weil es die DB nicht sinnlos belastet:

    Quellcode

    1. ID | FileName | FilePath
    3. + Verzeichnisbaum, in dem die Dateien liegen.
    Wenn du schon sagst, dass COUNT(spalte) schneller ist als COUNT(*), dann ist das ein sicheres Indiz dafür, dass riesige BLOBs die Auswertung ausbremsen. Für ein COUNT(*) braucht die DB nämlich einen Full Table Access, wenn man (wie oben schon angedeutet) keinen passenden Index hat. Damit muss er schon zum Zählen die ganze Tabelle durchackern --> bei BLOBs ist das ineffizient, weil sie keinerlei (für die DB) nützliche Informationen enthalten.
    Gruß
    hal2000

    Hallo hal2000,

    ja ich vermute mittlerweile auch dass die BLOBs das Problem sind.
    Leider ist der Kollege der die Idee hatte die Daten in der DB abzulegen nicht mehr im Unternehen, so dass ich ihn leider nicht mehr fragen kann wieso er diesen Weg gewählt hat.

    Ich hab dass ganze nun über den von mir oben schon beschriebenen Weg im Code gemacht.
    Hab das eine Statement in 2 Statements geteilt getrennt abgefragt und im Code mit hilfe des Datasets gejoint.

    Das ganze hat nun noch eine Laufzeit von ca einer(!!) Sekunde.

    Folglich ist für mich das Problem jetzt vor erst mal gelöst.
    Auch wenn ich mal versuche raus zu finden aus welchem Grund die BLOBs in der DB gespeichert werden.


    EDIT: Danke nochmal an alle die geholfen haben! :)
    lg.

    LucaWelker

    Hallo,

    bitte unbedingt ansehen: msdn.microsoft.com/library/hh461480

    Du kannst von einem Auto, welches du mit 3 Tonnen belädst eben nicht erwarten, dass es noch seine normale Geschwindigkeit erreicht.
    Es sei denn du hast einen Haummer. Aber ich denke nicht, dass du Zugriff auf Quantencomputer hast?!

    Gruß
    To make foobar2000 a real random music player, I figured out the only way to achieve this is to use Windows Media Player.

    “At some point in time, you recognize that knowing more does not necessarily make you more happy.”

    LucaWelker schrieb:

    Auch wenn ich mal versuche raus zu finden aus welchem Grund die BLOBs in der DB gespeichert werden.
    Vermutlich weil man das im Studium (hier zumindest) so lernt.

    Chrisber schrieb:

    Du kannst von einem Auto, welches du mit 3 Tonnen belädst eben nicht erwarten, dass es noch seine normale Geschwindigkeit erreicht.
    Der Vergleich hinkt, Datenbanken sind dafür da Daten zu verwalten und, zumindest was Oracle betrifft, tun sie das auch schneller als wenn man den Umweg übers Dateisystem nimmt, siehe z.B. SecureFiles Performance.
    Ich würde eher darauf tippen das jmd. die Serverkonfiguration überprüfen müsste.

    Chrisber schrieb:

    bitte unbedingt ansehen: msdn.microsoft.com/library/hh461480

    Werde mir das Dokument später einmal ansehen. Im Moment komm ich leider nicht dazu, danke aber schonmal für den Hinweiß.

    gs93 schrieb:

    Ich würde eher darauf tippen das jmd. die Serverkonfiguration überprüfen müsste.

    Was denkst du denn genau, dass es an der Konfig geprüft werden müsste?
    Hab mal heute morgen nochmal geschaut wie viele Daten gecacht werden => 4 GB. Das sollte doch eigentlich reichen oder?

    lg.
    lg.

    LucaWelker

    Cache alleine ist eine schwammige Aussage (bei Oracle) gibts da allein schon mal data dictionary cache, data buffer cache und log buffer cache. Dann gibts noch Sachen wie Sperrgranularität, kein Index für kleine Tabelle, Mehr-Attribut-Index, Cluster für oft zusammen genutzte Tabellen, Größe des Tablespace und noch viel mehr Zeugs wo man rumoptimieren kann. Ich kenn mich da aber auch nur theoretisch aus (und das Thema wurde auch nur kurz behandelt), sowas kann man im Studium auch schwer praktisch üben^^ Aber wie gesagt: hier meinte der Prof auch das man heutzutage alles in der Datenbank speichert, die sind schließlich dafür ausgelegt (Oracle entwickelt ja z.B. auch btrfs, kennt sich in dem Gebiet also auch aus). Wenn ihr einen Datenbankadministrator habt würd ich lieber mal den fragen.

    Hey gs93,

    okay ja.. das übersteigt dann jetzt auch meinen horizont.. :D

    Ich werde glaub ich wirklich mal bei unseren Netzwerkadmins nachfragen ob die Ahnung davon haben.

    Vielen Dank für eure mühe! :)
    lg.

    LucaWelker

Facebook
Telefonspende