Sr-8-wyk-1.0-Slajd16
Relokacja — charakterystyka
Relokacja danych jest atrakcyjna z tego powodu, że pozwala na zwiększenie wydajności dostępu dodanych, nie powodując jednocześnie powstawania problemu spójności. Generuje jednak inne problemu, m.in. problem lokalizacji obiektów, do których kierowane są odwołania. Ponieważ jednostka zmienia swoją lokalizację (adres), przy każdym odwołaniu konieczne jest ponowne jego ustalenie, co może zredukować potencjalne zyski.
Innym problemem związanym ze stosowaniem relokacji jest kwestia właściwego doboru rozmiaru i struktury obiektu . Utrzymywanie małych obiektów umożliwia podział wspólnych danych na serwery, w których występują odwołania do nich. Z drugiej jednak strony z każdym obiektem związane są pewne struktury danych przechowujące informację zarządzającą (bieżący adres, tryb dostępu, właściciel itp.). Stosowanie dużych obiektów nie obciąża systemu dużymi kosztami administracyjnymi, ale wymaga sporych nakładów podczas przenoszenia obiektów z węzła na węzeł. W efekcie mamy tu do czynienia z kompromisem między zyskiem związanym z lokalnym dostępem a kosztami związanymi z zarządzaniem i relokacją obiektów. Pewnym rozwiązaniem jest stosowanie podejścia strukturalnego (hierarchicznego) do tworzenia obiektów. Obiekt jako całość może mieć wyodrębnione swoje – w miarę niezależne – części, które mogą być przemieszczane w oderwaniu od obiektu głównego.
Ostatnim istotnym problemem relokacji jest problem migotania , polegający na nieustannym przenoszeniu obiektu między dwoma lub większą liczbą węzłów, z powodu występujących na tych węzłach odwołań. Sytuacja taka może mieć miejsce, gdy procesy naprzemiennie odwołują się do wspólnych danych. W tym przypadku bardziej opłacalne może się okazać pozostawienie obiektu w jednym z tych węzłów i realizowanie pozostałych odwołań zdalnie. Chcąc uniknąć takiego przypadku, system musi monitorować charakterystykę odwołań do obiektu i szacować prawdopodobieństwo lokalizacji przyszłych odwołań.
