Konstrukcja systemów obiektowych i rozproszonych

© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 4, Folia 1 październik 2004

Konstrukcja systemów obiektowych i rozproszonych

Wykładowca: Kazimierz Subieta

Polsko-Japońska Wyższa SzkołaTechnik Komputerowych, [email protected]

Instytut Podstaw Informatyki PAN, [email protected]

Wykład 4: Wprowadzenie do optymalizacji zapytań

Metody organizacji i udostępniania danych


Dlaczego zapytania muszą być optymalizowane?

Wysoki poziom abstrakcji i deklaratywność zapytań prowadzi zwykle do niskiej (nieakceptowalenej) efektywności ich wykonania.

Dla niektórych zapytań naiwna ewaluacja mogłaby trwać nawet setki lat na najszybszych komputerach. Zwykle należy to skrócić do sekund.

Zadanie radykalnego skrócenia czasu wykonania zapytań, zwane optymalizacją zapytań, przerzucono na specjalny moduł oprogramowania SZBD, tzw. optymalizator zapytań (query optimizer). • Ręczna optymalizacja przy użyciu języka niższego poziomu nie prowadzi do

pożądanych efektów. Programista nie jest w stanie zrozumieć i uwzględnić wszystkich powiązań i zależności występujących w złożonym zapytaniu i w środowisku jego ewaluacji.

• Zejście na niższy poziom językowy jest bardzo niekorzystne z punktu widzenia pielęgnacyjności oprogramowania. Kod staje się mało czytelny i znacznie bardziej obszerny.

Automatyczny optymalizator, korzystający z gotowych algorytmów i dysponujący wiedzą dotyczącą aktualnego stanu środowiska bazy danych, jest w stanie działać w sposób znacznie bardziej uniwersalny i skuteczny, nie zakłócając przy tym pielęgnacyjności oprogramowania.


Optymalizacja automatyczna czy ręczna?

Efektywność współczesnych optymalizatorów zapytań jest ograniczona przez charakter i złożoność zapytań oraz ograniczony zakres stosowalności algorytmów optymalizacyjnych.

Niektóre, nawet proste zapytania, mogą nie podlegać optymalizacji ze względu na ich charakter wymagający np. pełnego przeglądu bardzo dużego zbioru obiektów.

W systemach relacyjnych, takich jak Oracle, przyjmuje się kompromisowe stanowisko, gdzie programista może wpływać na czas ewaluacji zapytania poprzez odpowiednie jego sformułowanie, przyjmując pewne „złote reguły”.• Jest to podejście rozsądne, bazujące na doświadczeniu z konkretnym

językiem zapytań oraz konkretnym jego procesorem i optymalizatorem.

• Jest oczywiste, że programista może dysponować informacją (np. o charakterze przetwarzanych danych), która jest niedostępna dla automatycznego optymalizatora.

• Informację tę może wykorzystać dla lepszego sformułowania zapytania.


Optymalizacja zapytań w systemach relacyjnych

Literatura dotycząca optymalizacji relacyjnych języków zapytań jest bardzo obszerna - tysiące publikacji.

Część metod proponowanych dla modelu relacyjnego została zaadaptowana dla obiektowych języków zapytań, pojawiły się także ich nowe odmiany.

Zaproponowano taże specjalne metody dla języków przeznaczonych dla danych półstrukturalnych.

Pojawiły się także nowe metody, takie jak przemiana wskaźników (pointer swizzling), specyficzne wyłącznie dla modeli obiektowych.

W tym wykładzie nie będziemy prezentować wszystkich metod optymalizacyjnych opisanych w literaturze przedmiotu, gdyż jest to temat na dużą książkę.

Ograniczymy się do metod, które mogą być bezpośrednio wykorzystane w ramach podejścia stosowego. • Niektóre z nich, takie jak metoda niezależnych podzapytań, są wynalezione

w związku z podejściem stosowym i nie były rozpatrywane w innych kontekstach.


Model danych a efektywność zapytań

