Первая страница
Наша команда
Контакты
О нас

    Головна сторінка



Архітектура “клієнт-сервер”. Сервер БД

Архітектура “клієнт-сервер”. Сервер БД




Сторінка18/20
Дата конвертації10.03.2017
Розмір2.36 Mb.
ТипПротокол
1   ...   12   13   14   15   16   17   18   19   20

13. Архітектура “клієнт-сервер”. Сервер БД




13.1. Загальні поняття

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

Раніше ми уже відзначали, що, взагалі кажучи, локальну БД, наприклад, створену в Access, можна установити на мережному сервері і дозволити користувачам працювати з цією БД через мережу. Усе буде добре доти, поки з БД буде працювати невелике число користувачів - клієнтів. Якщо число одночасно працюючих користувачів зросте (наприклад, 10 і більш), то відразу ж виявляться недоліки такої архітектури БД (її називають архітектурою «файловий сервер») – різко знижується продуктивність інформаційної системи, відбувається уповільнення роботи системи, зростає час її реакції. При значному зростанні числа клієнтів (100 і більше) інформаційна система з такою архітектурою взагалі стає непрацездатною. Основні причини цих недоліків очевидні і полягають у наступному:


  • По мережі передається великий обсяг “зайвої” інформації, тому що обмін даними відбувається шляхом пересилання файлів, хоча клієнту може бути потрібна тільки невелика частина інформації з файлу. При збільшенні числа клієнтів швидко настає перевантаження каналів зв'язку;

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

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

Тому розроблювачі СУБД, призначених для роботи великої кількості користувачів, неминуче прийшли до необхідності побудови нової архітектури БД, у якій би вирішувалися зазначені вище проблеми. Ця нова архітектура була названа архітектурою “клієнт-сервер”. Ця архітектура реалізована в сучасних версіях промислових СУБД, наприклад, таких, як MS SQL Server, Oracle, Informix, InterBase і багатьох інших.

Найбільш характерні ознаки (особливості) архітектури “клієнт-сервер” наступні:



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

  • Основна обробка даних перенесена на комп'ютер-сервер, на якому встановлена БД. Завдяки цьому зменшилося до мінімуму кількість помилок і протиріч, внесених у дані. Крім того, з'явилася можливість реалізувати більш стійкий захист від несанкціонованого доступу до даних, що є винятково важливим для інформаційних систем з великою кількістю користувачів;

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

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

Нехай, наприклад, ви один із клієнтів, що працюють із загальної БД, і в деякий момент часу ви прочитали який-небудь запис і робите його редагування. У цей же час інший клієнт також звернувся до цього ж запису і намагається змінити в ньому дані чи взагалі видаляє його. Що і як буде відбуватися після того, як ви спробуєте зберегти зроблені зміни? Ясно, що виникає конфліктна ситуація! Розв’язання подібних конфліктів здійснюється на основі спільного застосування механізмів транзакцій і блокувань.



13.2. Поняття транзакції



Транзакцією називають групу логічно зв'язаних послідовно виконуваних операцій (операторів SQL), таких, що тільки успішне виконання всіх операцій приводить до реальних змін даних у БД, які є результатом виконання операцій, включеним у дану транзакцію. Якщо хоча б одна з операцій не буде успішно виконана (через збій чи з якої-небудь іншої причини), то всі зміни, що до цього часу вже були зроблені, скасовуються. Скасування зроблених змін називають відкатом транзакції (RollBack).

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

Класичним прикладом транзакції, який звичайно приводять у літературі по БД, є бухгалтерська проводка. Нехай, наприклад, у банку є рахунки клієнтів А и Б, і потрібно деяку суму S зняти з рахунка А и перевести її на рахунок Б. Таким чином, у даному прикладі транзакція складається з двох операцій:


  1. зняти суму S з рахунка А;

  2. помістити суму S на рахунок Б.

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

При невдалому виконанні транзакції (при її відкаті), вона може бути виконана повторно.


13.3. Проблеми доступу до даних багатьох користувачів

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



  1. «читання незафіксованих змін»;

  2. «неповторювальне читання»;

  3. «незафіксовані (чи фантомні) записи»;

  4. «загублені зміни», і ін.

Суть цих проблем коротко полягає в наступному:

«Читання незафіксованих змін». Нехай, наприклад, паралельно (одночасно) виконуються дві транзакції: Т1 і Т2. Транзакція Т1 зробила зміни даних у запису А, але ще їх не зафіксувала (транзакція ще не завершилася). Транзакція Т2 прочитала зміни даних у запису А и продовжує виконуватися далі. Якщо тепер з якої-небудь причини відбудеться скасування транзакції Т1, то в цьому випадку транзакція Т2 буде працювати з невірними даними.

«Неповторювальне читання». Транзакція Т1 прочитала запис А і продовжує з нею працювати. Транзакція Т2 до завершення Т1 змінила дані в записі А и зафіксувала їх у БД. При повторному читанні транзакцією Т1 даних вони можуть відрізнятися від колишніх і результати виконання транзакції Т1 можуть виявитися помилковими.

«Незафіксовані (фантомні) записи». Нехай транзакція Т1 створила новий запис А, але ще не зафіксувала його в БД. У цей час транзакція Т2 прочитала запис А и продовжує з ним працювати. Якщо транзакція Т1 буде скасована, то виявиться, що транзакція Т2 працює з неіснуючим записом.

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



«Загублені зміни». Транзакція Т1 зробила зміни в запису А, але ще їх не зафіксувала. У цей час транзакція Т2 ще раз змінила дані в А и успішно завершилася. Зміни, зроблені транзакцією Т1, будуть загублені.

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

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

13.3. Блокування


Блокування, як уже відзначалося, є основним засобом розв’язання конфліктів.

При виникненні конфлікту у транзакції є два вибори – або негайно збудити виключення (помилку), або почекати якийсь час і після цього знову спробувати виконати потрібну дію. У зв'язку з цим введене поняття режиму блокування, що може мати два значення: wait (чекати), і nowait (не чекати).

Конфлікти, про які мова йде, можуть виникати як при читанні даних, так і при введенні чи редагуванні даних.

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



13.3.1. Конфлікт при вставці запису


Нехай транзакція Т1 додає запис у таблицю, але ще не підтвердила зміни. У цей час транзакція Т2 так само намагається вставити запис з таким же значенням первинного ключа (Рис. 13.1).
Таблиця


0

4

1

Т
2
1


3





4

Т2


Рис. 13.1. Конфлікт при вставці запису

У залежності від режиму блокування транзакції Т2 можливі такі варіанти:



  1. якщо Т2 запущена в режимі wait, то вона чекає завершення Т1. Якщо Т1 завершується підтвердженням, то для Т2 генерується виключення (помилка). Якщо Т1 не підтверджується (зроблений відкат Т1), то Т2 успішно завершується;

  2. якщо Т2 запущена в режимі nowait, то для Т2 відразу генерується помилка.



13.3.2. Конфлікт при редагуванні запису

Транзакція Т1 змінила дні у якому-небудь запису, але ще не підтвердила зміни. Транзакція Т2 намагається редагувати чи видалити цей самий запис. У залежності від режиму блокування для Т2 можливі такі варіанти:



  1. якщо Т2 запущена в режимі wait, то вона буде чекати, поки Т1 не підтвердиться чи скасується. Якщо Т1 підтвердилася, то для Т2 генерується помилка. Якщо Т1 не підтвердилася, то Т2 успішно завершується;

  2. якщо Т2 запущена в режимі nowait, то відразу генерується помилка.



13.3.3. Взаємне блокування транзакцій

Нехай запущені дві трансакції: Т1 і Т2, і є два запису: А и Б. Припустимо, виконується така послідовність дій:



  1. Транзакція Т1 заблокувала запис А і успішно з ним працює;

  2. Транзакція Т2 заблокувала запис Б и також успішно з ним працює;

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

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

У результаті виникла сумна ситуація: обидві транзакції не мають ніякої можливості продовжити своє виконання, тому що “намертво” заблокували одна одну.

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


13.4. Рівні ізоляції транзакцій

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

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

Існують чотири рівні ізоляції транзакцій:



DIRTY READ. Транзакція з таким рівнем ізоляції може читати непідтверджені дані в інших транзакціях. Цей рівень називають “брудне читання”. У InterBase такий рівень ізоляції транзакцій заборонений.

REАD COMMITED. Транзакція, запущена з таким рівнем, може читати зміни, зафіксовані в паралельно виконуваних транзакціях. Цей рівень гарантує, що ми не зможемо прочитати непідтверджені змінені дані в інших транзакціях, але підтверджені дані прочитати можна.

SNAPSHOT. Цей рівень ізоляції використовується для створення “моментального знімка” БД у момент запуску транзакції. Всі операції читання даних у цієї транзакції будуть “бачити” БД у стані, у якому вона була в момент запуску транзакції. Усі зміни в інших транзакціях (підтверджені і непідтверджені) не видимі для цієї транзакції.

SNAPSHOT TABLE STABILITY. Цей рівень ізоляції аналогічний рівню SNAPSHOT, але додатково блокує таблицю на запис. Ідея тут проста – якщо транзакція з таким рівнем ізоляції робить зміни в якій-небудь таблиці, то транзакції з рівнями REАD COMMITTED і SNAPSHOT можуть тільки читати цю таблицю, а транзакції з таким же рівнем ізоляції, тобто SNAPSHOT TABLE STABILITY, не можуть і читати її дані.

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




Каталог: uploads
uploads -> Ііі міжнародний економічний саміт «Україна І світ. Новий діалог»
uploads -> Інформація про роботодавців Одеси (перелік відсортований за розміром штату співробітників у місті) Компанія Проекти і технології
uploads -> Методичні вказівки до лабораторних робіт з дисципліни: " Програмування мобільних пристроїв " для студентів напряму підготовки
uploads -> Оголошення про тендер (rfq) Номер rfq: ucbi-062-с дата оголошення: 13 листопада 2015 Кінцевий термін подання: 20 листопада 2015 Опис: Постачання it обладнання для зони митного оформлення в Одесі
uploads -> О. К. Юдін, директор Інституту комп’ютерних інформаційних технологій, д-р техн наук, професор
1   ...   12   13   14   15   16   17   18   19   20



  • 13.2. Поняття транзакції
  • 13.3. Проблеми доступу до даних багатьох користувачів
  • 13.3. Блокування
  • 13.3.1. Конфлікт при вставці запису
  • 13.3.2. Конфлікт при редагуванні запису
  • 13.3.3. Взаємне блокування транзакцій
  • 13.4. Рівні ізоляції транзакцій