Комментарии 14
Если у вас оптимизация БД дошла до точки «лезть в исходники», то вы используете не свой инструмент не для своей задачи.
Оставьте мускулу простые задачки ведения блокнотика.
Для базы используйте СУБД с реальным ACID, реальным масштабированием и нормальным анализом планов запросов.
Оставьте мускулу простые задачки ведения блокнотика.
Для базы используйте СУБД с реальным ACID, реальным масштабированием и нормальным анализом планов запросов.
любитель постгреса детектед
суровое замечание, только не понял какой инструмент используется не для своей задачи? MySQL используется в очень крупных конторах, работающих с очень большим трафиком. Только вот разработка MySQL отстает сильно и часть кода приходится дописывать ручками. К примеру тот же анализ таблиц и индексов, который обещают в 5.6 уже давно написан в Google.
на данный момент MySQL является одной из лучшех open source БД, которая способна выполнять большое количество транзакций в секунду. И тем кто не может позволить себе купить Oracle с его мощными инструментами анализа и сверх навороченным оптимизатором приходиться использовать то что есть.
но в общем конечно замечание верное, ибо performance_schema в том виде в котором она есть, на данный момент в основе — инструмент разработчика. Хотя я вроде не сишник, а спокойно понимаю что написано в исходниках, думаю другим информация подобного рода тоже будет не лишней. Посмотреть самый верхний мьютекс и залезть в инет узнать что и как вроде несложная задача.
судя по оценкам и обилию комментариев, я так понимаю, большинство людей читающих этот блог с вами согласны… думал скинуть ещё пару статей подобного рода, но вижу, что таски такого рода не сильно интересны. В следующий раз постараюсь выбрать тему для поста «ближе к народу»
на данный момент MySQL является одной из лучшех open source БД, которая способна выполнять большое количество транзакций в секунду. И тем кто не может позволить себе купить Oracle с его мощными инструментами анализа и сверх навороченным оптимизатором приходиться использовать то что есть.
но в общем конечно замечание верное, ибо performance_schema в том виде в котором она есть, на данный момент в основе — инструмент разработчика. Хотя я вроде не сишник, а спокойно понимаю что написано в исходниках, думаю другим информация подобного рода тоже будет не лишней. Посмотреть самый верхний мьютекс и залезть в инет узнать что и как вроде несложная задача.
судя по оценкам и обилию комментариев, я так понимаю, большинство людей читающих этот блог с вами согласны… думал скинуть ещё пару статей подобного рода, но вижу, что таски такого рода не сильно интересны. В следующий раз постараюсь выбрать тему для поста «ближе к народу»
Не стоит. Очень интересно. Сам люблю полазить в глубинах.
Вот только дешевле взять более другую БД или более другое железо, чем тратить кучу времени на вот такие разбирательства.
Вот только дешевле взять более другую БД или более другое железо, чем тратить кучу времени на вот такие разбирательства.
Платить деньги за СУБД и за дорогое железо это не наши методы.
Наши это: оптимизация архитектуры, глубокое понимание проблемной области.
Тот же Oracle легко роняется обычними запросами, если их пишут криворукие программисты, или же администраторы настраивают так параметры, что жить на БД становится невозможно. На текущий момент performance_schema не готова к выходу в массы, но те кто желает понять как именно реагирует инстанс на изменение параметров — с радостью воспользуются тем инструментарием которые эта схема предоставляет.
Наши это: оптимизация архитектуры, глубокое понимание проблемной области.
Тот же Oracle легко роняется обычними запросами, если их пишут криворукие программисты, или же администраторы настраивают так параметры, что жить на БД становится невозможно. На текущий момент performance_schema не готова к выходу в массы, но те кто желает понять как именно реагирует инстанс на изменение параметров — с радостью воспользуются тем инструментарием которые эта схема предоставляет.
Скажите это Facebook. Вот уж блокнотик, так блокнотик :)
Товарищи апологеты, ну хватит уже приходить в блог MySQL и рекламировать другие СУБД. Ну в курсе все, в курсе, в каждом топике же обязательно найдется желающий обосрать MySQL в той или иной форме. Не мешайте другим обсуждать тот софт, который они по тем или иным причинам выбрали, пожалуйста. Хочется читать полезные коментарии по делу, а не холивары.
Автор, продолжайте пожалуйста тему, ваша информация очень востребована
Автор, продолжайте пожалуйста тему, ваша информация очень востребована
Спасибо за поддержку, честно говоря нулевая реакция на статью меня несколько удивила…
Несколько лет я занимался Oracle, и поверьте если делать на нем серьезные вещи, то в нем находиться столько багов, что сложно представить. На его оптимизатор начинаешь плеваться, постоянные ORA-600 (а их там знаете сколько) выискиваешь на metalink пихая туда корки от unix процессов. Как только начнинаешь юзать новые фичи — понимаешь что они нифига не работают так, как описано в документации, а если и работают, то крайне неоптимально!
Tweeter — работал на MySQL (раньше)
Facebook — работает на MySQL
Google — очень активно испольщует MySQL
К чему я все это? А к тому что у каждой БД есть свои недостатки, но если вы профессионал, то вы научитесь их обходить. Кончено проще сказать — переходи на другой софт, но поверьте мне это не панацея. Может статья и не простая и не всем удасться применить её на практике, но когда я попробывал проанализировать эту схему на одном из своих промышленных серверов я офигел:
— не правильно выбран движок для некоторых очень важных таблиц
— с кэшами драйвера JDBC какая-то жопа
— чекпойнты излишне агрессивны
— размер лог файлов задан неверно
и т.д.
Анализ данной схемы позволяет вам оценить на сколько верно вы выбрали архитектуру всего решения в целом, да потребуются дополнительные навыки, но а кому сейчас легко?
Несколько лет я занимался Oracle, и поверьте если делать на нем серьезные вещи, то в нем находиться столько багов, что сложно представить. На его оптимизатор начинаешь плеваться, постоянные ORA-600 (а их там знаете сколько) выискиваешь на metalink пихая туда корки от unix процессов. Как только начнинаешь юзать новые фичи — понимаешь что они нифига не работают так, как описано в документации, а если и работают, то крайне неоптимально!
Tweeter — работал на MySQL (раньше)
Facebook — работает на MySQL
Google — очень активно испольщует MySQL
К чему я все это? А к тому что у каждой БД есть свои недостатки, но если вы профессионал, то вы научитесь их обходить. Кончено проще сказать — переходи на другой софт, но поверьте мне это не панацея. Может статья и не простая и не всем удасться применить её на практике, но когда я попробывал проанализировать эту схему на одном из своих промышленных серверов я офигел:
— не правильно выбран движок для некоторых очень важных таблиц
— с кэшами драйвера JDBC какая-то жопа
— чекпойнты излишне агрессивны
— размер лог файлов задан неверно
и т.д.
Анализ данной схемы позволяет вам оценить на сколько верно вы выбрали архитектуру всего решения в целом, да потребуются дополнительные навыки, но а кому сейчас легко?
Нулевая реакция лишь потому, что вами поднятая тема слишком сложна и/или специфична для обычного веб-разработчика, которому что попроще да по эффективнее подавай. К тому же совершенно свежая фича MySQL в которой если и пытались разбираться, то единицы, а остальным просто нечего сказать по теме (как и мне в том числе, я лишь с удовольствием прочитал, положил в избранное и буду пробовать когда перейдем на 5.5/5.6).
Критерием полезности статьи на хабре я считаю лишь количество положивших статью в избранное.
Критерием полезности статьи на хабре я считаю лишь количество положивших статью в избранное.
Привет автору из далекого 2015 года.
Юные администраторы познают Дзен по вашей статье, так что рабора была проведена не зря. Кое-что, разумеется, поменялось, но для понимания что к чему в 5.5 статья актуальна.
Юные администраторы познают Дзен по вашей статье, так что рабора была проведена не зря. Кое-что, разумеется, поменялось, но для понимания что к чему в 5.5 статья актуальна.
И в 2016ом вашу статью читают :)
В попытках выявить деградацию производительности в 5.6 версии.
В попытках выявить деградацию производительности в 5.6 версии.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Введение в PERFORMANCE_SCHEMA