© 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ła Technik Komputerowych, Warszawa Instytut Podstaw Informatyki PAN, Warszawa Wykład 4: Wprowadzenie do optymalizacji zapytań Metody organizacji i udostępniania danych

© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 4, Folia 2 październik 2004 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.

© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 4, Folia 3 październik 2004 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.

© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 4, Folia 4 październik 2004 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.

© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 4, Folia 5 październik 2004 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.

© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 4, Folia 6 październik 2004 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..*] Nazwisko Imię[1..*] Adres[1..*] ZFZFPZ[0..*]ZPZP Firma[0..*] Nazwa Miejsce[1..*] Zatrudnienie[0..*] Wypłata[0..*] Ocena[1..*] Pracownik[0..*] Stan[1..*]

© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 4, Folia 7 październik 2004 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 )

© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 4, Folia 8 październik 2004 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.

© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 4, Folia 9 październik 2004 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.

© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 4, Folia 10 październik 2004 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.

© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 4, Folia 11 październik 2004 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.

© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 4, Folia 12 październik 2004 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.

© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 4, Folia 13 październik 2004 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.

© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 4, Folia 14 październik 2004 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ż 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.

© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 4, Folia 15 październik 2004 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.

© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 4, Folia 16 październik 2004 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ń

© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 4, Folia 17 październik 2004 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.

© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 4, Folia 18 październik 2004 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).

© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 4, Folia 19 październik 2004 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, 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.

© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 4, Folia 20 październik 2004 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.

© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 4, Folia 21 październik 2004 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.

© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 4, Folia 22 październik 2004 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).

© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 4, Folia 23 październik 2004 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.

© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 4, Folia 24 październik 2004 Organizacja kolekcji obiektów (2) i 22 Dział i 23 Nazwa Sprzedaż i 24 Lokacja Radom i 25 Zatrudnia i 9 i 26 Zatrudnia i 5 i 17 Dział i 18 Nazwa Produkcja i 19 Lokacja Kielce i 21 Zatrudnia i 1 i 20 Lokacja Kraków Obiekty logiczne i 77 Dział flaga jrk i 17 Dział i 18 Nazwa Produkcja i 19 Lokacja Kielce i 21 Zatrudnia i 1 i 20 Lokacja Kraków i 99 Lokacja flaga jrk i 22 Dział i 23 Nazwa Sprzedaż i 24 Lokacja Radom i 25 Zatrudnia i 9 i 26 Zatrudnia i 5 i 88 Zatrudnia flaga jrk Fizyczna reprezentacja kolekcji obiektów

© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 4, Folia 25 październik 2004 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, 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.

© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 4, Folia 26 październik 2004 Organizacja obiektów typu spider (2) i 22 Dział i 23 Nazwa Sprzedaż i 24 Lokacja Radom i 25 Zatrudnia i 9 i 26 Zatrudnia i 5 Obiekt logiczny i 22 Dział Fizyczna reprezentacja obiektu typu spider i 88 Zatrudnia i 24 Lokacja i 23 Nazwa i 23 Nazwa Sprzedaż i 22 i 24 Lokacja Radom i 22 i 25 Zatrudnia i 9 i 26 Zatrudnia i 5 i 88 Zatrudnia flaga jrk i 22

© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 4, Folia 27 październik 2004 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 , 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.

© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 4, Folia 28 październik 2004 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.

© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 4, Folia 29 październik 2004 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 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.

© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 4, Folia 30 październik 2004 Leniwe wiązanie (2) Jeżeli dokonywane jest wiązanie nazwy n, zaś w kolejnej sekcji stosu występuje element, 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 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.