Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Граница между логикой в СУБД и на сервере прило...

CUSTIS
April 19, 2019

Граница между логикой в СУБД и на сервере приложений

Выступление Марии Щекочихиной, архитектора приложений, на MskDotNet Meetup #36 в CUSTIS (19 апреля 2019, Москва).

Видеозапись: https://www.youtube.com/watch?v=BqFCajUnyQ4.

CUSTIS

April 19, 2019
Tweet

More Decks by CUSTIS

Other Decks in Programming

Transcript

  1. Аннотация Все приложения работают с данными. Пока объем данных не

    слишком большой и приложение простое, не принципиально, где размещать бизнес-логику: в СУБД или на сервере приложений. С ростом объема данных и усложнением приложений появляется вопрос, где граница между логикой в СУБД и на сервере приложений. Когда C#-разработчику нужно звать на помощь SQL-разработчика? Всегда ли можно обойтись своими силами? 2
  2. План ▪ Контекст ▪ Где размещать бизнес-логику ▪ Критерии для

    анализа ▪ Смешанный вариант «и там и там» ▪ Выводы 3
  3. Историческая справка Двухзвенная архитектура «Клиент – Сервер» ▪ Большая часть

    бизнес-логики на клиенте ▪ БД не масштабируется, клиент становится сложным и тяжелым, проблемы с версиями клиентов ▪ Появилась необходимость в третьем слое ради масштабирования и балансирования нагрузки на слои 5
  4. Layer и tier Tier – физические слои: сервер приложений, клиент,

    СУБД Layer – логические слои: DAL (data access), BLL (business logic), presentation layer. Это способ организации кода 6 Business Logic Layer Data Access Layer DB Presentation layer Layer может быть распределен по нескольким физическим tier. В частности, сервер БД может содержать выделенный слой BLL Сервер приложений Клиент Сервер БД
  5. Пример расположения layer и tier ▪ Веб-приложение без своей БД

    ▪ Является оберткой к SAP-системе ▪ Слой BLL полностью расположен в SAP ▪ Данные в веб-приложение попадают из ФМ (похоже на ХП) ▪ Веб-приложение без слоя BLL, только DAL и клиентская логика 7
  6. План ▪ Контекст ▪ Где размещать бизнес-логику ▪ Критерии для

    анализа ▪ Смешанный вариант «и там и там» ▪ Выводы 8
  7. Пример. Только в БД Системы отчетности ▪ Интерфейс к БД,

    где нужно делать различные выборки ▪ Могут иметь промежуточный слой, в котором таблицы БД объединяются в логические объекты 11
  8. Проектирование ▪ На уровне архитектуры заложить, где будут находиться слои

    с бизнес-логикой ▪ Определить назначение каждого из этих слоев 12 Это задача архитектора
  9. Решение конкретных задач ▪ Опускаемся на уровень конкретной функции или

    задачи системы. Как мы можем решить задачу? ▪ Делаем оценку параметров задачи 13
  10. План ▪ Контекст ▪ Где размещать бизнес-логику ▪ Критерии для

    анализа ▪ Смешанный вариант «и там и там» ▪ Выводы 14
  11. Что оценивать ▪ Объем данных, передаваемых между слоями ▪ Потенциальный

    рост объема данных ▪ Сложность алгоритма получения и обработки ▪ Компетенции команды ▪ Наличие интеграционного слоя ▪ Процесс развертывания 15
  12. Объем данных ▪ Оценить объемы данных, которые будут считываться из

    БД ▪ Оценить потенциальный рост объема данных Зачем? ▪ Обработка 100 записей и обработка 1 млн записей – это разные задачи ▪ От объемов зависят физические мощности серверов (RAM, CPU, объемы дисков) 16 Оценку всегда проводить на реальных данных!
  13. Сложность алгоритма получения и обработки ▪ Насколько сложные преобразования нужно

    выполнить, сколько их, какого типа операции: выборка, группировка, какие-то сложные правила? ▪ Как их эффективнее выполнять? 19 Для каких задач эффективнее использовать C#, а для каких – SQL?
  14. Разница между SQL и C# ▪ SQL – декларативный язык,

    позволяет использовать оптимизацию ▪ C# – императивный 20
  15. Пример ▪ Требуется по запросу выполнять расчет показателей по данным

    из базы ▪ Алгоритм расчета зависит от настроек, хранящихся в базе. Алгоритм получения «готовых» настроек нетривиальный ▪ Объем настроек в «сыром» виде ~1 млн записей (на момент формирования требований) ▪ Жестких требований по времени расчета нет 21 Какой вариант решения вы бы выбрали: в БД, в приложении или смешанный?
  16. Пример. Как было у нас Задача полностью решалась на сервере

    приложений, перенесли в БД Было ▪ Считывали полностью таблицу, отдавали на сервер приложений, там делали обработку в поисках подходящих записей – ЦИКЛАМИ ▪ Объем увеличился с 1 млн строк до 12 млн ▪ Время работы увеличилось с 40 мин. до 3 часов Стало ▪ Из БД сразу отдавали только нужный объем ▪ Время работы: 3 мин 22 Почему сразу так не сделали?
  17. Компетенции команды Если в команде нет SQL-разработчика, то не стоит

    делать задачи на SQL. Даже те, которые кажутся «простыми» Последствия ▪ Недооценка сложности задачи ▪ Глупые ошибки ▪ Конструкции вида «view вызывает view» Что плохого в конструкции «view вызывает view»? 23
  18. View вызывает view Основная ошибка: использовать view для инкапсуляции и

    переиспользования кода ▪ Такой метод нужно применять очень аккуратно ▪ Для использования view в запросе нужно понимать, что лежит в основе view на всю глубину Последствия ▪ Сложности в анализе работы view ▪ Появление неочевидных зависимостей 24
  19. Как не надо делать: пример ▪ Цепочка зависимостей view V_Цветомодель_обогащенная

    ▪ Cost: 157 003 V_Цветомодель_обогащенная V_Цветомодель_рабочая V_Товар_обогащенный V_Цветомодель V_Товар V_Товар 25
  20. Как исправить ▪ Избавляемся от двойного обращения к V_Товар ▪

    Cost: 89 519 27 V_Цветомодель_обогащенная V_Товар_обогащенный V_Цветомодель V_Товар
  21. Наличие интеграционного слоя Нужно ли интегрировать приложение с другими? Каким

    образом? ▪ Интеграция через БД. Например, вызовы процедур или view –> располагаем слой BLL в БД ▪ Интеграция через веб-сервисы –> располагаем слой BLL на сервере приложений 29
  22. Пример ▪ Веб-приложение, интерфейс с большим количеством бизнес-правил ▪ Объемы

    данных до 100 тысяч ▪ Задача: на основе данных формировать xml по утвержденной форме 31 Какой вариант решения вы бы выбрали: в БД, в приложении или смешанный?
  23. Пример. Как было у нас ▪ Команда 2 разработка: js+c#

    и чистый sql ▪ Очень ограниченные сроки ▪ Формирование xml сделали в виде хранимой процедуры 32
  24. План ▪ Контекст ▪ Где размещать бизнес-логику ▪ Критерии для

    анализа ▪ Смешанный вариант «и там и там» ▪ Выводы 33
  25. Зачем может понадобиться перенос логики из приложения в СУБД? ▪

    Сокращение передаваемого объема данных между СУБД и сервером приложений ▪ Сокращение объема данных, которые попадают на обработку в приложение ▪ Работа с множествами ▪ Раскладка логики на блоки, которые выполняются наиболее подходящим инструментом 34
  26. Аргументы против смешанного варианта ▪ Усложняется отладка: когда все в

    одном месте, отладка проще ▪ Логика размывается, мы не всегда знаем, где искать Что на это можно ответить? 35
  27. Что ответить ▪ Универсального решения в этом случае нет ▪

    Всегда нужно анализировать ситуацию: смотреть на задачу, на данные, на объемы и т. д. ▪ По итогу принимать взвешенное решение, оптимальное для текущей ситуации 36
  28. Отладка ▪ Усложнение отладки зависит от квалификации участников и процесса

    разработки ▪ Если мы раскладываем логику на слои, то мы можем отлаживать эти слои независимо друг от друга. Таким образом упрощается поиск проблемных мест 37
  29. Размытие логики ▪ Нет ничего плохого в размытии логики, если

    мы понимаем, какие проблемы возникают при подходе «все в одном месте» ▪ Можно использовать подход с Linq, таким образом код будет «в одном месте» ▪ Нужно помнить, что реально выполнение разделено на 2 части: сервер приложения и запрос в БД 38
  30. Linq и ORM ▪ Разработчик полностью отгораживается от БД ▪

    Нет прозрачности запроса: мы не знаем, какой именно запрос будет отправлен в БД ▪ Запрос неявный, нет плана запроса, соответственно не можем отладить запрос – получаем непредсказуемый результат ▪ Нет явной границы между моментом вычитки данных (lazyload) 39
  31. С ORM или без ORM ▪ С ORM – до

    100 тыс. записей (выгружаемых на сервер приложения), объекты второго – третьего уровня вложенности ▪ Без ORM (или с микро-ORM) – все остальное 40
  32. Пример ▪ Пользовательский интерфейс, грид больше 20 колонок ▪ Информация

    собирается из 10+ таблиц (справочная информация, различные показатели со связанных объектов) ▪ Данные хранятся на низком уровне детализации, порядок 1 млн, делается агрегация до более высокого уровня, в результате на экране 3–4 тыс.строк ▪ Ограничение по времени открытия интерфейса – 3 минуты 41 Какой вариант решения вы бы выбрали: в БД, в приложении или смешанный?
  33. Пример. Как было у нас ▪ Интерфейс полностью построен на

    view ▪ View оптимизированы под выдачу экранов с конкретными наборами параметров ▪ Для ускорения выдачи результатов часть агрегации выполняется заранее 42
  34. План ▪ Контекст ▪ Где размещать бизнес-логику ▪ Критерии для

    анализа ▪ Смешанный вариант «и там и там» ▪ Выводы 43
  35. Когда звать SQL-разработчика ▪ Вычитка и работа с коллекциями больше

    1 млн записей ▪ Для получения нужного набора данных требуется больше 7–10 соединений (join) ▪ Преобразование коллекций одного типа в другой ▪ View вызывает view 44
  36. Итог ▪ Если благодаря SQL мы можем сократить объем данных,

    передаваемых в приложение, это нужно делать ▪ Важно всегда делать оценку реальных объемов данных ▪ Выгодно, когда C#-разработчик понимает SQL, работа всегда с данными, объемы данных и сложность растут по экспоненте ▪ Не существует универсального метода решения задач – в каждой ситуации нужно взвешивать все за и против 45