MSSQL/ADO ... speed is everything !!!

[bernhard_LA]

ich experimentiere gerade an der Optimierung von SQL-Queries herum.
Die Aufgabenstellung ist wie folgt :


a) gegeben sind xx Millionen Records in einer MSSQL Datenbank , xx= 1 ... 100 ;
b) jeder einzelne Datensatz muss vom Server geholt werden und in einer Funktion PROC(aDataset) verarbeitet werden.
c) gemessen wird die Verarbeitungszeit aller Daten.


Ich habe eine Abhängigkeit der verarbeiteten Datensätze / Sekunde von der Größe des angeforderten Datenpaketgröße festgestellt.

Bei kleinen Paketen ist der Kommunikations-Overhead DB/Anwendung die Bremse, bei Großen Query-Ergebnissen geht der Zugriff auf einzelne Rekords nicht mehr linear in der Zeit.

Sind meine Beobachtungen und Erklärungen richtig?

[Dejan Vu]

Nein. Die Geschwindigkeit ist von vielen Faktoren abhängig, die im Provider und auch im Server eingestellt werden können.

In deinem Fall ist es aber eher so, das not Speed everything ist, but the Speicherverbrauch also into Consideration getaked werden muss. What brings it you when you theoretically very fast deine Daten fetchen kannst, aber die not in the Speicher ryne bekommst.

Die Lösung lautet: 'Overlapped': Wenn Du overlapped arbeitest, kannst Du sowohl Server als auch Client optimal ausnutzen. Overlapped bedeutet hier: Während ein Thread (oder mehrere) den nächsten Block von Daten liest, kann der andere (die anderen) Thread(s) die Daten bereits verarbeiten.

Deine Verarbeitungsgeschwindigkeit ist also nicht: Ladezeit + Verarbeitungszeit, sondern eher: Max(Ladezeit, Verarbeitungszeit)+Kleiner Overhead.

Und *dann* kannst Du an der Pagegröße herumdrehen, der Anzahl der Threads etc. Aber das Wichtigste: Dein Speicher wird nie überlaufen, deine Anwendung ist auch bei 100 Mrd Datensätzen stabil und schnell etc. Und Du kannst die Parameter so drehen, das der Server nicht übermäßig belastet wird etc.

Wenn dieses Tool jedoch öfter eingesetzt wird, würde ich mir überlegen, die Daten schon vorher zu verarbeiten/verdichten. Eventuell 1x täglich, alle Stunde, Minute, in Echtzeit etc.

[mkinzler]

Zudem wäre zu Überlegen, ob man PROC als SP oder UDF auf den Server verlagern kann.

[Sir Rufo]

Oder man benutzt Message Queuing und kann dann mit beliebig vielen Rechnern auf den Datensätzen rumknuspern ohne den Datenserver damit zu behelligen.

[Dejan Vu]

Zitat:

Zitat von mkinzler (Beitrag 1262670)

Zudem wäre zu Überlegen, ob man PROC als SP oder UDF auf den Server verlagern kann.

Oder als .NET-DLL, was der Performance zuträglich wäre. Allerdings ist das nur in Verbindung mit einem ETL-Prozess sinnvoll, d.h. eine kontinuierliche Verarbeitung.

Die Datenmenge ist zwar noch nicht sonderlich hoch, aber vermutlich wäre das auch etwas für BigData, zumindest, um sich damit mal zu beschäftigen.

[mkinzler]

Zitat:

Oder als .NET-DLL, was der Performance zuträglich wäre.

Was ja nur eine Implementationsform einer SP wäre

[Dejan Vu]

Zitat:

Zitat von mkinzler (Beitrag 1262674)

Zitat:

Oder als .NET-DLL, was der Performance zuträglich wäre.

Was ja nur eine Implementationsform einer SP wäre

Eine Stored Procedure ist in SQL geschrieben (und hat limitierte Möglichkeiten zur Auswertung). Eine .NET-DLL nicht. Also ist es nicht 'nur eine Implementationsform einer SP', sondern viel viel mehr.

[bernhard_LA]

Mein Pseudocode geht wie folgt :

Delphi-Quellcode:

    procedure complete_Process(...);     

           mytimer := 0;   ///  hier beginnt  die Zeitmessung

           someInit ();

           MakeSQLStr();

           query.sql.add();
           query.open;

           myTimer.result(1)    //  hier messe ich die Zeit bis zum laden der Daten in die Query

           query.first;
           for i := 0  to maxrecords  do
                begin   
                proc (query, ......);
                query.next;
                end;
           ....
            myTimer.result(2);    //  hier ist die Zeitmessung wie im Graphen ganz oben gezeigt

           finalize



          
           end;

die Zeit an Messpunkt1 ist gegenüber Messpunkt 2 zu vernachlässigen

[Sir Rufo]

@bernhard_LA

Und der Ansatz ist eben von der Performance her schlecht.

Code:

Daten lesen ---> Queue -+-> Verarbeitungs-Thread 1 -+-> Queue ---> Daten schreiben
                        +-> Verarbeitungs-Thread 2 -+
                        :                            :
                        +-> Verarbeitungs-Thread n -+

Bei der Implementierung ist natürlich darauf zu achten, dass man den Queues eine Maximal-Größe mitgibt, die nicht überschritten werden darf.

[Dejan Vu]

Hier ist der Aufwand (LadeZeit + VerarbeitungsZeit/AnzahlDerThreads). Überlappe LadeZeit und Verarbeitungszeit, dann bist Du bei der optimalen Lösung. Siehe auch Post #2 ( die jetzt nicht unbedingt optimal ist).

Ich würde hierfür einen Workerthreadpool einsetzen und die parallelen Ladejobs von der Serverkonfiguration (output-pipes) abhängig machen.


Jeder der L Lade-Thread lädt N Datensätze und überführt sie in Queue.
Jeder der V Verarbeitungs-Thread nimmt sich 1-M Datensätze und verarbeitet sie.

Der Ladethread wartet, wenn die Queue 'zu voll' ist, d.h. mehr als Q Einträge hat und fängt an, wenn die Queue weniger als P Einträge hat (P<Q).

Nun hat man 6 Stellschrauben (L,V, N,M,P und Q) mit denen sich trefflich optimieren lässt.
Vermutlich ist V die Anzahl der Cores und L die Anzahl der Outputpipes des SQL-Servers (4 waren das, glaube ich).

Je nachdem, wie der Server bzw. die Datenbank konfiguriert ist (Stichwort: Partioning) sind parallele Ladethreads auch überflüssig, weil der Server das eh parallelisiert. Bei 100 Mio DS kann man schon über Tablepartitioning nachdenken.