Распределенные информационные системы и базы данных. Учебное пособие

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

Синхронизация данных

Наличие распределенных копий фрагментов данных вызывает проблему поддержки согласованного распределенного набора данных (идентичности всех копий данных на всех узлах, вовлеченных в процесс тиражирования) – синхронизацию данных.

Репликация – это процесс создания и поддержания одинаковых копий данных (реплик) на различных узлах распределенной системы. Это обеспечивает повышенную надежность и доступность данных, позволяя сохранить информацию в случае отказа или сбоя системы. Репликация также может быть использована для балансировки нагрузки и увеличения производительности системы.

Сложность репликации заключается в обработке изменений реплицируемых данных. Существует три практически используемых алгоритма для репликации изменений между узлами: репликация с одним лидером, репликация с несколькими лидерами и репликация без лидера [51].

41

Репликация на основе лидера (активная/пассивная или «главныйподчиненный»). Суть ее заключается в следующем.

1.Одна из реплик назначается лидером (основной). Все изменения

вданных сначала записываются в основную реплику.

2.Каждый раз, когда лидер записывает новые данные, он также отправляет изменение данных всем подчиненным репликам в виде журнала репликации или потока изменений.

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

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

Репликация с несколькими лидерами («мастер-мастер» или активная/активная). Алгоритм репликации «мастер-мастер» позволяет выделить несколько реплик в качестве основной реплики, принимающих операции записи. Каждый лидер передает изменения другим, обеспечивая синхронизацию как основных реплик, так подчиненных. Этот метод обеспечивает лучшую отказоустойчивость и позволяет балансировать нагрузку между базами данных.

Репликация без лидера. Описанные подходы к репликации основаны на том, что запросы на запись отправляются на один узел (лидер), а система управления распределенной базой данных копирует записи на другие реплики. Лидер определяет порядок обработки записей, а подчиненные узлы применяют записи лидера в том же порядке.

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

Типы репликации данных подразделяются следующим образом

[51–54].

1. По способу синхронизации данных.

Репликация транзакций – это репликация базы данных, при которой фиксируются и передаются отдельные транзакции из основной базы данных на реплики: каждое изменение, внесенное в основную

42

базу данных (например, вставка, обновление или удаление), реплицируется на реплики в том же порядке, в котором оно произошло.

Репликация моментальных снимков8 – это репликация базы данных, при которой периодически создается копия (снимок) всей основной базы данных, которая передается на реплики. За этим первоначальным снимком затем следуют инкрементальные обновления для синхронизации реплик с основной базой данных. Репликация моментальных снимков обычно используется, когда данные изменяются нечасто или когда реплики расположены в удаленных местах с ограниченной пропускной способностью.

Репликация слиянием – это репликация базы данных, которая позволяет нескольким репликам независимо изменять данные, а затем объединять изменения обратно в основную базу данных. Этот тип репликации обычно используется, когда реплики часто отключаются от сети или когда необходимо разрешить конфликты между изменениями, внесенными в разные реплики.

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

2. По способу передачи данных.

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

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

8 Моментальный снимок (snapshot) – набор записей, который отражает статическое представление данных, зафиксированное во время создания моментального снимка.

43

к задержке, поскольку транзакции приходится ждать завершения процесса репликации.

Преимущества синхронной репликации:

данные в копиях идентичны;

высокая доступность. В случае отказа основной базы данных переключение на реплику происходит достаточно быстро (в пределах минуты), поскольку реплики продолжают работу и содержат актуальные данные.

Недостатки синхронной репликации:

замедляется работа основного приложения, так как возникает задержка при передаче данных на резервный сервер;

не предназначена для работы на больших расстояниях из-за увеличения времени отклика в канале связи;

значительно дороже других форм репликации.

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

Преимущества асинхронной репликации:

предназначена для работы на больших расстояниях;

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

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

Недостатки асинхронной репликации:

временная задержка между хранением на основном и удаленных узлах;

44

в случае аварии или сбоя данные, которые не были скопированы, будут потеряны, а данные во вторичном хранилище будут отставать от основной БД на то количество, которое не было передано.

Согласованность или доступность

Модель согласованности – подход, используемый в той или иной распределенной системе для обеспечения гарантий согласованности данных [55].

В системах с распределенной базой данных распространены следующие три модели согласованности:

1)строгая согласованность (сильная, strong consistency);

2)согласованность в конечном счете (eventual consistency);

3)слабая согласованность (weak consistency).

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

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

Слабая согласованность – модель согласованности, предполагающая, что данные могут обновляться на всех узлах в течение некоторого периода времени, при этом какие-то узлы временно будут содержать необновленные данные. Период с момента рассылки обновления до появления этих данных на всех узлах называется окном несогласо-

ванности (inconsistency window).

Основная сложность работы с транзакциями в распределенных базах данных заключается в управлении множественным (одновременным) доступом, при этом в транзакцию может быть вовлечено несколько узлов. Известные алгоритмы управления одновременным доступом основаны на механизме блокировок. Если приложение пытается получить доступ к данным, обрабатываемым другим приложением, то ему необходимо ждать завершения текущей транзакции. Однако это нарушает требование доступности: база данных должна быть доступна одновременно для всех пользователей в любое время,

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