Postać modelu danych i implikowanych przez model struktur danych ma bardzo silny wpływ na potrzebę i skuteczność metod optymalizacyjnych.

Metody optymalizacyjne w SQL zajmują się głównie naprawianiem tego, co zostało zepsute przez zabiegi normalizacyjne niezbędne dla zapisania danych w postaci relacyjnej. • Głównym adresatem optymalizacji w relacyjnych bazach danych jest

kosztowny operator złączenia (lub iloczynu kartezjańskiego). • Wskutek normalizacji stosowanie tego operatora w relacyjnych językach

zapytań jest bardzo częste i nieuniknione. • Z tego powodu dość często stosuje się „denormalizację” bazy danych, czyli

połączenia kilku tabel w jedną poprzez ich złączenie. • Dzięki denormalizacji (odejściu od 3NF) zapytania stają się efektywniejsze.

Struktury obiektowe, nie zakładające tego rodzaju „form normalnych” oraz stosujące asocjacje w postaci powiązań pointerowych, redukują kilkakrotnie zapotrzebowanie na operator złączenia, przez co zapytania do struktur obiektowych są z definicji wydajniejsze od równoważnych im zapytań do struktur relacyjnych.


Przykład: schemat prostej obiektowej bazy danych

Programista po 2-3 minutach wyjaśnień jest w stanie zorientować się w zawartości bazy danych.

Zawiera ona cztery klasy obiektów, związki asocjacji z rolami, liczności kolekcji obiektów, asocjacji i atrybutów oraz związek dziedziczenia. • Ze schematu wynika np. że każdy pracownik jest osobą, ma jedno nazwisko,

lecz może mieć wiele imion i adresów, może pracować wielu firmach, posiadać wiele wypłat i ocen w każdej z nich, itd.

• Po tych wyjaśnieniach bez trudu sformułuje zapytania w SBQL.

FZ[0..*]

Osoba[0..*]NazwiskoImię[1..*]Adres[1..*]

ZF PZ[0..*]ZPFirma[0..*]NazwaMiejsce[1..*]

Zatrudnienie[0..*]Wypłata[0..*]Ocena[1..*]

Pracownik[0..*]Stan[1..*]


Przykład: schemat podobnej relacyjnej bazy danych

Część informacji semantycznej została utracona, np. informacja o licznościach atrybutów i związków.

Programista spędzi kilkanaście minut nad zrozumieniem zależności.

Firma(NrF, Nazwa)

Lokal(NrF, Miejsce)

Zatrudnienie(NrF, NrP)

Pracownik(NrP, NrOs)

Oceny(NrOceny, Ocena, NrF, NrP)

Dochód(NrDochodu, Wypłata, NrF, NrP)Osoba(NrOs, Nazwisko)

Wyszkolenie(Stan, NrP)

Imiona(NrOs, Imię) Adresy(NrOs, Adres)


Straty na efektywności zapytań

Skutki zgubionej informacji semantycznej odbijają się na efektywności:Podaj nazwiska i stanowiska pracowników pracujących w firmach zlokalizowanych w Radomiu :

SBQL, model obiektowy (21 elementów leksykalnych): (Firma where ”Radom” Miejsce).

FZ.Zatrudnienie.ZP.Pracownik.(Nazwisko, Stan)

Jeżeli mamy indeks dla atrybutu Miejsce, to zapytanie realizowane jest jako nawigacja po pointerach – bardzo szybka.

SQL, model relacyjny (78 elementów leksykalnych):select s.Nazwisko, w.Stan

from Firma as f, Lokal as k, Zatrudnienie as z,

Pracownik as p, Wyszkolenie as w, Osoba as s

where k.Miejsce = “Radom” and k.NrF = f.NrF

and f.NrF = z.ZF and z.ZP = p.NrP and w.NrP = p.NrP

and p.NrOs = s.NrOs

Zapytanie w SQL jest nie tylko dłuższe od zapytania w SBQL , ale jego wykonanie wymaga złączenia 6-ciu relacji, które nawet przy optymalizacji może być bardzo pracochłonne .


Kryteria optymalizacji

