Metody optymalizacji przez indeksowanie dla obiektowego jêzyka zapytañ***

Transkrypt

1 AUTOMATYKA 2009 Tom 13 Zeszyt 3 Tomasz M. Kowalski*, Pawe³ Cebula*, Kamil Kuliberda*, Jacek Wiœlicki*, **, Rados³aw Adamus*, ** Metody optymalizacji przez indeksowanie dla obiektowego jêzyka zapytañ*** 1. Wprowadzenie Indeks to pomocnicza (nadmiarowa) struktura danych przechowywana na serwerze. Administrator baz danych zarz¹dza pul¹ indeksów, generuj¹c nowe albo usuwaj¹c istniej¹ce w zale noœci od aktualnych potrzeb, maj¹c na celu zwiêkszenie tym samym ca³kowitej wydajnoœci aplikacji. Tak jak w przypadku tradycyjnych ksi¹ ek, indeksy na koñcu ksi¹ ki pozwalaj¹ na szybkie odnalezienie po ¹danej strony, podobnie indeks bazodanowy umo liwia szybki dostêp do obiektów (lub rekordów) spe³niaj¹cych okreœlone kryteria. W zwi¹zku z faktem, e indeksy maj¹ relatywnie ma³y rozmiar (w porównaniu do ca³ej bazy danych), zajêcie dodatkowej przestrzeni dyskowej do ich przechowywania jest ca³kowicie uzasadnione poprzez zysk na wydajnoœci dzia³ania bazy danych. Bardzo efektywna fizyczna organizacja indeksów umo liwia osi¹gniêcie nawet o kilka rzêdów wielkoœci wy szej wydajnoœci. Ogólna idea indeksowania w zorientowanych obiektowo bazach danych nie ró ni siê od indeksowania w bazach relacyjnych [2]. Wiele metod mo e byæ zaadaptowanych z systemów relacyjnych, a nawet ich zastosowanie mo e byæ znacz¹co rozszerzone. Bywaj¹ sytuacje, w których metody indeksacji wziête z relacyjnych baz danych s¹ przestarza³e dla baz danych zorientowanych obiektowo. W szczególnoœci operacje z³¹czenia nie wymagaj¹ szczególnej optymalizacji, poniewa w obiektowych bazach danych potrzeba z³¹czeñ jest znacznie mniejsza ze wzglêdu na obecnoœæ identyfikatorów obiektów oraz jawnych wskaÿnikowych powi¹zañ. * Katedra Informatyki Stosowanej, Politechnika ódzka ** Stypendysta projektu Innowacyjna dydaktyka bez ograniczeñ zintegrowany rozwój Politechniki ódzkiej zarz¹dzanie uczelni¹, nowoczesna oferta edukacyjna i wzmacnianie zdolnoœci do zatrudniania, tak e osób niepe³nosprawnych wspó³finansowany przez Uniê Europejsk¹ w ramach Europejskiego Funduszu Spo³ecznego *** Praca naukowa finansowana ze œrodków na naukê w latach 2008/2009 jako projekt badawczy nr N

2 1530 Tomasz M. Kowalski, Pawe³ Cebula, Kamil Kuliberda, Jacek Wiœlicki, Rados³aw Adamus ODRA (Object Database for Rapid Applications development) jest prototypem systemu zarz¹dzania zorientowan¹ obiektowo baz¹ danych opart¹ na podejœciu stosowym SBA (Stack Based Architecture) [13, 14]. G³ównym celem projektu ODRA jest tworzenie i rozwijanie nowych paradygmatów tworzenia aplikacji bazodanowych oraz wprowadzenie nowego, uniwersalnego, deklaratywnego jêzyka programowania wraz z rozproszonym œrodowiskiem wykonawczym, zorientowanym na bazy danych i obiektowoœæ. ODRA zawiera w³asny jêzyk zapytañ o nazwie SBQL (Stack Basek Query Language), który jest zintegrowany z mo liwoœciami programistycznymi i abstrakcjami, w tym abstrakcjami bazodanowymi: aktualizowane widoki, procedury sk³adowane, transakcje. Wa n¹ cech¹ systemu ODRA jest silnik optymalizacyjny odpowiedzialny za zwiêkszanie wydajnoœci wykonywania zapytañ bazodanowych. Zasadniczym komponentem silnika jest modu³, który optymalizuje zapytania u ywaj¹c indeksacji. G³ówne cechy implementacji indeksowania to: przezroczysty wybór odpowiednich indeksów dla zadanego zapytania (jeœli to mo liwe), automatyczna aktualizacja indeksów w odpowiedzi na zmiany w powi¹zanych danych oraz zarz¹dzanie administracyjne indeksami. Niniejszy artyku³ prezentuje wspomniane trzy aspekty implementacji indeksacji w ODRA. Sekcja 2 przedstawia ogóln¹ architekturê optymalizacji zapytañ w ODRA. Sekcja 3 omawia cechy systemu indeksowania w ODRA. Sekcja 4 opisuje narzêdzia zarz¹dzania indeksami w ODRA. Sekcja 5 ilustruje optymalizacjê zapytañ bazodanowych opart¹ o indeksacjê. Sekcja 6 prezentuje zysk wydajnoœci wynikaj¹cy z proponowanych rozwi¹zañ na podstawie przyk³adowych zapytañ. Sekcja 7 zawiera podsumowanie artyku³u i wnioski. 2. Idea indeksowania w ODRA W uproszczeniu indeks mo e byæ postrzegany jako tabela sk³adaj¹ca siê z dwóch kolumn, gdzie pierwsza z nich zawiera unikaln¹ wartoœæ kluczow¹, natomiast druga przechowuje wartoœæ niekluczow¹. W wiêkszoœci przypadków wartoœæ niekluczow¹ stanowi referencja do obiektu. Wartoœæ kluczowa jest u ywana jako dana wejœciowa dla procedur wyszukuj¹cych opartych o indeksy. W rezultacie, procedura zwraca odpowiadaj¹c¹ wartoœæ z drugiej kolumny tego samego wiersza tabeli. Klucze s¹ zazwyczaj wartoœciami wybranych atrybutów obiektów (gêste indeksy) lub reprezentuj¹ zakres tych wartoœci (indeksy zakresowe). Wartoœci kluczowe mog¹ byæ obliczane przy u yciu wyra eñ, które zawieraj¹ wbudowane funkcje jêzyka zapytañ lub funkcje definiowane przez u ytkownika (indeksy funkcyjne [1]). To podejœcie umo liwia administratorowi stworzenie indeksu odpowiadaj¹cego dok³adnie predykatom w obrêbie najczêœciej pojawiaj¹cych siê zapytañ, tak by ich ewaluacja sta³a siê szybsza i u ywa³a minimalnej iloœci operacji we/wy. W optymalizacji zapytañ indeksy s¹ u ywane w kontekœcie operatora where, w przypadku gdy lewy argument jest zindeksowany wed³ug wartoœci kluczowej prawego argu-

