Какова связь между количеством запросов и размером запросов при оптимизации запросов к базе данных?

Question

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

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

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

Существует ли какое-либо практическое правило о том, сколько стоит каждый запрос, чтобы узнать, когда оптимизировать количество запросов в зависимости от их размера? Я пытался получить в Google данные объективного анализа производительности, но, к удивлению, не смог найти ничего подобного.

Очевидно, что это отношение изменится для таких факторов, как, например, когда база данных увеличится в размере, что сделает ее несколько индивидуализированной, но, конечно, она не настолько индивидуализирована, чтобы нельзя было вытянуть широкий смысл ландшафта?

Я ищу общие ответы, но для чего бы то ни было, я запускаю приложение на Heroku.com, что означает Ruby on Rails с базой данных Postgres.

Answer 1

Я твердо в лагере "получай только то, что тебе нужно, когда тебе это нужно".

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

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

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

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

Разработчики настолько привыкли к "модульности" всего, что вовсе не необычно, когда на самом деле получается конечная веб-страница, которая составляет сотню. или даже несколько тысяч обращений к базе данных для загрузки веб-страницы всего один раз .У нас есть коммерческий продукт, который, как мы измерили, совершает более 50 000 обращений к базе данных для одного действия.

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

1. Получение списка заказов из таблицы заголовка заказа
2. Программный цикл по заказам
3. Для каждого заказаВыполните запрос, чтобы получить все подробные записи заказа
4. Программно сложите элементы заказа, чтобы получить итоговую сумму, которая отображается в сетке

Звучит безумно, верно?Это чаще, чем вы думаете, особенно когда вы встраиваете привязанную к данным логику в отдельные веб-компоненты.Гораздо эффективнее:

1. Сделайте один вызов к базе данных, что-то вроде:

   SELECT oh.OrderID, oh.OrderDate, SUM(od.LineTotal) as OrderTotal
   FROM OrderHeader oh
   INNER JOIN OrderDetail od on oh.OrderID = od.OrderID
   

2. Отобразите результаты всетка.

Answer 2

Если вы ищете эмпирическое правило: по возможности фильтруйте, сортируйте и просматривайте страницу в запросе к базе данных. База данных оптимизирована для таких операций (операции над множествами).

Код приложения лучше всего резервировать для истинной бизнес-логики (и логики отображения и т. Д.).