Планирование мощности системы

Обработка транзакций

В данном разделе мы изучим, как выполнять анализ тенденций использования сервером базы данных ресурсов процессоров, памяти и дисков. Это нужно, чтобы правильно выбирать систему для нужного приложения. Сервер базы данных выполняет только функции работы с базой данных: при своей работе этот сервер выполняет только транзакции. При исполнении оператора SELECT или UPDATE сервер базы данных интерпретирует данные операторы как последовательности операторов чтения и записи. На самом деле, любая транзакция может быть разбита на чтения и записи в базу данных. На этом атомарном уровне сервер базы данных обрабатывает операции ввода-вывода. Нужно выбрать систему, способную обращаться с транзакциями различных видов и объемов, и с порождаемыми ими операциями ввода-вывода. Основными типами транзакций являются системы оперативной обработки транзакций (OLTP, on-line transaction processing) и системы поддержки принятия решений (DSS, decision support system).

Транзакции систем оперативной обработки транзакций

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

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

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

Практические советы

Банкоматы

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

Транзакции систем поддержки принятия решений

Другим типом систем обработки транзакций являются системы поддержки принятия решений (DSS). Транзакции систем поддержки принятия решений возвращают большие объемы информации и требуют для своей обработки гораздо больше времени, чем транзакции OLTP. Для обработки транзакции DSS могут понадобиться часы или даже дни. В качестве примера системы поддержки принятия решений можно привести архив складских запасов, запись в который производится редко, только при его обновлениях. Такие системы обычно снабжают информацией сотрудников-управленцев, чтобы они могли принимать важные решения, например, о развитии бизнеса или о необходимом уровне складских запасов. В качестве другого примера можно привести используемую военно-воздушными силами США систему поддержки принятия решений, информирующую руководящий состав ВВС о текущем состоянии, расположении и вооружении реактивных истребителей, бомбардировщиков и людей.

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

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

Как знают системные аналитики, в системах этого типа обычно достигается 100-процентное использование центрального процессора и других системных ресурсов, поэтому вопрос состоит не в загрузке системы работой, а в сроках обработки запросов системой. Есть такое практическое правило при проектировании систем DSS: распределяйте, насколько это возможно, систему по имеющемуся оборудованию. Другими словами, вы должны не просто иметь количество дисков, достаточное для того, чтобы база данных помещалась бы на них, а спланировать размещение базы данных по многим томам, чтобы рассеять по ним активность ввода-вывода. Насчет оперативной памяти в этом отношении никакие подобные меры не понадобятся, потому что кэширование к ней почти не применяется. (Для обработки транзакций DSS потребуются полные сканирования таблиц, т.е. просмотр таблиц будет начинаться от их начал и продолжаться пока они не будут полностью обработаны.)

Практические советы

Квартальные продажи

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