3 Metody optymalizacji przez indeksowanie dla obiektowego jêzyka zapytañ 1531 mentu stanowi¹cego predykat selekcji. Dla du ych baz danych zast¹pienie klauzuli where wywo³aniem funkcji indeksu, mo e powodowaæ zysk wydajnoœci nawet o kilka rz¹dów wielkoœci. Niemniej do osi¹gniêcia tego wzrostu serwer baz danych powinien zapewniaæ przezroczystoœæ indeksów. Oznacza ona, e programista aplikacji z baz¹ danych nie musi byæ œwiadomy istnienia indeksów. Najczêœciej optymalizator zapytañ jest odpowiedzialny za automatyczne wykorzystanie indeksów. Drugi wa ny aspekt przezroczystoœci jest zwi¹zany z utrzymywaniem spójnoœci miêdzy indeksami a indeksowanymi danymi. Jest to problem tzw. automatycznej aktualizacji indeksu. Modyfikacje w bazie powinny byæ automatycznie wykrywane i odzwierciedlane w odpowiednich indeksach Cechy indeksów w ODRA Obecnie implementacja wspiera indeksy oparte na liniowym haszowaniu [5], które mo e byæ ³atwo rozszerzane do rozproszonej wersji SDDS [6] w celu optymalnego wykorzystania zasobów obliczeniowych systemów rozproszonych. Niemniej jednak, istnieje szeroki zakres ró nych struktur indeksów, które mog¹ byæ u yte do indeksowania w obiektowo zorientowanych bazach danych podobnie do rozwi¹zañ obecnych w relacyjnych bazach danych [1, 2, 8, 10]: B-Drzewa, indeksy bitmapowe, itp. Implementacja indeksowania w ODRA wspiera indeksy z wieloma kluczami. W dodatku do typów kluczy wspomnianych wczeœniej (gêstych i zakresowych), wprowadzono typ enum m.in. do zwiêkszenia elastycznoœci indeksowania na wielu kluczach. Ponadto, dziêki w³asnoœciom jêzyka SBQL, tj. ortogonalnoœci i kompozycyjnoœci, zaimplementowane rozwi¹zania dostarczaj¹ generycznego wsparcia dla dowolnych definicji indeksów np. z³o onych z wyra eñ zawieraj¹cych polimorficzne metody i operatory agreguj¹ce. 3. Zarz¹dzanie indeksami Wszystkie indeksy znajduj¹ce siê w bazie danych s¹ zarejestrowane i zarz¹dzane przez menad era indeksów systemu ODRA. Lista wszystkich indeksów i pomocnicze informacje wymagane dla optymizatora s¹ przechowywane wewn¹trz specjalnego modu³u administracyjnego. Ka dy indeks jest skojarzony z modu³em, w którym zosta³ stworzony, a jego nazwa musi byæ unikalna. Dlatego te menad er indeksów sprawdza czy dany indeks istnieje na liœcie referencji do obiektów metabazy opisuj¹cych indeksy u ywaj¹c kombinacji sk³adaj¹cej siê z nazwy modu³u oraz nazwy indeksu: nazwa_modu³u.nazwa_indeksu Przyk³adowy schemat Schemat na rysunku 1 jest wprowadzony jako podstawa dla przedstawionych dalej przyk³adów u ycia indeksów.

