praca magisterska new2 - IIGWholmes.iigw.pl/~rszczepa/dyplomy/2069_Piotr_Nowak.pdfo jakości...

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


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


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.


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.


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,


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.


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


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.


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ą


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ę


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.


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.


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]


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.


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.


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:


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.


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.


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.


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.


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.


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:


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.


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.


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.


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.


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.


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.


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.


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.


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].


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.


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ę.


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:


sieci komórkowe – wiadomości SMS

komunikatory internetowe – Gadu Gadu, Jabber, AIM, ICQ itp.

email

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.


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.


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.


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


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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:


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 {


Uruchom scenariusz testowy X


Wypisz czas potrzebny na wykonanie scenariusza

Utwórz indeksy


Uruchom scenariusz testowy X


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.


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.


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.


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


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.


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.


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

]


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


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

]


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

]


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.


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



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



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.


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.


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]


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


0

200

400

600

800

1000

1200

0 10 20 30 40 50 60 70

miesiące

czas [

s]


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.


0

2000

4000

6000

8000

10000

12000

14000

0 10 20 30 40 50 60 70

miesiące

czas [

s]


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]


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.


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



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



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



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.


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.


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


czas [

s]


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.


0

50

100

150

200

250

1 12 60 1 12 60 1 12 60

I II III


czas [

s]


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


czas [

s]


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ń.


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


czas [

s]


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


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


czas [

s]


Rys. 19. Zestawienie czasu wykonania kwerend testowych dla systemu 50 stacji i tabeli przechowującej pomiary bez indeksów, z pominięciem schematu II


0

5

10

15

20

25

30

35

40

45

50

1 12 60 1 12 60


czas [

s]


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.


0.0

0.5

1.0

1.5

2.0

2.5

3.0

3.5

1 12 60 1 12 60

I III


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


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.


0

2

4

6

8

10

12

14

16

18

20

1 12 60 1 12 60


czas [

s]



0.0

0.2

0.4

0.6

0.8

1.0

1.2

1.4

1 12 60 1 12 60

I III


czas [

s]



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.


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


czas [

s]



0.0

0.1

0.2

0.3

0.4

0.5

0.6

1 12 60 1 12 60


czas [

s]



Wykresy na rysunkach 25 i 26 dokumentują wyniki testów

przeprowadzone dla symulacji systemu obsługującego dużą sieć 50

stacji pomiarowych.


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


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


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




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


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



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.


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


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


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.


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


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.


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



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


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.


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]


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.


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.


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


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.


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.


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.


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.


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.


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



TABELI PRZECHOWUJĄCEJ POMIARY BEZ INDEKSÓW, Z POMINIĘCIEM SCHEMATU II I KWERENDY 4 ............................................................................................................................. 72


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. 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. 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


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.


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.

praca magisterska new2 - IIGWholmes.iigw.pl/~rszczepa/dyplomy/2069_Piotr_Nowak.pdfo jakości...

Documents

Transcript of praca magisterska new2 - IIGWholmes.iigw.pl/~rszczepa/dyplomy/2069_Piotr_Nowak.pdfo jakości...