Опубликован: 16.04.2007 | Доступ: свободный | Студентов: 5321 / 857 | Оценка: 4.18 / 4.08 | Длительность: 16:03:00
Лекция 12:

Концепции распределенных баз данных

< Лекция 11 || Лекция 12: 1234 || Лекция 13 >

Отложенная синхронизация

Создать точную копию базы данных MySQL довольно просто. Способы резервного копирования баз данных описывались в лекции "Устранение последствий катастроф". Что касается восстановления данных, то это можно сделать на любом сервере. Располагая такими средствами, несложно реализовать распределенную базу данных, которая синхронизируется через достаточно большие промежутки времени, например, раз в день.

Рассмотрим проблему обновления данных. Если обновления происходят сразу на двух серверах, их нужно согласовывать. Чтобы не возникали неразрешимые ситуации, необходимо позволить вносить изменения только на одном сервере. Тогда синхронизация будет заключаться в дублировании содержимого сервера, доступного для записи, на все остальные серверы. Их полезность зависит от того, насколько важна актуальность данных. Во многих случаях база данных, содержащая все записи, кроме тех, которые были созданы за последние 24 часа, вполне приемлема.

Методика отложенной синхронизации идеально подходит для баз данных, содержащих результаты ночных отчетов. Например, Web-узел, предоставляющий доступ к МР3-файлам, может регистрировать названия запрашиваемых песен и составлять рейтинги популярности. Раз в день все серверы посылают свои журнальные главному серверу, который корректирует рейтинги согласно новой статистике. Схема такой базы данных приведена в листинге 12.1.

/* Каталог МР3-файлов. */
CREATE TABLE song (
	ID INT NOT NULL AUTO INCREMENT,
	Name CHAR(40) NOT NULL,
	Artist CHAR(16) NOT NULL,
	Filename CHAR(80) NOT NULL,
	PRIMARY KEY(ID),
	INDEX (Name),
	INDEX (Artist)
);

/* Журнал запрашиваемых файлов. */
CREATE TABLE log (
	Server TINYINT UNSIGNED NOT NULL,
	Song INT NOT NULL,
	DownloadTime DATETIME NOT NULL
);
Листинг 12.1. Схема распределений

Каждый сервер хранит информацию о доступных песнях в таблице song. В таблицу log заносится запись всякий раз, когда кто-то загружает очередной МР3-файл. У этой таблицы нет первичного ключа, так как в обычном режиме она используется лишь для вставки записей. Наличие индекса только замедлит работу с таблицей.

Раз в день таблицы log всех серверов объединяются по следующему сценарию. Один из серверов прекращает обслуживать запросы Web-приложений. Остальные серверы создают копии таблицы log, извлекают из них последние записи и посылают их серверу, генерирующему отчет. На время этой процедуры каждый сервер должен заблокировать свою таблицу log. Чтобы слишком много пользовательских запросов не оказалось заблокировано, процедуру желательно выполнять в период минимальной активности сервера.

Сервер, генерирующий отчет, загружает полученные данные в свою таблицу log, после чего выполняет сценарий, показанный в листинге 12.2. В этом сценарии создаются два рейтинга популярности: по всем песням и за последние 24 часа. Временный индекс таблицы log ускоряет ее просмотр.

/* Создание индекса. */
CREATE INDEX song ON log (Song);

/* Определение рейтинга всех песен. */
DROP TABLE IF EXISTS popular alltime;
CREATE TABLE popular alltime (
	Rank INT NOT NULL,
	Song INT NOT NULL,
	Hits INT NOT NULL,
);
SET @id = 0;
INSERT INTO popular alltime
	SELECT (@id := @id+1), song, COUNT (*)
	FROM Log
	GROUP BY 2
	ORDER BY 3 DESC;
ALTER TABLE popular alltime
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,
);
SET @id = 0;
INSERT INTO popular last24
	SELECT (@id := @id+1), song, COUNT (*)
	FROM Log
	WHERE DownloadTime > DATE SUB (NOW(), INTERVAL 24 HOUR)
	GROUP BY 2
	ORDER BY 3 DESC;
ALTER TABLE popular last24
ADD PRIMARY KEY (Rank);

/* Удаление индекса */
DROP INDEX song ON log;
Листинг 12.2.

Таблицы рейтингов не содержат поле-счетчик: вместо него используется инкрементная переменная. Будучи созданной, рейтинговая таблица уже не меняется. Сценарий удаляет существующие таблицы и формирует их заново. Имеет смысл сжимать такие таблицы с помощью утилиты myisampack (см. лекцию "Утилиты командной строки"). Созданные таблицы загружаются остальными серверами, где они заменяют старые рейтинги.

Изменения в таблицу song должны вноситься на одном сервере. Тогда исчезают проблемы, связанные с дублированием песен и первичных ключей. Главный сервер публикует новую редакцию каталога песен либо после каждого изменения, либо по определенному графику.

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

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

< Лекция 11 || Лекция 12: 1234 || Лекция 13 >
Александра Каева
Александра Каева
Дмитрий Черепенин
Дмитрий Черепенин

Какого года данный курс?