Глава 11. Проектирование для архитектур клиент/сервер

• Почему клиент/сервер?
• Что такое архитектура клиент/сервер?
• Об аппаратных средствах
• Основные задачи проектирования для архитектур клиент/сервер
• Проектирование для архитектур клиент/сервер
• Модель рабочей нагрузки в архитектуре клиент/сервер
• Важность "тонких клиентов"
• Основы SQL*Net
• Анатомия SQL-предложения
• Появляется промежуточное звено
• Приемы проектирования для архитектур/клиент/сервер
• Кэширование неизменяемых данных на клиенте
• Клиент/сервер и распределенные базы данных
• Появление базы данных второго уровня
• Сокращение сетевого трафика с помощью представлений
• Оптимизация представлений
• Проверка данных в среде клиент/сервер
• Который час?

Архитектура клиент/сервер в последние пять-шесть лет является одной из самых популярных тем. В мире Oracle многие ранние приложения клиент/сервер работали прямо-таки катастрофически плохо — одно внутреннее Oracle-приложение давало ответ на тривиальнейший запрос через три минуты. Оно просуществовало в рабочем состоянии всего около трех часов и было отправлено "на свалку". Многие из тех, кто участвовал в разработке этого приложения, до сих пор работают в корпорации Oracle, но предпочитают об этом не вспоминать — это факт просто стерли из корпоративного знания. Большинство причин, приведших к этой катастрофе, устранены благодаря усовершенствованию аппаратных средств и нововведениям в последних версиях ПО, но некоторые из ключевых причин существуют до сих пор. В этой главе мы не раз будем упоминать это неудачное приложение, чтобы напомнить вам, как важно для проектировщиков учитывать особенности среды клиент/сервер.

Когда Microsoft Windows 3.1 стала доминирующей настольной операционной системой, широкое распространение получили привлекательные, удобные в работе персональные приложения, например текстовые процессоры и электронные таблицы. Диапазон средств подготовки документов быстро расширился, в нем появились как средства DTP, так и пакеты создания презентаций. Интерфейсы на базе командной строки, которые продолжали использовать для доступа к приложениям, работающим на корпоративных серверах и серверах подразделений, стали выглядеть менее привлекательно, чем интерфейсы настольных приложений. Кроме того, во многих случаях такие серверы были катастрофически перегружены. Сервер не только нес большую нагрузку, связанную с базой данных, — часто каждое нажатие клавиши на подключенном к нему терминале вызывало прерывание центрального процессора, необходимое для обработки операции ввода-вывода и отображения введенного символа на экране.

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

Поскольку связь между клиентами и серверами осуществляется с помощью сообщений, клиентская программа и сервис могут работать на разных машинах. Кроме того, поскольку клиентская программа "знает" сервис только по имени, она не осведомлена о местоположении сервера, предоставляющего данный сервис. Все это реализуется благодаря целому ряду уровней программного обеспечения. Естественно, где-то в глубине машины что-то должно знать, где на самом деле находится нужный сервис. В среде Oracle SQL*Net версии 2 эта информация обычно находится в файле с именем msnames.ora.

Рис. 11.1. Схема вложенной архитектуры клиент/сервер

Все эти положения описывают инкапсуляцию, которая является одним из ключей к успешному проектированию вообще и необходимым условием хорошей работы любого приложения, построенного на клиент-серверных методах. Обработка сообщений, используемая в архитектуре клиент/сервер, знакома каждому, кто работал с Web-броузерами Netscape Navigator или Microsoft Internet Explorer (это приложения клиент/сервер, применяющие протокол HTTP). Web-броузеры также иллюстрируют ту мощь, которую дает возможность работать с несколькими серверами. В более традиционных приложениях клиент/сервер, особенно в тех, которые пользуются инструментальными средствами и серверами БД Oracle, наблюдается тенденция к соединению каждого клиента с одним и только одним сервером.

В системах клиент/сервер конца 80-х, начала и середины 90-х годов обычно использовалась довольно мощная рабочая станция, на которой работало ПО на базе оконного интерфейса и которая взаимодействовала с сервером, реализованным на миникомпьютере среднего класса. Первоначально это были Unix-станции с ПО Motif, а сейчас это чаще всего ПК на элементной базе Intel с операционной системой MS Windows 3.х или MS Windows 95. В настоящее время в качестве клиентской операционной системы все чаще используется Windows NT Workstation. Мы наблюдаем также более активное внедрение Web-технологии, делающей природу клиентского устройства невидимой — не только для сервера, но, при наличии языков вроде Java, и для разработчика кода, предназначенного для работы на этом клиенте.

Во многих ранних реализациях модели клиент/сервер сервером была большая ЭВМ VAX фирмы Digital с операционной системой VMS. Сегодня сервер в большинстве случаев представляет собой Unix-систему (как правило, с ОС SVR4 и процессором SPARC, Alpha, Intel или PowerPC) с высоким MIPS-показателем и большими объемами внешней (дисковой) памяти. Все чаще в этой роли выступает и ОС Windows NT Server. Чем новее сервер, тем вероятнее, что он будет иметь несколько центральных процессоров и поддерживать несколько гигабайтов оперативной памяти. Многие из первых серверов были существенно ограничены как в мощности процессоров, так и в объемах оперативной памяти.

