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

Question

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

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

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

Answer 1

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

Answer 2

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

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

Answer 3

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

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

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

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

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

Я сам объектный парень, но я бы слегка наступил.

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

Answer 4

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

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

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

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