Правила оптимизации просты: Правило 1: Не делайте её. Правило 2 (только для экспертов) Не делайте её раньше времени.
Эти правила были сформулированы Майклом А. Джексоном (нет, не тем Майклом Джексоном, да, тем Джексоном, который придумал «Диаграммы Джексона») в его книге 1975 года Принципы разработки программ. Это интересное и депрессивное чтиво, которое напоминает нам, сколь много нам было известно о написании хороших программ тогда, и сколь мало мы используем это знание сегодня. На деле, не смотря на то, что минуло три десятилетия, а вычислительные мощности выросли практически до бесконечности, многие программисты не могут запомнить этих правил оптимизации. А среди тех, кто их помнит, многие не догадываются, что означает «оптимизация».
Будучи главным администратором в своей компании Крис отвечал за приобретение и настройку нового сервера баз данных для команды разработчиков. Хотя они просили довольно бюджетный сервер, Крис знал, что компания будет расти, и хотел, чтобы железо соответствовало возрастающим требованиям. Он купил сервер на двух Xeon 2.8 Ггц с 4 Гб памяти и 3x36 Гб 15K SCSI RAID5.
Разработчикам требовался сервер для создаваемого ими новейшего приложения управления данными. Их нынешняя система, хотя и была жизненно важна для ведения дел, была разработана примерно в то же время, когда была написана книжка Джексона и уже не совсем соответствовала времени. Все в компании, включая Криса, который отвечал за поддержку этого древнего приложения, хотели перейти на что-нибудь новенькое.
Новая команда разработчиков системы так и не выучила тех уроков, которыми пренебрегли в свое время разработчики старой. Поэтому в базе данных каждый столбец был объявлен как VARCHAR(100). Конечно, INT-ы и DATETIME-е неплохо справляются с хранением целых и дат, и возможно должны были использоваться для хранения целых и дат, но зато в нашем случае разработчикам надо было знать о существовании только одного типа. Всего за несколько месяцев база раздулась до 10 Гб. Некоторые таблицы были размером более 1 Гб, хотя в них было всего около 100000 записей.
Крис обратился к своему начальнику и предложил исправить типы данных во всей системе. «Нет, сейчас нам надо волноваться о завершении разработки. Оптимизировать будем потом». Прикинув сложность замены всех полей с VARCHAR(100) на соответствующие типы во всей работающей базе данных, Крис осознал, что VARCHAR(100) прописался в системе навсегда.
Впрочем, система уже ожила, и компания зависела от нее. Пользователям надо было создавать отчеты, чтобы делать свою работу. Однако создание отчета иногда подвешивало сервер на 30 минут, без какого либо информирования пользователя о текущем положении вещей. Крис снова обратился к начальнику, попросив добавить индикатор прогресса во время ожидания отчета, но снова получил: «сейчас не время для оптимизаций!»
Несмотря на его добрые намерения, вина за ненастроенный должным образом сервер легла на Криса. Он пробовал индексирование (не очень помогает, когда кругом одни VARCHAR-ы), оптимизацию запросов, и даже перемещение таблиц в память. Ничего не срабатывало. Большинство таблиц уперлось в предел на размер одной записи, да и все приведения типов производились на стороне сервера. Все правильно, ведь чтобы сделать даже простую выборку (скажем небольшого набора записей, заданного промежутком времени), SQL Server должен был прочитать каждую запись, перевести столбец с датой в DATETIME, и потом решить попадала ли она в заданный интервал. Все это ложилось на сервер тяжелым вычислительным бременем, и, в конечном счете, он с трудом справлялся со своей работой.
Крис больше там не работает, но система, над которой он трудился, все еще используется. И если бы он нажал «Создать отчет» в день своего ухода, то он вот-вот был бы уже готов.
Оригинал:http://worsethanfailure.com/Articles/We_0x27_ll_Optimize_Later.aspx
Перевод:Евгений Виговский