И клиент, и сервер подключаются к локальной сети, которая используется как магистраль для передачи сообщений. В некоторых случаях клиент и сервер находятся в одной ЛВС, но чаще они общаются через интрасеть — ограниченную совокупность связанных сетей. Доминирующей технологией в Oracle-системах клиент/сервер является Ethernet, но встречаются и кольцевые сети с маркерным доступом. Клиент и сервер могут использовать любой из множества коммуникационных протоколов, включая вездесущий TCP/IP. Благодаря программам многопротокольного обмена Oracle, клиент и сервер могут пользоваться разными протоколами, при этом ПО обмена предоставляет услуги по преобразованию. В настоящее время лишь ограниченное число приложений по-настоящему работают по Internet — говоря простым языком, по неограниченной совокупности связанных сетей, пользующихся общими протоколами. По мере перехода к Internet появляются клиентские устройства, подключенные по коммутируемым линиям, часто с очень маленькой полосой пропускания.

Такая сильная зависимость от технологии локальных сетей стала проблемой для многих организаций, которым требуется обеспечить поддержку удаленных пользователей, входящих в систему из дома или с клиентского узла. Часто в этих организациях разрабатывали два комплекта приложений, выполняющих одни и те же базовые задачи. Один набор приложений поддерживал интерактивных пользователей, которые подключались непосредственно к ЛВС. Второй набор мог включать высокоуровневый протокол выгрузки-загрузки, обеспечивающий обмен информацией между клиентом и сервером за относительно короткий сеанс и позволяющий пользователям работать в значительной степени автономно. Все было бы намного проще, если бы удаленных пользователей можно было рассматривать как локальных. Поскольку SQL*Net поддерживает много протоколов, включая WinSock, то существует потенциальная возможность работать, скажем, с Oracle Forms no коммутируемой линии. Проблема в том, что быстродействие линии и задержки при передаче сообщений часто делали это приложение неработоспособным. С появлением более скоростных модемов и технологий (например ISDN) ситуация несколько улучшилась, но, тем не менее, ее всегда следует учитывать при проектировании — приложение должно обеспечивать приемлемую скорость работы по самому медленнодействующему из поддерживаемых им каналов.

Решение проблемы, связанной с операциями обмена, состоит в том, чтобы свести число запросов к минимуму или, что более правильно, составить сложные запросы типа: "Сделать А, сделать В, сделать С, а затем передать мне ответ". Использование хранимых процедур PL/SQL в базе данных позволяет упростить реализацию запросов этого вида средствами Oracle. Что же касается Web-броузеров, то, скорее всего, здесь все зависит от способа доставки ответа сервером.

Нам постоянно приходится слышать, как руководители и технические специалисты говорят о быстродействии или пропускной способности сети как о критическом факторе для систем клиент/сервер. Это не всегда так. При использовании SQL*Net большинство сообщений между клиентом и сервером довольно короткие (десятки или сотни байтов, а не тысячи и миллионы). Поэтому скорость, с которой сеть может передать файл объемом 1 Мбайт, практически не имеет значения — может быть, поэтому поставщики сетей так любят указывать ее! Ключевыми статистическими данными являются время ответа и максимальная скорость передачи пакетов сервером. Время ответа в большинстве TCP/IP-сетей можно измерить с помощью команды ping имя_хоста (или ping -s имя_хоста, если ping просто сообщает о том, что данный хост работает). Это время находится в диапазоне от 1 мс (если клиент и сервер находятся в одной локальной сети) до 400 мс (когда используется мост Х.25). Максимальная скорость передачи пакетов обычно колеблется в пределах от 1000 до 2000 пакетов в секунду, что является абсолютным аппаратным пределом для сетевой интерфейсной платы.

Наша цель как проектировщиков приложений клиент/сервер проста и привлекательна — спроектировать систему так, чтобы и клиент, и сервер выполняли задачи, в которых они сильны (и, следовательно, были освобождены от задач, которые им даются трудно). Клиент обычно качественно обеспечивает работу прикладного интерфейса, а сервер хорошо выполняет обработку совместно используемых данных. Очевидное решение состоит в следующем — реализовать на клиенте прикладной интерфейс, а на сервере (серверах) выполнять все операции над совместно используемыми данными. Чтобы число пакетов было минимальным, запросы к совместно используемым данным объединяются, и многие из них выполняются за один проход. Звучит это очень просто, но в действительности все гораздо сложнее.

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

Рис. 11.2. Типы вычислений клиент/сервер

Эта модель распределения рабочей нагрузки оказалась полезной, и ее можно распространить на трехуровневые архитектуры, но она не дает возможности увидеть общую ошибку, которая заключается в попытке распределить все функции — представления данных, логики и управления данными — между клиентом и сервером. Чем жестче вы примените инкапсуляцию к своей схеме, тем меньше вероятность того, что маленькие фрагменты логики управления представлением окажутся глубоко запрятанными в коде управления данными (во многих случаях и довольно большие сегменты задачи управления данными оказываются закодированными непосредственно в уровне представления). В противном случае вы получите сложный, очень "чувствительный" к изменениям прикладной код, который часто невозможно сопровождать с какой-либо степенью надежности. К сожалению, такой стиль очень распространен в проектах на базе Oracle. В значительной степени это является наследием SQL*Forms версий 2 и 3, способствующих созданию так называемых ключевых триггеров (для управления представлением или интерфейсами), которые свободно могли содержать SQL-предложения и вызовы процедур базы данных.

Поскольку возможности SQL*Forms версии 2 в плане трансформации данных были ограничены, программисты также сочли необходимым встраивать правила форматирования в код управления данными (на SQL). Эта практика все еще преобладает сегодня в триггерах Oracle Forms, и они содержат, например, такие предложения:

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

Кроме того, на рис. 11.2 не отражены n-уровневые архитектуры. В этих архитектурах уровни управления приложениями, содержащие прикладную логику, находятся между клиентом и сервером данных.

О различиях между интерфейсом и процессом мы поговорим в главе 16. Наш подход к вычислениям клиент/сервер полностью соответствует изложенной там концепции. В приложении клиент/сервер на базе Oracle нам следует стремиться к чему-то среднему между распределенной логикой и удаленным представлением данных (см. рис. 11.2) и попытаться добиться, чтобы клиент решал только непосредственно относящиеся к пользовательскому интерфейсу задачи, а сервер — все остальные, включая всю обработку запросов и обновлений, а также внедрение правил обработки данных и бизнес-правил.

Ясно, что клиент "сведущ" в управлении представлением данных пользователю, будь то данные в графической форме, электронная таблица или экран на базе форм. Клиент обрабатывает все события, связанные с клавиатурой и мышью, рисует изображение экранной формы и позволяет манипулировать объектами, представленными на экране, и перемещаться по ним, Конечно, вы не захотите, чтобы клиентское ПО запрашивало с сервера массу необработанных данных (например, целые таблицы), а затем отбирало нужные вам данные. Это не только приведет к увеличению графика в сети, но и значительно увеличит нагрузку на сервер. Тем не менее, мы встречали многих проектировщиков с иррациональной верой в то, что данные можно извлекать из базы данных и передавать по сети, не создавая сколько-нибудь значительной нагрузки на сервер.

Сервер БД Oracle оптимизирован для селективной выборки, т.е. для выполнения реляционных операций, таких как фильтрация, проецирование и соединение, над большими объемами данных. Серверное ПО рассчитано на прием запросов, их обработку и возвращение статуса и (или) данных за минимальное время.

Не нужно, чтобы сервер решал такие задачи, как рисование экранных изображений и выполнение программ повышения производительности клиента. Никто, находясь в здравом уме, не порекомендовал бы такой подход. Однако просто удивительно, как много мы встречали организаций, где все клиентское ПО содержат на совместно используемом диске сервера. Почему? Потому что это облегчает распространение ПО и гарантирует, что все клиенты используют одну и ту же версию. Клиентское ПО обычно состоит из ядра, выполняющего базовые функции (оно реализовано в исполняемом файле), и набора подпрограмм в библиотеках связей (в Microsoft Windows они называются динамически загружаемыми библиотеками, или DLL). Если при обращении к подпрограмме DLL не находится в памяти, приходится загружать с сервера довольно большой двоичный файл. Это может происходить регулярно, если на клиенте недостаточно памяти.

Здесь мы говорим о том, что проблема с подгрузкой исполняемых файлов характерна для ПК, однако необходимо признать, что именно в этом направлении движется компьютерная индустрия. Сначала это движение стимулировала World Wide Web, а теперь — поддержка, которую Oracle оказывает концепции сетевого компьютера.

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

Высокоуровневый протокол, с которым работает SQL*Net, очень прост. По сути дела, клиент передает SQL-предложения или анонимные блоки PL/SQL на сервер для выполнения, сервер обрабатывает их и посылает данные обратно клиенту. Если предложением является SELECT, то возвращаются строки (в ответ на команду FETCH, посланную клиентом). Для DML-операторов и блоков PL/SQL возвращаемые данные представляют собой код завершения оператора и выходные параметры, если они есть. Это показано на рис. 11.3.

В Oracle полная архитектура клиент/сервер реализована начиная с версии 5, и эта архитектура используется даже в случае, если клиент и сервер находятся на одной машине. Как правило, Oracle применяет двухзадачную архитектуру, в которой клиент и сервер представляют собой два отдельных процесса (даже если они расположены на одной машине). На некоторых платформах их можно объединить в один процесс, хотя обычно это не рекомендуется из-за того, что прикладная программа может повредить SGA и, следовательно, саму базу данных. Многие операционные системы, включая MVS разработки IBM и VMS разработки Digital, допускают использование привилегированных библиотек. При их наличии приложение может вызвать библиотечную программу, например сервер БД, которая обладает привилегией просматривать SGA, даже несмотря на то, что вызывающая программа этого права не имеет. Отметим, что при оперативной обработке транзакций однозадачная архитектура Oracle во многих случаях работает приблизительно на 20% быстрее, чем двухзадачная, благодаря существенному сокращению числа переключений контекста в операционной системе.

