Petro123,

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

Ну и технологии развиваются, требования опять же расширяются. Аргументов у двузвенщиков всё меньше и меньше )

tunknownbetelgeizexА могут процедуры в БД масштабироваться отдельно от таблиц? Нет! Странный вопрос. Упрощённо- процедура есть набор запросов.

Перефразируя:
Могут http запросы масштабироваться отдельно от Nginx?

Это слишком упрощенно )

Процедура - это исполняемый код, который выполняется внутри процесса SQL сервера.

Конечно, процедуры используют SQL-запросы для обращения к таблицам этой же самой БД, но помимо запросов содержат операторы, переменные, функции итп.

Фактически, ХП выступают клиентом для SQL-движка СУБД. Таким же клиентом, как любая внешняя программа (на С#, к примеру),
за исключением того, что выполняются в том же процессе, что и SQL-движок.

Но если внешнее приложение можно запросто запустить во множестве экземпляров на разных хостах, то ХП всегда на одном хосте - где СУБД.

tunknownbetelgeizexНо если внешнее приложение можно запросто запустить во множестве экземпляров на разных хостах, то ХП всегда на одном хосте - где СУБД.
Кластеризация устраняет некоторые проблемы.

Статья, которую вы прислали, говорит про кластер master-slave. Он решает проблемы доступности, а не производительности.

Активный хост там всегда один. ХП будут выполняться только на нем ( ОК, read-only ХП можно и на слэйвах пускать, но это просто вопрос кэширования )

Это не про масштабируемость...

tunknownСон Веры ПавловныХП можно запустить из множества экземпляров внешнего приложения на разных хостах. И она (ХП) будет выполняться параллельно во множестве сессий (ну, если запрашиваемые блокировки позволят).Верно, без учёта блокировок sql сервер делает параллелизм "из коробки" без каких либо дополнительных действий. Вдруг, кто не знает.

Вы о чем? Что sql-сервера многопоточны? Это очевидно)

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

Это не про масштабируемость.. тоже.

Arm79betelgeizex,

это не так
Процедура - это код, алгоритм

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

Что именно не так? ) Мы тут много тем обсуждаем...

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

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

И зачем тут еще один слой в виде ХП? <тут удивлённый смайл>

ViPRostunknownпропущено...
Верно, без учёта блокировок sql сервер делает параллелизм "из коробки" без каких либо дополнительных действий. Вдруг, кто не знает.
А блокировки никто нигде не отменяет

Ну, известные мне СУБД позволяют явно управлять транзакциями в процедурах - тут принципиальной разницы с серверами приложений нет..
Минимизировать update-транзакции надо независимо от технологии. MS SQL 2000 рекомендует )))