Файл: Распределенная технология обработка информации.pdf

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

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

А при вертикальной фрагментации такое отношение делится на разные разделы при использовании операции проекции.

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

Для ослабления отличительных особенностей каждой распределенной системы создается параллельная система. Не существует четкого и конкретного разграничения между распределенными и параллельными системами. В частности, все архитектуры параллельных систем без используемых совместно ресурсов, которые обсуждаются ниже, очень схожи со слабо распределенными связанными системами. [9]

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

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

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

Важное значение имеет и применение стандартных аппаратных компонентов, чтобы иметь возможность с самым минимальным отставанием использовать разные результаты постоянных технологических и современных усовершенствований. [8]

В ПО базы данных могут предусматриваться 3 вида параллелизма, присущие приложениям с интенсивной обработкой данных: [2]

– Межзапросный параллелизм предполагает выполнение одновременное множество запросов, относящихся к самым разным транзакциям.

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

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

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

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

Это также обеспечивается за счет разных видов прозрачности: [7]

– прозрачность сети;

– прозрачность репликации;

– прозрачность фрагментации.

Вопросы прозрачности также более критичны для распределенных, нежели для параллельных систем. Этому есть 2 причины:

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

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

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

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

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

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

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

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

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

1.3.Понятия прикладных протоколов и стандартов в системах распределенной обработки данных

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

Протокол прикладного уровня является частью (весьма большой) для сетевых приложений. Рассмотрим 2 примера.

Web является специальным сетевым приложением, что позволяет пользователям получать web-документы с помощью запроса и состоящим из разного множества компонентов, включая также стандарт формата документов (тип HTML), браузеры (Microsoft Internet Explorer и другие), web-серверы (к примеру, Apache, Microsoft и Netscape), протоколы прикладных уровней.

Протокол прикладного уровня для сервиса web носит название «протокол передачи гипертекста» (HTTP) и описывает форматы и порядок обмена разными сообщениями между сервером и клиентом. Таким образом, HTTP – это лишь часть web-приложения.

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

Главным протоколом прикладного уровня электронной почты является протокол передачи сообщений (SMTP). Как видно, SMTP – лишь часть (хотя и большая) структуры приложений для электронной почты.

Протоколы прикладного уровня также определяют способ обмена разными сообщениями между 2-я процессами, выполняющимися с разными оконечными системами. Обычно протокол определяет такие элементы:

– типы используемых сообщений;

– синтаксис каждого с типов сообщений, что описывают поля сообщения;

– семантику полей, смысл информации, что содержится в каждом с полей сообщения;

– правила, которые описывают события, что вызывают генерацию сообщений.

Стоит отметить, что некоторые из протоколов для прикладного доступа (HTTP, SMTP) являются официально документированными. Это означает, что разработчик нового браузера также будет следовать стандарту, а браузер сможет получать все документы с разных web-серверов, построенных по этому стандарту.

Тем не менее также существует множество протоколов и прикладного уровня, что не стандартизированы и используются при этом для поддержки коммерческих проектов. В частности, это также характерно и для Интернет-телефонии.

В области интерфейсов для систем обработки данных для соединений типа клиент-сервер происходит процесс стандартизации.

Имея несколько альтернативных типов стандартов, организации, что внедряют в свои среды управления информацией технологию «клиент-сервер», могут выбрать те что решения, наиболее полно соответствуют их конкретным потребностям.

Процесс стандартизации для доступа к «клиент-сервер» приобрел наибольшую активность еще в конце 80-х – начале 90-х годов. В 1989 г. создана группа ученых SQL Access Group (SAG), которая представляет собой консорциум с 42 компаний, которые входят крупнейшие поставщики разных СУБД.

Одной из главных задач SAG было определение разных спецификаций форматов или протоколов (FAP) для коммуникаций в системах БД «клиент-сервер» на основании спецификаций Удаленного доступа к БД (RDA), разработанных Международной организацией для стандартизации.

Стандарт RDA также описан в документе ISO/IEC 9379, который состоит из 2-х частей:

– общая модель, сервис, протокол;

– специализация SQL.

Как раз вторая часть данного документа и стала базой спецификаций FAP, что предложена группой SAG.[3]

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

Примерно в это же время фирма IBM, единственный крупный поставщик для средств, не вошедший в группу SAG, вводит стандарт "Архитектура для распределенных реляционных БД", никак не согласуя с ISO RDA.

Исходной целью DRDA являлась интеграция БД в рамках системной архитектуры для приложений, предложенной IBM.

Но изначально SAA рассматривалась как основное средство интеграции для 4-х платформ IBM:[7]

– VM;

– OS/400;

– MVS;

– OS/2.

Используя SAA и DRDA, можно объединять менеджеры БД для этих платформ (SQL/DS, DB2, OS/400 Data Manager, OS/2) в единую модель типа «клиент-сервер».

В 1990 году IBM предложила архитектуру для хранилища информации, в которой DRDA отведена ключевая роль для интеграции баз данных типа «клиент-сервер», управляемых различными программными продуктами, а также ряд поставщиков средств БД объявили о своей поддержке стандарту DRDA.

Таким образом, уже в начале 1992 года в области стандартизации для доступа к БД «клиент-сервер» образовалось 2 "лагеря" – SAG, что опирался на стандарт RDA, а также сторонники DRDA, что был ориентирован на платформы IBM.

В 1992 г. возникли также сразу два конкурирующих стандарта – IDAPI и ODBC, они оба основаны на интерфейсе для уровня вызовов, предложенном SAG.

Первый – Открытый интерфейс доступа к БД (ODBC) был введен и продвигался компанией Microsoft. Основной целью Microsoft было использование приложениями Microsoft Windows доступа к БД, основанным на SQL, с помощью стандартизованного интерфейса «клиент-сервер» (рисунок 5).

Рисунок 5 – Архитектура ODBC

Главное назначение ODBC – это превратить SAG CLI с абстрактного обобщенного стандарта непосредственно в живую среду, где он может использоваться в приложениях на ПК.

Стандарт IDAPI сменил другой корпоративный стандарт компании Borland – ODAPI, который был частью специальной Компонентной объектной архитектуры фирмы Borland.

Стандарт IDAPI также обеспечивает поддержку серверов типа dBase (рисунок 6).

Рисунок 6 – Техническая архитектура IDAPI

1.4. Управление одновременным доступом

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