![]() Главная страница Случайная страница КАТЕГОРИИ: АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника |
Распределенные системы
Классификация. Следует выделить два класса систем распределенной обработки и системы распределенных данных: • системы распределенной обработки в основном отражают структуру и свойства многопользовательских операционных систем с базой данных, размещенной на центральном компьютере; • системы распределенных данных обеспечивают обработку распределенных запросов, когда при обработке одного запроса используются информационные ресурсы, размещенные на различных ЭВМ сети. При этом, как и ранее, следует говорить как о распределенных файловых системах, так и о распределенных базах данных. Для распределенных баз данных свойственны следующие характеристики: • база данных — это логически связанные, разделяемые на некоторое количество фрагментов данные; • фрагменты распределяются по разным узлам, которые связаны между собой сетевыми соединениями; • может быть предусмотрена репликация фрагментов; • доступ к данным на каждом узле происходит под управлением СУБД, которая на каждом узле должна поддерживать работу как локальных приложений, так и глобальных. Основные условия и требования к распределенной обработке данных: • прозрачность относительно расположения данных (СУБД должна представлять все данные так, как если бы они были локальными); • гетерогенность системы (СУБД должна работать с данными, которые хранятся в системах с различной архитектурой и производительностью); • прозрачность относительно сети (СУБД должна одинаково работать в условиях разнородных сетей); • поддержка распределенных запросов (пользователь должен иметь возможность объединять данные из любых баз, даже если они размещены в разных системах); • поддержка распределенных изменений (пользователь должен иметь возможность изменять данные в любых базах, на доступ к которым у него есть права, даже если эти базы размещены в разных системах); • поддержка распределенных транзакций (СУБД должна выполнять транзакции, выходящие за рамки одной вычислительной системы, и поддерживать целостность распределенной БД даже при возникновении отказов как в отдельных системах, так и в сети); • безопасность (СУБД должна обеспечивать защиту всей распределенной БД от несанкционированного доступа); • универсальность доступа (СУБД должна обеспечивать единую методику доступа ко всем данным). Поясним некоторые из этих требований: Прозрачность расположения. Прозрачный (для пользователя) доступ к удаленным данным предполагает использование в прикладных программах такого интерфейса с сервером БД, который позволяет переносить данные в сети с одного узла на другой, не требуя при этом модификации текста программы. Иными словами доступ к информационным ресурсам должен быть полностью прозрачен относительно расположения данных. Любой пользователь или любая прикладная программа оперирует с одной или несколькими базами данных. В том случае, когда прикладная программа и сервер БД выполняются на одном и том же узле, проблемы расположения не возникает. Для получения доступа к базе данных пользователю или программе достаточно указать имя базы, например: SQL Dbname. Однако в том случае, когда прикладная программа запускается на локальном узле, а база данных находится на удаленном, возникает проблема идентификации удаленного узла. Для того чтобы получить доступ к базе данных на удаленном узле, необходимо указать имя удаленного узла и имя базы данных. Если использовать жестко фиксированное имя узла в паре «имя_узла, имя_БД», то прикладная программа становится зависимой от расположения БД. Например, обращение к БД «host: stock», где первый компонент — имя узла, будет зависимым от расположения. Одно из возможных решений этой проблемы состоит в использовании виртуальных имен узлов. Управление ими обеспечивается специальным программным компонентом СУБД — сервером имен (Name Server), который адресует запросы клиентов к серверам. Прозрачность сети. Клиент и сервер взаимодействуют по сети с конкретной топологией; для поддержки взаимодействия всегда используется определенный протокол. Следовательно, оно должно быть организовано таким образом, чтобы обеспечивать независимость как от используемого сетевого аппаратного обеспечения, так и от протоколов сетевого обмена. Чтобы обеспечить прозрачный доступ пользователей и программ к удаленным данным в сети, объединяющей разнородные компьютеры, коммуникационный сервер должен поддерживать как можно r лее широкий диапазон сетевых протоколов (TCP/IP, DECnet SNA, SPX/IPX, NetBIOS, AppleTalk и др.). Автоматическое преобразование форматов данных. Как толь ко несколько компьютеров различных моделей под управлением различных операционных систем соединяются в сеть, сразу возникает вопрос о согласовании форматов представления данных Действительно, в сети могут быть компьютеры, отличающиеся разрядностью (16-, 32- и 64-разрядные процессоры), порядком следования байт в слове, представлением чисел с плавающей точкой и т. д. Задача коммуникационного сервера состоит в том чтобы на уровне обмена данными обеспечить согласование форматов между удаленным и локальным узлами с тем, чтобы данные, извлеченные сервером из базы на удаленном узле и переданные по сети, были правильно истолкованы прикладной программой на локальном узле. Автоматическая трансляция кодов. В неоднородной компьютерной среде при взаимодействии клиента и сервера возникает также задача трансляции кодов. Сервер может работать с одной кодовой таблицей (например, EBCDIC), клиент — с другой (например, ASCII), при этом происходит рассогласование трактовки кодов символов. Поэтому, если на локальном узле используется одна кодовая таблица, а на удаленном — другая, то при передаче запросов по сети и при получении ответов на них необходимо обеспечить трансляцию кодов. Решение этой задачи также ложится на коммуникационный сервер. Однако ни одна из существующих СУБД не достигает этого идеала вследствие следующих практических проблем: • низкая и несбалансированная производительность сетей передачи данных, что в распределенных транзакциях сильно снижает общую производительность обработки; • обеспечение целостности данных в распределенных транзакциях базируется на принципе «все или ничего» и требует специального протокола двухфазного завершения транзакций, что приводит к длительной блокировке изменяемых данных; • необходимо обеспечить совместимость данных стандартного типа, для хранения которых в разных системах используются разные физические форматы и кодировки; • трудности выбора схемы размещения системных каталогов. Если каталог будет храниться в одной системе, то удаленный доступ будет замедлен. Если будет размножен, то изменения придется распространять и синхронизировать; • необходимо обеспечить совместимость СУБД разных типов и поставщиков; • увеличение потребностей в ресурсах для координации работы приложений с целью обнаружения и устранения тупиковых ситуаций в распределенных транзакциях.
|