ДВАНАДЦЯТЬ ОСНОВНИХ ЦІЛЕЙ РОЗПОДІЛЕНИХ СИСТЕМ 1.

Локальна незалежність

Вузли в розподіленої системі повинні бути незалежні, або автономні Локальна незалежність означає, що всі операції на вузлі контролюються цим вузлом Ніякої вузол X не повинен залежати від деякого вузла Y, щоб успішно функціонувати (інакше, якщо вузол Y буде відключений, вузол X не зможе функціонувати, навіть якщо на самому вузлі X буде все в порядку виникнення таких ситуацій, безумовно, небажано) Локальна незалежність також означає, що локальні дані мають локальну приналежність, управління та облік Всі дані реально належать одній і тій же локальній базі даних, навіть якщо доступ до неї здійснюється з інших, віддалених вузлів Отже, такі питання, як безпека, цілісність, захист та представництво локальних даних на фізичному пристрої зберігання, залишаються під контролем і в межах компетенції локального вузла

Насправді, локальна незалежність не цілком досяжна – є безліч ситуацій, в яких вузол X повинен відмовлятися певною мірою від контролю на користь вузла у Тому мета досягнення локальної незалежності точніше можна було б сформулювати так: вузли повинні бути незалежними в максимально можливої ступеня (Див анотацію до [2113], де це питання описаний докладніше)

2 Відсутність залежності від центрального вузла

Локальна незалежність припускає, що всі вузли в розподіленої системі повинні розглядатися як рівні Тому, зокрема, не повинно бути ніяких звернень до центральному, або головному, вузлу для отримання деякої централізованої послуги Не повинно бути, наприклад, централізованої обробки запитів, централізованого управління транзакціями або централізованої служби присвоювання імен, оскільки в таких випадках система в цілому буде залежною від центрального вузла Таким чином, друга мета насправді є наслідком першої мети – якщо перша мета досягнута, то друга мета також завідомо досягається Але досягнення мети Відсутність залежності від центрального вузла корисно саме по собі, навіть якщо повна локальна незалежність вузлів не буде досягнута Тому окрема формулювання даної мети також важлива

Залежність від центрального вузла може виявитися небажаної принаймні по двох наступних причин По-перше, такий центральний вузол, швидше за все, стане вузьким місцем системи, і, по-друге (що ще гірше), система стане вразливою – Якщо робота центрального вузла буде порушена, то вся система вийде з ладу (проблема єдиного джерела відмови)

3 Безперервне функціонування

У загальному випадку перевага розподілених систем полягає в тому, що вони повинні надавати більш високий ступінь надійності і доступності

ш Надійність розуміється як висока ступінь ймовірності того, що система буде працездатна і буде функціонувати в будь-який заданий момент Надійність розподілених систем підвищується за рахунок того, що вони не спираються на принцип все або нічого; розподілені системи можуть безперервно функціонувати (щонайменше, у скороченому варіанті) навіть у випадках відмов частини їх компонентів, таких як окремий вузол

■&nbsp Доступність розуміється як висока ступінь ймовірності того, що система виявиться справною і працездатною і буде безперервно функціонувати протягом певного часу Доступність, як і надійність розподілених систем також підвищується – частково з тих же причин, а також завдяки можливості дублювання даних (подробиці наводяться в коментарі до мети 6)

Попередні міркування відносяться до випадків незапланованого відключення системи, тобто до аварійних ситуацій, які можуть виникнути в системі в будь-який момент Незаплановані відключення системи, безумовно, небажані, але їх важко попередити Плановані відключення системи, навпаки, ніколи не повинні бути необхідними, тобто ніколи не повинна виникати необхідність відключити систему, щоб виконати якусь завдання, наприклад, додати новий вузол або замінити на вже існуючому вузлі поточну версію СУБД її нової реалізацією

4 Незалежність від розташування

! Основна ідея незалежності від розташування, або так званої

прозорості

розташування, проста Користувачі не повинні знати, де саме дані зберігаються фізично і повинні чинити так (принаймні, з логічної точки зору), як якби всі дані зберігалися на їх власному локальному вузлі Завдяки незалежності від розташування спрощуються для користувача програми і термінальні операції Зокрема, дані можуть бути перенесені з одного вузла на інший, і це не повинно

вимагати внесення будь-яких змін до використовують їх програми або дії користувачів Така переносимість бажана, оскільки вона дозволяє переміщати дані в мережі відповідно до мінливих вимогами до ефективності роботи системи

Примітка Неважко помітити, що незалежність від розташування являє собою просте розширення звичайної концепції фізичноїнезалежності від даних стосовно до розподілених систем Забігаючи трохи наперед, слід сказати, що насправді кожну з цілей, в назві якої вжито слово незалежність, можна розглядати як розширення звичайної концепції фізичної незалежності від даних, у чому ми скоро переконаємося Ми ще повернемося до питання незалежності від розташування в розділі 214, в якому обговорюватиметься присвоювання імен обєктам (Підрозділ Управління каталогом)

5 Незалежність від фрагментації

Система підтримує незалежність даних від фрагментації, якщо деяка змінна відносини може бути розділена на частини, або фрагменти, при організації її фізичного зберігання, а різні фрагменти можуть зберігатися на різних вузлах Фрагментація бажана для підвищення продуктивності системи У цьому випадку дані можуть зберігатися в тому місці, де вони найчастіше використовуються, що дозволяє досягти локалізації більшості операцій та зменшення мережевого трафіку Наприклад, розглянемо змінну відносини ОМР з даними про службовців, приклад даних якої наведено на рис 212 У системі, яка підтримує незалежність від фрагментації, два фрагмента цієї змінної відносини можна визначити наступним чином (див нижню частину рис 212)

FRAGMENT EMP AS

N_EMP AT SITE New York1 WHERE DEPT#    =  DEPT# (Dl)

OR   DEPT# =    DEPT#     (D3) , L_EMP AT SITE London  WHERE DEPT#    =  DEPT# (D2)

Примітка Тут мається на увазі, що кортежі з даними про службовців змінної відносини ОМР відображаються у фізичній памяті якимось безпосереднім способом, причому D1 і D3 – відділи, розташовані в Нью-Йорку, a D2 – відділ, розташований в Лондоні Таким чином, кортежі з даними про службовців з Нью-Йорка зберігаються на вузлі в Нью-Йорку, а кортежі з даними про службовців з Лондона – на вузлі в Лондоні Відзначимо, що внутрішньосистемні імена фрагментів-N_EMP І L_EMP

Існує два основних види фрагментації: горизонтальна івертикальнавони відповідають реляційним операціями скорочення і проекції (на рис 212 показаний приклад горизонтальної фрагментації) У більш загальному випадку фрагмент можна представити у вигляді результату довільного поєднання операцій скорочення і проекції Вони є довільними, якщо не враховувати описані нижче умови

У разі операції скорочення це повинна бути ортогональнадекомпозиція в сенсі, зазначеному в розділі 136 глави 13 У разі операції проекції це повинна бути декомпозиція без втрат в сенсі, зазначеному в розділах 12 і 13

Завдяки цим двом правилам всі фрагменти даної змінної відносини будуть незалежними, тобто жоден з фрагментів не може бути представлений як похідний від інших фрагментів, а також, взагалі кажучи, не може містити результат операції скорочення або проекції, який може бути отриманий на підставі даних, що зберігаються на інших вузлах

Примітка Якщо дійсно необхідно зберігати одну і ту ж частину даних в декількох різних місцях, можна скористатися системним механізмом реплікації

для досягнення такого ефекту див наступний підрозділ

Рис 212 Приклад фрагментації

Відновлення початкової змінної відносини з її фрагментів виконується за допомогою відповідних операцій зєднання і обєднання (зєднання – для вертикальних фрагментів, а обєднання – для горизонтальних) До речі, зверніть увагу на те, що завдяки першому правилу у разі обєднання операцію виключення дублікатів виконувати не потрібно (тобто обєднання має бути непересічним обєднанням)

Необхідно сказати ще кілька слів щодо вертикальної фрагментації Як стверджувалося вище, безсумнівно, що така фрагментація повинна виконуватися без втрат Тому розбиття змінної відносини ОМР, показаної на рис 212, на фрагменти-проекції, наприклад, виду {EMP #, DEPT #} і {SALARY} було б неприпустимим Проте в деяких системах збережені змінні відносини розглядаються

як мають прихований, надається системою атрибут ідентифікатор кортежу, або скорочено – атрибут TID (Tuple ID) Для кожного зберігається кортежу атрибут TID, грубо кажучи, є адресою Очевидно, що він є одним з потенційних ключів для відповідної змінної відносини Тому, наприклад, якби мінлива відносини ОМР містила такий атрибут, то вона могла б бути фрагментована на проекції {TID, EMP #, DEPT #} і {TID, SALARY}, оскільки така фрагментація вже, безумовно, виконується без втрат Також зверніть увагу на те, що якщо, наприклад, атрибут TID є прихованим, то це ніяк не порушуєінформаційний принцип, оскільки незалежність від фрагментації (яка незабаром буде розглядатися в даній главі) означає, що користувач не повинен знати про існування фрагментації

До речі, відзначимо, що простота здійснення і фрагментації, і відновлення –

це дві основні причини, по яких розподілені бази даних повинні бути саме реляційними Реляційна модель надає всі ті операції, які

необхідні для вирішення таких завдань [156]

Тепер перейдемо до головного питання Система, яка підтримує фрагментацію даних, повинна підтримувати і незалежність від фрагментації(Іноді це властивість

називають прозорістю фрагментації) Іншими словами, користувачі повинні мати

можливість працювати точно так, принаймні, з логічної точки зору, як якби дані в дійсності були зовсім не фрагментовані Незалежність від фрагментації (як і незалежність від розташування) – Це досить бажана властивість, оскільки дозволяє спростити розробку програм користувача і виконання термінальних операцій Зокрема, це властивість гарантує, що в будь-який момент дані можуть бути заново відновлені (а фрагменти перерозподілені) у відповідь на зміну вимог до ефективності роботи системи, причому ні для користувача програми, ні термінальні операції при цьому не зачіпаються

Таким чином, якщо забезпечується незалежність від фрагментації, користувачі отримують дані у вигляді деякого подання, в якому фрагменти логічно

скомбіновані за допомогою відповідних операцій зєднання і обєднання

До обовязків системного оптимізатора належить визначення фрагментів, до яких потрібно фізичний доступ для виконання будь-якого з надійшли запитів користувача Наприклад, у випадку варіанту фрагментації, показаного на рис 212, припустимо, що користувач видає наступний запит

ОМР WHERE SALARY> 40K AND DEPT # = DEPT # (Dl)

З визначень фрагментів (які зберігаються, звичайно ж, в каталозі оптимізаторові має бути відомо, що весь необхідний результат може бути отриманий тільки за даними вузла в Нью-Йорку, а значить, немає ніякої необхідності звертатися до вузла в Лондоні

Розглянемо цей приклад більш докладно Мінлива відносини ОМР з точки зору користувача може розглядатися (спрощено) як деяке уявлення, сформоване на основі базових фрагментовNJEMP і L_EMP, таким чином

VAR ОМР VIEW / * Псевдокод * / N_EMP UNION L_EMP

Тоді оптимізатор перетворює вихідний запит користувача в наступний вираз

{ N_EMP UNION L_EMP ) WHERE SALARY &gt 4OK AMD DEPT# = DEPT# (Dl)

У процесі подальшої оптимізації це вираз буде перетворено в наступний вираз (оскільки операція скорочення розподіляється по обєднанню)

( N_EMP WHERE SALARY &gt 4OK AND DEPT# = DEPT# (Dl) ) UNION ( L_EMP WHERE SALARY &gt 40K AND DEPT# =

DEPT# (Dl) )

З визначення фрагмента L_EMP в каталозі оптимізаторові буде відомо, що другий з цих двох операндів обєднання UNION еквівалентний наступному вираженню

EMP WHERE SALARY &gt 4OK AND DEPT# =

DEPT# (Dl) AND DEPT# = DEPT# (D2)

Це вираження в результаті обчислення дасть пусте ставлення, оскільки відповідна умова в конструкції WHERE ніколи не може стати істинним (TRUE) Таким чином, весь початковий запит може бути приведений до наступного вигляду

N_EMP WHERE SALARY> 40К AND DEPT # = DEPT # (Dl)

Тепер оптимізатор визначить, що потрібний доступ лише до даних вузла в НьюЙорке

Вправа Розгляньте, які дії повинен буде виконати оптимізатор

приобробці наступного запиту

EMP WHERE SALARY &gt 4OK

З попереднього обговорення випливає, що проблема підтримки операцій на фрагментованих змінних відносини в деяких аспектах має багато спільного з проблемою підтримки операцій з уявленнями, визначених за допомогою операцій зєднання і обєднання (фактично це одна і та ж проблема – вона лише проявляється на різних рівнях загальної системної архітектури) Зокрема, проблема поновлення фрагментованих змінних відносини аналогічна проблемі оновлення уявлень, визначених за допомогою операцій зєднання і обєднання (див главу 10) Звідси випливає, що оновлення деякого кортежу (Знову ж, якщо говорити нестрого) може призвести до того, що кортеж буде перенесений з одного фрагмента в іншій (і, можливо, навіть з одного вузла на інший), якщо оновлений кортеж більше не задовольняє предикату для того фрагмента, якого він належав раніше

6 Незалежність від реплікації

Система підтримує реплікацію даних, якщо дана збережена мінлива відносини (або в загальному випадку даний фрагмент даної збереженої змінної відносини) може бути представлена ​​декількома окремими копіями, або репліками, які зберігаються на декількох окремих вузлах Розглянемо конкретний приклад (рис 213) Зверніть увагу на те, що всередині системи репліки мають імена NL_EMP І LN_EMP

REPLICATE N_EMP AS

LN_EMP AT SITE London

REPLICATE L_EMP AS

NL_EMP AT SITE New York

Реплікація бажана принаймні з двох причин По-перше, вона здатна забезпечити більш високу продуктивність, оскільки програми зможуть обробляти локальні копії замість того, щоб встановлювати звязок з віддаленими вузлами По-друге, наявність реплікації може також забезпечувати більш високу ступінь доступності, оскільки будь-який реплицируемой обєкт залишається доступним для обробки (Принаймні, для вибірки даних), поки хоча б одна репліка в системі залишається доступною Головним недоліком реплікації, безумовно, є те, що якщо реплицируемой обєкт оновлюється, то і всі його копії повинні бути оновлені (проблема розповсюдження оновлень) У розділі 214 ми ще скажемо кілька слів щодо цієї проблеми

До речі, відзначимо, що реплікація в розподілених системах представляється специфічним додатком ідеї контрольованої надмірності, яка обговорювалася в розділі 1

Рис 213 Приклад реплікації даних

Очевидно, що реплікація, як і фрагментація, теоретично повинна бути прозорою для користувача. Іншими словами, система, яка підтримує реплікацію даних, повинна також підтримувати  незалежність від реплікації(Іноді говорять Прозорість реплікації) Для користувачів повинна бути створена така середу, щоб вони, принаймні, з логічної точки зору могли вважати, що насправді дані не дублюються Незалежність від реплікації (як і незалежність від розташування і незалежність від фрагментації) є дуже бажаною, оскільки вона спрощує створення програм користувача і виконання термінальних операцій Зокрема, незалежність від реплікації дозволяє створювати і знищувати дублікати в будь-який момент відповідно до вимог, що змінюються, не зачіпаючи при цьому ніякі з користувацьких програм або термінальних операцій

З вимоги незалежності від реплікації випливає, що до обовязків системного оптимізатора також належить визначення, який саме з фізичних дублікатів

буде застосований для доступу до даних при виконанні кожного введеного користувачем запиту Тут не наведені докладні відомості з цього питання

Завершуючи підрозділ, відзначимо, що багато комерційні продукти в даний час підтримують такий вид реплікації, який НЕ забезпечує повної незалежності від

реплікації, тобто реплікація буде не повністю прозора для користувача. Деякі

додаткові зауваження з цього питання будуть приведені в підрозділі про поширення оновлення в розділі 214

7 Обробка розподілених запитів

Існує дві особливості, що стосуються теми цього розділу, які необхідно попередньо прокоментувати

■ По-перше, розглянемо запит: Отримати відомості про лондонські постачальниках деталей червоного кольору. Припустимо, що користувач працює на вузлі в НьюЙорке, а дані розміщені на вузлі в Лондоні Припустимо також, що мається л постачальників, які задовольняють даному запиту Якщо система реляції онная, то для виконання цього запиту, по суті, буде потрібно пересилання двох повідомлень: одне – із запитом з Нью-Йорка до Лондона, а інше – з повертаєть мим результатом, тобто набором з л кортежів, що пересилаються з Лондона в НьюЙорк Якщо, з іншого боку, система – реляційна і використовує операції з таблицями на рівні окремих записів, виконання запиту буде, по суті, включати пересилку 2п повідомлень – л повідомлень з Нью-Йорка до Лондона, вича запитують дані наступного постачальника, і л повідомлень з Лондона в Нью-Йорк, які повертають інформацію про черговому постачальника Цей приклад показує, що по продуктивності розподілена реляційна сис тема може на кілька порядків перевершувати нереляційних

■ По-друге, оптимізація в розподілених системах навіть більш важлива, ніж в цін тралізованних Суть в тому, що для запиту, подібного розглянутому вище, може знадобитися звернення до кількох вузлів У такій системі може бути багато можливих способів пересилання даних, що дозволяють виконати рассмат Ріва запит Тому вкрай важливо, щоб була знайдена ефективна стра тегія Наприклад, запит для обєднання, скажімо, відносини Rx, що зберігається на вузлі X, і відносини Ry, що зберігається на вузлі Y, може бути виконаний за допомогою пересилання відносини Rx на вузол Y або відносини Ry на вузол X, або обох відно шений на будь-який вузол Z і тп Наочна ілюстрація важливості оптимізації ції, що включає згаданий вище запит (Отримати відомості про лондонські постачальниках деталей червоного кольору), представлена ​​в розділі 214 Підводячи короткий підсумок цього прикладу, можна відзначити, що для обробки даного запиту аналізується шість різних стратегій з урахуванням певного набору вероят них припущень В результаті показано, що час відповіді в кожному випадку различ але і змінюється в широких межах від мінімального (від однієї десятої секунди) до максимального (близько шести годин) Таким чином, оптимізація, несомнен але, вельми важлива для розподіленої системи і, крім того, цю особливість можна вважати ще однією причиною, по якій розподілені системи завжди повинні бути реляційними (Відповідь проста: реляційні системи дозволяють оп тімізіровать обробку запитів, а нереляційні-ні)

8 Управління розподіленими транзакціями

Як відомо, існує два головних аспекти управління транзакціями, а саме: управління відновленням і керування паралельністю обробки Обидва ці аспекти мають розширену трактування в середовищі розподілених систем Щоб розяснити

особливості цієї розширеної трактування, спочатку необхідно ввести нове поняття – агент У розподіленої системі окрема транзакція може зажадати виконання коду на багатьох вузлах, зокрема, це можуть бути операції оновлення, що виконуються на декількох вузлах Тому говорять, що кожна транзакція містить декілька агентів,де під агентоммається на увазі процес, який виконується для даної транзакції на окремому вузлі Система повинна знати, що два агенти є елементами однієї і тієї ж транзакції, наприклад, два агента, які є частинами однієї і тієї ж транзакції, безумовно, не повинні опинятися в стані взаємного блокування

Тепер звернемося безпосередньо до управління відновленням Щоб забезпечити нерозривність транзакції (виконання її за принципом все або нічого) в розподіленої середовищі, система повинна гарантувати, що всі безліч відносяться до даної транзакції агентів або зафіксувало свої результати, або виконало відкат Такого результату можна досягти за допомогою протоколу двухфазной фіксації транзакції, який вже обговорювався в главі 15, хоча це обговорення і не було прямо повязане з розподіленими системами Детальніше про використання протоколу двофазної фіксації в розподілених системах мова піде в розділі 214

Що стосується управління паралельністю, то воно в більшості розподілених систем базується на механізмі блокування, точно так, як і в нерозподілених системах У декількох більш нових комерційних продуктах використовується управління паралельною роботою на основі одночасної підтримки багатьох версій [161] Але на практиці звичайна блокування, мабуть, все ще залишається тим методом, який найкраще підходить для більшості систем Детальніше це питання також буде обговорюватися в розділі 214

9 Апаратна незалежність

З цього питання фактично нема чого сказати – заголовок розділу говорить сам за себе Парк обчислювальних машин сучасних організацій зазвичай включає безліч різних компютерів, припустимо, компютери виробництва компаній IBM, Fujitsu, HP, персональні компютери, різного роду робочі станції і тд Тому дійсно існує необхідність інтегрувати дані всіх цих систем і надати користувачеві образ єдиної системи [219] Отже, бажано мати можливість експлуатувати одну і ту ж СУБД на різних апаратних платформах і, більше того, домогтися, щоб різні компютери брали участь у роботі розподіленої системи як рівноправні партнери

10 Незалежність від операційної системи

Досягнення цієї мети частково залежить від досягнення попередньої і також не вимагає додаткового обговорення Очевидно, що необхідно мати не тільки можливість забезпечити функціонування однієї і тієї ж СУБД на різних апаратних платформах, а й забезпечити її функціонування під управлінням різних операційних систем для багатьох платформ – включає різні операційні системи на одному і тому ж обладнанні (наприклад, щоб версія СУБД для операційної системи OS/390, версія для UNIX і версія для Windows могли спільно використовуватися в одній і тій же розподіленої системі)

11 Незалежність від мережі

Тут, знову ж таки, нічого додати Якщо система має можливість підтримувати багато принципово різних вузлів, що відрізняються обладнанням та операційними системами, безумовно необхідно, щоб вона також підтримувала ряд типів різних комунікаційних мереж

12 Незалежність від типу СУБД

У цьому розділі ми розглянемо, з чим доводиться стикатися при відмові від вимоги суворої однорідності системи Необхідність такого сильного обмеження викликає сумніви Дійсно, здається, все, що необхідно, – так це те, щоб екземпляри СУБД на різних вузлах всі разом підтримували один і той же інтерфейс, і зовсім не обовязково, щоб це були копії однієї і тієї ж версії СУБД Наприклад, СУБД Ingres і Oracle обидві підтримують офіційний стандарт мови SQL, а значить, можна домогтися, щоб вузол з СУБД Ingres і вузол з СУБД Oracle обмінювалися повідомленнями між собою даними в рамках розподіленої системи Іншими словами, розподілені системи цілком можуть бути, принаймні, в деякій мірі,неоднорідними

Підтримка неоднорідності вельми бажана На практиці сучасне програмне забезпечення зазвичай використовується не тільки на багатьох різних компютерах і в середовищі багатьох різних операційних систем Воно досить часто використовується і з різними СУБД, і було б дуже зручно, якби різні СУБД можна було якимось чином включити в розподілену систему Іншими словами, ідеальна розподілена система повинна обеспечіватьнезавісімость від СУБД

Однак ця тема занадто обширна (і важлива на практиці), тому нижче їй присвячено окремий розділ (див розділ 216)

Джерело: Дейт К Дж, Введення в системи баз даних, 8-е видання: Пер з англ – М: Видавничий дім «Вільямс», 2005 – 1328 с: Ил – Парал тит англ

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*