Comments 32
А как-нибудь менее сумбурно можно описать?
Можно, вот Вы и напишите, пожалуйста. А автору спасибо за статью, весьма познавательно.
Частично согласен, причина этому — нежелание оставлять воду. Если какие-то моменты совсем не понятны, можете написать мне в личку, постараюсь конкретизировать конкретные абзацы, если пойму, что критика действительно конструктивна.
Ну, я лично перешел на mariadb 10-ой ветки. На мой взгляд, по скорости работы, mysql уже давно отстаёт.
Пошел специально проверить, вдруг зарелизились.
Тоже жду этой версии, но статус девелоперской Альфы MariaDB 10.0.2-alpha Now Available не то, что позволяет ставить это СУБД на прод.
Тоже жду этой версии, но статус девелоперской Альфы MariaDB 10.0.2-alpha Now Available не то, что позволяет ставить это СУБД на прод.
Тоже перешли на марию 10 — уже больше месяца, полет нормальный. Скорость приятно порадовала, в некоторых случаях прирост производительности более чем в 10 раз.
У нас быстрее чем 2000 запросов в секунду в один поток через TCP ни mysql, ни mariadb не тянут. Даже на тестовом запросах «select 1».
А как на счет нескольких потоков?
Это на один поток, потом практически линейно масштабируются, по количеству ядер. 64 ядерных машин у нас нету, чтобы начались проблемы описываемые командой MySQL dev Team. Но 2000 эта не нетюненой БД с параметрами от 5.5, конечно же вполне допускаю, что в 5.6 и тем более в MariaDB ситуация может быть изменится, если поменять параметры инстанса. Да и честно говоря
В реальной системе мы упираемся в процедурное расширение MySQL, вызов процедуры для БД гораздо дороже обходится чем
select 1 это просто тестирование работы query_cache. Для реальных тестов нагрузки это не годится, просто как первый тест показывающий сколько максимально можно выжать, чтоб не пытаться прыгать выше потолка.В реальной системе мы упираемся в процедурное расширение MySQL, вызов процедуры для БД гораздо дороже обходится чем
select 1, как показали тесты ничего выдающегося в 5.6 и 10.0 по этому вопросу добавлено не было.В mysql benchmark() функция показывает, что можно выполнять 120 тыс. вызовов в секунду в одном потоке. В 60 раз медленнее получается, чем по сети.
результаты в «заключении» брались при выключенной Performance Schem' ой или нет?
InnoDB: ALTER TABLE… ONLINE
…
Ну вот собственно и все. Как видно из описания возможности предоставленные нам крайне скудны, будем надеяться, что в будущем ситуация улучшиться и изменения больших таблиц можно будет проводить без танцев с бубном, которые связаны с полным копированием таблицы при выполнении любой (с MySQL 5.6 читаем любой за исключением 5-ти) DDL команды.
А Вы эту табличку видели: dev.mysql.com/doc/refman/5.6/en/innodb-create-index-overview.html#innodb-online-ddl-summary-grid? Там, как бы, не пять операций. Помимо указанных: установка значения по умолчанию, add, drop, rename колонки, перемещение колонок, изменение параметров (NULL — не NULL, character set, etc.), удаление-добавление первичных ключей и это даже не всё.
Copies Table? = YES, я как бы об этом и говорю, добавить то колонку к примеру можно, однако «so it is still an expensive operation.» Соответственно если выбрать только те строчки, в которых Copies Table? = NO получим как раз ровно 5 операций.
Вы путаете понятие «online», то есть неблокирующий, и «без копирования».
Я понимаю, что с копированием операция занимает больше ресурсов и времени, но на мой взгляд то, что операция неблокирующая — это важнее. DDL в обычном приложении выполняется гораздо реже, чем SELECT и DML и я считаю, что некоторое снижение производительности DDL по сравнению с идеалом можно пережить, если на SELECT и DML это не влияет. В конце концов бесплатного сыра не бывает.
Вообще я поговорила с разработчиками из Runtime Team и они утверждают, что можно сделать «true online» операцию без применения копирования, но ценой будет общее увеличение времени выполнения запросов SELECT и DML. По-моему, это неприемлемо.
Я понимаю, что с копированием операция занимает больше ресурсов и времени, но на мой взгляд то, что операция неблокирующая — это важнее. DDL в обычном приложении выполняется гораздо реже, чем SELECT и DML и я считаю, что некоторое снижение производительности DDL по сравнению с идеалом можно пережить, если на SELECT и DML это не влияет. В конце концов бесплатного сыра не бывает.
Вообще я поговорила с разработчиками из Runtime Team и они утверждают, что можно сделать «true online» операцию без применения копирования, но ценой будет общее увеличение времени выполнения запросов SELECT и DML. По-моему, это неприемлемо.
Я о полезности и применимости в реальной жизни, поверьте копировать табличку online на триггерах все умеют. Просто в слоганах это звучит вот мы какие, а на деле от этого онлайна толку нет. Так что, как верно подмечено, это не тру онлайн :)
У меня вопрос, коль саппорт тим в треде. В Oracle при проведении online операции можно было поймать
У меня вопрос, коль саппорт тим в треде. В Oracle при проведении online операции можно было поймать
Snapshot too old если таблица была под активным DML и кончался UNDO. Так как MySQL версионная, можно ли поймать аналогичную ошибку при проведении online операции добавления колонки или же создания индекса? Или же достаточно выделить необходимый размер innodb-online-alter-log-max-size и другие внутренние структуры MySQL не используются?> Я о полезности и применимости в реальной жизни, поверьте копировать табличку online на триггерах все умеют.
Как показывает опыт — не все. Плюс лишние телодвижения лучше для досуга оставить.
> Так что, как верно подмечено, это не тру онлайн :)
Не-не-не, я говорила буквально можно сделать «true online» операцию без применения копирования, но это не значит, что текущий статус — это не true online. Копирование и online сравнивать — это, извините, как апельсины с яблоками.
Кстати, а устроит ли вас блокирующий ALTER, но без копирования в таблицу? То есть быстрый, но блокирующий. И почему это лучше, чем медленный, но неблокирующий?
Если ту же ссылку на InnoDB Team блог почитать, что Вы привели в статье, они пишут, что буфер отдельный. Так что вряд ли. Хотя вопрос, конечно, интересный.
Как показывает опыт — не все. Плюс лишние телодвижения лучше для досуга оставить.
> Так что, как верно подмечено, это не тру онлайн :)
Не-не-не, я говорила буквально можно сделать «true online» операцию без применения копирования, но это не значит, что текущий статус — это не true online. Копирование и online сравнивать — это, извините, как апельсины с яблоками.
Кстати, а устроит ли вас блокирующий ALTER, но без копирования в таблицу? То есть быстрый, но блокирующий. И почему это лучше, чем медленный, но неблокирующий?
У меня вопрос, коль саппорт тим в треде. В Oracle при проведении online операции можно было поймать Snapshot too old если таблица была под активным DML и кончался UNDO. Так как MySQL версионная, можно ли поймать аналогичную ошибку при проведении online операции добавления колонки или же создания индекса? Или же достаточно выделить необходимый размер innodb-online-alter-log-max-size и другие внутренние структуры MySQL не используются?
Если ту же ссылку на InnoDB Team блог почитать, что Вы привели в статье, они пишут, что буфер отдельный. Так что вряд ли. Хотя вопрос, конечно, интересный.
Это мем такой про тру :) яро апельсины и яблоки я согласен.
Если операция отрабатывает мгновенно, то время просто минимально. 1 секунда простоя это не страшно.
Таблицу в 100Gb под активной вставкой изменить практически нереально, по этому схема на триггерах, + копирование диапазонами единственно возможный вариант в этом случае. Не представляю честно говоря как такую таблицу в 5.6 менять в онлайне, мне кажется что-нибудь отвалится.
Если операция отрабатывает мгновенно, то время просто минимально. 1 секунда простоя это не страшно.
Таблицу в 100Gb под активной вставкой изменить практически нереально, по этому схема на триггерах, + копирование диапазонами единственно возможный вариант в этом случае. Не представляю честно говоря как такую таблицу в 5.6 менять в онлайне, мне кажется что-нибудь отвалится.
DROP FOREIGN KEY — только удаление, добавление констрейнта пока не осилили, но в качестве бонуса разрешили удалять констрейнт и связанный с ним индекс одной коммандой.
ALTER TABLE table DROP FOREIGN KEY constraint, DROP INDEX index;
Добавлять тоже можно, только при выключенных foreign_key_checks
Удивляет, что авторы решили сравнивать производительность 4.0 и 5.6 на графиках. Гораздо полезнее было бы увидеть разницу по сравнению с 5.0/5.1
Не берусь судить, но может это связанно с тем, что Facebook, представителем которого является Mark Callaghan (автор того самого исследования) работает на сильно переписанном и оптимизированном 4.0, а может с тем что при выходе новой версии этот алгоритм работал все хуже и хуже…
Не, Facebook точно не на 4.0 =) Я думаю, Марк просто тестирует разные версии, потому что в разных ветках были разные оптимизации. Так, многие пользователи очень долго оставались на 4.1, потому что эта версия работала быстрее для некоторых нагрузок.
PS: Я, например, баги тестирую сразу на 4-ёх ветках. 4.1 и 4.0 по умолчанию у меня не включены, но иногда тестирование и на них выдаёт интересные результаты.
PS: Я, например, баги тестирую сразу на 4-ёх ветках. 4.1 и 4.0 по умолчанию у меня не включены, но иногда тестирование и на них выдаёт интересные результаты.
Вам сюда: dimitrik.free.fr/blog/
Света, а ткните и меня пожалуйста там в графики Write Only или конкретно эффективности сброса грязных блоков, у Марка то ведь тесты и пояснения об опосредованном тестировании асинхронного page_cleaner. Я почему то прочитав статью подумал, что у них для 4.0.30 есть патч обеспечивающий реальный асинхронный сброс грязных блоков, а так как в других версиях его не наблюдается он и тестировал на этой версии.
Знаю человека, который на 5.6 перешел из-за поддержки FULLTEXT индексов на движке innodb.
хм, будем знать
дополню, для тех кому интересно
bugs.mysql.com/bug.php?id=68487 вся соль описана в это баге
Структура блокировок для метаданных (MDL) представляет из себя хэш мапу. Хеш функция используемая для составления этой мапы назначает близким аргументам — близкие значения при отображении. Это приводит к тому, что таблицы с одинаковыми именами находятся в одной части этой мапы. Так же данная функция используется в параллельной репликации (MTS) для распределения имен баз данных по тредам.
Несложно догадаться, что это создает повышенную конкуренцию за те участи хеш мапы, которые содержат максимально большое количество объектов. Задержки наблюдаются для структур:
Блокировки:
дополню, для тех кому интересно
bugs.mysql.com/bug.php?id=68487 вся соль описана в это баге
Структура блокировок для метаданных (MDL) представляет из себя хэш мапу. Хеш функция используемая для составления этой мапы назначает близким аргументам — близкие значения при отображении. Это приводит к тому, что таблицы с одинаковыми именами находятся в одной части этой мапы. Так же данная функция используется в параллельной репликации (MTS) для распределения имен баз данных по тредам.
Несложно догадаться, что это создает повышенную конкуренцию за те участи хеш мапы, которые содержат максимально большое количество объектов. Задержки наблюдаются для структур:
- MDL (деградация производительности на большом количестве сессий достигает 15%)
- MTS
- table definition cache
- performance_schema (деградация производительности увеличивается с 3.5 до 10%% как и в MySQL 5.5)
Блокировки:
- wait/synch/mutex/sql/MDL_map::mutex
- wait/synch/rwlock/sql/MDL_lock::rwlock
So, please, try to rename tables to get another view of the problem
Sign up to leave a comment.
Переход на MySQL 5.6, а стоит ли?