Опубликован: 11.12.2006 | Доступ: свободный | Студентов: 5820 / 381 | Оценка: 4.42 / 3.86 | Длительность: 57:15:00
Лекция 4:

Проектирование системы Microsoft SQL Server

< Лекция 3 || Лекция 4: 12345 || Лекция 5 >
Двухзвенная архитектура

В двухзвенных приложениях службы представления и база данных размещаются на разных системах (компьютерах). Уровень служб представления (пользовательский интерфейс) обычно включает в себя логику работы приложения. Хорошим примером двухуровневого приложения является приложение, использующее SQL Server Enterprise Manager. У таких приложений пользовательский интерфейс и логика работы приложения размещаются в Enterprise Manager, но все данные, необходимые для функционирования приложения, находятся в базе данных SQL Server на другом компьютере.

Двухзвенные приложения встречаются чаще всего. Вы, наверное, уже работали со многими такими приложениями. Эти приложения обычно написаны на языках, поддерживающих API (интерфейсы прикладного программирования) для Windows, таких, как Microsoft Visual C++ или Visual Basic. При помощи двухзвенных приложений каждый пользователь может иметь одно или несколько соединений с базой данных SQL Server. Данная архитектура может стать неэффективной из-за того, что большинство этих соединений будут простаивать большую часть времени.

Трехзвенная архитектура

В трехзвенных приложениях уровень базы данных, уровень приложения и уровень служб представления выделены в три разные компоненты. В типичных трехзвенных приложениях используется промежуточный уровень для обслуживания многочисленных соединений от уровня служб представления, благодаря чему уменьшается количество соединений с SQL Server. Кроме того, этот промежуточный уровень может выполнять значительный объем работы, связанной с реализацией специфики целевых задач (логики предметной области), освобождая базу данных для решения тех задач, которые она выполняет лучше всего, – для доставки требуемых данных.

На вопрос, к какой категории – с двухзвенной или с трехзвенной архитектурой – можно отнести веб-приложение, ответить сразу бывает трудно. Можно воспользоваться простой проверкой: если данные, отображаемые уровнем служб представления, могут с той же легкостью применять и терминал или веб-браузер, то данное приложение, скорее всего, является двухзвенным.

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

Производительность и масштабируемость

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

  • Использование временных рабочих таблиц. Для небольших баз данных временные рабочие таблицы оказываются эффективными, но с увеличением размера базы данных они перестают работать правильно.
  • Использование агрегатных функций.Использование агрегатных функций (aggregate functions), таких как MIN( ), MAX( ) и AVG( ), сопоставимо с объемом используемых данных. Поэтому обратите внимание, чтобы ваш набор данных не стал со временем слишком громоздким.
  • Использование индексов. По мере роста объема данных, использование индексов становится более важным (см. "Создание и использование индексов" ).
  • Использование транзакций. Использование явных транзакций очень полезно, чтобы гарантировать атомарность операций. Однако, по мере роста числа одновременно работающих пользователей, важно ограничивать блокировки, насколько это окажется возможным.

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

Заключение

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

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

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

< Лекция 3 || Лекция 4: 12345 || Лекция 5 >