4 1532 Tomasz M. Kowalski, Pawe³ Cebula, Kamil Kuliberda, Jacek Wiœlicki, Rados³aw Adamus Rys. 1. Przyk³ad schematu zorientowanego obiektowo Przyk³adowy schemat ilustruje rekordy personelu pewnej firmy. Wprowadzono kilka klas PersonClass, StudentClass, EmpClass, EmpStudentClass oraz dwa typy strukturalne DeptType i AddressType. Trwa³e instancje klas wymienionych powy ej mog¹ byæ dostêpne za poœrednictwem nazw klas ich instancji Person, Student, Emp i w koñcu EmpStudent. Obiekty reprezentuj¹ce departamenty firmy, nazwane Dept maj¹ strukturê DeptType z atrybutem g³ównym name. Instancje klasy EmpClass reprezentuj¹ obecnych pracowników firmy oraz rozszerzaj¹ obiekty Person o atrybut salary. Obiekty Emp oraz Dept s¹ powi¹zane obiektami wskazuj¹cymi nazwanymi odpowiednio worksin oraz employs. Kolejna klasa, która rozszerza klasê PersonClass to StudentClass. Wprowadza ona atrybut scholarship. Ostatnia klasa pokazana na schemacie, nazwana EmpStudentClass, dziedziczy po EmpClass oraz StudentClass. Zosta³a wprowadzona, aby reprezentowaæ studentów, którzy s¹ jednoczeœnie pracownikami firmy. U ycie nazwy Person w zapytaniu SBQL daje w rezultacie wszystkie instancje klasy PersonClass i jej podklas. Podobnie poprzez nazwê Emp programista odnosi siê do instancji obu klas EmpClass i EmpStudentClass. Klasy mog¹ zawieraæ metody korzystaj¹ce z polimorfizmu (nadpisywanych w podklasach). Np. metoda gettotalincomes() klasy EmpClass zwraca wartoœæ atrybutu salary, ale dla instancji klasy EmpStudentClass zwraca sumê atrybutów salary i scholarship Typy indeksów Sk³adnia umo liwiaj¹ca stworzenie indeksów pozwala administratorowi wyspecyfikowaæ ogólne w³aœciwoœci klucza indeksu, tj. dotycz¹ce wartoœci kluczowych lub celu opty-

5 Metody optymalizacji przez indeksowanie dla obiektowego jêzyka zapytañ 1533 malizacji. Jest to osi¹gane poprzez wprowadzenie opcjonalnego typu wskaÿnika: dense, range oraz enum. WskaŸnik dense powoduje, e optymalizacja zapytañ, które u ywaj¹ danego klucza jako warunku, bêdzie stosowana tylko dla predykatów selekcji opartych na operatorach = oraz in. Dlatego dystrybucja zindeksowanych obiektów w indeksie (tj. w tabeli haszuj¹cej) mo e byæ bardziej losowa. Kolejnoœæ wartoœci kluczowych nie ma znaczenia dla procesu indeksacji. Typ dense jest zawsze u ywany do wartoœci wskaÿnikowych (bez wzglêdu czy zosta³o to okreœlone przez administratora). Ponadto jest to domyœlny typ wskaÿnika dla takich typów wartoœci kluczowych: integer, string, double. add index idxempsalary(dense) on Emp(salary) WskaŸnik range powoduje, e optymalizowane bêd¹ predykaty selekcji oparte nie tylko na operatorach = oraz in ale równie na operatorach >,, < i. W obrêbie indeksu funkcja haszuj¹ca grupuje obiekty zgodnie z zakresami wartoœci kluczowych. W obecnej implementacji, zakresy s¹ dynamicznie dzielone, poniewa ka dy zakres jest skojarzony z indywidualnym fragmentem liniowej mapy haszuj¹cej zwanym kube³kiem (bucket). add index idxdeptsalary(range) on Dept(sum(employs.Emp.salary)) Indeks idxdeptsalary zwraca referencje do departamentu zgodnie z wartoœci¹ (lub zakresem wartoœci) sumy wynagrodzeñ pracowników departamentu. Jego zalet¹ jest unikanie wyliczania wartoœci z³o onych predykatów selekcji wiele razy, poniewa jest ona wczeœniej wyznaczona w momencie tworzenia indeksu. Z drugiej strony koszt utrzymania indeksu idxdeptsalary jest bardzo du y i mo e powodowaæ powa ne zmniejszenie wydajnoœci operacji aktualizacji bazy danych. WskaŸnik enum jest stosowany w sytuacji, gdy chcemy wykorzystaæ w³asnoœci klucza ze skoñczonym, policzalnym zbiorem odrêbnych wartoœci, tj. klucze z nisk¹ licznoœci¹ (kardynalnoœci¹) wartoœci. Wydajnoœæ indeksu znacznie pogorsza siê je eli wartoœci kluczowe maj¹ nisk¹ licznoœæ, np. kolor oczu osób, stan cywilny (wartoœæ boolowska) lub rok urodzenia. U ywaj¹c klucza indeksu typu enum powoduje, e wewnêtrznie s¹ sk³adowane wszystkie mo liwe wartoœci kluczowe (lub zakres dla ca³kowitych wartoœci) a informacje te s¹ u ywane do optymalizacji struktury indeksów. Typ klucza enum powoduje optymalizacje predykatów selekcji dok³adnie tak jak w przypadku wskaÿnika range, np. dla operatorów =, >,, < i. Inna wa na w³aœciwoœæ klucza typu enum pojawia siê w momencie kiedy indeks jest za³o ony na wielu kluczach, wówczas optymizator mo e niektóre z nich pomin¹æ jeœli jest to potrzebne w trakcie optymalizacji zapytañ. Je eli enum jest ustawiony na wszystkich kluczach indeksu i iloœæ zindeksowanych obiektów jest du a, wówczas ewaluacja wywo³a-

