Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Доступ к базам данных по низкоскоростным каналам

Род Флек

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

Подход первый: архитектура клиент—агент—сервер

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

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

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

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

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

Некоторые производители уже предлагают продукты, поддерживающие такую архитектуру. Так, фирма Oracle поставляет продукт Oracle Mobile Agents (старое название Oracle in Motion), состоящий из трех компонентов: Message Manager, Message Gateway и Agent Event Manager. Message Manager предназначен для организации связи удаленного клиента, скажем, с центральным офисом по низкоскоростным каналам. Message Manager взаимодействует с Message Gateway, управляющим, в свою очередь, каналом связи из центрального офиса. Message Gateway общается с Agent Event Manager, который, собственно, и является агентом, связывающимся с сервером БД (или с другим сетевым ресурсом) по высокоскоростному каналу. При этом во время выполнения запроса между клиентом и агентом канал связи не нужен.

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

Подход второй: режим удаленного узла

В этом случае надо сделать так, чтобы приложения не ощущали никакой разницы между тем, осуществляется ли доступ к серверу БД с удаленного компьютера или с компьютера, непосредственно подключенного к ЛВС, в которой находится этот сервер. Небольшая работа с ПО компьютера-клиента превратит ваш модем в сетевую плату (хотя, конечно, и более медленную, чем настоящая сетевая плата). Удаленный компьютер-клиент, общаясь с сервером при помощи стандартных протоколов TCP/IP, IPX/SPX или NetBEUI, станет, по сути, еще одним узлом в ЛВС. Основная задача здесь — оценить скорость работы и производительность ПО, установленного на удаленном компьютере. Кроме того, необходим анализ функционирования протоколов и библиотеки связующего ПО (рис. 2). Так, при использовании сервера SQL Server фирмы Microsoft необходимо оценить работу стандартных протоколов совместно с библиотекой DB-Library. Если вы применяете ORACLE7, то придется уделить внимание взаимодействию протоколов с библиотекой SQL*Net Library. Не все протоколы одинаковы, и поэтому выбор конкретного семейства протоколов, возможно, будет определять производительность работы как клиентской, так и серверной стороны.

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

Для оптимизации доступа к корпоративной БД в режиме удаленного узла требуется мастерство в проектировании и программировании БД. Желательно избегать запросов типа “все или ничего”. Если в середине выполнения такого запроса вы решите его отменить, то не увидите ни единой строчки частичного результата, уже полученного к этому моменту. Запросы типа “все или ничего” позволяют видеть только результат выполнения всего запроса, а пользователю необходимо видеть результаты его запроса по мере их поступления и иметь возможность отменить дальнейшее выполнение запроса, если то, что он хотел получить, уже им получено. Не запрашивайте передачу всех столбцов таблицы, только потому, что они в ней присутствуют. Если какой-либо столбец вам не нужен, то стоит оставить его за пределами запроса. Спроектируйте свое приложение так, чтобы пользователь мог быстро и эффективно конкретизировать свой запрос. Новые технологии, разработанные производителями использующих язык SQL систем управления БД, значительно облегчают этот процесс.

Многие фирмы предлагают продукты для обеспечения доступа в режиме удаленного узла. Некоторые из таких продуктов, скажем Remote Access Server фирмы Microsoft, NetWare Connect производства Novell и NetModem фирмы Shiva, поддерживают широкий набор протоколов. Существуют и продукты, работающие на уровне библиотеки связующего ПО и расширяющие функциональные возможности стандартных систем доступа в режиме удаленного узла. В качестве примера приведем продукт Enterprise Wide Foray for SQL Server фирмы TechSmith. Его использование повышает производительность работы удаленного узла, специально настроенного для работы с SQL Server. Кроме того, Enterprise Wide Foray for SQL Server имеет еще два очень полезных свойства. Во-первых, он обеспечивает протокольную независимость общения клиента с сервером БД: клиент может общаться с коммуникационным сервером по протоколу, отличному от того, по которому последний обменивается данными с сервером БД. Во-вторых, средства безопасности Enterprise Wide Foray for SQL Server позволяют ограничить доступ к сетевым ресурсам, разрешив лишь доступ к серверу БД.

В случае доступа к БД режим удаленного узла наиболее подходит, когда одновременно осуществляется обработка ограниченного числа строк таблицы и объем данных, передаваемых между клиентом и сервером, невелик. Такой режим наиболее эффективен при коротких запросах, с малыми по объему ответами.

Подход третий: технология тиражирования

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

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

При использовании тиражирования БД необходимо иметь в виду следующее: таблицы должны быть спроектированы так, чтобы наиболее часто изменяемые данные были максимально нормализованы, т.е. таблицы должны быть узкими и длинными, а не широкими и короткими. По возможности необходимо проводить тиражирование только тех данных, которые нужны в том или ином филиале или на том или ином сервере. Сервер SQL Server 6.0 фирмы Microsoft позволяет выборочно тиражировать столбцы и строки таблицы, но вы обязательно должны тиражировать первичный ключ таблицы. Выборочное тиражирование уменьшает объем данных, передаваемых между серверами БД по низкоскоростному каналу связи. При значительных изменениях в БД данные можно тиражировать вручную, записывая их, скажем, на магнитную ленту и затем посылая по почте.

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

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

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

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

***

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


распечатать статью

Автомойка самообслуживания мойки самообслуживания.




  
2 '1996
СОДЕРЖАНИЕ

колонка редактора

• Сладкие сети

локальные сети

• Сценарии входа в сеть

• Высокоскоростные сетевые адаптеры

• Службы NetWare и новые средства разработки приложений

• Cisco и 3Com в одном проекте

• Массивы RAID: емкость и производительность

корпоративные сети

• "Штормящая" сеть

• Суперсерверы широкого пользования

• Catalyst 5000 фирмы Cisco

• Сетевая ловушка, или Платформы управления

• Установка и настройка средств удаленного доступа Windows 95

услуги сетей связи

• Пейджеры

• Беспроводные мосты

приложения клиент-сервер

• Стратегия многопроцессорной обработки

• Доступ к базам данных по низкоскоростным каналам

открытые системы

• Мир TCP/IP. Протоколы UDP и TCP

• Как улучшить Web-страницу?

защита данных

• Руководство по выбору ИБП

• Голосование без обмана

новые продукты

• Семейство BayStack, Цветные струйные принтеры DeskJet 1600C и DeskJet 1600CM, Дисковый массив StorageWorks RAID Array 230 ...



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх