Оптимизация запросов к базе данных веб-страницы

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

В настоящее время для страницы требуется 18 (правильно восемнадцать) обращений к базе данных. Я уже использую объединения, и некоторые запросы объединены в UNION, чтобы свести к минимуму обращения к базе данных. Моя локальная машина разработки может справиться с этим (страница не медленная), однако я чувствую, что если я выпущу это в дикую природу, количество запросов быстро переполнит мою базу данных (MySQL).

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

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

[Изменить]

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


person morpheous    schedule 05.06.2010    source источник
comment
Эти вещи не так очевидны. Без анализа запросов это просто стрельба вслепую. То же самое и с вашими вопросами о производительности: без профилирования результатов это просто пустая болтовня. Производительность нельзя оптимизировать с помощью какого-то рецепта или магического числа. Это процесс. Дело сделать.   -  person Your Common Sense    schedule 05.06.2010


Ответы (4)


18 запросов db, вероятно, немного излишни, если только это не какой-то сложный портал; хотя, не зная на 100%, что это за страница и серверный код, трудно судить.

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

В первом случае убедитесь, что ваш сервер поддерживает общий пул подключений к БД (я предполагаю, что вы используете PHP, поэтому у меня нет практических советов, но и у Java, и у Perl есть способы добиться этого); и, конечно же, убедитесь, что при загрузке одной страницы повторно используется одно и то же соединение с БД для всей страницы.

Для последнего (меньше запросов) изучите:

  • Объединение всех запросов в один большой запрос с несколькими наборами результатов

  • Денормализация наборов результатов с помощью JOIN и UNION, как вы это уже делали.

Кроме того, рассмотрите возможность наличия промежуточного уровня между вашим веб-приложением и БД (memcache или сервер приложений, кэширующий данные).

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

ОБНОВЛЕНИЕ: Чтобы ответить скептику в комментарии, вот некоторая информация о стоимости соединений, особенно в отношении mysql.

http://mysql-dox.net/Sams-MySQL.Database.Design.and/0672327651/ch14lev1sec3.html (кеш Google)

person DVK    schedule 05.06.2010
comment
Вы уверены, что эти соединения, как вы их называете, действительно на что-то влияют? - person Your Common Sense; 05.06.2010
comment
OP открывает только одно соединение - person Your Common Sense; 05.06.2010

Ваш подход совершенно неверен.
В этих "путешествиях на бд" есть нехорошее.

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

person Your Common Sense    schedule 05.06.2010
comment
Совсем неправильно? Нет ничего плохого в том, чтобы убедиться, что вы совершаете как можно меньше поездок в базу данных, не так ли? Я согласен, что делать это любой ценой — плохая идея, но я бы не сказал, что его подход совсем неправильный... - person Abe Miessler; 16.06.2010
comment
@Abe, пытающийся оптимизировать количество запросов вместо качества, является неправильным подходом. Попытка оптимизировать что-либо без профилирования результатов — неправильный подход. Вот почему это называется совершенно неправильно. Вы когда-нибудь слышали слово профилирование? - person Your Common Sense; 17.06.2010
comment
Вы должны учитывать все аспекты производительности, когда пытаетесь настроить приложение/базу данных. Включая количество запросов, инициированных при загрузке страницы, И любое выполненное вами профилирование. - person Abe Miessler; 19.06.2010

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

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

person Abe Miessler    schedule 16.06.2010

18 запросов не проблема, если они быстрые и эффективные.

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

person NotMe    schedule 16.06.2010