Podstawowym kryterium optymalizacji zapytań jest łączny czas ich ewaluacji, na który składa się czas samej optymalizacji oraz czas ewaluacji po optymalizacji.

Inne kryteria, takie jak zużycie zasobów komputerowych (dysku, pamięci operacyjnej, czasu procesora, przepustowości sieci) są również istotne, ale tylko w specyficznych sytuacjach, które występują zdecydowanie rzadziej.

Ze względu na to, że wszelkie operacje w pamięci operacyjnej są miliony razy szybsze od operacji na nośnikach mechanicznych (dysku), kryterium minimalizacji czasu wykonania jest praktycznie równoważne kryterium minimalizacji transferów dyskowych.


Kryterium satysfacji użytkownika

Rozbudowane środowisko komputerowe, w którym dokonywana jest ewaluacja zapytań, różnorodny charakter przetwarzanych struktur danych, bogactwo konstrukcji językowych oraz inne czynniki powodują, że istnieje ogromna ilość miejsc, w których można poszukiwać efektu skrócenia czasu ewaluacji zapytań.

Termin „optymalizacja zapytań” nie nawiązuje do klasycznych zadań optymalizacyjnych, w których poszukuje się ekstremum lub subekstremum pewnej funkcji kryterialnej.

Optymalizacja zapytań jest poszukiwaniem rozwiązania implementacyjnego, przy którym czas odpowiedzi na zapytanie niekoniecznie jest optymalny, lecz powinien być satysfakcjonujący dla użytkowników.

Kryterium satysfakcji użytkowników jest nieformalne, subiektywne i relatywne. • Język zapytań, który nie jest satysfakcjonujący dla użytkowników, pozostaje utopią

lub scholastyką. • Historia baz danych, szczególnie jej nurtu formalnego, dostarcza wielu przykładów

tego rodzaju utopii. • Wybitnym przykładem jest Datalog, którego nie udało się efektywnie

zaimplementować dla skali rzeczywistych baz danych.


Optymalizacja: nauka czy sztuka inżynierska?

Rozwiązania w zakresie optymalizacji zapytań mogą dotyczyć nie tylko samego języka zapytań, ale również:• Organizacji struktur danych (fizycznej lub logicznej), • Metod transmisji danych pomiędzy różnymi ich nośnikami i miejscami, • Metod opartych na zapamiętywaniu rezultatów poprzednich zapytań (w celu

ich ponownego użycia), • Metod opartych na zrównolegleniu wykonania pewnych operacji itd.

Optymalizacja zapytań nie ma charakteru metod uniwersalnych. Optymalizacja jest zależna od środowiska bazy danych, środowiska

implementacyjnego i konkretnych, potwierdzonych empirycznie pomysłów związanych z wykorzystaniem własności tych środowisk.

Optymalizacja jest bardziej tuningiem przy użyciu dowolnych inżynierskich zabiegów niż zastosowaniem systematycznych metod. • Metody „naukowe” mają najczęściej zastosowanie marginalne lub żadne

(patrz setki artykułów „naukowych”, których skutki są zerowe).• Liczy się wysiłek inżynierski, uporczywość w kolejnym i kolejnym

poprawianiu.


Metody optymalizacyjne dominujące

Metody optymalizacyjne dominujące nigdy lub prawie nigdy (poza sytuacjami skrajnymi, np. pustą kolekcją obiektów) nie pogarszają czasu odpowiedzi na zapytanie. • Takie metody można stosować bez ryzyka pogorszenia czasów wykonania i

bez konieczności wprowadzania dodatkowych kryteriów ich stosowalności.

Do takich należą niektóre metody oparte na przepisywaniu zapytań, np. metoda usuwania martwych podzapytań.

Metody te polegają na zastąpieniu zapytania q1 przez semantycznie równoważne zapytanie q2, zapewniające lepszy czas ewaluacji.

Metody przepisywania są oparte na regułach, które polegają na rozpoznaniu w zapytaniu fragmentu zgodnego z pewnym wzorcem i następnie, zmianą zapytania ustaloną przez regułę. • Jeżeli dana metoda nie jest dominujaca, to konieczne jest jeszcze określenie

