Post #12237
610
☀Объяснение:
Почему бизнес-логика в хранимых процедурах — это проблема для масштабирования?
Блокировки и взаимоблокировки (deadlocks) – длительные процедуры держат блокировки на таблицах, что при росте нагрузки увеличивает количество взаимоблокировок.
Ограниченное масштабирование – база данных вертикально масштабируется тяжелее, чем приложения. Добавить ещё один сервер с копией БД (read replica) не поможет, если логика пишет данные.
Сложность тестирования – хранимые процедуры сложно версионировать, тестировать изолированно и отлаживать по сравнению с кодом приложения.
Связанность с СУБД – миграция на другую БД становится практически невозможной.
Правильный подход для микросервисной архитектуры:
Логика должна жить в приложении (микросервисах), а база данных выполнять только функции хранения и атомарных операций (CRUD).
Использовать паттерн «Transaction Script» или Domain Model в коде, а не в процедурах.
Для сложных операций, требующих атомарности на уровне БД, использовать пессимистические блокировки или оптимистические блокировки (версионирование) на уровне кода, а не процедур.
При необходимости гарантировать согласованность между несколькими сервисами – использовать Saga (цепочка локальных транзакций с компенсациями) вместо монолитной транзакции.
Пример антипаттерна (в процедуре):
sql
Что делают в современных системах:
python
Реальный пример:
В Amazon переход от монолитной базы с процедурами к микросервисам с логикой в коде позволил масштабировать отдельные сервисы независимо и сократить время релиза новых фич с недель до часов.
Что должен зафиксировать аналитик:
«Бизнес-логика должна быть реализована на уровне приложения, а не в хранимых процедурах БД».
«База данных должна использоваться только для хранения данных и базовых атомарных операций».
Вывод: Хранимые процедуры — это инструмент для узкоспециализированных задач (например, массовые расчёты), но не для основной бизнес-логики в микросервисной архитектуре. Аналитик, понимающий это, поможет команде избежать архитектурного тупика при масштабировании.
Почему бизнес-логика в хранимых процедурах — это проблема для масштабирования?
Блокировки и взаимоблокировки (deadlocks) – длительные процедуры держат блокировки на таблицах, что при росте нагрузки увеличивает количество взаимоблокировок.
Ограниченное масштабирование – база данных вертикально масштабируется тяжелее, чем приложения. Добавить ещё один сервер с копией БД (read replica) не поможет, если логика пишет данные.
Сложность тестирования – хранимые процедуры сложно версионировать, тестировать изолированно и отлаживать по сравнению с кодом приложения.
Связанность с СУБД – миграция на другую БД становится практически невозможной.
Правильный подход для микросервисной архитектуры:
Логика должна жить в приложении (микросервисах), а база данных выполнять только функции хранения и атомарных операций (CRUD).
Использовать паттерн «Transaction Script» или Domain Model в коде, а не в процедурах.
Для сложных операций, требующих атомарности на уровне БД, использовать пессимистические блокировки или оптимистические блокировки (версионирование) на уровне кода, а не процедур.
При необходимости гарантировать согласованность между несколькими сервисами – использовать Saga (цепочка локальных транзакций с компенсациями) вместо монолитной транзакции.
Пример антипаттерна (в процедуре):
sql
CREATE PROCEDURE create_order(p_user_id INT, p_items JSONB) AS $$
BEGIN
-- проверка остатков, расчёт скидки, списание, создание заказа
-- всё в одной транзакции
END;
$$ LANGUAGE plpgsql;
Что делают в современных системах:
python
def create_order(user_id, items):
with db.transaction():
# проверка остатков (SELECT FOR UPDATE)
# расчёт скидки (в коде)
# создание заказа (INSERT)
# публикация события (Kafka)
Реальный пример:
В Amazon переход от монолитной базы с процедурами к микросервисам с логикой в коде позволил масштабировать отдельные сервисы независимо и сократить время релиза новых фич с недель до часов.
Что должен зафиксировать аналитик:
«Бизнес-логика должна быть реализована на уровне приложения, а не в хранимых процедурах БД».
«База данных должна использоваться только для хранения данных и базовых атомарных операций».
Вывод: Хранимые процедуры — это инструмент для узкоспециализированных задач (например, массовые расчёты), но не для основной бизнес-логики в микросервисной архитектуре. Аналитик, понимающий это, поможет команде избежать архитектурного тупика при масштабировании.
