Agent zarz ˛ adzaj ˛ acy

Zasadniczym zadaniem agenta zarz ˛adzaj ˛acego jest globalna optymalizacja ru-chu sieciowego z uwzgl˛ednieniem priorytetów projektów. Agent przypisany jest do realizacji pojedynczego projektu. Reprezentuje on u ˙zytkownika we-wn ˛atrz systemu. Odpowiedzialny jest za całokształt operacji zwi ˛azanych z two-rzeniem projektu oraz replikacj ˛a niezb˛ednych danych. Koordynuje realizacj˛e oblicze ´n, a tak ˙ze dostarcza wyniki do u ˙zytkownika systemu.

Agent pracowa´c mo ˙ze w dwóch trybach pracy: kooperacji lub konkurencji z innymi agentami zarz ˛adzaj ˛acymi. Celem pierwszego z nich jest optymalizacja korzy´sci z systemu dla wszystkich jego u ˙zytkowników, drugiego, zapewnienie realizacji zadania pojedynczego u ˙zytkownika.

3.2.1.1 Zarys funkcjonalno´sci

W chwili rozruchu systemu tworzona jest pula agentów zarz ˛adzaj ˛acych. Re-zyduj ˛a oni na fizycznej platformie sprz˛etowej centralnej bazy danych oraz nie posiadaj ˛a mo ˙zliwo´sci (potrzeby) przemieszczania si˛e do innych w˛ezłów syste-mu. Przypominaj ˛a oni zachowaniem demony systemu operacyjnego, oczeku-j ˛ac na nadej´scie zgłosze ´n od u ˙zytkowników. Agent oczekuj ˛acy na zadanie jest w stanie nieaktywnym. Nadej´scie zgłoszenia aktywuje agenta, który odpowie-dzialny b˛edzie za projekt przez cały czas jego istnienia. Zako ´nczenie projektu przez u ˙zytkownika powoduje ponowne przej´scie agenta do stanu nieaktywne-go i powrót do puli agentów oczekuj ˛acych na zgłoszenia.

Podj˛ecie zgłoszenia przez agenta zarz ˛adzaj ˛acego zwi ˛azane jest z wykona-niem akcji przygotowawczych w postaci stworzenia prywatnej kopii centralnej bazy danych, inicjalizacji stosownym schematem danych, a tak ˙ze utworzenia instancji modułu obliczeniowego. Zako ´nczenie sekwencji inicjalizuj ˛acej sygna-lizowane jest u ˙zytkownikowi w oczekiwaniu na decyzj˛e odno´snie szczegóło-wych parametrów projektu.

Lekarz decyduje o maksymalnym czasie dostarczenia oraz ilo´sci danych wymaganych w projekcie. Agent waliduje mo ˙zliwo´s´c realizacji zadania przy uwzgl˛ednieniu bie ˙z ˛acego oraz planowanego obci ˛a ˙zenia systemu. Wynikiem sprawdzenia mo ˙ze by´c stwierdzenie potwierdzaj ˛ace wykonalno´s´c projektu, lub te ˙z odpowied´z negatywna. Pomy´slna weryfikacja mo ˙zliwo´sci realizacji powo-duje przej´scie do fazy wykonawczej.

Agent zarz ˛adzaj ˛acy deleguje zadania szczegółowe do agentów replikuj ˛ a-cych oraz polega na ich ekspertyzie. Oznacza to, i ˙z z globalnego punktu widze-nia sposób realizacji replikacji lokalnej nie jest istotny. Interesuj ˛acym parame-trem ka ˙zdego segmentu sieci jest natomiast maksymalna przepustowo´s´c, rozu-miana jako ilo´s´c danych mo ˙zliwych do przesłania w zadanym kwancie czasu. W pocz ˛atkowej fazie pracy systemu zakłada si˛e oszacowanie dost˛epnej przepu-stowo´sci w oparciu o wiedz˛e dotycz ˛ac ˛a struktury sieci komputerowej. Podczas regularnej pracy statystyki te s ˛a uaktualniane bazuj ˛ac na rezultatach uzyskiwa-nych przez agentów replikuj ˛acych.