В Oracle7 разработчики корпорации сделали ряд важных шагов для повышения эффективности своей архитектуры клиент/сервер. Во многих случаях число сетевых пар (сообщений от клиента к серверу и обратно) необходимое для выполнения одного оператора, сокращено с четырех до одной.

Чтобы понять, какое влияние оказывают наши приложения на сетевой трафик, необходимо изучить механизм обработки SQL-предложений в базе данных Oracle.

Рассмотрим следующее предложение SELECT:

Процесс обработки этого простого предложения можно разбить на пять этапов: разбор, определение, привязка, выполнение, выборка. Если не используются средства отложенных вызовов Oracle, то для выполнения каждого этапа требуется минимум одна пара сетевых сообщений. Например, для выполнения этапа разбора клиент обычно посылает текст предложения на сервер, а сервер отвечает кодом статуса, сигнализирующим об успехе или неудаче. (Этапы, перечисленные в этом разделе, должны быть хорошо знакомы всем, кто программировал с помощью Oracle Call Interface (OCI), где их приходится программировать явно.)

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

Что же понимать под промежуточным ПО в контексте нашей главной темы — проектирование баз данных? В архитектуре клиент/сервер мы рассматривали внешнее приложение (клиент), которое инициирует выполнение SQL и PL/SQL в базе данных (на сервере). Промежуточное ПО — это слой программного обеспечения, находящийся между клиентом и сервером. Оно может располагаться на компьютере-сервере, компьютере-клиенте или на отдельной машине. Для повышения пропускной способности в нем может использоваться менеджер транзакций, такой как Tuxedo или CICS-система.

Одно из главных обоснований существования промежуточного ПО — обеспечение независимости внешнего приложения от базы данных. В этом случае клиент может использовать собственный язык высокого уровня или протокол для взаимодействия с промежуточным ПО. Ему будет совершенно безразлично, куда передает информацию это промежуточное ПО — в базу данных Oracle или в базу данных Sybase. Если же такое ПО генерирует SQL, строго соответствующий стандарту ANSI-92, то становится простой замена одной СУБД на другую. Даже если такая совместимость с базами данных других производителей не требуется, промежуточное ПО может оградить клиентское ПО от влияния изменений, вносимых в структуру базы данных на сервере. Другими словами, здесь мы имеем еще один способ инкапсуляции.

Это демонстрирует простой пример на рис. 11.4. Промежуточное ПО принимает высокоуровневый вызов от клиента через интерфейс прикладного программирования (API) и конвертирует его в SQL-предложение. В этом простом примере промежуточному ПО не нужно конвертировать возвращаемые с сервера данные — оно просто передает их клиенту. Промежуточное ПО должно обладать значительным интеллектом или иметь исключительно сложный преобразующий уровень, предназначенный для конвертирования вызовов в SQL.

Одним из относительно дешевых и простых вариантов реализации решения с промежуточным ПО является использование на клиенте только вызовов хранимых процедур и функций и разработка библиотеки или пакета процедур либо функций для обслуживания всех запросов приложения. Иногда это решение реализуют частично и сохраняют в клиентском приложении все предложения SELECT, которые могут возвращать несколько строк. В версии 7.2 появилась возможность передавать курсоры между приложениями, что позволяет достаточно изящным способом послать "многострочные" предложения SELECT для выполнения на сервер и передать результаты обратно. В версии 7.3 и в PL/SQL версии 2.3 поддержка этих функциональных возможностей значительно усовершенствована. Помимо сокращения сетевых затрат, этот подход к проектированию позволяет использовать разделяемые курсоры и уменьшить затраты на синтаксический анализ.

Преимущество промежуточного ПО — способность избежать зависимости от базы данных для наших приложений, однако каковы при этом затраты и риски? Конечно, с появлением нового уровня, который может быть потенциальным источником проблем, становится более сложной диагностика. Может пострадать и производительность, поскольку промежуточное ПО должно обслуживать запросы индивидуально и многозадачную работу может не обеспечить. В результате запросы могут попадать в очередь и ждать освобождения промежуточного ПО. Эти риски можно уменьшить с помощью менеджера транзакций, управляющего промежуточным ПО.

Один из побочных эффектов от использования промежуточного ПО, который может вызвать проблемы с производительностью, касается применения подсказок в предложениях SQL. Во-первых, некоторые драйверы ODBC "рационализируют" SQL, вырезая комментарии перед направлением предложений на сервер. Но ведь в комментариях содержатся подсказки для оптимизатора по стоимости в Огас1е7. Во-вторых, драйверы ODBC часто переформатируют SQL, и при этом могут быть исключены другие использованные методы настройки. И кроме того, иногда приложение на клиенте обладает сведениями об объеме или содержимом ожидаемых данных, которые нельзя просто так передать промежуточному ПО или конвертировать с его помощью. Вследствие этого возникает мысль о написании промежуточных программных компонентов для конкретных приложений, а это противоречит концепции промежуточного ПО. Очень разумным подходом является ввод уровня прикладной логики, который изолирует управление интерфейсом на клиенте от управления данными на сервере базы данных.

