1. Дистрибуиране базе података
Александар Чедић
Милан Ђорђевић
Бојана Љутић

2. Кориснику, дистрибуирани систем треба да изгледа исто као и недистрибуирани систем

3. Предности дистрибуираних база података
Локална аутономија података
Већи капацитет
Сигурност
Смањивање потребе за удаљеном комуникацијом

4. 12 изведених правила (циљева)
Локална аутономија
Не ослањати се на централни чвор више него што је потребно
Континуиран рад
Локална независност
Фрагментисање података
Репликација података
Дистрибуирана обрада упита
Дистрибуирано управљање трансакцијама
Хардверска независност
Оперативни систем независност
Мрежна независност
Независност система за управљање базама података

5. Проблеми дистрибуираних база података
Основни проблем је брзина преноса података у WAN – у.
Брзине које се постижу су и до хиљаду пута лошије него на једном рачунару
LAN мреже могу да постигну те брзине
Проблем се може свести на проблем смањења коришћења мреже.

6. Из овог проблема настеје низ проблема у следећим областима:
Обрада упита
Управљање каталогом
Пренето ажурирање
Опоравак
Конкурентност
1. Обрада упита
Због смањења употребе мреже оптимизација мора да буде дистрибуирана
Оптимизација се обавља у два корака: глобална и локална оптимизација

7. Пример 1:
Упит Q постављен на локацији X представља спајање релације од 10 хиљада n-торки које се налазе на локацији Y са релацијом која има 10 милиона n-торки које се налазе локацији Z.
Задатак оптимизатора на локацији X је да изабере глобалну стратегију за извршење упита.
Пожељно је да изабере стратегију да пребаци 10 хиљада n - торки са Y на Z и тамо изврши спајање (уместо 10 милиона на локацију Y).
У зависности од кардиналности резултата можда је боље да пребаци обе n-торке на локацију X и онда изврши спајање.
Овај корак зависи у потпуности од оптимизатора на локацији Z.

8. Пример 2: Свака n-торка је величине од 25 бајтова (200 битова)
S [SNABDEVAC, GRAD] n – торки на лок. A
P [DEO, BOJA] n – торки на лок. B
SP[SNABDEVAC, DEO] n – торки на л. A
Свака n-торка је величине од 25 бајтова (200 битова)
Брзина преноса података у мрежи је битова у секунди, а кашњење је 0.1 секунда.
Упит: Пронаћи све снабдеваче из Лондона који испоручују неки црвени део.
Претпоставимо да таквих снабдевача има , а да црвених делова има 10.

9. Разматрамо шест стратегија за извршење овог упита.
Време комуникације рачунамо на следећи начин:
(укупно кашњење) + (укупна количина података / брзина преноса)
или
(број порука * 0,1) + (број битова / )

10. Пример 2: Закључак

11. Пример 2: Закључак
Разлике у брзинама су огромне
За брзину су важни и брзина преноса и кашњење.
Време извршавања упита је занемарљиво у односу на времена комуникација за лош избор стратегија
У примерима није узето у обзир која локација добија крајњи резултат
Неке стратегије дозвољавају паралелно процесуирање на више локација.

12. 2. Управљање каталогом
Због фрагментације података каталог мора имати и додатне информације.
Проблем смештања.
Каталог може бити:
Централизован (на једној локацији)
Потпуно поновљен (свака локација има копију)
Партиционисан (свака локација има само оне податке који се односе на њене објекте)
Комбинован (партиционисан, једна локација има комплетан каталог)
Недостаци су зависност од једне локације или време приступа и зато се у пракси користи нешто другачији приступ.

13. Имплементација на систему R*
Глобално именовање објеката
Гарантована је непроменљивост имена.
Кориснику се имена објеката представљају или локалним именом или синонимом.
Синоними (CREATE SYNONYM)

14. Каталог на систему R* има следеће информације:
Слог за сваки објекат направљен на тој локацији (и тренутну локацију, ако је премештен)
Слог који садржи све објекте који се тренутно налазе на тој локацији
Табелу синонима за сваког корисника која пресликава синониме објеката у глобална системска имена.
Претрага функционише на следећи начин:
Корисник унесе синоним за неки објекат
Систем проналази глобално име у табели синонима
Из глобалног имена узима локацију где је направљен објекат (у којој пише и где се тренутно налази објекат)
Ако није премештан знамо његову локацију, а ако јесте потребна је још највише једна промена локације да бисмо га лоцирали.
DB2 поседује сличну шему назива као R*.

