Фуфаев - Разработка и эксплуатация удалённых БД (1084483), страница 5
Текст из файла (страница 5)
В некоторых системах эта проблема решается вводом промежуточного диспетчера, и созданная таким образом система называется архитектурой с виртуальным сервером (у(пца1 зегуег). В такой архитектуре (рис. 1.9) клиенты подключаются не к реальному серверу, а к промежуточному звену, называемому диспетчером и выполняющему только функции диспетчеризации запросов к серверам. В этом случае нет ограничений на использование многопроцессорных платформ и число серверов может быть согласовано с числом процессоров в системе. Однако и такая архитектура не лишена недостатков, так как здесь в систему добавляется новый слой, размещаемый между клиентом н сервером, что увеличивает потребность в ресурсах на поддержку баланса загрузки серверов (1оад Ьа1апс(пя) и ограничивает возможности управления взаимодействием между клиентом и сервером.
Во-первых, становится невозможно направить запрос от конкретного клиента конкретному серверу; во-вторых, Рис. !.9. Архитектура с виртуальным сервером Рис. 1.1О. Многопотоковая мультисерверная архитектура серверы становятся равноправными, так как нет возможности устанавливать приоритеты для обслуживания запросов. Подобная организация взаимодействия между клиентом и сервером аналогична организации процесса обслуживания в банке, где имеются несколько окон кассиров и специальный банковский служащий — администратор зала, направляющий каждого пришедшего посетителя (клиснта) к свободному кассиру (актуальному серверу).
Данная система работает нормально, пока все посетители равноправны (имеют равные приоритеты), однако стоит появиться посетителям, которые должны обслуживаться в специальном окне, возникают проблемы. Учет приоритета клиентов особенно важен в системах оперативной обработки транзакций, однако именно эту возможность нс может предоставить архитектура систем с диспетчеризацией.
Современное решение проблемы СУБД для мультипроцессорных платформ заключается в возможности запуска нескольких серверов базы данных, в том числе и на различных процессорах. При этом каждый из серверов должен быть многопотоковым. Если эти два условия выполнены, есть основания говорить о многопотоковой архитектуре с несколькими серверами, показанной на рис. 1.10, которую также называют многонитиевой мультисерверной архитектурой.
Эта архитектура обеспечивает распараллеливание выполнения одного пользовательского запроса несколькими серверными процессами, т.е. пользовательский запрос разбивается на ряд подзапросов, которые могут выполняться параллельно, а результаты их выполнения потом объединяются в общий результат выполнения запроса. Следовательно, в этом случае для обеспечения оперативности выполнения запросов их подзапросы могут быть направлены отдельным серверным процессам, а затем полученные результаты объединены в общий результат (см.
рис. 1.10). Серверные процессы в данном случае не являются независимыми и их принято называть нитями (ггеаоз). Управление нитями множества запросов пользователей требует дополнительных расходов от 25 Стандартное ~ Горизонтальный,' Вертикальный , 'Смешанный Время Рис. 1.11. Типы параллелизма СУБД, однако при оперативной обработке информации в хранилищах данных такой подход наиболее перспективен.
Типы параллелизма. Рассматривают следующие программноаппаратные способы распараллеливания запросов: горизонтальный, вертикальный н смешанный (рис. 1.11). Горизонтальный параллелизм возникает, когда хранимая в БД информация распределяется по нескольким физическим устройствам хранения, т.е. нескольким дискам. При этом информация из одного отношения разбивается на части по горизонтали.
Горизонтальный параллелизм иногда называют распараллеливанием, или сегментированием, данных. Параллельность здесь достигается выполнением одинаковых операций, например фильтрации, над разными хранимыми физическими данными. Эти операции могут выполняться параллельно разными процессами, так как они независимы. Результат выполнения целого запроса складывается из результатов выполнения отдельных операций.
Время выполнения запроса при соответствующем сегментировании данных существенно меньше, чем время выполнения этого же запроса традиционными способами одним процессом. Вертикальныйпараллелизм достигается конвейерным выполнением операций, составляющих запрос пользователя. Такой под- Рис. 1.! 2. Схема выполнения запроса при вертикатьном параллелизме Рис. 1.13.
Схема выполнения запроса при смешанном параллелизме ход, требующий серьезного усложнения модели выполнения реляционных операций ядром СУБД, предполагает, что ядро может производить декомпозицию запроса, базируясь на его функциональных компонентах, и при этом ряд подзапросов может выполняться параллельно с минимальной связью между отдельными шагами выполнения запроса.
Действительно, рассмотрев для примера следующую последовательность операций реляционной алгебры: 1. Я5 = Я1 [А, С~1; 2. Яб = Я2 [А, В, Р); 3. Я7 = Я5 [А > 1281; 4. Я8 = Я5 [А)Я6, увидим, что первую и третью операции можно объединить и выполнить параллельно со второй операцией, а затем с полученными результатами выполнить последнюю — четвертую — операцию. Общее время выполнения подобного запроса, конечно, будет существенно меньше, чем при традиционном способе выполнения последовательности из четырех операций (рис. 1.12).
Смешанный параллелизм является гибридом горизонтального и вертикального (рис. 1.13). Все виды параллелизма применяются в приложениях, где они позволяют существенно сократить время выполнения сложных запросов из нескольких таблиц с большим объемом данных. 1.4. Основные свойства распределенных баз данных С точки зрения пользователей распределенная база данных выглядит как обычная настольная база данных, компоненты которой могут находиться на различных компьютерах (узлах) локальной сети предприятия. В идеале для распределенных баз данных должны быть характерны следующие свойства: ° локальная автономия (1оса1 аигопогпу); 27 ° независимость узлов (по гейапсе оп сепГга! я!е); ° непрерывность операций (сопйпцоца орегайоп); ° прозрачность расположения (!осабоп (пдерепдепсе); ° прозрачность фрагментации (Ггарпептабоп 1пдсрепдепсе); ° прозрачность тиражирования (герйсабоп 1пдерепдепсе); ° возможность обработки распределенных запросов (оЫпЬцгед йцегу ргосеяяпа); ° возможность обработки распределенных транзакций (дМпЬщед ггапяасйоп ргосеза1пя); ° независимость от оборудования (Ьагдваге (пдерепдспсе); ° независимость от операционных систем (орегайопя зуягет 1пдерепг)епсе); ° прозрачность сети (пепяогК 1пдерепдепсе); ° независимость от баз данных (дагаЬаяе 1пдерепдепсе).
Локальная автономия — свойство, означающее, что управление данными на каждом из узлов распределенной системы выполняется локально. База данных, расположенная на одном нз узлов, является неотьемлемым компонентом распределенной системы. Будучи фрагментом общего пространства данных, она в то же время функционирует как полноценная локальная база данных, управление которой выполняется локально и независимо от других узлов системы. Независимость узлов — свойство, означающее, что в идеальной системе все узлы равноправны и независимы, а расположенные на них базы являются равноправными поставщиками данных в общее пространство данных.
База данных на каждом из узлов самодостаточна, т.е. она включает в себя полный собственный словарь данных и полностью защищена от несанкционированного доступа. Непрерывность операций — свойство, которое можно трактовать как возможность непрерывного доступа к данным (24 ч в сутки или семь дней в неделю) в рамках РРВ независимо от их расположения и независимо от операций, выполняемых на локальных узлах. Это свойство можно выразить следующим образом: данные доступны всегда, а операции над ними выполняются непрерывно. Прозрачность расположения — свойство, означающее полную прозрачность расположения данных.
Пользователь, обращающийся к РРВ, ничего не должен знать о реальном (физическом) размещении данных в узлах информационной системы. Все операции с данными выполняются без учета их местонахождения. Транспортировка запросов к базам данных осуществляется встроенными системными средствами.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
