Как снизить нагрузку на БД или какую БД использовать?
Добрый день, коллеги.
Есть проект, где используются несколько таблиц в БД, где записей от 100 тысяч до миллиона (и количество записей будет расти, причем значительно). Пол года он проработал с mysql + pdo - проблем никаких не было, начала расти нагрузка на процессор, но заказчик сказал "работает - не трожь". Сейчас проект переходит другому заказчику, сайт уже знатно подтормаживает и естественно это никого не устраивает.
Не знаю, какие параметры важны, чтобы было понятно насколько все плохо и что менять, задавайте, пожалуйста, уточняющие вопросы.
Мой вопрос - как быстро снизить нагрузку на БД, наверняка же тот же mysql не предназначен для работы с 100 записями и не более?
Если менять mysql на что-то другое - порекомендуйте, пожалуйста, на что и как с минимальными затратами переехать
анализ, что работает медленно (не "заказчик говорит медленно", а например "запрос для товаров, при выборке по акциям и покупателям" работает 2 секунды)
оптимизация кода, работающего с запросами (снижение числа запросов или более точные выборки) -- самая популярная проблема,
- снижал на этом только этапе в 1000-1500 раз,
- видел по 1500 запросов на страницу,
- видел 1 запрос, но на всю таблицу и потом по коду с этими данными гигантская работа, когда можно было сделать 2 ооочень шустрых запроса в БД с конечными данными :)
- запросы в цикле, очень много раз видел (гуглить проблема N+1)
оптимизация медленных запросов
Сделать запрос более быстрым, за счет или более точных выборок, или более верного синтаксиса, или стоит например раздробить на нексколько очень мелких, а бекендом все привести к нужному виду
индексы (сильно оптимизируют и бывают достаточны для решений многих бед со скоростью на большой выборке)
кеш на стороне БД
кеш на стороне приложения
денормализация некоторых данных, например предагрегация (например меню сайта и нужно для каждого вывести число твоаров, каждый пункт связан с категорией, категорий много, чтобы каждый раз по 100 категорий на подсчет товаров для каждой не делать -- делать это сильно реже и хранить в некой агрегирующей табличке)
С техниками типа шардинга/репликации никогда не работал
Миллионы записей - это совершенно обычный и, я бы сказал, крайне небольшой кейс для MySQL.
Самое быстрое: отпрофилировать запросы (например, performance_schema=1 и подключить sys-таблицы, они наполнятся данными по прошествии времени), найти неоптимизированные индексами и добавить недостающие индексы на этих таблицах.
а может дело быть в железе?
одно дело крутить миллионы записей на мелком VPS со слабым CPU и 1Gb RAM, а другое на выделенном сервере с нормальным CPU и 32Gb RAM ???
а может дело быть в железе?
одно дело крутить миллионы записей на мелком VPS со слабым CPU и 1Gb RAM, а другое на выделенном сервере с нормальным CPU и 32Gb RAM ???
Может дешевле купить мощный сервер, чем тратить деньги на программиста.
Pavel Denisov, так бы и сказали, что не знаете как влияет мощность сервера на эти лаги. и да, ваша позиция ясна, лучше потратить полмесяца программиста (40тр), чем арендовать помощнее сервак за 2-3тр. и это тоже в принципе не будет лучшим решением.
Evgeniy S, поддержу Pavel Denisov. Да, "тупо добавить мощностей" работает, но не всегда. Да, это может быть дешевле, но не всегда. Возьмите за руку сис. админа, либо еще кого-то кто разбирается и попросите его расказать, в чем же там проблема. И даже если сервер и вправду слабенький - не факт что дешевле будет наращивать мощности.
Профилирование запросов на сравнительно небольшом приложении в общем случае займёт от часа до суток, а не полмесяца. Результат анализа поможет исключить иные причины и даст установить, что именно нужно сделать для устранения проблемы, чтобы избежать риска покупки ресурсов, но сохранения тормозов.
"Лаги" могут возникать по многим причинам. CPU и RAM находятся в них не на первых местах.
--
одно дело крутить миллионы записей на мелком VPS со слабым CPU и 1Gb RAM
У меня есть проекты, где в MySQL крутятся десятки миллионов строк на VPS в 512MB RAM. Приложение осуществляет выборку за миллисекунды, не упираясь в CPU/RAM.
Средний
