Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
ul. Warszawska 24, 31-155 Kraków, tel/fax (+48 12) 628 20 41, e-mail: [email protected], internet: www.iigw.pl
INSTYTUT INŻYNIERII I GOSPODARKI WODNEJ
POLITECHNIKA KRAKOWSKA im. TADEUSZA KOŚCIUSZKI
Piotr Nowak
OCENA WYDAJNOŚCI HYDROMETEOROLOGICZNYCH BAZ DANYCH
W MYSQL 5.0
praca magisterska
studia dzienne kierunek studiów: informatyka
specjalność: informatyka stosowana w inżynierii środowiska
promotor: dr inż. Robert Szczepanek
nr pracy: 2069
data złożenia: ................................
KRAKÓW 2007
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 2
Spis Treści:
SPIS TREŚCI: ................................................................................................................................. 2 1. WSTĘP ...................................................................................................................................... 4
1.1. CEL PRACY .......................................................................................................................... 4 1.2. OPIS PROBLEMU.................................................................................................................. 4 1.3. ZAWARTOŚĆ PRACY ............................................................................................................ 4 1.4. KRYTERIA OCENY ................................................................................................................ 6
1.4.1. Wydajność zapisu ..................................................................................................... 6 1.4.2. Wydajność wyszukiwania ....................................................................................... 6 1.4.3. Objętość....................................................................................................................... 7
1.5. TEORETYCZNE PODSTAWY SYSTEMÓW BAZODANOWYCH .................................................... 8 1.5.1. Język SQL.................................................................................................................... 8 1.5.2. Relacyjny model danych ......................................................................................... 9 1.5.3. Formalny zapis operacji na modelu relacyjnym .............................................. 9 1.5.4. Normalizacja baz danych...................................................................................... 13 1.5.5. Pojęcie postaci normalnej .................................................................................... 14 1.5.6. Hurtownie danych................................................................................................... 17 1.5.7. Systemy MySQL/PostgresSQL............................................................................. 19
1.6. WYMAGANIA SPRZĘTOWE ................................................................................................. 21 1.6.1. Propozycja konfiguracji obsługującej projektowany system...................... 21
2. WYMAGANIA FUNKCJONALNE.................................................................................... 23 2.1. ZAŁOŻENIA PROJEKTOWANEGO SYSTEMU......................................................................... 23
2.1.1. Rodzaj informacji zasilających system ............................................................. 23 2.1.2. Format gromadzonych danych ........................................................................... 24 2.1.3. Przewidywana ilość danych zasilająca system............................................... 25 2.1.4. Możliwe sposoby dostępu do danych ................................................................ 27
2.2. FUNKCJE PODSTAWOWE.................................................................................................... 29 2.2.1. Gromadzenie danych z systemu czujników .................................................... 29 2.2.2. Archiwizacja danych w dłuższym horyzoncie czasowym............................. 29 2.2.3. Umożliwienie klientom dostępu do danych ..................................................... 30
2.3. PROPOZYCJE ROZSZERZEŃ FUNKCJONALNOŚCI ................................................................ 31 2.3.1. Zapis danych, a detekcja błędów....................................................................... 31 2.3.2. Wykorzystanie logiki rozmytej w detekcji błędów ........................................ 32 2.3.3. Określanie właścicieli przechowywanych pomiarów ..................................... 34 2.3.4. Obsługa różnych poziomów użytkowników ..................................................... 34 2.3.5. Automatyczne powiadomienia ............................................................................ 35 2.3.6. Synchronizacja z bazami „zaprzyjaźnionymi” ................................................ 36 2.3.7. Obsługa płatnego dostępu do danych............................................................... 37 2.3.8. System monitorowania danych w czasie rzeczywistym .............................. 37
2.4. PROPOZYCJE ZWIĘKSZENIA WYDAJNOŚCI ......................................................... 39 2.4.1. Mechanizm cacheingu............................................................................................ 39 2.4.2. Rozwiązanie softwarowe – AdoDB ..................................................................... 41 2.4.3. Wydzielenie wyspecjalizowanych serwerów ................................................... 42 2.4.4. System rozproszony............................................................................................... 43
3. PROJEKTOWANE PROPOZYCJE ROZWIĄZAŃ ...................................................... 44 3.1. DANE ZAPISANE W JEDNEJ TABELI.................................................................................... 44 3.2. KAŻDY POMIAR W OSOBNYM REKORDZIE ......................................................................... 46 3.3. TRZECIA POSTAĆ NORMALNA ............................................................................................ 47
4. SCENARIUSZE DOSTĘPU DO DANYCH .................................................................... 49
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 3
4.1. NAJCZĘŚCIEJ WYKORZYSTYWANE KWERENDY................................................................... 49 4.2. OPIS SPOSOBU PROWADZENIA POMIARÓW CZASU WYKONANIA ...................................... 50
4.2.1. Środowisko testowe ............................................................................................... 51 4.2.2. Sposób prowadzenia pomiarów .......................................................................... 51
4.3. PORÓWNANIE WYDAJNOŚCI SCHEMATÓW W OBSŁUDZE ZAPYTAŃ.................................... 53 4.3.1. Wpływ zastosowania indeksów na czas obsługi zapytań. ........................... 53
4.4. KRYTERIA OCENY PROPONOWANYCH ROZWIĄZAŃ ............................................................ 54 4.4.1. Objętość..................................................................................................................... 55 4.4.2. Wydajność zapisu ................................................................................................... 55 4.4.3. Wydajność odczytu................................................................................................. 55
5. ZESTAWIENIE UZYSKANYCH WYNIKÓW .............................................................. 56 5.1. ZESTAWIENIE WYDAJNOŚCI ROZWIĄZAŃ ......................................................................... 56
5.1.1. Objętość..................................................................................................................... 56 5.1.2. Wydajność zapisu ................................................................................................... 60 5.1.3. Wydajność odczytu................................................................................................. 64
5.2. WYBÓR ODPOWIEDNIEGO ROZWIĄZANIA......................................................................... 74 6. ANALIZA WYNIKÓW........................................................................................................ 83
6.1. ZALETY WYBRANEGO ROZWIĄZANIA ................................................................................. 85 6.2. WADY WYBRANEGO ROZWIĄZANIA ................................................................................... 86
7. WNIOSKI .............................................................................................................................. 87 8. SPISY...................................................................................................................................... 89
8.1. SPIS ILUSTRACJI............................................................................................................... 89 8.2. SPIS TABEL ....................................................................................................................... 90 8.3. LITERATURA ...................................................................................................................... 91 8.4. LINKI................................................................................................................................. 91
9. ABSTRAKT ............................................................................................................................ 92
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 4
1. WSTĘP
1.1. Cel pracy
Przedmiotem rozważań tej pracy jest badanie wydajności
różnych schematów bazy danych hydrometeorologicznych. Baza ta,
ma w założeniu odpowiadać za gromadzenie i przetwarzanie danych,
z terenu jednego powiatu. Badanie zostanie przeprowadzone
w środowisku MySQL 5.0 i obejmie trzy propozycje schematów
bazodanowych. Wyniki przeprowadzonych testów pozwolą
udokumentować proces „odnajdywania” najlepszego rozwiązania.
1.2. Opis problemu
Problemem, który w założeniu, ta praca ma rozwiązać, jest
wydajne gromadzenie i udostępnianie klientom, danych
hydrometeorologicznych. Taka definicja problemu pozwala zauważyć
dwa pod problemy. Pierwszy z nich, to wydajne gromadzenie danych.
Można to rozumieć jako problem zagwarantowania wydajnego zapisu
do bazy danych. Drugi, wydajne udostępnianie, to problem
wydajności odczytu informacji zgromadzonych w systemie.
1.3. Zawartość pracy
Zgodnie z praktyką tworzenia rozwiązań informatycznych,
projektowanie systemu zostało podzielone na szereg etapów.
Pierwszym z nich jest zgromadzenie informacji na temat rodzaju
i ilości danych, które system będzie magazynował. Następnym
krokiem jest określenie funkcjonalności jaką system powinien
udostępniać. Na tym etapie należy określić jakie zestawy danych
powinny być łatwo dostępne, dane z jakiego okresu czasu powinny
być udostępniane w czasie rzeczywistym.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 5
Oraz czy istnieje konieczność implementacji różnych poziomów
dostępu do informacji zgromadzonej w projektowanym systemie. Po
ustaleniu na jakiej ilości, jakich danych system będzie pracował, oraz
jakie możliwości przetwarzania danych powinien oferować, opisany
zostanie proces tworzenia rozwiązań kandydujących. Rozwiązaniem
kandydującym jest każdy schemat bazodanowy, którego wydajność
nie została jeszcze sprawdzona i skonfrontowana z innymi
propozycjami. W założeniu, każde z tych rozwiązań spełnia
postawione warunki użyteczności, a zatem każde z nich mogłoby
zostać użyte podczas wdrażania opisywanego systemu. Należy jednak
porównać rozwiązania kandydujące poprzez szereg testów
stworzonych na podstawie analizy wymogów funkcjonalnych. Testy te
mają na celu sprawdzenie, czy dane rozwiązanie spełnia wymogi
wydajności zapisu, odczytu i objętości.
Zestawienie wyników testów przeprowadzanych w izolowanym
środowisku bazodanowym pozwoli zilustrować, które z rozwiązań
najlepiej funkcjonuje w zadanych warunkach. Efektem powziętych
wysiłków będzie opis zachowania proponowanych rozwiązań
w poszczególnym teście. Dzięki temu możliwe będzie podjęcie
racjonalnej decyzji, które z rozwiązań jest najlepsze dla zadanych
warunków działania projektowanego systemu na zadanym terenie,
z uwzględnieniem specyficznych wymagań mogących wystąpić.
Dodatkowo, można przeprowadzić analizę możliwości rozwoju
danych rozwiązań kandydujących w celu zwiększenia funkcjonalności
lub ułatwienia obsługi. Na tym etapie należy zadać pytanie czy, a jeśli
tak, to jakie dodatkowe usługi system powinien posiadać. Czy istnieje
potrzeba implementacji rozwiązań typu database cache (AdoDB) lub
Global Proxy (Akamai) lub też rozproszenia systemu, aby zbieranie
danych odbywało się lokalnie, a archiwizacja na głównym serwerze.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 6
1.4. Kryteria oceny
Przystępując do projektowania, należy określić kryteria oceny
jakości systemu. W badaniu jakości rozwiązań rozpatrywane będą
trzy kryteria:
Wydajność zapisu
Wydajność odczytu
Objętość
1.4.1. Wydajność zapisu
W systemie bazodanowym można wyszczególnić dwa
podstawowe rodzaje operacji. Są to operacje zapisu i odczytu danych.
Z punku widzenia użytkowników, wydajność tych operacji decyduje
o jakości systemu. Ze względu na zakładaną początkową liczbę stacji
pomiarowych tj. około 50, częstotliwość dokonywania pomiarów
tj. około 1 serii na 10 minut, oraz zakładanego rozwoju sieci
pomiarowej w przyszłości - wydajność zapisu danych jest
podstawowym kryterium branym pod uwagę podczas projektowania
systemu agregującego dane z wielu źródeł. Dodatkowo, na wydajność
zapisu mają duży wpływ czynniki zewnętrzne, nie związane
z zastosowanym schematem bazy danych. Zaliczają się do nich
parametry łącza jakie obsługuje serwer bazodanowy, ilość pamięci
przydzielonej procesowi serwera, dopuszczalna ilość konkurujących
połączeń przychodzących, rodzaj urządzeń fizycznie magazynujących
dane – dysków twardych, oraz sposób ich podłączenia. Z punktu
widzenia oprogramowania bazodanowego, zapis nowych danych jest
jedną z najszybszych operacji. Twórcy oprogramowania włożyli sporo
wysiłku aby ten proces maksymalnie zoptymalizować.
1.4.2. Wydajność wyszukiwania
Jako, że głównym zastosowaniem baz danych jest ułatwianie
dostępu do wyspecyfikowanego wycinka większego zbioru informacji,
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 7
projektując taki system nie można pominąć kwestii wygody
użytkownika podczas dostępu do poszukiwanych danych. Podczas
rozpatrywania zagadnień wydajności dostępu do danych, czynniki
zewnętrzne także nie pozostają bez znaczenia, jednakże ich
znaczenie nieco się zmienia, np. szybkość łącza internetowego
obsługującego serwer ma mniejsze znaczenie ze względu na fakt, iż
rzadko przychodzą żądania ilości danych objętościowo dorównujących
tym, jakie musza być zapisywane. Nie można jednak pominąć
ograniczeń fizycznych, wynikających ze specyfikacji użytego sprzętu
komputerowego. Można ograniczyć ich wpływ stosując rozwiązania
zwiększające wydajność odczytu i zapisu, takie jak szybkie dyski
SCSI, macierze dyskowe RAID oparte o dyski (S)ATA, lub także
o dyski SCSI.
1.4.3. Objętość
Wraz z upływem czasu i przyrostem przechowywanych
informacji, pojawi się także problem składowania takich ilości danych.
Dla przykładu, w sytuacji gdy w systemie działa 500 stacji
pomiarowych, z których każda gromadzi 20 pomiarów co 10 minut,
objętość surowych danych będzie przyrastała o 0.25MB co każdą
godzinę, jeśli zapisu dokonujemy używając liczb całkowitych. Jeśli
użyjemy typu zmiennoprzecinkowego Double będzie to 0.5MB na
godzinę. Baza zasilana taką ilością danych po 10 latach osiągnie
ogólny rozmiar 20.5GB przy liczbach całkowitych i 41GB przy liczbach
zmiennoprzecinkowych. Można więc zauważyć, że sama zmiana typu
przechowywanych danych pozwala zaoszczędzić połowę miejsca.
Niestety przetwarzanie takich danych przechowywanych w liczbach
całkowitych wiązałoby się z wykorzystaniem większej mocy
obliczeniowej do ich późniejszego przetwarzania. Dodatkowo, to
proste wyliczenie nie uwzględnia faktu powiększania się ilość stacji
monitorujących w czasie.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 8
1.5. Teoretyczne podstawy systemów bazodanowych
1.5.1. Język SQL
SQL stał się najpopularniejszym relacyjnym językiem zapytań
bazodanowych. Nazwa jest skrótem od Structured Query Language
(Strukturalny Język Zapytań). W 1974 r. Donald Chamberlin i inni
zdefiniowali SEQUEL (Structured English Query Language). Po raz
pierwszy został wprowadzony w prototypie IBM zwanym SEQUEL-XRM
w 1974-75 r. W latach 1976-77 powstała poprawiona wersja SEQUEL
nazwana SEQUEL/2 , a nazwę tą następnie zmieniono na SQL.
Nowy prototyp System R, wprowadzony przez IBM w 1977r.
obejmował większą część SEQUEL/2 (teraz SQL) jak i wprowadzał
wiele zmian do SQL. Sukces i akceptacja pierwszych użytkowników
spowodował, że IBM rozpoczęła wprowadzanie pierwszych
komercyjnych produktów opartych na technologii Systemu R,
zawierających SQL. [Wikipedia, 2007-08-29]
Przez następne lata IBM i inni producenci stworzyli produkty
korzystające z technologii SQL, takie jak:
SQL/DS (IBM)
DB2 (IBM)
ORACLE (Oracle Corp.)
DG/SQL (Data General Corp.)
SYBASE (Sybase Inc.)
Obecnie SQL jest standardem oficjalnym. W 1982 r. Komitet
Baz Danych X3H2 Amerykańskiego Instytutu Standardów ANSI
(American National Standards Institute) przedstawił propozycję
standardu języka relacyjnego, który zawierał dialekt IBM i został
przyjęty w 1986 r. Rok później standard ten został również
zaakceptowany przez Międzynarodową Organizację Standaryzacji ISO
(International Organization for Standardization). Oryginalna wersja
standardu jest nieformalnie nazywana SQL/86. W 1989 r. standard
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 9
został rozszerzony i ponownie było to rozszerzenie nieformalnie,
a nowy standard nazwano SQL/89.
Komitety ISO i ANSI przez wiele lat pracowały nad
zdefiniowaniem bardziej rozbudowanej wersji standardu nazwanej
SQL2 lub SQL/92. Ta wersja w 1992 r. została przyjęta jako:
"International Standard ISO/IEC 9075:1992, Database Language
SQL". Szczegółowy opis SQL/92 podano w Date and Darwen, 1997.
1.5.2. Relacyjny model danych
Jak wspomniano wcześniej, SQL jest językiem relacyjnym.
Oznacza to, że jest oparty na relacyjnym modelu danych,
opublikowanym po raz pierwszy przez E.F.Codd'a w 1970 roku. Baza
danych oparta na modelu relacyjnym, jest bazą postrzeganą przez
użytkowników jako zbiór tabel. Tabela składa się z wierszy i kolumn,
gdzie każdy wiersz reprezentuje rekord, a każda kolumna atrybuty
rekordów zawartych w tabeli. Definiując tabelę, możemy określać
atrybuty rekordów oraz jakiego rodzaju dane będą reprezentować
dany atrybut. [David M. Kroenke, 1997]
1.5.3. Formalny zapis operacji na modelu relacyjnym
Model relacyjny może być zapisany w postaci podzbioru
iloczynu kartezjańskiego z listy dziedzin. Od tej teoretycznej relacji
bierze się nazwa tego modelu. W rzeczywistości dziedzina, inaczej
domena, jest po prostu zbiorem wartości. Na przykład, dziedziną jest
zbiór liczb całkowitych lub zbiór łańcuchów znakowych o długości 20
znaków, czy też zbiór liczb rzeczywistych.
Iloczyn kartezjański dziedzin:
D1, D2, ... Dk
zapisany jako:
D1 × D2 × ... × Dk
jest zbiorem wszystkich krotek
v1, v2, ... vk, takich jak v1 D1, v2 D2, ... vk Dk.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 10
Na przykład, gdy mamy k=2, D1={0,1} oraz D2={a,b,c} wtedy
D1 × D2 jest {(0,a),(0,b),(0,c),(1,a),(1,b),(1,c)}.
Relacją jest dowolny podzbiór iloczynu kartezjańskiego jednej lub wielu dziedzin [Ramez Elmasri, Shamkant B. Navathe, 2005]:
R D1 × D2 × ... × Dk.
Na przykład {(0,a),(0,b),(1,a)} jest relacją; tzn. zbiorem
D1 × D2 wspomnianych wyżej.
Elementy relacji są nazywane krotkami. Każda relacja jakiegoś
iloczynu kartezjańskiego
D1 × D2 × ... × Dk
jest zbiorem krotek.
Każda relacja jest odzwierciedlana tabelą i może być
przeglądana w taki sam sposób jak tabela. Nazwy kolumn nazywane
atrybutami odgrywają główną rolę w definicji schematu relacji.
Schematem relacji R jest dowolny zbiór atrybutów A1, A2, ...
Ak. Dla każdego atrybutu Ai, 1 <= i <= k, jest dziedzina Di, skąd
brane są wartości atrybutów. Często schemat relacji zapisuje się
w ten sposób:
R(A1, A2, ... Ak).
Aby możliwe było wykonywanie operacji na modelu danych SQL
należy użyć jednego z dwóch rodzajów zapisu wyrażeń relacyjnych.
Są to algebra relacyjna oraz rachunek relacji. Te dwa języki
formalne dodają do modelu zbiór operacji umożliwiających
manipulowanie danymi przechowywanymi w bazie danych.
Algebra relacyjna stanowi podstawowy zbiór operacji dla
modelu relacyjnego. Operacje należące do tego zbioru umożliwiają
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 11
użytkownikowi wykonywanie podstawowych zapytań wyszukiwania,
a ich wynikiem jest zawsze nowa relacja tworzona z użyciem jednej
lub więcej relacji istniejących wcześniej. Oznacza to, że wynikiem
wykonania jednej operacji algebry relacyjnej jest relacja, mogąca być
użytą w wykonaniu innej / kolejnej operacji tej algebry. Sekwencja
takich operacji tworzy wyrażenie algebry relacyjnej, którego
wynikiem także jest relacja (np. wynik zapytania do bazy danych lub
żądania przeszukiwania).
Algebra relacyjna jest jednym z najważniejszych elementów
modelu relacyjnego ponieważ:
stanowi formalna podstawę dla operacji tego modelu.
Jest wykorzystywana podczas implementowania i optymalizowania
zapytań RDBMS
Niektóre z elementów tej algebry zostały włączone do języka
zapytań SQL
Operacje składające się na algebrę relacyjną można podzielić na
2 grupy. Jedna grupa obejmuje operacje na zbiorach
z matematycznej teorii zbiorów – w formalnym modelu relacyjnym
każda relacja jest zbiorem krotek. Operacje tej grupy to:
suma
część wspólna
różnica
iloczyn kartezjański
Druga grupa to zbiór operacji opracowanych specjalnie na
potrzeby relacyjnego modelu danych. Grupę tą można podzielić na
dwie podgrupy. Pierwsza to, operacje unarne, czyli operujące na
pojedynczych relacjach. Druga to, operacje binarne, czyli operujące
na dwóch tablicach.
Do grupy operacji unarnych zaliczamy:
selekcja – (SELECT) jest niezbędna do wyznaczenia takiego
podzbioru krotek z relacji, który spełni warunek selekcji. Operację
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 12
taką można traktować jak pewnego rodzaju filtr, który przepuszcza
jedynie krotki spełniające zdefiniowany warunek. Warunek selekcji
może być prosty – definiować wymóg tylko dla jednego parametru
krotki lub złożony – będący koniunkcją lub alternatywą warunków
prostych.
projekcja – w przeciwieństwie to operacji selekcji, projekcja
wybiera pewne kolumny z tabeli. Umożliwia ona rzutowanie
istniejącej relacji do formy, którą tworzą jedynie kolumny będące
przedmiotem zainteresowania w danej chwili.
Do grupy operacji binarnych zaliczamy:
złączania – (JOIN) operacja ta jest wykorzystywana do łączenia
występujących w dwóch różnych relacjach, połączonych ze sobą
krotek w pojedyncze krotki. Ta operacja jest bardzo ważna dla
relacyjnych baz danych, które zawierają więcej niż jedną relację.
Daje ona możliwość przetwarzania istniejących związków pomiędzy
relacjami.
dzielenia – przykładem tego specjalnego rodzaju operacji, może
być realizacja zapytania: „znajdź wszystkie stacje prowadzące
pomiary takich samych parametrów jak stacja ‘Żywiec 1’”.
Operacja dzielenia definiuje realizację takiego zapytania jako
następującą procedurę.
o Odnalezienie listy pomiarów przeprowadzanych przez
stację „Żywiec 1” i umieszczenie jej w pośredniej relacji
POMIARY_ZYWIEC1.
o Stworzenie relacji POMIAR_STACJA zawierającej krotki
w postaci
o <id_pomiaru, id_stacji>
o Dopiero dla tych dwóch relacji pośrednich stosujemy
właściwą operację dzielenia, która w wyniku zwróci
relację złożoną z oczekiwanych krotek.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 13
Rachunek relacji stanowi element systemu, zapewniający
deklaratywną notację definiowania relacyjnych zapytań na bardziej
abstrakcyjnym poziomie. Wyrażenie rachunku relacji tworzy nową
relację, której zawartość określają wartości zmiennych opisujące
zakresy krotek relacji przechowywanych w bazie danych. Wyrażenie
rachunku relacji nie określa kolejności wykonywania operacji,
a jedynie informacje jakie powinny się znaleźć w wygenerowanym
wyniku.
1.5.4. Normalizacja baz danych
Normalizacja to technika modelowania danych, której celem
jest zapewnienie organizacji elementów danych taki sposób, aby były
one przechowywane tylko w jednym miejscu [Allen S, 2006]. Zawiera
w sobie tworzenie tabel i wyznaczanie relacji pomiędzy tymi tabelami.
Normalizując bazę danych należy dążyć do wyeliminowania zjawisk:
Nadmiarowości
Niespójnych zależności
Nadmiarowość występuje gdy w obrębie tabeli lub bazy,
wielokrotnie powtarza się ta sama informacja. Przykładem
nadmiarowości może być tabela, gdzie każdy pomiar oznaczony jest
nazwą stacji z jakiej został pobrany.
Tabela 1. Przykładowa tabela z nadmiarowością danych
Stacja Polozenie czas_pomiaru temp2m temp0m Żywiec1 5311’45’’N 1311’45’’E 2007-04-22 12:00:11 11C 12C Żywiec2 5511’45’’N 2111’45’’E 2007-04-22 12:00:14 16C 17C Żywiec1 5311’45’’N 1311’45’’E 2007-04-22 12:00:21 11C 12C Żywiec1 5311’45’’N 1311’45’’E 2007-04-22 12:00:31 12C 14C
W powyższym przykładzie widać, że informacja w 2 pierwszych
kolumnach powtarza się. Oznacza to, że wraz ze zwiększaniem się
ilości zapisanych pomiarów, objętość bazy danych będzie wzrastać
niewspółmiernie do ilości pomiarów.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 14
W przypadku systemów przechowujących tak duże ilości
informacji, jak w przypadku projektowanego systemu dla pomiarów
hydrometeorologicznych, strata związana z niepotrzebnie
przechowywanymi danymi byłaby ogromna. Dodatkowym problemem
byłaby modyfikacja zawartych danych. Jeśli w tabeli z pomiarami
przechowywano by także numer telefonu do operatora stacji, a po
pewnym czasie numer ten uległby zmianie – należałoby zmienić
wszystkie rekordy dotyczące pomiarów dokonanych dla tej stacji.
Operacja taka byłaby bardzo kosztowna z punktu widzenia
zapotrzebowania na zasoby i mogłaby zakłócić poprawne
funkcjonowanie systemu.
Niespójne zależności. O ile poszukiwanie danych o numerze
telefonu do stacji Żywiec1 w tabeli Stacje, jest bardzo intuicyjne, to
szukanie numeru telefonu do osoby odpowiedzialnej za tę stację nie
jest poprawną drogą do rozwiązania problemu. Numer telefonu
takiego pracownika jest przypisany do osoby pracującej na danej
placówce – więc taka informacja powinna być przeniesiona do tabeli
Pracownicy. Niespójna zależność może oznaczać niemożliwość
dotarcia do takiej informacji. Może to być spowodowane błędnym
zaplanowaniem relacji w strukturze bazy danych.
1.5.5. Pojęcie postaci normalnej
Istnieje kilka postaci normalizacji baz danych. Każda z nich
nazywana jest „Postacią normalną”. Jeśli w danej strukturze
bazodanowej spełniona jest pierwsza z nich, uważa się, że baza
danych „jest w pierwszej postaci normalnej”. Jeśli spełnione są trzy
pierwsze zasady, rozważana struktura „jest w trzeciej postaci
normalnej”. Możliwe są wyższe poziomy normalizacji, uważa się
jednak, że trzecia postać normalna jest najwyższym poziomem
wymaganym w większości przypadków. [Kent, W., 1983]
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 15
Podobnie jak z wieloma teoretycznymi specyfikacjami, świat
rzeczywisty nie zawsze pozwala w pełni dopasować projektowane
rozwiązanie do postaci normalnych. Ogólnie, normalizacja wymaga
dodatkowych tabel, a niektórzy klienci, zamawiający rozwiązanie,
uważają taki fakt za zbędną komplikację. Jednak, jeśli podejmuje się
decyzję o odejściu od którejś z trzech pierwszych zasad normalizacji,
należy upewnić się, że projektowany system nie sprawi problemów
z nadmiarowością lub niespójnymi zależnościami. Pierwsza postać
normalna wymaga:
wyeliminowania powtarzających się grup w tabelach
utworzenia oddzielnej tabeli dla każdego zestawu danych
pokrewnych
określenia klucza podstawowego (Primary Key – (PK)) dla każdego
zestawu danych pokrewnych [Kent, W., 1983]
Nie należy używać pól w jednej tabeli do przechowywania
podobnych informacji. Przykładem może być zapis stacji z której
pochodzi pomiar.
Tabela 2. Przykład tabeli przechowującej Stacje pomiarowe
id_stacji (PK) nazwa Polozenie 1 Żywiec1 5311’45’’N 1311’45’’E 2 Żywiec2 5511’45’’N 2111’45’’E
Tabela 3. Przykład tabeli przechowującej Pomiary przed normalizacją
Id_pomiaru stacja1 stacja2 czas_pomiaru temp2m temp0m 1 1 2007-04-22 12:00:11 11C 12C 2 2 2007-04-22 12:00:14 16C 17C 3 1 2007-04-22 12:00:21 11C 12C 4 1 2007-04-22 12:00:31 12C 14C
Niestety, rozwiązanie takie jest bardzo nieelastyczne. Jeśli do
naszego systemu dodamy jeszcze jedną stację - cała nasza struktura
będzie wymagała przebudowy. Operacja taka jest możliwa, ale
wymaga zastosowania dodatkowego oprogramowania i może się
okazać niebezpieczna dla informacji przechowywanych w już
istniejących polach.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 16
Druga postać normalna wymaga:
utworzenia oddzielnych tabel dla zestawów wartości odnoszących
się do wielu rekordów
ustalenia powiązania tabel za pomocą klucza obcego [Kent, W., 1983]
Zobrazowaniem tej sytuacji może być utworzenie tabeli Stacje
i w tabeli Pomiary przechowywać, zamiast pól z przykładu (stacja,
położenie) jedynie pole id_stacji (klucz obcy – Foreign Key (FK)),
a informacje związane ze stacją zapisywać w tabeli Stacje.
Tabela 4. Przykład tabeli przechowującej Stacje pomiarowe
id_stacji (PK) nazwa polozenie 1 Żywiec1 5311’45’’N 1311’45’’E 2 Żywiec2 5511’45’’N 2111’45’’E
Tabela 5. Przykład tabeli przechowującej Pomiary po sprowadzeniu do drugiej postaci normalnej
id_pomiaru (PK) id_stacji (FK) czas_pomiaru temp2m temp0m 1 1 2007-04-22 12:00:11 11C 12C 2 2 2007-04-22 12:00:14 16C 17C 3 1 2007-04-22 12:00:21 11C 12C 4 1 2007-04-22 12:00:31 12C 14C
Rekordy nie powinny zależeć od niczego poza kluczem
podstawowym (względnie kluczem kompozytowym jeśli jest to
konieczne).
Trzecia postać normalna wymaga:
wyeliminowania pól, które nie zależą od klucza [Kent, W., 1983]
Wartości w rekordzie, które nie są częścią klucza, nie należą do
tabeli. Ogólnie, jeśli jakaś grupa pól odnosi się do więcej niż jednego
rekordu tabeli, należy rozważyć umieszczenie tych pól w osobnej
tabeli. W praktyce może być rozsądniej zastosować trzecią postać
normalną tylko do danych często się zmieniających. Jeśli istnieją pola
zależne, przy takiej konstrukcji bazy danych, należy zaplanować
aplikacje tak, aby wymagać od użytkownika weryfikacji wartości
w tych polach.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 17
1.5.6. Hurtownie danych
Hurtownia danych jest dużym systemem, który organizuje dane
tak, aby można było dotrzeć do większości informacji w nim
przechowywanych. Innymi słowy „… to coś więcej niż dane, to cały
proces służący przekazaniu danych ze źródła do tabeli, a następnie
dostarczeniu danych z tabeli do analityków [Anahory, S., & Murray, D.,
1997]”. Hurtownie danych mogą być i są używane w praktycznie
wszystkich aspektach biznesowych, rządowych czy edukacyjnych.
Wiele firm posiada ogromne ilości danych, które składowane są
w sposób uniemożliwiający swobodne korzystanie z nich. Hurtownie
danych organizują i udostępniają te dane analitykom, tak aby mogli
oni podejmować lepsze decyzje. Systemy takie mogą zbierać różne
dane z wielu źródeł i wyznaczać powiązania pozwalające wszystkim
typom informacji współgrać ze sobą. Ten typ rozwiązania posiada
zalety niedostępne w innych systemach bazodanowych. Inne typy
rozwiązań koncentrują swoją uwagę na składowaniu danych najlepiej
odpowiadających aplikacji jaką mają obsługiwać, a hurtownie danych
posuwają się o krok dalej, koncentrując się na danych samych
w sobie. Inną zaletą takich rozwiązań jest integracja danych, stabilne,
poprawne wartości i zapis nowych informacji w czasie rzeczywistym.
Systemy hurtowni danych umożliwiają wywoływanie kwerend dla
całościowych i posortowanych zestawów danych. Posiadanie jednego
pełnego źródła informacji dla użytkowników, daje pewność, że
wysłana kwerenda zwróci wynik tak bliski kompletnemu, jak to tylko
możliwe. [William H. Inmon, Richard D. Hackathorn, 1994]
Pojęcie hurtowni danych zawiera w sobie oprogramowanie,
sprzęt i siłę ludzką potrzebne do utrzymania takiego systemu.
Z pośród mnogości terminów związanych z teorią hurtowni danych
najważniejsze to:
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 18
Load Manager(s)
Load Interface – opcjonalny komponent ułatwiający korzystanie
z Load managera.
Query Manager(s) -
User Interface – Interfejs użytkownika
Data Storage Area – Skład danych
Określenie Load Manager opisuje aplikację lub zespół aplikacji
obsługujących interakcję pomiędzy użytkownikiem i Składem danych.
Te swoiste bufory maskują składowanie danych w hurtowni. Procesy
te odpowiadają za pobranie danych oraz za znalezienie optymalnego
miejsca do przechowywania indeksów tych informacji do użytku dla
przyszłych wyszukiwań.
Interfejs użytkownika to kluczowy komponent systemu
hurtowni danych, którego implementacja jest krytyczna dla sukcesu
takiego systemu. Ten interfejs musi czynić system intuicyjnym tak,
aby użytkownicy byli w stanie się go nauczyć i przy jego pomocy
podejmować decyzje.
Query Manager odpowiada za wysyłanie zapytań do Składu
danych mających zaspokoić żądania z interfejsu użytkownika.
Interakcja pomiędzy tymi podsystemami stanowi serce całego
systemu.
Szacuje się, że statystycznie tylko co druga próba wdrożenia
systemu hurtowni danych kończy się sukcesem. Takie statystyki
w połączeniu z kosztem wdrożenia profesjonalnej hurtowni na
poziomie 1 mln USD stanowią, że ryzyko niepowodzenia jest spore.
Z punktu widzenia opisywanego systemu bazodanowego,
podejście jakie prezentuje teoria hurtowni danych nie wydaje się
najlepszym rozwiązaniem. Przede wszystkim, projektowany system
ma stanowić ułatwienie pracy i dostępu do informacji w małych
jednostkach terenowych takich jak powiaty lub gminy, a w takiej skali
system nie będzie gromadził aż takiej ilości różnych informacji, aby
uzasadnione było użycie rozwiązań dla dużych firm i korporacji.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 19
1.5.7. Systemy MySQL/PostgresSQL
MySQL i PostgreSQL to dwa najbardziej rozpowszechnione
systemy bazodanowe spośród rozwiązań na licencji Open-Source na
rynku. Pierwsza zasadnicza różnica pomiędzy tymi systemami to
sposób w jaki powstają. Pierwszy jest produktem szwedzkiej firmy
MySQL AB, natomiast drugi jest tworzony przez społeczność open-
source. Skandynawski produkt znajduje zastosowanie przy małych
instalacjach i średnich, które w prosty, a szybki sposób mają
obsługiwać bazę danych, podczas gdy PostgreSQL, często
porównywany do rozwiązań Oracle znakomicie sprawdza się przy
większych projektach. PostgreSQL to osadzane języki proceduralne,
wykonywane przez bazę danych, wśród których znajdują się: Perl,
Pyton, Tcl i inne. System umożliwia ponadto tworzenie funkcji
w języku C, kompilowanych dalej do dynamicznych bibliotek.
Zarówno MySQL jak i PostgreSQL to także API do wielu języków
C/C++, Pyton, Perl oraz Java poprzez JDBC i ogólne podłączanie
poprzez sterownik ODBC. Oba systemy udostępniają dużą liczbę
typów: liczby, ciągi znakowe, obiekty binarne (ang. Binary Large
Objects, BLOB), data i czas, typy wyliczeniowe, zestawy. Co warto
zaznaczyć, w systemach bazodanowych dana kolumna może zostać
dostosowana do pewnej wielkości danych, które zamierzamy w niej
przechowywać, tym samym uzyskujemy większą wydajność
i mniejsze zużycie pamięci (również dyskowej). Przykładem może być
zastosowanie typu TINYINT zamiast INT. Oprócz tego istnieje
możliwość definiowania niektórych typów danych jako narodowych
(różne standardy kodowania na poziomie krotek).
Nowa, piąta wersja MySQL bardzo zbliża się pod względem
funkcjonalnym do rozwiązania PostgreSQLa. Obsługuje niedostępne
w poprzednich wersjach procedury składowane (ang. stored
procedures), kursory (ang. cursors), wyzwalacze (ang. triggers) oraz
perspektywy.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 20
PostgreSQL posiada mechanizm wyzwalaczy, które mogą być
przyłączane do tabel lub widoków. Wyzwalacze mogą być definiowane
w PL/pgSQL, PL/Perl, PL/Python lub PL/Tcl. W bazie
zaimplementowano obsługę wielu typów indeksów takich jak
B-drzewo, Hash, R-drzewo i GiST. Indeksy posiadają szereg nowych
możliwości, m.in. mogą powstawać jako wynik funkcji, a nie
pochodzić od wartości kolumny, mogą reprezentować część tabeli,
poprzez dodanie klauzuli WHERE podczas wykonywania zapytania
CREATE INDEX. PostgreSQL ma zaimplementowany mechanizm MVCC
(ang. Multiversion Concurrency Control) do zarządzania transakcjami.
Mechanizm ten umożliwia udostępnienie tej samej krotki więcej niż
jednej transakcji. Równocześnie może istnieć przynajmniej kilka
wersji tej samej krotki, które nie są widoczne dla innych
użytkowników do zakończenia danych transakcji. Dzięki temu baza
danych wydajnie zachowuje zasadę ACID. ACID to skrót od
angielskich słów: Atomicity - atomowość, Consistency - spójność,
Isolation - izolacja, Durability - trwałość. [Wikipedia, 2007-09-10]
Określają one warunki jakie powinny spełniać transakcje w bazach
danych.
atomowość transakcji oznacza, iż każda transakcja albo wykona
się w całości, albo zostanie anulowana.
spójność transakcji oznacza, że po wykonaniu transakcji, system
będzie spójny, czyli nie zostaną naruszone żadne zasady
integralności.
izolacja transakcji oznacza, iż jeżeli dwie transakcje wykonują się
współbieżnie, to zazwyczaj (zależnie od poziomu izolacji) nie widzą
zmian przez siebie wprowadzanych.
trwałość danych oznacza, że system potrafi uruchomić się
i udostępnić spójne i nienaruszone dane zapisane w ramach
zatwierdzonych transakcji, na przykład po nagłej awarii zasilania.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 21
Pomimo tylu dostępnych rozwiązań PostgreSQL jest systemem
w pełni zgodnym ze standardem SQL i na każdym etapie rozwoju ta
zgodność była nadrzędnym celem twórców, co przez dłuższy czas
było problematyczne dla MySQL.
1.6. Wymagania sprzętowe
Projektując system informatyczny, należy uwzględniać także
jego część sprzętową. Wynika to z faktu, że nawet najlepiej
zaprojektowana aplikacja nie będzie pracować poprawnie na źle
dobranym sprzęcie. Dodatkowo, dokonując wyboru należy brać pod
uwagę niezawodność, serwis i wsparcie techniczne dla
poszczególnych elementów systemu.
1.6.1. Propozycja konfiguracji obsługującej projektowany
system
Podstawową decyzją jaką należy podjąć przy planowaniu
budowy zestawu sprzętowego do obsługi systemu bazodanowego jest
określenie, czy komputer przeznaczony do obsługi systemu
bazodanowego będzie dedykowany, czy współdzielony z innymi
usługami takimi jak na przykład serwer HTTP (HyperText Transport
Protocol). Biorąc pod uwagę ilość informacji, jakie system będzie
przetwarzał, należy skłaniać się ku rozwiązaniu z dedykowaną
maszyną serwera baz danych. W początkowym okresie działania
systemu wystarczy pojedyncza maszyna obsługująca zapis,
wyszukiwania oraz archiwizację starszych pomiarów.
Kwestią kluczową będzie prędkość odczytu i zapisu danych na
dyskach. Najwydajniejszym rozwiązaniem byłaby macierz dyskowa
zbudowana z szybkich dysków SCSI. Rozwiązania takie stosuje się
w systemach mocno obciążonych dostępem do danych. Alternatywą
mogą być dyski konwencjonalne spięte w macierz RAID0.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 22
Rozwiązanie takie sprawdziło się w przypadku „farm serwerów”
firmy Google, której większość powierzchni dyskowej, przekraczającej
(według szacunków po opublikowaniu w lutym 2007r. raportu
dotyczącego awaryjności dysków) 20 PB (petabajtów), składa się
z „tańszych” dysków. W późniejszym okresie agregacji danych należy
rozważać przeniesienie tabel z danymi archiwalnymi na inny serwer,
najlepiej na fizycznie inną maszynę. Jeśli założymy, że nie jest
priorytetem szybki dostęp do danych archiwalnych, serwer
obsługujący te dane, nie będzie musiał spełniać tak wysokich
wymagań jak podstawowa maszyna.
Problemem, którego nie można zbagatelizować, jest kwestia
pamięci dostępnej dla serwera bazodanowego. Jeśli baza danych ma
działać sprawnie, jak najwięcej operacji powinno być wykonywane
bezpośrednio w pamięci, która ma znacznie większą prędkość
zapisu/odczytu danych niż najszybsze nawet dyski.
Do rozważenia pozostaje kwestia mocy obliczeniowej. Jest to
problem trudny do rozwiązania szacując ilość informacji. Producenci
sprzętu serwerowego nie chcą udostępniać danych dotyczących
realnego sprawowania się sprzętu przy np. obsłudze dużych baz
danych. Wydaje się jednak racjonalne twierdzenie, że
dwuprocesorowy komputer oparty o technologie Intel Core 2 Duo,
Intel Xeon, AMD Operon będzie odpowiednim rozwiązaniem.
W kwestii systemu operacyjnego rozważać można wybór
pomiędzy produktem Microsoft – Windows 2003 Server,
a OpenSurce’owym Linuxem lub jego komercyjną dystrybucją
serwerową. Otwarty system wydaje się lepszym wyborem ze względu
na mniejszą ilość problemów ze współpracą z innym
oprogramowaniem. Polityka giganta z Redmond wymusza niejako
wykorzystanie technologii i rozwiązań pochodzących od tego samego
producenta, co może znacząco utrudnić późniejsze modyfikacje,
rozbudowy i/lub integracje z innymi systemami.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 23
2. WYMAGANIA FUNKCJONALNE
2.1. Założenia projektowanego systemu
Na początku każdego procesu projektowego należy zaznajomić
się z typami danych, ich formatem, ilością, wymaganą tolerancją
błędów, sposobem gromadzenia, a przede wszystkim ze sposobem,
w jaki zgromadzone dane mają być potem udostępniane klientom.
Określenie tych założeń na samym początku procesu projektowego,
pozwala w pewnym stopniu, przewidywać problemy, jakie
rozpatrywane rozwiązanie może nieść za sobą w poszczególnych
dziedzinach. Wiedza na temat danych przechowywanych
w projektowanym systemie jest także ważna ze względu na
określenie spodziewanej poprawności danych. Dla przykładu można
podać przypadek pomiaru temperatury. Jeśli z założeń wiadomo, że
mierzona wartość określa temperaturę powietrza na wysokości
2 metrów, to przewidywany zakres temperatur, jakie można uznać za
poprawne w naszym klimacie to ok. -40C - 50C. Wartości nie
mieszczące się w tym zakresie można uznać za mało prawdopodobne
lub błędne. Natomiast wiedząc, że mierzona wartość oznacza
temperaturę oleju w silniku, zakres poprawnych wartości będzie
diametralnie różny od przedstawionego powyżej.
2.1.1. Rodzaj informacji zasilających system
W przypadku systemu gromadzenia danych z pomiarów
hydrometeorologicznych, rejestrowanych w systemie ciągłym przy
wykorzystaniu mierników cyfrowych do bazy danych trafiają dane
opisujące wartości parametrów środowiska. Są to wartości obrazujące
takie wielkości jak:
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 24
Temperatura na poziomie gruntu
Temperatura na wysokości 2m
Wilgotność powietrza
Opad
Opad wykroplenia
Suma Opadów
Ciśnienie atmosferyczne
Prędkość wiatru
Kierunek wiatru
Promieniowanie słoneczne
Strumień ciepła gruntowego
Wszystkie te wielkości mają charakter numeryczny i najlepiej
obrazowane są za pomocą zmiennoprzecinkowych typów danych.
Dodatkowo, przy każdym pomiarze konieczne jest zapisanie
informacji lokalizujących te dane na osi czasu i przypisującej je do
stacji, która te pomiary przeprowadziła. Wartości te to:
Identyfikator pomiaru – unikatowa wielkość określająca kolejny
numer pomiaru zapisanego w bazie – liczba całkowita.
Identyfikator stacji – pole identyfikujące stacje z której dany
zestaw pomiarów pochodzi – liczba całkowita.
Czas dokonania pomiaru
Czas zapisania pomiaru w systemie
2.1.2. Format gromadzonych danych
Dane pomiarowe reprezentują wielkości parametrów
środowiska. A więc konieczna jest możliwość zapisu wartości
z dokładnością do kilku miejsc po przecinku. Istnieje kilka możliwości
realizacji systemu bazodanowego dla dużej ilości danych.
Podstawowym sposobem jest gromadzenie danych w formacie
zmiennoprzecinkowym. Format ten jest najprostszą reprezentacją
rzeczywistych wartości parametrów środowiska.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 25
Zaletą takiego rozwiązania jest brak konieczności przetwarzania
danych, w celu „odzyskania” rzeczywistych wartości, przed
udostępnieniem ich klientowi. Za wadę można uznać znaczne (około
dwukrotne) zwiększenie objętości bazy przy przechowywaniu wartości
zmiennoprzecinkowych w stosunku do bazy trzymającej dane jako
liczby całkowite.
Drugą możliwością jest zapis informacji w formacie liczb
całkowitych. Rozwiązanie takie wymaga dodatkowego
przechowywania informacji o sposobie odzyskania wartości
oryginalnej. Informacją taką jest mnożnik, czyli liczba przez jaką
wartość zapisaną należy podzielić aby otrzymać rzeczywistą wartość
parametru. Zaletą takiego rozwiązania jest oszczędność na objętości
bazy danych, niestety niesie ono ze sobą konieczność dodatkowego
przetwarzania wydobytych z bazy danych lub przekazania klientowi
informacji, jak takie dane przetworzyć.
Trzecim rozwiązaniem, przeznaczonym głównie do
archiwizowania danych pochodzących ze starszych pomiarów, jest
zapis wartości jako tekst o określonej długości, z określonym
sposobem wydzielania danych. Rozwiązanie takie sprawdza się przy
zapisie danych, do których nie ma wymogu natychmiastowego
dostępu. Znacząco zwiększa ono czas dostępu do informacji, ale
pozwala utrzymać prostą strukturę bazy danych archiwalnych.
2.1.3. Przewidywana ilość danych zasilająca system
Przewiduje się, że na standardowym obsługiwanym przez
system obszarze będzie funkcjonowało od 5 do 50 stacji
pomiarowych, rejestrujących maksymalnie 20 różnych parametrów
środowiska każda. Tabela 6. obrazuje ile wartości pomiarów będzie
trzeba przechować w bazie po upływie zadanego czasu.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 26
510
50100
200500
1
30
365
1825
3650
0
1 000 000 000
2 000 000 000
3 000 000 000
4 000 000 000
5 000 000 000
6 000 000 000
ilo
ść p
om
iaró
w
liczba stacji
czas
po
mia
rów
[d
ni]
Rys. 1 Przyrost liczby gromadzonych pomiarów w czasie dla założonej liczby stacji.
Tabela 6. Liczba pomiarów w zależności od ilości stacji i czasu działania systemu
Czas gromadzenia pomiarów Liczba stacji 10
minut 1
godzina 1 dzień 1 miesiąc 1 rok 5 lat 10 lat
1 20 120 2 880 86 400 1 036 800 5 184 000 10 368 000 2 40 240 5 760 172 800 2 073 600 10 368 000 20 736 000 5 100 600 14 400 432 000 5 184 000 25 920 000 51 840 000 10 200 1 200 28 800 864 000 10 368 000 51 840 000 103 680 000 50 1 000 6 000 144 000 4 320 000 51 840 000 259 200 000 518 400 000
100 2 000 12 000 288 000 8 640 000 103 680 000 518 400 000 1 036 800 000 200 4 000 24 000 576 000 17 280 000 207 360 000 1 036 800 000 2 073 600 000 500 10 000 60 000 1 440 000 43 200 000 518 400 000 2 592 000 000 5 184 000 000
Tabela 7. Pokazuje jaka może być różnica pomiędzy objętością
bazy przy zapisie danych za pomocą pól typu zmienno przecinkowych
a liczb całkowitych. W przypadku projektowanego systemu użyty
zostanie typ zmienno przecinkowy. Wybór ten zagwarantuje, że czasy
uzyskiwane z uruchamiania kwerend testowych nie będą
zniekształcone konwersją z liczb całkowitych na zmiennoprzecinkowe.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 27
Tabela 7. Objętość pomiarów w zależności od typu danych i okresu działania systemu.
Czas gromadzenia pomiarów Typ
zapisu 10
minut [MB]
1 godzina
[MB] 1 dzień
[MB] 1 miesiąc
[MB] 1 rok [MB]
5 lat [MB]
10 lat [MB]
Double 0,08000 0,48000 11,52000 345,60000 4 147,20000 20 736,00000 41 472,00000 Integer 0,04000 0,24000 5,76000 172,80000 2 073,60000 10 368,00000 20 736,00000
2.1.4. Możliwe sposoby dostępu do danych
Projektowany system zakłada możliwość szybkiego dostępu do
najnowszych danych. Długość czasu, z jakiego dane powinny być
dostępne na bieżąco, należy ustalić indywidualnie dla każdej
implementacji systemu.
Podział na informację bieżącą i archiwalną określa pośrednio
sposób dostępu do informacji. Dzięki rozdzieleniu danych nowych od
starszych zyskujemy na szybkości przeszukiwania tych pierwszych.
Archiwizacja niesie za sobą jednak spadek dostępności danych
archiwalnych. Czas oczekiwania na starsze dane może być dłuższy ze
względu na konieczność odzyskania informacji z archiwum, jak i na
fakt, że żądania danych bieżących powinny mieć pierwszeństwo.
Możliwe są 3 sposoby skorzystania z danych zgromadzonych
w systemie:
Bezpośredni dostęp do bazy danych – ze względu na kwestie
bezpieczeństwa, trudności merytorycznych związanych z obsługą
Systemu Zarządzania Relacyjną Bazą Danych (RDBMS), problemami
z wygodnym eksportowaniem danych, sposób ten nie powinien być
rozważany w kontekście innym niż wykonanie czynności
administracyjno konserwacyjnych.
Interfejs WWW poprzez stronę internetową – Bardzo
rozpowszechniony i wygodny sposób na realizację zadań z zakresu
udostępniania danych klientom. Jego podstawową zaletą jest brak
konieczności instalacji dodatkowego oprogramowania na komputerze
klienta / użytkownika.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 28
Dodatkowym atutem jest fakt, że dobrze zaprojektowany
interfejs może dawać ogromne możliwości w zakresie formatowania
prezentowanych danych, ograniczania dostępu do wybranych części
informacji, kontroli tożsamości osób próbujących skorzystać
z zasobów systemu, a także monitorowania czynności wykonywanych
przez osoby korzystające z systemu. Sporą zaletą jest także swoboda
modyfikacji i usprawnień. Aby dodać nową funkcjonalność wystarczy
zmodyfikować kod na serwerze WWW i wszyscy klienci natychmiast
mają dostęp do nowych możliwości. Wadą takiego rozwiązania jest
niewątpliwie większe zapotrzebowanie na zasoby sprzętowe serwera.
Wynika to z faktu, że aby dostarczyć klientowi możliwość korzystania
z systemu bazodanowego za pośrednictwem interfejsu WWW,
konieczne jest uruchomienie dodatkowej usługi, obsługującej
generowanie stron z danymi poszukiwanymi przez klientów. Jeśli
rozważamy przypadek, gdzie z systemu ma korzystać bardzo
ograniczona liczba klientów, zagadnienie to nie stanowi problemu,
gdyż usługę taką może z powodzeniem udostępniać ten sam serwer,
który obsługuje samą bazę. Gdy jednak w planach pojawi się większa
ilość osób korzystających z systemu, może się okazać konieczne
zastosowanie komputerów dedykowanych usługom WWW.
Aplikacja systemowa – rozwiązanie eliminujące problem
dodatkowych zasobów potrzebnych na udostępnianie użytkownikom
interfejsu dostępowego. Aplikację taką klient instaluje na swoim
komputerze i za jej pomocą korzysta z zasobów systemu
bazodanowego. Dzięki takiemu rozwiązaniu można uniknąć
problemów z zabezpieczeniami serwerów WWW, które są często
podstawowym punktem ataków ze strony osób starających się
uzyskać nieautoryzowany dostęp do informacji chronionej. Kolejnym
plusem na rzecz takiego rozwiązania jest korzyść wynikająca
z przeprowadzania obliczeń (jeśli takie są konieczne aby
zaprezentować klientowi poszukiwaną przez niego informacje)
bezpośrednio na komputerze klienta.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 29
Pozwala to znacząco odciążyć serwery zajmujące się obsługą
systemu. Wadą takiego rozwiązania jest niewątpliwie problem
z wprowadzaniem nowych wersji oprogramowania. Operacja taka
wymaga zainstalowania poprawki lub całego programu na każdym
z komputerów klienckich. Sytuacja taka, gdy klient musi co pewien
czas instalować nowe oprogramowanie, może być odbierana przez
klientów jako niepotrzebna strata czasu.
2.2. Funkcje podstawowe
2.2.1. Gromadzenie danych z systemu czujników
Podstawową funkcją projektowanego systemu jest gromadzenie
danych spływających z czujników. Ze względu na przewidywaną
częstotliwość z jaką poszczególne czujniki będą wysyłały
zgromadzone informacje, ta część funkcjonalności stanowi kluczowy
punkt systemu. W systemach bazodanowych zapis informacji jest
jedną z najszybszych operacji. Szczególnie, jeśli zapis
przeprowadzany jest bezpośrednio do jednej tabeli. Należy jednak
pamiętać, że projektowany system powinien umożliwiać w łatwy
sposób implementacje rozwiązań walidujących zapisywane dane.
2.2.2. Archiwizacja danych w dłuższym horyzoncie czasowym
W systemach gromadzących duże ilości danych, z czasem
pojawia się problem zarządzania posiadanymi danymi. Na przykład
operacje wyszukiwania stają się znacznie wolniejsze przy bardzo
dużych tabelach. W związku z takim niepożądanym efektem, należy
zaplanować, w jaki sposób magazynować dane pochodzące z bardziej
odległej przeszłości. Przeniesienie starszych danych do innej tabeli,
nazywanej „tabela archiwalną” pozwoli odciążyć tabelę do której
odbywa się zapis. Rozwiązanie takie pociąga za sobą szereg
konsekwencji.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 30
Między innymi, jest to możliwość dłuższego oczekiwania na
niektóre zestawy danych, poszukiwane przez użytkowników, co
wynika bezpośrednio z konieczności przeglądania dodatkowej tabeli
(archiwalnej), w której może zostać użyty inny format zapisu danych.
Pozytywnym efektem będzie sprawniejsze obsługiwanie kwerend
poszukujących danych najnowszych – wprost z tabeli gromadzącej
pomiary z czujników.
2.2.3. Umożliwienie klientom dostępu do danych
Do tej pory opisano jedynie część funkcjonalności
odpowiedzialną za gromadzenie i zapis danych. Jednak samo
gromadzenie danych nie jest celowe, jeśli nie ma możliwości
sprawnego wykorzystania zapisanej informacji. W związku z tym
faktem, projektowany system musi umożliwiać klientom łatwy dostęp
do poszukiwanej informacji. Ze względu na dużą różnorodność
gromadzonych danych (temperatura, opad i wiele innych) istnieje
ogromna ilość przypadków w jakich może istnieć zapotrzebowanie na
dostęp to informacji. System powinien wychodzić naprzeciw
oczekiwaniom i umożliwiać dostęp do każdego poszukiwanego
podzbioru informacji. Ponieważ rodzaj przechowywanych danych,
pomimo ich różnorodności, jest stały – parametry
hydrometeorologiczne – można wyznaczyć listę najczęściej
poszukiwanych zestawów danych. Zestawy takie nazywane dalej
„scenariuszami testowymi” reprezentują najczęściej wykonywane
kwerendy lub zestawy kwerend. Zakres scenariuszy standardowych
na potrzeby tej pracy zostanie ustalony odgórnie i przetestowany
indywidualnie na każdej propozycji schematu bazodanowego.
Podejście takie pozwoli porównać poszczególne propozycje pod kątem
wydajności obsługi scenariuszy standardowych.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 31
2.3. Propozycje rozszerzeń funkcjonalności
2.3.1. Zapis danych, a detekcja błędów
Dane zasilające system mogą ulegać zniekształceniom
powodowanym błędami przesyłu lub błędami pomiaru (uszkodzenie
czujnika, złe wyskalowanie). Należy rozważyć możliwości takiego
zaprojektowania systemu, aby automatycznie zminimalizować wpływ
danych błędnych na całość posiadanej informacji. Jeżeli możliwe jest
wychwycenie części błędnych danych jeszcze przed zapisem
i oznaczenie ich odpowiednio to wynik zapytania, jaki trafi do klienta
w odpowiedzi, będzie bardziej wiarygodny i nie będzie wymagał
dodatkowych zabiegów sprawdzających poprawność danych.
Najprostszym sposobem detekcji błędów jest określenie
„z góry” ograniczeń wprowadzanych wartości. Ustawione wartości
dolnego i górnego ograniczenia pozwalają zaimplementować system
stosunkowo prostych reguł, na podstawie których pomiar może zostać
oznaczony jako błędny. Oznaczenie takie pozwoli pominąć go podczas
wyszukiwania danych dla klientów.
Do określenia stopnia poprawności danych można użyć prostych
reguł jak:
weryfikacja czasu pomiaru i czasu odebrania zestawu danych
weryfikacja poprawności napływających danych.
Obie te reguły składają się na prosty mechanizm weryfikacji
napływających informacji. Ma on na celu zapewnić, że dane
przechowywane w systemie są, z dużym prawdopodobieństwem,
poprawne.
Pierwsza z nich sprawdza czy czas dokonania pomiaru nie jest
późniejszy lub równy czasowi odebrania zestawu przez system
bazodanowy. Jeśli tak jest można stwierdzić, że dane
najprawdopodobniej zostały źle zakodowane do wysłania lub
niepoprawnie rozkodowane po odebraniu.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 32
Jeśli zostanie wykryta taka sytuacja, można odrzucić cały
zestaw danych lub sprawdzać pojedyncze wartości czy odpowiadają
ogólnemu trendowi dla poszczególnych grup danych.
Zagadnienie detekcji błędów może zostać umieszczone poza
samą bazą danych, w oprogramowaniu obsługującym system
bazodanowy. W przypadku tego opracowania takie założenie pozwoli
uniknąć dodatkowego narzutu czasu, spowodowanego sprawdzaniem
poprawności zapisywanych danych.
2.3.2. Wykorzystanie logiki rozmytej w detekcji błędów
Napływające dane można weryfikować za pomocą narzędzi
takich jak teoria zbiorów rozmytych. Ta, sformułowana w 1995 roku
teoria, zmienia tradycyjne podejście do teorii zbiorów, w którym to,
czy dany element należy do zbioru określają dwa stany – należy i nie
należy. W teorii zbiorów rozmytych określa się nie tylko to, czy
element należy do zbioru, ale także w jakim stopniu. Odbywa się to
za pomocą przypisania elementowi liczby z zakresu [0,1], gdzie
0 oznacza, że element nie należy do zbioru, a 1, że jest w 100%
częścią zbioru. Zbiorem rozmytym nazywa się taki zbiór, którego
wszystkie elementy mają przypisaną wartość przynależności. Wartość
ta w teorii nazywa się „funkcją przynależności”. Z punktu widzenia
weryfikacji danych, najciekawsze w teorii zbiorów rozmytych jest
podejście lingwistyczne. Zmiennej lingwistycznej, w przeciwieństwie
do tradycyjnej zmiennej, przyporządkowuje się nie liczby a wartości
lingwistyczne, takie jak dobry, zielony. Te zaś reprezentują
odpowiednie zbiory rozmyte. Koncepcja zmiennych lingwistycznych
jest zaczerpnięta ze sposobu, w jaki mózg człowieka radzi sobie
z cechami, które mają wartość ciągłą. Posługując się zmiennymi
lingwistycznymi, przyjmującymi jedną z 9 wartości, człowiek jest
w stanie prowadzić samochód a nawet samolot [Czasopismo „Professional
Programming Software for SAP DB” - artykuł “Zbiory rozmyte”, grudzień 2004].
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 33
Konstruowanie zmiennych lingwistycznych, które będą łatwe do
interpretowania, nie jest jednak sprawą prostą i wymaga spełnienia
poniższych wymogów:
Rozróżnialność – każda wartość lingwistyczna powinna mieć
znaczenie semantyczne, a jej zbiór rozmyty musi się dać łatwo
rozróżnić od innych zbiorów rozmytych,
Odpowiednia liczba elementów – liczebność przestrzeni
lingwistycznej zmiennej powinna być zgodna z liczbą etykiet
tworzonych przez człowieka do opisu zmiennej (około 5-7),
Kompleksowe pokrycie – zmienna lingwistyczna powinna
zapewniać pokrycie całej przestrzeni rozważań,
Normalizacja zbiorów – każdy zbiór rozmyty powiązany
z wartością lingwistyczną powinien być zbiorem normalnym, tzn.
musi istnieć, co najmniej jeden element o wartości funkcji
przynależności równej 1.
Korzystając z powyższej wiedzy można wyznaczyć zmienną
lingwistyczną określającą prawdopodobieństwo poprawności
testowanego pomiaru. W przypadku oznaczania zbioru danych można
posłużyć się etykietami: nieprawdopodobna, mało prawdopodobna,
prawdopodobna, bardzo prawdopodobna, pewna. Takie rozbicie
pozwala prowadzić bardzo zróżnicowane analizy posiadanych danych.
Można wyobrazić sobie sytuację, gdy wyszukuje się dane do analizy
opadów lub zmian temperatury na zadanym terenie. Przy takich
badaniach klient będzie zainteresowany tylko danymi o wysokim
prawdopodobieństwie poprawności. Z drugiej strony, można
wyszukiwać stacje, których czujniki wymagają przeglądu lub kalibracji
– wystarczy wyszukać stacje z największą ilością pomiarów
oznaczonych jako nieprawdopodobne i lub mało prawdopodobne.
Dodatkowym atutem takiego rozwiązania jest łatwość podejmowania
decyzji co do kwestii, czy dana informacja kwalifikuje się do
archiwizacji. Nie wydaje się rozsądne archiwizowanie danych
wątpliwej jakości.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 34
Implementacja takiego rozwiązania nie nastręcza większych
problemów, poza podjęciem decyzji, czy logika ma zostać
zaimplementowana w bazie, czy zaszyta w aplikacji obsługującej
system bazodanowy. Ze względu na możliwość tworzenia procedur
w nowych wersjach systemów zarządzania bazami danych , wydaje
się rozsądne zapisanie logiki w bazie danych. Jedna z możliwości
implementacji to utworzenie tabeli z zapisem przedziałów
określających zakresy prawdopodobnych wyników pomiaru. Można
zastosować jednakową funkcję przynależności dla wszystkich
pomiarów, lub wprowadzić możliwość przyporządkowania różnych
funkcji dla różnych typów pomiarów.
2.3.3. Określanie właścicieli przechowywanych pomiarów
W systemach gromadzących duże ilości danych, potencjalnie
z różnych źródeł, pojawia się problem określania, kto jest
właścicielem danych. Jeśli rozważamy sytuację, w której dane mogą
być zapisywane z wielu źródeł, może zdarzyć się tak, że poszczególne
stacje czujnikowe mają różnych właścicieli, a w związku z tym, dane
także są objęte różnymi prawami własności. W takiej sytuacji należy
znaleźć rozwiązanie pozwalające w prosty sposób rozróżniać do kogo
należą dane. Najprostsza implementacja to przypisanie właścicieli do
poszczególnych stacji i określanie praw do danych po numerze stacji
z której konkretne informacje pochodzą.
2.3.4. Obsługa różnych poziomów użytkowników
Z aplikacji bazodanowych korzysta z reguły całe grono
użytkowników. Najczęściej są oni podzieleni na grupy ze względu na
pełnione funkcje w systemie. Grupami, jakie można wyszczególnić
w praktycznie każdym systemie, są administratorzy i użytkownicy.
Grupy te różnią się poziomem uprawnień i zakresem obowiązków.
Administratorzy odpowiadają za utrzymanie serwisu w stanie
umożliwiającym klientom bezproblemową pracę.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 35
Najczęściej administratorzy posiadają uprawnienia zwykłych
użytkowników, wzbogacone o dodatkowe możliwości. Przydzielony
wachlarz uprawnień umożliwia administratorom pomoc
użytkownikom, wprowadzanie poprawek do oprogramowania
aplikacji, dbanie o bezproblemowy dostęp do aplikacji. Użytkowników
nie interesują zagadnienia utrzymania aplikacji w ruchu – dla nich
jest ona narzędziem pracy, źródłem niezbędnych informacji. Grupa
użytkowników może dzielić się dodatkowo na podgrupy z dodatkowo
wyspecjalizowanymi uprawnieniami. Projektowane rozszerzenie
funkcjonalności systemu powinno spełniać wymogi bezpiecznego
rozdzielenia funkcji korzystających z niego grup użytkowników oraz
umożliwiać jak najprostszą i przeźroczystą pracę administratorów.
Przez termin przeźroczysta praca, należy rozumieć możliwość
wykonywania zadań konserwacyjnych w sposób niezauważalny dla
użytkowników lub przynajmniej nie uniemożliwiający lub utrudniający
im pracy.
2.3.5. Automatyczne powiadomienia
W dużych systemach, przechowujących ogromne ilości
informacji, użytkownicy często mają problem z wychwyceniem
nowych danych z interesującego ich zakresu. Dotyczy to zwłaszcza
sytuacji, gdy użytkownik zainteresowany jest wychwyceniem zmiany
w cyklicznie zapisywanych danych. Przykładem może być sytuacja
monitorowania poziomu wód w rzekach na zadanym obszarze. Osoba,
zajmująca się takim zagadnieniem, będzie zainteresowana
wychwyceniem nagłego podniesienia się poziomu wody. W celu
rozwiązania takiego problemu można zaimplementować system
indywidualnego i konfigurowalnego monitoringu napływających
danych. Po wykryciu, że dane układają się we wzorzec zdefiniowany
w filtrze użytkownika, system może wysyłać powiadomienia
dostępnymi kanałami. W powszechnym zastosowaniu do takich celów
używane są takie kanały komunikacyjne jak:
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 36
sieci komórkowe – wiadomości SMS
komunikatory internetowe – Gadu Gadu, Jabber, AIM, ICQ itp.
Najłatwiejszy do zaimplementowania jest system powiadomień
wysyłanych na email użytkownika. Ma on niestety podstawową wadę
– powiadomienie zostanie odebrane, gdy użytkownik sprawdzi swoją
skrzynkę pocztową lub jeśli ma włączony program monitorujący
pocztę. Więcej pracy jest z komunikatorami internetowymi, które
jednak dają większe szanse dotarcia do użytkownika – komunikatory
internetowe z reguły są włączane wraz z komputerem i oczekują na
nadejście wiadomości. Systemem wymagającym najwięcej pracy jest
obsługa wysyłania wiadomości SMS bezpośrednio na telefon
użytkownika. Rozwiązanie to, pozwala dotrzeć do użytkownika nawet
jeśli ma on wyłączony komputer lub aktualnie nie znajduje się w jego
bezpośrednim otoczeniu.
2.3.6. Synchronizacja z bazami „zaprzyjaźnionymi”
Zagadnienie to umożliwia łatwą wymianę danych pomiędzy
systemami przechowującymi podobne dane, ale z innych źródeł.
Można wyszczególnić dwie podstawowe metody realizacji takiego
rozwiązania. Pierwsza, gdzie dane pomiędzy systemami są okresowo
synchronizowane i druga, w której nie przesyła się całości danych
pomiędzy bazami, a jedynie, na żądanie klienta, jedna baza odpytuje
drugą o dane jakich może jej brakować. Pierwsze z rozwiązań daje
dodatkowy plus w postaci tworzenia dodatkowej kopii danych
w drugim systemie, niestety sporym minusem jest ogromna ilość
danych przesyłana pomiędzy tymi systemami. Drugi system nie
generuje takiego ruchu na łączach, ale może powodować opóźnienia
w pozyskiwaniu danych podczas wyszukiwania dla klienta.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 37
2.3.7. Obsługa płatnego dostępu do danych
Dodatkową funkcjonalnością, o jaką można wzbogacić system,
jest odsprzedaż danych osobom i organizacjom trzecim. Projektując
takie rozwiązanie należy najpierw zaimplementować system
użytkowników, ze względu na konieczność określenia praw własności
dla konkretnych danych. Po określeniu grupy właścicieli
i zgromadzeniu danych tych osób / instytucji potrzebnych do
zrealizowania transakcji należy zaplanować jak ma wyglądać system
sprzedaży, w których jego miejscach można wprowadzić promocje,
rabaty i jak będą przechowywane dane. Dodatkowo można skorzystać
z usług takich pośredników jak np. PayPal.
2.3.8. System monitorowania danych w czasie rzeczywistym
Jako ostatni przykład możliwości rozbudowy systemu
bazodanowego przedstawiony zostanie projekt monitoringu danych,
w czasie rzeczywistym, już na wejściu do systemu. Takie podejście
daje użytkownikom możliwości śledzenia zmian danych natychmiast
po ich odnotowaniu w systemie. Dodatkową zaletą jest fakt, że taki
system nie powodowałby dodatkowego obciążenia bazy danych
kwerendami wyciągającymi dane. W założeniu wyświetlane byłyby
dane tuż przed zapisem i odświeżane natychmiast w momencie
odnotowania nowej wartości danego parametru. Systemy takie
działają z powodzeniem w innych branżach, między innymi
w bankowości, gdzie wykorzystuje się takie rozwiązania do
monitorowania rynków finansowych. Ich podstawowym zadaniem jest
dostarczenie użytkownikowi informacji o zmianach cen i wartości
aktywów. Najnowsze implementacje umożliwiają także
poszczególnym użytkownikom zdefiniowanie jakie informacje
i w jakiej formie mają być im prezentowane. W przypadku danych
hydrometeorologicznych, analogiczna funkcjonalność mogłaby zostać
zaimplementowana do monitorowania czynników środowiskowych.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 38
Użytkownicy mieliby do dyspozycji cały wachlarz funkcji
udostępnianych przez takie systemy. Między innymi mogłoby to być:
przeglądanie danych spływających do systemu w czasie
rzeczywistym
wyświetlanie historii poszczególnych parametrów
możliwość dokładnego określenia pochodzenia danych
oglądanie zmian w postaci wykresów
indywidualne konfiguracje prezentacji danych
Rozwiązanie takie może bazować na architekturze
klient-serwer, czyli asymetrycznej architekturze oprogramowania,
umożliwiającej rozdzielenie pewnych funkcjonalności, w celu
zwiększenia elastyczności i ułatwienia wprowadzania zmian w każdej
z części systemu. Polega to na ustaleniu, że serwer zapewnia usługi
dla klientów, którzy mogą komunikować się z serwerem wysyłając
żądanie (request). Podstawowe i najczęściej używane serwery to:
serwer pocztowy, serwer WWW, serwer plików, serwer aplikacji.
Z usług jednego serwera może zazwyczaj korzystać wielu klientów.
W takim przypadku, serwer byłby odpowiedzialny za przechwytywanie
informacji na drodze do systemu bazodanowego, przeprowadzenie
wstępnej walidacji i rozesłanie w zestandaryzowanym formacie, na
przykład XML, do klientów. Ten typ rozwiązania sprawdzi się
doskonale, jeśli zakładamy, że serwer proponowanego rozwiązania
zostanie umieszczony na tej samej maszynie co oprogramowanie
zapisujące dane do systemu bazodanowego. Jeśli z jakiegoś powodu
nie jest to możliwe, można taki system rozszerzyć o dodatkowy
poziom aplikacji tzw. „Backend Server”. Jego zadaniem jest
przechwytywanie danych napływających do systemu, podobnie jak
w przypadku serwera aplikacji, ale w tym przypadku nie wysyła on
danych do klientów, tylko za pomocą przyjętego protokołu rozsyła je
po sieci tak, aby mogły one być odebrane przez faktyczny serwer
aplikacji.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 39
Protokołem używanym w takim przypadku może stać się na
przykład Tibco Rendezvous1 . Dane po takiej początkowej obróbce,
i przesłaniu do aplikacji klienckich zasilają odpowiednie części
interfejsu użytkownika. Projektując taki interfejs należy zwrócić
uwagę na wybór sposobu implementacji. Jeśli jako podstawową
platformę wybrana zostanie opcja np. biblioteki MFC (Microsoft
Foundation Class), czyli opcja dostarczania osobnego pakietu
klienckiego napisanego pod wybrany system operacyjny, należy
rozważyć jakie systemy operacyjne będą musiały być obsługiwane.
Jeśli podjęta zostanie decyzja o implementacji w środowisku
webowym, za pomocą technologii takich jak Java Enterprise Edition,
Spring MVC i JavaScript, trzeba brać pod uwagę konieczność
zwrócenia większej uwagi na kwestie optymalizacji działania aplikacji.
Wynika to z faktu, że interfejsy webowe napisane w JavaScript bazują
w dużej mierze na możliwościach przeglądarek, w jakich zostają
uruchamiane. Te z kolei, nie charakteryzują się wysoką wydajnością
obsługi skomplikowanych skryptów JavaScript. Nie jest to także
bezpośrednio uzależnione od klasy użytego procesora – np. Internet
Explorer 6 nadal wykorzystuje tylko jeden rdzeń niezależnie od
zastosowanego procesora.
2.4. PROPOZYCJE ZWIĘKSZENIA WYDAJNOŚCI
2.4.1. Mechanizm cacheingu
Cache (pamięć podręczna nazywana także buforem) to
mechanizm, w którym ostatnio pobierane dane dostępne ze źródła
o długim czasie dostępu (tzw. wysokiej latencji) i niższej
przepustowości są przechowywane w pamięci o lepszych
parametrach. Cache jest elementem właściwie wszystkich systemów.
1 Więcej informacji na stronie producenta: http://www.tibco.com/software/messaging/rendezvous/default.jsp
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 40
Przykładem może być współczesny procesor, który ma 2 albo
3 poziomy pamięci cache oddzielającej go od pamięci RAM. Innym
przykładem jest dostęp do dysku, który jest buforowany w pamięci
RAM. Przykładem najbliższym użytkownikom współczesnych
komputerów jest cache buforujący strony WWW otwierane
w przeglądarce. Strony internetowe mogą być buforowane zarówno
przez samą przeglądarkę, jak i na zupełnie niezależnych serwerach
nazywanych serwerami Proxy. Na bardzo podobnej zasadzie działa
wewnętrzny cache bazy danych, który gromadzi wyniki ostatnio
wykonanych zapytań w osobnej tabeli. Systemy te są tak wydajne
dzięki lokalności odwołań - jeśli nastąpiło odwołanie do pewnych
danych, jest duża szansa, że w najbliższej przyszłości będą one
potrzebne ponownie. Niektóre systemy buforujące próbują
przewidywać, które dane będą potrzebne i pobierają je wyprzedzając
żądania.
Mechanizm buforowania może być realizowany na różne
sposoby. Praktycznie w każdym przypadku istnieje możliwość wyboru
pośród kilku sposobów wdrożenia takiego rozwiązania. W przypadku
systemów opartych o technologie bazodanowe, w większości
przypadków wewnętrzny cache bazy danych pozostaje włączony
w znaczącym stopniu ograniczając czas potrzebny na dwukrotne
wyszukanie tego samego zestawu danych.
W projektowanym systemie przewiduje się możliwość
późniejszego wzbogacenia jego funkcjonalności o rozwiązania
buforujące, umieszczone poza bazą danych. Czyli wprowadzenie
kolejnego poziomu tego rozwiązania. Projekt przewiduje dwie
możliwości wdrożenia rozwiązań buforujących. Mogą one zostać
wprowadzone niezależnie, gdy zostanie wybrane tylko jedno z nich,
a mogą także występować jednocześnie.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 41
2.4.2. Rozwiązanie softwarowe – AdoDB
AdoDb, czyli Active Data Objects Data Base, to zestaw bibliotek
i klas, które standaryzują funkcje obsługi baz danych języka PHP.
Jego podstawowym założeniem jest ukrycie różnic pomiędzy różnymi
systemami bazodanowymi i udostępnienie prostych i jednolitych
funkcji wykonywania zapytań bazodanowych. Dodatkowym atutem
jest fakt, że zmiana systemu RDBMS obsługującego system
wykorzystujący ADOdb, będzie wymagała minimalnych zmian
w kodzie źródłowym. Inne unikatowe funkcje ADOdb to:
Łatwy do zrozumienia dla programistów Windows.
Udostępnia kod do obsługi zapisu nowych i aktualizacji rekordów,
który może być w łatwy sposób zaadoptowany do współpracy
z innym systemem bazodanowym.
Wbudowano w niego system „metatypów”, co umożliwia
przezroczyste konwertowanie takich typów jak CHAR, TEXT,
STRING do ekwiwalentów na różnych systemach RDBMS.
Jest łatwy do przeniesienia pomiędzy systemami, dzięki
wyodrębnieniu funkcji obsługi bazy danych. Wystarczy zmienić
wartość zmiennej konfigurującej.
Zastosowanie ADOdb do dodatkowego buforowania zwracanych
wyników z bazy danych ma zastosowanie, gdy system jest obciążony
interakcja z wieloma użytkownikami, którzy mają zbliżone potrzeby
w kwestii poszukiwanych informacji. Jest to rozwiązanie działające
poza samym systemem bazodanowym co uniezależnia go np. od
skonfigurowanego na danym serwerze limitu pamięci przeznaczonego
na cache kwerend. W tym przypadku, buforowanie określa się
długością trwania, standardowo 60 minut, a nie jak w np. w MySQL
objętością tabeli buforującej.
Niewątpliwą zaletą tego rozwiązania jest jego cena. Ponieważ
ADOdb rozpowszechniane jest na licencji BSD, więc może być
wykorzystywane nieodpłatnie także w projektach komercyjnych.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 42
Wadą jest konieczność specyficznej implementacji kodu
systemu obsługującego bazę danych. Zaimplementowanie tego
rozwiązania do istniejącego systemu, szczególnie napisanego
proceduralnie, może się okazać bardzo kosztowne.
2.4.3. Wydzielenie wyspecjalizowanych serwerów
Rozwiązanie to polega na rozdzieleniu systemu na kilka
serwerów i określeniu konkretnych zadań dla każdego z nich.
Konkretnych implementacji takiego systemu rozproszonego może być
wiele i byłoby bardzo trudne określenie, który z nich byłby najlepszy.
Należałoby przeprowadzić serie testów na wybranych konfiguracjach
i wyznaczyć maksimum wydajności przy minimalnych kosztach.
Najprostszą konfiguracją byłby system złożony z dwóch
maszyn. Jedna odpowiedzialna tylko za gromadzenie danych, a druga
obsługująca interfejs użytkownika i korzystająca z odrębnej bazy
danych. Baza ta, byłaby okresowo synchronizowana z bazą maszyny
gromadzącej nowe dane. Założenie do implementacji takiego
rozwiązania mówi, że niewielka zwłoka w aktualizacji danych
dostępnych dla klientów nie powoduje problemów w ich pracy.
Ponieważ projektowany system może być wykorzystywany do
określania aktualnej sytuacji powodziowej na zadanym terenie musi
istnieć sposób na pozyskiwanie danych w czasie rzeczywistym.
Problem ten można rozwiązać implementując różne poziomy
użytkowników, gdzie ci odpowiedzialni za prognozowanie
ewentualnych niebezpieczeństw mają dane pobierane bezpośrednio
z serwera gromadzącego dane. Innego rozwiązania wymaga
przypadek, gdy zakładamy, że wszyscy pracownicy klienta mają mieć
dostęp do najnowszych danych, a jedynie, dane serwowane za
pośrednictwem strony internetowej dla osób z zewnątrz, są
opóźnione. Przypadek ten można zaimplementować obciążając Server
gromadzący dane obsługą interfejsu dla pracowników, a druga
maszyna może służyć za serwer obsługujący ruch z Internetu.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 43
2.4.4. System rozproszony
Rozwiązanie to zakłada rozbudowę systemu. Chodzi
o przypadek, gdy sieć czujników rozrasta się poza jeden powiat lub
liczba stacji pomiarowych wzrasta powyżej założonego maksimum
i ruch w sieci zaczyna być niemożliwy do obsłużenia przez pojedynczą
bazę danych. W takiej sytuacji należy rozważyć możliwość
rozproszenia systemu gromadzenia danych na więcej niż jedną
maszynę. Planując taka operację należy zastanowić się, jak ważna
będzie możliwość dostępu do całości danych na bieżąco. Zakłada się,
że nie będzie to bardzo częsty przypadek i można zaakceptować nieco
wydłużony czas poszukiwania informacji z wielu serwerów. Jeśli
podjęta zostanie decyzja o wprowadzeniu w życie takiego
scenariusza, należy odpowiednio przygotować infrastrukturę
serwerową. Należy wytyczyć, gdzie umieszczony zostanie główny
serwer bazodanowy, a gdzie pozostawione będą serwery buforujące
bieżące dane. Proponowane rozwiązanie powinno zakładać okresową
synchronizację baz buforujących z bazą główną. Ma to na celu
umożliwienie łatwego wyszukiwania po całości informacji.
Synchronizacja taka powinna odbywać się raz na dobę. Najlepiej
w godzinach minimalnego obciążenia systemu ze strony
użytkowników. W efekcie powstania takiego systemu otrzymamy kilka
możliwości pracy z danymi. Jeśli użytkownik z góry określi, na danych
z jakiego obszaru będzie pracował, można automatycznie przełączyć
go na bazę obsługującą dany region.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 44
3. PROJEKTOWANE PROPOZYCJE ROZWIĄZAŃ
3.1. Dane zapisane w jednej tabeli
Najprostsza propozycja rozwiązania kandydującego, mająca
spełniać większość wymogów stawianych przed projektowanym
systemem. Została ona utworzona przy założeniu, że wszystkie dane,
które gromadzone są w systemie, stanowią integralną całość. Wynika
to z faktu, że dla klientów np. dane opadu lub temperatury nie mają
wartości jeśli nie są odniesione do konkretnej lokalizacji. Schemat
określany dalej numerem I jest w istocie pojedynczą tabelą,
gromadzącą wszystkie dane dotyczące pomiaru. Są to takie
informacje jak:
Nazwa stacji na której dokonano pomiaru
Lokalizacja stacji pomiarowej
Czas dokonania pomiaru
Wartości mierzonych parametrów
Czas zapisu pomiaru w systemie
Rys 2. Schemat I – Wszystkie gromadzone dane zapisywane są w jednej tabeli.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 45
Niestety ogromną wadą tego typu rozwiązań są problemy
z wprowadzaniem jakichkolwiek korekt do danych opisujących
pomiar. Problem taki można łatwo zilustrować na przykładzie sytuacji
gdzie zakładamy, że po roku gromadzenia pomiarów okaże się, że
zachodzi konieczność zmiany formatu numeru stacji (pole
stationNumber), z liczbowego na kombinację znaków
alfanumerycznych. W takim przypadku należałoby zmodyfikować
wszystkie dotychczas zapisane rekordy z pomiarami, zapisując nową
wartość numeru stacji. Po roku gromadzenia pomiarów z 500 stacji
byłoby to około 500 (stacji) *365 (dni) * 24 (godziny) * 6 (pomiarów
na godzinę) = 26,28 mln rekordów. Operacja taka zajęła by ogromną
ilość czasu i w znaczącym stopniu ograniczyła możliwości systemu
w zakresie obsługi bieżących usług dla klientów. Za inny przykład
sytuacji, w której ten schemat nie będzie optymalny można uznać
problem archiwizacji starszych informacji. W związku
z nadmiarowością takiej struktury danych, również archiwum
cechowałoby się niepotrzebnym narzutem powielających się
informacji. Ten problem jednak jest łatwiejszy do zneutralizowania –
wystarczy przechowywać dane archiwalne w nieco zmienionej
strukturze. Np. w drugiej postaci normalnej. Do zalet stosowania
struktury z jedną tabelą należą bez wątpienia:
łatwość tworzenia zapytań
prostota ustalania indeksów
Prostota zapytań obsługujących taka strukturę danych polega
na braku konieczności łączenia wyników pobieranych z wielu tabel lub
przeszukiwania innych tabel pod kątem określenia warunków do
odnalezienia poszukiwanego zakresu informacji. Natomiast tworzenie
indeksów jest o tyle ułatwione, że nie ma możliwości powstania
skomplikowanych związków pomiędzy różnymi tabelami.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 46
3.2. Każdy pomiar w osobnym rekordzie
Ta propozycja schematu bazodanowego stanowi przykład
rozbicia modelu danych na obiekty atomowe. W terminologii
bazodanowej obiekt atomowy, to taki którego nie sposób podzielić.
Postępując zgodnie z tą zasadą poszczególne rekordy tabeli
measurement przechowują pojedyncze wartości, których typ
określony jest w tabeli measurement_type.
Rys 3. Schemat II – Poszczególne wartości pomiarów przechowywane jako osobne rekordy.
Dzięki temu istnieje możliwość zidentyfikowania poszczególnych
pomiarów po określonym w nich typie. Tabela measurement zostaje
zredukowana do podstawowych pól, czyli:
measurement_id – unikalny identyfikator pomiaru
station_id – klucz obcy relacji z tabelą station
measurement_type_id – klucz obcy relacji z tabelą
measurement_type
measurementTime – czas dokonania pomiaru
persistTime – czas zapisu pomiaru w systemie
value – wartość parametru.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 47
Podejście takie zmienia nieco definicję terminu pomiar.
W poprzednich przypadkach za pomiar (Measurement) uznawany był
kompletny zestaw parametrów mierzonych na danej stacji
pomiarowej. Tymczasem, w tym przypadku za pomiar uznaje się
pojedynczą wartość parametru. Zapis taki w znaczącym stopniu
upraszcza operacje wyszukiwania danych jednego typu. Wiąże się
jednak ze znacznym zwiększeniem objętości bazy danych.
Dodatkowym minusem jest w tym przypadku trudniejsze
wyszukiwanie zestawu różnych parametrów dla zadanego regionu lub
stacji.
3.3. Trzecia postać normalna
W tym rozwiązaniu z tabeli Measurements opisanej w rozdziale
3.1 wydzielono dane dotyczące lokalizacji z której dany zestaw
parametrów został pobrany. Efektem jest zestaw trzech tabel:
region
station
measurements
Tabele te odpowiadają fizycznym modelom istniejącym
w rzeczywistej sieci pomiarowej.
Rys 4. Schemat III – Tabele odzwierciedlające fizyczne modele danych.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 48
Dzięki temu rozdzielone zostają wartości pomiarów, od danych
określających ich lokalizację. Dodatkową zaletą takiego rozwiązania
jest łatwość edycji informacji dotyczących stacji lub regionów. Takie
podejście do problemu pozwala na swobodniejsze planowanie
sposobu w jaki gromadzone dane powinny być następnie
archiwizowane. Nie występuje także zjawisko nadmiarowości
w postaci ciągłego przepisywania danych lokalizacyjnych.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 49
4. SCENARIUSZE DOSTĘPU DO DANYCH
4.1. Najczęściej wykorzystywane kwerendy
W każdym systemie, pośród całej projektowanej
funkcjonalności można wyznaczyć taką, która będzie wykorzystywana
najczęściej. W przypadku systemu gromadzącego dane z pomiarów
parametrów hydrometeorologicznych, operacją najczęściej
wykorzystywaną będzie udostępnianie zgromadzonych danych
użytkownikom. Dane, przed wysłaniem do klienta muszą zostać
najpierw odnalezione w systemie. W systemach bazodanowych
operację taką przeprowadza się na podstawie kryteriów wyszukiwania
podanych przez użytkownika. Kryteria te określają dziedzinę
informacji, jaka danego klienta interesuje, a także dokładny
przedział, jaki należy klientowi zwrócić. Kryteria te mogą być
wprowadzane za pośrednictwem interfejsu użytkownika na stronie
WWW lub bezpośrednio w systemie bazodanowym za pośrednictwem
udostępnianej przez dany serwer konsoli. Określenie czynności oraz
kryteriów jej przeprowadzenia pozwala zbudować kwerendę
(zapytanie) do bazy danych. Czynnością w tym kontekście może być
np. operacja selekcji, a kryteriami, określenie zakresu z jakiego
selekcja ma zwrócić dane klientowi.
Podstawową funkcją systemu jest gromadzenie danych, wobec
czego operacje zapisu danych do bazy traktowane są priorytetowo.
Przewiduje się test aplikacji pod kątem zapisu pełnego pakietu
danych, czyli symulacje zapisu danych ze stacji posiadającej komplet
czujników.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 50
Bardziej skomplikowana jest sytuacja z pobieraniem danych
z systemu. Wynika to z faktu, że użytkownicy będą bardziej
zainteresowani wartościami jednego parametru na zadanym
obszarze, niż kompletu danych z danej stacji. Dlatego też, badaniu
podlegać będzie średni czas dostępu do wybranego podzbioru,
składającego się z jednego do trzech parametrów ze stacji na
zadanym obszarze. Stosując takie podejście, można pokusić się
o określenie sytuacji, w jakiej szybki dostęp do danych będzie
najbardziej potrzebny. Za taką sytuację można uznać zagrożenie
powodziowe, występujące na pewnym obszarze. W takim przypadku
najważniejszymi parametrami są: poziom wody (water) i wysokość
opadu (precipitation). Wydajność systemu zostanie przetestowana za
pomocą scenariuszy testowych. Scenariusze testowe zostały tak
dobrane, aby jak najlepiej odzwierciedlały zapytania, zlecane
systemowi przez użytkowników. Do przeprowadzenia testów
przygotowano poniższy zestaw scenariuszy:
Wyszukanie sum godzinowych opadów dla danej stacji.
Wyszukanie wartości przekraczających ustalone wartości graniczne.
Wybranie ekstremalnych wartości parametru z pominięciem
wykraczających poza zakres.
Podstawowe statystyki, takie jak średnie wartości parametrów.
Pozyskiwanie sumy opadów na zadanym terenie (objętym zadaną
liczbą stacji pomiarowych) dla ostatnich 3 godzin.
4.2. Opis sposobu prowadzenia pomiarów czasu wykonania
Procedura testowa została zaplanowana tak, aby poszczególne
fazy testów nie wpływały na siebie oraz aby zapewnić maksymalną
możliwą powtarzalność otrzymywanych wyników. Środowisko testowe
zbudowane zostało w oparciu o powszechnie dostępne komponenty,
które jednak działają z powodzeniem w dużych instalacjach
serwerowych.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 51
4.2.1. Środowisko testowe
W celu uzyskania wiarygodnych wyników wszystkie testy
przeprowadzone zostały na tym samym serwerze. Maszyna ta na czas
testów stanowiła izolowane środowisko bazodanowe i nie obsługiwała
żadnych innych zadań.
Tabela 8. Specyfikacja serwera testowego
Komponent Typ Wersja / Wielkość System bazodanowy MySQL 5.0.38
Język skryptowy PHP 5.2.1 Procesor Athlon64 3200+ (2000Mhz)
Pamięć RAM DDR 3200 1GB System operacyjny Ubuntu Linux 7.04 (Feisty Fawn) kernel 2.16.20
Dysk twardy Western Digital SATA WD800JD-22LS 80GB
4.2.2. Sposób prowadzenia pomiarów
Do realizacji scenariuszy testowych wykorzystane zostały
skrypty napisane w języku PHP5. W środowisku testowym utworzone
zostały dwa rodzaje skryptów. Pierwszy z nich służy do uruchomienia
testów wydajności zapisu do bazy danych, drugi uruchamia
scenariusze testujące wyszukiwanie danych. Aby możliwe było
analizowanie rzeczywistych czasów wykonania kwerend, został
wyłączony wewnętrzny cache systemu MySQL.
Pierwszy skrypt ma za zadanie sprawdzenie wydajności zapisu
do bazy danych i porównanie czasów wykonania określonej ilości
zapisów do tabeli bez indeksów oraz z indeksami. Istotę jego
działania obrazuje pseudokod:
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 52
Iteracja po zmiennej indeksów: z indeksami, bez indeksów {
Iteracja po ilości stacji w systemie: 5, 25, 50 {
Iteracja po długości okresu: 1 miesiąc, 1 rok, 5 lat {
Jeżeli z indeksami: utwórz indeksy
Rozpocznij pomiar czasu
Zapisz kolejno n pomiarów; n : ilość pomiarów
Zakończ pomiar czasu
Wypisz czas zużyty na zapis do bazy
Wypisz objętość bazy po zapisie
Jeżeli z indeksami: usuń indeksy
}
}
}
Zadaniem drugiego skryptu jest przeprowadzenie testów
wydajności wyszukiwania danych. Jest podobnie skonstruowany do
skryptu testującego zapis: Iteracja po ilości stacji w systemie: 5, 25, 50 {
Iteracja po długości okresu: 1 miesiąc, 1 rok, 5 lat {
Zapisz kolejno n pomiarów; n : ilość pomiarów
Iteracja po scenariuszu testowym: 1, 2, 3, 4, 5 {
Rozpocznij pomiar czasu
Uruchom scenariusz testowy X
Zakończ pomiar czasu
Wypisz czas potrzebny na wykonanie scenariusza
Utwórz indeksy
Rozpocznij pomiar czasu
Uruchom scenariusz testowy X
Zakończ pomiar czasu
Wypisz czas potrzebny na wykonanie scenariusza
Usuń indeksy
}
}
}
Oba skrypty w trakcie prowadzenia testów wypisują aktualne
wyniki, które z kolei są zapisywane w pliku tekstowym. Następnie
dane przenoszone są do arkusza programu Excel w celu dalszego
przetwarzania.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 53
4.3. Porównanie wydajności schematów w obsłudze
zapytań
Głównym celem tego opracowania jest odpowiedź na pytanie,
które z przedstawionych wcześniej rozwiązań spełni pokładane w nim
oczekiwania co do optymalnej wydajności i użyteczności podczas
pozyskiwania danych zgromadzonych w systemie. Przedstawiony
wcześniej schemat przeprowadzenia pomiarów ma zapewnić
jednakowe warunki dla testów każdej z propozycji. Wyniki
przeprowadzonych testów zostaną następnie zestawione w postaci
tabel i wykresów co pozwoli w wygodny sposób prześledzić, które
rozwiązanie najlepiej spełnia wymogi stawiane przed projektem.
4.3.1. Wpływ zastosowania indeksów na czas obsługi zapytań.
Indeksy to struktura, która przyspiesza wyszukiwanie danych
w Bazie. Indeksy przypominają zakładki z literami alfabetu
w katalogach. Jeżeli szukamy czegoś na literę „D” nie szukamy juz
gdzie indziej tylko za zakładka z literą „D”. Oczywiście zbyt wiele
kolumn oznaczonych jako indeksy nie spowoduje przyspieszenia,
a wręcz przeciwnie, spowolnią proces. Indeksy przyspieszają
przeszukiwanie danych (SELECT), ale spowalniają modyfikacje
(INSERT, UPDATE i DELETE). Spowolnienie tych ostatnich wynika
wprost z konieczności zapisu nie tylko danych w tabeli, ale także
aktualizacji indeksu dla tych informacji. To z kolei, wymaga
przesortowania już posiadanych danych tak, aby nowe informacji
znalazły się w odpowiednich miejscach.
Na indeksy najlepiej nadają się kolumny zawierające
niepowtarzalne dane, czyli wszelkiego typu identyfikatory. Do
utworzenia indeksu najlepiej nadaje się pole unikalne, czyli
w przypadku tabeli z pomiarami measurement_id. W tym przypadku,
indeks tworzony jest automatycznie, ponieważ pole jest w tej tabeli
kluczem głównym.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 54
Jako indeksy można też użyć kolumn, które będą często
wykorzystywane do filtrowania danych, czyli pola występujące
w warunku WHERE. W przypadku tabeli z pomiarami, powinno to być
pole station_id lub w przypadku schematu I stationName.
Indeksy mogą być tworzone dla jednego lub wielu pól. Możemy
utworzyć indeks dla pól temperature0m i temeperature2m jeżeli
będziemy często przeszukiwać bazę według takiego kryterium. Można
także utworzyć więcej niż jeden indeks dla tabeli. Dokładnie, MySQL
umożliwia utworzenie 64 indeksów dla jednej tabeli typu MyISAM,
ale należy unikać tworzenia zbyt wielu indeksów.
Korzystając z przedstawionej powyżej teorii można określić, że
indeksy mogą mieć decydujący wpływ na wydajność prezentowanych
propozycji. Dzięki ich zastosowaniu, zmienia się zależność czasu
wykonania kwerendy od ilości danych w bazie.
4.4. Kryteria oceny proponowanych rozwiązań
Przystępując do testów rozwiązań kandydujących, należy
wyszczególnić jakie ich cechy mają największe znaczenie.
W przypadku systemu bazodanowego należy brać pod uwagę takie
zagadnienia jak:
Objętość
Wydajność zapisu
Wydajność odczytu
Należy pamiętać o głównym przeznaczeniu systemu. Jeśli
system ma być nastawiony na jak największą wydajność zapisu lub/i
odczytu rozsądnie będzie uznać, że objętość bazy danych nie stanowi
wielkiego problemu. Jeśli natomiast wiadome jest, że nie ma potrzeby
gwarantować klientom szybkiego dostępu do danych, można wybrać
rozwiązanie najlepsze pod kątem objętości.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 55
4.4.1. Objętość
Jest to jeden z najważniejszych parametrów jeśli rozważa się
problem baz danych mających przechowywać ogromne ilości danych.
Od niego zależy wybór ilości miejsca dostępnego na serwerze. Na
objętość bazy danych wpływają takie czynniki jak:
Długość okresu gromadzenia danych
Zastosowany schemat bazy danych
Sposób implementacji indeksów
Typ danych przechowywanych w tabelach
4.4.2. Wydajność zapisu
Parametr pomijany bardzo często w opisach schematów baz
danych. Jednym z powodów takiego podejścia jest fakt, że operacja
zapisu do bazy jest jedną z najszybszych. W tym miejscu należy
zaznaczyć, że tak się dzieje tylko jeśli nie zachodzą dodatkowe
czynniki. Takim czynnikiem wpływającym na szybkość zapisu mogą
być na przykład nienajlepiej dobrane indeksy dla tabeli, na przykład
za duża ich liczba.
4.4.3. Wydajność odczytu
Zdecydowanie jeden z najważniejszych parametrów systemu
bazodanowego. W przeważającej większości systemów to właśnie na
odczyt danych kładzie się największy nacisk. Sytuacja ta wynika
z faktu, że informacja jest na tyle użyteczna, na ile łatwo do niej
dotrzeć. Istnieją wprawdzie systemy bazodanowe zajmujące się
głównie magazynowaniem informacji, ale jest to znikomy procent
implementacji.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 56
5. ZESTAWIENIE UZYSKANYCH WYNIKÓW
5.1. Zestawienie wydajności rozwiązań
Testom wydajności poddane zostały rozwiązania:
Wszystkie dane zgromadzone w jednej tabeli – dalej oznaczane „I”
Każdy pomiar w osobnym rekordzie – oznaczane dalej jako „II”
Trzecia postać normalna – rozwiązanie oznaczane nr „III”
Każdemu z rozwiązań kandydujących przypisany został numer.
Ma to na celu ułatwić identyfikację poszczególnych schematów
w dalszej części dokumentu. Opisując cechy omawianych rozwiązań
będą one określane jako Schemat X, gdzie X oznacza rozwiązanie
kandydujące o numerze I, II lub III.
5.1.1. Objętość
Sprawdzenie objętości bazy danych po zapisaniu pewnej ilości
pomiarów, polega na odczytaniu rozmiaru plików przechowujących,
odpowiadającą testowanemu schematowi, bazę danych.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 57
0
100
200
300
400
500
600
1 12 60
miesiące
ob
jęto
ść [
MB
]
III schematII SchematI Schemat
Rys. 5. Zależność objętości plików bazy danych od czasu gromadzenia pomiarów dla systemu 5 stacji i tabeli przechowującej pomiary bez indeksów.
0
100
200
300
400
500
600
700
800
1 12 60
miesiące
ob
jęto
ść [
MB
]
III schematII SchematI Schemat
Rys. 6. Zależność objętości plików bazy danych od czasu gromadzenia pomiarów dla systemu 5 stacji i tabeli przechowującej pomiary z indeksami.
Na rysunkach 6 i 7 można zauważyć, że pod względem
objętości, rozwiązanie II znacząco odstaje od dwóch pozostałych. Ma
to miejsce nawet w najprostszym przypadku gdy dane gromadzone
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 58
są z 5 stacji pomiarowych. Stosunek ten pozostaje niezmienny
niezależnie od ilości stacji z jakich gromadzone są pomiary:
0
1000
2000
3000
4000
5000
6000
1 12 60
miesiące
ob
jęto
ść [
MB
]
III schematII SchematI Schemat
Rys. 7. Zależność objętości plików bazy danych od czasu gromadzenia pomiarów dla systemu 50 stacji i tabeli przechowującej pomiary bez indeksów.
0
1000
2000
3000
4000
5000
6000
7000
8000
1 12 60
miesiące
ob
jęto
ść [
MB
]
III schematII SchematI Schemat
Rys. 8. Zależność objętości plików bazy danych od czasu gromadzenia pomiarów dla systemu 50 stacji i tabeli przechowującej pomiary z indeksami.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 59
Taka sytuacja jest pewnego rodzaju zwiastunem tego jaka
będzie charakterystyka systemu opartego na rozwiązaniu II. Wynika
to z faktu, że w operacjach bazodanowych objętość bazy jest
czynnikiem wpływającym na czas wykonania zapytań, którego nie
można pominąć w rozważaniach.
Komplet wyników pomiarów przyrostu objętości bazy w czasie:
Tabela 9. Objętość bazy danych [MB] dla schematu I
bez stosowania indeksów z zastosowanymi indeksami Miesiące Miesiące liczba
stacji 1 12 60 liczba stacji 1 12 60
5 3 32 143 5 3 34 148 25 14 164 717 25 15 170 740 50 29 328 1434 50 30 340 1482
Tabela 10. Objętość bazy danych [MB] dla schematu II
bez stosowania indeksów z zastosowanymi indeksami Miesiące Miesiące liczba
stacji 1 12 60 liczba stacji 1 12 60
5 11 124 543 5 14 154 688 25 56 623 2718 25 70 787 3417 50 113 1246 5436 50 140 1579 6861
Tabela 11. Objętość bazy danych [MB] dla schematu III
bez stosowania indeksów z zastosowanymi indeksami Miesiące Miesiące liczba
stacji 1 12 60 liczba stacji 1 12 60
5 2 29 130 5 3 32 141 25 13 149 650 25 14 161 704 50 27 298 1301 50 29 323 1408
Przedstawione powyżej, w tabelach 9, 10, 11, wyniki pokazują,
że objętość danych zapisanych w schemacie II znacznie przewyższa
objętość danych zapisanych w schematach I i III. Można zauważyć,
że objętość danych zapisanych we wszystkich rozwiązaniach
przyrasta proporcjonalnie do ilości stacji i czasu. Schemat II
charakteryzuję się tak gwałtownym przyrostem objętości plików bazy
danych, ponieważ wymaga zapisania 11 rekordów, gdy schematy
I i III zgromadza tylko 1 rekord.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 60
Można także zaobserwować, że objętość plików bazy danych nie
jest w bezpośredniej korelacji z ilością rekordów w bazie. Można to
zauważyć ponieważ ilość rekordów zapisanych w schemacie II jest,
co zostało powiedziane już wcześniej, 11 razy większa niż
w schematach I i III, a rozmiar plików bazy danych zwiększył się
tylko około czterokrotnie.
5.1.2. Wydajność zapisu
W tym rozdziale przeprowadzona zostanie analiza wydajności
rozwiązań pod kątem zapisu danych. Aby wyniki były możliwe do
wizualizacji, pomiary przeprowadzone zostały na zróżnicowanej ilości
danych. W tym celu do bazy zostaną zapisane dane z 1 miesiąca,
1 roku i 5 lat. Czasy, potrzebne do zapisu wszystkich zestawów dla
poszczególnych schematów, pozwolą zaobserwować jaka różnica
dzieli poszczególne schematy.
0
200
400
600
800
1000
1200
1400
0 10 20 30 40 50 60 70
miesiące
czas [
s]
III schematII SchematI Schemat
Rys 9. Zależność czasu zapisu danych od długości okresu gromadzenia pomiarów dla systemu 5 stacji i tabeli przechowującej pomiary bez indeksów
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 61
0
200
400
600
800
1000
1200
0 10 20 30 40 50 60 70
miesiące
czas [
s]
III schematII SchematI Schemat
Rys. 10. Zależność czasu zapisu danych od długości okresu gromadzenia pomiarów dla systemu 5 stacji i tabeli przechowującej pomiary z indeksami
Obserwując na rysunkach 9 i 10 zachowanie schematów dla
najprostszego systemu obsługującego jedynie 5 stacji pomiarowych,
nie sposób nie zauważyć wpływu znacznie szybciej przyrastającej
objętości plików bazy danych schematu II na czas zapisu nowych
rekordów. Znacznie większa ilość rekordów w tym schemacie sprawia,
że czas zapisu nowych przyrasta praktycznie liniowo.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 62
0
2000
4000
6000
8000
10000
12000
14000
0 10 20 30 40 50 60 70
miesiące
czas [
s]
III schematII SchematI Schemat
Rys. 11. Zależność czasu zapisu danych od długości okresu gromadzenia pomiarów dla systemu 50 stacji i tabeli przechowującej pomiary bez indeksów.
0
2000
4000
6000
8000
10000
12000
0 10 20 30 40 50 60 70
miesiące
czas [
s]
III schematII SchematI Schemat
Rys. 12. Zależność czasu zapisu danych od długości okresu gromadzenia pomiarów dla systemu 50 stacji i tabeli przechowującej pomiary z indeksami.
Analiza wyników pomiarów czasu potrzebnego na zapisanie
porcji danych z zadanego okresu, ujawniła, że w tym przypadku także
schemat II znacząco odstaje od konkurentów.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 63
Fakt ten wynika bezpośrednio z punktu poprzedniego, czyli
znacznie większej objętości bazy II. W przypadku testów wydajności
zapisu pojawiła się także pewna rozbieżność pomiędzy schematem I
a II. Można zaobserwować, że zastosowanie indeksów znacząco
(dwukrotnie) wydłuża czas potrzebny do zapisania tej samej ilości
danych w schemacie I.
Analizując zachowanie się poszczególnych schematów w tym
teście, można zauważyć różnicę we wpływie jaki na czas zapisu ma
stosowanie indeksów. W przypadku Schematu I, czas zapisu uległ
wydłużeniu o około 50%. Dla Schematu II i III odnotowano
skrócenie się czasu zapisu o odpowiednio 8% i 7%.
Zestawienie kompletnych wyników pomiarów czasu zapisu
danych, z różnych okresów i dla różnej liczby stacji pomiarowych.
Tabela 12. Czas zapisu danych [s] dla schematu I
bez stosowania indeksów z zastosowanymi indeksami Miesiące Miesiące liczba
stacji 1 12 60 liczba stacji 1 12 60
5 3 29 127 5 5 61 218 25 13 147 641 25 27 292 1115 50 27 296 1306 50 57 546 2317
Tabela 13. Czas zapisu danych [s] dla schematu II
bez stosowania indeksów z zastosowanymi indeksami Miesiące Miesiące liczba
stacji 1 12 60 liczba stacji 1 12 60
5 25 274 1198 5 23 253 1080 25 126 1387 6030 25 116 1278 5528 50 252 2772 12109 50 232 2598 11135
Tabela 14. Czas zapisu danych [s] dla schematu III
bez stosowania indeksów z zastosowanymi indeksami Miesiące Miesiące liczba
stacji 1 12 60 liczba stacji 1 12 60
5 3 27 118 5 3 29 108 25 12 136 596 25 11 127 550 50 25 274 1195 50 23 258 1109
Przedstawione powyżej wyniki potwierdzają wniosek z testów
przyrostu objętości. Rozmiar bazy danych decyduje o wydłużeniu
czasu zapisu nowych rekordów.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 64
Natomiast można zauważyć bardziej bezpośredni związek
pomiędzy liczbą rekordów w bazie i czasem zapisu nowych danych,
niż pomiędzy ilością rekordów, a objętością plików na dysku.
W przypadku czasu zapisu do bazy opartej o schemat II, jest on 9x
dłuższy niż dla schematu I bez stosowani indeksów i 4x dłuższy niż
ten sam schemat ale z zastosowaniem indeksów. Przeprowadzając
analogiczne porównanie ze schematem III można zauważyć ze czas
zapisu do schematu II jest około 10x dłuższy w obu przypadkach
indeksowania.
5.1.3. Wydajność odczytu
Do określenia wydajności odczytu danych z poszczególnych
rozwiązań, posłużą kwerendy odpowiadające testom
zaproponowanym w rozdziale 4.1. Kwerendom testowym zostały
przypisane numery dla poprawy czytelności wykresów:
K1: Znalezienie sum godzinowych opadów dla zadanej stacji.
K2: Wyszukanie wartości przekraczających ustalone wartości
graniczne.
K3: Wybranie ekstremalnych wartości parametru z pominięciem
wykraczających poza zakres.
K4: Podstawowe statystyki, takie jak średnie wartości parametrów.
K5: Pozyskiwanie sumy opadów na zadanym terenie (objętym
zadaną liczba stacji pomiarowych) dla ostatnich 3 godzin.
Każda z kwerend została uruchomiona dla danego schematu
z indeksem i bez indeksu. Do testów indeks został utworzony na polu
station_id w tabeli measurements. Ponieważ w Schemacie I nie ma
takiego pola, indeksowanie oraz wyszukiwanie odbywa się po
stationName.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 65
0
10
20
30
40
50
60
70
80
1 12 60 1 12 60 1 12 60
I II III
schemat / ilość miesięcy
czas [
s]
Kwerenda 1Kwerenda 2Kwerenda 3Kwerenda 4Kwerenda 5
Rys. 13. Zestawienie czasu wyszukiwania dla systemu 5 stacji i tabeli przechowującej pomiary bez indeksów.
0
1
2
3
4
5
6
7
8
9
10
1 12 60 1 12 60 1 12 60
I II III
schemat / ilość miesięcy
czas [
s]
Kwerenda 1Kwerenda 2Kwerenda 3Kwerenda 4Kwerenda 5
Rys. 14. Zestawienie czasu wyszukiwania dla systemu 5 stacji i tabeli przechowującej pomiary z indeksami
Na rysunkach 13 i 14, ponownie można zaobserwować bardzo
negatywny wpływ objętości bazy danych schematu II na czasy
wykonania zapytań testowych.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 66
0
50
100
150
200
250
1 12 60 1 12 60 1 12 60
I II III
schemat / ilość miesięcy
czas [
s]
Kwerenda 1Kwerenda 2Kwerenda 3Kwerenda 4Kwerenda 5
Rys. 15. Zestawienie czasu wyszukiwania dla systemu 50 stacji i tabeli przechowującej pomiary bez indeksów
0
20
40
60
80
100
120
1 12 60 1 12 60 1 12 60
I II III
schemat / ilość miesięcy
czas [
s]
Kwerenda 1Kwerenda 2Kwerenda 3Kwerenda 4Kwerenda 5
Rys. 16. Zestawienie czasu wyszukiwania dla systemu 50 stacji i tabeli przechowującej pomiary z indeksami
Powyższe zestawienie wyników pomiarów dla wszystkich trzech
schematów ujawnia, że schemat II nie dorównuje pozostałym także
pod względem szybkości wyszukiwania danych. W dodatku różnice są
tak duże, że utrudniają analizę wyników lepszych rozwiązań.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 67
Dlatego poniżej przedstawione zostanie zestawienie wyników z
wykluczeniem rozwiązania II.
0.0
0.5
1.0
1.5
2.0
2.5
3.0
3.5
1 12 60 1 12 60
I III
schemat / ilość miesięcy
czas [
s]
Kwerenda 1Kwerenda 2Kwerenda 3Kwerenda 4Kwerenda 5
Rys. 17. Zestawienie czasu wykonania kwerend testowych dla systemu 5 stacji i tabeli przechowującej pomiary bez indeksów, z pominięciem schematu II
0.0
0.5
1.0
1.5
2.0
2.5
3.0
3.5
1 12 60 1 12 60
I IIIschemat / ilość miesięcy
czas
[s]
Kw erenda 1
Kw erenda 2
Kw erenda 3
Kw erenda 4
Kw erenda 5
Rys. 18. Zestawienie czasu wykonania kwerend testowych dla systemu 5 stacji i tabeli przechowującej pomiary z indeksami, z pominięciem schematu II
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 68
Przyglądając się wynikom testu tego najprostszego przypadku
odczytu danych i pamiętając o wynikach testów objętości i zapisu,
można zauważyć ogólne trendy zachowania się opisywanych
schematów. Widać wyraźnie, że dla okresu 1 miesiąca czasy
schematów I i III nie odbiegają od siebie znacząco. Jednak im więcej
danych zgromadzone jest w systemie tym bardziej uwidaczniają się
różnice pomiędzy tymi schematami.
0
5
10
15
20
25
30
35
40
45
50
1 12 60 1 12 60
I III
schemat / ilość miesięcy
czas [
s]
Kwerenda 1Kwerenda 2Kwerenda 3Kwerenda 4Kwerenda 5
Rys. 19. Zestawienie czasu wykonania kwerend testowych dla systemu 50 stacji i tabeli przechowującej pomiary bez indeksów, z pominięciem schematu II
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 69
0
5
10
15
20
25
30
35
40
45
50
1 12 60 1 12 60
I IIIschemat / ilość miesięcy
czas [
s]
Kwerenda 1Kwerenda 2Kwerenda 3Kwerenda 4Kwerenda 5
Rys. 20. Zestawienie czasu wykonania kwerend testowych dla systemu 50 stacji i tabeli przechowującej pomiary z indeksami, z pominięciem schematu II
Po pominięciu schematu II można zaobserwować różnice
pomiędzy schematami I a III. Dodatkowo wykresy na rysunkach 19
i 21, pokazują że kwerendy korzystające z większości rekordów, jak
to ma miejsce przy kwerendzie 4, nie korzystają z indeksów. Przez to
na powyższych wykresach (Rysunki 18 do 21) nadal trudno jest
zaobserwować różnice dzielące schemat I i III. Dlatego też poniżej
zamieszczone zostanie kolejne zestawienie. Nie będzie ono
uwzględniało Kwerendy 4, co pozwoli zaobserwować zachowanie
systemu przy najczęściej używanych kwerendach.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 70
0.0
0.5
1.0
1.5
2.0
2.5
3.0
3.5
1 12 60 1 12 60
I III
schemat / ilość miesięcy
czas [
s]
Kwerenda 1Kwerenda 2Kwerenda 3Kwerenda 5
Rys. 21. Zestawienie czasu wykonania kwerend testowych dla systemu 5 stacji i tabeli przechowującej pomiary bez indeksów, z pominięciem schematu II i Kwerendy 4
0.0
0.5
1.0
1.5
2.0
2.5
3.0
3.5
1 12 60 1 12 60
I IIIschemat / ilość miesięcy
czas
[s]
Kw erenda 1
Kw erenda 2
Kw erenda 3
Kw erenda 5
Rys. 22. Zestawienie czasu wykonania kwerend testowych dla systemu 5 stacji i tabeli przechowującej pomiary z indeksami, z pominięciem schematu II i Kwerendy 4
Rysunki 21. i 22 pokazują, że przy stosunkowo małym systemie
obsługującym 5 stacji schemat I nie sprawdza się przy obsłudze
Kwerendy 5.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 71
0
2
4
6
8
10
12
14
16
18
20
1 12 60 1 12 60
I IIIschemat / ilość miesięcy
czas [
s]
Kwerenda 1Kwerenda 2Kwerenda 3Kwerenda 5
Rys. 23. Zestawienie czasu wykonania kwerend testowych dla systemu 25 stacji i tabeli przechowującej pomiary bez indeksów, z pominięciem schematu II i Kwerendy 4
0.0
0.2
0.4
0.6
0.8
1.0
1.2
1.4
1 12 60 1 12 60
I III
schemat / ilość miesięcy
czas [
s]
Kwerenda 1Kwerenda 2Kwerenda 3Kwerenda 5
Rys. 24. Zestawienie czasu wykonania kwerend testowych dla systemu 25 stacji i tabeli przechowującej pomiary z indeksami, z pominięciem schematu II i Kwerendy 4
Wykresy na rysunkach 23 i 24 pokazują, że dla systemu 25
stacji pomiarowych schemat I prezentuje słabszą wydajność
podstawowych kwerend (K1, K2, K3) w stosunku do Schematu III.
Kwerenda 5 okazuje się swoistą piętą Achillesową schematu I.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 72
W tym przypadku czas wykonania tego zapytania jest o rząd
wielkości dłuższy niż z zastosowaniem schematu III.
0
5
10
15
20
25
30
35
40
45
50
1 12 60 1 12 60
I III
schemat / ilość miesięcy
czas [
s]
Kwerenda 1Kwerenda 2Kwerenda 3Kwerenda 5
Rys. 25. Zestawienie czasu wykonania kwerend testowych dla systemu 50 stacji i tabeli przechowującej pomiary bez indeksów, z pominięciem schematu II i Kwerendy 4
0.0
0.1
0.2
0.3
0.4
0.5
0.6
1 12 60 1 12 60
I IIIschemat / ilość miesięcy
czas [
s]
Kwerenda 1Kwerenda 2Kwerenda 3Kwerenda 5
Rys. 26. Zestawienie czasu wykonania kwerend testowych dla systemu 50 stacji i tabeli przechowującej pomiary z indeksami, z pominięciem schematu II i Kwerendy 4
Wykresy na rysunkach 25 i 26 dokumentują wyniki testów
przeprowadzone dla symulacji systemu obsługującego dużą sieć 50
stacji pomiarowych.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 73
Przy tak dużej ilości danych testowych uwidocznione zostają
nawet niewielkie różnice w wydajności rozwiązań. Wyraźnie można
zaobserwować różnicę pomiędzy testowanymi schematami. Widać
także, że stosowanie indeksów powoduje opóźnienia w działaniach
systemu przy niewielkiej ilości danych w nim zgromadzonych.
Objawia się to dłuższymi czasami wykonania kwerend dla danych z
jednego miesiąca, niż z jednego roku. Dla systemu obsługującego 50
stacji czas wykonania kwerendy 5 uległ skróceniu, w stosunku do
systemu z 25 stacjami. Sytuacja ta ma związek z zastosowanym
indeksem. Dopiero przy takiej ilości stacji zastosowanie indeksu
pozwoliło skrócić czas wykonania kwerendy.
Tabela 15. Zestawienie czasów wyszukiwania [s] dla poszczególnych schematów przy systemie 5 stacji i tabeli przechowującej wyniki bez indeksów
Schemat I II III Miesiące
Kwerenda 1 12 60 1 12 60 1 12 60
1 0.02509 0.25730 1.01723 0.07902 0.77846 69.03832 0.01019 0.08928 0.29976 2 0.02723 0.28662 1.05334 0.06566 0.70720 34.24004 0.01078 0.09834 0.32297 3 0.02206 0.24366 1.02190 0.06163 0.71036 31.39790 0.00689 0.07204 0.29682 4 0.03333 0.39087 1.73664 0.08056 0.92845 33.18582 0.01234 0.13320 0.57296 5 0.08705 0.74057 3.12429 0.07454 0.78181 38.51185 0.01878 0.14323 0.37102
Tabela 16. Zestawienie czasów wyszukiwania [s] dla poszczególnych Schematów przy systemie 5 stacji i tabeli przechowującej wyniki z indeksami
Schemat I II III Miesiące
Kwerenda 1 12 60 1 12 60 1 12 60
1 0.03942 0.16662 0.17034 0.08903 0.82104 3.39466 0.02194 0.08867 0.08816 2 0.03704 0.16374 0.15652 0.08197 1.22617 3.86107 0.01963 0.09111 0.10272 3 0.03255 0.13113 0.13388 0.07962 1.25648 2.47958 0.01345 0.04985 0.06724 4 0.03304 0.38703 1.68221 0.08026 0.98775 8.85851 0.01400 0.13175 0.57055 5 0.09080 1.36430 2.48125 0.09080 1.36430 2.48125 0.03273 0.13191 0.16067
Tabela 17. Zestawienie czasów wyszukiwania [s] dla poszczególnych Schematów przy systemie 25 stacji i tabeli przechowującej wyniki bez indeksów
Schemat I II III Miesiące
Kwerenda 1 12 60 1 12 60 1 12 60
1 0.10704 1.14416 4.99105 0.33057 3.91572 75.51242 0.03362 0.31914 1.41100 2 0.11749 1.20488 14.42514 0.35870 12.05723 78.96825 0.03473 0.34499 7.91140 3 0.11298 1.18516 13.95440 0.32489 11.47294 80.28558 0.03165 0.33988 7.90125 4 0.16611 1.92720 15.42025 0.44885 12.14457 82.12093 0.06165 0.71430 9.07666 5 0.16746 1.63968 17.42070 0.35777 11.00756 88.80611 0.04463 0.34622 11.56543
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 74
Tabela 18. Zestawienie czasów wyszukiwania [s] dla poszczególnych Schematów przy systemie 25 stacji i tabeli przechowującej wyniki z indeksami
Schemat I II III Miesiące
Kwerenda 1 12 60 1 12 60 1 12 60
1 0.03986 0.02489 0.04942 0.19575 0.46015 0.48185 0.02181 0.01310 0.03280 2 0.04389 0.03860 0.06240 0.18301 0.44813 0.28443 0.02251 0.02057 0.03470 3 0.03247 0.03144 0.04967 0.18330 0.45611 0.33035 0.01438 0.01472 0.02993 4 0.16435 1.88793 11.54036 0.41873 7.60002 57.32280 0.06735 0.65740 6.33396 5 0.16243 0.82197 1.19924 0.19810 0.44386 0.30144 0.03246 0.03058 0.03656
Tabela 19. Zestawienie czasów wyszukiwania [s] dla poszczególnych Schematów przy systemie 50 stacji i tabeli przechowującej wyniki bez indeksów
Schemat I II III Miesiące
Kwerenda 1 12 60 1 12 60 1 12 60
1 0.21277 2.27752 41.56857 0.66677 29.82824 156.50204 0.05990 0.63151 24.85482 2 0.22331 2.42672 44.05970 0.65949 37.57112 180.43608 0.06773 0.67513 26.60841 3 0.22012 2.36727 44.32734 0.64884 38.34521 180.41408 0.06983 0.68310 26.72964 4 0.33350 3.86821 43.97431 0.84774 37.81477 183.10341 0.13273 1.34382 27.20114 5 0.29018 2.76135 44.34751 0.71056 46.35121 208.03617 0.07306 0.69253 26.53468
Tabela 20. Zestawienie czasów wyszukiwania [s] dla poszczególnych Schematów przy systemie 50 stacji i tabeli przechowującej wyniki z indeksami
Schemat I II III Miesiące
Kwerenda 1 12 60 1 12 60 1 12 60
1 0.03964 0.02354 0.12616 0.09836 0.44620 0.47202 0.02307 0.01306 0.05943 2 0.03810 0.02306 0.09866 0.08513 0.68822 0.48302 0.02035 0.01168 0.03848 3 0.03363 0.01859 0.09242 0.17633 0.44979 0.46696 0.01376 0.00724 0.03838 4 0.33116 3.79494 47.14505 0.91800 40.21995 111.88453 0.12459 1.31142 29.99671 5 0.19598 0.13253 0.47658 0.10007 0.50166 0.48054 0.03031 0.01942 0.09095
5.2. Wybór odpowiedniego rozwiązania.
Kierując się wynikami zestawionymi w rozdziale 6.2, można
z całą pewnością uznać schemat II za rozwiązanie nie nadające się
do zaimplementowania. Pozostaje wyeliminować jedno z dwóch
pozostałych rozwiązań aby uzyskać odpowiedź na pytanie, który
z przedstawionych schematów jest najlepsza propozycją. W tym celu
otrzymane wyniki zostaną ponownie zestawione i przeanalizowane.
Jednak należy pamiętać, że już w poprzednim zestawieniu wyniki
wskazywały, że schemat III sprawdza się lepiej niż schemat I.
Poniżej ogólne zestawienie czasów wykonania kwerend dla obu
schematów.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 75
1I
12I
60I
1III
12III
60III
K1
K2
K3K4
K5
0.0
0.5
1.0
1.5
2.0
2.5
3.0
3.5
czas [
s]
schemat / miesiące
kw
ere
nd
a
K1K2K3K4K5
Rys. 27. Zobrazowanie różnic w czasach wykonania kwerend dla systemu 5 stacji i tabeli przechowującej wyniki bez indeksów, z pominięciem schematu II
Już w najprostszym przypadku, gdy system zbiera dane tylko
z 5 stacji pomiarowych, można zaobserwować różnicę pomiędzy
czasami wykonania kwerend dla schematu I i III. W przypadku bazy
danych bez zastosowanych indeksów możemy mówić o trzykrotnie
krótszym czasie dla schematu III.
1I
12I
60I
1III
12III
60III
K1
K2K3
K4K5
0
1
1
2
2
3
3
4
czas [
s]
schemat / miesiące
kw
ere
nda
K1K2K3K4K5
Rys. 28. Zobrazowanie różnic w czasach wykonania kwerend dla systemu 5 stacji i tabeli przechowującej wyniki z indeksami, z pominięciem schematu II
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 76
Rysunek 28 pokazuje, że po zastosowaniu indeksów, nadal
czasy pomierzone dla schematu III są krótsze, ale różnica zmniejsza
się do dwóch razy.
1I 12
I 60I 1
III 12III 60
III
K1
K2
K3
K4
K5
0
2
4
6
8
10
12
14
16
18
czas [
s]
schemat / miesiącekw
ere
nd
a
K1K2K3K4K5
Rys. 29. Zobrazowanie różnic w czasach wykonania kwerend dla systemu 25 stacji i tabeli przechowującej wyniki bez indeksów, z pominięciem schematu II
Powyżej, na rysunkach 28 i 29, zestawiono wyniki pomiarów dla
systemu gromadzącego dane z 25 stacji pomiarowych. Przedstawione
dane pokazują, że dla okresu pomiarowego 12 miesięcy, kwerendy
zwrócą wynik trzy do czterech razy szybciej jeśli użyty zostanie
schemat III. Natomiast po okresie pięciolecia dla większości
kwerend, różnica ta zmniejsza się do niecałych dwóch razy.
Obserwując otrzymane wyniki, można uznać, że bez zastosowania
indeksów, nie powinno się przechowywać danych z okresu dłuższego
niż 1 rok.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 77
1I 12
I 60I 1
III 12III 60
III
K1
K2
K3
K4
K5
0
2
4
6
8
10
12czas [
s]
schemat / miesiące
kw
ere
nd
a
K1K2K3K4K5
Rys. 30. Zobrazowanie różnic w czasach wykonania kwerend dla systemu 25 stacji i tabeli przechowującej wyniki z indeksami, z pominięciem schematu II
Sytuacje poprawia zastosowanie indeksów. Jak widać na
powyższym zestawieniu, dla kwerend 1,2 i 3, systemy zachowują się
prawie identycznie (różnice rzędu 0.2, 0.01 sekundy). Kwerenda 4 ze
względu na zastosowane grupowanie i testowanie niemal wszystkich
rekordów, nie podlega takiemu przyspieszeniu w obu przypadkach, co
można było zaobserwować także w poprzednich zestawieniach.
Rozbieżność widać natomiast przy kwerendzie 5. Schemat III
znacznie lepiej obsługuje taki typ zapytania.
Ponieważ na rysunku 30 czas wykonania Kwerendy 4 jest
znacząco dłuższy niż innych kwerend, zaciera on różnice pomiędzy
kwerendami potrzebującymi mniej czasu. Dlatego poniżej
zamieszczony zostaje wykres z pominięciem Kwerendy 4.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 78
1I 12
I 60I 1
III 12III 60
III
K1
K2
K3
K5
0.0
0.2
0.4
0.6
0.8
1.0
1.2
czas[s
]
schemat / miesiące
kw
ere
nd
a
K1K2K3K5
Rys. 31. Zobrazowanie różnic w czasach wykonania kwerend dla systemu 25 stacji i tabeli przechowującej wyniki z indeksami, z pominięciem schematu II i Kwerendy 4
Na rysunku 31 wyraźnie widać różnice w czasach wykonania
poszczególnych kwerend. Z otrzymanych wyników można
wnioskować, że kwerendy wykonywane na schemacie III potrzebują
przynajmniej dwukrotnie mniej czasu na wykonanie.
1I 12
I 60I 1
III 12III 60
III
K1
K2
K3
K4
K5
0
5
10
15
20
25
30
35
40
45
czas [
s]
schemat / miesiące
kw
ere
nd
a
K1K2K3K4K5
Rys. 32. Zobrazowanie różnic w czasach wykonania kwerend dla systemu 50 stacji i tabeli przechowującej wyniki bez indeksów, z pominięciem schematu II
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 79
Najbardziej złożony przypadek systemu obsługującego dane
z 50 stacji pomiarowych, pokazuje dobitnie, że przechowywanie
w tabeli bez indeksów tak dużej ilości danych nie spełni żadnych
oczekiwań. Dodatkowo można zauważyć, że różnica w czasach
pomiędzy 12 miesiącami a 60, rośnie wykładniczo.
1I 12
I 60I 1
III 12III 60
III
K1
K2
K3
K4
K5
0
5
10
15
20
25
30
35
40
45
czas [
s]
schemat / miesiące
kw
ere
nd
a
K1K2K3K4K5
Rys. 33. Zobrazowanie różnic w czasach wykonania kwerend dla systemu 50 stacji i tabeli przechowującej wyniki z indeksami, z pominięciem schematu II
Po zastosowaniu indeksów nawet na tak dużej tabeli czasy
wykonania kwerend spadają do wartości znacznie poniżej 1 sekundy
(około 0.03 sekundy). Niezmienna pozostaje kwestia kwerendy 4.
Czas jej wykonania jest tak długi, że zaciera różnice pomiędzy
pozostałymi zapytaniami. Dlatego poniżej załączony zostaje wykres
oparty na tym z rysunku 33, ale z pominięciem kwerendy 4.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 80
1I 12
I 60I 1
III 12III 60
III
K1
K2
K3
K5
0.00
0.05
0.10
0.15
0.20
0.25
0.30
0.35
0.40
0.45
0.50czas [
s]
schemat / miesiące
kw
ere
nd
a
K1K2K3K5
Rys. 34. Zobrazowanie różnic w czasach wykonania kwerend dla systemu 50 stacji i tabeli przechowującej wyniki z indeksami, z pominięciem schematu II i Kwerendy 4
Wykres na rysunku 34. pokazuje wyraźnie różnice dzielące
schemat I i III. Czasy wykonania kwerend dla schematu III są
znacznie krótsze niż w przypadku schematu I. Dla wszystkich
kwerend, do których wykonania wykorzystywane są indeksy, widać że
dla małej ilości danych (z jednego miesiąca) czas wykonania
kwerendy wydłuża się, w stosunku do okresu 1 roku. Ten negatywny
wpływ indeksów na wydajność wyszukiwania został zobrazowany na
rysunku 35. Efekt ten spowodowany jest koniecznością wykonania
dodatkowych operacji związanych z obsługą indeksów, poza sama
kwerendą. Ten dodatkowy czas nie jest zauważalny w przypadku
dużych ilości danych, ale uwidacznia się przy małych tabelach. [Gavin
Powell, 2005-12]
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 81
0.00
0.02
0.04
0.06
0.08
0.10
0.12
0.14
1 12 60
miesiące
czas
[s]
Schemat III
Schemat I
Rys. 35. Wpływ indeksów na czas wykonania Kwerendy 1.
Poniżej na rysunkach 36 i 37 przedstawione zostało
bezpośrednie porównanie schematów I i III uzależnione od liczby
stacji pomiarowych obsługiwanych przez system.
0
5
10
15
20
25
30
35
40
45
50
5 25 50
liczba stacji
czas
[s]
Schemat I
Schemat III
Rys. 36. Czas wykonania Kwerendy 2 odniesiony do ilości stacji pomiarowych, tabela przechowująca pomiary bez indeksów, pomiary gromadzone przez 5 lat.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 82
Rysunek 36. to wykres porównujący czasy wykonania Kwerendy
2 w zależności od ilości stacji pomiarowych obsługiwanych przez
system. To porównanie zostało przeprowadzone na bazie danych bez
zastosowania indeksów, widać że czas wykonania kwerendy wydłuża
się szybciej jeśli zastosowano Schemat I.
0.00
0.02
0.04
0.06
0.08
0.10
0.12
0.14
0.16
0.18
5 25 50
liczba stacji
czas
[s]
Schemat I
Schemat III
Rys. 37. Czas wykonania Kwerendy 2 odniesiony do ilości stacji pomiarowych, tabela przechowująca pomiary z indeksami, pomiary gromadzone przez 5 lat.
Powyżej, na rysunku 37. przedstawiono porównanie czasu
wykonania Kwerendy 2 w zależności od ilości stacji pomiarowych
w systemie. W tym przypadku zostały utworzone indeksy na tabeli
measurements dla pola station_id lub stationName (dla schematu I).
Na tym porównaniu można zaobserwować, że czas wykonania
kwerendy dla schematu I cały czas przewyższa czas schematu III,
i zmienia się gwałtowniej przy zwiększeniu liczby stacji.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 83
6. ANALIZA WYNIKÓW
Analizując uzyskane wyniki i zestawiając je z założeniami
przedstawionymi wcześniej dla projektowanego systemu, można
uznać, że schemat III najlepiej sprawdzi się w projektowanym
systemie. Dodatkowo, aby zapewnić poprawne działanie systemu
także w długim horyzoncie czasowym, należy rozważyć rozbudowę
schematu III o mechanizm archiwizacji starszych pomiarów.
Podejście takie zagwarantuje, że w tabeli measurements liczba
rekordów nie będzie rosła w nieskończoność. Można to osiągnąć za
pomocą dodatkowych skryptów, sprawdzających czy w tabeli tej nie
znajdują się rekordy starsze niż pewien założony okres. Odpowiednie
ustalenie długości okresu, po którym dane mają zostać przeniesione
do archiwum, pozwoli zachować czas wykonania kwerend
statystycznych, czyli sprawdzających wszystkie lub większość
rekordów, na zadowalającym poziomie.
Przeprowadzone testy pokazały, że najprostsza struktura bazy
danych, jaką jest pojedyncza tabela (schemat I), byłaby wielokrotnie
wydajniejsza niż teoretycznie lepiej zaprojektowana struktura
rozdzielająca poszczególne pomiary na pojedyncze rekordy (schemat
II). Zaistniała różnica wynika z trzech podstawowych czynników:
Objętości plików bazy danych – odczyt z dysków twardych jest
bardzo powolny, więc skanowanie ogromnych (ok. 6GB po 5 latach
i 50 stacjach w systemie) plików jest uciążliwe.
Ilości rekordów w tabeli z pomiarami – jeśli założymy, że z każdej
stacji pomiarowej zapisywane jest 11 parametrów, to wprost
można określić ze w przypadku schematu II w bazie znajdzie się
11 razy więcej rekordów z pomiarami. Dodatkowym utrudnieniem
w tym przypadku jest fakt, że w tabeli measurements nie ma
bezpośrednio zapisanej informacji o typie pomiaru
przechowywanego w danym rekordzie. Powoduje to, że przy
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 84
wyszukiwaniu zadanego typu parametru konieczne jest
dokonywanie porównania czy typ pomiaru z danego rekordu jest
tym, jaki interesuje klienta zlecającego wyszukiwanie.
Projektowany system obsługuje klientów, których zapytania mają
charakter przekrojowy, a więc wymagają przeglądania sporej części
zgromadzonych rekordów. W takim przypadku zagadnienie
fizycznej objętości bazy, jak i ilości rekordów przestają być tylko
problemem zapewnienia miejsca na dysku twardym.
Opierając się na otrzymanych wynikach i decydując się na
schemat III lub jego wersję rozwiniętą o system archiwizacji
starszych danych należy pamiętać o zaletach i wadach przyjętego
rozwiązania. Takie podejście pozwoli w przyszłości skutecznie
zaplanować prace nad implementacją i wdrożeniem systemu, a także
zapewni wygodę pracy nad jego późniejszym utrzymaniem.
Dodatkowym atutem jest znacznie mniejsza podatność schematu III
na rozpiętość obsługiwanego systemu pomiarowego. Uzyskiwane
wyniki zmieniają się znacznie mniej gwałtownie w stosunku do ilości
stacji lub okresu gromadzenia pomiarów, niż w przypadku schematu
I.
Wyniki testów uwidoczniły, że w wyniku zastosowaniu
indeksów, schemat III notuje dłuższe czasy wykonania kwerend dla
małej ilości danych. Sytuacja taka ma miejsce na przykład
w porównaniu czasów zapytań testowych dla okresu 1 miesiąca
i 1 roku. Opóźnienie to nie stanowi jednak problemu ze względu na
bardzo krótki czas wykonania kwerendy dla tak małej liczby rekordów
w tabeli. O ile opóźnienie nie stanowi problemu w sensie wydajności
systemu, może stanowić podpowiedź co do optymalnej ilości danych
w tabeli z pomiarami.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 85
Analizując wyniki testów można określić, że system najlepiej
będzie działał, jeżeli w tabeli z pomiarami przechowywane będą
pomiary z około 1 roku. Można to osiągnąć tworząc dodatkową tabelę
z pomiarami starszymi niż sprzed roku. Starsze pomiary można
archiwizować okresowo, na przykład raz na miesiąc.
6.1. Zalety wybranego rozwiązania
Schemat III okazał się najlepszym wyborem w kontekście
projektowanego systemu dzięki połączeniu ze sobą takich cech jak:
Umiarkowany rozmiar bazy danych
Zminimalizowana ilość rekordów przechowujących dane pomiarowe
Brak konieczności sprawdzania typu pomiaru przy wyszukiwaniu
zadanego parametru
Prostota zapisu danych – nie ma potrzeby rozbijania każdego
zestawu danych przesłanego ze stacji pomiarowej, na kilka
kwerend zapisujących.
Pod względem wydajności schemat III na tle rozwiązań I i II
prezentuje się bardzo dobrze. Nie wymaga przeprowadzania
dodatkowych operacji podczas zapisu danych lub odczytu z bazy.
Jego struktura sprzyja także sprawnej obsłudze zapytań, jakie będą
najbardziej interesowały klientów. Klienci korzystający z bazy danych
pomiarów parametrów środowiska, potrzebują danych odniesionych
do konkretnej lokalizacji. Schemat III umożliwia wygodne utworzenie
indeksów dla pól używanych w określaniu lokalizacji, na której dane
zostały pobrane. To duża zaleta, ponieważ przy tak dużej ilości
danych, poprawnie utworzone indeksy pozwalają znacząco skrócić
czas wykonania zapytań, a co za tym idzie - znacząco poprawić
interakcje użytkownika z systemem.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 86
6.2. Wady wybranego rozwiązania
Decydując się na wybór pewnego rozwiązania trzeba być
świadomym wad, jakie wybrany schemat posiada. W przypadku
schematu III największą wadą będzie stosunkowo mała skalowalność
systemu. Jeśli bowiem zajdzie konieczność obsługi więcej niż jednego
regionu ilość danych w tabeli measurements będzie przyrastała
proporcjonalnie szybciej. Taka sytuacja niesie za sobą, jak wykazano
w testach, zwiększenie objętości bazy i co za tym idzie, wydłużenie
czasu wykonania kwerend. Należy także pamiętać, że schemat III
jest podatny na spowolnienie zapisu przez stosowanie indeksów.
Poza kwestią wydajności stosując schemat III ograniczamy
elastyczność systemu w kwestii udostępniania danych innym
podmiotom. Samo udostępnienie jest oczywiście możliwe, ale
kontrola dostępu, może okazać się trudna. Jako przykład może
posłużyć sytuacja, gdy klient płaci za dostęp do wybranego
parametru, na przykład temperatury. Jeśli zajdzie taka sytuacja,
schemat bazodanowy nie wspiera kontroli dostępu do konkretnych
danych. Nie ma możliwości identyfikowania konkretnych parametrów
bezpośrednio w bazie danych. W takim przypadku można
implementować kontrolę dostępu w warstwie aplikacji obsługującej
system, ale rozwiązanie nie będzie tak elastyczne jak identyfikowanie
praw użytkownika wprost na zasobach bazy danych.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 87
7. WNIOSKI
Celem pracy była ocena wydajności hydrometeorologicznych
baz danych, stworzonych w środowisku MySQL 5.0. Wynik
przeprowadzonej oceny ma posłużyć rozwiązaniu problemu
wydajnego gromadzenia i udostępniania danych
hydrometeorologicznych. W ocenie jakości rozwiązań rozpatrywano
trzy kryteria: wydajność zapisu, wydajność odczytu oraz objętość
bazy danych.
Cel został osiągnięty, wyniki przeprowadzonych testów
pozwoliły określić charakterystyki poszczególnych rozwiązań.
Schemat I, to rozwiązanie przewidujące przechowywanie
wszystkich danych w pojedynczej tabeli. Pomimo, że spełniał
wymagania funkcjonalne, prezentował gorszą wydajność niż schemat
III – wydzielający dane lokalizacyjne do osobnych tabel. Jego piętą
Achillesową okazała się kwerenda wyszukująca sumy opadów dla
wybranej stacji, z ostatnich 3 godzin.
Schemat II, który zakładał rozdzielenie poszczególnych
pomiarów na pojedyncze rekordy, okazał się całkowicie nietrafioną
koncepcją. Zapis każdego zestawu danych, otrzymanego ze stacji,
wymagał utworzenia 11 rekordów, zamiast 1 w pozostałych
rozwiązaniach. Takie podejście zaowocowało dziesięciokrotnym
zwiększeniem objętości bazy danych oraz znacznym wydłużeniem
czasu wykonania zapytań.
Schemat III, okazał się najlepszą propozycją. Spełnia on
stawiane wymagania funkcjonalne, a także prezentuje dobry
stosunek wydajności do objętości. We wszystkich testach okazał się
wydajniejszy od schematu I.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 88
Wyniki testów pokazały też, długi czas wykonania kwerendy
wyszukującej sumy opadów dla poszczególnych stacji. Czas ten, nie
powinien mieć negatywnego wpływu na codzienna pracę systemu.
Wynika to z faktu, że jako zapytanie statystyczne, kwerenda ta jest
stosunkowo rzadko wykorzystywana.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 89
8. Spisy
8.1. Spis Ilustracji
RYS. 1 PRZYROST LICZBY GROMADZONYCH POMIARÓW W CZASIE DLA ZAŁOŻONEJ LICZBY STACJI. 26 RYS 2. SCHEMAT I – WSZYSTKIE GROMADZONE DANE ZAPISYWANE SĄ W JEDNEJ TABELI. ............ 44 RYS 3. SCHEMAT II – POSZCZEGÓLNE WARTOŚCI POMIARÓW PRZECHOWYWANE JAKO OSOBNE
REKORDY.................................................................................................................................... 46 RYS 4. SCHEMAT III – TABELE ODZWIERCIEDLAJĄCE FIZYCZNE MODELE DANYCH. ......................... 47 RYS. 5. ZALEŻNOŚĆ OBJĘTOŚCI PLIKÓW BAZY DANYCH OD CZASU GROMADZENIA POMIARÓW DLA
SYSTEMU 5 STACJI I TABELI PRZECHOWUJĄCEJ POMIARY BEZ INDEKSÓW................................ 57 RYS. 6. ZALEŻNOŚĆ OBJĘTOŚCI PLIKÓW BAZY DANYCH OD CZASU GROMADZENIA POMIARÓW DLA
SYSTEMU 5 STACJI I TABELI PRZECHOWUJĄCEJ POMIARY Z INDEKSAMI. .................................. 57 RYS. 7. ZALEŻNOŚĆ OBJĘTOŚCI PLIKÓW BAZY DANYCH OD CZASU GROMADZENIA POMIARÓW DLA
SYSTEMU 50 STACJI I TABELI PRZECHOWUJĄCEJ POMIARY BEZ INDEKSÓW. ............................ 58 RYS. 8. ZALEŻNOŚĆ OBJĘTOŚCI PLIKÓW BAZY DANYCH OD CZASU GROMADZENIA POMIARÓW DLA
SYSTEMU 50 STACJI I TABELI PRZECHOWUJĄCEJ POMIARY Z INDEKSAMI. ................................ 58 RYS 9. ZALEŻNOŚĆ CZASU ZAPISU DANYCH OD DŁUGOŚCI OKRESU GROMADZENIA POMIARÓW DLA
SYSTEMU 5 STACJI I TABELI PRZECHOWUJĄCEJ POMIARY BEZ INDEKSÓW ................................ 60 RYS. 10. ZALEŻNOŚĆ CZASU ZAPISU DANYCH OD DŁUGOŚCI OKRESU GROMADZENIA POMIARÓW
DLA SYSTEMU 5 STACJI I TABELI PRZECHOWUJĄCEJ POMIARY Z INDEKSAMI ............................ 61 RYS. 11. ZALEŻNOŚĆ CZASU ZAPISU DANYCH OD DŁUGOŚCI OKRESU GROMADZENIA POMIARÓW
DLA SYSTEMU 50 STACJI I TABELI PRZECHOWUJĄCEJ POMIARY BEZ INDEKSÓW. ..................... 62 RYS. 12. ZALEŻNOŚĆ CZASU ZAPISU DANYCH OD DŁUGOŚCI OKRESU GROMADZENIA POMIARÓW
DLA SYSTEMU 50 STACJI I TABELI PRZECHOWUJĄCEJ POMIARY Z INDEKSAMI.......................... 62 RYS. 13. ZESTAWIENIE CZASU WYSZUKIWANIA DLA SYSTEMU 5 STACJI I TABELI PRZECHOWUJĄCEJ
POMIARY BEZ INDEKSÓW. .......................................................................................................... 65 RYS. 14. ZESTAWIENIE CZASU WYSZUKIWANIA DLA SYSTEMU 5 STACJI I TABELI PRZECHOWUJĄCEJ
POMIARY Z INDEKSAMI............................................................................................................... 65 RYS. 15. ZESTAWIENIE CZASU WYSZUKIWANIA DLA SYSTEMU 50 STACJI I TABELI
PRZECHOWUJĄCEJ POMIARY BEZ INDEKSÓW ............................................................................. 66 RYS. 16. ZESTAWIENIE CZASU WYSZUKIWANIA DLA SYSTEMU 50 STACJI I TABELI
PRZECHOWUJĄCEJ POMIARY Z INDEKSAMI................................................................................. 66 RYS. 17. ZESTAWIENIE CZASU WYKONANIA KWEREND TESTOWYCH DLA SYSTEMU 5 STACJI I TABELI
PRZECHOWUJĄCEJ POMIARY BEZ INDEKSÓW, Z POMINIĘCIEM SCHEMATU II ............................ 67 RYS. 18. ZESTAWIENIE CZASU WYKONANIA KWEREND TESTOWYCH DLA SYSTEMU 5 STACJI I TABELI
PRZECHOWUJĄCEJ POMIARY Z INDEKSAMI, Z POMINIĘCIEM SCHEMATU II................................ 67 RYS. 19. ZESTAWIENIE CZASU WYKONANIA KWEREND TESTOWYCH DLA SYSTEMU 50 STACJI I
TABELI PRZECHOWUJĄCEJ POMIARY BEZ INDEKSÓW, Z POMINIĘCIEM SCHEMATU II ................ 68 RYS. 20. ZESTAWIENIE CZASU WYKONANIA KWEREND TESTOWYCH DLA SYSTEMU 50 STACJI I
TABELI PRZECHOWUJĄCEJ POMIARY Z INDEKSAMI, Z POMINIĘCIEM SCHEMATU II.................... 69 RYS. 21. ZESTAWIENIE CZASU WYKONANIA KWEREND TESTOWYCH DLA SYSTEMU 5 STACJI I TABELI
PRZECHOWUJĄCEJ POMIARY BEZ INDEKSÓW, Z POMINIĘCIEM SCHEMATU II I KWERENDY 4 ... 70 RYS. 22. ZESTAWIENIE CZASU WYKONANIA KWEREND TESTOWYCH DLA SYSTEMU 5 STACJI I TABELI
PRZECHOWUJĄCEJ POMIARY Z INDEKSAMI, Z POMINIĘCIEM SCHEMATU II I KWERENDY 4....... 70 RYS. 23. ZESTAWIENIE CZASU WYKONANIA KWEREND TESTOWYCH DLA SYSTEMU 25 STACJI I
TABELI PRZECHOWUJĄCEJ POMIARY BEZ INDEKSÓW, Z POMINIĘCIEM SCHEMATU II I KWERENDY 4 ............................................................................................................................. 71
RYS. 24. ZESTAWIENIE CZASU WYKONANIA KWEREND TESTOWYCH DLA SYSTEMU 25 STACJI I
TABELI PRZECHOWUJĄCEJ POMIARY Z INDEKSAMI, Z POMINIĘCIEM SCHEMATU II I KWERENDY 4 ................................................................................................................................................ 71
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 90
RYS. 25. ZESTAWIENIE CZASU WYKONANIA KWEREND TESTOWYCH DLA SYSTEMU 50 STACJI I
TABELI PRZECHOWUJĄCEJ POMIARY BEZ INDEKSÓW, Z POMINIĘCIEM SCHEMATU II I KWERENDY 4 ............................................................................................................................. 72
RYS. 26. ZESTAWIENIE CZASU WYKONANIA KWEREND TESTOWYCH DLA SYSTEMU 50 STACJI I
TABELI PRZECHOWUJĄCEJ POMIARY Z INDEKSAMI, Z POMINIĘCIEM SCHEMATU II I KWERENDY 4 ................................................................................................................................................ 72
RYS. 27. ZOBRAZOWANIE RÓŻNIC W CZASACH WYKONANIA KWEREND DLA SYSTEMU 5 STACJI I TABELI PRZECHOWUJĄCEJ WYNIKI BEZ INDEKSÓW, Z POMINIĘCIEM SCHEMATU II .................. 75
RYS. 28. ZOBRAZOWANIE RÓŻNIC W CZASACH WYKONANIA KWEREND DLA SYSTEMU 5 STACJI I TABELI PRZECHOWUJĄCEJ WYNIKI Z INDEKSAMI, Z POMINIĘCIEM SCHEMATU II ...................... 75
RYS. 29. ZOBRAZOWANIE RÓŻNIC W CZASACH WYKONANIA KWEREND DLA SYSTEMU 25 STACJI I TABELI PRZECHOWUJĄCEJ WYNIKI BEZ INDEKSÓW, Z POMINIĘCIEM SCHEMATU II .................. 76
RYS. 30. ZOBRAZOWANIE RÓŻNIC W CZASACH WYKONANIA KWEREND DLA SYSTEMU 25 STACJI I TABELI PRZECHOWUJĄCEJ WYNIKI Z INDEKSAMI, Z POMINIĘCIEM SCHEMATU II ...................... 77
RYS. 31. ZOBRAZOWANIE RÓŻNIC W CZASACH WYKONANIA KWEREND DLA SYSTEMU 25 STACJI I
TABELI PRZECHOWUJĄCEJ WYNIKI Z INDEKSAMI, Z POMINIĘCIEM SCHEMATU II I KWERENDY 4................................................................................................................................................... 78
RYS. 32. ZOBRAZOWANIE RÓŻNIC W CZASACH WYKONANIA KWEREND DLA SYSTEMU 50 STACJI I TABELI PRZECHOWUJĄCEJ WYNIKI BEZ INDEKSÓW, Z POMINIĘCIEM SCHEMATU II .................. 78
RYS. 33. ZOBRAZOWANIE RÓŻNIC W CZASACH WYKONANIA KWEREND DLA SYSTEMU 50 STACJI I TABELI PRZECHOWUJĄCEJ WYNIKI Z INDEKSAMI, Z POMINIĘCIEM SCHEMATU II ...................... 79
RYS. 34. ZOBRAZOWANIE RÓŻNIC W CZASACH WYKONANIA KWEREND DLA SYSTEMU 50 STACJI I
TABELI PRZECHOWUJĄCEJ WYNIKI Z INDEKSAMI, Z POMINIĘCIEM SCHEMATU II I KWERENDY 4................................................................................................................................................... 80
RYS. 35. WPŁYW INDEKSÓW NA CZAS WYKONANIA KWERENDY 1. .................................................. 81 RYS. 36. CZAS WYKONANIA KWERENDY 2 ODNIESIONY DO ILOŚCI STACJI POMIAROWYCH, TABELA
PRZECHOWUJĄCA POMIARY BEZ INDEKSÓW, POMIARY GROMADZONE PRZEZ 5 LAT. ................ 81 RYS. 37. CZAS WYKONANIA KWERENDY 2 ODNIESIONY DO ILOŚCI STACJI POMIAROWYCH, TABELA
PRZECHOWUJĄCA POMIARY Z INDEKSAMI, POMIARY GROMADZONE PRZEZ 5 LAT. ................... 82
8.2. Spis tabel
TABELA 1. PRZYKŁADOWA TABELA Z NADMIAROWOŚCIĄ DANYCH ..................................................... 13 TABELA 2. PRZYKŁAD TABELI PRZECHOWUJĄCEJ STACJE POMIAROWE .............................................. 15 TABELA 3. PRZYKŁAD TABELI PRZECHOWUJĄCEJ POMIARY PRZED NORMALIZACJĄ ........................... 15 TABELA 4. PRZYKŁAD TABELI PRZECHOWUJĄCEJ STACJE POMIAROWE .............................................. 16 TABELA 5. PRZYKŁAD TABELI PRZECHOWUJĄCEJ POMIARY PO SPROWADZENIU DO DRUGIEJ POSTACI
NORMALNEJ ................................................................................................................................ 16 TABELA 6. LICZBA POMIARÓW W ZALEŻNOŚCI OD ILOŚCI STACJI I CZASU DZIAŁANIA SYSTEMU ..... 26 TABELA 7. OBJĘTOŚĆ POMIARÓW W ZALEŻNOŚCI OD TYPU DANYCH I OKRESU DZIAŁANIA SYSTEMU.
................................................................................................................................................... 27 TABELA 8. SPECYFIKACJA SERWERA TESTOWEGO.............................................................................. 51 TABELA 9. OBJĘTOŚĆ BAZY DANYCH [MB] DLA SCHEMATU I............................................................ 59 TABELA 10. OBJĘTOŚĆ BAZY DANYCH [MB] DLA SCHEMATU II....................................................... 59 TABELA 11. OBJĘTOŚĆ BAZY DANYCH [MB] DLA SCHEMATU III ...................................................... 59 TABELA 12. CZAS ZAPISU DANYCH [S] DLA SCHEMATU I ................................................................. 63 TABELA 13. CZAS ZAPISU DANYCH [S] DLA SCHEMATU II ................................................................ 63 TABELA 14. CZAS ZAPISU DANYCH [S] DLA SCHEMATU III .............................................................. 63 TABELA 15. ZESTAWIENIE CZASÓW WYSZUKIWANIA [S] DLA POSZCZEGÓLNYCH SCHEMATÓW PRZY
SYSTEMIE 5 STACJI I TABELI PRZECHOWUJĄCEJ WYNIKI BEZ INDEKSÓW ................................. 73 TABELA 16. ZESTAWIENIE CZASÓW WYSZUKIWANIA [S] DLA POSZCZEGÓLNYCH SCHEMATÓW PRZY
SYSTEMIE 5 STACJI I TABELI PRZECHOWUJĄCEJ WYNIKI Z INDEKSAMI ..................................... 73 TABELA 17. ZESTAWIENIE CZASÓW WYSZUKIWANIA [S] DLA POSZCZEGÓLNYCH SCHEMATÓW PRZY
SYSTEMIE 25 STACJI I TABELI PRZECHOWUJĄCEJ WYNIKI BEZ INDEKSÓW ............................... 73
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 91
TABELA 18. ZESTAWIENIE CZASÓW WYSZUKIWANIA [S] DLA POSZCZEGÓLNYCH SCHEMATÓW PRZY SYSTEMIE 25 STACJI I TABELI PRZECHOWUJĄCEJ WYNIKI Z INDEKSAMI ................................. 74
TABELA 19. ZESTAWIENIE CZASÓW WYSZUKIWANIA [S] DLA POSZCZEGÓLNYCH SCHEMATÓW PRZY SYSTEMIE 50 STACJI I TABELI PRZECHOWUJĄCEJ WYNIKI BEZ INDEKSÓW ............................... 74
TABELA 20. ZESTAWIENIE CZASÓW WYSZUKIWANIA [S] DLA POSZCZEGÓLNYCH SCHEMATÓW PRZY SYSTEMIE 50 STACJI I TABELI PRZECHOWUJĄCEJ WYNIKI Z INDEKSAMI................................... 74
8.3. Literatura
[1.] Allen S., 2006, “Modelowanie danych”, Apress, w Polsce: Helion. [2.] Anahory, S., & Murray, D., 1997, “Data Warehousing in the Real World”,
Harlow [3.] Czasopismo „Professional Programming Software for SAP DB” - artykuł
“Zbiory rozmyte”, grudzień 2004 [4.] Codd, E. F., 1970, "A relational model of data for large shared data
banks", Communications of the ACM [5.] Date, C. J., Darwen, H., 2000, “Foundation for Future Database Systems:
The Third Manifesto”, 2nd edition, Addison-Wesley Professional. [6.] Date, C.J., 2003, “An Introduction to Database Systems”, Eighth Edition,
Addison Wesley. [7.] David M. Kroenke, 1997, “Database Processing: Fundamentals, Design,
and Implementation”, Prentice-Hall, Inc. [8.] Elmasri R., Navathe B. S., 2005, “Wprowadzenie do systemów baz
danych”, Addison-Wesley, w Polsce: Helion [9.] Inmon H. William, Hackathorn D. Richard, 1994, “Using the Data
Warehouse”, John Wiley & Son's [10.] Kent, W., 1983, “A Simple Guide to Five Normal Forms in Relational
Database Theory”, Communications of the ACM, vol. 26 [11.] Lightstone S., Teorey T., Nadeau T., 2005, “Database Modeling & Design:
Logical Design, 4th edition”, Morgan Kaufmann Press [12.] Lightstone S., Teorey T., Nadeau T., 2007, “Physical Database Design: the
database professional's guide to exploiting indexes, views, storage, and more”, Morgan Kaufmann Press
[13.] Powell G., 2005, “Beginning Database Design”, Wrox Publishing [14.] Pyle, Dorian, 2003, “Business Modeling and Data Mining”, Morgan
Kaufmann [15.] Schneider D. Robert, 2005, „MySQL Database Design and Tuning”, MySQL
Press
8.4. Linki
[L1] http://www.edm2.com/0612/msql7.html - Wprowadzenie do Relacyjnych baz danych.
[L2] http://en.wikipedia.org/wiki/Relational_database - Relacyjne bazy danych [L3] http://en.wikipedia.org/wiki/Database - Historia baz danych [L4] http://en.wikipedia.org/wiki/Database_management_system - Systemy
zarządzania bazami danych [L5] http://en.wikipedia.org/wiki/Relational_model - Relecyjny model danych [L6] http://www.databasejournal.com/sqletc/article.php/1469521 - Relacyjne bazy
danych – wprowadzenie.
Piotr Nowak „Ocena wydajności hydrometeorologicznych baz danych w MySQL 5.0.” 92
9. ABSTRAKT
Na przestrzeni ostatnich lat, dokonała się rewolucja
w technologiach pomiarowych. Tradycyjne mierniki analogowe są
wypierane przez nowocześniejsze urządzenia cyfrowe. Szybki rozwój
technologii cyfrowych spowodował lawinowy przyrost ilości danych
gromadzonych przez różne systemy pomiarowe. Szczególnym
przypadkiem takiego systemu, jest system monitoringu środowiska.
Ta praca jest opisem badania wydajności baz danych
hydrometeorologicznych, stworzonych w środowisku MySQL 5.0.
W dokumencie zawarte są podstawy teoretyczne systemów
bazodanowych. Określono także kryteria według jakich można
dokonać oceny jakości schematu bazy danych. Sformułowano
wymagania funkcjonalne jakie musi spełniać baza danych
hydrometeorologicznych. Wyjaśnione zostały takie pojęcia jak:
relacyjny model danych oraz normalizacja baz danych. Na podstawie
przedstawionej teorii, zostały zaproponowane trzy schematy
bazodanowe oraz zestaw testów wydajności. Przeprowadzone testy
pozwoliły wytypować najlepsze z zaproponowanych rozwiązań.
Analiza wyników uwidoczniła zagadnienia, na jakie należy zwrócić
szczególną uwagę projektując bazę danych.
Aktualna sytuacja w branży IT pokazuje, że projektując system
informatyczny, nie można pominąć kwestii zastosowania technologii
bazodanowej. Twierdzenie to tyczy się zarówno dużych systemów
komercyjnych, jak i mniejszych, akademickich lub biurowych.