Ю. А. Григорьев, Г. И. Ревунков - Банки данных

13. Выбор общесистемных пакетов

Клиент

Прикладная программа

Динамический вызов метода или вызов с помощью стаба IDL

Рис. 13.13. Структура интерфейса брокера объектных запросов

чивающее внутреннее представление объектов и передачу заявок, и набор надстраиваемых компонентов, интерфейсы которых «маскируют» различия в реализации ORB. Клиенты максимально мобильны и должны работать без изменения исходного кода в среде любого ORB, который поддерживает отображение IDL в соответствующий язык программирования. Языковое отображение определяет характерные для IDL типы данных и интерфейсы доступа к объектам средствами соответствующего языка программирования.

Для определенного языкового отображения и в зависимости от ис­ пользуемого объектного адаптера обеспечивается доступ к методам, реали-

300

13.2. Варианты выбора распределенной СУБД

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

В настоящее время существует ряд промышленных реализаций ORB, соответствующих стандарту CORBA. Лидером рынка можно считать фирму lona Technologies, которая продала свое программное обеспечение более чем 10 тыс. клиентов из разных стран мира. Ее ORB Orbix существует в версиях для множества платформ, включая различные редакции Unix, Win­ dows, Macintosh, компьютеры производства Digital Equipment под управле­ нием ОС VMS и всевозможные Web-серверы.

Отличительной особенностью продукта корпорации Visigenic Soft­ ware является использование интеллектуальных программ-агентов в составе программного обеспечения ORB Visibroker. Эти агенты обнаруживают сбои серверов и автоматически переносят исполнение сервисов на исправные компьютеры в пределах локальной сети, а также выравнивают вычисли­ тельную нагрузку.

Корпорация ExperSoft предлагает «нейтральный» в отношении объ­ ектной модели и языка программирования ORB PowerBroker Corbaplus for C++ and OLE. Это одна из первых систем, поддерживающих одобренную OMG спецификацию COM/CORBA-взаимодействия. С помощью этой сис­ темы приложения, являющиеся OLE-клиентами, могут взаимодействовать с CORBA-объектами.

SunSoft возлагает надежды на Joe. В отличие от других ORB, боль­ шинство из которых написано на C++, для создания Joe использовался язык Java. Используя этот продукт, можно организовать взаимодействие Javaкомпонентов с объектами, основанными на других технологиях, в рамках интрасетей предприятий или по Internet. На рис. 13.14 представлен пример схемы обработки электронных карточек учета рабочего времени на основе объектной среды Joe (Java Object Environment).

Обработка карточки выполняется в такой последовательности (см. рис. 13.14):

1) броузер загружает активный объект Java, служащий внешним ин­ терфейсом, и клиентский компонент Joe;

2) активный объект Java получает от брокера объектных запросов де­ скрипторы объектов, представляющих сотрудника и карточку учета рабоче­ го времени.

С сервера, на котором находится представляющий сотрудника объект, поступает информация о работнике (через адаптер — объектно-ориентиро­ ванную СУБД).

Пользователь броузера вводит данные, активный объект Java проверя­ ет допустимость введенных им значений на месте. Корректные данные пе-

301

13. Выбор общесистемных пакетов

Рис. 13.14. Система обработки электронных карточек учета рабочего времени, построенной на основе объектной среды Joe

ресылаются на сервер, на котором находится объект, представляющий кар­ точку учета рабочего времени.

Программное обеспечение Joe основано на технологии NEO и входит как составная часть в интегрированную среду объектно-ориентированной разработки NEOworks. Хотя среда NEOworks способна функционировать только под управлением ОС Solaris корпорации Sun, сам ORB является пол­ ностью кроссплатформным.

Программное обеспечение ORBplus 2.0 компании HP создано в пер­ вую очередь для обеспечения интеграции между платформами Unix и Win­ dows NT. В нем реализована одновременная «прозрачная» поддержка не­ скольких транспортных протоколов, прежде всего ПОР, описанного специ­ фикацией CORBA, и DCOM корпорации Microsoft.

Различие между производителями ORB определяется также числом поддерживаемых ими языков программирования. Самый широкий выбор

302

