Информационный сайт

 

Реклама
bulletinsite.net -> Книги на сайте -> Программисту -> Тоу Д. -> "Настройка SQL. Для профессионалов" -> 10

Настройка SQL. Для профессионалов - Тоу Д.

Тоу Д. Настройка SQL. Для профессионалов — СПб.: Питер, 2004. — 333 c.
ISBN 5-94723-959-0
Скачать (прямая ссылка): nastroykasqldlyaprof2004.djvu
Предыдущая << 1 .. 4 5 6 7 8 9 < 10 > 11 12 13 14 15 16 .. 161 >> Следующая


Если отвлечься от этих теоретических соображений, мой собственный 13-летний опыт настройки и исследования производительности заключается в том, что система управления базой данных (точнее, та часть приложения, которая взаимо-
Кто должен настраивать SQL?

23

действует с SQL-сервером) представляет собой лучшее место для попыток повысить производительность и пропускную способность.

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

ПРОИЗВОДИТЕЛЬНОСТЬ И ПРОПУСКНАЯ СПОСОБНОСТЬ-----------------------------------------

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

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

Выбор средств для решения проблемы низкой пропускной способности ограничен. Можно устранить узкие места (например, добавив центральных процессоров), если вы еще не достигли пределов возможностей системы, либо настроить приложение, включая, конечно же, его часть, взаимодействующую с SQL-сервером. Если вы не можете применить ни одного из этих способов, система не сможет поддерживать желаемый уровень нагрузки. Данную проблему невозможно решить, использовав большее количество пользователей. Также не следует ожидать, что пользователи смирятся с низкой производительностью, причиной которой будет перегрузка системы. С центральными процессорами нельзя договориться. Если для решения вашей задачи необходимо большее количество ресурсов, чем могут предоставить центральные процессоры, их нельзя заставить работать более интенсивно. Если вы не можете настроить систему или устранить лишнюю нагрузку на нее, это означает, что вам придется подгонять свой бизнес под систему, а такой результат является худшим из возможных и может означать для вас потерю существенной доли ваших доходов.

Кто должен настраивать SQL?

Итак, вы убедились, что SQL настраивать стоит. Следует ли этим заниматься именно вам и именно в вашей работающей системе? Скорее всего, вы приложили руку к созданию, самое большее, лишь небольшого модуля работы с SQL-сервером
24

1. Введение

в вашей системе, поскольку большинство систем создаются большими группами разработчиков. Вы можете даже — как и я в большинстве случаев из собственной практики — иметь дело с приложением, для которого вы не написали ни одной строчки на языке SQL, и даже не несете ответственности за устройство базы данных. На протяжении многих лет я полагал, что разработчики приложения, написавшие SQL, всегда гораздо лучше меня разберутся в том, как исправить программу. Тем не менее, поскольку на мне лежало бремя ответственности за производительность, я полагал, что лучшее, что я могу сделать, — это определить, которые операторы SQL создают большую часть нагрузки и, соответственно, заслуживают усилий по настройке. Затем (как я думал) моя задача заключалась в том, чтобы ворчливо приставать к разработчикам с просьбами настроить созданные ими SQL-програм-мы. Мне стыдно в этом признаваться, но я чудовищно заблуждался.

Предыдущая << 1 .. 4 5 6 7 8 9 < 10 > 11 12 13 14 15 16 .. 161 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100