Передача бизнес-логики (c #) для транзакций (sql) улучшит производительность?

Question

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

1) получить все возможные маршруты (попадание в БД для получениявсе маршруты, включенные в решение)

2) Получить все возможные отправные точки

3) Построить двунаправленный граф, объединяющий все маршруты.

---- foreach начальная точка ----

4) Вычислить k-кратчайший путь, используя алгоритм Хоффмана Павли (мы ограничиваем это определенным числом путей ei: первые 10 путей сокращают пути)

----- foreach путь для фактической начальной точки -----

5) оценить маршрут, подсчитав, сколько ресурсов мы можем перенести с каждого узла маршрута напункт назначения

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

----- КОНЕЦ foreach для фактической начальной точки -----

----- КОНЕЦ foreach начальной точки ----

7) вернуть возможное решение, упорядоченное пунктуацией

Первая версия этой логики заняла ~ 1 мин для вычисления решений.Но во второй ревизии мы обнаружили, что у нас много проблем с Select N + 1, поэтому мы оптимизировали запросы (не все), и теперь каждый запуск занимает ~ 3-10 секунд, в зависимости от количества переменных.

Но теперь кто-то предложил передать всю эту логику для выполнения SQL и позволить SQL-серверу обрабатывать все эти вычисления, сказал он, поскольку все данные уже находятся на SQL-сервере, базе данных потребуется меньше времени для выполнения всех операций.расчет, избегающий всех выбранных проблем N + 1 и отложенной загрузки.Кроме того, он обеспокоен параллелизмом: несколько пользователей, использующих эту логику, приведут к остановке сервера приложений, но он сказал, что sql-сервер может очень хорошо справляться с такого рода нагрузками.

Мое мнение: возможно, мы должны попытаться оптимизировать все запросы, прежде чем пытаться передать 1500 строк логики c # в Transact SQL.И не говоря уже о том, что для некоторых вычислений мы используем сторонние библиотеки для двунаправленного графа и алгоритма Хоффмана Павли, которые недоступны в транзакции, либо нам нужно искать что-то еще, уже написанное в транзакции, или реализовывать всю эту логику самостоятельно.

ПРИМЕЧАНИЕ: мы используем Nhibernate в качестве ORM.

Answer 1

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

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

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

• Перенос ваших 1500 строк для кодирования в TSQL займет много времени.Вы можете использовать .NET CLR, если это последняя версия MSSQL, но по моему опыту это значительно медленнее, чем .NET на Windows Server

• Вытащить все своинеобходимые данные заранее, чтобы избежать выбора N + 1;получите все , что вам нужно, и объедините все это в соответствующий граф объектов.

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

Answer 2

Перемещение логики в SQL может помочь, но оно стоит:

• Поддержание SQL, который делает то же самое, что 1500 строк кода C #, - настоящий ад (100-строчные запросы, хранимые процедуры, которые устаревают после добавления новых функций и т.
• Отладка намного сложнее

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

Answer 3

Трудно дать представление о проблеме оптимизации, которая носит столь общий характер, но утверждение:

", поскольку все данные уже есть на SQL Server, для базы данных потребуется меньше времени, чтобы выполнить всерасчет "

не обязательно верен.Прямой порт вашего кода C # в t-sql будет по-прежнему выполнять столько же запросов, сколько потребуется для выполнения, если вы вообще не измените логику.Вы сэкономите время, которое требуется для передачи данных между сервером SQL и компьютером, на котором выполняется приложение, но является ли это узким местом или временем, которое требуется серверу SQL для фактического выполнения всех этих запросов?Насколько велики результаты каждого из этих запросов?

Другой вопрос: будет ли t-sql быстрее выполнять все вычисления, связанные с этим, в той степени, в которой они предполагают итерацию данных в таблицах и выполнение чего-либос этими данными?Я сомневаюсь.В зависимости от того, сколько времени фактически обрабатывается (а не ждет базы данных), это может быть даже медленнее.

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

Answer 4

Вот предложение:

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

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

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

Answer 5

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

Сторонние библиотеки могут быть включены в Transact SQL, если вы используете сборки CLR, так что это не проблема.

С точки зрения ресурсов, как правило, проще расширить серверы приложений, чем сервер баз данных (репликация?). Поэтому, если завтра эти вызовы перейдут в X или X 50 сегодняшних вызовов, уверены ли мы, что ваш сервер базы данных все еще будет выполнять вычисления и что-либо еще в приемлемое время?

С точки зрения производительности, вы снижаете время с 1 минуты до 5 секунд, просто оптимизируя SQL. Очевидно, что если вы использовали неоптимизированный SQL в одном только движке SQL, у вас все равно была разница, чем в использовании оптимизированного SQL - опять же в движке только для SQL.

Я бы предложил сосредоточиться на оптимизации SQL и движка на c #. Эти N + 1 случаи, я думаю, являются основой, и вы не можете получить запись до того, как завершите предыдущую. Все, что вы можете выбрать заранее, - это повышение производительности: лучше получить 10 записей с 3 вариантами выбора, возвращающими в общей сложности 1000 записей (с фильтрацией 10 в C #), чем с 10 вариантами выбора, возвращающими в общей сложности 10 записей.