Performance: viele Einzelabfragen vs. eine Abfrage mit vielen Filtern

[kwakz]

Hallo zusammen,

ich habe folgende Aufgabenstellung: Von unseren Produktionsanlagen werden Messdaten, Statusmeldungen und so weiter in einer SQL-Datenbank abgelegt. Jetzt möchte ich gern per LabVIEW eine Auswertesoftware schreiben, die auf die Datenbank zugreift und mir ein paar Diagramme zaubert.

Leider ist es jetzt so, dass die Datenbank Performance-seitig schon ziemlich am Limit ist. Daran können wir leider nix ändern, weil das Ganze auf einen etwas unüberlegten Aufbau seitens des Anlagenherstellers zurückzuführen ist. Ich möchte nun mit meiner Auswertung die Datenbank so wenig wie möglich belasten. Daraus ergeben sich jetzt zwei Möglichkeiten:
1. Ich kann mit relativ einfachen Anfragen die notwendigen Rohdaten auslesen und dann innerhalb meines LabVIEW-Programms die benötigten Informationen daraus ziehen und kombinieren.
2. Ich kann eine einzelne Anfrage mit entsprechend vielen Filtern an die Datenbank schicken und mir meine benötigten Nutzdaten von der Datenbank kombinieren lassen.

Jetzt ist die Frage: Was beansprucht die Datenbank mehr? Die Bereitstellung einer großen Datenmenge oder die Verarbeitung von mehreren Filtern?

Mfg Daniel

 

[ukulele]

Bei der Bereitstellung der Rohdaten wird in jedem Fall das Netzwerk stärker beansprucht, was meist der Flaschenhals bei großen Datenmengen ist. Man könnte die Abfragen aber mal lokal laufen lassen und sich Dauer und Auslastung angucken, die ja immer mit angegeben wird. Prinzipiell tippe ich, das eine Abfrage die Daten aggregiert aber nicht zu viele Datensätze joinen muss immer schneller sein wird.

MS SQL hat den Query Execution Plan der vergleichbar ist mit EXPLAIN. Ich habe damit noch nicht viel gearbeitet aber der sollte dir bei der Performance Optimierung dienlich sein. http://stackoverflow.com/questions/7359702/how-do-i-obtain-a-query-execution-plan

 

[Fumus]

Hallo Daniel,

MS SQL Server verfolgt folgenden Workflow, wenn du einen Query absetzt: FROM->JOINS->WHERE->GROUP BY->HAVING->SELECT->ORDER BY ----> Ausgabe. Insofern tust du dir immer einen guten Gefallen, wenn du mit where vorab den SQL Server entlastest. Bei Inner Joins spielt es keine Rolle, ob du Filter im Inner join oder im Where zusammenbastelst. Der Ausführungsplan (Execution Plan) wird dir das sagen. Besser wäre noch mit SET Statistics On und Set Statistics time ON deine Abfrage mal zu testen. Ziel: Weniger CPU weniger Seiten!
Und auch kein Select * verwenden ;-)

Nun zu deiner Entscheidung. Lieber eine große statt vieler kleiner Abfragen? Das kommt drauf an. Du kannst das messen. Einmal mit Execution Plan oder auch mit SET STATISTICS. Du musst halt ein wenig die Werte addieren. Im SELECT des Plans findest du die Kosten. Die kannst du sehr gut vergleichen. Bei den Statistiken ebenfalls...
Was man noch beachten müsste wäre theoretisch das Auftreten von Sperren, aber zu kompliziert wollen wir das mal nicht machen.

Anderer Ansatz: http://blog.fumus.de/sql-server/201...-systemmonitor-wichtige-leistungsindikatoren/


Da dein SQL Server schon ein wenig lahmt (CPU, RAM, HDD?), versuch mit Prozeduren zu arbeiten, die nicht allzu benutzerfreundlich (mal Abfrage nach * , mal nach einer eindeutigen ID) sind. Dann hast du den Vorteil deinen Plan Cache entlasten zu können und profitierst davon in Sachen Speicher und Vermeidung von Rekompilierungen. So mal als Gedankenansatz..

Liebe Grüße

Fumus