Концепції розподілених баз даних 513
Мал. 29.2. розподілені сервери
В ідеалі клієнти не знають, є система розподіленої чи ні. Вони лише посилають їй запити, а система повертає клієнтам результати цих запитів. Як вона це робить, клієнтів не цікавить. На практиці розподілені бази даних проявляють різну прозорість. В крайньому випадку РБД зберігається на декількох незалежних серверах, а клієнтського додатку доводиться вибирати сервер в залежності від того, яку інформацію потрібно отримати. Це має на увазі, що таблиці, що знаходяться на різних серверах, не мають ніяких внутрішніх зв'язків. Природно, така організація РБД лише зрідка виявляється корисною.
Система управління розподіленими базами даних, або РСУБД, надає клієнтам уніфікований інтерфейс доступу до даних, завдяки якому виникає ілюзія єдиного сервера. Якщо дані знаходяться в разнтх місцях, РСУБД пос1ла-ет запити та оновлення до відповідних сховища. Залежно від того, з яким сховищем ведеться робота, продуктивність системи може виявитися різною, але, по крайней мере, клієнтам не доводиться самим займатися вибором сервера.
Якщо дані реплікуються між декількома серверами, клієнт в загальному випадку може віддати перевагу той чи інший сервер. У подібній схемі всі сервери зберігають одні й ті ж дані. Спеціальний модуль може допомагати клієнтам у виборі серверів, здійснюючи вирівнювання навантаження. РСУБД відповідає за виконання транзакцій в многосерверной середовищі, але в будь-який момент часу два сервера не можуть бути синхронізовані між собою.
У РБД застосовується кілька схем розподілу даних. У разі реплікації кожен сервер зберігає весь обсяг даних. Для цього потрібно, щоб РСУБД дублювала транзакції, дозволяючи всім клієнтам бачити узгоджений образ бази даних. У разі несиметричного поділу даних вибирається рівень сегментації. На найвищому рівні розщепленню піддаються окремі бази даних, але не таблиці. Кожна таблиця цілком знаходиться в якомусь одному місці. На нижчому рівні таблиці розщеплюються по рядках або стовпцях. Наприклад, при горизонтальному розщепленні окремі підмножини записів поміщаються в різні сховища, а при вертикальному розщепленні підмножини формуються на підставі стовпців.
Створити точну копію бази даних MySQL досить просто. Способи резервного копіювання баз даних описувалися в главі 25, Усунення наслідків катастроф. Що стосується відновлення даних, то це можна зробити на будь-якому сервері. Маючи в своєму розпорядженні такими засобами, нескладно реалізувати розподілену базу даних, яка синхронізується через досить великі проміжки часу, наприклад раз в день.
Розглянемо проблему поновлення даних. Якщо оновлення відбуваються відразу на двох серверах, їх потрібно узгоджувати. Щоб не виникали нерозв'язні ситуації, необхідно дозволити вносити зміни тільки на одному сервері. Тоді синхронізація буде полягати в дублюванні вмісту сервера, доступного для запису, на всі інші сервери. Їх корисність залежить від того, наскільки важлива актуальність даних. У багатьох випадках база даних, що містить всі записи, крім тих, які були створені за останні 24 години, вполнепріемлема.
Методика відкладеної синхронізації ідеально підходить дя баз даних, що містять результати нічних звітів. Наприклад, Web-вузол, що надає доступ до може реєструвати назви запитуваних пісень і складати рейтинги популярності. Раз в день всі сервери посилають свої журнальні головного сервера, який коригує рейтинги згідно з новою статистикою. Схема такої бази даних приведена в лістингу
Лістинг 29.1. ISiXBMiijajfn / ieiViw
/ * Каталог МРЗ-файлів. * / CREATE TABLE song (
ID INT NOT NULL AUTO INCREMENT,
Name CHAR (4 0) NOT NULL,
Artist CHAR (16) NOT NULL,
Filename CHAR (80) NOT NULL,
/ * Журнал запитуваних файлів, * / CREATE TABLE log (
Server TINYINT UNSIGNED NOT NULL,
Song INT NOT NULL,
DownloadTime DATETIME NOT NULL
Кожен сервер зберігає інформацію про доступні піснях в таблиці song. У таблицю log заноситься запис щоразу, коли хтось завантажує черговий У цій таблиці немає первинного ключа, так як в звичайному режимі вона використовується лише для вставкізапісей. Наявність індексу тільки сповільнить роботу з таблицею.
Раз в день таблиці log всіх серверів об'єднуються за наступним сценарієм. Один з серверів припиняє обслуговувати запити Web-додатків. Решта сервери створюють копії таблиці log, витягують з них останні записи і посилають
їх сервера, що генерує звіт. На час цієї процедури кожен сервер повинен заблокувати свою таблицю log. Щоб занадто багато призначених для користувача запитів не виявилося заблоковано, процедуру бажано виконувати в період мінімальної актівностісервера.
CREATE INDEX song ON log (Song);
/ * Визначення рейтингу всіх пісень. * / DROP TABLE IF EXISTS popular alltime; CREATE TABLE popular alItime (
Rank INT NOT NULL, Song INT NOT NULL, Hits INT NOT NULL
INSERT INTO popular alltime
ALTER TABLE popular alItime ADD PRIMARY KEY (Rank);
/ * Визначення рейтингу пісень за останні 24 години. * / DROP TABLE IF EXISTS popular last24; CREATE TABLE popular last24 (
Rank INT NOT NULL, Song INT NOT NULL,
Hits INT NOT NULL
INSERT INTO popular last24
SELECT (@id: = @ id + l), Song, COUNT (*) FROM log
WHERE DownloadTime> DATE SUB (NOW (), INTERVAL 2 4 HOUR)
ORDER BY 3 DESC; ALTER TABLE popular last24 ADD PRIMARY KEY (Rank);
/ * Видалення Kca. * / DROP INDEX song ON log;