6 1534 Tomasz M. Kowalski, Pawe³ Cebula, Kamil Kuliberda, Jacek Wiœlicki, Rados³aw Adamus nia indeksu powinna zadzia³aæ w sposób bardzo wydajny (ka da kombinacja wartoœci kluczowych wskazuje na osobn¹ tablicê referencji obiektów zwan¹ kube³kiem) add index idxperage&mar&city(enum enum enum) on Person (age, married, address.city) Inne przyk³ady poleceñ tworz¹cych indeksy przedstawiono poni ej: add index idxperzip(enum) on Person(address.zip) Indeks enum który zwraca obiekty Person, którego argumentem jest podobiekt podobiektu address czyli kod pocztowy osoby. Nale y zwróciæ uwagê na fakt, i atrybut kod pocztowy (zip) na schemacie na rysunku 1 jest opcjonalny i dlatego ten indeks przechowuje tylko obiekty Person, które go zawieraj¹. add index idxperbirthyear(range) on Person(2009 age) Indeks w tym przypadku zwraca obiekty Person wed³ug wartoœci wyra enia 2009 age. Zak³ada siê, e ten indeks jest w stanie przetwarzaæ zapytania zakresowe. add index idxemptotalincomes on Emp(getTotalIncomes()) Indeks gêsty u ywaj¹cy metody gettotalincomes() klasy Emp jako klucza dla selekcji obiektów Emp. Ta metoda jest nadpisana dla instancji klasy EmpStudent. Jedyn¹ akcj¹ wymagan¹ od administratora, aby skorzystaæ z zalet indeksowania jest stworzenie odpowiednich indeksów. Pozosta³a czêœæ optymalizacji jest przezroczysta dla programistów. Nastêpna sekcja opisuje zasady stosowane przez optymizator wykorzystuj¹cy indeksy. 4. Optymalizacja zapytañ W systemie ODRA u ycie indeksów jest ca³kowicie przezroczyste dla kodu aplikacji. Programista nie musi byæ œwiadomy o istnieniu indeksów, poniewa kod zupe³nie od nich nie zale y. Optymalizator indeksów automatycznie stosuje wszystkie mo liwe indeksy w trakcie procesu kompilacji zapytañ. Oprócz tej mo liwoœci u ytkownik mo e równie u ywaæ indeksów jawnie. Ta cecha jest wdro ona do celów testowych, aby sprawdziæ równoœæ semantyczn¹ opracowanych metod optymalizacji przez indeksowanie i badañ nad nowymi mo liwoœciami wykorzystania indeksowania. Poni sza sekcja opisuje ogólne zasady u ywane w rozwi¹zywaniu problemów semantycznej równowa noœci zapytañ oryginalnych, wejœciowych i przetworzonych przez

