Стратегии и средства настройки 523

Проектирование с учетом производительности

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

История из жизни: группа проектировщиков разработала приложение. Оно являлось расширением существующей системы. Приложение включало ряд собственных таблиц и использовало несколько существующих. Новое приложение было внедрено, и сразу же существующая система стала неработоспособной - вся система в целом стала работать слишком медленно. Оказалось, что разработчики нового приложения решили, что разберутся, какие индексы нужны, на месте . За исключением созданных автоматически для поддержки первичных ключей, никаких индексов не было. Практически каждый запрос приводил к многочисленным полным просмотрам таблиц. Разработчики спрашивали, как это быстро исправить. Напрашивался лишь один ответ: Удалите ваши таблицы и выкиньте приложение . Проектировщикам казалось, что настройкой можно заняться по завершении разработки, т.е. сначала создаем работающее приложение, а затем заставляем его работать быстрее. Не стоит и говорить, что проект закончился полным провалом. Разработанная структура базы данных не позволяла эффективно отвечать на выполняемые запросы. Пришлось вернуться к началу и все создавать заново.

Для того чтобы проиллюстрировать свой подход, расскажу небольшую историю. Там, где я работал, использовалась простая внутренняя система под названием phone. Можно было с помощью telnet подключиться к любому почтовому серверу (тогда почта была только текстовой) и в командной строке набрать phone <искомая строка>. В ответ выдавались данные следующего вида:

$ phone tkyte

TKYTE Kyte, Tom 703/555 4567 Managing Technologies

RESTON:

Примерно в 1995/1996 году, когда активно начал использоваться Web, наша группа создала небольшую Web-систему, загружавшую данные о телефонах в таблицу и позволявшую пользователям вести по этой таблице поиск. Теперь, после помещения данных в СУБД и добавления небольшого графического интерфейса, система стала в компании стандартным средством поиска информации о сотрудниках. Со временем мы стали добавлять в нее все больше данных и дополнительные поля. Она становилась все более популярной. В определенный момент мы решили добавить намного больше полей и пересоздать систему, существенно расширив ее возможности.

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

Глава 10

стенькой системы, - спроектировали таблицы, в которых содержатся ее данные. Мы специально проектировали эти таблицы с учетом дальнейшего использования. Речь шла о небольшом хранилище данных только для чтения, в котором пользователи осуществляют поиск, причем поиск должен был выполняться быстро. Популярность системы росла с каждым днем, и система угрожала захватить все ресурсы сервера. Вся информация хранилась в одной 67-столбцовой таблице с 75000 строк, в которой необходимо было выполнять поиск строк по разным полям. Так что, если ввести строку ABC, то ее поиск выполняется в поле адреса электронной почты, имени и т.д. Что еще хуже, можно было вводить шаблоны типа %АВС% и искать без учета регистра символов.

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

CREATE TABLE FAST EMPS

PCTFREE 0

CACHE

SELECT upper(last name)/upper(first name)/ /

substr(phone, length(phone)-4) SEARCH STRING,

rowid row id FROM EMPLOYEES

после завершения обновления. Фактически мы строили максимально плотную и компактную таблицу (pctfree 0) и рекомендовали держать ее в буферном кэше.

select *

from employees where rowid in (select row id

from fast emp where search string like :bv and rownum <= 500)

Этот запрос всегда выполняет полн1й просмотр таблицы FASTEMP, но мы этого и добивались. С учетом типа выполняемых запросов, это был единственно возможный выбор. Нет никакой схемы индексации, поддерживающей все запросы требуемого вида. Нашей целью было минимизировать объем просматриваемых данных, ограничить объем данных, получаемых в ответ на запросы, и сделать поиск максимально быстрым. Представленный выше подход позволяет достичь всех трех целей. Таблица FAST EMP обычно целиком будет помешаться в буферном кэше. Она - маленькая (размер ее составляет менее 8 процентов размера исходной таблицы) и просматривается очень быстро. Поиск без учета регистра символов в ней обеспечен уже при создании, один раз (а не при каждом запросе), путем хранения данных в верхнем регистре. Количество соответствующих запросу записей не будет превосходить 500 (если поиск дает больше результатов, надо уточнить критерий: 500 результатов все равно никто никогда не просматривает). Фактически эта таблица используется во многом аналогично индексу, поскольку хранит идентификаторы строк в основной таблице. Для поддержки поиска в этой системе вообще не использовались индексы - только две таблицы.

Стратегии и средства настройки 525

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

Пробуйте разные подходы

Очень важно экспериментировать, пробуя различные реализации. Теория - это хорошо, но часто неправильно - результаты тестирования реализаций намного точнее. Пробуйте реализовать свои идеи. Проверяйте, какой будет реальная производительность. СУБД предлагают тысячи средств реализации. Нет единственного лучшего решения (если бы оно б1ло, то поставщик СУБД только бы его и предоставлял). Иногда фрагментация данных повышает производительность, иногда - нет. Иногда использование компонента interMedia Text может повысить скорость поиска, а иногда - не повысит. Иногда хеш-кластер - лучшее решение, иногда от него нет никакого проку. В СУБД нет вредных средств (которых надо избегать любой ценой). Аналогично, нет и панацеи , средств, решающих все проблемы.

Прежде чем утвердить именно такой проект для описанного выше приложения, мы опробовали несколько альтернативных подходов: пытались использовать быстрый полный просмотр индекса по функции (тоже быстро, но не настолько), применяли компонент interMedia Text (не помог, поскольку требовался поиск по шаблону типа %АВС%), пробовали добавить еще одно поле в таблицу EMPLOYEES (но она не вмещалась в буферный кэш, т.е. оказалась слишком большой для эффективного полного просмотра). Может показаться странным, что столько времени было потрачено на одну эту деталь реализации. Однако представленный выше запрос выполнялся от 150000 до 250000 раз в день, т.е. два-три раза в секунду в течение целого дня (при равномерном поступлении запросов). Но это предположение неверно: как и в большинстве систем, мы наблюдали пики активности. Если бы один этот запрос выполнялся медленно, вся система развалилась бы - и это всего лишь один из тысяч поддерживаемых запросов. Определив заранее предполагаемые слабые места или наиболее очевидные цели и сконцентрировав на них усилия, мы смогли создать хорошо масштабируемое приложение. Если бы использовался подход настройка постфактум приложение пришлось бы переписывать.

Применяйте защитное программирование

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