Optymalizacja bazy danych poprzez migrację na inny silnik

[Ralliart]

Tworząc narzędzia z których korzysta wiele osób nie raz przyjdzie wam stanąć przed dylematem optymalizacji wykonywania zapytań służących do wykonywania zadania. Samo wybranie silnika bazy danych może mieć kluczowe znaczenie dla sposobu w jaki proces będzie przebiegał i jak długo będzie trwał. W tym wypadku przedstawię założenia projektu, jego funkcjonowanie oraz działania optymalizujące.

1. Założenia:

Wyliczenie aktualnej marży w różnych ujęciach (na artykuły, działy, total, itd.) dla całego sklepu na podstawie pliku zawierającego dane o paragonach fiskalnych w formacie txt przy wykorzystaniu tabel bazy danych DB2 do wczytania danych nie występujących w pliku txt.

2. Realizacja:

a)Baza danych MS Access jako podstawa działań

Przebieg procesu:

Komputer A kopiuje pliki na dysk sieciowy

Komputer B (maszyna wirtualna) Uruchamia makro klawiaturowe które wywołuje obliczenia w Accsesie

- pliki tekstowe jako tabele połączone

- Tabele z DB2 jako tabele połączone

- Operacje wykonywane na widokach (20 kroków)

- Czas wykonania od 3 do 10 minut (tylko obliczenia)

Komputer B kopiuje plik .mdb do lokalizacji sieciowej

Problemy:

• Komputery nie korzystają z serwera czasu - brak synchronizacji działań
• Access nie wykonuje zadania w terminie (8 minut ustawione w skrypcie klawiaturowym)
• Dyski sieciowe często się rozłączają
• Tabela z DB2 traci połączenie po restarcie
• Po restarcie maszyny wymagane odtworzenie połączeń sieciowych i wpisanie hasła dla DB2
• Wolne odświeżanie w Excelu
• Częste błędy w Excelu z winy użytkowników
• Problem z połączeniem do DB2 w Excelu

Generalnie zero plusów - po dłuższym użytkowaniu wyszły na jaw wszystkie słabe punkty rozwiązania, a im dalej w las tym gorzej. Access niestety nie podołał, a z racji konieczności kopiowania całego pliku .mdb nie można było zaimportować tabel z DB2 (w sumie dałyby 500MB). Dużym problemem okazał się też brak synchronizacji z serwerem czasu, przez co często serwer A nie był w stanie skopiować pliku, bo serwer B już go używał i tym samym nie mógł być zaktualizowany. Access pokazał swoje zalety jedynie w momencie projektowania aplikacji - jego kreator wizualny potrafi wiele i kreowanie nowych tabel szło szybko.

Access:

Jedna z kwerend (kreator wizualny)

To samo w SQL

b)MySQL:

Przebieg procesu:

-Serwer A kopiuje plik TXT

-Serwer A uruchamia procedurę w MSSQL która pobiera dane do bazy po czym przesyła je do MySQL, a następnie wywołuje procedurę obliczającą marżę i sam ściąga je z powrotem.

-Wszystkie tabele DB2 są zaimportowane do baz zarówno w MSSQL jak i MySQL

- Operacje tylko i wyłącznie na indeksowanych tabelach

- Czas wykonania całości procesu max 3 minuty (Z czego obliczenia 5-20 sekund!)

Problemy:

• Brak sterownika obdc dla MySQL na serwerze terminalowym zmusza do używania serwera MSSQL
• Brak skryptu który sam wrzucałby rekordy do MySQL
• Długi przesył rekordów z MSSQL do MySQL

Jak widać problemów brak, poza tak naprawdę drobiazgami które nie mają kompletnie żadnego wpływu na działanie samego zadania. Cały proces nadzoruje jeden komputer, także nawet w przypadku braku synchronizacji z serwerem czasu i tak wszystko wykona się poprawnie. Wykorzystanie MSSQL i MySQL likwiduje problem połączeń - nie ma żadnego problemu z udziałami sieciowymi i wynikającymi z tego powodu komplikacjami. Excel został odpowiednio przygotowany, a hasła w Arkuszach do modyfikacji skutecznie wyeliminowały błędy po stronie tej aplikacji. Problemem dla mnie jest (jeszcze) tempo przesyłania danych pomiędzy MSSQL a MySQL, ale wkrótce to się zmieni.

Widok jobu MSSQL: