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

Анотація наукової статті з комп'ютерних та інформаційних наук, автор наукової роботи - Борівський Дмитро Петрович, Вагнер Дмитро Петрович


Область наук:
  • Комп'ютер та інформатика
  • Рік видавництва: 2008
    Журнал: Доповіді Томського державного університету систем управління і радіоелектроніки

    Наукова стаття на тему 'Координатор розподілених дій для БД в багатокористувацької середовищі'

    Текст наукової роботи на тему «Координатор розподілених дій для БД в багатокористувацької середовищі»

    ?УДК 004.416.6

    І.Г. Борівський, Д.П. Вагнер

    Координатор розподілених дій для БД в середовищі з багатьма користувачами

    Розглянуто проблему координації розподілених дій в багатокористувацької середовищі на прикладі настільних баз даних, використання яких в деяких випадках призводить до спотворення і втрати інформації. Досліджено стандартні механізми вирішення проблеми за допомогою інструменту блокувань даних; на основі виявлених недоліків запропоновано рішення - розробка координатора розподілених транзакцій з використанням технології обміну даними Windows Socket.

    Необхідність координації дій в інформаційних системах найбільш чітко окреслилася з появою багатокористувацьких і багатопрограмних середовищ. В даний час проблема координації розподілених дій для ряду користувачів не є проблемою як такої, оскільки в більшості систем вона вже вирішена розробниками. Найбільш яскравий приклад - бази даних: в цьому випадку мова йде про координацію транзакцій, паралельне виконання яких не повинно призводити до спотворення або втрати даних. У більшості сучасних СУБД відповідальність за проведення транзакцій покладено на координатор розподілених транзакцій. Так, наприклад, при роботі MS SQL Server використовується системна служба Windows - Distributed Transaction Coordinator (DTC), яка відповідає за координацію транзакцій, що відносяться не тільки безпосередньо до СУБД, але також і до черг повідомлень, файловим системам і іншим ресурсам [1]. Однак існують системи, в яких рішення проблеми координації дій не було закладено спочатку по ряду причин: використання систем в * домашніх умовах », невелика ймовірність виникнення конфліктних ситуацій, невисока вартість програмного забезпечення, наслідком чого була обмеженість функціональних можливостей і т.д. При використанні таких систем різке зростання користувачів і збільшення обсягу оброблюваних даних найчастіше можуть призводити до виникнення які раніше не з'являлися проблем з перекручуванням і втратою даних. В якості практичного прикладу авторами була розглянута проблема координації розподілених транзакцій для настільних баз даних (Microsoft Access), при використанні яких порушення при виконанні запитів на обробку даних стають критичними і не можуть бути вирішені стандартними засобами.

    Microsoft Access (MS Access) в даний час є однією з найбільш популярних СУБД, використовуваних для розробки настільних баз даних. Це обумовлено декількома факторами: програма надає не тільки широкий набір засобів створення, пошуку, управління і обробки даних, але також включає зручні механізми візуального конструювання та налаштування інтерфейсу. Крім того, важливим фактором, що обумовлює широке поширення MS Access, є повна інтеграція з іншими додатками Microsoft Office (MS Word, MS Excel і т.д.), а також використання Visual Basic for Applications (VBA) при вирішенні більш складних завдань автоматизації або створення інтерфейсу користувача [2].

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

    Описані проблеми були виявлені в результаті обчислювального експерименту ,: в якому кілька робочих потоків здійснювали одночасну вставку записів в кількості від 25 до 100 в таблицю MS Access, що має поле з унікальним ключем. Експеримент показав, що вже в разі двох робочих потоків втрати записів в зв'язку з повторенням у ні-

    І.Г. Борівський, Д.П. Вагнер. Координатор розподілених дій для БД ..

    75

    кального ключа при вставці досягають 32-40%, при наявності трьох - уже 39-50%, а при чотирьох потоках - 58-65% [3].

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

    Процесор баз даних забезпечує три рівні блокувань:

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

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

    3) блокування сторінки - самим нижнім рівнем блокування є рівень сторінки. Процесор Microsoft Jet автоматично встановлює блокування сторінки, яка далі не може контролюватися програмою. Сторінка даних може містити кілька записів, розмір яких дорівнює 26 Кбайт. Блокування сторінки призводить до блокування всіх записів, які перебувають на цій сторінці [4].

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

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

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

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

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

    Алгоритм роботи запропонованої схеми реалізується на наступних принципах:

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

    (Додаток-сервер), а на клієнтських машинах - «клієнтський компонент» (додаток-клієнт);

    • сервер здійснює постійну роботу і в будь-який момент часу знаходиться в одному з двох станів: «вільний» чи «зайнятий»;

    • сервер дає змогу отримувати доступ до необхідних даних одному клієнту;

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

    • якщо при зверненні до сервера клієнт отримує повідомлення про те, що сервер «зайнятий», клієнт стає в режим «очікування» і отримує доступ до сервера тільки після закінчення роботи з ним попереднього клієнта;

    • нестійка робота будь-якого з клієнтів, наприклад збій, зависання, відключення живлення, не впливає на роботу сервера або інших клієнтів [3].

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

    Схема взаємодії сервера і клієнтів

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

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

    Розвитком ідеї використання файлів служить технологія на основі іменованих каналів (Named Pipes).

    Іменовані канали - це об'єкти ядра операційної системи, що є засобом межпроцессной комунікації між сервером каналу і одним або декількома клієнтами каналу. Сервером каналу називається процес, який створює іменований канал. Клієнтом каналу називається процес, що підключається до створеного іменовані канали. Базовим об'єктом для реалізації іменованих каналів служить об'єкт «файл», тому для здійснення та отримання повідомлень по іменованих каналах використовуються ті ж самі функції Window API (Application Program Interface), що і при роботі з файлами (ReadFile, WriteFile).

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

    Іменовані канали відрізняються наступними можливостями: гарантована доставка повідомлень, асинхронний ввід / вивід, комунікація між процесами на різних комп'ютерах в локальній обчислювальній мережі і відносна простота використання [5],

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

    Windows Socket (сокети) - механізм, що дозволяє незалежно від протоколу передачі даних організувати мережевий інтерфейс між двома комп'ютерами в мережі. Зокрема, сокети можуть працювати як з протоколом TCP, так і з протоколом UDP. Звернення до сокету відбувається по IP-адресою машини, на якій був створений Windows Socket, і номером порту.

    Розрізняють сокети з встановленням з'єднання, тобто адреси сокетів відправника і одержувача з'ясовуються заздалегідь, до передачі повідомлень між ними - встановлюється так званий віртуальний канал між двома машинами в мережі, і без встановлення з'єднання - адреси сокетів відправника і одержувача передаються з кожним пересилаються повідомленням. Для кожного сокета призначається тип, за допомогою якого визначається спосіб передачі даних між двома сокетами. Тип Windows Socket з встановленням з'єднання - це віртуальний канал, а тип Windows Socket без встановлення з'єднання - дейтаграмма. У першому випадку використовується протокол TCP, що відрізняється високим ступенем надійності при передачі даних. При цьому з'являється можливість миттєво відстежувати стан каналу (з'єднання по сокету), що в свою чергу дозволить коректно розмежувати доступ до даних. У другому випадку використовується протокол UDP, при цьому надійність передачі даних виявляється істотно нижче, проте до переваг даного способу відноситься більш висока швидкість роботи,

    Сокети з встановленням з'єднання взаємодіють за схемою клієнт / сервер: серверному покет призначається загальновідомий адресу і він безперервно очікує прибуття клієнтських повідомлень. Клієнтський процес посилає повідомлення на сервер по оголошеному адресою серверного сокета [5].

    Одним з переваг сокетов є і той факт, що більшість сучасних операційних систем (Windows, Unix, Linux) підтримує сокети на рівні вбудованих в ядро ​​бібліотек.

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

    Також варто відзначити, що використання координатора розподілених дій в мережі, що має 35 активних підключень при доступі до бази даних обсягом понад 0,5 Гбайт, повністю виключило невизначеність операцій. Наприклад, вставка даних користувачами в таблицю, що має поле з унікальним ключем, більше не призводить до проблеми його дублювання. Крім того, при виникненні ситуації збою будь-якого з клієнтів надійність і ефективність всієї системи залишаються незмінно високими. До недоліків запропонованої системи можна віднести те, що існує незначна часова в роботі сервера, яка, втім, для користувача є практично непомітною.

    література

    1. Microsoft Corporation. Адміністрування Microsoft® SQL Server 7.0. Навчальний курс: офіційне посібник Microsoft для самостійної підготовки: пров. з англ. - М.: Російська Редакція, 2000. - 512 с.

    2. Microsoft Corporation Microsoft Access 2000. Крок за кроком: практ. посібник: пер. з англ. - М.: ЕКОМ, 2002. - 352 с.

    3. Вагнер Д.П. Координатор розподілених транзакцій для настільних баз даних / Д.П. Вагнер // Наукова сесія ТУСУР - 2007: Додати матеріали доповідей Всеросійської науково-технічної конференції студентів, аспірантів і молодих вчених, Томськ, 3-7 травня 2007 - Томськ: В-Спектр, 2007. - Ч. 1. - 346 с. - С. 342-345.

    4. Вілларіал Б. Програмування Access 2002 у прикладах: пров. з англ. / Б. Виллари-ал. - М.: КУДИЦ-ОБРАЗ, 2003. - 496 с.

    5. Соломон Д. Внутрішній устрій Microsoft Windows 2000. Майстер-клас / Д. Соломон, М. Руссинович; пер. з англ. - СПб. : Пітер; Російська Редакція, 2004. - 746 с.

    Борівський Ігор Георгійович

    Проф., Д-р фіз.-мат. наук, зав. каф. економічної математики, інформатики та статистики ТУСУРа Тел .: 41 49 878.

    Вагнер Дмитро Петрович

    Аспірант кафедри. економічної математики, інформатики та статистики ТУСУРа Ел. пошта: Ця електронна адреса захищена від спам-ботів. Вам потрібно увімкнути JavaScript, щоб побачити її., Ця електронна адреса захищена від спам-ботів. Вам потрібно увімкнути JavaScript, щоб побачити її.

    I.G. Borovskoi, D.P. Vagner

    Database coordinator of the distributed actions in the multiuser environment

    In the article the problem of coordination of the distributed actions in the multiuser environment on an example of desktop databases which use in some cases results in distortion and loss of the information is cdnsidered. Standard mechanisms of the decision of a problem with the help of the tool of blocking of the data are investigated, on the basis of the revealed lacks the decision - development of the coordinator of the distributed transactions with use of technology of data exchange Windows Socket is offered.


    Завантажити оригінал статті:

    Завантажити