Budowa indeksu dla systemu OfficeObjects Portal z wykorzystaniem struktur SDDS

1. Budowa indeksu dla systemu OfficeObjects Portal z wykorzystaniem struktur SDDS Piotr Wilczyński Michał Ziółkowski PJWSTK, 2004

2. Plan prezentacji • Założenia pracy • Definicja SDDS • Algorytmy LH i LH* • Porównanie SDDS-2000 i SDDS-LH* • Indeks zbudowany na SDDS-2000 • Indeks zbudowany na SDDS-LH* • Rezultaty pracy

3. Założenia pracy Celem pracy było stworzenie mechanizmu szybkiego wyszukiwania w systemie OfficeObjects Portal przy pomocy zewnętrznego indeksu wykorzystującego struktury SDDS.

4. Definicja SDDS Mówiąc o SDDS mamy na myśli środowisko składające się z dowolnej ilości stanowisk klienckich dzielących plik F. F składa się z dowolnej ilości obiektów indeksowanych kluczami. • Klienci wstawiają obiekty podając OID (klucze główne), wyszukują obiekty (zazwyczaj podając konkretny OID) lub usuwają obiekty. • Plik F przechowywany jest na serwerach. • Klienci i serwery mogą być odrębnymi komputerami w sieci. • Klienci nie wiedzą nic o pozostałych klientach.

5. Definicja SDDS (2) • Każdy serwer udostępnia przestrzeń do składowania obiektów wchodzących w skład F, zwanych kubełkami (bucket). • Serwer może wysyłać obiekty do innych serwerów. • Ilość obiektów przysyłanych do składowania jest nieprzewidywalna i może znacznie przekraczać rozmiar kubełka. • Ilość połączonych serwerów może być bardzo duża (10-100000).

6. Definicja SDDS (3) • SDDS musi spełniać następujące trzy warunki: • Plik musi swobodnie się rozszerzać, ale tylko kiedy używane do tej pory serwery są optymalnie obciążone. • Nie istnieje główny serwer niezbędny do ustalenia adresu obiektu. • Dostęp do plików oraz ich modyfikacja nie powoduje konieczności atomowych odświeżeń stanu pliku u klientów.

7. Algorytm LH* Jednym z algorytmów spełniających powyższe kryteria przy minimalnej ilościprzesyłanych wiadomości jest algorytm LH*. LH* jest generalizacją algorytmu Linear Hashing przeznaczonego dla pojedynczych stanowisk lub wieloprocesorowych komputerów posługujących się pamięcią dzieloną.

8. Algorytm LH* (2) LH* może obsłużyć dowolną ilość klientów i serwerów i pozwala plikom rozszerzać się na dowolną liczbę stanowisk zachowując następujące właściwości: • Plik może powiększyć się do dowolnego rozmiaru przy mniej więcej stałym wypełnieniu kubełków (65-95% w zależności od struktury pliku). • Wstawienie obiektu wymaga zazwyczaj jednej wiadomości (trzech w najgorszym przypadku). • Wyszukanie obiektu po OID wymaga zazwyczaj dwóch wiadomości (czterech w najgorszym przypadku). • Równoległe operacje na pliku o M kubełkach wymagają co najwyżej 2M + 1 wiadomości i między 1, a O(log M) rund wiadomości.

9. Algorytmy mieszające • Algorytmy mieszające działają na strukturach danych analogicznych do opisanej wcześniej (klucz - obiekt). • Wykorzystywana jest pseudolosową funkcja hashującą h. Np. mieszanie przez dzielenie h(c) = c mod M. M = 1, 2, ... • Klucze trafiają do M kubełków o ustalonej pojemności b. • Jeśli kubełek jest pełen w momencie operacji wstawiania nowego klucza to mówimy o kolizji. • W klasycznych metodach rozwiązywania kolizji dołączane są nowe kubełki jako rozszerzenie podstawowego. • Takie podejście powoduje gwałtowne pogorszenie wydajności po przekroczeniu pewnego progu wypełnienia.