13.2. Варианты выбора распределенной СУБД

предлагает lona: C++, Smalltalk, Ada95, Java и Visual Basic (на основе OLE). ExperSoft поддерживает C++ и Smalltalk — язык, который предпочитают переходящие к объектному программированию приверженцы языка Cobol.

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

Производители не оставляют пожелания покупателей без внимания: HP, например, запустила в разработку дополнительный комплект инстру­ ментальных средств для ORBplus под названием Wizards. Он может исполь­ зоваться непосредственно в интегрированной среде разработки Microsoft Developer Studio и обеспечивает автоматическую генерацию программного кода на C++, необходимого для работы с CORBA-приложениями и сервисами.

Спецификация CORBA описывает 13 различных сервисов, однако большинство производителей ORB поддерживают только два из них — службу именования и службу событий.

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

ORB не является самостоятельным продуктом. Он может существо­ вать только в окружении поддерживающих его платформ, специализиро­ ванных сервисов, интерфейсов и средств разработки. Корпорации Sun и IBM объявили о намерении встроить программное обеспечение ORB в свои операционные системы, что сделает доступ к этой технологии фактически бесплатным.

Контрольные вопросы

1.Охарактеризуйте проблемы выбора сетевых ОС.

2.Для чего выполняется интеграция различных сетевых ОС?

3.Опишите схему взаимодействия клиентов ОС NetWare и Windows NT Server.

4.Опишите схему взаимодействия клиентов с ОС NetWare и Unix.

5.Когда следует использовать серверы приложений?

6.Опишите процесс управления транзакциями в Taxedo System.

7.Дайте характеристику SQL3 — объектно-реляционного расширения языка SQL.

303

14. ПРОБЛЕМЫ ОБЕСПЕЧЕНИЯ ВЫСОКОЙ ПРОИЗВОДИТЕЛЬНОСТИ в СИСТЕМАХ РАСПРЕДЕЛЕННОЙ ОБРАБОТКИ ДАННЫХ

Рассматриваются факторы, влияющие на время выполнения запрос в системах распределенной обработки данных. Приведены рекомендации уменьшению времени обслуэюивания заявок ресурсами системы. Описан процесс настройки СУБД в среде Solaris.

14.1. Факторы, влияющие на время выполнения запросов

В настоящее время проблема обеспечения высокой производительно­ сти в системах распределенной обработки данных стоит достаточно остро. На рис. 14.1 представлена схема зависимости времени выполнения запросов к распределенной БД от загрузки ресурса.

Иногда ИС сравнивают со стаканом воды (см. левую часть рис. 14.1). Собственно под стаканом (оболочкой) подразумевают технические средства системы и общесистемные пакеты, которые редко меняются в действующей системе. А с водой (содержимым стакана) связывают количество рабочих станций, приложения, которые подвержены частым изменениям. При функ­ ционировании сети возрастает число станций, добавляются новые приложе­ ния (стакан наполняется). Начиная с какого-то момента, рост нагрузки на сеть превышает возможности технических средств и система начинает «пробуксовывать» (вода выливается из стакана). Справа на рис. 14.1 пред­ ставлен график зависимости времени выполнения запроса от загрузки ре­ сурса. Сначала с ростом загрузки время выполнения запроса практически не изменяется, оставаясь равным времени выполнения запроса в режиме рабо­ ты только одного пользователя (Го)- Начиная с некоторого значения загруз­ ки ресурса Ркр, временное показатели системы резко ухудшаются.

Критическими ресурсами, при увеличении загрузок которых может возникнуть перегрузка всей системы, в основном являются следующие:

•шина или канал LAN-, MANили WAN-сети;

•процессор сервера;

•жесткий диск.

Очередь к оперативной памяти (ОН), как правило, не возникает, так как многие современные ОС работают с виртуальной памятью. В этом слу­ чае очередь к ОП трансформируется в очередь к внешней памяти.

304

14.1. Факторы, влияющие на время выполнения запросов

Загрузка ресурса

Рис. 14.1. Зависимость времени выполнения запроса от загрузки ресурса