Однако наличие такого среднего уровня означает, что мы уже перешли от простой архитектуры клиент/сервер к трехуровневой архитектуре. Эта архитектура обладает значительными теоретическими преимуществами, но инструментальные средства Oracle поддерживают ее плохо. Кроме того, она не очень популярна в сообществе пользователей Oracle, несмотря на то, что архитектура сетевых вычислений Oracle должна обеспечивать непосредственную поддержку трехуровневой обработки. (Эта тема также обсуждается в главе 16.)

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

Ясно, что для этой совершенно ненужной пересылки данных мы задействуем ресурсы сети и центрального процессора сервера. Очевидное решение — извлечь эти данные при первом обращении к ним пользовательского интерфейса, а затем хранить их на клиенте для обслуживания последующих запросов. Если объем этих данных невелик, то клиентское ПО может направлять запрос на их получение при запуске приложения на клиенте. Таким образом, программа пользовательского интерфейса всегда может рассчитывать на их наличие. Реализация этого механизма зависит от клиентского ПО. Например, в приложении на Visual C++ можно выделять память динамически и хранить эти данные в связанных списках. В Oracle Forms 4.5 для хранения кэшированных значений можно пользоваться группами записей.

Давайте в качестве примера рассмотрим таблицу, содержащую описание деталей. Может оказаться, что из перечисленных в ней 100000 деталей один клиент часто выбирает лишь 100. Если описания деталей в процессе обработки системой клиент/сервер никогда не изменяются (или допускается использование устаревшего описания), то можно реализовать на клиенте механизм движущегося кэша (rolling cache), или исключения давно использовавшихся данных (least recently used).

Этот механизм работает так. Каждый запрос сначала проверяется на предмет того, есть ли данные в кэше. Если данные есть, то они извлекаются из кэша. В противном случае данные передаются с сервера, добавляются в кэш, а затем их получает программа интерфейса. Таким образом, данные вызвавшей программе всегда передаются из кэша, а не прямо с сервера. Каждый элемент данных (в примере — описание детали) выбирается в клиентском сеансе только один раз. К сожалению, если длительность этого сеанса очень велика, то кэш не только может устареть, но и значительно увеличиться в объеме. Однако эти проблемы можно решить, если у вас есть время и энергия на проектирование и создание подходящего решения.

Более серьезная задача — обеспечение непротиворечивости данных кэша. Ее можно попытаться решить, применив автоматическое удаление кэшированных элементов по истечении заданного временного промежутка (например, 30 минут) либо при помощи триггера на сервере, который будет заносить дату и время последнего изменения в базовой таблице. Клиентская программа может периодически проверять это производное поле и делать соответствующий кэш недействительным, если данные на сервере с момента начала загрузки кэша изменились. Если клиентская операционная система поддерживает удаленные запросы (RPC), то сервер может автоматически делать кэш недействительным, когда вносится изменение. Однако это решение очень сложное в техническом плане и может вызвать значительные проблемы с производительностью, если число клиентов очень велико или если в кэшированные объекты часто вносятся изменения.

Самая серьезная проблема при любом виде кэша — простом или сложном — заключается в том, что если отсутствует промежуточное ПО, "скрывающее" кэш, то программа пользовательского интерфейса должна знать о существовании кэша и уметь запрашивать из него данные. Таким образом, независимо от того, используется промежуточное ПО или нет, выборка данных, которые могут быть локально кэшированы, не должна осуществляться через SQL, за исключением случая, когда на клиенте работает экземпляр базы данных — однако при этом мы уже имеем дело не только с архитектурой клиент-сервер, а еще и с распределенной базой данных. (Эта тема изложена здесь с точки зрения вычислений клиент/сервер. Более подробно распределение данных рассматривается в главе 12.)

Кэши приложений дают наибольшую выгоду в тех приложениях клиент/сервер, где задействуется глобальная сеть. При этом методе также экономятся ресурсы центрального процессора, даже если и клиент, и сервер работают на одной машине. Однако если ожидается большой объем кэша и сложный алгоритм управления им, то мы рекомендуем рассмотреть альтернативные проектные решения; они могут предполагать наличие распределенной базы данных. Помимо всего прочего, рассматриваемый нами кэш является, по сути, созданной в рамках проекта резидентной базой данных, а Oracle уже затратила массу времени и денег на реализацию серверного кода для сервера базы данных. Сервер Oracle, несмотря на потенциально огромную потребность в памяти и административном внимании, все же работает, тогда как очень сложный администратор кэшей, созданный в рамках проекта, может и не работать.