7 Metody optymalizacji przez indeksowanie dla obiektowego jêzyka zapytañ 1535 optymalizator. Wiêkszoœæ poni szych zasad dotyczy optymalizacji zapytañ zakresowych. Optymalizator analizuje prawy argument niealgebraicznego operatora where bior¹c pod uwagê wszystkie predykaty selekcji po³¹czone operatorami koniunkcji (and) i alternatywy (or). Podstawowa procedura optymalizacji przez indeksowanie dzia³a na selektywnych zapytaniach gdzie lew¹ stronê operatora where stanowi kolekcja zaindeksowana przez jeden lub wiêcej indeksów. Algorytm analizuje wszystkie predykaty selekcji po³¹czone operatorem and i próbuje znaleÿæ indeks, którego klucz pasuje do predykatów. Je eli wiêcej ni jeden indeks zostaje znaleziony, optymalizator wybiera jeden z najlepsz¹ selektywnoœci¹ (na podstawie istniej¹cego modelu kosztów) 4.1. Sk³adnia u ycia indeksów Z punktu widzenia sk³adni jêzyka SBQL inwokacja indeksu jest po prostu wywo³aniem procedury: <indexname>( <key_param_1> [; <key_param_2>...] ) Liczba parametrów jest równa liczbie kluczy indeksu. Ka dy parametr klucza definiuje po ¹dan¹ wartoœæ kluczow¹. Wywo³anie funkcji indeksu zwraca referencje do obiektów odpowiadaj¹cych okreœlonym kryteriom. Wyra enie parametru klucza mo e definiowaæ pojedyncz¹ wartoœæ jako kryterium. W takim przypadku ewaluacja powinna zwróciæ wartoœæ typu integer, double, string, reference lub Boolean albo wskaÿnik do takowej wartoœci. Poni ej zaprezentowaliœmy wywo- ³anie dla przyk³adowego indeksu idxdeptname: idxdeptname( HR groupas $equal) Pojedyncza wartoœæ kluczowa mo e byæ przekazana przez wartoœæ bindera nazwanego $equal. Bindery s¹ u ywane do zwiêkszenia czytelnoœci oraz aby umo liwiæ ³atwiejsze wprowadzanie typów parametrów dla wywo³ania indeksów. Aby okreœliæ zakres jako kryterium wartoœci kluczowej, wyra enie powinno zwracaæ strukturê sk³adaj¹c¹ siê z czterech parametrów: (<lower_limit>, <upper_limit>, <lower_closed>, <upper_closed>) gdzie: <lower_limit> i <upper_limit> s¹ wartoœciami klucza okreœlaj¹cymi zakres <lower_closed> jest wartoœci¹ typu Boolean okreœlaj¹c¹ czy <lower_limit> nale y do zakresu kryterium <upper_closed> jest wartoœci¹ typu Boolean okreœlaj¹c¹ czy <upper_limit> nale y do zakresu kryterium

8 1536 Tomasz M. Kowalski, Pawe³ Cebula, Kamil Kuliberda, Jacek Wiœlicki, Rados³aw Adamus Przyk³ady wywo³añ indeksów: idxperbirthyear((1978, 1982, true, true) groupas $range) idxperbirthyear((1900, (sum(person.(2009 age)) / count(person)), true, false) groupas $range); Ostatni przyk³ad zwraca referencje do osoby, której rok urodzenia jest wczeœniejszy ni œrednia wieku wszystkich osób zawartych w bazie danych. Podobnie jak w przypadku pojedynczych parametrów wartoœci klucza, parametry okreœlaj¹ce zakres s¹ przekazywane z u yciem wartoœci bindera o nazwie $range. Parametr klucza mo e specyfikowaæ równie kolekcjê wartoœci kluczowych jako kryterium. idxempage&workcity((25 union 30 union 35) groupas $in; Boston groupas $equal) Binder o nazwie $in jest u yty do przekazania kolekcji wartoœci kluczowych. Jeœli kryterium zwraca zbiór pusty, wówczas wywo³anie indeksu równie zwraca pusty zbiór Równowa noœæ semantyczna w optymalizacji obejmuj¹cej klucze opcjonalne W pierwszej kolejnoœci rozwa my jak licznoœæ klucza [0..1] wp³ywa na optymalizacje. U ywanie kryteriów o opcjonalnej licznoœci mo e spowodowaæ wyst¹pienie b³êdu czasu wykonania, poniewa predykat selekcji oparty na operatorach =, >,, < i wymusza u ywanie pojedynczej wartoœci zarówno w przypadku lewego jak i prawego argumentu. Nieoczekiwana iloœæ wartoœci argumentów powoduje b³¹d czasu wykonania. U ycie wywo³ania indeksu w optymalizacji z takowymi predykatami wyeliminowa³oby niebezpieczeñstwo wyst¹pienia b³êdu a zatem zoptymalizowane zapytania nie by³yby semantycznie równe oryginalnym. W takich przypadkach optymalizacja jest dozwolona tylko jeœli operator in jest u yty jako predykat poniewa nie ogranicza on licznoœci prawego argumentu. Poni ej prezentowany jest przyk³ad niebezpiecznej ewaluacji predykatu, który mo e spowodowaæ b³¹d czasu wykonania. Lewa strona predykatu selekcji ma licznoœæ [0..1] zgodnie z kardynalnoœci¹ atrybutu kodu pocztowego (zip). Person where address.zip = 94107