kryteriów, kiedy ma ona być zastosowana.

• Prowadzi to do modelu kosztów ewaluacji zapytania.


Zasada zachowania semantyki zapytania

Zmiana postaci lub planu ewaluacji zapytania nie może doprowadzić do zmiany jego semantyki i (w konsekwencji) wyniku. • Dotyczy to dowolnej bazy danych odpowiadającej jej schematowi, w tym

bazy danych zawierające niektóre puste kolekcje i kolekcje mające miliony obiektów.

W tym względzie rozwiązania ad hoc nie mają najlepszej opinii, ze względu na rozliczne błędy występujące w proponowanych algorytmach i implementacjach. • Przykładowo, tzw. „Halloween problem” dotyczył aktualizacji danych

w SQL za pomocą klauzuli update. Optymalizator, dotąd poprawny, w interferencji z innymi już zaimplementowanymi mechanizmami (indeksem), dawał niepoprawny wynik.

• Tego rodzaju problemy dotyczyły wielu innych pomysłów, również tych, które były proponowane przez specjalistów z najwyższej światowej półki.

Dlatego jest konieczne mocne teoretyczne uzasadnienie proponowanego rozwiązania i/lub staranne jego przetestowanie.


Model kosztów

Jeżeli dana metoda nie dostarcza rozwiązań dominujących, wówczas powstaje pytanie, kiedy ją należy stosować.

Kryterium rozstrzygające to pytanie może mieć postać reguły heurystycznej, • np. daną metodę warto stosować, jeżeli przeszukiwany zbiór obiektów ma

więcej niż 10000 elementów. Systematyczne podejście do tego problemu prowadzi do wprowadzenia

modelu kosztów ewaluacji zapytania. Model kosztów jest określony przez pewną funkcję lub algorytm

obliczaną na wewnętrznej reprezentacji zapytania przed jego ewaluacją. Zadaniem modelu kosztów jest oszacowanie czasu/kosztu ewaluacji

różnych planów ewaluacji zapytania i wybranie planu o minimalnym szacowanym koszcie.

Model kosztów zależy od czynników obserwowanych w aktualnym stanie bazy danych i środowiska komputerowego.• Ale powinien być jednocześnie prosty, ze względu na czas samej

optymalizacji.


Model kosztów powinien obejmować:

Szczegółową budowę zapytania (jego semantykę); Sposób jego ewaluacji; Metainformacje dotyczące struktur danych (np. rozmiary kolekcji

obiektów); Metainformacje retrospektywne (np. dotyczące rzeczywistych kosztów

ewaluacji podobnych zapytań lub różnorodne statystyki, np. statystyki selektywności określonych typów predykatów itd.);

Informacje odnośnie do pomocniczych struktur danych uczestniczących w ewaluacji zapytań (np. rozmiar buforów);

Informacje odnośnie do środowiska komputerowego (np. ilość wolnej przestrzeni dyskowej);

Dowolne inne informacje relewantne dla optymalizacji, np. czas transferu dyskowego, szybkość sieci, itd.


Wady oparcia optymalizacji na modelu kosztów

Stworzenie modelu kosztów a priori, bez eksperymentów w realnym środowisku operacyjnym, może prowadzić do znacznych błędów w definicji funkcji matematycznej lub algorytmu.• Zależność kosztu ewaluacji od poszczególnych czynników wpływających na

ten koszt jest trudna do uchwycenia i trudno przewidywalna.• Niektórych czynników nie da się przewidzieć, inne zaś, pozornie istotne,

mają znikomy wpływ na koszt ewaluacji. Obliczanie przewidywanych kosztów dla zapytań dodatkowo obciąża czas

wykonania, szczególnie w przypadku nietrywialnych algorytmów. Modele kosztów są obciążone prawem GIGO (Garbage In – Garbage

Out): twórca modelu kosztów musi przyjąć pewne wzory lub dane „z sufitu”, co może poważnie zniekształcić wynik.