10. Dynamiczne funkcje hashujące • Rozwiązaniem jest stworzenie w momencie kolizji funkcji h', która będzie przydzielała nowe adresy części elementów z przepełnionego kubełka i dawała takie same wyniki jak h dla pozostałych kubełków. Taką operację nazywa się podziałem (split), a funkcje – funkcjami podziału (split functions). • Funkcje podziału muszą spełniać następujące kryteria: • Dla przestrzeni kluczy C:h0 : C -> {0, 1, ..., N-1}hi: C -> {0, 1, ..., 2iN-1} • Oraz dla każdego c albohi(c) = hi-1(c)lubhi(c) = hi-1(c) + 2i-1N

11. Wirtualne funkcje hashujące (przykład) Weźmy h0: c = c mod N, gdzie N = 100. Pojemność kubełka b = 5 rekordów. Stosujemy mieszanie przez dzielenie - hi: c = c mod 2iN.

12. Przykład (2) • Tworzymy nowe h: • h(c) = h1(c) jeśli h0(c) = 0 • h(c) = h0(c)

13. Linear hashing • Pokazane powyżej podejście z podziałami w momentach kolizji wymaga jednak przechowywania tabel funkcji. • Funkcje nie wymagające tabel można uzyskać tylko jeśli ustalimy jakiś z góry znany porządek wykonywanych podziałów. • To jest właśnie istota algorytmu liniowego mieszania.

14. Linear hashing (2) • Podziałów kubełków dokonujemy w liniowej kolejności (niezależnie od miejsca wystąpienia kolizji). • Przechowujemy indeks następnego kubełka do podziału – n. • Dla przepełnionych kubełków stosujemy klasyczne metody CRM. • Wszystkie kubełki z danego poziomu zostaną podzielone zanim plik osiagnie następny poziom. Można więc oczekiwać, że liczba rekordów przepełnienia będzie niska.

15. Struktura indeksu LH n 2iN hi+1 hi hi+1 i nazywamy poziomem pliku (file level).

16. Struktura indeksu LH n 2iN hi+1 hi hi+1

17. Struktura indeksu LH n 2i+1N hi+1 i + 1 – nowy poziom pliku

18. Wyliczanie adresu kubełka • Operacja jest bardzo prosta: m := hi(c) if m < n: m := hi+1(c) endif

19. LH* revisited • Bazuje na LH • Każdy kubełek zawiera w nagłówku swój poziom (czyli zastosowaną funkcję mieszającą). • Przepełnienia obsługiwane są w ten sam sposób co w LH. • Kubełki są ponumerowane (0, 1, ...). Numery oznaczają adresy kubełków (istnieje translacja na adresy serwerów – statyczna lub dynamiczna). • Podział pliku następuje w taki sam sposób jak dla LH.

20. Adresowanie • Operacje na obiektach plików w LH* są wykonywane przez klientów. • Algorytm LH zakłada, że wyliczanie adresów oparte jest o poprawne wartości i i n (poziom pliku i nr kubełka do podziału). • W przypadku SDDS takie założenie nie jest prawdziwe – zachodziłaby konieczność istnienia głównego serwera lub replikacja wartości i i n po każdej modyfikacji.

21. Adresowanie (2) • Założenia LH* są inne i nie zakłada się, że klient ma spójny obraz pliku. • Każdy dostęp rozpoczyna się od obliczenia adresu przez klienta (client address calculation). Klient używa swoich wartości i’ i n’, które mogą być niewłaściwe. • Wartości te są odświeżane dopiero po wykonaniu manipulacji przez klienta. • Jako, że klient może zaadresować nieodpowiedni kubełek to każdy serwer wylicza adres jeszcze raz (server address calculation) i ewentualnie przekazuje żądanie dalej. • Po każdym błędzie klient dostaje wiadomość korekcyjną (image adjustment message), która zbliża jego obraz pliku do faktycznego. • W praktyce klienci nie robią zbyt wielu błędów adresowania.