15. 3. Пренето ажурирање
Понављањем података јавио се проблем како ажурирати исте податке на различитим локацијама.
Прва идеја је ажурирати све податке од једном.
али ово није добро ако је нека локација недоступна
Концепт примарне копије:
Једна копија сваког поновљеног објекта проглашава се примарном копијом (све остале су секундарне)
Примарне копије различитих објеката чувају се на различитим локацијама
Ажурирање се сматра логички завршеним када се ажурира примарна копија

16. Неки системи користе методу асинхроне репликације
Ажурирање секундарних копија је у надлежности локације где се налази примарна копија (оно се мора обавити пре завршетка трансакције)
Ажурирање секундарних копија се извршава протоколом двофазног комплетирања трансакције
Могуће неизвршавање трансакције у случају да је локација примарне копије недоступна
Неки системи користе методу асинхроне репликације
Ажурирање после комплетирање трансакције
Не може се гарантовати конзистентност података
Већа брзина извршавања

17. 4. Опоравак
Заснива се на методи двофазног комплетирања трансакције или некој варијанти тог протокола
Захтеви:
Да свака локација буде способна да буде координатор трансакције
Координатор трансакције мора да комуницира са учесницима трансакције
Учесници трансакције, по потреби, морају да буду под привременом контролом координатора
Опис двофазне COMMIT операције:
Координатор шаље поруку учесницима да ажурирају објекте
Када координатор добије потврду од учесника да су извршили ажурирање он шаље поруку да се изврши COMMIT, у супротном шаље поруку за ROLLBACK

18. Ово је сложеније у пракси због могућности пада неке локације
У случају пада координатора дилема се избегава читањем података из системског лога
Координатор мора да памти своје одлуке (COMMIT или ROLLBACK) у случају пада неке локације
Немогуће је гарантовати да ће ова процедура бити отпорна на падове
Побољшања:
Претпостављени COMMIT
Претпостављени ROLLBACK

19. Претпостављени COMMIT:
Ако је издата ROLLBACK порука он чека потврду свих учесника да су извршили ROLLBACK
У случају пада неке локације она проверава лог координатора
Ако има информација о трансакцији онда треба да изврши ROLLBACK, у супротном COMMIT
Претпостављени ROLLBACK:
Претпоставља се да је извршен ROLLBACK, лог се чува на сличан начин као и за претпостављени COMMIT
Претпостављени ROLLBACK даје боље резултате

20. 5. Конкурентност Заснива се на закључавању Оно мора бити дистрибуирано
Претпоставимо да за трансакцију Т постоји n локација са поновљеним објектима.
Уобичајна имплементација би захтевала 5n порука:
n порука за закључавање
n повратних порука
n порука за ажурирање
n порука за откључавање
Ефикасније је слати поруке за закључавање и ажурирање заједно, али ни ово није добро

21. Решење је да се користи стратегија примарне копије:
Локација која садржи примарну копију одговорна је за слање порука о закључавању
Сада имамо 2n+3 поруке (једна за закључавање, једна повратна, n порука за ажурирање, n повратних порука, једна порука за откључавање)
Трансакција се неће извршити ако је локација са примарном копијом у паду
Смањење перформанси због обавезног закључавања примарне копије

22. Проблем који такође настаје је проблем узајамног блокирања трансакције (тј. deadlock-а)
У њему може да учествује више две или више локација
Ниједна локација не може да открије проблем на основу својих информација
Морају се спојити учесници трансакције да би се открила блокада
Неки системи за откривање користе timeout механизам

23. Пример deadlock-a (блокаде)

24. КЛИЈЕНТ / СЕРВЕР СИСТЕМ
Клијент/сервер је дистрибуиран систем у ком:
неке локације су клијент локације, а неке сервер локације
сви подаци се налазе на сервер локацијама
све апликације се извршавају на клијент локацијама
није могућа потпуна локациона независност

25. Неколико клијената могу да деле исти сервер
Један клијент може да приступи неколико сервера, одакле имамо два случаја:
клијент је ограничен да приступа само једном серверу
клијент може да приступи већем броју сервера истовремено

26. КЛИЈЕНТ/ СЕРВЕР СТАНДАРДИ
Разликујемо неколико стандарда:
Одређене клијент/сервер карактеристике су укључене у SQL стандард.
ISO Remote Data Access (RDA) стандард.
Distributed Relational Database Architecture (DRDA) стандард.

27. КЛИЈЕНТ/ СЕРВЕР АПЛИКАТИВНО ПРОГРАМИРАЊЕ
Релациони системи су set – level системи
Мора што више функционалности бити упаковано у set-level захтеве

28. ПРОЛАЗ (GАТЕWАY)

29. DATA ACCESS MIDDLEWARE
SQL СРЕДСТВА