Python-сообщество

В OLTP базах банков очень даже пихают.

o7412369815963

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

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

одна из причин - бд зачастую самое узкое место, а самое узкое место стараются разгрузить (а не нагрузить хранимками)
например у нас в компании поставили софт от Нестле - полное г. вся логика в базе, даже простые функции а+б хранимками, в итоге все дико тормозит даже на последних ксеонах.

джойнами не пользуются потому что это медленно и неудобно в случае когда ваша база размазана на 100 серверов.

Высоконагруженные проекты обычно используют разные технологические решения, ничто не мешает использовать nginx как фронтенд с апачовыми бекендами, которые лезут в зависимости от задачи в MySQL, постгрю или ту же монгу, предварительно посмотрев в Memcached

o7412369815963
а не нагрузить хранимками

Не флейма ради, просто интерестно - можете ткнуть в доку?
Я всегда считал, что хранимки, наоборот быстрее ‘тяжелых’ запросов с кучей условий.
(применительно к postgresql, в моем случае)

Отредактировано s0rg (Фев. 8, 2013 18:08:12)

Muan
которые лезут в зависимости от задачи в MySQL, постгрю или ту же монгу, предварительно посмотрев в Memcached

…которые пишут не хранимками, по сути хранимки экономят на передаче данных - что-б не гонять лишний трафик. Я говорю не про полный отказ от хранимок, в некоторых случаях они могут дать преимущество в больших проектах.

s0rg
просто интерестно - можете ткнуть в доку?

про доки незнаю, есть статьи и набор рекомендаций, сейчас не найду - давно читал.

Например можно сделать сферический расчет, например проект в котором 50% времени проца тратиться на запросы и 50% на логику.
В итоге когда мощности будет не хватать, в случае отдельной логики (в сервер-приложении) мы всю логику перенесем на отдельную ноду. А если все будет хранимками, тот сервер продолжит загибаться (это в общем случае т.к. всякие выкрутасы ещё можно делать). А если нагрузка на логику возрастет? 20% на 80%, мы можем раскидать логику на 4 ноды.
Оптимизацию конечно никто не отменял, но большие проекты должны легко масштабироваться.

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

s0rg
Я всегда считал, что хранимки, наоборот быстрее ‘тяжелых’ запросов с кучей условий.

Мы тут про другое. (Запросы + логика) в БД vs (Запросы в БД + Логика в приложении) для БОльшых проектов (сотни серверов). запросы могут быть одинаковыми.

Отредактировано o7412369815963 (Фев. 8, 2013 20:11:26)

Muan
Высоконагруженные проекты обычно используют разные технологические решения, ничто не мешает использовать nginx как фронтенд с апачовыми бекендами, которые лезут в зависимости от задачи в MySQL, постгрю или ту же монгу, предварительно посмотрев в Memcached

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

o7412369815963
Например можно сделать сферический расчет, например проект в котором 50% времени проца тратиться на запросы и 50% на логику.В итоге когда мощности будет не хватать, в случае отдельной логики (в сервер-приложении) мы всю логику перенесем на отдельную ноду. А если все будет хранимками, тот сервер продолжит загибаться (это в общем случае т.к. всякие выкрутасы ещё можно делать). А если нагрузка на логику возрастет? 20% на 80%, мы можем раскидать логику на 4 ноды.

Почему вы решили, что для СУБД нет таких же возможностей, что и для сервер-приложения?

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

Или pgpool - у этой мидлвари немного другая направленность, но позволяет так же распараллелить запросы к БД.

Lexander
для Postgres есть GridSQL

Ну это подтверждает мои слова, сообщество сделало вспомогательный сервер, т.к. это не неудобно делать на хранимках в самой БД.