|
|||||||
АвтоАвтоматизацияАрхитектураАстрономияАудитБиологияБухгалтерияВоенное делоГенетикаГеографияГеологияГосударствоДомДругоеЖурналистика и СМИИзобретательствоИностранные языкиИнформатикаИскусствоИсторияКомпьютерыКулинарияКультураЛексикологияЛитератураЛогикаМаркетингМатематикаМашиностроениеМедицинаМенеджментМеталлы и СваркаМеханикаМузыкаНаселениеОбразованиеОхрана безопасности жизниОхрана ТрудаПедагогикаПолитикаПравоПриборостроениеПрограммированиеПроизводствоПромышленностьПсихологияРадиоРегилияСвязьСоциологияСпортСтандартизацияСтроительствоТехнологииТорговляТуризмФизикаФизиологияФилософияФинансыХимияХозяйствоЦеннообразованиеЧерчениеЭкологияЭконометрикаЭкономикаЭлектроникаЮриспунденкция |
СИСТЕМИ УПРАВЛІННЯ БАЗАМИ ДАНИХДля взаємодії користувача з БД використовуються| системи управління базами даних (СУБД), які забезпечують: - набір засобів для підтримки таблиць і співвідношень між ними; - розвинений призначений для користувача інтерфейс, що дозволяє вводити і модифікувати інформацію, здійснювати пошук і представляти результати; - засоби програмування високого рівня, що дозволяють створювати власні застосування. СУБД структури "сервер-клієнт" Побудова розподілених систем має важливе значення, особливо в умовах несистемного оснащення підприємства комп'ютерною технікою, коли багато вже, як правило, працюють (чи їм необхідно працювати) з системами, що складаються з безлічі комп'ютерів різного типу (серверів, міні-комп'ютерів, великих машин). Централізоване зберігання даних і доступ до центральної БД в умовах географічно розподіленої системи призводять до необхідності встановлення з'єднань між центральним сервером, що зберігає дані, і комп'ютерами-клієнтами. Більшість комп'ютерів-клієнтів відокремлена від центрального сервера повільними і недостатньо надійними лініями зв'язку, і робота в режимі видаленого клієнта стає майже неможливою. Цим можна пояснити існуючу ситуацію, коли у вузлах розподіленої системи функціонують групи автоматизованих робочих місць (АРМ), абсолютно не пов'язані один з одним. Змістовна сторона завдання зазвичай вимагає обміну даними між групами АРМ, оскільки зміни в які-небудь дані можуть вноситися в одній групі, а використовуватися вони можуть в іншій. У сучасній технології АРМ об'єднані в локальну мережу. Арм-клієнт видає запити на вибірку і оновлення даних, а СУБД виконує їх. Запити клієнта відповідно до вимог завдання згруповані в логічні одиниці роботи (транзакції). Якщо усі операції з базою даних, транзакції, що містяться усередині, виконані вдало, транзакція в цілому також виконується успішно (фіксується). Якщо хоч би одна з операцій з БД усередині транзакції проведена невдало, то усі зміни у БД, що сталися до цього моменту з транзакції, відміняються (відбувається відкат транзакції). Таке функціонування забезпечує логічну цілісність інформації у базі даних. При розподіленій обробці зміни, що проводяться застосуванням-клієнтом, можуть зачіпати більш ніж один сервер СУБД. Для підтримки цілісності і в цьому випадку потрібне застосування того або іншого транзакційного механізму, що реалізовується системними засобами, а не прикладною програмою. Але основний недолік систем, побудованих на розподілених транзакціях, - високі вимоги до надійності і пропускної спроможності ліній зв'язку. Тому альтернативою розподіленим транзакціям вважається реплікація (дублювання) даних. У таких системах одна і та ж інформація зберігається в різних вузлах. Узгодження значень і поширення даних по вузлах здійснюється автоматично. Транзакція може вносити зміни (тобто додавати, видаляти і змінювати записи) в одну або декілька таблиць бази даних. Вибрані для реплікації таблиці спеціальним чином позначаються. Для кожної такої таблиці або групи її рядків, вибраної по заданій умові, визначається один вузол (СУБД), в якому ці таблиці є первинними. Це той вузол, в якому відбувається найбільш активне оновлення даних. Реплікаційному серверу, обслуговуючому БД з первинними даними, задається опис тиражування (replication definition). У цьому описі, приміром, можуть бути задані інтервали значень первинного ключа таблиці або яка-небудь інша умова, при виконанні якого змінені дані тиражуватимуться з цього вузла до передплатників. Якщо умова не задана, то опис тиражування діє для усіх записів таблиці. Можливість тиражування групи записів таблиці означає, зокрема, що частина записів може бути первинними даними в якому- те одному вузлі, а ще частина - в інших вузлах. У одній базі даних можуть міститися як первинні дані, так і дані-копії. Застосування-клієнт, працююче зі своєю СУБД, може вносити зміни безпосередньо (операторами INSERT, DELETE, UPDATE) тільки в первинні дані. Для зміни копії даних призначений механізм асинхронного виклику процедур. Для роботи цього механізму в декількох базах даних створюються процедури з однаковим ім'ям і параметрами, але, можливо, з різним текстом. У одній базі даних процедура позначається як призначена до реплікації. Виклик цієї процедури разом зі значеннями параметрів через журнал і механізм реплікації передається до вузлів-передплатників, і в їх базах даних викликається однойменна процедура з тими ж значеннями параметрів. СУБД, що зберігає вторинні дані, може бути будь-якою з ряду доступних через шлюз. СУБД, що зберігає первинні дані, вимагає наявності менеджера журналу транзакцій (Log Transfer Manager - LTM). Зараз розроблені LTM для Sybase SQL Server і Oracle; на черзі інші СУБД. Інтерфейс LTM є відкритим, і незабаром, можливо, подібні модулі будуть створені для нестандартних джерел даних. Слід підкреслити, що реплікаційний сервер тиражує транзакції, а не окремі зміни у базі даних. Метод тиражування транзакцій гарантує цілісність усередині транзакції і, як наслідок, неможливість порушення посилальної цілісності. Схема оновлення первинних даних і копій даних унеможливлює виникнення конфліктів; останні можуть бути викликані тільки неправильним проектуванням системи або збоєм. Розподілена обробка даних грунтується на синхронних або асинхронних механізмах обробки розподілених транзакцій. Ці механізми можуть використовуватися і спільно. Оскільки кожен механізм має свої сильні і слабкі сторони, вибір його залежить від вимог конкретної підзадачі. Історично першим з'явився метод синхронного внесення змін до декількох БД, званий двофазною фіксацією (2PC, two-phase commit). Цей механізм реалізований зараз практично усіма виробниками СУБД. Суть методу двофазної фіксації полягає в тому, що при завершенні транзакції сервери БД, що беруть участь в ній, отримують команду "Приготуватися до фіксації транзакції". Після отримання підтверджень від усіх серверів транзакція фіксується на кожному| з них. Таким чином, у будь-який момент часу забезпечується цілісність даних в розподіленій системі. Платою за це є вимога доступності усіх серверів, що беруть участь, і ліній зв'язку під час проведення транзакції, а також неможливість роботи застосувань-клієнтів при недоступності, наприклад, видаленого сервера. Крім того, потрібна висока швидкодія ліній зв'язку для забезпечення прийнятного часу реакції у застосування-клієнта. У розподіленій системі ідеальним був би стан, коли кожна програма-клієнт звертається тільки до тих серверів, які знаходяться в межах її локальної мережі, а передача даних і забезпечення цілісності здійснюються системними засобами і не вимагають спеціальних дій з боку прикладної програми. Такий розподіл функцій можливий і на практиці реалізується за допомогою механізму асинхронного тиражування транзакцій. Механізм асинхронного тиражування транзакцій (реплікації) гарантує доставку змінених даних на вторинні сервери безпосередньо після завершення транзакції, якщо сервер доступний, або ж негайно після підключення сервера до мережі. Такий спосіб припускає зберігання дублюючої інформації в різних вузлах мережі і в порівнянні з іншими підходами до реплікації істотно розвантажує трафік мережі, мінімізує час відгуку системи, а також дозволяє оптимізувати навантаження на сервери. Залежно від умов, специфікованих розробником, реплікація може проводитися або відразу після настання деякої події (скажімо, модифікації рядка таблиці), або через заздалегідь задані інтервали часу (кожну хвилину, кожну годину і так далі), або в певний момент часу (наприклад, вночі, коли завантаження і вартість ліній зв'язку мінімальне). Якщо вузол, в який виконується реплікація, в даний момент недоступний, інформація про це зберігається в зухвалому вузлі, і реплікація здійснюється після відновлення зв'язку. Більше того, гарантується збереження заданого зухвалим вузлом порядку її виконання. Потрібно відмітити, що асинхронна реплікація не робить лінії зв'язку надійнішими або швидкіснішими. Вона лише перекладає завдання трансляції даних і забезпечення їх цілісності "з плечей" прикладної програми і користувача на системний рівень. Асинхронна реплікація, на відміну від 2РС|, не гарантує повної синхронності інформації на усіх серверах у будь-який момент часу. Синхронізація відбувається через деякий, зазвичай невеликий інтервал часу, величина якого визначається швидкодією відповідного каналу зв'язку. Для більшості завдань короткочасна наявність застарілих даних у видалених вузлах не критична і цілком допустимо. В той же час асинхронна реплікація транзакцій принципово забезпечує цілісність інформації, оскільки об'єктом обміну даними тут є логічна одиниця роботи - транзакція, а не просто дані зі змінених таблиць. Усі сучасні сервери БД використовують блокування, щоб забезпечити паралелізм в розрахованому на багато користувачів середовищі. Може йтися про блокування на рівні сторінок, рядків або таблиць, причому характер використовуваного блокування найчастіше визначається у момент опису таблиць. Дійсно, користувачі і розробники корпоративних інформаційних систем все| більше уваги приділяють ефективності базової СУБД. Зокрема, йдеться про способи реалізації систем блокування, які значною мірою впливають на якість виконання проектів. Система блокувань синхронізує доступ користувачів до бази даних, а в ідеалі гарантує несуперечність даних і істинність результатів виконання запитів. Тоді як один користувач блокує область бази даних, наприклад, для перегляду і·можливої модифікації даних, останні мають бути захищені від дії з боку інших користувачів, що можливо намагаються вносити зміни в тій же області даних. Завдання масштабування рано чи пізно встає у будь-якій організації, і це цілком з'ясовно. Ніхто і ніколи не купує апаратуру про запас, з великими резервами по обчислювальній потужності. В той же час об'єми даних, що зберігаються, і кількість реально працюючих застосувань мають тенденцію до неухильного збільшення. Тому краще всього спочатку зупинити свій вибір на такій апаратній конфігурації, яка надалі буде легко нарощуватися і розвиватися. Нині цій вимозі найбільшою мірою відповідають комп'ютери з симетричною багатопроцесорною (SMP) або масивно-паралельною (МРР) архітектурою, на яких при збільшенні кількості процесорів забезпечується практично лінійний ріст продуктивності. Обробка декількох запитів, вкладених циклів усередині одного запиту, завантаження і сортування даних, створення індексів і так далі - усе це виконується паралельно на різних процесорах. Більше того, одночасно реалізується ефективне динамічне балансування завантаження системних ресурсів (процесорів, оперативної і дискової пам'яті). Виртуальным-процессором (ВП) називається процес сервера баз даних. ВП можна порівняти з операційною системою - потік по відношенню до нього виступає як процес, подібно до того як сам ВП є процесом з точки зору операційної системи. На відміну від операційної системи, яка повинна забезпечувати виконання довільних процесів, ВП підрозділяються на декілька класів, кожен з яких спроектований для найбільш оптимального виконання завдань певного виду. Наприклад, ВП CPU працюють на потоки обслуговування клієнтів, реалізовуючу оптимізацію і логіку виконання запитів; ВП АIO виконують операції асинхронного обміну з диском; ВП TLI контролюють мережеву взаємодію. Сервер підтримує черги потоків для кожного класу ВП. Як тільки ВП звільняється, він вибирає з черги наступний потік, тим самим досягається рівномірне завантаження. Перемикання ж ВП з одного потоку на інший виконується значно швидше, ніж перемикання ОС з одного процесу на інший. Крім того, багатопотокова архітектура сприяє раціональнішому використанню ресурсів ОС, оскільки потоки розділяють ресурси ВП, на якому вони виконуються, - пам'ять, комунікаційні порти, файли. Початкове число ВП кожного класу задається в конфігураційному файлі. Але якщо потреби в якихось видах збільшуються, то інструменти адміністрування дозволяють динамічно, не зупиняючи сервер, запустити додаткові ВП. Наприклад, якщо росте черга потоків до ВП CPU, то можна збільшити їх число. Так само можливе додавання віртуальних процесорів обміну з дисками, мережевих процесорів. Розподіл даних між віртуальними процесорами і потоками сервера реалізований на основі пам'яті, що розділяється, - механізму, що забезпечується операційною системою. Розподіл даних дозволяє: - понизити загальне споживання пам'яті, оскільки процесам, що беруть участь в розподілі, тобто віртуальним процесорам, немає нужди підтримувати свої копії інформації, що знаходиться в пам'яті, що розділяється; - скоротити число обмінів з дисками, тому що буфери введення-виводу скидаються на диск не для кожного процесу окремо, а утворюють один загальний для усього сервера баз даних пул; віртуальний процесор частенько уникає виконання операцій введення з диска, оскільки потрібна таблиця вже прочитана іншим процесором; - організувати швидку взаємодію між процесами; через пам'ять, що розділяється, зокрема, обмінюються даними потоки, що беруть участь в паралельній обробці складного запиту; пам'ять, що розділяється, використовується також для організації взаємодії між локальним клієнтом і сервером. Поиск по сайту: |
Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Студалл.Орг (0.004 сек.) |