Дизайнерское решение? 4-минутный отчет ... связывающий сервер

Question

У меня есть несколько отчетов, выполнение которых занимает до 4 минут в моем приложении RoR.С тех пор мои пользователи испытывают задержки с выполнением своих простых задач в системах, где система перестает отвечать.

Я все еще пытаюсь выяснить основную причину проблемы, чтобы увидеть, зависает ли отчетность и системаотносятся к.Кто-нибудь посоветует, как мне следует реструктурировать свой отчет, чтобы он не занимал 4 минуты?

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

Техническая информация:

• VPS работает с 384 МБ ОЗУ (будет ли это достаточным обходным решением?)
• Отчеты представляют собой комбинацию SQL-запросов с некоторыми тяжелыми сценариями Ruby, которые массируют содержимое, поэтому они отображаются в видеreadible fashion
• Таблицы БД содержат от 2000 до 30000 строк

Техническая информация отчета

1. DB-query-1 имеет 5внутренние соединения.Сначала он запускается для создания поискового хэша
2. DB-query-2 имеет 5 внутренних объединений.Он запускается один раз, и каждая запись его набора результатов пересекается
3. Для каждой записи (2.) выполняется DB-query-3 (содержащий 5 внутренних объединений)
4. Для каждой записи(2.), поиск хэша из (1.) обходится для выполнения некоторых вычислений

После написания этого запроса Anon о дополнительной информации я уже могу видеть строку вложенного цикла ...

Answer 1

30000 записей - ничто.Вы должны быть в состоянии выполнить полный экспорт / импорт базы данных такого размера менее чем за 4 секунды, поэтому что-то кажется неправильным:)

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

Некоторые общие советы по отчетам о производительности: Не используйте ORM-инструментдля отчетов, если требования к отчетам не являются очень тривиальными (в этом случае это будет называться список, а не отчет)Перейти на ручной SQL с отношением.

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

Делайте как можно больше работы внутри базы данных.(При использовании расширений это становится намного проще).Базы данных созданы для поиска, сортировки и агрегирования данных, и они делают это очень хорошо.Таблица с 1 000 000 строк при среднем размере строки 200 байтов будет занимать менее 200 МБ.Предполагая, что дисковая подсистема может выдавать 50 Мбит / с, потребуется 4 секунды, чтобы выполнить SUM (значение) по всей таблице.Это теоретический верхний предел.Если вам нужно больше, вам нужно предварительно вычислить данные, чтобы рабочий набор стал меньше (в Google это «агрегат» и «сведение»).

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

Не выполнять запросы в цикле.Если для выполнения запроса требуется 1 мс, выполнение 1000 запросов не займет 1 секунду.Каждый вызов должен «платить» за сетевую задержку, сортировку / удаление данных, потенциальные проблемы с блокировкой, анализ, выборку и т. Д.

(обновлено)

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

Сохранение пользовательских функций на минимуме.Они сбивают с толку оптимизатор и часто вызывают обработку строк (которая не масштабируется).