хм, будем знать
дополню, для тех кому интересно 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
Это мем такой про тру :) яро апельсины и яблоки я согласен.
Если операция отрабатывает мгновенно, то время просто минимально. 1 секунда простоя это не страшно.
Таблицу в 100Gb под активной вставкой изменить практически нереально, по этому схема на триггерах, + копирование диапазонами единственно возможный вариант в этом случае. Не представляю честно говоря как такую таблицу в 5.6 менять в онлайне, мне кажется что-нибудь отвалится.
Это на один поток, потом практически линейно масштабируются, по количеству ядер. 64 ядерных машин у нас нету, чтобы начались проблемы описываемые командой MySQL dev Team. Но 2000 эта не нетюненой БД с параметрами от 5.5, конечно же вполне допускаю, что в 5.6 и тем более в MariaDB ситуация может быть изменится, если поменять параметры инстанса. Да и честно говоря select 1 это просто тестирование работы query_cache. Для реальных тестов нагрузки это не годится, просто как первый тест показывающий сколько максимально можно выжать, чтоб не пытаться прыгать выше потолка.
В реальной системе мы упираемся в процедурное расширение MySQL, вызов процедуры для БД гораздо дороже обходится чем select 1, как показали тесты ничего выдающегося в 5.6 и 10.0 по этому вопросу добавлено не было.
Света, а ткните и меня пожалуйста там в графики Write Only или конкретно эффективности сброса грязных блоков, у Марка то ведь тесты и пояснения об опосредованном тестировании асинхронного page_cleaner. Я почему то прочитав статью подумал, что у них для 4.0.30 есть патч обеспечивающий реальный асинхронный сброс грязных блоков, а так как в других версиях его не наблюдается он и тестировал на этой версии.
Я о полезности и применимости в реальной жизни, поверьте копировать табличку online на триггерах все умеют. Просто в слоганах это звучит вот мы какие, а на деле от этого онлайна толку нет. Так что, как верно подмечено, это не тру онлайн :)
У меня вопрос, коль саппорт тим в треде. В Oracle при проведении online операции можно было поймать Snapshot too old если таблица была под активным DML и кончался UNDO. Так как MySQL версионная, можно ли поймать аналогичную ошибку при проведении online операции добавления колонки или же создания индекса? Или же достаточно выделить необходимый размер innodb-online-alter-log-max-size и другие внутренние структуры MySQL не используются?
Не берусь судить, но может это связанно с тем, что Facebook, представителем которого является Mark Callaghan (автор того самого исследования) работает на сильно переписанном и оптимизированном 4.0, а может с тем что при выходе новой версии этот алгоритм работал все хуже и хуже…
Тут я пожалуй соглашусь, так как все таки выполнить одну команду перед добавлением не затратно, просто надо это учитывать как ограничение. Спасибо за комментарий.
Copies Table? = YES, я как бы об этом и говорю, добавить то колонку к примеру можно, однако «so it is still an expensive operation.» Соответственно если выбрать только те строчки, в которых Copies Table? = NO получим как раз ровно 5 операций.
Частично согласен, причина этому — нежелание оставлять воду. Если какие-то моменты совсем не понятны, можете написать мне в личку, постараюсь конкретизировать конкретные абзацы, если пойму, что критика действительно конструктивна.
Пошел специально проверить, вдруг зарелизились.
Тоже жду этой версии, но статус девелоперской Альфы MariaDB 10.0.2-alpha Now Available не то, что позволяет ставить это СУБД на прод.
«Фреймворк для создания OLAP на триггерах»
1. может быть использован только создателем
2. совершенно бесполезен в конкурентной высоконагруженной системе
Чем вам обычный DDL не угодил, у вас так много таблиц, которые требуют агрегации и их число постоянно растет, чтобы разрабатывать для этого фреймворк? Даже в этом случае выгода сомнительно, поскольку предпоследний запрос в разы проще осмысления вызова 6-ти функций, для описания колонок. Сочувствую тому специалисту, который будет все это поддерживать после вас и будет вынужден использовать эти функции. Хотя думаю он свой велосипед напишет.
Не знаю как остальным, но к примеру мне общие слова ни о чем не говорят, а ссылки на алгоритмы тем более. В вашей статье я ожидал увидеть больше математики и больше объяснений, на интуитивно понятном уровне, конкретных используемых алгоритмов, для анализа выбранной вам задачи. В ней нет ни того ни другого. Я очень рад что вы так хорошо в этом разбираетесь, но наверное статья писалась о том чтобы мы по её ходу действия могли разобраться вместе с вами. Очень жаль, что я этого сделать не смог, тупею наверно, но все равно спасибо.
Именно пример подаваемый такими солидными компаниями и осуждается данным топиком, если уж Mail.ru можно писать mailware то почему нам, простым студентам нельзя? Чем мы хуже? Корпорации делают на этом деньги и мотивируют это тем что это не мы такие — это мир изменился. В чем вы вините бедного студента? В том что моральные устои общества в котором он воспитан давно пошатнулись и граница между черным и давно утеряна?
Сударь, не стоит ковыряться в чужом глазу — ищите бревна в своем и не переводите тему с больной головы на здоровую. Здесь мы ставим клеймо позора на Mail.ru.
Прочитал первый же совет, не понял, позвал коллегу, прочитали вместе — не поняли, пошли читать комментарии, дружно поржали дочитав статью вместе. Чувствую хабр, судя по оценкам, не понял настолько тонкого юмора.
дополню, для тех кому интересно
bugs.mysql.com/bug.php?id=68487 вся соль описана в это баге
Структура блокировок для метаданных (MDL) представляет из себя хэш мапу. Хеш функция используемая для составления этой мапы назначает близким аргументам — близкие значения при отображении. Это приводит к тому, что таблицы с одинаковыми именами находятся в одной части этой мапы. Так же данная функция используется в параллельной репликации (MTS) для распределения имен баз данных по тредам.
Несложно догадаться, что это создает повышенную конкуренцию за те участи хеш мапы, которые содержат максимально большое количество объектов. Задержки наблюдаются для структур:
Блокировки:
Если операция отрабатывает мгновенно, то время просто минимально. 1 секунда простоя это не страшно.
Таблицу в 100Gb под активной вставкой изменить практически нереально, по этому схема на триггерах, + копирование диапазонами единственно возможный вариант в этом случае. Не представляю честно говоря как такую таблицу в 5.6 менять в онлайне, мне кажется что-нибудь отвалится.
select 1это просто тестирование работыquery_cache. Для реальных тестов нагрузки это не годится, просто как первый тест показывающий сколько максимально можно выжать, чтоб не пытаться прыгать выше потолка.В реальной системе мы упираемся в процедурное расширение MySQL, вызов процедуры для БД гораздо дороже обходится чем
select 1, как показали тесты ничего выдающегося в 5.6 и 10.0 по этому вопросу добавлено не было.У меня вопрос, коль саппорт тим в треде. В Oracle при проведении online операции можно было поймать
Snapshot too oldесли таблица была под активным DML и кончался UNDO. Так как MySQL версионная, можно ли поймать аналогичную ошибку при проведении online операции добавления колонки или же создания индекса? Или же достаточно выделить необходимый размерinnodb-online-alter-log-max-sizeи другие внутренние структуры MySQL не используются?Тоже жду этой версии, но статус девелоперской Альфы MariaDB 10.0.2-alpha Now Available не то, что позволяет ставить это СУБД на прод.
1. может быть использован только создателем
2. совершенно бесполезен в конкурентной высоконагруженной системе
Чем вам обычный DDL не угодил, у вас так много таблиц, которые требуют агрегации и их число постоянно растет, чтобы разрабатывать для этого фреймворк? Даже в этом случае выгода сомнительно, поскольку предпоследний запрос в разы проще осмысления вызова 6-ти функций, для описания колонок. Сочувствую тому специалисту, который будет все это поддерживать после вас и будет вынужден использовать эти функции. Хотя думаю он свой велосипед напишет.
а как все радовались в 2008 году что мы не в Китае
Сударь, не стоит ковыряться в чужом глазу — ищите бревна в своем и не переводите тему с больной головы на здоровую. Здесь мы ставим клеймо позора на Mail.ru.
Скандалы, интриги, расследования!
странно, судя по описанию проект сделали быстро, дешево и у него 9 успешных запусков из 12-ти, действительно странно чем так гордится комманда SpaceX.