К тому же, очень немногие ориентированные на базы данных клиентские средства сильны в файловом вводе-выводе. Необходимо подумать и том, как достичь приемлемой производительности при обработке запросов. Допустим, что при необходимости хранить важные данные локально, мы будем хранить их в базе данных (либо Oracle, либо не-Oracle). Кроме того, предположим, что локальная база данных представляет собой версию Oracle, которая либо поддерживает Distributed Database Option, либо способна работать с этой опцией. Это очень важно, поскольку очень немногие разработчики умеют хорошо обращаться с несколькими одновременно открытыми соединениями с базой данных. Кроме того, насколько мы знаем, только немногие широко используемые средства ускоренной разработки приложений (УРП) обеспечивают полную поддержку открытия одновременно нескольких соединений с базой данных. Как правило, множественные соединения поддерживаются только из языков третьего поколения (и, как ни странно, с помощью редко используемой команды COPY из SQL*Plus).

Если у нас есть и локальная, и удаленная базы данных и мы должны работать только с одним соединением, то должны соединяться с локальной базой данных, потому что это — единственный путь, которым мы можем добраться до нее без создания графика сообщений. Ведь мы пытаемся уменьшить трафик сообщений. Таким образом, для каждого пользователя его экземпляр локальной базы данных становится пунктом управления всей его работой. Из этого следует, что любая попытка обеспечить прозрачность расположения может вызвать (и, вероятно, вызовет) появление сетевых соединений (cross-network joins) и распределенных транзакций, требующих использования двухфазной фиксации (описанной в главе 12).

Хотя в каждом последующем выпуске Oracle7 производительность сетевых соединений улучшалась, мы не советуем слепо верить в то, что эти соединения будут оптимизированы, как планировалось. Рекомендуем также точно оценить уровень оптимизации в версии (версиях), которая у вас работает. Если же имеется не-0гас1е-сервер с доступом через шлюзовые продукты, то необходимо еще более тщательное исследование.

Самый крайний случай, с которым мы встречались, — когда приложение Microsoft Access соединяло локальную таблицу Access с таблицей Oracle на удаленном сервере. Оказалось, что вся таблица Oracle пересылалась на клиент, где выполнялось соединение, несмотря на то, что SQL-предложение содержало условие, по которому сервер возвращал всего одну строку.

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

Давайте рассмотрим проблему графика сообщений. Допустим, у нас есть приложение, отображающее сетку (иногда называемую многострочным блоком) заказов. В таблице ORDERS есть столбец CUS_ID, который содержит уникальный идентификатор покупателя, разместившего заказ. Нашему приложению нужно отобразить имя покупателя, которое должно быть выбрано из таблицы CUSTOMERS. Предположим, что это приложение предстоит разрабатывать в Oracle Forms 4.0/4.5.

Поскольку Customer Name не является столбцом таблицы ORDERS, нам потребуется написать (или сгенерировать) код для управления этим полем. Нам нужно указать имя покупателя, когда мы отображаем заказ, и, возможно, представить в этом поле список значений, чтобы при создании нового заказа пользователь мог выбрать покупателя из списка.

Вероятно, первое, что приходит вам в голову (особенно если вы такой же старый Forms-хакер, как мы), — это мысль реализовать эти функциональные возможности как триггер POST-QUERY:

При этом производится простой и высокоэффективный индексный поиск, однако он осуществляется один раз для каждой отображаемой в форме строки. Таким образом, в этом простом случае придется выполнять одну дополнительную операцию обмена сообщениями с сервером на каждую строку многострочной формы лишь для того, чтобы получить имя покупателя. Последствия этого гораздо серьезнее, чем может показаться на первый взгляд, поскольку в Oracle Forms интенсивно используется массивная выборка, позволяющая выбрать все строки для заполнения формы за одно обращение. Таким образом, если в форме необходимо отобразить 10 строк, то наш простой триггер может увеличить трафик сообщений с одной пары сообщений до одиннадцати.

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

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

Во всех версиях Oracle до 7.3 представления, которые содержат соединения, не могут быть объектом DML-операций. Это означает, что операции INSERT, UPDATE и DELETE для них не разрешаются. Версия 7.3 поддерживает обновляемые представления, хотя, как следует ожидать, и здесь существует ряд ограничений. В любом представлении обновляемые столбцы должны принадлежать одной таблице, и эта таблица должна быть защищена по ключу (key preserved). В самом простом случае это означает, что ключ (ключи), по которому выполняется соединение, обновлять нельзя.

Пока вы не станете работать с версией 7.3 (или более новой), вам придется программировать или генерировать триггеры ON-INSERT, ON-UPDATE и ON-DELETE в экранной форме для того, чтобы выполнить обновление через блок, построенный на представлении, содержащем соединение, или фактически на любом необновляемом представлении. Эти триггеры, которые, как правило, создать очень легко, просто явно выдают DML-операции для базовых таблиц представления. В нашем примере это почти наверняка будет таблица ORDERS, так как совершенно невероятно, что мы будем использовать многострочный блок на базе таблицы ORDERS для корректировки имен покупателей.

