Можно ли улучшить производительность SQL-сервера с помощью кэширования?

Question

Какое наиболее распространенное и простое в реализации решение для повышения скорости работы базы данных SQL Server 2008R2 и приложения .Net 3.5.

У нас есть приложение со следующими атрибутами:
- небольшое количество одновременных клиентов (~ 200 по МОСТУ).
- сложные математические операции на стороне сервера SQL
- мы имитируем что-то для защиты на уровне строк от Oracle (таким образом, вместо непосредственного запроса к таблицам мы используем tvf и хранимые процедуры) -Основная проблема заключается в том, что пользователи выполняют большое количество обновлений / вставок / удалений / вычислений, и они сходят с ума, потому что им нужно ждать перезагрузки страниц, пока эти действия выполняются.

Вопросы, на которые мне нужно ответить, следующие:

1. Что быстрее: возвращение всего набора данных с сервера SQL и выполнение математических функций на стороне C # или выполнение функций вычисления на стороне SQL (таким образом, не возвращая дополнительные столбцы). Или это зависит только от аппаратного обеспечения?
2. Улучшит ли кеширование производительность (например, если мы добавим кеш redis). Или решения для кэширования возможны только для большого количества клиентов?
3. Является ли плохой практикой предварительный расчет некоторых данных и их сохранение где-то в базе данных (поэтому, когда пользователь запросит, он уже будет рассчитан). Или это то, что кеширование должно делать? Если это не плохая практика, как настроить сервер SQL для выполнения вычислений при наличии доступных ресурсов?
4. Как кэширование может улучшить производительность, если ему все еще нужно перейти в базу данных и посмотреть, обновлены ли какие-либо записи?

общие предложения и комментарии также приветствуются.

Answer 1

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

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

Для начала я буду использовать ваши вопросы.Что быстрее?зависит от фактической агрегации, которую вы выполняете, если вы имеете дело с операциями над множествами, например, SUM / AVG столбца, сохраните его в SQL, с другой стороны, если вы обнаружите, что в процедуре есть курсор, переместите его вC #.Курсоры убьют вашу производительность!Вы спросили, является ли плохой практикой объединение данных в сторону и последующий запрос к этому репозиторию, это лучшая практика :).В итоге у вас будет одна база данных, обслуживающая транзакционных высокоскоростных клиентов, и другая база данных, хранящая агрегированную информацию, и она будет быстро и легко доступна для других ваших нужд.Переход к следующему шагу приведет к тому, что у вас будет хранилище данных, так что это именно то место, куда вы хотите идти, когда у вас много информации и вычислений.

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

Один из ваших лучших друзей для этой задачи -SQL Profiler, запустите трассировку на stmt: выполнено, чтобы увидеть, какая максимальная длительность / io / cpu, и выберите их сначала.

Удачи!