Zako ´nczenie replikacji danych powoduje automatyczne przekazanie sygna-łu powoduj ˛acego rozpocz˛ecie kalkulacji przez moduł obliczeniowy. Sytuacja ta sygnalizowana jest u ˙zytkownikowi. Agent oczekuje na zako ´nczenie obli-cze ´n, informuje u ˙zytkownika o tym zdarzeniu oraz przekazuje uzyskane wy-niki oczekuj ˛ac na dalsze polecenia.

3.2.1.2 Okre´slenie mo˙zliwo´sci realizacji

Najbardziej zaawansowane zadanie agenta stanowi sprawdzenie mo ˙zliwo´sci realizacji projektu w ˙z ˛adanym czasie, a tak ˙ze dobór optymalnej sekwencji wy-konawczej. W tym celu u ˙zytkownik musi poinformowa´c agenta o wymaganej strategii działania:

strategia 1 — konkurencja,

strategia 2 — kooperacja.

Skutkuje to w ustawieniu stanu wewn˛etrznego oraz notyfikacji innych agen-tów zarz ˛adzaj ˛acych o dokonanym wyborze. Z formalnego punktu widzenia strategia konkurencji odpowiada minimalizacji maksymalnego kosztu realizacji zada ´n, natomiast strategia kooperacji minimalizacji całkowitego kosztu, przy-j˛etego modelu

Agent utrzymuje w swojej pami˛eci nast˛epuj ˛ace parametry obsługiwanego projektu:

tmax– maksymalny czas realizacji,

a– priorytet,

b– przepustowo´s´c sieci,

t0– czas pocz ˛atkowy,

t₁– czas ko ´ncowy,

i_p – numer identyfikacyjny porz ˛adku pocz ˛atkowego,

io – numer identyfikacyjny porz ˛adku optymalnego.

Walidacja wykonalno´sci projektu odbywa si˛e w poszczególnych krokach decyzyjnych, wykorzystuj ˛ac zaprezentowany uprzednio aparat matematycz-ny. Pierwszym etapem procesu jest okre´slenie priorytetu realizacji projektu a. Obliczany jest on w oparciu o ˙z ˛adany czas dostarczenia danych tmax zgodnie z formuł ˛a:

a = ¹ tmax

. (3.2)

Zakłada si˛e, i ˙z tmax ­ 1. Realizacja tego zało ˙zenia jest zapewniona poprzez

dobór stosownej jednostki czasu dla wszystkich projektów.

Dla ka ˙zdej decyzji wchodz ˛acej w skład optymalizowanej sekwencji osobne podzadanie stanowi okre´slenie maksymalnego przepływu w sieci oraz optyma-lizacja uszeregowania realizacji projektów. W celu wyznaczenia przepustowo-´sci sieci konieczna jest znajomo´s´c zarówno dost˛epnej struktury sieciowej wraz z maksymaln ˛a przepustowo´sci ˛a replikacji poprzez ka ˙zdy łuk, jak i zapotrzebo-wania na dane z poszczególnych w˛ezłów.

Struktura sieciowa przechowywana jest w postaci listy w˛ezłów V identy-fikowanych poprzez indeks unikalny oraz nazw˛e, a tak ˙ze listy kraw˛edzi E, opisanych poprzez indeks wierzchołka pocz ˛atkowego, ko ´ncowego oraz mak-symaln ˛a przepustowo´s´c. Ka ˙zdy w˛ezeł o dodatnim zapotrzebowaniu (wyzna-czonym podczas interakcji z u ˙zytkownikiem) okre´slany jest jako ´zródło danych. Graf uzupełniany jest o specjalny w˛ezeł o charakterze super-´zródła, który ł ˛ aczo-ny jest ze wszystkimi ´zródłami poprzez kraw˛edzie o przepustowo´sci równej zapotrzebowaniu. W rozpatrywanym systemie istnieje wył ˛acznie jeden w˛ezeł docelowy (uj´scie) b˛ed ˛acy centraln ˛a baz ˛a danych.

Dla tak przygotowanej struktury agent oblicza maksymaln ˛a przepustowo´s´c sieci F F . Zgodnie z twierdzeniem Forda – Fulkersona warto´s´c ta równa jest mi-nimalnemu przekrojowi grafu. W przypadku, kiedy wszystkie przesyłane dane s ˛a jednakowego rodzaju stosowany jest algorytm Goldberga – Tarjana. Rozwi ˛ a-zanie zagadnienia dla danych ró ˙znych typów (ang. multi-commodity) wyznacza-ne jest przy pomocy algorytmu Karakostasa.

Poprzez komunikacj˛e z innymi agentami zarz ˛adzaj ˛acymi znane s ˛a projekty aktywnie realizowane w systemie, ich szczegółowe wymagania odno´snie da-nych oraz stosowne warto´sci F F . Wiedza ta jest niezb˛edna w celu wyznaczenia parametru b funkcji celu przyj˛etego modelu. Normalizacja czynnika

odpowia-daj ˛acego za przepustowo´s´c sieci realizowana jest zgodnie ze wzorem:

b = ^{F F}

max F F^. (3.3)

Znajomo´s´c zapotrzebowania na dane Z jest niezb˛edna w celu okre´slenia mo ˙zliwo´sci realizacji projektu. Jednorazowe obliczenie maksymalnej przepu-stowo´sci F F pozwala na oszacowanie mo ˙zliwo´sci realizacji projektu w sytuacji wył ˛aczno´sci dost˛epu do zasobów. W przypadku, kiedy:

t_max < ^Z

F F^, (3.4)

arbitralnie mo ˙zna stwierdzi´c, i ˙z projekt nie jest realizowalny w ˙z ˛adanym czasie. Projekt zostaje odrzucony, a informacja o tym przekazana u ˙zytkownikowi.

Dla przypadku, kiedy ˙z ˛adany czas realizacji jest wi˛ekszy b ˛ad´z równy sto-sunkowi zapotrzebowania do maksymalnej przepustowo´sci niezb˛edna jest kontynuacja walidacji wykonalno´sci, a ˙z do momentu obliczenia wszystkich planowanych cykli wykonawczych, b ˛ad´z stwierdzenia braku mo ˙zliwo´sci reali-zacji na którym´s etapie procesu. Pełny algorytm decyzyjny przedstawi´c mo ˙zna nast˛epuj ˛aco3.1:

F F ←maksymalny przepływ w sieci

while tmax­ Z /F F

do tmax← t_max− 1

if tmax = 0or Z = 0 return true

Z ← Z − F F

F F ←maksymalny przepływ w sieci

return false

Tabela 3.1: Algorytm badaj ˛acy wykonalno´s´c projektu w sytuacji wył ˛aczno´sci dost˛epu do zasobów

Zauwa ˙zmy, i ˙z proste podzielenie zapotrzebowania przez pocz ˛atkowy prze-pływ maksymalny nie gwarantuje realizowalno´sci projektu, gdy ˙z przeprze-pływ mo ˙ze zmniejsza´c si˛e w kolejnych cyklach przetwarzania.

Komplikacja okre´slenia optymalnej sekwencji realizacji projektów zale ˙zy od przyj˛etej strategii działania. W przypadku konkurencji agentów — co odpowia-da problemowi formalnemu n | ait_i−1+ b_i; a_i > 0; b_i > 0; t₀ ­ 0 | min(max(t_i)) — zagadnienie zawsze posiada rozwi ˛azanie o wielomianowej zło ˙zono´sci obli-czeniowej. Parametry wszystkich aktywnych projektów s ˛a dla agentów jawne. Wyznaczenie optimum polega na sortowaniu ilorazu czynnika a oraz b w po-rz ˛adku malej ˛acym. Symboliczny zapis procedury przedstawiony jest w postaci algorytmu3.2.

Dla strategii kooperacji — równowa ˙znej problemowi formalnemu n |

a_it_i−1+ b_i; a_i > 0; b_i > 0; t₀ ­ 0 | minP

t_i — dobór optymalnej sekwencji de-cyzji zale ˙zy od relacji mi˛edzy parametrami a i b. Je ˙zeli pr˛edko´s´c sieci nie jest

