Хранимые процедуры mySQL: преимущества и недостатки

Question

[BorisT]

В текущем проекте мы активно (уже порядка 10тыс. строк процедур) используем хранимые процедуры mySQL. Это игровой сервис с не тривиальной бизнес-логикой. Используя процедуры, мы значительно сокращаем кол-во запросов к БД. Но вот недавно встал вопрос рентабельности их использования. Запросы не кэшируются, если в них используются переменные пользователя (http://www.mysql.ru/docs/man/Query_Cache_How.html). Таким образом, используя процедуры, мы значительно сокращаем кол-во кэшируемых запросов. На данный момент у нас в кэше более чуть более 50% всех запросов. И возникает вопрос: навреди ли мы проекту или наоборот? Получается, что у хранимых процедур наряду с плюсами есть один минус.

У кого какой опыт использования хранимых процедур mySQL и мысли по этому поводу?

Answer 1

[Вячеслав Плиско]

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

Comments

[Владимир Чернышев]

Логику (бизнес-логику, а также «логику хранения») можно и не размазывать, а перенести её в СУБД полностью. Хотя поддерживать всё равно сложнее, из-за необходимости синхронизировать исходники процедур (файлы) и их «представление» в БД. Различные миграции и деплой-скрипты не убирают проблему полностью.

Answer 2

[Григорий Перетяка]

Мое, не авторитетное, мнение:

Хранимые процедуры — это перенос части логики в БД. В некоторых случая может быть какой-то рост производительности, но в среднем можно сказать, что разница несущественная. Другой вопрос, что эту логику будет выполнять сервер db, а не сервер приложения, иногда это важно.

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

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

Answer 3

[Alex XYZ]

У меня опыт хранимых процедур для MySQL не большой (в MSSQL побольше, но как пользователь серверов большой принципиальной разницы не вижу), поэтому просто хочу поделиться мыслями. Не важно на чём вы пишете процедуры — на C++, JavaScript или SQL, но если у вас несколько технологий в проекте, то:

1. Каждую процедуру нужно писать в своей технологии.
2. Максимально изолировать технологии друг от друга (в идеале только передача параметров и результатов), чтобы держать проектирование под контролем.
3. Искать методы численной оценки производительности различных этапов программирования. Это отдельная задача.

Может у вас всё нормально идёт, и вы просто боитесь, что что-то пойдёт не так?

Answer 4

[Владимир Чернышев]

Хранимые процедуры и триггеры плохо поддерживаются универсальными ORM. Видимо из-за больших различий в разных РСУБД. Вот когда (если?) научатся транслировать DSL модели в конкретный диалект SQL и синхронизировать изменения с БД (а для «примитивных» — реализовывать на «обычном» ЯП), тогда и обретут второе дыхание.

Answer 5

[Александр]

хм… использование хранимых процедур в БД, где и как попало ни есть хорошо.

Был у нас один «архитектор», пришедший в WEB из Enterprise App, как-то в одном проекте мы впердолили 30% логики на хранимках. В итоге много ресурсов сожрал MySQL сервер, постоянный deadlock… отлаживать очень сложно, пришлось еще написать 15-20 % кода, для трейсинга выполнения хранимок…
ну и работать стало все медленнее. Когда я про это рассказал разработчикам Мускуля, они долго смеялись над построением такой архитектуры…

Так что, если использховать хранимки, то только в самых простейших случаях,
Мускуль — вам не Оракл, хоть он теперь и есть его младший братик…

в общем я бы сказал, что проект завалили, хотя он закрылся по причине финансирования (был кризис)…
но архитектор все равно оказался дураком, хотя хотел сделать как лучше