Modele kosztów muszą być weryfikowane praktycznie w realnym środowisku. • W praktyce stosuje się proste, sprawdzone empirycznie heurystyki, które

w pewnym stopniu aproksymują model kosztów, uwzględniając tylko najważniejsze czynniki wpływające na koszt ewaluacji zapytań


Wybór optymalnego planu ewaluacji

Z modelem kosztów jest związany wybór optymalnego planu ewaluacji zapytania. Przykładowo, dla zapytania Prac where Nazwisko = ”Kowalski” and Zar = 2500 • jeden plan ewaluacji zakłada użycie indeksu nazwisk pracowników i następnie

wyselekcjonowanie tych, którzy zarabiają 2500, • drugi plan zakłada skorzystanie z indeksu zarobków pracowników i następnie

wyselekcjonowanie tych, którzy mają nazwisko Kowalski. • Model kosztów ma dać odpowiedź, który z tych planów jest lepszy.

W literaturze podkreśla się, że dla niektórych zapytań liczba takich planów ewaluacji może być bardzo duża, tysiące lub więcej. • Dla takich przypadków proponowane są specjalne heurystyki pozwalające na

zredukowanie przestrzeni możliwych planów. Ten problem jest nieco wymyślony.

• Przestrzeń dopuszczalnych planów ewaluacji jest duża tylko wtedy, gdy możliwa jest permutacja kolejności wykonania pewnych fragmentów zapytania, np. mamy 10 złączeń na tym samym poziomie i kolejność ich wykonania jest dowolna

• W językach obiektowych, takich jak SBQL, taki przypadek będzie rzadki, gdyż hierarchiczna organizacja obiektów, powiązania pomiędzy obiektami, wyrażenia ścieżkowe itp. znacznie redukują możliwości permutowania operatorów.


Trzy grupy metod optymalizacyjnych

Metody fizycznego przechowywania, buforowania i udostępniania danych. • Np. w wielu przypadkach metoda przechowywania obiektów oparta na

kodowaniu mieszającym (hash coding) jest znacznie bardziej sprawna niż metoda polegająca na sekwencyjnym ułożeniu obiektów w pliku.

Metody oparte na przepisywaniu, w których dokonuje się transformacji wewnętrznej reprezentacji zapytania na inną postać rokującą lepszy czas wykonania. • W systemach relacyjnych typową i najważniejszą metodą należącą do tej grupy

jest przesuwanie operatora selekcji przed operator złączenia. Metody oparte na pomocniczych, redundantnych strukturach danych

zwanych zwykle indeksami. • Istnieje ogromne bogactwo różnych form indeksów, i w ślad za tym różnych

form optymalizacji zapytań bazujących na indeksach. • Do tej grupy można także zaliczyć metody oparte na

• plikach odwróconych (inverted files), • relacjach wspomagających dostęp (access support relations), • zapamiętanych zapytaniach (cached queries) • zmaterializowanych perspektywach (materialized views).


Wybór identyfikatora obiektu

Jednym z podstawowych wyborów przy fizycznej organizacji trwałego składu obiektów jest sposób budowy identyfikatorów.

Popularne stwierdzenia, że identyfikator obiektu (OID) powinien być niezależny od adresu miejsca przechowywania obiektu należy traktować z rezerwą.

Symboliczny OID oznacza albo konieczność utrzymywania tablicy pośredniczącej zawierającej pary <OID, fizyczny adres obiektu>, albo zastosowanie funkcji mieszającej, która zamieni symboliczny identyfikator obiektu na jego adres fizyczny. • Obydwa sposoby mają poważne wady.

Z tych powodów dość często identyfikator obiektu ma postać liczby (liczb), którą za pomocą prostej formuły można zamienić na fizyczny adres dyskowy. • Wadą tego sposobu jest utrudnienie operacji zwiększania rozmiaru obiektu oraz (po

pewnym czasie eksploatacji) fragmentacja przestrzeni dyskowej.