Вопросы оптимизации выполнения запросов более проблематичны. Для большинства сложных многострочных блоков должен выполняться поиск не в одной таблице, а в нескольких. Часто бывает, что внешний ключ допускает неопределенные значения (т.е. эта связь не обязательна), поэтому в таком представлении должно осуществляться внешнее соединение. Первоначальная реакция как разработчика, так и пользователя на блоки, построенные на представлении, почти всегда положительна. Это объясняется тем, что они могут использовать любое из полей как основу для запроса и это устраняет традиционные проблемы, связанные с "запросами к небазовым таблицам". К сожалению, хотя это решение богато функциональными возможностями и создает минимальный трафик сообщений, оно может серьезно увеличить нагрузку на сервер и время ответа.

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

Соединение по схеме "звезда " называется так потому, что для него очевидна аналогия с соответствующей топологией локальной сети. В следующем примере приводится запрос к представлению V_ORDERS, в котором используется такое соединение.

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

Шаги 1, 2 и 3 — это соединение по схеме "звезда", а версии до 7.3 выдают неудачные планы выполнения запросов, использующих такое соединение. К сожалению, не особенно помогают в этом случае даже подсказки. Причин этому две. Во-первых, механизмы выполнения запросов в ранних редакциях располагают нормальной стратегией для реализации подсказки. Во-вторых, в большинстве Forms-приложений трудно предсказать, какие из допустимых аргументов будут указаны (потому что они вводятся как критерии запроса), а от этого зависит план. Например, нельзя использовать ту же последовательность табличных ссылок, если заданы два наименования валют и имя покупателя (а не Sales Office). При отсутствии поддержки для соединений по схеме "звезда" в механизме выполнения запросов самый лучший подход к такому соединению — кодировать его при помощи процедур.

Проблема с внешними соединениями состоит в том, что оптимизатор запросов Oracle никогда не выдаст план запроса, который выполняется "неверно" по внешнему соединению. Это имеет место даже в случае, если имеется условие, показывающее, что для выбираемых данных не нужно создавать внешнее соединение вообще. Следовательно, наличие внешних соединений в этом примере означает, что запросы с соединением по схеме "звезда" фактически использовать нельзя. Поэтому порядок соединения будет таким:

Если реализовать процедурное решение на клиенте, то этим мы увеличим трафик сообщений — а ведь главным мотивом построения блока на представлении было снижение числа сообщений в сети. Если построить блок на представлении, но при этом предотвратить использование этого представления, добавив триггеры ON-SELECT, ON-FETCH и ON-LOCK, вызывающие процедуры PL/SQL на стороне сервера, то таким образом мы полностью инкапсулируем логику запросов на сервере. При этом число пар сообщений будет таким: одна — для инициирования обработки и одна — на каждую строку. Этот метод подходит для блока, содержащего одну строку. Если же речь идет о многострочном блоке, то, чем больше строк нужно в нем заполнить, тем менее приемлемым он становится. Однако этот метод все равно обеспечивает значительное сокращение числа сообщений по сравнению с другим вариантом, который заключается в поиске с помощью нескольких триггеров уровня поля. Кроме того, он позволяет справиться со сложностью запросов к небазовым таблицам силами логики на стороне сервера, а не на стороне клиента.

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

Нам известен один проект, в котором проектировщики собираются уменьшить трафик сообщений, заставив функцию FETCH_ROW возвращать несколько строк таблицы. Это делается за счет того, что каждая переданная обратно переменная будет содержать список значений, упакованный в одну строку. Для этого потребуется создать дополнительный код и на стороне сервера, и на стороне клиента. Хотя этот метод недостаточно изящен и потребляет много ресурсов центрального процессора, он все же может сократить число операций обмена до того же уровня, что и представления (до одной для заполнения экранной формы).

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

Функция check_credit вызывается дважды — сначала явно из экранной формы для обеспечения немедленной обратной связи в, процессе ввода данных, а затем неявно триггером, когда в таблице выполняется вставка или обновление.

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

Рис. 11.6. Пример дублирования проверки на клиенте и сервере

Важно, чтобы у вас был набор стандартов на разработку ГПИ, четко определяющих подход к проверке в масштабах всего приложения. Экранные формы, которые разработаны в Oracle Forms версии 3 или более старой, а затем конвертированы с помощью какого-либо инструмента, все равно склонны вести себя, как программа, написанная в Oracle Forms версии 3, хотя и выглядят, как ГПИ. В них продолжает выполняться обширная проверка навигационных событий. Такие конвертированные экранные формы, как правило, плохо сочетаются с формами, которые "с нуля" разработаны в Oracle Forms версии 4.5, и весьма вероятно, что их придется переписывать; Привлекательно выглядит еще одна идея (особенно для отделов маркетинга фирм-поставщиков приложений): иметь один и тот же исходный код как для текстовых, так и для ГПИ-версий одного приложения. Но мы считаем эту идею несбыточной — из-за компромиссов, которые она предполагает.

