[MSSQL] równoległe przetwarzanie danych

Cześć, w mojej aplikacji pewne obliczenia wykonują się dość długo. Obliczenia te zależą od przekazanego zakresu dat. I wpadłem na pomysł, że, żeby zwiększyć prędkość wystarczy obliczenia te rozbić na kilka wątków.

Chodzi o to, że zamiast wywołać procedurę składowaną dla całego zakresu, np:
ProcessData '2010-01-01', '2010-12-31'

mogę wywołać tą procedurę w dwóch osobnych wątkach z ograniczonymi zakresami, czyli:
wątek 1: ProcessData '2010-01-01', '2010-05-31'
wątek 2: ProcessData '2010-06-01', '2010-12-31'

Oczywiście przekazując też ID wątku, bo jest mi to potrzebne.

Załóżmy w uproszczeniu, że procedura ProcessData wypełnia mi tabelę TAB pewnymi danymi. Najpierw zbiera te dane i odpowiednio je przelicza, a na końcu dodaje rekord do tabeli TAB. Wszystko dzieje się w kursorze.

Zrobiłem sobie prosty test z użyciem SQL Server Management Studio (wersja sql: SQL 2005 Express)
Tzn. na jednej karcie odpaliłem jedną procedurę, na drugiej drugą. I okazało się, że czas wykonania osiągnął 40 sekund, czyli jakieś 2 razy więcej niż normalnie.

I teraz pytania:

• czy taki test jest miarodajny, czy gdzieś dałem tyłka?
• czy muszą być spełnione jakieś specyficzne warunki, żeby mój pomysł miał rację bytu?

Okazuje się, że tabela TAB jest wypełniona mieszanymi danymi(tzn. w kolejności dane były zapisywane: trochę z jednego wywołania, trochę z drugiego). Tego się spodziewałem, jednak moim zdaniem ten stopień "pomieszania" jest trochę mały w porównaniu do ilości danych.

Spróbuję jeszcze zrobić tak, żeby każde wywołanie insertowało dane do tylko swojej tabeli, a potem unię z nich.

SQL Express nie wspiera chyba wielowatkowosci. Czytaj: to, ze Ty odpalisz procedury wielowatkowo nie znaczy, ze serwer je tak przetworzy.

wersja express ogranicza sie do uzycia tylko jednego rdzenia procesora
skup sie raczej nad optymalizacja query, obstawiam ze da sie obejsc bez kursorow
kursory pod ms sql server to masakra i jesli nie jest to na prawde konieczne nie powinno sie ich uzywac, szczegolnie jesli zalezy nam na predkosci
raczej zadaj pytania, ktore pomoga poprawic ci wydajnosc query (raczej potrzebujemy kody query zeby cos sensownego doradzic, mozesz pozmienic i wyciac pewne biznesowe "tajne" elementy)

Jakbym pokazał ten kod, musiałbym Was zabić :D
Nie, a tak serio, to tego jest dość sporo i branych jest pod uwagę wiele aspektów. Chodzi o czas liczenia pracy.

Wg mnie nie da się obejść bez kursora, zresztą robiłem testy i okazuje się, że wcale nie on wykonuje najdłuższą operację.

Najdłuższa operacja to select z funkcji tabelarycznej(która jest wielokrotnie zagnieżdżonym selectem) i usuwanie z innego selecta.

no to moze warto zastanowic sie nad optymalizacja tej funkcji, lub w ogole eliminacja funkcji na rzecz podzapytan i/lub zmiennych tablicowych, ktore tymczasowo jakis zbior danych przetrzymaja, wielkokrotnie uzywany pozniej do jakiegos filtorwania, zlaczen, podzapytan

No warto by było, ale to są dość skomplikowane obliczenia i najlepiej byłoby wdrożyć w tą część kodu kogoś, kto się na SQLu NAPRAWDĘ zna ;)

Z fusow nie wywrozymy ;) Albo zamiescisz albo kogos wynajmiesz do tego. Wydaje mi sie, ze juz ten temat pare razy u Ciebie walkowalismy.

johny_bravo napisał(a)

Z fusow nie wywrozymy ;) Albo zamiescisz albo kogos wynajmiesz do tego. Wydaje mi sie, ze juz ten temat pare razy u Ciebie walkowalismy.

Zgadza się. Jednak zamieszczenie tego kodu nie ma sensu, bo to jest kilka tabel, kilka procedur, kilka funkcji, tak więc generalnie nikt by się w tym nie pokapił ;)

Zmieniłem trochę sposób przeliczania danych. Praktycznie rzecz biorąc jest dużo szybciej, ale faktycznie wygląda to tak jak z zaginaniem czasoprzestrzeni. Statek kosmiczny ma tą samą prędkość, a w punkcie końcowym jest dużo szybciej :P

Dla każdego wątku utwórz osobne komponenty bazodanowe i zobacz czy to pomogło.

@rasert: Nie przeczytales poprzednich odpowiedzi. SQL Express i tak przetworzy to na 1 rdzeniu. Wiecej watkow nie przyspieszy pracy w takim wypadku.

Zawsze można zmienić bazę danych na obsługującą wiele rdzeni. Poza tym, jeśli już używa kilku wątków z tymi samymi komponentami bazodanowymi, to będzie miał stale błędy systemowe typu "access violation".

rasert napisał(a)

Zawsze można zmienić bazę danych na obsługującą wiele rdzeni.

Czy ja dobrze rozumiem, że chcesz kupić koledze pełną wersję? :)

rasert napisał(a)

Poza tym, jeśli już używa kilku wątków z tymi samymi komponentami bazodanowymi, to będzie miał stale błędy systemowe typu "access violation".

Eeee, a mechanizm lockow?

johny_bravo napisał(a)

rasert napisał(a)

Poza tym, jeśli już używa kilku wątków z tymi samymi komponentami bazodanowymi, to będzie miał stale błędy systemowe typu "access violation".

Eeee, a mechanizm lockow?

Nic nie pomoże. Po prostu te wszystkie komponenty DBExpress i inne nie wspierają wielowątkowości.

@up: Ale o czy Ty mowisz? Jaki DBExpress? Autor pisal tylko o SQL Express i o zadnym dostepie do bazy nie wspominal.

johny_bravo napisał(a)

@up: Ale o czy Ty mowisz? Jaki DBExpress? Autor pisal tylko o SQL Express i o zadnym dostepie do bazy nie wspominal.

Jakoś musi się przecież dostać do bazy przez biblioteki kompilatora.

Biblioteki kompilatora? Do bazy? WTF?
I czemu musi, skoro nic o tym nie wspomina?

@rasert: Zdajesz sobie sprawe, ze biblioteki Borlanda nie sa jedynymi na swiecie bibliotekami do obslugi baz danych?

Łączę się za pomocą ADO, żeby była jasność ;>
Natomiast no ta wielowątkowość odpada i to już ustaliliśmy :P

To ADO obsługuje wielowątkowość?

Co ma biblioteka do tego? Jak sobie odpalisz rownoczesnie 2 zapytania to biblioteka musiala by byc mocno zwalona, zeby na to nie pozwolic. Raczej chodzi o to, czy serwer potrafi je "naraz" przetworzyc lub czy sterownik potrafi obslugiwac rozne konteksty. Przykladowo w ODBC do sql nie mozna na tym samym polaczeniu wywolac dwoch jednoczesnych sekwencji funkcji, ale na osobnych juz nie ma problemu.