45

Алгоритмы управления одновременным доступом могут использовать централизованное управление блокировками, при котором для всей распределенной базы данных поддерживается единая таблица блокировок. Эта таблица находится под управлением единого менеджера блокировок и располагается на одном из узлов, который может стать узким местом как из-за большого объема обработки данных, так и из-за генерируемого вокруг него интенсивного сетевого трафика, поскольку все узлы системы должны взаимодействовать с ним во время каждой своей операции. Кроме того, надежность такой системы ограниченна, поскольку отказ или недоступность центрального узла приводит к выходу из строя всей системы [8].

Распределенные транзакции и операции объединения, затрагивающие несколько фрагментов (узлов) распределенной базы данных, будут очень неэффективными из-за накладных расходов на связь и двухфазную фиксацию [56].

Требования ACID (Atomicity, Consistency, Isolation, Durability) ори-

ентированы на строгую согласованность и являются важными для бесперебойной работы системы, однако оказывается практически невозможным удовлетворить всем трем требованиям в полном объеме [56]. Когда происходит потеря связи между узлами, система должна принести согласованность в жертву доступности [57].

Теорема CAP

Акроним9 CAP отражает три важных свойства распределенных систем:

consistency (согласованность) – после выполнения каждой операции система находится в согласованном состоянии, т. е. данные на различных узлах не противоречат друг другу;

availability (доступность) – каждый запрос получает корректный ответ даже в случае выхода из строя узлов;

partition tolerance (устойчивость к разделению) – сохранение работоспособности при разделении системы на несколько изолированных частей.

9 Акроним – аббревиатура, образованная из начальных букв, частей слов или словосочетаний, например ФИО.

46

Теорема CAP утверждает, что лишь два из этих свойств могут поддерживаться одновременно [56]. Поэтому при построении распределенной базы данных приходится сделать выбор в пользу двух из перечисленных характеристик и пожертвовать третьей [57]. Выбор в каждом случае осуществляется исходя из конкретной задачи и требований к проектируемой базе. В зависимости от выбранных свойств СУРБД разделяются на три класса.

1.CA (consistency и availability) – система с фрагментацией данных,

строгой ACID, непротиворечивостью и принципом синхронных изменений с применением двухфазного протокола фиксации транзакций.

2.AP (availability и partition tolerance) – система поддерживает

согласованность в конечном счете. Это означает, что изменения с течением времени достигнут всех узлов, но одновременные запросы на несколько узлов могут вернуть разные результаты, поскольку изменения еще не достигли всех узлов.

3. CP (consistency и partition tolerance) – система поддерживает согласованность, чтобы с каждого узла можно было получать одни и те же данные. Однако могут быть отказы в выполнении запроса на узел, который еще не согласован с остальными узлами.

Замечание: свойство доступности в CAP не учитывает задержку ответа на запрос (latency). В реальных системах время ответа должно находиться в разумных пределах, а если задержка велика, то узел считается проблемным (недоступным). Более точным подходом будет компромисс между строгостью модели согласованности данных и получаемой в результате задержкой. Чем выше согласованность данных, тем больше времени нужно на выполнение запросов, и наоборот – при слабой согласованности запросы выполняются быстрее и задержка уменьшается.

Требования BASE

Альтернативным набором требований к распределенным системам является набор BASE [58]:

Basically Available – базовая доступность;

Soft-state – неустойчивое состояние;

Eventually consistent – согласованность в конечном счете.

Вотличие от строгой согласованности, входящей в набор ACID, набор BASE включает в себя более слабое требование – согласованность в конечном счете. Это условие подразумевает наличие окна

47

несогласованности, когда различные пользователи могут иметь доступ к разным версиям данных. Однако такой подход позволяет получить ряд преимуществ:

доступность – данные становятся доступными сразу после записи на узел;

отказоустойчивость – сбой одного из узлов не ведет к сбою системы в целом (данные будут недоступны лишь для пользователей узла, на котором произошел сбой).

Наборы свойств ACID и BASE представляют собой возможные

варианты требований к распределенной системе, и выбор одного из них зависит от того, какое из свойств играет бо́льшую роль для разрабатываемой системы – согласованность или доступность.

Особенности проектирования распределенной базы данных

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

Основные этапы последовательности проектирования распределенной базы данных показаны на рис. 10.

Анализ предметной области

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

48

Концептуальное проектирование

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

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

Логическое проектирование

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

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

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

На этом этапе осуществляется выбор системы управления РБД и учет ограничений выбранной СУРБД. Результатом логического проектирования является глобальная структура БД.

Расчленение (фрагментация) базы данных

На этом этапе проектирования исходная глобальная база данных разделяется на множество фрагментов (см. подраздел Стратегии распределения данных) так, чтобы совокупность фрагментов содержала в точности все данные, имевшиеся в глобальной базе данных, а также соблюдались ограничения на допустимый размер фрагментов.

При оценке производительности должны учитываться также

два основных фактора: время отклика и надежность системы.

Фрагменты должны содержать такие часто используемые совместно

50