Лучшая практика: разместить нагрузку на SQL или веб-сервер?

Question

Я вебмастер для крупного американского университета. У нас много запросов на нашем веб-сайте, которые я создавал и отвечал за последние 7 лет или около того. Я встраивал все более сложные функции в наш веб-сайт, и всегда практиковал, чтобы возлагать как можно больше бремени программирования на наш многопроцессорный сервер Microsoft SQL - используя хранимые процедуры, представления и т. Д., И в том, что нельзя сделать с помощью PHP, ASP или Perl с веб-сервера IIS. Оба сервера являются очень мощными и способными машинами. Поскольку я так долго занимался этим один, и никто не мог провести мозговой штурм, мне любопытно, подходит ли мой подход к ситуациям с еще более высокой нагрузкой, которые у нас будут в будущем.

У меня такой вопрос: лучше ли на практике размещать бремя нагрузки на SQL-сервере, используя вложенные операторы SELECT, представления, хранимые процедуры и агрегатные функции, или мне следует выполнять несколько простых запросов и обрабатывать их с помощью сервера? боковые сценарии времени компиляции, такие как PHP? Продолжать держать или придумать лучший способ?

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

Спасибо за ваш совет и вклад.

Answer 1

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

Нет никакого смысла в том, чтобы сервер базы данных отправлял 1000 строк и использовал PHP для их фильтрации, если было бы достаточно предложения WHERE или предложения GROUP. Не оптимально вызывать базу данных для добавления двух целых чисел (SELECT 5+9 работает нормально, но php может сделать это сам, и вы сохраняете туда-обратно).

Возможно, вы захотите взглянуть на масштабируемость : какие части вашего приложения можно разделить на несколько процессов? Если вы все еще используете 2 слоя (script & db), там есть много возможностей для масштабирования. Но всегда сначала начинайте с узкого места .

Некоторые примеры: размещать статическое содержимое в CDN, использовать кеширование для своих страниц, читать о nginx и memcached, использовать nosql (mongoDB), рассмотреть возможность разделения, рассмотреть репликацию.

Answer 2

Мое мнение таково, что обычно (в основном) лучше отдавать разрешение на обработку веб-серверами. Две точки:

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

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

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

Answer 3

Я стараюсь делать как можно больше за пределами БД, рассматривая вызовы БД как дорогие / требующие много времени.

Например, при выполнении выбора таблицы пользователя с полями name_given и name_family я моготкормить запрос, чтобы получить столбец с именем full_name, созданный путем конкатенации.Но такого рода вещи можно легко сделать в модели на языке сценариев на стороне сервера (PHP, Ruby и т. Д.).

Конечно, бывают случаи, когда БД является более "естественным" местом длявыполнить операцию.Но в целом я больше склоняюсь к тому, чтобы нагрузить веб-сервер, и оптимизирую его многими методами, отмеченными в других ответах.

Answer 4

Во-первых, вы можете проверить, есть ли какая-либо нагрузка, которая может быть полностью удалена путем кэширования на стороне клиента (.js, .css, статический HTML и изображения), а также использования таких технологий, как AJAX, для частичного обновления экранов.- это снимет нагрузку как с веб-сервера, так и с сервера sql.

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