Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Лекция 7.
Проектирование распределенной обработки данных
1. Общие принципы управления распределенными базами данных.
2. Доступ к распределенным базам данных.
3. Репликация данных.
Основные принципы архитектурного построения систем распределенной обработки данных рассматривались на одной из первых лекций по курсу «Проектирование АСОИ и У». На данной лекции будут рассмотрены основные принципы управления распределенными базами данных с помощью SQL. Кроме того, будут также рассмотрены задачи, возникающие при работе с распределенными данными и концептуальные пути их решения.
1. Общие принципы управления распределенными базами данных.
Применение цифровых вычислительных сетей различной направленности и масштаба привело к тому, что сегодня практически повсеместно применяется распределенная обработка данных. Данные в таких системах хранятся, преимущественно, в тех места, где производится их обработка, а в дальнейшем, для принятия управленческих решений по деятельности предприятия (корпорации), все данные собираются в аналитическом центре с помощью мощных корпоративных серверов баз данных.
В связи с тем, что данные распределены по различным системам, нетрудно себе представить запросы, связанные с обращением сразу к нескольким базам данных. Эти запросы должны осуществлять обращения по сети для выборок и обработки данных, хранящихся в различных отделах на серверах, находящихся под управлением различных СУБД. Ведущие производители СУБД предлагают множество продуктов, позволяющих эффективно управлять распределенными данными и решать весь спектр связанных с этим задач.
Для того чтобы система управления распределенными данными была близка к идеальной, она должна удовлетворять следующим требованиям:
Реализовать систему, удовлетворяющую всеем перечисленным требованиям практически невозможно, т.к. приходится преодолевать ряд проблем, связанных с низкой производительностью, сохранением целостности, поддержки плана выполнения статического SQL, оптимизации БД, хранения системных каталогов, совместимости оборудования от различных поставщиков, преодоления тупиковых ситуаций.
2. Доступ к распределенным базам данных.
В простейшем случае пользователю одной БД предоставляется возможность подключения по сети к другим БД и извлекать из них информацию. Обычно это означает выполнение одиночного запроса к удаленной БД (СЛАЙД 1).
На данном рисунке изображена схема выполнения запроса с помощью SQL, которая применяется, когда локальная БД является периферийной, а удаленная – центральной корпоративной БД. Также на этом же рисунке показана схема выполнения обычного клиент-серверного запроса к удаленной БД, направленного пользователем другого ПК. С точки зрения удаленной БД , разница между обработкой от обычного клиентского ПК и запроса, полученного по специальной технологии удаленного доступа, невелика. В обоих случаях запрос передается по сети, удаленная СУБД определяет, имеет ли пользователь нужные привилегии, и выполняет запрос. Информация о том, чем завершилось выполнение запроса, передается обратно по сети.
А вот локальная СУБД, участвующая в процессе, должна выполнять совершено иные действия, чем при выполнении обычного локального запроса. У нее несколько задач:
Для подключения к удаленной БД применяется специальная инструкция: CONNECT TO имя_удаленонго_сервера.
После выполнения этой инструкции локальный сервер входит в режим сквозной передачи и направляет все последующие инструкции удаленному серверу.
Когда работа с удаленным сервером закончена, нужно выполнить инструкцию DISCONNECT.
В некоторых СУБД применяется иная схема доступа к удаленным данным. Для доступа к удаленной БД пользователь локальной системы использует стандартные инструкции SQL, только к именам удаленных таблиц и представлений добавляется символ @, за которым следует имя канала связи. Например, SELECT MANE, ADRESS, FON/FAX
FROM table1@HOST1
WHERE ________________
Определенные неудобства в составлении запросов к удаленным базам данных начинаются когда необходимо обратится с запросом к конкретной таблице конкретного пользователя. В этом случае используются полные имена, а написание таких длинных текстов запросов не совсем удобно. Кроме того, определенные трудности возникают, когда происходит обработка распределенных транзакций. В следующем, третьем, вопросе будет рассмотрена технология репликации баз данных.
3. Репликация данных
Доступ к удаленным базам данных из локальных СУБД преимущественно применяется при выполнении небольших запросов и нерегулярном доступе к данным. Если же приложению требуется интенсивный и частый доступ к удаленной БД, тогда коммуникационные издержки могут оказаться неприемлемыми. Когда интенсивность и частота операций удаленного доступа превышает определенный предел, более эффективным оказывается использование локальной копии удаленных данных (СЛАЙД 2). В простейшем случае содержимое таблицы извлекается из главной базы даны, посылается по сети и помещается в соответствующую таблицу-реплику в подчиненной базе данных. Эта процедура выполняется периодически во время наименьшей загрузки сети.
Такой подход удобен в тех случаях, когда данные в реплицируемых таблицах изменяются редко или изменения выполняются в пакетном режиме. Данную стратегию модно организовать без поддержки со стороны СУБД. Для должны быть написаны несколько программ: во-первых, программа, извлекающая данные из БД и помещающая их в файл; во-вторых, программа, пересылающая файл на локальный ПК; в-третьих, программа, считывающая содержимое файла и применяющая инструкции DROP TABLE, CREAT TABLE и INSERT для заполнения таблиц-реплик. Данный подход носит название «дублирования таблиц». При такой схеме приложениям не разрешается обновлять данные. В случае подобной попытки СУБД сгенерирует ошибку.
Более гибкой в этом отношении схемой является схема двунаправленной репликации (СЛАЙД 3).
Такая схема применяется, когда каждый пользователь имеет права на изменение данных в одних и тех же таблицах. Однако в этом случае возможны ситуации обновления одной и той же строки в различных репликах. То есть на лицо нарушение целостности данных. Следовательно, в системах двунаправленной ситуации должен быть предусмотрен механизм соблюдения целостности базы данных.
Затраты на репликацию
На практике любая стратегия репликации подразумевает определенный компромисс между актуальностью данных и производительностью системы. Причем учитываются не только чисто технические аспекты, но и особенности конкретной ситуации, в которой применяется репликация. Во многих случаях выбрать схему репликации, при которой конфликты между обновленными репликами будут устранены или, по крайней мере, сведены к минимуму затруднительно. Рассмотрим несколько типичных сценариев репликации таблиц и принципы разрешения, возникающих в них конфликтов.
ГОРИЗОНТАЛЬНАЯ РЕПЛИКАЦИЯ ТАБЛИЦ
Распределить таблицу по сети можно следующим образом: разделить таблицу горизонтально, помещая полученные данные в различные системы (СЛАЙД 4).
Например, компания имеет несколько региональных дистрибьюторских центра, в каждом из которых предлагаются свои группы товаров, выполняется собственная обработка заказов и имеется база данных товарных запасов.
Для реализации этой схемы центральная таблица table разделяется горизонтально на три части, и в нее добавляется столбец, указывающий местоположение товара. Строки товара, описывающие товары конкретного центра, передаются в региональные БД, управляемые центральной СУБД.
Большинство обновлений таблицы table выполняется в региональных центрах в процессе обработки заказов. Поскольку реплики таблицы table в каждом центре независимы друг от друга (любая строка таблицы может входить только в одну реплику), конфликты обновлений невозможны. Все изменения реплик могут периодически пересылаться в центральную БД, чтобы в ней была представлена актуальная информация.
ВЕРТИКАЛЬНАЯ РЕПЛИКАЦИЯ ТАБЛИЦ
Другой способ распределения таблицы по сети состоит в вертикальном разделении таблицы и размещении ее столбцов в разных системах (СЛАЙД 5).
Таблица, показанная на данном рисунке, содержит информацию, которая используется как отделом кадров, так и отелом обработки заказов. Работа каждого отдела по большей части сфокусирована на одном или двух столбцах таблицы, относящихся как к отделу к отделу кадров, так и к отделу обработки заказов.
Для реализации этой схемы таблица целиком реплицируется в обе системы, но логически считается разделенной вертикально на две части. столбцы таблицы, содержащие личные данные принадлежат БД отдела кадров. Любые конфликты, связанные с обновлением этих столбцов, решаются в пользу отдела кадров. Остальные столбцы принадлежат БД отдела обработки заказов. В его пользу решаются конфликты в отношении этих столбцов. поскольку в обеих БД имеется полная копия таблицы, можно создавать по ней отчеты и обращаться к ней с запросами, причем вся обработка буде производиться локально. Только при обновлениях задействуется механизм репликации, возникает сетевой трафик и возможно возникновение конфликтов.
ЗЕРКАЛЬНАЯ РЕПЛИКАЦИЯ ТАБЛИЦ
Когда репликация необходима для обеспечения высокой отказоустойчивости системы (чтобы система могла продолжать свою работу в аппаратных сбоев или сбоев в БД), создается зеркальная копия всей таблицы (СЛАЙД 6).
В простейшей конфигурации одна БД становится активной, а другая – резервной. Все запросы направляются к активной БД (система А), которая посылает реплики всех изменений резервной БД (система В). В случае сбоя запросы перенаправляются в резервную систему, которая содержит свежие данные. Недостатком такого подхода является то, что при нормальной работе без сбоев ресурсы резервной системы тратятся впустую. Эту систему необходимо обслуживать и оплачивать, хотя она не участвует в обработке данных.
Из-за указанного недостатка системы с высокой отказоустойчивостью проектируют так, чтобы сбалансировать возникающую в них нагрузку (СЛАЙД 7).
В такой конфигурации некоторая промежуточная программа перехватывает запросы к СУБД и распределяет их между двумя или более системами. При нормальной работе ни одна из систем не простаивает.
4. Механизмы репликации SQL Server 2000.