Файл: Учебнопрактическое пособие Владимир 2021.pdf

206 судить о согласованности реплицированной базы данных в условиях, когда применяются относительно нестрогие политики репликаций.
Исследования в этой области находятся лишь в зачаточном состоя- нии.
Теорема САР
Теорема CAP (известная также как теорема Брюера) — эвристи- ческое утверждение о том, что в любой реализации распределённых вычислений возможно обеспечить не более двух из трёх следующих свойств:

согласованность данных (англ. consistency) — во всех вы- числительных узлах в один момент времени данные не противоречат друг другу;

доступность (англ. availability) — любой запрос к распре- делённой системе завершается корректным откликом, однако без га- рантии, что ответы всех узлов системы совпадают;

устойчивость к разделению (англ. partition tolerance) — расщепление распределённой системы на несколько изолированных секций не приводит к некорректности отклика от каждой из секций.
Акроним CAP в наименовании теоремы сформирован из первых букв английских наименований этих трёх свойств.
Принцип был предложен профессором Калифорнийского уни- верситета в Беркли Эриком Брюером в июле 2000 года и впослед- ствии получил широкую популярность и признание в среде специали- стов по распределённым вычислениям. Концепция NoSQL, в рамках которой создаются распределённые нетранзакционные системы управления базами данных, зачастую использует этот принцип в ка- честве обоснования неизбежности отказа от согласованности данных.
С точки зрения теоремы CAP, распределённые системы в зави- симости от пары практически поддерживаемых свойств из трёх воз- можных распадаются на три класса — CA, CP, AP.
В системе класса CA во всех узлах данные согласованы и обес- печена доступность, при этом она жертвует устойчивостью к распаду

207 на секции. Такие системы возможны на основе технологического программного обеспечения, поддерживающего транзакционность в смысле ACID, примерами таких систем могут быть решения на осно- ве кластерных систем управления базами данных или распределённая служба каталогов LDAP.
Система класса CP в каждый момент обеспечивает целостный результат и способна функционировать в условиях распада, но дости- гает этого в ущерб доступности: может не выдавать отклик на запрос.
Устойчивость к распаду на секции требует обеспечения дублирования изменений во всех узлах системы, в связи с этим отмечается практи- ческая целесообразность использования в таких системах распреде- лённых пессимистических блокировок для сохранения целостности.
В системе класса AP не гарантируется целостность, но при этом выполнены условия доступности и устойчивости к распаду на секции.
Хотя системы такого рода известны задолго до формулировки прин- ципа CAP (например, распределённые веб-кэши или DNS), рост по- пулярности решений с этим набором свойств связывается именно с распространением теоремы CAP. Так, большинство NoSQL-систем принципиально не гарантируют целостности данных, и ссылаются на теорему CAP как на мотив такого ограничения. Задачей при построе- нии AP-систем становится обеспечение некоторого практически це- лесообразного уровня целостности данных, в этом смысле про AP- системы говорят, как о «целостных в конечном итоге» (англ.
eventually consistent) или как о «слабо целостных» (англ. weak
consistent).
Во второй половине 2000-х годов сформулирован подход к по- строению распределённых систем, в которых требования целостности и доступности выполнены не в полной мере, названый акронимом
BASE (от англ. Basically Available, Soft-state, Eventually consistent — базовая доступность, неустойчивое состояние, согласованность в ко- нечном счёте), при этом такой подход напрямую противопоставляется
ACID. Под базовой доступностью подразумевается такой подход к проектированию приложения, чтобы сбой в некоторых узлах приво- дил к отказу в обслуживании только для незначительной части сессий

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

209
Центры обработки данных (ЦОД) - совокупность функциональ- но и конструктивно связанных технических, программных и инфор- мационно-лингвистических компонентов, принадлежащая одному объекту АИС и предназначенная для автоматизированного выполне- ния заданных функций управления на объекте. В системах с иерархи- ческим управлением различают ЦОД головных, промежуточных и низовых объектов (рис. 3.3).
Рис. 3.3. Техническая структура информационной системы
ЦОД состоит из технологических комплексов, объединяющих в себе технические средства автоматизации (рис. 3.4). Ниже приведен список технологических комплексов:

Электронно-вычислительные комплексы (серверы, маши- ны) (ВК, ЭВМ) – создание и ведение информационной базы, решение расчетных задач, контроль процессов обработки данных;

Комплексы средств общения пользователей с ВК (автома- тизированные рабочие места – АРМ, выполненные на базе персо- нальных ЭВМ или терминалов) – ввод, прием данных вычислитель-

210 ных комплектов, хранение и документирование данных, решение не- сложных задач;

Комплексы средств передачи данных (КСПД) - обеспечи- вают передачу данных от источника (отправителя) к потребителю
(получателю);

Комплексы средств фиксации и сбора первичной инфор- мации (АДИ) - фиксируют и собирают информацию в местах ее воз- никновения, а также представляют ее в виде, допускающем передачу;

Комплексы средств ведения единого времени (КСВЕВ) - индикацию текущего астрономического времени, отсчет абсолютного астрономического времени;

