pobierz plik referatu

Transkrypt

Rozdział monografii: 'Bazy Danych: Rozwój metod i technologii', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2008
Rozdział 18
w
Blokowanie ścieżki i poddrzewa w hierarchicznych
zasobach danych
w
1 Wstęp
da
.b
w
Streszczenie. W pracy proponujemy wykorzystanie etykietowania węzłów
dokumentu XML do celów efektywnego zarządzania blokadami. Rozważamy
dwa rodzaje tzw. blokad strukturalnych, którymi są blokada ścieżki oraz blokada zakresu, rozumianego jako pewien podzbiór węzłów dokumentu wyznaczony przez parę etykiet. Proponujemy algorytmy konsolidacji blokad współdzielonych, wyznaczające spójny zbiór pokrywający, będące formą przetwarzania wstępnego, które upraszcza i przyspiesza działanie menedżera blokad.
Wykorzystanie etykiet XML rozważamy zarówno w kontekście protokołu
B2F (blokowanie dwufazowe – 2PL) jak i protokołów kooperacyjnych, proponując dwa algorytmy dla menedżera kooperacyjnego.
pl
s.
Rosnące znaczenie dokumentów XML w systemach informatycznych sprawia, że coraz
bardziej popularne stają się tzw. rodzime (native) systemy przetwarzania, które oprócz
efektywnej obsługi mechanizmów przechowywania, wyszukiwania oraz aktualizacji powinny umożliwiać przetwarzanie współbieżne. Nawet pobieżna analiza kodu źródłowego
dowolnego systemu zarządzania relacyjną bazą danych uzmysławia skalę zadań związanych z obsługą synchronizacji transakcji współbieżnych oraz odtwarzania. Przypadek baz
danych XML jest jeszcze bardziej skomplikowany, gdyż leżący u jego podstaw hierarchiczny model danych operuje bardziej złożonymi obiektami i pojęciami. W niniejszym
rozdziale chcemy się zająć obsługą blokad pewnych typowych dla dokumentów XML
obiektów takich jak: ścieżka, zakres węzłów (zgodny z pewnym porządkiem enumeracji)
oraz poddrzewo. Zauważmy, że zarządzanie blokadami zakładanymi na pojedynczych węzłach dokumentu XML (czyli blokadami ekstensjonalnymi) jest kwestią, która nie wychodzi
poza zakres obejmujący konwencjonalne systemy baz danych. Zauważmy też, że monografia [1] w żaden sposób nie ogranicza swych rozważań do baz relacyjnych, czyniąc je adekwatnymi również w przypadku współbieżnego przetwarzania dokumentów XML.
Pomysłem prezentowanym w tej pracy jest wykorzystanie tzw. etykiet węzłów do celów
efektywnego zarządzania współbieżnością w systemach rodzimych baz danych XML. Etykiety węzłów są pewnymi obiektami danych, inteligentnymi identyfikatorami, które oprócz
Andrzej Sikorki
Politechnika Poznańska, Instytut Automatyki i Inżynierii Informatycznej, ul. Piotrowo 3a, 60-965
Poznań, Polska
email:[email protected]
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2008
A. Sikorski
w
tego, że jednoznacznie identyfikują węzły dokumentu XML, pozwalają również na ustalenie ich wzajemnego położenia (przykładowo rodzic-potomek) w strukturze danych [9],
[15]. Własność ta jest niezmiernie przydatna do celów efektywnego przetwarzania zapytań
w języku XPath, zarówno w systemach rodzimych jak i hybrydowych (relacyjno-rodzimych) [4], [5]. W niniejszej pracy pokazujemy, że menedżer blokad może korzystać z etykiet w zarządzaniu pewnym szczególnym typem blokad intensjonalnych, nazywanych
przez nas blokadami strukturalnymi, zakładanymi na zbiorach wierzchołków znajdujących
się w relacjach określonych przez strukturę hierarchiczną.
Wyodrębnione przez nas blokady strukturalne, wynikają z obiektowego charakteru dokumentu XML i mają za zadanie odzwierciedlić powiązania pomiędzy poszczególnymi
składowymi modelu obiektowego. Podobnie jak w przypadku blokad intensjonalnych,
blokady strukturalne zakładane są na zbiory obiektów, jednakże tym razem zbiór wyznaczany jest na podstawie wzajemnych powiązań między obiektami. Korzystając z nowych
dokonań w zakresie identyfikowania obiektów dokumentu XML, w naszej pracy pokazujemy, że zarządzanie blokadami tego typu może być realizowane z dużą efektywnością, porównywalną z efektywnością implementacji blokad ekstensjonalnych, zakładanych na pojedynczych węzłach.
w
w
2 Model dokumentu XML, etykiety
da
.b
Chociaż prezentowane wyniki uzyskano w ramach prac nad zagadnieniami współbieżnego
przetwarzania dokumentów XML dotyczą one generalnie hierarchicznych struktur danych.
Model struktury hierarchicznej przyjęty w naszych rozważaniach pokazany jest na rys. 1.
Składa się on z węzłów oznaczonych kółkami, między którymi występują powiązania określające hierarchię: rodzic-potomek (child) oraz rodzeństwo (sibling). Powiązanie określone
jako sibling jest nieco rozszerzone, tj. w przypadku gdy węzeł jest najmłodszy z rodzeństwa, sibling wskazuje na młodsze rodzeństwo najbliższego z przodków, które takie rodzeństwo posiada. Sibling jest wskazaniem pustym, jeśli takiego przodka nie ma. Wskazania takie wystąpią w skrajnej prawej ścieżce drzewa.
child
2
sibling
3
sibling
pl
s.
1
6
7
sibling? (uncle)
4
5
Rys. 1. Wierzchołki drzewa zaetykietowane w porządku preorder
Węzły w przyjętym modelu dokumentu są zaetykietowane. Na rys. 1 etykietami są numery
wyznaczone w porządku preorder. To zaetykietowanie okaże się wystarczające do celów
naszych rozważań. Niemniej należy pamiętać, że w ogólnym przypadku obiekt danych będący etykietą powinien spełniać szereg wymagań, na które składają się [15]:
230
Blokowanie ścieżki i poddrzewa w hierarchicznych zasobach danych
w
− wzajemne położenie w hierarchii między wierzchołkami może być ustalone na podstawie porównania wartości ich etykiet,
− zmiana struktury drzewa, wynikająca z modyfikacji, usuwania bądź dodawania
wierzchołków nie może powodować ponownego etykietowania,
− etykiety powinny mieć ograniczone wymagania pamięciowe,
− etykiety powinny sprawnie współpracować z funkcjami XPath oraz XQuery.
Dla celów tej pracy istotny jest pierwszy z powyższych wymogów, spełniany przez ponumerowanie preorder. Wymogiem niespełnionym jest żądanie by zmiana struktury (np.
wstawienie węzła) nie pociągała za sobą konieczności przeliczenia etykiet. Numerowanie
preorder nie ma tej własności, jeśli używa się liczb całkowitych. Obecnie dwiema metodami etykietowania lepiej lub gorzej spełniającymi wymogi dot. modyfikowania struktury
są ORDPATHs firmy Microsoft [9] (US Patent 6889226) oraz Prime [15]. My zakładamy
jedynie, że etykiety są obiektami danych dającymi się liniowo uporządkować.
w
w
3 Blokady strukturalne
da
.b
Dające się wyodrębnić w hierarchicznym zasobie danych struktury takie jak ścieżka, poddrzewo czy określony etykietami zakres są naturalnymi przedmiotami przetwarzania w bazie danych dokumentów XML. W związku z tym powstaje konieczność efektywnego zarządzani blokadami zakładanymi na tych strukturach. Praca [3] podaje dwie zasadnicze
przyczyny, dla których blokady strukturalne są pożądane. Po pierwsze, przetwarzanie struktury danych może odbywać się niezgodnie z porządkiem hierarchicznym, tj. dostęp do potomka może zostać uzyskany z pominięciem węzłów rodzicielskich. W takim przypadku
zachodzi potrzeba zablokowania całej ścieżki od korzenia do przetwarzanego węzła. Najprostszym rozwiązaniem jest wędrówka po tej ścieżce z jednoczesnym zakładaniem blokad
na kolejne wierzchołki. Takie rozwiązanie jest nieefektywne zarówno pod względem złożoności czasowej (zależność od głębokości wierzchołka) jak i pod względem pamięciowym,
co wynika z konieczności założenia i utrzymywania pewnej liczby blokad ekstensjonalnych. Należy również zauważyć, że w przypadku architektury serwera korzystającej z zewnętrznej implementacji DOM [11] z osadzonym w niej interpreterem XPath, wszelki
dostęp do wynikowych wierzchołków odbywa się z pominięciem prowadzących do nich
ścieżek.
Zakładanie blokady na poddrzewo, drugi obok ścieżek charakterystyczny obiekt, jest
proste, jeśli założyć, że dostęp do jego wierzchołków będzie odbywał się poprzez korzeń.
Założenie to może jednak poważnie ograniczyć interpreter XPath i to nie tylko ze względu
na wspomniane w [3], [8] skoki, zmieniające drzewo w ogólny graf. Architektura menedżera danych może preferować inne porządki przetwarzania, wyszukiwania czy też modyfikacji. W takiej sytuacji korzystne mogłoby być efektywne sprawdzenie czy dany wierzchołek
został zablokowany a jeśli tak, to w jakim trybie, bez konieczności uprzedniego przechodzenia ścieżki wiodącej do niego od korzenia.
Blokady zakresów ograniczonych wartościami etykiet mogą być interesujące ze względu
na wsparcie dla eskalacji blokad i tzw. granulacji wieloziarnistej (MGL multi granularity
locking) [2]. Inaczej niż w relacyjnych bazach danych, gdzie MGL postuluje pewien ściśle
zhierarchizowany zestaw obiektów danych, w dokumencie XML zablokowany zakres może
być określony dowolnie. Powinien on wynikać z analizy statystycznej gęstości blokad ekstensjonalnych założonych przez transakcję. W przypadku przekroczenia progu określonego
w konfiguracji, menedżer dokonuje eskalacji, usuwając blokady ekstensjonalne i zastępując
ją pojedynczą blokadą zakresu. Zauważmy, że „ziarna” w modelu relacyjnym wynikają
pl
s.
231
A. Sikorski
z pojęć tego modelu oraz technik implementacji (krotka, strona menedżera danych, tabela,
klaster itp.) W dokumencie XML liczba dostępnych, naturalnych poziomów granulacji
odpowiada wysokości drzewa. Niemniej, można też rozważać czysto statystyczne podejście, w którym menedżer blokad ignoruje strukturę dokumentu (tj. zakresy nie odpowiadają
poddrzewom).
w
3.1 Blokada ścieżki
Zablokowanie ścieżki odbywa się poprzez zapamiętanie przez menedżera blokad etykiety
węzła leżącego na jej końcu. Jeżeli menedżer ma rozstrzygnąć czy węzeł N leży na zablokowanej ścieżce to sprawdzany jest następujący predykat:
w
is _ path _ locked( N ) ≡ ∃is _ locked( X ) ∧ label( N ) < label( X ) < label( sibling( N ))
X
w
Gdzie label(N) oznacza etykietę przypisaną węzłowi N, natomiast sibling(N) oznacza opisane w p.2 rodzeństwo. Przyjmujemy dodatkowo, że label(null) przyjmuje pewną wartość
maksymalną, nieużywaną do etykietowania węzłów znajdujących się w drzewie.
1
da
.b
2
4
12
9
8
5
6
11
3
10
7
pl
s.
Rys. 2. Blokada ścieżki określona wartością etykiety
Rozważmy teraz przykład (rys. 2). Jeżeli menedżer blokad otrzyma polecenie zablokowania węzła oznaczonego etykietą 10 oraz ścieżki do niego wiodącej, to zostanie zapamiętana
etykieta wraz z odpowiednią adnotacją o typie blokady. Próba uzyskania dostępu do dowolnego węzła leżącego na ścieżce zostanie poprzedzona sprawdzeniem predykatu. Dla 3
okaże się, że istnieje takie x że 3<x<11 (x=10). Koszt tego sprawdzenia przy użyciu indeksu porządkującego zbiór blokad wyniesie najwyżej log(n), gdzie n jest liczbą założonych
blokad.
3.2 Blokada zakresu
Analogicznie jak w przypadku blokady ścieżki, menedżer przechowuje jedynie wartości
etykiet. Tym razem jednak zapamiętywana informacja o założonej blokadzie jest zaopatrzona w dwie etykiety identyfikujące odpowiednio początek i koniec zablokowanego za232
kresu. Odpowiedni predykat, za pomocą którego menedżer sprawdza czy węzeł N leży
w zablokowanym zakresie ma teraz postać:
is _ range _ locked ( N ) ≡
∃ label ( X ) < label ( N ) < label (Y ) ∧ is _ locked ( X , Y )
X ,Y
w
Menedżer musi więc sprawdzić, czy istnieje obiekt identyfikujący blokadę o dwóch etykietach pomiędzy którymi znajduje się bieżący węzeł. W szczególności może zachodzić
Y=sibling(X), jeśli zakres dotyczy poddrzewa. Ponieważ zbiór blokad można przeszukiwać
tylko względem jednego klucza, szczegółowemu omówieniu zagadnienia efektywnego
rozstrzygania tego predykatu poświęcony zostanie kolejnym punkt. Okaże się przy tym, że
należy oddzielnie rozpatrzyć przypadek blokad wyłącznych (exclusive - przypadek najprostszy), blokad współdzielonych dla blokowania dwufazowego oraz blokad współdzielonych dla blokowania kooperacyjnego (przypadek najbardziej złożony). Najpierw jednak
podamy przykład.
w
w
1
3
2
da
.b
9
4
8
5
6
12
10
11
7
Rys. 3. Blokada zakresu określona parą wartości etykiet
pl
s.
Na rys. 3 przedstawiona jest sytuacja, gdy zablokowany jest zakres określony przez węzły o
etykietach 3 oraz 11. Przykładowo dla wierzchołka 10 menedżer może stwierdzić, że istnieje blokada opatrzona etykietami 3 oraz 11, a więc jest 3<10<11.
4 Blokada wyłączna zakresu
Identyfikowanych dwiema etykietami blokad zakresu nie da się poindeksować tak by
w przypadku ogólnym rozstrzygać odpowiedni predykat w czasie log(n). Niemniej sprawdzenie czy węzeł znajduje się w zakresie zablokowanym w trybie wyłącznym okazuje się
proste. Wystarczy bowiem sprawdzić dla danego węzła wartość największego poprzednika
identyfikującego początek zablokowanego zakresu. Następnie należy jedynie sprawdzić czy
etykieta identyfikująca koniec zakresu jest większa od etykiety sprawdzanego węzła. Jeżeli
takiej blokady nie ma, to, jak można łatwo pokazać, węzeł nie może być zablokowany.
Podamy teraz równoważną, korzystającą z tego spostrzeżenia, postać predykatu, dającą się
zweryfikować w czasie log(n). Najpierw wprowadzamy predykat pomocniczy:
233
A. Sikorski
left _ range( N ) ≡ max{label ( X ) : is _ locked ( X , Y ) ∧ label ( X ) < label ( N )}
Dla danego węzła dokumentu XML wyznacza on etykietę węzła będącego początkiem
zablokowanego obszaru takiego, że leży on na lewo od węzła będącego argumentem i takiego, że jego etykieta określająca początek ma maksymalną wartość. Zmodyfikowany
predykat przybierze postać:
is _ range _ locked _ exclusive( N ) ≡ is _ locked (left _ range( N ), Y ) ∧ label (Y ) > label ( N )
w
w
By go sprawdzić efektywnie wystarcza żeby menedżer blokad utrzymywał indeks porządkujący rosnąco blokady względem etykiet określających początki zakresu. Zauważmy, że
utrzymywanie posortowanego zbioru początków zakresów nie wprowadzi dodatkowego
narzutu na działanie menedżera blokad, ponieważ blokady ekstensjonalne i tak są na ogół
przechowywane w indeksie uporządkowanym według identyfikatorów (kluczy) obiektów.
w
5 Blokada współdzielona zakresu
da
.b
Przypadek blokady współdzielonej jest bardziej złożony, gdyż obszary zablokowane mogą
się częściowo pokrywać. Rozwiązaniem w tym przypadku jest utrzymywanie przez menedżera dodatkowej struktury danych zawierającej spójne obszary pokryte blokadami współdzielonymi. Zaproponujemy więc mechanizm wstępnego przetwarzania dla blokad współdzielonych, który będzie wyznaczać takie właśnie obszary określone etykietami. Zauważmy, że utrzymywanie struktury danych przechowującej informacje o spójnych obszarach
zablokowanych (a nie tylko o założonych blokadach) znowu pozwoli na sprawdzenie
w czasie log(n) czy wierzchołek jest zablokowany, gdzie n jest tym razem liczbą zakresów
spójnych. Niemniej nakład związany z utworzeniem i utrzymywaniem tej dodatkowej
struktury zależy od trybu pracy menedżera. Inaczej można postępować w przypadku blokowania dwufazowego B2F (blokady mogą być zdejmowane tylko w momencie zakończenia transakcji), inaczej gdy menedżer obsługuje jakąś wersję protokołu kooperacyjnego
operującego blokadami w sposób bardziej swobodny.
pl
s.
5.1 Zarządzanie współdzielonymi blokadami zakresu dla protokołu B2F
Dla protokołu B2F możemy przyjąć, że zdejmowanie blokad (w tym również zdejmowanie
blokad zakresu) jest zdarzeniem zachodzącym rzadko w stosunku do częstotliwości, z jaką
napływają żądania założenia blokady; zdejmowanie może mieć miejsce jedynie w momencie zakończenia transakcji. Dlatego jest dopuszczalne, by menedżer w momencie zakończenia transakcji dokonywał aktualizacji stanu pomocniczej struktury danych poprzez jej
ponowne wygenerowanie dla każdego dokumentu XML, w którym zakończona transakcja
utrzymywała blokady. Zauważmy, że aktualizacja w przypadku pojawienia się nowej blokady jest prosta i może być łatwo zintegrowana ze sprawdzaniem przez menedżera możliwości jej założenia, gdyż w obu przypadkach musi być przeszukany odpowiedni indeks.
Każdorazowo, gdy transakcja jest zakończona i zdjęte zostaną uzyskane przez nią blokady, menedżer wywołuje procedurę CoverSet (implementacja w C# na rys. 4) Wynikiem
wywołania tej procedury jest wyznaczenie ciągu spójnych zakresów pokrytych blokadami
współdzielonym uzyskanymi przez aktywne transakcje. Dla obszarów spójnych można już
stosować ten sam zmodyfikowany predykat, który podaliśmy dla przypadku blokad wyłącznych.
234
public static List<XmlNodeRangeLock>
CoverSet(List<XmlNodeRangeLock> rangeLocks)
{
List<XmlNodeRangeLock> set = new List<XmlNodeRangeLock>();
List<XmlNodeRangeLock> sortedRangeLocks =
SortByLeftAsc(rangeLocks);
XmlNodeRangeLock last =
new XmlNodeRangeLock(NegInfinity, NegInfinity);
w
w
foreach (XmlNodeRangeLock xnrl in sortedRangeLocks)
if (xnrl.left.value > last.right.value)
{ last = new XmlNodeRangeLock(xnrl); set.Add(last);}
else if (xnrl.right.value > last.right.value)
last.right.value = xnrl.right.value;
return set;
}
Rys. 4. Implementacja funkcji znajdującej obszary spójne
w
5.2 Zarządzanie współdzielonymi blokadami zakresu dla protokołów kooperacyjnych
da
.b
Inaczej niż w przypadku protokołu B2F, transakcje kooperacyjne mogą zakładać i zdejmować blokady w dowolnym momencie. W poprzednim punkcie pokazaliśmy, że zdjęcie
współdzielonej blokady zakresu jest związane z koniecznością ponownego wygenerowania
zbioru zakresów pokrywających. Jest więc możliwe, że korzyści wynikające z zastosowania mniej restrykcyjnego protokołu zostaną utracone na skutek dodatkowego obciążenia
menedżera blokad.
Prostym rozwiązaniem może być opóźnianie zdejmowania blokad. Takie czysto techniczne rozwiązanie w oczywisty sposób niweluje zalety blokowania kooperacyjnego, gdyż
obiekty zwolnione przez transakcje nadal pozostawałyby zablokowane. Jest to o tyle niepożądane, że aplikacje kooperacyjne i tak mogą ponosić pewne dodatkowe koszty związane
z utrzymywaniem spójności danych na poziomie aplikacyjnym [10].
Rozwiązaniem, które tutaj zaproponujemy, jest minimalizacja pokrycia zakresu. Jeżeli
menedżer blokad utrzymywałby dodatkowo minimalną listę blokad (minimalną w sensie
długości listy) pokrywającą obszar spójny, to jak łatwo zauważyć lista taka może być wykorzystana do celów optymalizacji przetwarzania, bowiem jedynie usunięcie blokady zakresu wchodzącego w skład tejże listy powoduje, że zakres musi zostać zaktualizowany.
Skoro lista ta jest minimalna, wynika stąd, że prawdopodobieństwo przynależności zdejmowanej blokady zakresu do tejże listy jest minimalne. Dlatego też menedżer blokad będzie musiał dokonywać aktualizacji zakresów tak rzadko jak to jest to tylko możliwe.
Algorytm wyznaczający minimalne pokrycie znajduje również listę spójnych zakresów
zablokowanych w trybie współdzielonym oraz dodatkowo minimalną listę blokad pokrywających każdy z tych zakresów. Podamy dwa warianty tego algorytmu: optymalny oraz
rozszerzony. Pierwszy z nich charakteryzuje się krótkim czasem wykonania; drugi zaś
umożliwia znalezienie wszystkich wariantów minimalnego pokrycia. Uzasadnimy dalej, że
możliwość rozpatrzenia większej liczby kombinacji blokad zakresu może być pożądana w
przypadku menedżera blokad działającego w trybie kooperacyjnym.
Implementacja w C# algorytmu optymalnego podana jest na rys. 5. Algorytm ten ma
złożoność liniową co już dowodzi jego optymalności, gdyż każda pojedyncza blokada zakresu musi być choć raz rozpatrzona jako kandydat na składową minimalnego pokrycia.
Funkcja MinCover1Pass wyznacza ciągi zakresów dla poszczególnych obszarów spójnych posługując się utrzymywanym przez menedżera blokad indeksem porządkującym
pl
s.
235
A. Sikorski
początki zakresów(Å{1}). Zwracamy uwagę na fakt, że w momencie wykonania instrukcji
oznaczonej komentarzem (Å{2}) wiadomo już, że długość zakresu nie może być krótsza
od bieżącej oraz, że zakres stający się poprzednikiem wstawianego nowego zakresu musi
należeć do minimalnego pokrycia. Obydwu własności dowodzi się w prosty sposób. Jeśli
chodzi o rząd złożoności to jest on liniowy, jeżeli pominąć etap sortowania.
w
da
.b
w
w
public static List<List<XmlNodeRangeLock>>
MinCover1Pass(List<XmlNodeRangeLock> rangeLocks)
{
List<List<XmlNodeRangeLock>> set =
new List<List<XmlNodeRangeLock>>();
List<XmlNodeRangeLock> range=null;
XmlNodeRangeLock last=null;
XmlNodeLabel l=MinLabel();
foreach (XmlNodeRangeLock xnrl in SortByLeftAsc(rangeLocks))
if (xnrl.left.value > l.value) //Å{1}
{
last = xnrl;
range = new List<XmlNodeRangeLock>();
set.Add(range);
range.Add(last); l = last.right;
} else
if (xnrl.right.value > l.value)
{
if (range.Count > 1 &&
range[range.Count - 2].right.value > xnrl.left.value)
range[range.Count - 1] = xnrl;//Å{2}
else range.Add(xnrl);// Å{3}
last = xnrl; l = last.right;
}
return set;
}
Rys. 5. Optymalny algorytm znajdowania minimalnego pokrycia
pl
s.
Algorytm optymalny wyznacza tylko pewne szczególne, zachłanne, pokrycie minimalne,
gdyż, co łatwo można pokazać, bieżące pokrycie minimalne ma zawsze maksymalny zasięg
(w sensie uporządkowania etykiet). Jednakże, transakcje kooperacyjne mogą dostarczać
menedżerowi blokad pewnych dodatkowych informacji odnośnie planowanych interakcji
z obsługiwaną przezeń bazą danych. Przykładowo, menedżer może być w stanie oszacować
czas trwania transakcji kooperacyjnej – wiadomo, ze transakcje kooperacyjne bywają długotrwałe. Jeżeli istniałaby możliwość wyznaczania (przeglądania) wielu wariantów minimalnego pokrycia, to menedżer mógłby stosować dodatkowe kryteria przy ustalaniu wariantu optymalnego. Wskazane mogłoby być umieszczenie w takim pokryciu blokad, o których wiadomo, że w najbliższym czasie zostaną przez swoje transakcje utrzymane.
Zaproponowany przez nas rozszerzony algorytm wyznaczania minimalnej listy blokad
jest dwuprzebiegowy. Jako wynik zwraca listę list, dla każdego spójnego zakresu wyznaczając minimalny podzbiór blokad zakresu pokrywający spójny obszar. Kod z rys. 6 zawiera eksperymentalną implementację. Pierwszy przebieg (oznaczony komentarzem Å{1})
obejmuje posortowanie blokad rosnąco względem początków oraz przegląd posortowanej
listy w celu wyznaczenia minimalnych długości ciągów zakresów pokrywających zakres
spójny. Długość ta jest przechowywana w pomocniczym polu pred. Zakres wyznaczający
początek obszaru spójnego ma w tym polu liczbę 0. Drugi przebieg (Å{2}) przegląda zakresy w porządku malejącym, tym razem względem końców zakresów. Każdorazowo znajdowany jest poprzednik na liście minimalnej lub początek zakresu spójnego. Kluczowa jest
w tym przypadku instrukcja (Å{3}), ponieważ warunek może być spełniony wielokrotnie
236
każdorazowo można więc zastosować dodatkowe kryteria wyboru oparte o informacje
przekazane menedżerowi przez transakcje. Wykorzystanie możliwości zamiany ostatniego
zakresu w minimalnym pokryciu wymaga drobnej modyfikacji zamieszczonego kodu.
public static List<List<XmlNodeRangeLock>>
MinCover(List<XmlNodeRangeLock> rangeLocks)
{
List<XmlNodeRangeLock> sortedRangeLocks=
SortByLeftAsc(rangeLocks);
w
w
foreach (XmlNodeRangeLock xnrl in sortedRangeLocks) //Å{1}
{
if(xnrl.pred==int.MaxValue) xnrl.pred = 0;
foreach(XmlNodeRangeLock xnrl1 in
GetSuccessors(xnrl, sortedRangeLocks))
nrl1.pred =min( xnrl.pred + 1,xnrl1.pred);
}
}
da
.b
w
sortedRangeLocks = SortByRightDesc(rangeLocks);
//Å{2}
List<List<XmlNodeRangeLock>> set =
new List<List<XmlNodeRangeLock>>();
List<XmlNodeRangeLock> range = null;
int pred = 0;
foreach (XmlNodeRangeLock xnrl in sortedRangeLocks)
{
if (pred == 0)
{
range = new List<XmlNodeRangeLock>();
set.Add(range); range.Add(xnrl);
}
else
if (pred == xnrl.pred + 1)// Å{3}
range.Add(xnrl);
pred = xnrl.pred;
}
return set;
Rys. 6. Algorytm rozszerzony
pl
s.
Poprawność algorytmu rozszerzonego wynika z faktu, że jest on pewnym szczególnym
zastosowaniem schematu Dijkstry używanego do wyznaczania minimalnych dróg w grafach. Zadanie znalezienia minimalnego pokrycia zakresu daje się bowiem zakodować jako
problem wyznaczenia drogi minimalnej długości w grafie o równych wagach (długościach)
krawędzi. W tym przypadku pojedyncze zakresy odpowiadają wierzchołkom. Krawędzie
łączą te wierzchołki, których odpowiadające im zakresy mają część wspólną. Zauważmy
jednak, że znajdowanie minimalnego pokrycia nie jest izomorficzne z zadaniem znalezienia
drogi o minimalnej długości (używając terminologii algebry problem jest monomorficzny
[6])
Odnośnie złożoności obliczeniowej możemy zauważyć, że stosują się w tym przypadku
wszystkie ustalenia dotyczące algorytmu Dijkstry (por.[7]) .Wynosi ona nlog(n), gdzie n
oznacza liczbę wierzchołków (w tym przypadku blokad zakresów). Konieczność dwukrotnego posortowania zakresów występuje tylko w implementacji eksperymentalnej, ponieważ
menedżer blokad (co już wielokrotnie podkreślaliśmy) i tak utrzymuje pomocniczy indeks
zawierający identyfikatory zablokowanych obiektów. Indeks ten może być dodatkowo
wykorzystywany do celów generowania listy minimalnej. Jednakże nawet w przypadku
menedżera eksperymentalnego lub menedżera zarządzającego zbiorami blokad w inny
237
A. Sikorski
sposób złożoność obliczeniowa jest ta sama, ponieważ sortowanie ma również rząd złożoności obliczeniowej nlog(n).
6 Wnioski
w
Idea wykorzystania etykiet węzłów została przez nas przetestowana w ramach eksperymentalnej implementacji rodzimego systemu zarządzania bazą danych XML. Architektura eksperymentalnego systemu oparta została na pomyśle przedstawionym w [11], gdzie zaproponowano wykorzystanie biblioteki MSXML2 w charakterze procesora zapytań oraz menedżera danych. Jako podstawowy tryb pracy przyjęliśmy poziom izolacji, w którym modyfikowane węzły są blokowane w trybie wyłącznym natomiast ścieżki do nich wiodące w
trybie współdzielonym. Jak łatwo zauważyć koszt zablokowania węzła wraz ze ścieżką jest
równy kosztowi wstawienia pojedynczego obiektu do indeksu.
Etykietowanie węzłów w implementacji eksperymentalnej oparliśmy na pomysłach mających swoje źródła w pochodzących z lat 80-tych pracach Tarjana i Willarda [12], [13],
[14]. Wymienieni autorzy uzyskali wówczas interesujące wyniki dotyczące indeksowania
danych za pomocą etykiet pozwalających na wstawianie nowych obiektów bez konieczności ponownego etykietowania lub z etykietowaniem o koszcie ograniczonym przez stałą.
Zagadnień tych nie omawiamy, gdyż do wyłożenia proponowanej idei zarządzania blokadami wystarcza by etykiety dały się liniowo uporządkować.
Dalsze prace nad eksperymentalnym systemem obejmują wsparcie dla MGL oraz zbadanie przydatności przetwarzania wstępnego na poziomie pojedynczych transakcji. Zbiory
pokrywające wyznaczone dla blokad założonych przez jedną transakcję mogą być wykorzystane przez mechanizm eskalacji blokad, gdyż zbiór blokad zakresów tworzących spójny
obszar może być zastąpiony pojedynczą blokadą. Konsolidacja zakresów może być realizowana na bieżąco – menedżer blokad sprawdza wtedy, czy żądanie założenia nowej blokada dotyczy zakresu już zablokowanego, czy też żądanie to częściowo z takim zakresem
się pokrywa. W pierwszym przypadku można uznać żądanie za spełnione, w drugim przypadku menedżer sprawdza czy jest możliwe rozszerzenie blokady i następnie, w przypadku
pozytywnym, aktualizuje odpowiednio swój stan.
da
.b
w
w
1.
2.
3.
4.
5.
6.
7.
8.
pl
s.
Literatura
Bernstein P.A., Hadzilacos V., Goodman N.: Concurrency Control and Recovery in Database
Systems Addison-Wesley, 1987.
Gray J., Reuter A.: Transaction Processing, Concepts and Techniques, Morgan Kaufmann
Publisher, San Francisco, CA 94104-3205, USA, 2000.
Helmer S., Kanne C.-C., Moerkotte G.: Evaluating lock-based protocols for cooperation on
XML documents, ACM SIGMOD Record, v.33 n.1, March 2004.
Jagadish H.V. et al.: A Native XML Database, VLDB Journal 11/4, 2002, p. 274-291.
Al-Khalifa S., Jagadish H.V, Koudas N., Patel J.M., Srivastava D., Wu Y: A Primitive for
Efficient XML Query Pattern Matching, Proceedings of the 18th International Conference on
Data Engineering, IDCE’02.
Lidl R.: Algebra dla przyrodników i inżynierów, PWN, Poznań, 1983.
Lipski W.: Kombinatoryka dla programistów, WNT Warszawa, 1989.
Moerkotte G.: Anatomy of a Native XML Base Management System, VLDB Journal 11/4, 2002,
p. 292-314.
238
9.
10.
11.
12.
w
13.
O’Neil P. et al.: ORDPATHs: Insert-Friendly XML Node Labels, SIGMOD, Paris, 2004, p. 903908.
Rusinkiewicz M. e al.: Towards a Cooperative Transaction Model – The Cooperative Activity
Model, Proceedings of the 21th VLDB Conf. Zurich, 1995.
Sikorski A.: Menedżer blokad protokołu B2F dla baz danych XML, Systemy Czasu
Rzeczywistego, Karpacz, 2007.
Sleator D.D., Tarjan R.E.: Amortized Efficiency of List Updates and Paging Rules, CACM
28(2), February 1985.
Tarjan R.E.: Data Structures and Network Algorithms, Society for Industrial and Applied
Mathematics, Philadelphia, PA 1983.
Willard. D.E.: Maintaining dense sequential files in a dynamic environment, Proc. 14th ACM
STOC, May 1982.
Wu X., Lee M.L., Hsu W.: A Prime Number Labeling Scheme for Dynamic Ordered XML
Trees, Conference on Data Engineering, 2004.
14.
15.
da
.b
w
w
pl
s.
239
w
da
.b
w
w
pl
s.

pobierz plik referatu

Transkrypt

Podobne dokumenty

Torebka do przechowywania blokad, kłódek, jedna

Wymiana blokad ()

Blokada wyłączników miniaturowych Zestaw blokad do urządzeń

Blokada wyłączników miniaturowych Zestaw blokad do zaworów i

Karta katalogowa htsp - przenosna stacja blokad - hts

Zestaw blokad rozrządu Opel / Renault / Nissan - magnus

Kliknij aby pobrać dokument w formacie PDF

Wykład 7

Kliknij aby pobrać dokument w formacie PDF