Ідентифікація об’єктів corba і com в мережі. Основні відмінності

CORBA і СОМ абсолютно по-різному підходять до проблем ідентифікації (identity) об’єктів і їх збереження в довгостроковій пам’яті (persistance). CORBA вводить поняття об’єктної посилання (object reference), яка унікальним чином ідентіфіціруетоб’ект в мережі. Тим самим примірника об’єкта дається право на існування протягом деякого часу. Об’єкти можуть активуватися, зберігатися в довгострокову пам’ять, пізніше знову активувати і деактивувати, і при цьому об’єктне посилання буде вказувати весь час на один і той же конкретним втіленням об’єкта. Для об’єктів, призначених для тривалого використання, об’єктні посилання можуть інтегруватися зі службою каталогів або службою імен. Клієнт не має ніяких легальних засобів виявити, куди і яким чином зберігається екземпляр об’єкта. Служба іменування InteroperableNaming Service призначена для прозорого пошуку і виклику об’єктів, що не залежить від конкретної реалізації ORB.

У СОМ поняття об’єктної посилання відсутня. Найближчий аналог – це механізм moniker, що забезпечує перетворення символьного імені об’єкта в покажчик інтерфейсу. Цей механізм діє для тих об’єктів, які зберігаються в довгостроковій пам’яті. Два ж активних об’єкта вважаються ідентичними, якщо для них збігаються покажчики на інтерфейс IUnknown.

Для довготривалого зберігання в СОМ підтримуються дві моделі. Перша і початкова модель надає клієнту можливість управляти зберіганням об’єкту. Інший, більш пізній варіант збереження в довготривалу пам’ять в СОМ передбачає використання Microsoft Transaction Server (MTS), який забезпечує управління зберіганням з боку сервера.

Мови опису інтерфейсів CORBA і COM. Основні властивості

У CORBA мова опису інтерфейсів – найважливіша частина архітектури, основа схеми інтеграції об’єктів. Всі інтерфейси і типи даних визначаються на IDL. Різні мови програмування підтримуються завдяки заданим відображенням між описами типів даних на IDL в відповідні визначення на конкретній мові. CORBA IDL задає визначення, які можуть відображатися в безліч різних мов, не вимагаючи при цьому жодних змін від цільового мови. Ці відображення реалізуються компілятором IDL, який генерує вихідні коди потрібною мовою. На даний момент підтримується відображення в C, C ++, SmallTalk, Ada, Delphi, Visual Basic, Cobol і Java. Сам IDL синтаксично нагадує декларації типів в Сі ++, але не ідентичний цій мові.

У Microsoft IDL (MIDL) – лише один з можливих способів визначення інтерфейсів об’єкта. Технологія COM реалізує інтеграцію на дочірньому рівні, тому всі специфікації і стандарти, які стосуються рівню вихідних текстів компонентів, є допоміжними і не надають вирішального впливу на загальну архітектуру системи. Мова MIDL прив’язаний до платформи.

MIDL, що є розширенням DCE RPC IDL, не визначає загального набору типів даних, доступних різним мовам програмування. На MIDL можна визначити інтерфейси і типи даних, які відповідають програмам на C, C ++, Visual Basic, Java.

Основні вбудовані об’єктні служби corba і com

Служби COM:

• захист (security),

• управління життєвим циклом (lifecycle managemеnt),

• інформація про типи (type information),

• іменування (naming),

• доступ до баз даних (database access),

• передача даних (data transfer),

• реєстрація (registry),

• асинхронне взаємодія.

Служби CORBA (16):

• іменування (naming),

• події (events),

• життєвий цикл (life cycle),

• довгострокове зберігання об’єктів (persistent),

• транзакції (transactions),

• контроль за доступом до ресурсів (concurrency control),

• відносини (relationsips),

• імпорт / експорт (externalization),

• запити (query),

• ліцензування (licensing),

• властивості (property),

• час (time),

• захист (security),

• переговори між об’єктами (object trader),

• збір об’єктів (object collections),

• служба асинхронного обміну повідомленнями (asynchronous messaging).

Операційні середовища функціонування CORBA і COM. Висновки порівняльного аналізу двох технологій.

• Обидві технології розвиваються і ускладнюються.

• CORBA є більш універсальною, ніж COM, розрахована на неоднорідну мережу.

• CORBA відповідає розподіленої системі галузі, COM – робочій групі.

• COM поступається CORBA в організації захисту, управлінні транзакціями і координованих розподілі структур.

• Ряд продуктів дозволяє використовувати спільно ці технології.

Лекція 6:

Розподілені СУБД. Архітектура MS SQL Server 2008.

Для кращого розуміння принципів роботи сучасних СУБД розглянемо структуру однієї з найбільш поширених клієнт-серверних СУБД – Microsoft SQL Server 2008. Незважаючи на те, що кожна комерційна СУБД має свої відмінні риси, інформації про те, як влаштована якась із СУБД, зазвичай буває досить для швидкого початкового освоєння іншої СУБД. Короткий огляд можливостей Microsoft SQL Server – 2008 року було наведено в розділі, присвяченому короткому огляду сучасних СУБД. В даному розділі розглянемо основні моменти, пов'язані зі структурою відповідної СУБД (архітектурою бази даних і структурою програмного забезпечення).

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

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

Фізичний рівень (внутрішнє подання даних в пам'яті ЕОМ – фізична структура бази даних). Даний рівень розгляду на увазі вивчення бази даних на рівні файлів, що зберігаються на жорсткому диску. Структура цих файлів - особливість кожної конкретної СУБД, в т.ч. і Microsoft SQL Server.

Microsoft SQL Server 2008 презентує собою реляційну СУБД (дані представляються у вигляді таблиць). Таким чином, основною структурою моделі даних цієї СУБД є таблиці.

Таблиці містять дані про всіх сутності концептуальної моделі бази даних. При описі кожного стовпчика (поля) користувач повинен визначити тип відповідних даних. Microsoft SQL Server 2008 підтримує як вже традиційні типи даних (символьний рядок з різним поданням, число з плаваючою точкою довжиною 8 або 4 байта, ціле число довжини 2 або 4 байти, дата і час, поле приміток, логічне значення і т. Д. ), так і нові типи даних. Крім етогоMicrosoft SQL Server 2008 надає спеціальний апарат для створення користувацьких типів даних.

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

Просторові дані – це дані, що визначають географічні розташування і форми, переважно на Землі. Це можуть бути орієнтири, дороги і навіть розташування фірми. У SQL Server 2008 є географічні (geography) і геометричні (geometry) типи даних для роботи з цією інформацією. Тип даних geography працює з інформацією для кулястої землі. Модель кулястої землі використовує при розрахунках кривизну земної поверхні. Інформація про стан задається широтою і довготою. Ця модель добре годиться для додатків, пов'язаних з морськими перевезеннями, військовим плануванням і короткостроковими програмами, що мають прив'язку до земної поверхні. Цю модель потрібно використовувати, якщо дані зберігаються у вигляді широт і довгот.

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

Типи geography і geometry створюються з векторних об'єктів, заданих в форматах Well-Known Text (WKT) або Well-Known Binary (WKB). Це формати для перенесення просторових даних, описані в простих функціях відкритого геопространственного консорціуму (Open Geospatial Consortium (OGC) Simple Features) для специфікацій SQL (SQL Specification).

Для кожної таблиці повинен бути визначений первинний ключ - мінімальний набір атрибутів, унікально ідентифікує кожну запис в таблиці. Для реалізації зв'язку між таблицями в одну з пов'язаних таблиць включається додаткове поле (кілька полів) – первинний ключ іншої таблиці. Додатково включені поле або поля в цьому випадку називаються зовнішнім ключем відповідної таблиці. Крім таблиць, в модель даних Microsoft SQL Server 2008 входить ще цілий ряд компонентів.

Індекси створюються для прискорення пошуку потрібної інформації і містять інформацію про впорядкованості даних за різними критеріями. Індексування може бути виконано по одному або кількох стовпців. Індексування може бути вироблено в будь-який момент. Індекс містить ключі, побудовані з одного або декількох стовпців в таблиці або поданні. Ці ключі зберігаються у вигляді структури збалансованого дерева, яка підтримує швидкий пошук рядків по їх ключовим значенням в SQL Server.

Представлення – це віртуальна таблиця, вміст якої визначається запитом. Подання формується на основі SQL-запиту SELECT, який формується за звичайними правилами. Таким чином, уявлення є пойменований запит SELECT.

Як і справжня таблиця, подання складається із сукупності іменованих стовпців і рядків даних. Поки подання не буде проіндексовано, воно не існує в базі даних як збережена сукупність значень. Рядки і стовпці даних беруться з таблиць, зазначених у визначальному уявлення запиті і динамічно створюваних при зверненнях до подання. Подання виконує функцію фільтру базових таблиць, на які вона посилається. Визначальний уявлення запит може бути ініційований в одній або кількох таблицях або в інших уявленнях поточної або інших баз даних. Крім того, для визначення уявлень з даними з декількох різнорідних джерел можна використовувати розподілені запити. Це корисно, наприклад, якщо потрібно об'єднати структуровані таким чином дані, що відносяться до різних серверів, кожен з яких зберігає дані конкретного відділу організації.

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

Обмеження дозволяють задати метод, за допомогою якого компонент СУБД Database Engine автоматично забезпечує цілісність бази даних. Обмеження задають правила допустимості певних значень в стовпцях і являють собою стандартний механізм забезпечення цілісності. Рекомендується використовувати обмеження, а не тригери, правила і значення за замовчуванням. Оптимізатор запитів також використовує визначення обмежень для побудови високопродуктивних планів виконання запитів.

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

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

Лекція 7:

Поняття транзакції. Неявні і явні транзакції. Рівні ізольованості транзакцій в MS SQL Server 2008.

Поняття транзакції. Неявні і явні транзакції.

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

Транзакції бази даних володіють властивостями, скорочено званими ACID (Atomicity, Consistency, Isolation, Durability).

• Неподільність (Atomicity). Транзакція або виконується повністю, або не виконується.

• Узгодженість (Consistency). Транзакція переводить базу даних з одного узгодженого стану в інше.

• Ізольованість (Isolation). Результати транзакції стають доступні для інших транзакцій тільки після її фіксації.

• Тривалість (Durability). Після фіксації транзакції зміни стають постійними.

Всі команди, що виконуються користувачами на сервері, виробляються в тілі транзакцій. Однак існує два підходи до вказівкою меж транзакцій в потоці команд – явні і неявні транзакції.

Явні транзакції. За замовчуванням, кожна команда виконується як окрема транзакція. Користувач може об’єднати кілька команд в одну транзакцію, явно вказавши її початок і кінець.

Неявні транзакції. Не існує оператора початку транзакції. Транзакція починається з початком сеансу роботи з БД. Завершується транзакція при наступних подіях:

• Явно виконаний оператор завершення транзакції – rollback або commit

• Оператор DDL

• Завершення сеансу.

Після закінчення транзакції одразу неявно починається нова транзакція.

Рівні ізольованості транзакцій, відмінності реалізації Oracle від інших СУБД

Проблеми організації паралельної роботи:

1. Проблема втраченого поновлення.

2. Проблема залежності від незафіксованих результатів.

3. Непогоджена обробка даних

Відповідно визначають чотири сценарії взаємовпливу кількох транзакцій з точки зору обробки одних і тих же даних.

• Брудне читання (dirty read). Допускається читання незафіксованих ( "брудних") даних. При цьому порушується як цілісність даних, так і вимоги зовнішнього ключа, а вимоги унікальності ігноруються.

• неповторність при читанні (non-REPEATABLE READ). Це означає, що якщо рядок читається в момент часу T1, а потім перечитується в момент часу T2, то за цей період вона може змінитися. Рядок може зникнути, може бути оновлена ​​і так далі.

• Читання фантомів (phantom read). Це означає, що якщо виконати запит в момент часу T1, а потім виконати його повторно в момент часу Т2, в базі даних можуть з’явитися додаткові рядки, що впливають на результати. Від неповторності при читанні це явище відрізняється тим, що прочитані дані не змінилися, але критеріям запиту стало задовольняти більше даних, ніж раніше.

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

Особливості реалізації транзакцій в Oracle і MS Sql Server

Загальні оператори управління транзакціями

• COMMIT (COMMIT WORK). Оператор COMMIT завершує транзакцію і робить будь-які виконані в ній зміни постійними (тривалими). У розподілених транзакцій використовуються розширення оператора COMMIT. Ці розширення дозволяють помітити оператор COMMIT (точніше, позначити транзакцію), задавши для нього коментар, а також примусово зафіксувати сумнівну розподілену транзакцію.

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

• SAVEPOINT. Оператор SAVEPOINT дозволяє створити в транзакції "мітку", або точку збереження. В одній транзакції можна виконувати оператор SAVEPOINT кілька разів, встановлюючи кілька точок збереження.

• ROLLBACK TO <точка збереження>. Цей оператор використовується спільно з представленим вище оператором SAVEPOINT. Транзакцію можна відкотити до зазначеної точки збереження, чи не скасовуючи всі зроблені до неї зміни.

• SET TRANSACTION. Цей оператор дозволяє встановлювати атрибути транзакції, такі як рівень ізольованості і то, чи буде вона використовуватися тільки для читання даних або для читання і запису. Цей оператор також дозволяє прив’язати транзакцію до певного сегмента відкату.

Oracle

1. Неявні транзакції. Транзакція автоматично начитається або з початку сеансу або з моменту закінчення попередньої транзакції.

2. Типи транзакцій – Read Write, Read Only. Транзакція Read Only еквівалентна при читанні рівню ізольованості SERIALIZABLE. Така транзакція бачить тільки зміни, зафіксовані на момент її початку, але в цьому режимі не дозволена вставка, зміна і видалення даних (інші сеанси можуть змінювати дані, але транзакція тільки для читання – немає).

3. Рівні ізольованості – Read Committed, Serializable

4. Механізм багатоверсійності. Основні характеристики

1) Узгодженість з читання для запитів. Запити видають узгоджені результати на момент початку їх виконання. Змінні дані містяться в область сегмента відкату.

2) Неблоковані запити. Запити, які змінюють дані, не блокують запити, які читають дані, і читають запити не блокують змінюють, як це буває в інших СУБД.

5. Оператори управління транзакціями

o SET TRANSACTION

o COMMIT, ROLLBACK

o SAVEPOINT

MS Sql Server

1. Явні транзакції. Кожен оператор виконується в своїй транзакції, якщо він не знаходиться в блоці begin tran – commit (rollback)

2. Наявність вкладених транзакцій. приклад

3. begin tran

4. ............

5. begin tran

6. .................

7. commit (rollback)

8. ................

      commit (rollback)

Підтвердження вкладеної транзакції ні на що не впливає. Відкат вкладеної транзакції відкочується внутрішньою транзакцією.

9. Оператори управління транзакціями

1. SET TRANSACTION

2. BEGIN TRANSACTION

3. COMMIT, ROLLBACK

4. SAVEPOINT

Лекція 8:

Реплікація даних. Види і властивості реплікації.

Однією з основних характеристик сховища даних є модель його несуперечності, в якій визначаються правила, які необхідно дотримуватися, щоб сховище повертало в різних процесах правильні результати. Виділяють наступні моделі несуперечності [1]: сувора, послідовна, причинна, FIFO, слабка, вільна і по елементна. Розглядається реплікативний аспект послідовної, слабкою і FIFO моделей несуперечності. Цей вибір обумовлений тим, що перші дві моделі забезпечують глобальну серіалізацію операцій, а остання – досить легко можна реалізувати і є менш жорсткою, ніж перші дві. В [1] наведено визначення всіх перерахованих вище моделей несуперечності, тут же наводяться визначення тільки розглянутих моделей, необхідні для подальшого викладу.

Послідовна несуперечливість визначається наступним правилом:

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

Несуперечливість FIFO визначається наступним правилом:

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

слабка несуперечливість

Для визначення слабкої несуперечності вводиться поняття змінної синхронізації. Мінлива синхронізації (S) має асоційований з нею набір реплікаційних даних і дозволяє виконувати над собою єдину операцію synchronize (S). В ході виконання цієї операції зміни зроблені процесом в локальній копії даних поширюються на всі інші копії даних, асоційовані зі змінною синхронізації. Також в ході цієї операції локальна копія оновлюється даними з інших копій.

Модель слабкою несуперечності має три властивості:

• Доступ до змінних синхронізації, асоційованими з сховищем даних, здійснюється на умовах послідовності й несуперечності.

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

• З елементами даних не може бути проведена жодна операція до повного завершення всіх операцій зі змінними синхронізації.

Протокол несуперечності являє собою конкретну реалізацію відповідної моделі. Прийнято виділяти такі групи протоколів несуперечності [1]: на базі первинної копії, реплікаційного запису, узгодження кешів.

Протоколи на базі первинної копії, що мають на увазі реплікацію даних

Всі протоколи на базі первинної копії мають на увазі наявність для кожного елемента даних Х, асоційованого з ним первинного елемента даних, який відповідає за координацію операцій записи. В [1] виділяється два протоколи підтримують реплікацію:

Протокол первинного архівування з видаленим записом

Опис протоколу:

Розшифровка позначень:

• W1 – запит на запис

• W2 – Пересилання запрошення на сервер

• W3 – сигнал на оновлення резервних копій

• W4 – підтвердження виконання поновлення

• W5 – підтвердження виконання записи

• R1 – запит на читання

• R2 – відповідь для читання

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

Протокол первинного архівування з локальної записом

Опис протоколу:

Розшифровка позначень:

• W1 – запит на запис

• W2 – переміщення елемента даних х на новий первинний сервер

• W3 – підтвердження завершення запису

• W4 – сигнал на оновлення резервних копій

• W5 – підтвердження оновлення

• R1 – запит на читання

• R2 – відповідь для читання

У протоколі мається на увазі асинхронне оновлення інших копій. Тут також необхідно вживати додаткових заходів, щоб гарантувати оновлення інших реплік, однак проблеми узгодженого читання для вузла, який ініціював оновлення, тут не виникає. Без додаткових заходів протокол реалізує FIFO несуперечливість, реалізувавши повністю впорядковану групову розсилку (за допомогою відміток часу Лампорта) [1], можна отримати реалізацію послідовно й несуперечливо. Оскільки в протоколі допускається переміщення первинної копії то необхідно вирішити завдання пошуку вузла, що містить первинну копію і зміни власника.

Приклад вирішення завдань пошуку і зміни власника первинної копії

У СУБД Oracle існує метод реплікації даних, що запобігає виникненню конфліктів [2,3], і який містить рішення двох розглянутих задач. В [2] він визначається як dynamic ownership with token passing (динамічне володіння з перехідним маркером). У цьому методі мається на увазі наявність декількох реплік табличних даних, розташованих на різних вузлах, на кожному з яких встановлена ​​СУБД Oracle. До реплікаційної таблиці додається два стовпці, перший з яких містить ім’я вузла (owner), який володіє рядком даних, а другий номер версії рядки даних (epoch). Стовпець epoch використовується для запобігання конфліктів упорядкування при асинхронної розсилці змін.

Алгоритм пошуку первинної копії

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

Алгоритм зміни власника первинної копії

Передбачається, що власник був знайдений за допомогою попереднього алгоритму. Рядок, власник якої змінюється, блокується на вузлі поточного власника. На обох вузлах змінюються значення owner і epoch. Owner змінюється на ім’я вузла, який ініціював зміну власника, а epoch збільшується на одиницю. Після цього решти вузлів асинхронно розсилаються нові значення owner і epoch. Такий алгоритм гарантує, що в кожен момент часу тільки один вузол вважає себе власником рядки.

Протоколи реплікаційних записів

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

Активна реплікація

Активна реплікація увазі можливість поновлення довільній репліки з подальшою розсилкою оновлень іншим реплік (за допомогою команд поновлення або самих оновлених даних). Для того щоб за допомогою активної реплікації можна було реалізувати модель послідовної несуперечності, необхідно гарантувати однакову послідовність виконання всіх операцій запису на всіх машинах. Це можна забезпечити за допомогою впорядкованої групового розсилання, побудованої за допомогою відміток часу Лапорта, або за допомогою виділення спеціального вузла, який буде впорядковувати всі операції запису, за рахунок присвоєння їм послідовного унікального ідентифікатора. Останнє рішення, однак, наближає активну реплікацію до протоколів на базі первинної копії. Також можливо треба буде розв’язати проблему реплікованих звернень, сенс якої полягає в наступному: якщо об’єкт А звертається до реплікаційного об’єкту В, який при цьому звертається до об’єкту С, то об’єкт З отримає кілька звернень замість одного.

Протоколи кворуму

Основна ідея, що лежить в основі протоколів кворуму полягає в тому, щоб запитувати дозвіл на проведення операцій читання і запису у кількох серверів, що утворюють кворум. Існують кворум записи і кворум читання. Ці Кворуми треба зібрати перед проведенням відповідних операцій. При цьому з кожною операцією запису одних і тих же даних зіставляється послідовно зростаючий номер версії. Нехай розділяється ресурс має N реплік, тоді кворум читання Nr (кількість реплік, до яких виконується запит на читання) і кворум записи Nw (кількість реплік, в яке здійснюється запис) визначаються з наступних двох умов:

• Nr + Nw> N

• Nw> N / 2

Сенс цих обмежень полягає в наступному: перше обмеження гарантує, що при опитуванні Nr серверів, хоча б один з них містить останню версію запитуваних даних, друге обмеження усуває конфлікт подвійного запису, тобто робить неможливих існування розрізняються копій одних і тих же даних, що мають однакову версію. У граничному випадку, коли Nr = 1 Nw = N, всі операції читання можуть бути здійснені локально, проте операція оновлення повинна бути проведена на всіх репліках.

Зауваження з приводу реалізації вільної несуперечності

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

Завдання отримання нової несуперечливої ​​репліки

Розглядається розподілене сховище даних (РГД), що складаються з N вузлів, кожен з яких містить репліки даних. Стоїть завдання отримання несуперечливої ​​репліки для нового N + 1 вузла.

Існує два різних підходи до вирішення цього завдання:

1. Переклад розподіленого сховища даних в стан, в якому виконання операцій зміни даних заборонено, з подальшим копіюванням всіх необхідних даних в нову репліку

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

Алгоритм, який ілюструє 1–ий підхід

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

Алгоритм отримання глобального стану системи

В [1] наводиться алгоритм отримання глобального стану. Вузол, який ініціює отримання глобального стану системи, виконує локальне копіювання і посилає всім іншим вузлам запит на проведення операції отримання глобального стану. Кожен вузол, отримавши такий запит, робить одне з двох:

1. Якщо запит отримано вперше, то він записує своє локальне стан і пересилає запит всім іншим вузлам. Після цього він починає протоколювати всі вхідні повідомлення від усіх вузлів

2. Інакше він зберігає список всіх повідомлень отриманих від вузла джерела (вузол, від якого йому прийшов запит) за час протоколювання повідомлень і перестає протоколювати повідомлення цього вузла. Після того як будуть отримані повідомлення від усіх вузлів, вузлу, який ініціював отримання глобального стану, надсилається записане локальне стан і всі збережені списки повідомлень.

На підставі алгоритму отримання глобального стану системи можна запропонувати алгоритм отримання нової репліки для РХД, в якому всі зміни виконуються за допомогою розподілених транзакцій, без призупинення виконання операцій зміни.

Алгоритм, який ілюструє 2–ий підхід

Вузол, для якого виходить нова репліка (вузол N), втягується в виконання розподілених транзакцій. Для кожного запиту на проведення розподіленої транзакції він підтверджує виконання своєї частини, реально не виконуючи ніяких дій. Далі він розсилає всім вузлам повідомлення на отримання глобального стану. Кожен вузол, отримавши це повідомлення, виконує ті ж дії, що і в алгоритмі 2. Завершивши формування свій частині глобального стану, кожен з вузлів посилає його вузлу N. Вузол N отримає, таким чином, два повідомлення від кожного з інших вузлів: 1 та після того як вузол збереже своє локальне стан (надсилається при 1–му дії за алгоритмом 2) і 2–е, що містить частину глобального стану (надсилається при 2–му дії за алгоритмом 2). Після отримання 1–ого повідомлення від деякого вузла M, вузол N починає протоколювати всі наступні повідомлення від цього вузла, до тих пір поки не отримає повідомлення 2 від всіх вузлів. Після цього вузол N має в своєму розпорядженні глобальний стан і список повідомлень від кожного з вузлів, які були послані вузлу N, після збереження ними свого локально стану. Цих даних достатньо, щоб отримати нову несуперечливу репліку.

Якщо прийняти додаткові припущення про РХД, наприклад, що всі репліки містять одні й ті ж дані або що всі зміни здійснюються за допомогою розподілених транзакцій, то можна модифікувати алгоритм 3, підвищивши його ефективність за рахунок зменшення кількості повідомлень, що пересилаються. Це є предметом подальшої розробки.

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

Лекція 9:

Внутрішня мова СУБД. Характеристики T–SQL.

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

1. Процедури, що зберігаються, пакети, функції

2. Тригери

3. Безіменні блоки

SQL Server. Процедурне розширення – Transact-SQL (T-SQL). Володіє основними можливостями. До версії 2005 була відсутня обробка винятків.

Основні характеристики T-SQL:

• Повний діапазон типів даних

• Явно визначається структура коду – блоки даних, процедури і т.д.

• Оператори управління потоком команд – умовні, цикли і т.д.

• Обробники винятків

• Тісна інтеграція з SQL – безпосередній виклик команд SQL з процедурного коду