Подскажите пожалуйста хорошие online курсы по MySQL performance optimization. Оказалось что наш програмист вообще нифига не шарит в partitioning и sql request tuning. База раздулась до немыслимых размеров, он в ручную посоздавал новые таблицы и предлагает нам пользовать юнион, плюс использует исам вместо иннодб и вся таблица лочится на время апдейта. Сам я больше по postgreSQL optimzation шарю, а по MySQL сходу ничего не нашли.
Судя по неполному описанию, ваш программист скорей всего всё правильно делает. MySQL это довольно странная поделка, особенно для тех, кто с чем-то другим работал. После работы с SQL сервером и Ораклом я сам удивился когда в MySQL был вынужден «вручную посоздавать новые таблицы». :) Для оптимизации MySQL сервера когда то давно нашёл неплохой скрипт, может он вам поможет как-то улучшить ситуацию: alexf.name/...-konfiga-mysql
у меня запрос который отвечал раньше за минуту, отвечает теперь за 5 минут. Что то таки да нетак )
за скрипт спасибо.
у меня запрос который отвечал раньше за минуту, отвечает теперь за 5 минут.объём базы прежний?
Смотрите план запроса.
PS И книжку в руки.
Адекватных, комплексных курсов нет.
Ниже советовали Карвина и книжку от ребят из Перконы: первая помогла бы вам на начальных этапах проектирования системы, вторая же поможет только после полного и всеобъемлющего её раскуривания. На русском языке есть
В остальном, разрозненные статьи на перконовском же блоге, презенташки Карвина и прочие локальные советы, вероятно, вам не помогут: необходимо представлять целостную картину возможностей оптимизации (железо, ос, мускул, запросы, etc.), и, я так понял, за довольно сжатые сроки. Потому, рекомендую всё же осилить High Perfomace MySQL.
Так же, как показывает практика, магической настройки конфига, решающей все проблемы, нет, потому вам для начала необходимо выделить все проблемные места («репорт долго генерится» и т.п.), проанализировать связанные с ними сущности\процессы\ситуации (что ещё может тормозить\сломаться) и после этого что то чинить. Так же, многое может зависеть от того, как у вас там всё устроено: простые и действенные оптимизации (чего либо) могут в текущей базе не прижиться by её design, так сказать.
Так же полезно будет в процессе чтения изучать соответствующие статьи с dev.mysql.com и искать инфу на сайте перконы, так как в доке часто можно встретить множество нюансов и тонкостей.
Оказалось что наш програмист вообще нифига не шарит в partitioning и sql request tuning.Подождите, и ваше решение проблемы — отправить его на курсы?!
Либо ваша проблема стоит совсем не так остро, как вы описываете, либо вы живёте на острове и больше вокруг нет других программистов, либо — ...
у нас есть еще пару систем с такой же функциональностью.
И что с этого? В вашем случае надо просто взять спеца на работу. Или хотябы пригласить с фриланса. А потом уже решите, что делать со своим программистом.
Вся инфа есть в интернете/форумах. Если человек не смог её найти — курсы не помогут.
хорошие online курсы по MySQL performance optimizationя какбы регулярно занимаюсь оптимизацией, но какие там курсы, очень мало даже толковых док по специфическим вещам.
SQL Antipatternsот Bill Karwin
нифига не шарит в partitioningв мускуле partitioning очень даже уныл, реальный выигрыш получается только при использовании отдельных винтов под разные partitions и то, только если база очень сильно «черпает» диск
он в ручную посоздавал новые таблицы и предлагает нам пользовать юниониногда это правильный подход. например архив и свежие данные в некоторых сценариях удобно разделить, ведь в архив не каждый день лазят :)
плюс использует исам вместо иннодбисам реально быстрее на read сценариях, без дополнительного описания жаловаться на это бесполезно, возможно єто реальный тюнинг который позволяет ускорить часто выполняемые запросы на треть
у нас база гдето 50 гигов, в postgreSQL партишинг создается через материнскую таблицу и чаилды, чаилды хранят данные для каждого месяца, на запросы к материнской таблице вешается тригер который подсоединяет нужное количество чаилдов. В последнем mySQL можна тоже делать партишенинг на основании строковых данных.
Одна из таблиц обновляется раз в 5 минут и время обновления около 2х минут, юзеры очень жалуются что долго ждут, поэтому возникли мысли про блокировки, оказалось что таблица по исам и ее всю лочит.
у нас база гдето 50 гигова сколько RAM на сервере ?
в postgreSQLподходы из постгри не работают с мускулем, как и наоборот :)
Одна из таблиц обновляется раз в 5 минут и время обновления около 2х минут, юзеры очень жалуются что долго ждутну тогда да, либо иннодб либо методом дополнительных таблиц — создаем копию оригинальной, обновляем, переименовываем
гм. тогда точно косяки , вам бы лучше кого отправить для review-fix
В постановке вижу две проблемы:
1. вы не точно понимаете значения performance optimizations
2. вы хотите достать звезду из болота, хотя вчера там еще было прозрачное озеро.
А по делу, оптимизация делается 2х видов:
1. оптимизация работы mysql сервера — это к сис-админу опытному (как сделано у нас)
2. тот же админ или кто-то со стороны может сказать вам — какие проблемы есть в вашей структуре БД. Вот на эту часть и надо взглянуть с программистом и дать ему почитать — что и как делается.
плюс использует исам вместо иннодб и вся таблица лочится на время апдейтасмотря, для чего таблица сделана, порой этот lock очень даже нужен :)
он у нас и админ и програмист, и еще чей то родсвенник кто его привел. На начальном этапе он справлялся нормально, потом когда обновление репорта начало занимать 5 минут появились вопросы, на вопросы он с умным видом отвечал что посмотрит. Но когда он создал какой то новый вьюв которой делал юнион для нескольких таблиц и все это очень медленно работало мне стало интерестно что же происходит и я пошел с ним побеседовать. Оказалось что он не спец по базам и он читает в интернете как что делать. Увольте его и взять когото другого не рассматривается из-за его крыши, поэтому мы найдем курсы и прокачаем его на новый уровень.
все это очень медленно работало мне стало интерестно что же происходит и я пошел с ним побеседовать. Оказалось что он не спец по базам и он читает в интернете как что делать.вам повезло. человек читает , значит разберется :)
Когда отчет строится долго — «скоро разберется» — может стать неактуальным.....
а топик-стартер в конторе кем является? ко-фундером, CTO, PM? или просто девелопером, который любит потыкать носом коллег?
я из другого отдела который пользует базу. Раньше это была наша база, я ее дизайнил, программировал и поддерживал. Потом босы взяли какогото дружбана и создали под него отдел «датабейс и тулз», дружбан набрал каких то людей на должности администраторов и они этим занимались около двух лет. Тыкать никого не хочу, за это орденов не дают. Курсы уже одобрены боссами потому что они тоже страдают.
Мда, неужели и в IT теперь кумовство?Ой, деточка, не хочу тя растраивать, но «кумовство» было есть и будет, не зависимо от страны и отрасли.
В IT это часто называют нетворкингом.
В IT это часто называют нетворкингом.Чета вспомнилось: «Не про..али, а аджайл».
наверное надо добавить, что под «читает» я подразумевал читать английские источники, если читает по-русски то тогда лучше его на курсы английского отправить
сочувствую, был у нас такой, но без крыши.
предложение такое — найти кого-то, кто бы глянул на вашу БД и сказал — куда копать.
Я полагаю, что с тюнингом настроек БД пока можно потянуть, замедлить выполнение запросов они сильно не смогут.
Если вас устроят устно-письменные комментарии — постараюсь помочь, стучите
Если у вас не высонагруженный сервис — методик для ускорения работы запросов меньше 10ка
я могу сам посмотреть и настроить, только нафиг оно мне сдалось. Компания большая — пусть платят за курсы.
ну вот видите, значит вы пытаетесь сделать работу менеджера.
я стараюсь ткунть в конкретные книги/статьи — отдельно взятые курс(ы) это всегда долго и малоэффективно.
Пару ссылок есть на курсы — удачи :)
Оказалось что он не спец по базам и он читает в интернете как что делатьНу да, за это сразу увольнять надо, ведь «спец по базам» знает абсолютно все про БД, SQL, может на память исходики мускуля цитировать...
)))
его должность предполагает компетенс по базам данных. Увольнять его никто не собирался, собираются отправить на курсы если найдутся подходящие.
Вы хотите найти курсы MySQL или рассказать, какой некомпетентный у вас админ? Если первое — зачем рассказы про крышу, родственников итд? Можно было бы просто написать «компания спонсирует курсы по MySQL Performance. Пожалуйста, посоветуйте такие курсы»
Но судя по всему, вам нужно второе — дружно обсасывать, какой же балбес ваш админ у него за спиной...
IMHO вас этот админ только что чем-то обидел и вы не нашли ничего лучше, чем разводить полемику и жаловаться на форуме
mobile mobileпохоже на конфликт разработчика и
5 часов назад
я из другого отдела который пользует базу. Раньше это была наша база, я ее дизайнил, программировал и поддерживал. Потом босы взяли какогото дружбана и создали под него отдел «датабейс и тулз», дружбан набрал каких то людей на должности администраторов и они этим занимались около двух лет.
Книжка вот хорошая — High Performance MySQL: Optimization, Backups, and Replication — www.amazon.com/...n/dp/1449314287
И ещё одна — SQL Antipatterns: Avoiding the Pitfalls of Database Programming — www.amazon.com/...s/dp/1934356557
(их все можно скачать, если поискать, или у меня попросить :))
И вот здесь записи вебинаров от Percona www.percona.com/.../mysql-webinars
Но книжки лучше )
спасибо за книги. Курсы нужны что бы его прокачать официально.
у перконы есть и курсы www.percona.com/.../mysql-training
И у Oracle есть курсы
Alexander Fedorov
Gremlin
Kostiantyn Reu
двадцатитрёхлетний сениор
Pavel Kruchina
Pavel Kruchina
anonymous
proger
Andrey Tkachenko
Andrey Tkachenko
Володимир Дубовий
Bogdan Shyiak
Sergii Voloshyn
Ilya Trushchenko
Olena Sharovar
Olena Sharovar
Борис Бажура
40 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів