Может ли «перенос бизнес-логики на уровень приложения» повысить производительность?

Question

В моем текущем проекте бизнес-логика реализована в хранимых процедурах (их более 1000), и теперь они хотят масштабировать ее по мере роста бизнеса.Архитекторы решили перенести бизнес-логику на уровень приложений (.net), чтобы повысить производительность и масштабируемость.Но они ничего не перепроектируют/переписывают.Короче говоря, те же SQL-запросы, которые выполняются из SP, будут запускаться из функции .net с использованием ADO.Net.Как это может дать какую-либо производительность?

Насколько я понимаю, нам нужно переместить бизнес-логику на уровень приложения, когда нам нужна независимость от БД или есть какая-то бизнес-логика, которую можно лучше реализовать на языке ООП, чем в механизме РСУБД (например, обход иерархии или некоторая обработка изображений, и т. д..).В остальных случаях, если нет сложной бизнес-логики для реализации, я считаю, что лучше хранить бизнес-логику в самой БД, по крайней мере, таким образом можно избежать сетевых задержек между уровнем приложения и БД.

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

Answer 1

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

Чтобы повысить производительность, вам нужно перенести некоторую работу на уровень приложения. Можете ли вы, например, кэшировать данные на сервере приложений и выполнять поиск или проверку без обращения к базе данных?

Answer 2

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

Очевидно, существует некоторый компромисс между выполнением логики на уровне базы данных и отправкой данных обратно на уровень приложений и их обработкой там.Затраты на доставку данных и затраты на обработку.Поскольку вы указываете, что стоимость и сложность бизнес-логики будут важным фактором, другим будет размер передаваемых данных.

Вполне возможно, что если уровень БД перегружен, то выгрузка обработки на другой уровень может обеспечить большую общую пропускную способность, даже если время отдельных ответов увеличится.Затем мы могли бы масштабировать уровень приложений, чтобы справиться с некоторой дополнительной нагрузкой.Скажете ли вы теперь, что производительность улучшилась (повысилась общая пропускная способность) или ухудшилась (что привело к увеличению времени отклика)?

Теперь подумайте, может ли уровень приложений реализовать интересные стратегии кэширования.Возможно, мы получим очень большой выигрыш в производительности — вообще отсутствие нагрузки на БД по некоторым запросам!

Answer 3

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

Заявления типа «Вся бизнес-логика принадлежит хранимым процедурам» или «Все должно быть на среднем уровне» обычно делаются людьми, чьи знания ограничены базами данных или объектами соответственно.Лучше совмещать и то, и другое, когда судите, и делать это на основе измерений.

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

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

Средние уровни имеют тенденцию приходить и уходить, а данные остаются навсегда.

Я сам объектный парень, но я бы действовал осторожно.

Это сложная проблема.Я не думаю, что черно-белые утверждения сработают в каждом случае.

Answer 4

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