Академия Специальных Курсов по Компьютерным Технологиям
    Главная страница Послать письмо
 
AskIt.ru  
   
   
   
   
   
   
 
 
  Главная / Заказные курсы / Microsoft SQL Server 2005 для администраторов
 
 

Получить учебные материалы по этому курсу


<-- Назад Читать дальше -->

Модуль 2. Планирование и установка SQL Server 2005

2.1. Планирование установки SQL Server 2005

2.1.1. Оценка архитектуры приложения на основе SQL Server 2005

SQL Server 2005 - планирование архитектуры приложения, базы данных OLTP и хранилища данных, подключения к SQL Server по низкоскоростным соединениям

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

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

q      первым делом покупается мощный многопроцессорный сервер с хорошим RAID-массивом и большим объемом оперативной памяти;

q      таблицы и индексы дефрагментируются (а иногда система индексов полностью переделывается);

q      ресурсоемкие операции (загрузка и выгрузка данных, формирование больших отчетов и т. п.) переносятся на нерабочее время;

q      оптимизируются подключения пользователей (например, подключения по ODBC заменяются на подключения по OLE DB);

q      вручную настраиваются (например, при помощи хинтов оптимизатора) самые важные запросы пользователей.

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

Наиболее удачное решение выглядит так: базу данных надо разделить на две. При этом каждая база данных должна храниться на своем сервере (они оптимизируются совершенно по-разному). Рабочая база данных, в которой пользователи выполняют текущие операции (заносят информацию о новых договорах, закрывают их, формируют текущие отчеты и т. п.) называется базой данных OLTP (OnLine Transaction Processing — оперативной обработки транзакций). На регулярной основе (раз в сутки, раз в месяц, раз квартал и т. п.) информация о старых транзакциях переносятся в другую базу данных — Data Warehouse (хранилище данных). Обычно для этой цели используются пакеты SSIS/DTS.

Информация в Data Warehouse, как правило, доступна только на чтение и используется для:

q      формирования отчетов;

q      получения аналитической информации (например, как выглядят тенденции по прибыльности такой-то линейки продуктов за продолжительный период). Часто для анализа на основе данных из Data Warehouse формируется еще одна база данных — OLAP (OnLine Analytical Processing — оперативная аналитическая обработка данных), где вместо таблиц используются кубы с преагрегированными итогами (за период, по региону, по продуктовой линейке и т. п.).

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

Все эти способы вполне можно реализовать, если он них подумали заранее — на этапе проектирования приложения (или хотя бы при сдаче в эксплуатацию). Если же задача работает уже несколько лет и "обросла" системой отчетов и вспомогательных приложений, то менять ее будет очень сложно.

Вторая проблема, о которой тоже лучше подумать сразу: будут ли с вашей базой данных работать удаленные территориально пользователи, например, из филиалов, во время командировок, из дома и т. п. Если да, то лучше изначально предусмотреть решение. Обычно используются следующие варианты:

q      применение терминальных технологий (Microsoft Terminal Server или Citrix). Преимуществами этих технологий являются защищенность, отсутствие необходимости устанавливать на пользовательские компьютеры клиентские приложения (кроме клиента Terminal Server), работа практически с любыми операционными системами (при использовании Citrix). К недостаткам можно отнести то, что придется открывать порты терминальных протоколов для обращения из-за пределов вашей сети, на что сетевые администраторы идут не всегда. Кроме того, не все клиентские приложения работают без проблем через терминальный сервер;

q      применение Web-интерфейса (который можно использовать и для пользователей в локальной сети). К недостаткам этого способа можно отнести обязательную необходимость дополнительной защиты трафика HTTP, например, средствами SSL (Secure Socket Layer);

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

Еще один архитектурный момент, над которым стоит подумать — нужно ли разносить компоненты вашего приложения по разным компьютерам. Условно большинство приложений, которые построены на основе SQL Server, можно разделить на три уровня:

q      уровень данных — сами таблицы и индексы, средства обеспечения целостности данных и прочие компоненты, которые непосредственно связаны с хранением данных;

q      уровень бизнес-логики — то, как выполняются операции вашего приложения, например, добавление нового заказа или клиента. Чаще всего этот уровень реализуется при помощи хранимых процедур, хотя можно использовать и COM-компоненты, и реализацию бизнес-логики на клиенте;

q      уровень представления данных — интерфейс для представления данных пользователю. Чаще всего используется Windows- или Web-приложение.

Во власти разработчика разнести эти компоненты по отдельным компьютерам или, наоборот, объединить на одном компьютере. При этом следует принимать во внимание:

q      соображения производительности. Мы можем просто снять часть нагрузки с сервера данных путем переноса бизнес-логики на другой сервер;

q      соображения отказоустойчивости. Серверов, которые обеспечивают бизнес-логику или представление данных (терминальные серверы, Web-серверы) может быть несколько, и в случае отказа одного из них пользователи могут продолжить работу с другим сервером;

q      соображения безопасности. Например, если к данным SQL Server открыт доступ из Интернета через Web-приложение, то, конечно, безопаснее будет поместить Web-сервер на отдельном компьютере по отношению к SQL Server.

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

 

   
   
   
   
   
   
   
   
   
   
 
<-- Назад Читать дальше -->

Получить учебные материалы по этому курсу


 
© 2004-2016, Академия Специальных Курсов
по Информационным Технологиям
.
Все права защищены.

Разработка NevaStudio
г. Санкт-Петербург, Васильевский остров,
20-я линия, д. 7
Офис 101, 2-й этаж
Телефон: 8(812)922-47-60
E-mail: info@askit.ru