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

Размещение базы данных

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

Журнал транзакций

Журнал транзакций критически важен для работы, для стабильности и производительности сервера базы данных. У каждой базы данных имеется свой собственный журнал транзакций, поэтому каждый журнал транзакций должен быть правильно размещен. Журнал транзакций используется для записи изменений в базу данных, что позволяет восстановить систему в случае отказа. Так как восстановление опирается на журнал транзакций, важно, чтобы эта компонента базы данных была защищена от возможных сбоев при помощи RAID-устройств. Журнал транзакций должен оставаться доступным даже при выходе диска из строя.

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

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

Файлы данных

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

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

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

Приложение

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

Архитектура

Основная архитектура приложения может принимать различные формы. Основные различия между архитектурами приложений состоят в количестве систем, участвующих в работе приложения. Эта классификация производится по количеству звеньев (tiers). Реклама многих наиболее популярных приложений основывается на количестве звеньев, которые могут в них содержаться.

Сравнение архитектур

Каждое приложение базы данных состоит из трех отдельных компонент:

• Службы базы данных (database services). Это – конечный сервер базы данных и данные, которые размещены в этой базе данных.
• Службы приложения (application services). Это – механизмы манипулирования данными, извлекаемыми из базы данных. Логика их работы определяется приложением или потребностями бизнеса.
• Службы представления (presentation services). Это – пользовательский интерфейс. Службы представления должны быть способными манипулировать данными таким образом, чтобы это было понятно пользователям.

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

Рис. 4.1. Различия между однозвенной, двухзвенной и трехзвенной архитектурами

Однозвенная архитектура

Однозвенная (one-tier, single-tier) архитектура – это система, в которой все службы базы данных, приложения и представления (пользовательский интерфейс) размещены на одной системе. Системы такого типа не производят обработку вне тех компьютеров, на которых они исполняются. Примером однозвенной архитектуры может служить база данных Microsoft Аccess с локальными службами представления.

В наше время трудно встретить действительно однозвенную архитектуру, особенно на платформе Windows 2000. Тем не менее многие небольшие однопользовательские приложения являются однозвенными. Примером этому могут служить Microsoft Money, Quicken и TurboTax. Такие приложения обычно размещаются на том же компьютере, на котором они и исполняются. Пример однозвенной архитектуры с SQL Server найти гораздо труднее. Фактически, даже если вы можете исполнять Enterprise Manager на той же системе, где размещена и база данных, но на самом деле такое приложение не является однозвенным, потому что данное приложение пользуется сетевыми компонентами SQL Server. Тот факт, что вы вот взяли и запустили его на той же системе, является несущественным.