Porównanie różnych metod tworzenia identyfikatora obiektu w systemie Loqis wykazało zasadniczą przewagę metody opartej na fizycznych adresach i place holders nad innymi. • Badania miały jednak ograniczony charakter.


Alokacja obiektów i rejestrowanie nieużytków (1)

Zasada zarządzania przestrzenią dyskową mówi, że system musi pamiętać informację o każdym wolnym obszarze (nieużytku), nawet jeżeli ma on rozmiar jednego bajtu.

Sposób pamiętania tej informacji jest dowolny. Przykładowo, można przyjąć, że na początku obszaru nieużytku

pamiętane są adresy następnego i poprzedniego nieużytku lub jest tworzony specjalny indeks nieużytków.

Wadą pierwszego sposobu jest trudność ze znalezieniem wolnego miejsca dla alokacji obiektu, gdyż wymaga to sekwencyjnego przeglądania długich łańcuchów.

Wadą drugiego sposobu jest znaczne zaangażowanie zasobów dyskowych dla trzymania indeksu nieużytków, zwiększenie czasu niektórych operacji (np. zmniejszających rozmiary obiektu) poprzez konieczność operacji na długim indeksie oraz stworzenie dodatkowego wąskiego gardła dla przetwarzania transakcji.


Alokacja obiektów i rejestrowanie nieużytków (2)

Jakkolwiek druga metoda nadaje się do rejestrowania nieużytków nawet rozmiaru jednego bajtu, nie jest to zaletą, gdyż jest okupione znacznymi stratami pamięci na pozycję indeksu nieużytków.

Przy stosowaniu obydwu metod należy przyjąć zasadę, że nie wolno zaalokować (lub zmienić rozmiar) obiektu w taki sposób, że powstały po alokacji nieużytek jest mniejszy niż minimalny rozmiar obiektu.

W przeciwnym przypadku skłonność do fragmentacji przestrzeni dyskowej silnie obciąży czasy wykonania.

Według moich testów, dla dynamicznie zmieniającej się bazy danych przyjęcie tej zasady daje nawet kilkakrotne skrócenie czasów wykonania.

W przypadku wykorzystania fizycznych własności bloków dyskowych, rejestrację nieużytków na danym bloku można powiązać z organizacją informacji zawartych w tym bloku.


Fizyczna organizacja obiektów

Popularną metodą organizacji obiektów jest przechowywanie ich w postaci monolitu na jednej lub kilku sąsiednich stronach dyskowych.

Dodatkowo, wszelka metainformacja, taka jak nazwa obiektu, nazwy jego atrybutów itd. jest trzymane poza obiektem w specjalnych katalogach (metadanych). • Główną zaletą takiej organizacji jest oszczędność miejsca na dysku. • Taka organizacja ma jednakże bardzo poważne wady, wśród nich brak dostatecznej

elastyczności w zakresie zmiany rozmiaru obiektu lub jego podobiektów. Ponieważ przestrzeń dyskowa jest bardzo tania, tego rodzaju organizacja nie ma

istotnego uzasadnienia. Odwrotnością tej tendencji jest trzymanie informacji o obiekcie dokładnie

w duchu modeli M0-M3, w których relatywizm obiektów owocuje w relatywizm sposobu ich przechowywania na dysku.

W systemie Loqis każdy obiekt lub podobiekt (np. atrybut) jest odrębnym bytem, połączonym związkami pointerowymi z jego podobiektami lub nadobiektem.

Takie rozwiązanie zapewnia elastyczność w zakresie rozszerzania obiektu, np. zwiększania liczby jego atrybutów, zwiększania liczby elementów kolekcji będącej atrybutem obiektu itd. • Wadą tej metody jest wzrost ilości danych organizacyjnych (flag i pointerów).


Organizacja kolekcji obiektów (1)

W modelach składu M0-M3 przyjmujemy, że obiekty są ulokowane w jednej „płaskiej” puli, bez podziału na kolekcje. • W implementacji takie założenie jest niekorzystne, gdyż pośrednio implikuje

przeglądanie sekwencyjne zbioru wszystkich obiektów, których mogą być miliony. • Jest to również niekorzystne z punktu widzenia reprezentacji kolekcji obiektów na

stosach ENVS i QRES, gdyż w nieoptymalizowanym przypadku oznaczałoby to trzymanie tam ogromnej liczby binderów, w większości niepotrzebnie.

W związku z tym, w systemie Loqis przyjęliśmy, że dowolne obiekty opatrzone tą samą nazwą n w ramach tego samego środowiska obiektów (np. całej bazy danych) są reprezentowane przez pojedynczy, nadrzędny obiekt posiadający nazwę n, swój własny identyfikator oraz flagę „jestem reprezentantem kolekcji” („jrk”).

Dzięki temu przy wszelkich przeszukiwaniach obiektów, gdzie kryterium jest nazwa obiektu (w szczególności przy wiązaniu nazw) nie występuje konieczność wizytowania wszystkich obiektów opatrzonych tą nazwą, lecz tylko reprezentanta kolekcji.

Wynikiem przeszukiwania jest identyfikator tego reprezentanta wyposażony dodatkowo w flagę „jestem reprezentantem kolekcji”.


Organizacja kolekcji obiektów (2)

i22 Dział

i23 Nazwa ”Sprzedaż”

i24 Lokacja ”Radom”

i25 Zatrudnia i9

i26 Zatrudnia i5

i17 Dział

i18 Nazwa ”Produkcja”

i19 Lokacja ”Kielce”

i21 Zatrudnia i1

i20 Lokacja ”Kraków”

Obiekty logiczne

i77 Dział

flaga „jrk”

i17 Dział

i18 Nazwa ”Produkcja”

i19 Lokacja ”Kielce”

i21 Zatrudnia i1

i20 Lokacja ”Kraków”

i99 Lokacjaflaga „jrk”

i22 Dział



i25 Zatrudnia i9

i26 Zatrudnia i5

i88 Zatrudnia

flaga „jrk”

Fizyczna reprezentacja kolekcji obiektów


Organizacja obiektów typu spider (1)

Jedną z podstawowych operacji wykonywanych na obiekcie jest funkcja nested, która udostępnia bindery do podobiektów danego obiektu. • Bez optymalizacji funkcja ta oznacza konieczność wizytowania wszystkich

podobiektów, co może być związane ze znaczną stratą czasu na pobieranie do buforów RAMu odpowiednich bloków dyskowych.

Aby tego uniknąć, w systemie Loqis rezultat funkcji nested został umieszczony w nagłówku każdego obiektu złożonego.

Organizacja ta została nazwana „spider”.• Jest to tablica par <nazwa, identyfikator>, gdzie każda para charakteryzuje

pewien podobiekt obiektu złożonego.

• Jeżeli podobiekty mają tę samą nazwę (tj. tworzą kolekcję), wówczas identyfikator w tej parze prowadzi do reprezentanta kolekcji.

Organizacja typu „spider” została zastosowana dla wszystkich typów obiektów, niezależnie od poziomu hierarchii obiektów.


Organizacja obiektów typu spider (2)

i22 Dział



i25 Zatrudnia i9

i26 Zatrudnia i5

Obiekt logiczny

i22 Dział

Fizyczna reprezentacja obiektu typu „spider”

i88Zatrudnia

i24Lokacja

i23Nazwa


i22


i22

i25 Zatrudnia i9

i26 Zatrudnia i5

i88 Zatrudnia

flaga „jrk”

i22


Słownik nazw danych

Dość częstą operacją jest porównywanie nazw danych i w wielu przypadkach jest to operacja czasochłonna.

Jeżeli ponadto dopuścimy długie nazwy, np. 100 bajtów, wówczas reprezentacja wszystkich nazw w składzie obiektów zajmie bardzo dużo miejsca, gdyż nawet nazwy 3-znakowe będą wymagać 100 bajtów.

Aby tego uniknąć, w systemie Loqis przyjęliśmy, że każda nazwa będzie reprezentowana przez 2-bajtowy kod będący odsyłaczem do słownika.

