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

Обычный сервер хранит у себя все данные и обслуживает все клиентские запросы. Схема взаимодействия между сервером и клиентами изображена на рис 12.1. Серверные данные располагаются на одном или нескольких физических дисках. Чтобы сделать запрос, клиент устанавливает соединение с сервером. Сервер анализирует инструкции, выполняет их, извлекает данные и возвращает результаты запроса. По мере возрастания нагрузки производительность сервера снижается. Чтобы избежать этого, задействуют дополнительные ресурсы, например, наращивают память, ставят дополнительные процессоры и даже сетевые платы. Эта стратегия эффективна, если клиенты расположены в непосредственной близости от сервера, — например, несколько серверов приложений взаимодействуют с одной СУБД. Но в тех архитектурах, где сервер и клиенты удалены друг от друга, производительность обратно пропорциональна расстоянию.

Решением этой проблемы являются распределенные базы данных (РБД), которые сегментируют хранимую информацию и перемещают отдельные ее блоки ближе к нужным клиентам. Способов организации таких баз данных много. Можно разместить таблицы на разных компьютерах или использовать несколько идентичных хранилищ. Во втором случае серверы взаимодействуют друг с другом для поддержания синхронизации. Если на одном из серверов происходит обновление данных, оно распространяется и на все остальные серверы.

К недостаткам распределенных баз данных можно отнести то, что возрастает сложность управления ими. Но преимуществ все же больше. Главное из них — повышение производительности. Данные быстрее обрабатываются несколькими серверами, а кроме того, данные располагаются ближе к тем пользователям, которые чаще с ними работают.

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

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

Распределенные базы данных трудно проектировать и обслуживать. Порядок работы в системе может со временем поменяться что повлечет за собой изменение схемы хранения данных. Как клиенты, так и серверы должны уметь обрабатывать запросы к данным, которые не расположены в ближайшей системе. Плохо спроектированная РБД может демонстрировать меньшую производительность, чем одиночный сервер.

РБД состоит из трех основных частей: клиентов, модуля обработки транзакций и хранилища данных. Сервер обычно берет на себя задачи обработки транзакций и хранения данных, хотя в полностью распределенной базе данных за решение этих задач отвечают разные аппаратные компоненты. Обратимся к рис 12.2. Здесь три клиента взаимодействуют с двумя модулями обработки транзакций, которые, в свою очередь, работают с двумя хранилищами. Клиенты посылают свои запросы модулям, а те определяют, в каком из хранилищ находятся требуемые данные.

В идеальном случае, клиенты не знают, является система распределенной или нет. Они лишь посылают ей запросы, а система возвращает клиентам результаты этих запросов. Как она это делает, клиентов не интересует. На практике распределенные базы данных проявляют разную "прозрачность". В крайнем случае РБД хранится на нескольких независимых серверах, а клиентскому приложению приходится выбирать сервер в зависимости от того, какую информацию требуется получить. Это подразумевает, что таблицы, находящиеся на разных серверах, не имеют никаких внутренних связей. Естественно, такая организация РБД лишь изредка оказывается полезной.

Система управления распределенными базами данных, или РСУБД, предоставляет клиентам унифицированный интерфейс доступа к данным, благодаря которому возникает иллюзия единого сервера. Если данные находятся в разных местах, РСУБД посылает запросы и обновления в соответствующие хранилища. В зависимости от того, с каким хранилищем ведется работа, производительность системы может оказаться разной, но, по крайней мере, клиентам не приходится самим заниматься выбором сервера.

Если данные реплицируются между несколькими серверами, клиент в общем случае может предпочесть тот или иной сервер. В подобной схеме все серверы хранят одни и те же данные. Специальный модуль может помогать клиентам в выборе серверов, осуществляя выравнивание нагрузки. РСУБД отвечает за выполнение транзакций в многосерверной среде, но в любой момент времени два сервера не могут быть синхронизированы между собой.

В РБД применяется несколько схем распределения данных. В случае репликации каждый сервер хранит весь объем данных. Для этого требуется, чтобы РСУБД дублировала транзакции, позволяя всем клиентам видеть согласованный образ базы данных. В случае несимметричного разделения данных выбирается уровень сегментации. На самом высоком уровне расщеплению подвергаются отдельные базы данных, но не таблицы. Каждая таблица целиком находится в каком-то одном месте. На более низком уровне таблицы расщепляются по строкам или столбцам. Например, при горизонтальном расщеплении отдельные подмножества записей помещаются в разные хранилища, а при вертикальном расщеплении подмножества формируются на основании столбцов.

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

Создать точную копию базы данных 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
);

Каждый сервер хранит информацию о доступных песнях в таблице 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;

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

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

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

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

