Миллсап про тюнинг

[egorius]

Меня до сих пор удивляет то, что на рынке Oracle производительность считается работой администраторов, а не разработчиков. От разработчиков как минимум на 90% зависит, насколько быстро сможет работать приложение. Я думаю, так повелось с тех времён, когда множество проектов имело команды администраторов, но не имело команд профессиональных разработчиков.

Большинство тех проектов были связаны с внедрением больших «коробочных» приложений типа Oracle Financial и Manufacturing Applications (которые выросли в Oracle E-Business Suite). Разработчики, участвовавшие в таких проектах, не были профессионалами. Как правило, это были люди от бизнеса, не имевшие программистского образования, но им сказали, что теперь-де каждый может написать программу на этом новом языке четвёртого поколения, именуемом SQL.

Ясное дело, что внедряя Чрезвычайно Гибкое Приложение с двадцатью тысячами таблиц в базе, вы столкнётесь с проблемами производительности. Кто-то должен их решать, и администраторы оказались единственными технически подкованными людьми, способными на это. Они также участвовали в организации первых конференций Oracle, и я думаю, что с тех пор термин «performance tuning» стал прочно ассоциироваться с администраторами.

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

Довольно свободный перевод кусочка из оригинала.

Comments

[autoench.livejournal.com]

администраторы оказались единственными технически подкованными людьми, способными на это
Ну так, пардон, нефиг было городить монструозность на голом месте. Вот теперь расхлебывайте %)

[egorius.livejournal.com]

Дык, расхлёбываем :)
Но.
Во-первых, монструозность проистекает не из голого места, а из Чрезвычайной Гибкости. Понятно, что если тот же Oracle E-Business Suite писать каждый раз отдельно под нужды конкретной организации, то всё будет существенно проще. Но кто ж будет этим заниматься?
А во-вторых, проблемы производительности проистекают не только из монструозности приложения, но и (в основном) из больших объёмов данных. Так что проблемы гарантированы в любом случае...

[autoench.livejournal.com]

Увы, так и есть. Но, повторюсь, Оракл умышленно сдвинул центр тяжести в область администрирования. С этим вы согласны?

[egorius.livejournal.com]

Да я бы не сказал.
Традиционно-ориентированные разработчики привыкли к императивному стилю программирования. Сам всё запрограммировал, сам расхлёбываешь. Собственно, что повсеместно и происходит: попытки навязать БД своё видение алгоритма редко бывает удачным, потому что мыслить циклами при работе с БД нельзя.
А вот SQL — штука декларативная, там изрядная часть работы происходит за кулисами оптимизатора. И разработчик должен учиться не мешать оптимизатору, и даже наоборот — помогать. То есть переключиться в декларативную парадигму. И администратор тут совершенно ни при чём.
Другое дело, что оптимизатор иной раз не справляется, и чтобы разобраться в проблеме и аккуратно её исправить, требуются знания, которые к традиционному программированию отношения вроде как не имеют: все эти трассировки, ожидания, планы запроса... Считать ли это областью ответственности администратора? На мой взгляд, тоже нет.