Таким образом, время выполнения запроса зависит от загрузок ресур­ сов р и времени выполнения запроса в режиме работы одного пользователя (Го). При этом важно следить, чтобы максимальная загрузка ресурсов (по всем ресурсам системы) не превышала Ркр » 0,6. В этом случае время вы­ полнения запроса будет примерно равно Го. В случае, если загрузка какоголибо ресурса превышает значение 0,6, то система начинает работать неста­ бильно. Поэтому, например, тот факт, что в критических ситуациях Token Ring сохраняет производительность на уровне 12 Мбит/с, не помогает, так как в этом случае важно снизить интенсивность поступления пакетов, чтобы выйти из зоны нестабильности (см. рис. 14.1). Необходимо отметить, что Го зависит от р: при фиксированном числе рабочих станций снижение загрузки ресурсов приводит к уменьшению и времени выполнения запроса Го. Ниже приведены рекомендации по уменьшению загрузок критических ресурсов.

Загрузка ресурса

p = ?i6,

где X — интенсивность потока заявок к ресурсу (1/с); b — время обслужи­ вания заявки ресурсом (с).

Все рекомендации по повышению производительности системы мож­ но разделить на две группы:

•рекомендации, связанные с уменьшением времени обслуживания за­ явки ресурсом (Z));

•рекомендации, направленные на снижение интенсивности потоков заявок к ресурсу (X).

305

14.Проблемы обеспечения высокой производительности

14.2.Повышение производительности системы

Рекомендации по уменьшению времени обслуживания заявок ре­ сурсами системы. Уменьшение времени обслуживания заявок ресурсами системы можно обеспечить использованием более совершенных техниче­ ских средств. Это можно достичь за счет уменьшения времени передачи данных по шине или каналу связи (рекомендуется использовать высокоско­ ростные LAN-сети (по крайней мере, для объединения высокоскоростных серверов), процессорного времени и времени обмена с жесткими дисками (например, серверы фирм Sun Microsystems и Hewlett-Packard).

Рекомендации, направленные на снижение интенсивности пото­ ков заявок к ресурсам. Эти рекомендации связаны с уменьшением нагруз­ ки X на ресурсы системы, т.е. со стремлением уменьшить «наполнение ста­ кана» (см. рис, 14.1).

1. Уменьшение интенсивности обращения к шине или каналу связи: а) основные рекомендации связаны с использованием хранимых про­

цедур и серверов приложений (рис. 14.2). Если предположить, что на вход хранимой процедуры передаются параметры первого оператора SELECT, а возвращаются результаты выполнения последнего предложения SELECT, то поток передаваемых данных уменьшается до А.1+Р3;

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

в) поток данных на сеть можно снизить и системными средствами:

•рекомендуется использовать виртуальные сети на коммутаторах;

•следует рационально выбирать размер окна передачи данных по сети (число пакетов, после передачи которых принимающая станция посылает квитанцию о результатах передачи). При размере окна Л^ = 1 трафик (число пакетов в единицу времени) удваивается. При увеличении окна до N = к

поток данных при надежной передаче уменьшается в 2к/(к + 1) раз;

•для маршрутизации пакетов следует применять новые маршрутиза­ торы (роутеры), использующие протоколы NLSP и OSPF. В старых маршру­ тизаторах применяется протокол RIP, в соответствии с которым каждый роутер посылает соседним маршрутизаторам RIP-пакеты через каждую ми­ нуту. Роутеры на базе NLSP- и OSPF-протоколов посылают технологиче­ ские пакеты при возникновении определенных событий: при включении или выключении сервера, при выходе из строя канала связи и т.д.;

•при передаче данных рекомендуется выбирать максимальный раз­ мер пакета (для Ethernet он равен 1500 байтам). Для относительно надеж­ ных каналов это позволит снизить трафик сети.

2. Уменьшение нагрузки на процессор и внешнюю память сервера. Следует отметить, что эти нагрузки часто являются взаимосвязанными — уменьшение интенсивности использования процессора приводит к сокра-

306

14.2. Повышение производительности системы

WS

Select 1

Select 2

Select 3

Wb

?^Г -Рз

Рис. 14.2. Использование хранимых процедур для уменьшения нафузки на шину:

