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

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

ПРИМЕЧАНИЕ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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