9 Metody optymalizacji przez indeksowanie dla obiektowego jêzyka zapytañ 1537 Aby unikn¹æ mo liwoœci wyst¹pienia b³êdu czasu wykonania powinien byæ u yty bezpieczny operator in: Person where in address.zip W omawianym przypadku optymalizator indeksów wspiera optymalizacje, kiedy predykaty s¹ zdefiniowane przy u yciu operatorów =, >,, < i pod warunkiem u ycia odpowiedniego predykatu egzystencjalnego exists. Przyk³ad bezpiecznej ewaluacji predykatu z u ytym operatorem = przedstawiony jest poni ej: Person where exists(address.zip) where address.zip = Jedynie w przypadku dwóch ostatnich przyk³adów zapytañ optymalizator wykorzystuj¹cy indeksy mo e stosowaæ nastêpuj¹c¹ transformacjê zapytania: idxperzip(94107 groupas $equal) Minimalna licznoœæ klucza równa zero oznacza, e indeks mo e nie zawieraæ referencji do wszystkich obiektów zdefiniowanej przy tworzeniu indeksu indeksowanej kolekcji. W przypadku indeksu na wielu kluczach, jeœli taki klucz by³by pominiêty w predykacie selekcji, zaistnia³aby mo liwoœæ, e ewaluacja operatora where zwróci referencje do obiektu, który nie jest przechowywany wewn¹trz indeksu. Zatem optymalizator nie zastosowa³by optymalizacji u ywaj¹c takiego indeksu. Reasumuj¹c, klucze z minimaln¹ licznoœci¹ równ¹ zero s¹ obligatoryjne, pomimo zadeklarowania przy pomocy wskaÿnika typu enum Aspekty optymalizacji predykatów zakresowych Je eli predykat selekcji zoptymalizowanego zapytania okreœla tylko jeden limit zakresu (dolny lub górny), wówczas drugi limit jest generowany automatycznie, tj. mo liwie najmniejsza lub najwiêksza wartoœæ dla danego klucza. Przyk³adowo poni sze zapytanie dotyczy oddzia³u zlokalizowanego w Warszawie, którego pracownicy sumarycznie zarabiaj¹ mniej ni najlepiej op³acany pracownik w ca³ej firmie. Zapytanie oryginalne: Dept where sum(employs.emp.salary) < max(emp.salary) and address.city = Warszawa Zapytanie zoptymalizowane idxdeptsalary(( , max(emp.salary), true, false) groupas $range) where address.city = Warszawa

10 1538 Tomasz M. Kowalski, Pawe³ Cebula, Kamil Kuliberda, Jacek Wiœlicki, Rados³aw Adamus Je eli mamy do czynienia z wiêcej ni jednym predykatem dotycz¹cym jednego limitu (np. dolnego) zakresu danego klucza, wówczas wyra enia min, max, union oraz porównania s¹ u ywane do wyznaczenia odpowiedniego parametru klucza zakresu. Zapytanie oryginalne: ((sum(person.(2009 age)) / count(person)) as avgyear). (Person where 2009 age > avgyear and 1970 <= 2009 age and 2009 age < 1980) Zapytanie zoptymalizowane: (sum(person.(2009 age)) / count(person)) as avgyear). idxperbirthyear((max(avgyear union 1970), 1980, 1970 > avgyear, false) groupas $range) 4.4. Pomijanie kluczy w wywo³aniu indeksu W indeksach opartych na wielu kluczach, klucze enum mog¹ byæ zwykle pomijane w wywo³aniach indeksów. Optymalizator indeksów, aby pomin¹æ klucz, kiedy aden predykat selekcji nie zosta³ okreœlony, ustawia oba dolne oraz górne ograniczenia do najni szej oraz najwy szej mo liwej wartoœci kluczowej. Zapytanie oryginalne: Person where true = married and address.city in Wroc³aw Zapytanie zoptymalizowane: idxperage&mar&city (( , , true, true) groupas $range; true groupas $equal ; Wroc³aw groupas $equal) Aby pomin¹æ klucz typu boolean w wywo³aniu indeksu u ywa siê zbioru kryteriów parametru kluczowego z³o onego z dwóch wartoœci fa³sz i prawda. Zapytanie oryginalne: Person where age > 30 and 33 >= age and address.city in Wroc³aw Zapytanie zoptymalizowane: idxperage&mar&city((30, 33, false, true) groupas $range; (false union true) groupas $in ; Wroc³aw groupas $equal)

11 Metody optymalizacji przez indeksowanie dla obiektowego jêzyka zapytañ Alternatywa predykatów oraz uwzglêdnienie dziedziczenia Optymalizator indeksów jest przygotowany równie do przetwarzania zapytañ, w których predykaty selekcji s¹ po³¹czone operatorem or. Jako e dysjunkcja os³abia selekcjê, komplikuje to równie proces optymalizacji. Dlatego je eli zastosowanie indeksów jest mo liwe bez uwzglêdnienia predykatów po³¹czonych operatorem or, wówczas optymalizator mo- e pomin¹æ g³êbsze analizy. W przeciwnym wypadku, aby sprawdziæ wszystkie mo liwoœci indeksowania, optymalizator usuwa operatory or, rozdzielaj¹c niealgebraiczne wyra enie where na dwa czêœciowe wyra enia selekcji. Obiekty zwracane przez obydwa wyra enia mog¹ byæ zduplikowane wiêc istnieje potrzeba pozostawienia tylko ró nych referencji obiektów; jest to osi¹gane poprzez u ycie wyra enia uniqueref. Indeksowanie umo liwia redukcje iloœci danych przetwarzanych przez zapytania wtedy, gdy mo e byæ zastosowane do obu czêœciowych wyra eñ. Ta procedura jest rekursywna w przypadku, gdy mamy do czynienia z wiêcej ni jednym operatorem or. Przeanalizujmy poni szy przyk³ad optymalizacji. Emp where age = 28 and married = true and (address.city = Szczecin or Szczecin in worksin.firm.address.city) Zapytanie mo e byæ podzielone przez optymalizator indeksów zgodnie z poni sz¹ form¹: uniqueref((emp where age = 28 and married = true and address.city = Szczecin ) union (Emp where age = 28 and married = true and Szczecin in worksin.firm.address.city)) Zale nie od obecnego modelu kosztów oraz istniej¹cych indeksów, optymalizator mo e zastosowaæ nastêpuj¹c¹ transformacjê: uniqueref(((emp) idxperage&mar&city(28 groupas $equal; true groupas $equal; Szczecin groupas $equal))union (idxempage&workcity(28 groupas $equal; Szczecin groupas $equal) where married = true) Predykat selekcji oparty na wyra eniach age, married oraz address.city dotyczy nadklasy klasy EmpClass, tj. PersonClass i z tego powodu administrator mo e wyposa yæ ca³¹ kolekcjê Person w indeks idxperage&mar&city. Indeks ten mo e zwracaæ instancje, które nie nale ¹ do EmpClass, st¹d optymalizator musi wykorzystaæ narzêdzie do usuwania instancji nienale ¹cych do EmpClass z rezultatu inwokacji indeksu. Mo e to byæ zrealizowane poprzez operator koercji jêzyka SBQL. Sk³adnia operatora koercji zosta³a wziêta z typowej konwencji syntaktycznej znanej z takich jêzyków jak C, C++ jako rzutowanie. W rezultacie wywo³anie indeksu idxperage&mar&city zwraca wynik, który jest automatycznie rzutowany na kolekcjê Emp, poniewa oryginalne zapytanie dotyczy tylko pracowników. W zaprezentowanym podejœciu do ponownego u ycia indeksu w hierarchii dziedziczenia kolekcji, indeksy dotycz¹ce klasy, która wprowadza dany klucz, s¹ bardziej wszechstronne i uniwersalne, jako e mog¹ byæ u yte w optymalizacji zapytañ adresowanych równie do kolekcji okreœlonych przez podklasy.

12 1540 Tomasz M. Kowalski, Pawe³ Cebula, Kamil Kuliberda, Jacek Wiœlicki, Rados³aw Adamus 5. Zysk optymalizacji Rozwa my nastêpuj¹cy przyk³ad testowy. Je eli wywo³anie indeksu jest umieszczone po prawej stronie niealgebraicznego operatora, na przyk³ad operatora kropki, wówczas jest prawdopodobne, e bêdzie ono ewaluowane wiêcej ni jeden raz podczas wykonywania zapytania. Jest to przedstawione w nastêpuj¹cym przyk³adzie z indeksem idxemptotalincomes. Zapytanie w tabeli 1, dla 61-letnich pracowników w stanie ma³ eñskim, zamieszkuj¹cych w odzi lub Wroc³awiu, zwraca imiê po³¹czone z nazwiskiem oraz liczbê pracowników z równ¹ iloœci¹ ca³kowitych przychodów. Na rysunku 2 przedstawiono czasy wykonania obu postaci zapytania z tabeli 1 oraz zysk wynikaj¹cy z wykorzystania indeksowania. Testy prototypu indeksowania w bazie danych ODRA przeprowadzono na komputerze klasy PC z procesorem Intel Mobile Core 2 Duo T2300, 1,66 GHz, z pamiêci¹ RAM 2,00 GB na systemie operacyjnym MS Windows Server 2003 R2 Service Pack 2, 32 bit. Tabela 1 Zapytanie oryginalne Zapytanie zoptymalizowane ((Emp where address.city = " ódÿ" and worksin.dept.address.city in (" ódÿ" union "Wroc³aw") and married = true and age = 61) as e).(e.name + " " + e.surname, count(emp where gettotalincomes() = e.gettotalincomes())) ((Emp where address.city = " ódÿ" and worksin.dept.address.city in (" ódÿ" union "Wroc³aw") and married = true and age = 61) as e).(e.name + " " + e.surname, count(idxemptotalincomes(e.gettotalincomes())) liczba osób Rys. 2. Porównanie czasów wykonania i zysku optymalizacji zapytania

13 Metody optymalizacji przez indeksowanie dla obiektowego jêzyka zapytañ 1541 Dodatkowo wprowadÿmy inny indeks idxempage&workcity tak, aby zoptymalizowaæ ewaluacje pierwszej czêœci zapytania, co mo e znacz¹co wp³yn¹æ na wzrost wydajnoœci. W tabeli 2 wyszczególniono zapytania wykorzystuj¹ce ró ne kombinacje indeksów. Na rysunku 3 znajduje siê wykres z odpowiadaj¹cymi im zyskami optymalizacji uzale nionymi od liczby osób w bazie danych. Tabela 2 Zapytanie z indeksem idxemptotalincomes Zapytanie z indeksem idxempageworkcity Zapytanie z dwoma indeksami ((Emp where address.city = " ódÿ" and worksin.dept.address.city in (" ódÿ" union "Wroc³aw") and married = true and age = 61) as e). (e.name + " " + e.surname, count(idxemptotalincomes(e.gettotalincomes())) ((idxempage&workcity(61 groupas $equal; (" ódÿ" union "Wroc³aw") groupas $in) where address.city = " ódÿ" and married = true) as e). (e.name + " " + e.surname, (e.name + " " + e.surname, count(emp where gettotalincomes() = e.gettotalincomes()))) ((idxempage&workcity(61 groupas $equal; (" ódÿ" union "Wroc³aw") groupas $in) where address.city = " ódÿ" and married = true) as e). (e.name + " " + e.surname, count(idxemptotalincomes(e.gettotalincomes())) liczba osób Rys. 3. Zysk optymalizacji indeksów dla zapytania

14 1542 Tomasz M. Kowalski, Pawe³ Cebula, Kamil Kuliberda, Jacek Wiœlicki, Rados³aw Adamus Dla bazy danych zawieraj¹cej obiektów odpowiadaj¹cych osobom, dwa indeksy daj¹ zysk w przybli eniu 40 razy wiêkszy. Pomimo takiej ró nicy najwa niejszy jest indeks wo³any wielokrotnie, tj. idxemptotalincomes. Bez tego indeksu nie ma zauwa alnej poprawy wydajnoœci. 6. Wnioski i plany dalszych prac W niniejszym artykule zosta³y skrótowo opisane zasady dotycz¹ce tworzenia i wykorzystywania indeksów w prototypie ODRA. W zaprezentowanym podejœciu optymalizacja jest osi¹gniêta poprzez opisan¹ transformacjê zapytañ. Zaproponowana implementacja indeksacji w ODRA umo liwia tworzenie i przezroczyst¹, automatyczn¹ aktualizacjê indeksów u³atwiaj¹cych przetwarzanie predykatów selekcji opartych na dowolnych, deterministycznych wyra eniach sk³adaj¹cych siê z wyra eñ œcie kowych, funkcji agreguj¹cych, inwokacji metod klas (w³¹cznie z dziedziczeniem oraz polimorfizmem). Wszystkie funkcjonalnoœci wymagane do kompletnego dzia³ania systemu indeksowania zosta³y ju zaimplementowane. Niemniej jednak, indeksacja w ODRA nadal jest rozwijana i wymaga dalszych badañ. Plany przysz³ych prace obejmuj¹ zastosowanie innych struktur indeksów (np. B-Drzewa) oraz implementacji nowych metod optymalizacji, korzystaj¹cych z zalet indeksów (np. optymalizacja zapytañ rankingowych). Kolejne prace dotycz¹ techniki ulotnego indeksowania, która mo e byæ stosowana do przetwarzania danych heterogenicznych oraz wirtualnie udostêpnionych poprzez perspektywy SBQL. Technika ta wykazuje skutecznoœæ w przetwarzaniu z³o onych zapytañ, w których indeks jest wywo³ywany wiêcej ni jeden raz. Dodatkowo rozwa amy rozszerzenia mo liwoœci indeksowania na rozproszone œrodowisko przy u yciu skalowalnego i rozproszonego indeksu SDDS. Literatura [1] Burleson D., Turbocharge SQL with advanced Oracle9i indexing. March 26, 2002, [2] Elmasri R., Navathe S.B., Fundamentals of Database Systems 4th ed. Pearson Education, Inc., 2004, ISBN: [3] GemStone Systems, Inc. [4] Java API User Guide ObjectStore, Release 7.1 for all platforms, August [5] Litwin W., Linear Hashing: a new tool for file and tables addressing. Reprinted from VLDB-80 in READINGS IN DATABASES. 2-nd ed., Morgan Kaufmann Publishers, Inc., 1994, Stonebraker, M. (Ed.). [6] Litwin W., Nejmat M.A., Schneider D.A., LH*: Scalable, Distributed Database System. ACM Trans. Database Syst., 21(4), 1996, [7] Meier D., Stein J., Indexing in an object-oriented DBMS. Proceedings of the OODBS, IEEE Computer Society Press, 1986, [8] O Neil P.E., Quasi D., Improved Query Performance with Variant Indexes. Proceedings of SIGMOD, 1997, [9] Objectivity for Java Programmer s Guide, Release 9.3, October 13, 2006.

15 Metody optymalizacji przez indeksowanie dla obiektowego jêzyka zapytañ 1543 [10] Oracle9i Data Warehousing Guide Release 2 (9.2). Part Number A [11] P³odzieñ J., Optimization Methods In Object Query Languages. IPIPAN, Warszawa, 2000 (Ph.D. Thesis). [12] P³odzieñ J., Kraken A., Object Query Optimization in the Stack-Based Approach. Proc. of 3rd ADBIS Conf., Maribor, Slovenia, Springer LNCS 1691, 1999, [13] SBA & SBQL Web pages: [14] Subieta K. Theory and Construction of Object-Oriented Query Languages (in Polish). PJIIT Publishing House, 2004, 522. [15] VERSANT Database Fundamentals Manual, (Release ) July 2005.