а — хранимые процедуры не используются; б — хранимые процедуры используются; Хх + + Х,2 + А.З — поток SQL-запросов к серверу СУБД, Pi + Рг + рз

нения запросов

щению нагрузки на внешнюю память. В этом случае можно говорить о на­ грузке на сервер. Здесь можно предложить следующие решения:

а) при наличии скоростной надежной магистрали целесообразно ис­ пользовать слабо связанные кластеры серверов (рис. 14.3). Уменьшение нагрузки на сервер кластера достигается за счет того, что подзапросы (SQLоперации), получаемые в результате оптимизации запроса, выполняются на меньшем объеме данных. Конечно, в этом случае увеличивается нагрузка на шину сети, связанная с передачей подзапросов. Но влияние кластера на сеть можно устранить, выделив серверы кластера в отдельный сегмент и под­ ключив его к порту коммутатора. Кластеры не целесообразно использовать для медленных и ненадежных каналов связей (WAN-сетей);

307

14. Проблемы обеспечения высокой производительности

Внешняя память Процессор

Запрос

а

Рис. 14.3. Уменьшение нагрузки на процессор и внешнюю память при использова­ нии кластера серверов:

а — нагрузка без использования кластера; б — нагрузка с использованием кластера

б) учет особенностей выполнения SQL-операторов позволяет сущест­ венно уменьшить нагрузку на сервер. Самой ресурсоемкой операцией явля­ ется операция соединения таблиц, поэтому рекомендуется по возможности не использовать объединение таблиц (а.номер = в.номер) и вложенных под­ запросов (...IN (SELECT номер FROM ... WHERE ...)). Если такие запросы имеются, то следует убедиться, что они выполняются не очень часто;

в) по возможности следует использовать хеширование по ключу таб­ лицы. Часто в приложениях выполняют поиск по ключу таблицы (например, id = 4). При этом заранее известно, что будет найдено не более одной запи-

308

14.3. Настройка СУБД в среде Solaris

си. Если хеширование не используется, то сервер СУБД выполняет поиск с использованием индекса.

3. Уменьшение нагрузки на внешнюю память:

а) рекомендуется использовать большой кэш-буфер. Более 50 % за­ просов к данным выполняются по данным из кэш-буфера сервера СУБД. При меньшем проценте запросов следует добавить новые блоки оператив­ ной памяти и увеличить размер кэш-буфера;

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

14.3. Настройка СУБД в среде Solaris

Дисковые операции ввода/вывода

Использование асинхронного ввода/вывода. СУБД Oracle полно­ стью реализует преимущества асинхронного ввода/вывода (АЮ) и логиче­ ского управления томами (LVM) из ОС Solaris. АЮ позволяет операциям ввода/вывода перекрывать друг друга, что улучшает пропускную способ­ ность систем; LVM сокращает нагрузку на диски, распределяя данные по нескольким физическим устройствам.

В операционной системе Solaris 2 режим АЮ включен по умолчанию. Он поддерживается для файлов БД, созданных в файловой системе или на устройствах непосредственного доступа. В версиях Solaris 2.4 и 2.5 АЮ на устройствах непосредственного доступа улучшен за счет размещения части кода в ядро ОС, что сокращает непроизводительные переключения контекстов.

Асинхронный режим используется СУБД Oracle для параллельной за­ писи в БД. Этот режим включен по умолчанию (параметр файла init.ora ASYNC_WRITE=TRUE). Во время восстановления Oracle в среде Solaris использует режим асинхронного чтения файлов БД. Дополнительный выиг­ рыш во времени достигается на многопроцессорных машинах установкой параметра RECOVERY?ARALLELISM=n в файле init.ora.

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

Использование логического управления томами. Средства логиче­ ского управления томами (LVM), такие, как Online DiskSuite и Veritas Vol­ ume Manager, обеспечивают возможность распределения данных между несколькими физическими устройствами для сокращения нагрузки на дис­ ки. Обычно бывает трудно определить характеристики заранее. Таким обра­ зом, эффективно используя LVM, можно более равномерно распределить данные, что даст общее повышение производительности. Большое влияние на производительность СУБД оказывает размер областей (stripes), на кото-

309