Репликация в MySQL

Программа MySQL реализует функции автоматической репликации данных между главным и подчиненными серверами. Главный сервер ведет журнал изменений, который делается доступным для одного или нескольких подчиненных серверов. Простейшая схема репликации с участием одного главного и двух подчиненных серверов изображена на рис 12.3.

Все серверы работают под управлением MySQL на разных компьютерах подключенных к сети. В целях синхронизации подчиненные серверы регулярно связываются с главным сервером. Последний фиксирует каждое изменение в двоичном журнале (см. лекцию "Физическое хранение данных"). Если не считать короткие промежутки времени, в течение которых происходит синхронизация, подчиненные серверы содержат зеркальные копии базы данных.

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

На подчиненном сервере запускается отдельный поток, который периодически опрашивает главный сервер на предмет наличия изменений. Однако бывает так, что сервер одновременно является и главным, и подчиненным. Тогда становится возможной схема репликации, изображенная на рис 12.4. Здесь есть четыре сервера, каждый из которых играет двойную роль. Приложение направляет "своему" серверу запросы как на выборку, так и на обновление данных. Обновление, произошедшее на одном сервере, передается по цепочке остальным серверам.

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

В схеме на рис 12.4 каждое приложение взаимодействует с одним сервером, хотя это необязательно. Если серверы расположены рядом, можно формировать пул серверов. Тогда при выборе сервера приложение сможет учитывать возможность сбоя или применять алгоритм выравнивания нагрузки.

Подчиненный сервер контролирует, какое изменение было получено от главного сервера последним. По умолчанию сведения об этом находятся в файле master info.

Если обновление приводит к появлению ошибки, то поток, управляющий синхронизацией, останавливается. В этом случае сервер записывает сообщение в журнал ошибок. В MySQL версии 3.23.39 механизм репликации имеет ряд ограничений. В основном все они связаны с тем, что изменения фиксируются только в двоичном журнале. Функция RAND() по умолчанию инициализирует генератор псевдослучайных чисел значением системных часов, но это значение не сохраняется в двоичном журнале. В подобной ситуации можно инициализировать генератор самостоятельно с помощью функции UNIX TIMESTAMP().

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

Значения переменных не реплицируются. Если в обновлении строки участвовала переменная, то на подчиненном сервере будет использовано локальное, а не реальное значение этой переменной.

Чтобы включить функции репликации, нужно отредактировать конфигурационные файлы сервера. Ниже перечислены опции демона mysqld, имеющие отношение к репликации. Все они были описаны в лекции "Утилиты командной строки".

--binlog-do-db=база данных
--binlog-ignore-db=база данных
--log-bin-index=каталог
--log-bin[=каталог]
--log-slave-updates
--master-connect-retry=секунды
--master-host=узел
--master-info-file=файл
--master-password=пароль
--master-port=порт
--master-user=пользователь
--replicate-do-db=база данных
--replicate-do-table=база данных.таблица
--replicate-ignore-db=база данных
--replicate-ignore-table= база данных.таблица
--replicate-rewrite-db=главный->подчиненный
--replicate-wind-do-table=шаблон
--replicate-wind-ignore-table=шаблон
--server-id=идентификатор

Прежде чем редактировать конфигурационные файлы, создайте на главном сервере учетную запись, чтобы подчиненный сервер мог получать обновления. В листинге 12.3 показана инструкция, создающая пользователя user с привилегией FILE. Никакие другие привилегии подчиненному серверу не нужны. В данном примере пользователь может посылать запросы с любого узла, но на практике обычно указывают конкретное доменное имя.

GRANT FILE ON *.*  ТО slave IDENTIFIED BY ‘password’

Теперь нужно остановить главный сервер или заблокировать все таблицы, подлежащие репликации. Создайте точные копии реплицируемых баз данных и лишь затем редактируйте конфигурационные файлы. Вспомните, что таблицы MySQL имеют системно независимый формат. Это позволяет копировать и перемещать файлы, не меняя их формат. В листинге 12.4 создается tar архив одной базы данных. Можно также выполнить на подчиненном сервере инструкцию LOAD TABLE, чтобы получить точную копию нужной таблицы.

[/usr/local/var]# tar cvfz freetimedb.tar.gz. /freetime/

Далее требуется включить двоичный журнал на главном сервере, внеся изменения в конфигурационный файл /etc/my.cnf Соответствующая опция называется log bin. С помощью опции server id серверу присваивается уникальный идентификатор. В листинге 12.5 показаны две строки, которые добавляются в раздел [mysqld] конфигурационного файла. После внесения изменений нужно перезапустить главный сервер.

log-bin
server_id=1