Dwa bajty powodują ograniczenie liczby nazw do ok. 65 000, co dla większości zastosowań jest wystarczające. • Słownik można zorganizować jako tablicę o stałym formacie, gdzie kod

nazwy jest indeksem tablicy. • Tablica jest przechowywana jako trwały obiekt w bazie danych. • Tablica ta jest wczytywana do RAM na początku każdej sesji użytkownika

i następnie rozszerzana o nazwy tymczasowe występujące w tej sesji. Nowe nazwy obiektów trwałych powinny być bezpośrednio alokowane do

tablicy przechowywanej na dysku.


Tradycyjne oszczędne organizacje obiektów

Tradycyjnie, obiekt jest upakowany oszczędnie i przechowuje wyłącznie wartości swoich atrybutów. • Nazwy obiektu i podobiektów nie są w nim reprezentowane. • Informacja o podobiektach nie występuje w samym obiekcie: ma ona postać

tzw. offsetu. • Wiązanie jest statyczne, czyli dokonywane jest podczas kompilacji.

Z punktu widzenia współczesnych wymagań na obiekty baz danych, ta organizacja ma wiele wad, w szczególności uniemożliwia:• dynamiczne rozszerzanie obiektu o nowe podobiekty, • kolekcje podobiektów, • rozszerzanie długości jego atrybutów, • atrybuty będące długimi wartościami (tzw. BLOBy) itd.

Uzasadnieniem tej organizacji jest czas dostępu do obiektu i jego podobiektów, gdyż wtedy całość obiektu, wraz z atrybutami, jest sprowadzana do pamięci operacyjnej w ramach jednego odczytu.

Organizacja ta nie jest sprzeczna z podejściem stosowym i można ją potraktować jako jedną z optymalizacji.


„Leniwe” wiązanie (1)

Oficjalna semantyka SBQL wymaga zastosowania funkcji nested do identyfikatora obiektu i, a następnie włożenia odpowiedniej sekcji na stos ENVS.

W większości przypadków takie rozwinięcie binderów wszystkich podobiektów obiektu i jest niepotrzebne, gdyż wiązana jest pojedyncza nazwa n, zatem wkładanie na stos binderów wynikających z funkcji nested i opatrzonych inną nazwą jest niepotrzebne.

Ta obserwacja pozwala na ograniczenie ilości operacji dokonywanych na stosach, zgodnie z następującą regułą: • Jeżeli nested działa na identyfikatorze i, to wynikiem jest para

<flaga ”nested”, i >.

• Flaga „nested” informuje, że ten element jest substytutem działania funkcji nested na identyfikatorze i. Wartość funkcji nested nie jest fizycznie wyznaczana.

• Taka para może dowolnie długo wędrować po stosach, aż do momentu, kiedy jej rozwinięcie będzie niezbędne.


„Leniwe” wiązanie (2)

Jeżeli dokonywane jest wiązanie nazwy n, zaś w kolejnej sekcji stosu występuje element <flaga ”nested”, i >, to następuje fizyczne przeszukanie podobiektów obiektu i, posiadających nazwę n; ich referencje są rezultatem wiązania. • Dzięki temu funkcja nested nie jest w ogóle liczona.

Jeżeli ponadto wiadomo, że ta nazwa musi być związana w tej sekcji stosu (co wynika z analizy statycznej zapytania), to wynikiem może być trójka<flaga „zastępca identyfikatora”, i, n>

zastępująca identyfikator podobiektu nazwanego n w ramach obiektu i.

Taki zastępczy identyfikator nie wymaga odwołania do składu obiektów i może być przechowywany zarówno na stosie ENVS, jak i QRES aż do momentu, kiedy właściwy identyfikator będzie rzeczywiście niezbędny.

Leniwe wiązanie pozwala znacznie ograniczyć ilość niezbędnych odwołań do dysku oraz zredukować operacje na stosach.

Konstrukcja systemów obiektowych i rozproszonych

Documents

Transcript of Konstrukcja systemów obiektowych i rozproszonych