Введение в системы БД (542480), страница 202
Текст из файла (страница 202)
° Во-вторых, оптимизация в распределенных системах даже более важна, нежели в централизованных. Суть в том, что для запроса, подобного рассмотренному выше, может потребоваться обращение к нескольким узлам, В такой системе может быть много возможных способов пересылки данных, позволяющих выполнить рассматриваемый запрос. Поэтому крайне важно, чтобы была найдена эффективная стратегия. Например, запрос для, скажем, объединения отношения йх, хранимого на узле Х, и отношения Ку, хранимого на узле У, может быть выполнен посредством пересылки отношения Кх на узел 2 или отношения йу на узел Х, или обоих отношений на какой-либо узел 2 и т.п.
Неопровержимая иллюстрация важности оптимизации, включающая упомянутый выше запрос (" Получить сведения о лондонских поставщиках красных деталей"), представлена в разделе 20.4, Подводя краткий итог этого примера, можно отметить, что по вопросу обработки данного запроса анализируется шесть различных стратегий с учетом определенного набора вероятных допущений. В результате показано, что время ответа в каждом случае различно и изменяется в широких пределах от минимального (от олной до десяти секунд) до максимального (около шести часов!).
Таким образом, оптимизация, 778 Часть К Дополнительные аспекты несомненно, весьма критична для распределенной системы и, кроме того, на эту особенность можно взглянуть, как на еше одну причину, по которой распределенные системы всегда должны быть реляционными (ответ прост; реляционные системы позволяют оптимизировать обработку запросов, а не реляционные — нет).
8. Управление распределенными транзакциями Как известно, существует два главных аспекта управления транзакциями, а именно; управление восстановлением и управление параллельностью обработки. Оба этих аспекта имеют расширенную трактовку в среде распределенных систем. Чтобы разъяснить особенности этой расширенной трактовки, сначала необходимо ввести новое понятие агеит. В распределенной системе отдельная транзакция может включать в себя выполнение кода на многих узлах, в частности зто могут быть операции обновления, выполняемые на нескольких узлах. Поэтому говорят, что каждая транзакция содержит несколько агентов, где под агентом подразумевается процесс, который выполняется для данной транзакции на отдельном узле. Система должна знать, что два агента являются элементами одной и той же транзакции, например два агента, которые являются частями олной и той же транзакции, очевидно, не должны оказываться в состоянии взаимной блокировки.
Теперь обратимся непосредственно к управлению восстановлением. Чтобы обеспечить атомарность транзакции (принцип "все или ничего") в распределенной среде, система должна гарантировать, что все множество относящихся к данной транзакции агентов или зафиксировало свои результаты, или выполнило откат. Такого результата можно достичь с помощью протокола двухфазной фиксации транзакции, который уже обсуждался в главе 14, хотя это обсуждение и не было прямо связано с распределенными системами. Подробнее об использовании протокола двухфазной фиксации в распределенных системах речь пойдет в разделе 20.4.
Что касается управления параллельностью, то оно в большинстве распределенных систем базируется на механизме блокирования, точно так, как и в не распределенных системах. В нескольких более новых коммерческих продуктах была реализована многовариантная блокировка данных [15.!1. Оливка на практике обычное блокирование еще, кажется, по-прежнему остается тем методом, который выбирается в большинстве систем. Подробнее этот вопрос также будет обсуждаться в разделе 20.4.
9. Аппаратная независимость По этому вопросу фактически нечего сказать — заголовок раздела говорит сам за себя. Парк вычислительных машин современных организаций обычно включает множество разных компьютеров — машины 1ВМ, машины 1С1., машины НР, персональные компьютеры, различного рода рабочие станции и т.д. Поэтому действительно существует необходимость интегрировать данные всех этих систем и предоставить пользователю "образ единой системы". Следовательно, желательно иметь возможность запускать одну и ту же СУБД на различных аппаратных платформах и, более того, добиться, чтобы различные машины участвовали в работе распределенной системы как равноправные партнеры.
10. Независимость от операционной системы Достижение этой цели частично зависит от достижения предыдущей и также не требует дополнительного обсуждения. Очевидно, что необходима не только возможность функционирования одной и той же СУБД на различных аппаратных платформах, но и возможносп ее Глава 20. Распределенные базы данных функционирования под различными операционными системами для многих платформ— включая различные операционные системы на одном и том же оборудовании (например, чтобы версия СУБД для операционной системы МЧБ, версия для 1ЛЯХ и версия для %1пдомз НТ могли совместно использоваться в одной и той же распределенной системе). 11. Независимость от сети Здесь, опять же, нечего добавить.
Если система имеет возможность поддерживать много принципиально различных узлов, отличающихся оборудованием и операционными системами, очевидно, необходимо, чтобы она также поддерживала ряд типов различных коммуникационных сетей. 12. Независимость от типа СУБД В этом разделе мы рассмотрим, с чем приходится сталкиваться при отказе от требования строгой однородности системы. Необходимость такого сильного ограничения вызывает сомнения. Действительно, все, что необходимо, — так это то, чтобы экземпляры СУБД на различных узлах все вместе поддерживалн один и тот же интерфейс, и совсем необязательно, чтобы это были копии одной и той же версии СУБД.
Например, СУБД!пягез и Огас1е обе поддерживают официальный стандарт языка БОЬ, а значит, можно добиться, чтобы узел с СУБД 1пкгез и узел с СУБД Огас!е обменивались сообщениями между собой в контексте распределенной системы. Иными словами, распределенные системы вполне могут быть, по крайней мере в некоторой степени, неоднородны.ми. Поддержка неоднородности весьма заманчива.
На практике современное программное обеспечение обычно используется не только на многих различных компьютерах и в среде многих различных операционных систем. Оно довольно часто используется и с различными СУБД, и было бы очень хорошо, если бы различные СУБД можно было каким-то образом включить в распределенную систему. Иными словами, идеальная распределенная система должна обеспечивать независимость от СУБД.
Однако эта тема слишком обширна (и важна на практике), поэтому ниже ей посвящен отдельный раздел !см. раздел 20.6). 20.4. Проблемы распределенных систем В этом разделе подробно рассматриваются проблемы, которые упоминались в разделе 20.3. Ключевая проблема распределенных систем состоит в том, что коммуникационные сети, по крайней мере сети с "большой протяженностью*' или глобальные сети, пока являются медленнымн.
Обычная глобальная сеть чаще всего имеет среднюю скорость передачи данных от 5 до 1О тысяч байтов в секунду. Обычный же жесткий диск имеет скорость обмена данными около 5 — 1О миллионов байтов в секунду. (С другой стороны, некоторые локальные сети поддерживают скорость обмена данными того же порядка, что и лиски.) Поэтому основная задача распределенных систем — минимизировать использование сетей, т.е. минимизировать количество и объем передаваемых сообщений. Эта задача, в свою очередь, сталкивается с проблемами в нескольких дополнительных областях, Приведем список таких областей, хотя мы и не гарантируем, что он полный. ° Обработка запросов ° Управление каталогом 780 Часть р. дополнительные аспекты ° Распространение обновлений ° Управление восстановлением ° Управление параллельностью Обработка запросов Чтобы решить задачу минимизации использования сети, процесс оптимизации запросов должен быть распределенным, как и процесс выполнения запросов.
Иначе говоря, в общем случае процесс оптимизации будет содержать этап глобальной оптимизации, за которым последуют этапы локальной оптимизации на каждом задействованном узле. Например, предположим, что запрос О представлен на рассмотрение узлу Х, и предположим, что запрос О включает объединение отношения Ву, в котором сто кортежей на узле 1, с отношением Вг, в котором миллион кортежей на узле Х. Оптимизатор на узле Х должен выбрать глобальную стратегию выполнения запроса О.
В данном случае очевидно, что было бы вьподнее переслать отношение Ву на узел Х, а не отношение Вг на узел 1 (ну и, конечно же, не оба отношения Ву и Вг на узел Х). Затем, после принятия решения о пересылке отношения Ву на узел Х, реальная стратегия выполнения объединения на узле Х будет определяться локальным оптимизатором этого узла.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