22. Korekcja obrazu pliku u klienta • W przypadku błędów adresowania jeden z serwerów wysyła klientowi wiadomość korekcyjną. A klient aktualizuje swoje wartości i’ i n’. • Celem tej operacji jest zbliżenie tych parametrów do faktycznych i tym samym maksymalizacja liczby kluczy dla których adresy będą wyliczone prawidłowo. • W sytuacji kiedy wszyscy klienci przestaną wstawiać obiekty, a będą ich jedynie wyszukiwać wartości i’ i n’ będą zbiegać do faktycznych. • W przypadku ciągłych operacji modyfikujących aktywniejsi klienci będą mieli obraz bliższy rzeczywistości i będą popełniać mniej błędów.

23. Systemy SDDS Stosowano dwie wersje SDDS: • SDDS-2000 (stworzony przez zespół prof. Litwina), oparty na algorytmie RP* • Własną implementację SDDS-LH* oparty na algorytmie LH* • Systemy różnią się oferowaną funkcjonalnością oraz wydajnością

24. Porównanie systemów SDDS

25. OfficeObjects Portal • System OOP jest obiektową bazą danych zbudowaną głównie na potrzeby portali internetowych i intranetowych • Ze względów architektonicznych OOP charakteryzuje się bardzo słabą wydajnością operacji (m. in. wyszukiwania)

26. Zewnętrzny indeks dla OOP • Jako rozwiązanie problemu wyszukiwania zastosowano zewnętrzny indeks umieszczony fizycznie w strukturze SDDS • Obiekty OOP indeksowane są po wartościach pojedynczych atrybutów

27. Założenia dla indeksu • Indeks dostępny jest w postaci interfejsu programistycznego • Indeks nie jest przezroczysty ani też samoaktualizujący • W indeksie przechowywane są referencje do obiektów OOP • Pozwala to na szybkie pobranie konkretnego obiektu klasy, bez przeglądania całej jej ekstensji

28. Zarys architektury indeksu OOP SDDS API Klient

29. Budowa indeksu Budowa indeksu polega na: • Pobraniu wszystkich obiektów określonej klasy • Odczytaniu wartości wskazanego atrybutu • Wstawieniu referencji do struktury SDDS pod kluczem otrzymanym po zastosowaniu funkcji mieszającej

30. Wyszukiwanie z wykorzystaniem indeksu Wyszukiwanie w indeksie polega na: • Obliczeniu wartości klucza SDDS przez funkcję mieszającą na podstawie argumentu wyszukiwania • Pobraniu referencji r do obiektu OOP z odpowiedniego rekordu SDDS • Pobraniu obiektu o referencji r z OOP • Przekazaniu obiektu do klienta

31. Indeks zbudowany na SDDS-2000 Wrapper API Index Server OOP SDDS Klient

32. Indeks zbudowany na SDDS-2000, 2 • Komunikacja pomiędzy API oraz SDDS odbywa się za pośrednictwem Index Server. • Z uwagi na brak funkcjonalności SDDS-2000 konieczne było zastosowanie bufora do zbudowania struktury rekordów przed wstawieniem ich do SDDS. • Brak aktualizacji oraz usuwania rekordów • Ograniczenia na wielkość pola danych (100 bajtów)

33. Indeks zbudowany na SDDS-LH SDDS Wrapper API OOP Klient

34. Indeks zbudowany na SDDS-LH, 2 • Rozszerzona funkcjonalność w stosunku do SDDS-2000 – aktualizacja, usuwanie, lista plików. • Brak ograniczeń odnośnie wielkości pola danych. • Nie występuje konieczność stosowania dodatkowych warstw pośrednich (jak IndexServer) • Większa wydajność wyszukiwania.

35. Porównanie wydajności systemów

36. Wyniki W wyniku przeprowadzonych testów oraz na stosowanych danych stwierdzono: • Trzykrotne przyspieszenie wyszukiwania dla wiekszego indeksu (SDDS-2000) • Siedmiokrotne przyspieszenie wyszukiwania dla wiekszego indeksu (SDDS-LH)