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

o7412369815963
Это не вспомогательный сервер!
Это расширение функционала.

Пример.
Я пока не останавливаюсь на месте хранения бизнес-логики. Об этом ниже.
Если у вас система маленькая, вам не нужна вся мощь СУБД и параллельное масштабирование вы не используете, то вы обходитесь одним сервером БД.
Система разрослась, масштабируете систему, добавляете вспомогательную систему управления этим масштабированием, его мониторинга и обслуживания.
Обратите внимание, что этот сценарий подходит для клиент-генерируемой логики и для логики, реализованной в ХП.


Это можно делать хранимками!
О том и речь, что вы делаете как хотите: запускаете SQL транзакцию с клиента или внутри ХП - за вас система сама сделает адресацию этой одной ХП на нужные сервера.

Два местоположения бизнес-логики нацелены на разные получения разных преимуществ, им присущих.
И выбор этот достаточно прагматичен.

Писать простую (ее больше) логику на клиенте быстрее и проще (в том числе за счет ОРМ, например).
Еще на клиенте пишут очень сложные преобразования.
Когда мы пишем на клиенте, мы надеемся (или предполагаем), что у нас не будет потребности оптимизировать SQL-запросы. А если и появится, то достаточно будет руками эти запросы написать.

Зато логика в ХП работает быстрее (запросы уже скомпилированы и, часто, имеют оптимизированный план выполнения, плюс экономится память на ряд обслуживающих процедур типа пула соединений, гораздо более простой системы прав доступа, избыточности протоколов и даже физических шин данных), но требует специальных знаний.
В данный момент реализация логики на ХП все еще быстрее клиент-сгенерированных запросов, хотя технический прогресс сокращает разрыв.
Но, даже начиная писать новую систему, я бы все еще подумал бы над выбором: ХП или клиентский SQL.

Аналогично, мы вставляем блоки кода на С, если нужна высокая скорость.

Lexander
Это не вспомогательный сервер!
Это расширение функционала.

“Как ни называй смысл один.”

Lexander
Зато логика в ХП работает быстрее

Мы про разные вещи говорим, запаковать пару запросов в хранимку (оптимизация) - это одно, а например у нас есть 2 сервера с пользователями (шардинг), и 3 сервера с сообщениями, для действия “отправить сообщение”, например нужно будет слазить в одну группу серверов, потом в другую, потом опять в первую - такая логика, а если ещё в процесса отправки нужно будет обратиться к внешнему АПИ?

Тут опять сеть будет лишний раз перегружаться, если прикинуть такую систему на 1 сервере пользователи, на 2-м сообщения, логика например в 1ом сервере, отправляем сообщение, мы с web сервера отправляем запрос 500 байт (100 для пользователя, 400 для сервера сообщений) - 1ый сервер пережевывает и отправляет 400байт (сообщение) на 2-й сервер, итого прокачали 900б, вместо 500б если б напрямую, а если серверов больше, продумывать шардинг хранимками?
Похоже шардинг и логика (не оптимизация) в БД не вяжется.

o7412369815963
“Как ни называй смысл один.”

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

o7412369815963
Мы про разные вещи говорим, запаковать пару запросов в хранимку (оптимизация) - это одно, а например у нас есть 2 сервера с пользователями (шардинг), и 3 сервера с сообщениями, для действия “отправить сообщение”, например нужно будет слазить в одну группу серверов, потом в другую, потом опять в первую - такая логика, а если ещё в процесса отправки нужно будет обратиться к внешнему АПИ?

Получилось хорошее такое животное в вакууме ;)
Для отправки сообщений локальным пользователям использовать внешнее АПИ? :/

o7412369815963
а если серверов больше, продумывать шардинг хранимками?Похоже шардинг и логика (не оптимизация) в БД не вяжется.

Отсылаю вас к моему посту о GridSQL и pgpool.
Там ясно написано: работу по отправке нужным нодам запросов и контроль за их выполнением они берут на себя.
Для разработчика все прозрачно. Весь кластер представляет собой один логический объект - БД.

В целом, масштабирование и логика ортогональны.