Хранимые процедуры

[MildMildMint]

Что облегчает применение хранимых процедур на практике в приложении на одном языке?
Расскажите про свой положительный опыт применения.

 

[fixxxer]

Есть два варианта:
1) перенести вообще всю логику в ХП, из приложения дергать только их, никаких иных запросов вообще. На мой взгляд, неудобно, хотя многие так и делают во всякой банковской опердени например - тут это скорее организационный момент, разделение ответственности.
2) Использовать их (тут скорее таже триггеры) только для всяких вспомогательных штучек, относящихся скорее к внутренностям хранилища или расширению sql-синтаксиса, чем к логике. Например у меня что есть:
- функции типа unix_timestamp, ибо затрахаешься каждый раз писать extract(epoch блабла...)
- триггер для эмуляции mysql-евского on update current_timestamp
- эмуляция частных случаев merge, который в постгресе все никак не сделают - хотя тут обычно хватает rule
- партиционирование по табличкам той же статистики
итд

 

[grigori]

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

 

[флоппик]

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

 

[MildMildMint]

1), 3) Зачем? Ведь с базой по сути работает 1 приложение. Точнее приложения не пересекаются в функционале.

2) Согласен, несколько небольших функций из проекта в проект. Которые и в мускуле можно сделать(хотя в мускуле теоретически все можно).

 

[grigori]

MildMildMint
забей, тебе это не нужно, просто пиши без процедур

в mysql теоретически невозможно очень многое, и еще больше очень неудобно практически, но тебе оно не нужно

 

[MildMildMint]

grigori ну я и хотел определить, для чего оно нужно, т.к. мне оно ни разу не понадобилось. Не было такого случая, где их применение было бы удобно.

А на мускуле теоретически можно и сайт построить, передавая в СКЛ-запрос лишь параметры хттп-запроса.

 

[fixxxer]

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

мне всегда было интересно как в этом случае решается проблема единой точки отказа

есть опыт? все что мне приходит в голову основано на мастер-мастер репликации и не нравится мне априори %)

 

[grigori]

хехехе есть факт недавнего падения Скайпа на сутки )))
я не понял из их описания в чем была причина

я могу найти ссылку на презентацию, где они описывали свою структуру
они вроде бы сделали (и выложили) свой менеджер соединений, который держит соединения открытыми,
а насчет точки отказа они не писали, вроде бы

я не вижу дополнительных проблем с единой точкой:
они не привязывают приложение к 1му серверу, а failover внутри базы может решаться менеджером соединений

 

[флоппик]

я не понял из их описания в чем была причина

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

 

[fixxxer]

У скайпа вроде первопричина была в том, что почти все суперноды (которые обычные клиенты которым досталась великая честь тратить свой трафик на общее благо) дружно свалились в корку из-за какого-то бага. Или мы о другом случае?

Так, ну а менеджер соединений это не SPOF? Куда приложение то коннектится?

 

[grigori]

Так, ну а менеджер соединений это не SPOF? Куда приложение то коннектится?

Я не дописал - вчера в момент написания поста начались ремонтные работы на Укртелекоме, а утром забыл.
Менеджер соединений - конечно, spof, но он маленький и легкий, его легко дублировать, мониторить и подменить, как и фронт-балансер.
Обработку момента падения менеджера несложно прописать в процедуре получения соединения: перейти на запасной, подождать и повторить попытку, лог+уведомление.
Да, скорость реакции просядет немного, но не сильно и ненадолго.

Зато в этой схеме сохраняются скомпилированные планы исполнения запросов в sql-процедурах и вероятно возможно повторно использовать подготовленные выражения в разных запусках скриптов.

У скайпа вроде первопричина была в том, что почти все суперноды (которые обычные клиенты которым досталась великая честь тратить свой трафик на общее благо) дружно свалились в корку из-за какого-то бага. Или мы о другом случае?

Я не знал значение понятия "супернода", спасибо

 

[MiksIr]

мне всегда было интересно как в этом случае решается проблема единой точки отказа

есть опыт? все что мне приходит в голову основано на мастер-мастер репликации и не нравится мне априори %)

Откуда в голову тут мастер-мастер приходит? Решается как и во всех других случаях - мастер-слейв или горячий бакап.
Там фишка в PL/Proxy - язык вызова удаленных процедур с возможностью партицирования

 

[grigori]

Откуда в голову тут мастер-мастер приходит?

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

Там фишка в PL/Proxy - язык вызова удаленных процедур с возможностью партицирования

Более того - шардинга с нужной логикой независимо от приложения.

 

[fixxxer]

Ну, короче, все как всегда, просто вместо кода на уровне приложения используем хранимки. Шило на мыло

 

[grigori]

Как-то у Пьера Кардена (кажется) спросили, почему он не сделает какой-то совершенно новый дизайн одежды.
Он спросил в ответ: "Это как - третий рукав?".

devil is in details, as usually,
просто немного другой подход к проектированию, имеет право на существование и свои плюсы