Комплекс средств технического обслуживания и ремонта
(КСТОР) – поддержка работоспособное состояние остальных ком- плексов;

Комплекс средств обучения и тренажа должностных лиц обслуживающего и оперативного состава (КСОТ);

комплексы средств жизнеобеспечения (КСЖО) - создание необходимых для работы пользователей и персонала условия.
Рис. 3.4. Обобщенная архитектура центра обработки данных

211
3.5. Репликация баз данных
Синхронизации данных необходима в случае, если для работы с информационной системой используется распределенная база дан- ных, когда требуется поддерживать актуальную версию изменяемых файлов, содержащую в себе все последние исправления, сделанные пользователями различных узлов системы независимо друг от друга.
Вопросы построения распределенной базы данных единой ин- формационной системы возникают в разных случаях, например, при развитии компании, когда создаются удаленные филиалы, магазины и склады. Каждая удаленная информационная система с целью повы- шения устойчивости должна работать самостоятельно, периодически отправляя в Центральный офис консолидированную информацию.
Синхронизация содержимого базы данных на стороне различ- ных клиентов системы (узлов сети) выполнятся посредством меха- низма репликаций (для исключения человеческого фактора в вопросе периодической синхронизации информации базы).
Репликация — процесс приведения данных электронных таблиц двух или более БД в идентичное состояние.
Репликация использует метафору издательского дела, в основе топологии репликации лежат такие компоненты как издатель, распро- странитель, подписчики, публикации, статьи и подписки.
Репликацию Microsoft SQL Server удобно представить в терми- нах, связанных с выпуском журнала.
Издатель журнала выпускает одну или несколько публикаций.
Публикация содержит статьи.
Издатель распространяет журнал напрямую или через распро- странителя.
Подписчики получают публикации, на которые они подписа- лись.
Хотя метафора журнала помогает понять суть репликации, она включает в себя не все функции репликации SQL Server. В частности, она не содержит возможности подписчика делать обновления, а изда- теля — вносить накопительные изменения в опубликованные статьи.

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

213 куда и когда. Существует два типа подписки: принудительная и по запросу.
Существует три основных типа репликации:

Репликация моментальных снимков;

Репликация на уровне транзакций;

Репликация данных методом слияния.
Выбор типа репликации для приложения зависит от ряда факто- ров, в том числе физической среды репликации, типа и количества реплицируемых данных, а также обновления данных у подписчика.
Физическая среда определяется числом и местоположением компью- теров, вовлеченных в репликацию, а также тем, являются ли они кли- ентами или серверами.
Обычная репликация любого типа начинается с исходной син- хронизации публикуемых объектов у издателя и подписчиков.
Репликация моментального снимка
Исходную репликацию можно выполнить с помощью реплика- ции моментального снимка, который является копией всех объектов и данных, указанных публикацией. Созданный моментальный снимок отправляется подписчикам. В случае репликации моментального снимка изменения данных не отслеживаются. При каждом примене- нии моментального снимка существующие данные полностью пере- записываются. Использование репликации моментальных снимков уместно, если выполняется одно или несколько следующих условий:

Данные изменяются редко.

Допускается хранение в течение некоторого времени ко- пий данных, устаревших по сравнению с данными издателя.

Реплицируются небольшие объемы данных.
За короткий промежуток времени происходит много изменений.
Репликация моментальных снимков создает меньшую непре- рывную нагрузку на издателя, чем репликация транзакций, так как последующие изменения не отслеживаются. Однако если реплициру-

214 ется очень большой набор данных, потребуются значительные ресур- сы для того, чтобы создать и передать снимок.
Для некоторых приложений достаточно репликации моменталь- ного снимка. В других случаях требуется, чтобы последующие изме- нения данных поступали подписчику в реальном времени. Кроме то- го, в некоторых приложениях изменения должны передаваться от подписчика обратно к издателю. Для таких приложений можно ис- пользовать репликацию транзакций или репликацию слиянием.
Репликация транзакций
Репликация транзакций обычно начинается моментальным снимком объектов и данных базы данных публикации. После снятия исходного моментального снимка последующие изменения данных и схем, сделанные в издателе, обычно доставляются подписчику по ме- ре их появления. Изменения данных применяются к подписчику в том же порядке и в тех же рамках транзакции, что и у издателя.
Репликация транзакций обычно используется в средах «сервер- сервер» и подойдет в любом из следующих случаев.
Необходимо распространять подписчикам добавочные измене- ния по мере их появления.
От приложения требуется малая задержка между внесениями изменений на издателе и доставкой этих изменений подписчику.
Приложению требуется доступ к промежуточным состояниям данных. Например, если строка меняется пять раз, репликация тран- закций позволяет приложению реагировать на каждое изменение строки, а не только на конечное.
Издатель выполняет большое количество операций вставки, об- новления и удаления.
Издатель или подписчик является базой данных, отличной от
SQL Server, например Oracle.
При репликации транзакций изменения записываются в журнал транзакций SQL Server.