whilew systemie istnieje niezoptymalizowany projekt

dopobierz parametry projektu p p[i++] ← p

sortuj(p[], porz ˛adek a/b malej ˛aco)

fori ∈ (0, ilo´s´c projektów - 1)

p[i].t0 ← (i == 0 ? p[i].t0 : p[i–1].t1 p[i].t1 ← (p[i].a + 1) * p[i].t0 + p[i].b

returnp[]

Tabela 3.2: Optymalizacja uporz ˛adkowania w trybie konkurencji

ograniczeniem dla projektu, wówczas czynnik b mo ˙zna pomin ˛a´c. Algorytm wy-znaczaj ˛acy uporz ˛adkowanie optymalne jest podobny jak3.2. Jedyn ˛a ró ˙znic ˛a jest zamiana porz ˛adku sortowania na: sortuj(p[], porz ˛adek a rosn ˛aco).

W sytuacji kiedy wszystkie priorytety a s ˛a identyczne, post˛epowanie jest podobne jak poprzednio, przy czym funkcja porz ˛adkuj ˛aca przyjmuje posta´c: sortuj(p[], porz ˛adek b rosn ˛aco).

Inny przypadek szczególny zachodzi je´sli czynniki b s ˛a sobie równe. Wów-czas szybki algorytm wyznaczaj ˛acy uporz ˛adkowanie optymalne mo ˙zna zapisa´c nast˛epuj ˛aco3.3.

whilew systemie istnieje niezoptymalizowany projekt

dopobierz parametry projektu p p[i++] ← p

sortuj(p[], porz ˛adek a rosn ˛aco) n ← ilo´s´c projektów forkrok ∈ (0, n-3) foropt ∈ (1, n) pr ← (opt==n ? 0 : p[0].b*(1 +Pn k=opt+2 Qk l=opt+2(p[l].a + 1)))

if((krok==0 ? p[krok].t0 : p[krok-1].t1) > pr) p[krok] ↔ p[krok+opt-1]

oblicz t0, t1 dla p[krok]

sortuj(p[], krok+1, n, porz ˛adek a rosn ˛aco)

break

oblicz t0, t1, t1⁰, t2, t2⁰ dla p[n-2], p[n-1]

if(t2⁰ < t2)

p[n-2] ↔ p[n-1]

returnp[]

Tabela 3.3: Optymalizacja uporz ˛adkowania w trybie kooperacji dla b = const W najbardziej skomplikowanym przypadku, kiedy czynniki a, b ró ˙zni ˛a si˛e dla poszczególnych projektów, wyznaczone rozwi ˛azanie jest suboptymalne. Procedura post˛epowania dana jest w postaci algorytmu3.4.

whilew systemie istnieje niezoptymalizowany projekt

dopobierz parametry projektu p p[i++] ← p

sortuj(p[], porz ˛adek a rosn ˛aco) n ← ilo´s´c projektów forkrok ∈ (0, n-2) fori ∈ (1, n) le-mniejsza-pr ← 0 forj ∈ (1, n) if i 6= j si ←Pn−2 k=1 Qk l=1;l6=i;l6=j (p[l].a + 1)

t0 ← (krok==0 ? p[krok].t0 : p[krok-1].t1) le ← t0*(p[krok+i-1].a + 1) + p[krok+i-1].b +

((p[krok+j-1].a + 1)*p[krok+i-1].b + p[krok+j-1].b) * (1 + si) pr ← t0*(p[krok+j-1].a + 1) + p[krok+j-1].b +

((p[krok+i-1].a + 1)*p[krok+j-1].b + p[krok+i-1].b) * (1 + si) le-mniejsza-pr += ((le<pr) ? 1 : 0)

ifle-mniejsza-pr == (n-1) p[krok] ↔ p[krok+i-1] oblicz t0, t1 dla p[krok]

sortuj(p[], krok+1, n, porz ˛adek a rosn ˛aco)

break

oblicz t0, t1 dla p[n-1]

returnp[]

Tabela 3.4: Optymalizacja uporz ˛adkowania w trybie kooperacji

3.2.2 Agent replikuj ˛acy

Agent replikuj ˛acy obsługuje cało´s´c lokalnego procesu integracyjnego od eks-trakcji danych z systemu ´zródłowego, poprzez opcjonalne etapy transformacji, uzupełnienia i korekty informacji, nast˛epuj ˛acej po nich walidacji danych, a ˙z do ko ´ncz ˛acego przetwarzanie ładowania do systemu docelowego. Podstawowym zadaniem agenta replikuj ˛acego jest lokalna replikacja danych, czyli fizyczne kopiowanie pomi˛edzy zadanym zbiorem ´zródłowym, a docelowym poprzez ustalony segment sieci. Agent spełnia rol˛e kontenera wykonawczego dla dedy-kowanych agentów wykonawczych. Dodatkowo, w zakresie jego obowi ˛azków znajduje si˛e dobór wydajnej architektury przetwarzania.

3.2.2.1 Etapy procesu

Z logicznego punktu widzenia przetwarzanie zawsze odbywa si˛e w nast˛epuj ˛ a-cych po sobie etapach zilustrowanych na diagramie3.1.

Dane pobierane s ˛a z systemu ´zródłowego poprzez agenta odczytuj ˛acego. W tym celu niezb˛edne jest umo ˙zliwienie podł ˛aczenia si˛e do okre´slonego

syste-Agent Replikujący System Źródłowy System Docelowy Agent Zapisujący Agent jący Sprawdza-Agent Korygujący Agent Transformu-jący Agent Czytający Bufor Danych Bufor Danych Bufor Danych Bufor Danych

Rysunek 3.1: Model replikacji danych

mu oraz odczyt interesuj ˛acej informacji zgodnie z logik ˛a oraz interfejsami obo-wi ˛azuj ˛acymi w tym systemie.

Kolejnym etapem jest opcjonalna transformacja danych, czyli zmiana formy lub formatu informacji. Zagadnienie to mo ˙zna rozpatrywa´c pocz ˛awszy od tak prostych przypadków jak konwersja typów danych, poprzez mechanizmy wy-szukiwania odpowiednich danych referencyjnych oraz skomplikowane przy-padki ł ˛aczenia danych z ró ˙znych ´zródeł.

Nast˛epny opcjonalny etap to automatyczne uzupełnianie oraz korekta da-nych. Stosunkowo cz˛esto zachodzi sytuacja, kiedy mo ˙zliwe jest automatyczne uzupełnienie brakuj ˛acych danych. Operacj˛e tak ˛a przeprowadzi´c mo ˙zna bazuj ˛ac na ustawieniach systemowych lub u ˙zytkownika oraz niekiedy na dodatkowej logice, która jest znana, ale nie jest zaimplementowana w systemie ´zródłowym. Kolejny opcjonalny etap to walidacja danych, czyli kontrola jako´sci informa-cji. Zachodzi tutaj sprawdzenie zgodno´sci przetwarzanych danych z zadanym zestawem reguł. Zbiór danych rozdzielony zostaje na dane poprawne oraz dane naruszaj ˛ace okre´slon ˛a reguł˛e lub zbiór reguł.

Ostatnim etapem procesu integracyjnego jest ładowanie danych do central-nej bazy danych. Proces ten obsługuje szczegóły poł ˛aczenia oraz zapisu okre´slo-nego rodzaju zbioru danych. Zapisywane mog ˛a by´c zarówno dane poprawne jak i te naruszaj ˛ace pewne reguły.

3.2.2.2 Dost˛epne strategie

Replikacj˛e lokaln ˛a mo ˙zna przeprowadzi´c stosuj ˛ac jedn ˛a z fizycznych architek-tur przetwarzania:

strategia 1 — po stronie systemu ´zródłowego,

strategia 2 — po stronie systemu docelowego,

strategia 3 — zarówno po stronie systemu ´zródłowego, jak i docelowego.

W pierwszym przypadku agent replikuj ˛acy przebywa w fizycznej platfor-mie sprz˛etowej ´zródłowej bazy danych. Odczytywane dane przesyłane s ˛a lo-kalnie z bazy do agenta poprzez JDBC. Jednocze´snie dane zapisywane s ˛a do zdalnej bazy docelowej, równie ˙z poprzez JDBC. W drugim przypadku stosowa-ne protokoły przesyłu danych s ˛a identyczne, zmienia si˛e wył ˛acznie lokalizacja agenta replikuj ˛acego.

Ostatni scenariusz wymaga współpracy dwóch agentów replikuj ˛acych. Je-den z nich przebywa na platformie sprz˛etowej ´zródłowej bazy danych, drugi docelowej. Odczyt danych nast˛epuje poprzez JDBC, nast˛epnie dane przetwa-rzane s ˛a na posta´c tekstow ˛a oraz wysyłane poprzez protokół FTP. Współpra-cuj ˛acy agent odbiera dane w postaci tekstowej, po czym ostatecznie zapisuje poprzez JDBC do lokalnej bazy docelowej.

W zale ˙zno´sci od dost˛epnej konfiguracji sprz˛etowej oraz integrowanych zbiorów danych integracja bezpo´srednia lub te ˙z poprzez wprowadzenie jawnej warstwy transportowej skutkuje w najwy ˙zszej wydajno´sci przetwarzania. Nad-rz˛ednym celem działania agenta jest zastosowanie strategii najbardziej efektyw-nej w konkretnym przypadku integracyjnym.

3.2.2.3 Taktyka post˛epowania

Przeprowadzono liczne badania wydajno´sciowe maj ˛ace na celu okre´slenie naj-lepszej strategii działania. W przypadku replikacji bezpo´sredniej, w wi˛ekszo´sci przebadanych konfiguracji przetwarzanie na komputerze docelowym okazało si˛e bardziej efektywne, ni ˙z operacja przeprowadzona na serwerze ´zródłowym. Replikacja z jawn ˛a warstw ˛a transportow ˛a zrealizowana w sposób równoległy typowo wykazywała przewag˛e nad replikacj ˛a bezpo´sredni ˛a. Odnotowano jed-nak konfiguracje wykazuj ˛ace odmienne zachowanie.

Prognozowanie, która z dost˛epnych architektur b˛edzie pracowa´c w sposób najefektywniejszy jest skomplikowane. Najprostszym sposobem okre´slenia ak-tualnej wydajno´sci jest dokonanie pomiaru bazowanego na przetwarzaniu re-alnych danych. Utrudnienie powoduje fakt, i ˙z wydajno´s´c replikacji mo ˙ze zmie-nia´c si˛e w czasie, w zwi ˛azku ze zmianami obci ˛a ˙zenia serwerów oraz ł ˛acz ˛acych je sieci komputerowych. Sytuacja ta wpływa na zaburzenie warunków pomia-rowych.

W momencie pocz ˛atkowym agent replikuj ˛acy rezyduje po stronie systemu docelowego, czyli centralnej bazy danych. Po dokonaniu czynno´sci inicjalizu-j ˛acych rozpoczyna si˛e regularne przetwarzanie. Agent replikuj ˛acy na bie ˙z ˛aco mierzy oraz zapami˛etuje (składuje) efektywno´s´c wykonania.

Przyj˛ecie nowego zgłoszenia powoduje przemieszczenie si˛e agenta do w˛ezła systemu ´zródłowego oraz wykonanie zadania w nowej lokalizacji. Podobnie jak poprzednio, zapami˛etywana jest pr˛edko´s´c replikacji w bie ˙z ˛acej konfiguracji.

Realizacja kolejnego zadania rozpoczyna si˛e od sklonowania agenta, po czym nast˛epuje przemieszczenie jednego z nich do lokalizacji macierzystej. Po dokonaniu migracji agenci nawi ˛azuj ˛a współprac˛e, a przetwarzanie odbywa si˛e zarówno na serwerze ´zródłowym, jak i docelowym. Przesył danych pomi˛edzy w˛ezłami realizowany jest wykorzystuj ˛ac protokół FTP. Nast˛epuje badanie

bie-˙z ˛acej wydajno´sci replikacji.

Po zako ´nczeniu trzeciego zadania integracyjnego agent replikuj ˛acy porów-nuje wydajno´s´c przetwarzania uzyskan ˛a w ka ˙zdej dost˛epnej konfiguracji. Naj-wydajniejsza z nich zostaje zapami˛etana i u ˙zywana do realizacji kolejnych zgło-sze ´n.

Przedstawiona strategia obarczona jest bł˛edem pomiaru wynikaj ˛acym z po-tencjalnie mocno zró ˙znicowanych danych przetwarzanych w ka ˙zdym ze zgło-sze ´n. Jak wykazały badania praktyczne pr˛edko´s´c replikacji zale ˙zna jest od roz-miaru rekordu. Dodatkowo, nie s ˛a uwzgl˛edniane wyniki replikacji bardzo ma-łych zbiorów danych, gdy ˙z w przypadkach takich widoczny jest wpływ inicja-lizacji procesu na uzyskiwane wyniki pomiarowe.

3.2.2.4 Strategia 3

Najprostsza realizacja przetwarzania z jawn ˛a warstw ˛a transportow ˛a wyma-ga ekstrakcji danych z systemu ´zródłowego, przesyłu pliku stosuj ˛ac protokół FTP oraz ładowania do docelowej bazy danych. Zasadniczym mankamentem tej koncepcji integracji jest sekwencyjno´s´c przetwarzania. Podczas replikacji z bazy danych do pliku tekstowego komputer docelowy nie realizuje ˙zadnego przetwarzania oczekuj ˛ac na dostarczenie danych. Podobnie, podczas ładowa-nia z pliku tekstowego do bazy docelowej komputer ´zródłowy pozostaje zupeł-nie zupeł-nieaktywny.

Bazuj ˛ac na tym spostrze ˙zeniu zaproponowa´c mo ˙zna znacznie wydajniejsz ˛a wersj˛e replikacji z jawn ˛a warstw ˛a transportow ˛a, realizowan ˛a poprzez party-cjonowanie danych, które umo ˙zliwia zrównoleglenie przetwarzania. Podej´scie takie zakłada zapis zadanej ilo´sci rekordów do pliku, po czym nast˛epuje jedno-czesny zapis do nowego pliku oraz przesłanie pierwszej cz˛e´sci do komputera docelowego. Bezpo´srednio po otrzymaniu pliku komputer docelowy rozpocz ˛a´c mo ˙ze zapis do systemu bazodanowego, podczas kiedy komputer ´zródłowy re-alizuje ekstrakcj˛e dalszej cz˛e´sci danych.

Załó ˙zmy, ˙ze strumie ´n danych składa si˛e z N ­ 1 niezale ˙znych partycji oraz oznaczmy:

Extb

n– pocz ˛atek przetwarzania DB –> tekst n–tej partycji danych

Exte

n– koniec przetwarzania DB –> tekst n–tej partycji danych

F tpe

n– koniec transferu FTP n–tej partycji danych

Ldrb

n– pocz ˛atek replikacji tekst –> DB n–tej partycji danych

Ldr_n^e – koniec replikacji tekst –> DB n–tej partycji danych

Rozpocz˛ecie poszczególnych etapów procesu integracyjnego opisa´c mo ˙zna zale ˙zno´sci ˛a:

Ext^b₁ = 0 (3.5)

F tp^b₁ = Ext^e₁ (3.6)

Ldr₁^b = F tp^e₁ (3.7)

Dodatkowo zakładaj ˛ac sekwencyjno´s´c wykonania poszczególnych etapów, zapisa´c mo ˙zna: ∀n ∈ (1, N i

Ext^b_n= Ext^e_n−1 (3.8)

F tp^b_n= max(Ext^e_n, F tp^e_n−1) (3.9)

Ldr^b_n= max(F tp^e_n, Ldr^e_n−1) (3.10) Oznaczmy czas przetwarzania n–tej partycji danych: ∀n ∈ h1, N i

Ext^e_n− Ext^b_n= ∆Extn (3.11)

F tp^e_n− F tpb

n= ∆F tp_n (3.12)

Ldr_n^e − Ldrb

n= ∆Ldr_n (3.13)

Równanie czasu zako ´nczenia procesu ekstrakcji mo ˙zna rozwi ˛aza´c jako:

Ext^e_n=

N

X

n=1

∆Extn (3.14)

Wyliczenie czasu zako ´nczenia transferu FTP oraz replikacji do docelowej bazy danych wymaga w przypadku ogólnym zastosowania algorytmu reku-rencyjnego. Równanie rozwi ˛azuje si˛e bezproblemowo, przy zało ˙zeniu stałego czasu przetwarzania pojedynczego fragmentu danych. Je ˙zeli strumie ´n danych podzielony jest na równe, dostatecznie du ˙ze cz˛e´sci oraz infrastruktura dedyko-wana jest do zadania testowego, zało ˙zenie to wydaje si˛e akceptowalne w celu oszacowania wyników pomiarowych.

Przyjmijmy wi˛ec: ∀n ∈ h1, N i

∆Ext_n= const (3.15)

∆F tp_n= const (3.16)

wówczas: Ext^e_n = N X n=1 ∆Ext_n = n ∆Ext (3.18)

Czas zako ´nczenia procesu FTP wynosi odpowiednio:

F tp^e_n = ( Exte n+ ∆F tp Ext^e_n ­ F tpe n−1 ∨ ( F tpe n−1+ ∆F tp Ext^e_n¬ F tpe n−1 (3.19) co przekształci´c mo ˙zna do postaci:

F tp^e_n= ( n ∆Ext + ∆F tp ∆Ext ­ ∆F tp ∨ ( n ∆F tp + ∆Ext ∆Ext ¬ ∆F tp (3.20) Czas zako ´nczenia procesu ładowania danych do bazy docelowej wynosi z kolei: Ldr^e_n= ( F tpe n+ ∆Ldr F tpe n ­ Ldre n−1 ∨ ( Ldre n−1+ ∆Ldr F tpe n¬ Ldre n−1 (3.21) Pierwsz ˛a cz˛e´s´c formuły przekształci´c mo ˙zna do postaci:

Ldr^e_n=      n ∆Ext + ∆F tp + ∆Ldr ∆Ext ­ ∆F tp ∆Ext ­ ∆Ldr ∨      n ∆F tp + ∆Ext + ∆Ldr ∆Ext ¬ ∆F tp ∆F tp ­ ∆Ldr (3.22) Drug ˛a cz˛e´s´c wyra ˙zenia mo ˙zna zapisa´c jako:

Ldr^e_n=      n ∆Ldr + ∆F tp + ∆Ext ∆Ext ­ ∆F tp ∆Ext ¬ ∆Ldr ∨      n ∆Ldr + ∆F tp + ∆Ext ∆Ext ¬ ∆F tp ∆F tp ¬ ∆Ldr (3.23) Czas zako ´nczenia ładowania danych do docelowej bazy danych równowa ˙z-ny jest z ł ˛acznym czasem realizacji zadania integracyjnego. Formuł˛e zapisa´c mo ˙zna w zwi˛ezłej postaci jako:

T = ∆Ext + ∆F tp + ∆Ldr + (N − 1) max(∆Ext, ∆F tp, ∆Ldr) (3.24) Zgodnie ze wzorem, zwi˛ekszanie ilo´sci partycji powoduje skrócenie czasu replikacji. Nale ˙zy jednak pami˛eta´c o poczynionym zało ˙zeniu na stało´s´c czasu wykonania pojedynczego kroku przetwarzania. W praktyce, zało ˙zenie to prze-staje by´c prawdziwe przy podziale strumienia na zbyt du ˙z ˛a ilo´s´c partycji, przy którym narzut czasowy zwi ˛azany z inicjalizacj ˛a przetwarzania oka ˙ze si˛e istot-ny.

Maksymalny teoretyczny przyrost wydajno´sci wynikaj ˛acy ze zrównolegle-nia przetwarzazrównolegle-nia przewy ˙zsza 65%. Faktyczna poprawa obserwowana w licz-nych badaniach praktyczlicz-nych plasuje si˛e na poziomie 40%.

W dokumencie Index of /rozprawy2/10132 (Stron 65-76)