pobierz plik referatu

Transkrypt

pobierz plik referatu - BDAS

Rozdział monografii: 'Bazy Danych: Nowe Technologie', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2007
Rozdział 37
w
Zastosowanie metody pomiaru czasu realizacji
zapytań w analizie systemu zarządzania danymi
w
1 Wstęp
da
.b
w
Streszczenie. Wyniki testów wydajności stanowią istotną wskazówkę w procesie doboru systemu zarządzania danymi w trakcie projektowania systemu
informatycznego. Porównując ze sobą wybrane systemy zarządzania danymi
napotkamy szereg problemów metodologicznych, technicznych oraz prawnych. Autorzy pracy rozwijają własny system pomiarowy mając na celu analizę przypadku intensywnego i zmasowanego napływu zapytań i danych do
systemu zarządzania danymi dla różnych typów baz danych.
pl
s.
Wyniki badań eksperymentalnych stanowią istotną wskazówkę w procesie porównywania
wydajności baz danych oraz ich doboru w realizacji konkretnego zadania. Analizując dostępne w literaturze rozwiązania można zauważyć, że oprócz problemów z doborem modelu badawczego, opracowaniem metodyki testów oraz identyfikacją czynników wpływających na dokładność pomiaru, pojawiają się również bariery prawne stawiane przez producentów oprogramowania. Dlatego odnalezienie i powtórzenie wyników prezentowanych
w literaturze oraz publikacjach elektronicznych jest znacząco utrudnione.
Autorzy pracy mając na uwadze powyższe problemy prowadzą prace nad narzędziem roboczo nazwanym w dalszej części pracy jako „System Pomiarowy”. Jednym z celów tych
prac jest określenie i porówanie efektywności wybranych systemów baz danych w wybranych zastosowaniach. Badania skupiają się głównie na analizie przypadków intensywnego
i zmasowanego napływu zapytań i danych. Kolejnym celem jest ustalenie faktu czy stworzony System Pomiarowy i przyjęta metodyka prowadzenia pomiaru jest w stanie dostarczyć przesłanek nt. zasad konstrukcji systemu bez koniecznej analizy kodów źródłowych
systemu zarządzania danymi.
Michał Widera Mentor Graphics
Chorzowska 50, 40-121 Katowice Polska
email: [email protected]
Adam Domański, Piotr Delijewski
Politechnika Śląska, Instytut Informatyki, ul. Akademicka 16, 44-100 Gliwice Polska
email: [email protected], [email protected]
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2007
M. Widera, A. Domański, P. Delijewski
2 Metody pomiaru wydajności baz danych
w
Obecnie prowadzonych jest kilka projektów [1], [2], [3], [8], [9] mających na celu opracowanie testów porównawczych dla systemów zarządzania danymi. Najpopularniejszym
i najczęściej przytaczanym w literaturze jest zestaw testów TPC.
Poniżej przedstawiono przegląd opisanych w literaturze systemów porównywania wydajności baz danych. Należy podkreślić, że za wyjątkiem projektów z rodziny wolnego i otwartego oprogramowania, nie opublikowano żadnych kodów źródłowych. Dla większości
nie opublikowano również szczegółów zastosowanej w procesie testowania metodologii.
Natomiast dla projektów, których metodologia badań została przedstawiona, nie ujawniono
wyników badań.
w
2.1 Transaction Processing Performance Council
pl
s.
da
.b
w
Organizacja ta zajmuje się m.in. rozwojem testów [2], [3]: TPC-App, TPC-C, TPC-H
i TCP-W. Każdy z nich jest przeznaczony do pomiaru wydajności innego typu systemu informatycznego. Głównym celem prowadzonych prac w ramach tego projektu jest zdefiniowanie zestawu funkcjonalnych wymagań, które mają zastosowanie w każdym systemie
transakcyjnym, niezależnie od sprzętu czy systemu operacyjnego.
− TPC-App – jest testem symulującym działanie transakcyjnego serwera aplikacyjnego
oraz jego usług sieciowych (test powstał pod koniec 1989 roku).
− TPC-C – powstał w 1992 roku jako następca testu TPC-A. Test przeznaczony do pomiaru wydajności (m.in. współczynnika cena/wydajność) systemów transakcyjnych
typu OLTP (ang. On-Line Transaction Processing). TPC-C dotyczy połączenia pięciu współbieżnych transakcji o różnym typie i złożoności, wykonywanych na bieżąco
albo przeznaczonych do późniejszego wykonania.
− TPC-H – jest testem [2] systemu wspomagania decyzji, składającym się z kompletu
tzw. zapytań ad-hoc (zadawanych na bieżąco w trakcie realizacji innych algorytmów)
i równoległych modyfikacji danych. Zapytania i ilość danych w bazie danych zostały
tak dobrane, aby miały związek z szeroko pojętym zastosowaniem w przemyśle.
− TPC-W – znajduje zastosowanie przy pomiarze wydajności sieciowych systemów
transakcyjnych. Przyjętą metryką wydajności jest liczba przetworzonych sieciowych
interakcji na sekundę. Kilka sieciowych interakcji jest użytych w celu symulowania
aktywności sklepu detalicznego, a każda z nich podlega rygorom czasowym ze
względu na czas odpowiedzi.
2.2 Open Source Development Labs Database Test Suite
OSDL jest organizacją wspierającą rozwój społeczności związanej z Linuxem. Jednym
z produktów dostarczanych przez OSDL jest zbiór testów [5] na wzór testów TPC. Oznaczane są one DBT-1, DBT-2, DBT-3, DBT-4 i odpowiadają one kolejnym testom TPC.
Umieszczona nota prawna uniemożliwia zastosowanie wyników tych testów dla celów komercyjnych.
382
Zastosowanie metody pomiaru czasu realizacji zapytań w analizie systemu zarządzania danymi
2.3 Open Source Database Benchmark
w
OSDB Powstał z mniejszego projektu w Compaq Computer Corporation w celu oszacowania przepustowości i ogólnej mocy przetwarzania systemu GNU Linux/Alpha. Zbudowany
jest na bazie AS3AP (ANSI SQL Standard Scalable and Portable), czyli testu systemu przeznaczonego dla relacyjnych systemów baz danych, stworzonego przez D. Bitton’a i C. Turbyfill’a. Tym, co odróżnia go od AS3AP jest raportowanie wielu miar badanego systemu,
nie ograniczając się jedynie do rozmiaru maksymalnej bazy danych, jaka może być użyta
w celu ukończenia kompletu testów AS3AP w mniej niż 12 godzin. Zaletą OSDB jest możliwość pracy z niekompletnymi implementacjami SQL-a lub implementacjami jego pozbawionych.
w
2.4 Niagara Extension to XMark
2.5 Linear Road
da
.b
w
Projekt Niagara jest efektem współpracy Portland State University i University of Wisconsin-Madison. Projekt ma na celu zbadanie mechanizmów efektywnego wykonywania zapytań w Internecie. Grupa pracująca nad testem NEXMark [4,6] zajmuje się zapytaniami
w strumieniach danych (XML). Jako przykładowy model przyjęto system zarządzania danymi dla internetowego serwisu aukcyjnego.
Wspólny projekt [7] uczelni Brandeis University, Stanford, Portland State oraz MIT umożliwia porównywanie charakterystyk wydajności systemów zarządzania strumieniowych baz
danych względem siebie oraz systemów relacyjnych. Celem tego testu jest ustalenie miary
wydajności systemu zarządzania danymi przetwarzającego strumienie. Przyjęty model
oparto na zestawie czujników realizujących monitoring ruchu na zatłoczonych drogach ekspresowych. Test jest uruchamiany ze zwiększającymi się współczynnikami dopóki nie zostanie znaleziony taki, dla którego nie będą spełnione założone wymagania.
pl
s.
3 Opracowana metoda pomiaru
W ramach prowadzonych prac opracowano zbiór programów mających na celu określenie
wydajności badanych systemów zarządzania danymi. Zbiór ten nazwano Systemem Pomiarowym. Przyjęty plan eksperymentu zakładał jego realizację na jednym komputerze. Zainstalowano na nim serwer bazy danych oraz uruchomiono System Pomiarowy, który w zadany sposób symulował zapytania pochodzące od stanowisk roboczych. Równoległość zachodzących procesów przy tworzeniu zapytań symulowano przy pomocy mechanizmu wielowątkowości. Każdy z procesów łączył się z lokalną bazą danych i wysyłał zapytania z określoną częstotliwością.
Przyjęcie takiego modelu wiąże się również z negatywnymi czynnikami, które wpływają
na wynik badania. Np. nie uwzględniono opóźnień wnoszonych przez sieć komputerową.
Pod uwagę nie wzięto również konsumpcji dodatkowych zasobów systemu operacyjnego
przez mechanizm obsługi wątków a także wpływu procesu dokonującego zapisu wyników
pomiaru.
383
3.1 Plan realizacji badań
w
W ramach planu badań przewidziano kilka typowych scenariuszy zastosowań systemów
baz danych. Określono uproszczony model systemu obsługi klientów oraz wydzielony fragment procesu zachodzącego w trakcie pracy hurtowni danych.
Analizując konstrukcję typowego systemu obsługującego klientów dużego sklepu lub
małej firmy można wydzielić kilka stanowisk roboczych oraz serwer bazy danych obsługujący transakcje generowane na poszczególnych stanowiskach. Przez pojedynczą, typową
transakcję na stanowisku roboczym rozumiemy obsługę pojedynczego klienta: pobranie
informacji o towarze, wyświetlenie ich na ekranie, przesłanie informacji o zakupie do bazy
oraz zatwierdzenie zapłaty. Tego typu schemat postępowania powtarza się wielokrotnie w
trakcie działania systemu zarządzania danymi. Przygotowano również eksperyment mający
na celu określenie wpływu indeksowania danych na czas odpowiedzi systemu.
Drugim analizowanym w ramach niniejszej pracy modelem systemu jest proces ładowania danych do hurtowni danych. Przez hurtownie danych rozumiemy bazę danych, którą
zorganizowano i zoptymalizowano pod kątem szybkiej analizy i przetwarzania informacji
z pewnego, ograniczonego wycinka rzeczywistości. Dla potrzeb prowadzonych badań analizowano proces szybkiego ładowania danych do hurtowni. W takim scenariuszu przeważają polecenia SQL umieszczające dane w bazie, co odpowiada zasilaniu hurtowni danych
informacjami z poszczególnych baz danych.
da
.b
w
w
3.2 System Pomiarowy
3.3 Błędy pomiaru
pl
s.
Na System Pomiarowy składa się program zarządzający przebiegiem testu oraz kilka programów testujących, po jednym dla każdego systemu zarządzania danymi. Program główny
odczytuje i przetwarza pliku konfiguracyjny a następnie uruchamia poszczególne programy
testujące. Programy komunikują się z systemem zarządzania bazą danych za pomocą najszybszego dostępnego interfejsu komunikacyjnego – wywołań funkcji API danej bazy danych. System zarządzania bazą danych realizuje żądane operacje, po czym informuje program testujący o powodzeniu operacji za pomocą zwracanej wartości. Dane dla procesu zawarto w postaci poleceń SQL znajdujących się w pliku konfiguracyjnym.
Po uruchomieniu programu testującego przez program zarządzający wczytywany jest
plik konfiguracyjny. Na podstawie jego zawartości tworzone są wątki, uruchamiane równolegle bądź szeregowo. Każdy z wątków realizuje powiązany z nim test, wykonując zapytania do bazy danych. Wątki jednocześnie umieszczają w specjalnej kolejce wyniki pomiarów. Są one następnie zapisywane do pliku wyjściowego przez kolejny wątek, pełniący
funkcję rejestratora zdarzeń. Po zakończeniu pracy wszystkich programów testujących następuje zakończenie pracy Systemu Pomiarowego i zamknięcie plików wynikowych.
Dane obserwacyjne i pomiarowe pobierane z obiektu badań doświadczalnych zwykle obciążone są błędami. Istotnym czynnikiem, wpływającym na wynik badania, jest fakt przeprowadzania testów na tym samym komputerze, na którym znajduje się serwer bazy danych
wraz z samą bazą. Operacje związane z przetwarzaniem danych wpływają na działanie systemu zarządzania danymi. Rozwiązaniem jest połączenie aplikacji z systemem zarządzania
danymi znajdującym się na innym komputerze. W tym wypadku należy wziąć pod uwagę
opóźnienia wynikające z połączenia sieciowego. Z uwagi na mechanizm buforowania, za384
w
warty w systemie zarządzania bazą danych, parametrem o kluczowym znaczeniu jest ilość
pamięci operacyjnej. W przypadku niewystarczającej ilości pamięci następuje uruchomienie mechanizmu stronicowania, co powoduje znaczący spadek wydajności i wpływa na rezultat pomiarów.
Badania przeprowadzono na systemach zainstalowanych z parametrami domyślnymi.
Tego typu podejście może wprowadzać potencjalny błąd związany wadliwą obsługą operatorską. Możliwe dodatkowe strojenie systemu, określenie dodatkowych parametrów, powiększenie buforów może mieć znaczący wpływ na wyniki pomiaru.
Pomimo wpływu przytoczonych błędów, potencjalnego błędu modelowego wynikającego z nadmiernych uproszczeń, po przeprowadzeniu szeregu eksperymentów można stwierdzić, że największe opóźnienia dla określonych w badaniu parametrów (jedynie 3 wątki odpytujące i jeden serwer bazy danych) wprowadza system zarządzania bazą danych i zastosowane w jego konstrukcji algorytmy dostępu do danych.
w
w
4 Badania eksperymentalne
da
.b
Stanowisko dla przeprowadzenia badań wydajności systemów zarządzania baz danych składało się z jednego komputera o następującej konfiguracji: system operacyjny Microsoft
Windows XP Professional z dodatkiem SP2, procesor AMD Athlon XP 1800+ (1.53 GHz),
pamięć operacyjna 512 MB DDR SDRAM, dysk twardy 120 GB. Na komputerze zainstalowano bazy danych: MySQL Server 5.0 oraz PostgreSQL 8.0. Baza SQLite 3.3.4, funkcjonująca w postaci samodzielnej biblioteki dynamicznej nie wymagała instalacji.
4.1 Eksperyment 1 – odczyt danych niezaindeksowanych
Celem pierwszego eksperymentu było określenie wydajności systemów w trakcie realizacji
zadania ciągłego odczytu danych w przedstawionym modelu obsługi klientów.
pl
s.
Rys. 1. Liczba zrealizowanych zapytań zrealizowanych w danym okresie dla systemów:
MySQL, PostreSQL i SQLite w trakcie realizacji eksperymentu 1
385
Założono stosunkowo niewielki, niezaindeksowany zbiór danych. Liczba wierszy w tabeli
wynosiła 5000, natomiast liczba zapytań wykonywanych przez każdy z trzech wątków była
równa 2000. Wysyłane do systemu zarządzania danymi zapytania przedstawiały się
następująco:
SELECT * FROM number WHERE intval1 = %d
w
Gdzie wartość %d była zastąpiona przez wartość losową o rozkładzie równomiernym
z przedziału 0,4999.
Przedstawiony na rys. 1 wykres ilustruje uśredniony z trzech równoległych wątków wynik dla zapytań wysłanych do wszystkich trzech baz danych. Na podstawie wykresu można
wnioskować, że najszybciej zadanie zostało zrealizowane przez system MySQL, więcej
czasu wymagała realizacja zadania w systemie SQLite a najwolniejszą bazą w tym eksperymencie okazał się PostgreSQL.
w
4.2 Eksperyment 2 – zapis danych
da
.b
w
Celem drugiego eksperymentu było sprawdzenie czasu realizacji zadania przez system zarządzania danymi dla modelu systemu hurtowni danych. Liczba wstawianych wierszy w tabeli wynosiła 5000, natomiast liczba zapytań wykonywanych przez każdy z trzech wątków
była równa 2000. Wysyłane do systemu zarządzania danymi zapytania przedstawiały się
następująco:
INSERT INTO number VALUES (%d, 1)
pl
s.
Rys. 2. Liczba zrealizowanych poleceń wstawiania danych zrealizowanych w danym
okresie MySQL i PostgreSQL w trakcie realizacji eksperymentu 2
386
w
Wstawiane wartości losowe nie miały znaczenia dla pomiaru czasu realizacji zbioru
poleceń.
Z powodu braku równoległej obsługi poleceń SQL umieszczających dane w bazie nie
otrzymano wyników dla tego systemu. W trakcie prowadzenia badań okazało się, że
SQLite obsługuje poprawnie wstawianie danych do bazy tylko dla jednego wątku. Operacja
umieszczenia danych przez różne wątki w tym samym czasie kończy się niepowodzeniem
i zgłoszeniem komunikatu błędu przez program testujący. Taka funkcjonalność SQLite
została potwierdzona w dokumentacji technicznej. Otrzymane wyniki dla systemów
PostreSQL oraz MySQL przedstawiono na rys. 2.
w
4.3 Eksperyment 3 – odczyt danych zaindeksowanych
pl
s.
da
.b
w
Celem trzeciego eksperymentu, podobnie jak w przypadku eksperymentu 1 było określenie
czasu realizacji ciągu zapytań. Różnica polegała na zastosowaniu indeksu utworzonego na
pierwszej kolumnie tabeli. Reszta parametrów eksperymentu pozostała taka sama.
O ile otrzymane wyniki wskazywały na znaczące (ponad 10 krotne) przyspieszenie procesu wybierania danych przez systemy MySQL i PostreSQL o tyle otrzymane wyniki
w trakcie realizacji eksperymentu z bazą SQLite budzą zainteresowanie.
Zaobserwowano, że testy, które miały być wykonane równolegle, zostały wykonane sekwencyjne w takiej kolejności, w jakiej zostały uruchomione. Otrzymane wyniki sugerują
najprostszą zastosowaną gospodarkę zasobami. Co ciekawe, pomimo tego, sumaryczny
i uśredniony czas realizacji eksperymentu dla tego systemu okazał się najkrótszy.
Rys. 3. Liczba zrealizowanych zapytań przez 3 oddzielne procesy w danym okresie dla
systemu SQLite z wykorzystaniem indeksowania w trakcie realizacji eksperymentu 3
387
w
da
.b
w
w
Rys. 4. Liczba zrealizowanych zapytań zrealizowanych w danym okresie dla analizowanych baz danych z wykorzystaniem mechanizmu indeksowania w trakcie realizacji eksperymentu 3
5 Wnioski
pl
s.
Otrzymany wynik potwierdza skuteczność opracowanego Systemu Pomiarowego w procesie identyfikacji zastosowanych algorytmów w konstrukcji systemu zarządzania danymi.
Na rys. 4 przedstawiono wykres ilustrujący realizację zapytań dla wszystkich trzech baz
danych. Otrzymane wyniki zostały uśrednione. Z przedstawionego wykresu można odczytać, że najszybciej zadanie zostało zrealizowane dla bazy SQLite. Nieco gorszy wynik uzyskał MySQL, natomiast najwolniejszą bazą, podobnie jak w pozostałych eksperymentach,
okazał się system PostgreSQL.
Należy zwrócić uwagę na zmiany w początkowej fazie eksperymentu. Czas odpowiedzi
systemu dla niewielkich ilości danych okazał się zależny od ilości zapytań. Podobnie jak
w poprzednim eksperymencie otrzymany wynik potwierdza skuteczność opracowanego
Systemu Pomiarowego w procesie identyfikacji zastosowanych algorytmów w konstrukcji
systemu zarządzania danymi.
Istnieje potrzeba stworzenia uniwersalnego i dobrze udokumentowanego systemu pomiarowego, przeznaczonego do porównywania wydajności systemów zarządzania baz danych.
Obecnie prowadzone są w wielu ośrodkach naukowych na świecie prace i badania mające
na celu opracowanie takich systemów.
W trakcie prowadzonych przez autorów pracy badań opracowano teoretyczno-eksperymentalny model badawczy. Przyjęto założenie, że realizacja eksperymentu nastąpi na pojedynczym komputerze. Zainstalowano serwery baz danych oraz uruchomiono program, któ-
388
w
ry w określony sposób tworzył zapytania, symulując tym samym zapytania nadchodzące ze
stanowisk roboczych. Wyniki pomiarów przedstawiono w postaci wykresów.
W ramach planu badań przewidziano kilka scenariuszy typowych dla zastosowań systemów
baz danych. Przeprowadzono eksperymenty symulujące działanie systemu obsługi klientów
oraz fragmentu procesu ładowania danych do hurtowni danych. Pierwszy eksperyment, który miał na celu sprawdzenie zachowania baz dla modelu systemu obsługi klientów w przypadku niewielkiej liczby danych w bazie, pokazał liniowy wpływ systemu MySQL na czas
odpowiedzi. Drugi eksperyment miał na celu zbadanie zachowania baz dla modelu systemu
hurtowni danych. Okazało się, że system SQLite obsługuje operacje wstawiania danych do
bazy tylko dla jednego procesu, co potwierdziły informacje ze strony producenta.
Celem trzeciego eksperymentu było sprawdzenie zachowania baz dla modelu systemu
obsługi klientów w przypadku niewielkiej liczby danych w bazie i przy zastosowaniu indeksu utworzonego na pierwszej kolumnie tabeli. Dla systemu SQLite zaobserwowano, że
testy, które miały być wykonane równolegle, zostały wykonane szeregowo. Pomimo tego,
baza ta najszybciej zrealizowała powierzone zadanie.
Podsumowując wyniki przeprowadzonych eksperymentów przy pomocy opracowanego
Systemu Pomiarowego można stwierdzić, że pomimo najlepszych wyników systemu
SQLite, w pewnych zastosowaniach, w których wymagana jest równoległość operacji system ten nie spełnia wymagań funkcjonalnych. Najlepszą i najbardziej racjonalną gospodarkę zasobami prowadzi system PostreSQL. Jednak jego wydajność ustępuje wydajności
osiągniętej w systemie MySQL. Dzięki opracowanemu Systemowi Pomiarowemu autorzy
pracy byli w stanie odkryć i porównać pewne algorytmy zastosowane w konstrukcji systemów zarządzania danymi bez konieczności analizy źródeł systemów zarządzania danymi.
1.
2.
3.
5.
6.
7.
8.
9.
Jeong H. J., Lee S. H.: An Integrated Database Benchmark Suite, Semantics, Knowledge and
Grid, SKG '05, str. 60, Pekin, Chiny, 2005.
Vandierendonck H., Trancoso P.: Building and Validating a Reduced TPC-H Benchmark,
Proceedings of the 14th IEEE International Symposium on Modeling, Analysis, and Simulation,
str. 383-392, 2006.
Yagoub K., Florescu D., Issarny V., Valduriez P.: Caching Strategies for Data-Intensive Web
Sites, VLDB Journal , str. 188-199, 2000.
Che D., Aberer K., Ozsu T.: Query optimization in XML structured-document databases,
VLDB J., str. 263-289, 2006.
http://www.osdl.org/lab_activities/kernel_testing/osdl_database_test_suite
Tucker P. A., Tufte K., Papadimos V., Maier D.: NEXMark a Benchmark for Querying Data
Streams - DRAFT, http://www.cse.ogi.edu/dot/niagara/pstream/nexmark.pdf
Arasu A., Cherniack M., Galvez E. F., Maier D., Maskey A., Ryvkina E., Stonebraker M.,
Tibbetts R.: Linear Road: A Stream Data Management Benchmark, Proceedings of the 2004
VLDB Conf., str. 480-491, 2004.
Haftmann F., Kossmann D., Lo E.: Parallel execution of test runs for database application
systems, Proc. 31st VLDB, 2005, Trondheim, Norwegia, str. 589-600, 2005.
Widera M., Domański A., Kasprzyk P.: Analiza zastosowania baz danych w zadaniu
przetwarzania sygnałów biomedycznych, Bazy danych Modele, technologie, narzędzia - Analiza
danych i wybrane zastosowania BDAS 05, str. 371-378, 2005.
pl
s.
4.
da
.b
w
w
Literatura
389
w
pl
s.
da
.b
w
w

pobierz plik referatu - BDAS

Transkrypt

Podobne dokumenty

Semestr IV

PDF: Projekt pilotażowy w zaledwie 10 dni

pobierz plik referatu

pobierz plik referatu

Duży plakat szkolny 2 - Szkoła Podstawowa nr 19 w Elblągu

Agencja Bezpieczeństwa Wewnętrznego ogłasza nabór do służby w

Dynamicznie rozwijająca się firma konsultingowa opierająca się na