Время — это еще одна проблема в приложениях клиент/сервер. От большинства проектировщиков требуют (по крайней мере, они так думают) чтобы на клиенте можно было работать с текущими датой и временем. Во всех средах, за исключением распределенных вычислительных сред, у каждого клиента и каждого сервера есть свои системные часы, и эти часы выдают широкий диапазон несогласованных значений времени. Какое из них должно использовать приложение? Неразбериха возникает и потому, что один и тот же момент времени в разных часовых поясах представлен разным значением.

Если вы просто хотите снабдить меткой даты или времени новую или обновленную строку, то можно отправить на сервер SQL-предложение с псевдостолбцом, содержащим SYSDATE для определения даты. SYSDATE будет вычислена, и для строки будет применена дата и время сервера. Этот метод хорошо работает для установки меток времени и приемлем для подавляющего большинства приложений. Вот пример SQL-предложения такого типа:

Однако предположим, что от приложения требуется, чтобы пользователь видел метку времени на записи перед тем, как решать, фиксировать запись или нет. Теперь появляется выбор — приложение может запросить дату и время с сервера или воспользоваться локальными часами клиента. Причем результат в данном случае будет зависеть от того, какое средство применялось при его создании. Многие пользователи удивляются, обнаружив, что, когда локальная процедура на PL/SQL, работающая в приложении, созданном в Oracle Forms, обращается к SYSDATE, это приводит к вызову сервера для выборки текущего значения. Единственный путь обратиться к локальным часам — по умолчанию использовать для элементов Forms $$DATE$$ или $$EDATETIME$$.

Во многих клиентских инструментальных средствах предусмотрен вызов, позволяющий получить текущее время из часов клиента (например, в Visual Basic есть функция Now).

Принимая решение о том, откуда брать время, обязательно учтите, что делает приложение и для чего нужно время. Рекомендуем во всех случаях, когда время необходимо передавать в базу данных, использовать серверное время. Если база данных является распределенной, следует брать время с самого центрального сервера. Общее правило (имеющее к архитектуре клиент/сервер отдаленное отношение) звучит так: любая процедура, в которой используется время, должна получать его один и только один раз, чтобы передавать одно и то же время. Вряд ли вы обрадуетесь, когда, закодировав соединение по метке времени, увидите, что данное конкретное время отличается на две-три секунды из-за того, что SYSDATE использовалось в одной долгой транзакции не один, а несколько раз.

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

НОВОСТИ ФОРУМА Рыцари теории эфира

10.11.2021 - 12:37: ПЕРСОНАЛИИ - Personalias -> WHO IS WHO - КТО ЕСТЬ КТО - Карим_Хайдаров. 10.11.2021 - 12:36: СОВЕСТЬ - Conscience -> РАСЧЕЛОВЕЧИВАНИЕ ЧЕЛОВЕКА. КОМУ ЭТО НАДО? - Карим_Хайдаров. 10.11.2021 - 12:36: ВОСПИТАНИЕ, ПРОСВЕЩЕНИЕ, ОБРАЗОВАНИЕ - Upbringing, Inlightening, Education -> Просвещение от д.м.н. Александра Алексеевича Редько - Карим_Хайдаров. 10.11.2021 - 12:35: ЭКОЛОГИЯ - Ecology -> Биологическая безопасность населения - Карим_Хайдаров. 10.11.2021 - 12:34: ВОЙНА, ПОЛИТИКА И НАУКА - War, Politics and Science -> Проблема государственного терроризма - Карим_Хайдаров. 10.11.2021 - 12:34: ВОЙНА, ПОЛИТИКА И НАУКА - War, Politics and Science -> ПРАВОСУДИЯ.НЕТ - Карим_Хайдаров. 10.11.2021 - 12:34: ВОСПИТАНИЕ, ПРОСВЕЩЕНИЕ, ОБРАЗОВАНИЕ - Upbringing, Inlightening, Education -> Просвещение от Вадима Глогера, США - Карим_Хайдаров. 10.11.2021 - 09:18: НОВЫЕ ТЕХНОЛОГИИ - New Technologies -> Волновая генетика Петра Гаряева, 5G-контроль и управление - Карим_Хайдаров. 10.11.2021 - 09:18: ЭКОЛОГИЯ - Ecology -> ЭКОЛОГИЯ ДЛЯ ВСЕХ - Карим_Хайдаров. 10.11.2021 - 09:16: ЭКОЛОГИЯ - Ecology -> ПРОБЛЕМЫ МЕДИЦИНЫ - Карим_Хайдаров. 10.11.2021 - 09:15: ВОСПИТАНИЕ, ПРОСВЕЩЕНИЕ, ОБРАЗОВАНИЕ - Upbringing, Inlightening, Education -> Просвещение от Екатерины Коваленко - Карим_Хайдаров. 10.11.2021 - 09:13: ВОСПИТАНИЕ, ПРОСВЕЩЕНИЕ, ОБРАЗОВАНИЕ - Upbringing, Inlightening, Education -> Просвещение от Вильгельма Варкентина - Карим_Хайдаров.