1. Система большая переписать сложно
2. В каждой системе свои проблемы, я оптимист, MySQL вроде стабильно идет вперед, иногда долго, иногда медлено, иногда в обратную сторону, но я надеюсь на лучшее
3. Новый проект пишем под PostgreSQL
… выше ответил
Разработчики сервера Percona, используют за основу тот же самый код. Накладывают на него свои патчи по usability и немного расширяют функциональность в плане мониторинга и бэкапирования. Вот и все. Три раза натыкаясь на баги MySQL искал их решение в перконе. После третьего, больше не ищу, хотя часть их кода считаю полезной.
Ядро данных СУБД то же самое, только выходит с задержкой в месяц после оригинального MySQL, ибо надо успеть наложить свои патчи на то, что написано. Так что и баги у них практически всегда аналогичны.
Для себя нашел статью интересной, но ряд советов из неё без пояснений можно смело назвать вредными.
К примеру советы про пул буферов. Для того чтобы менять параметры по сбросу буферного пула на диск и созданию множества пулов буферов, надо хотя бы в начале в performance_schema (к примеру) или в других средствах диагностики увидеть множественные ожидания мьютексов буферного пула. Каждый буферный пул имеет свой мьютекс и свой LRU список адресов загруженных в память буферов. Если в вашей системе всего 4 ядра, но индексы базы занимают 100Gb, вы никак не сможете работать с множеством буферных пулов. Просто не хватит процессоров или дисков, чтобы читать 4 LRU списка одновременно. А вот на 16 ядерной машине с 20 HDD конечно смысл имеется.
В пул буферов при пессимистическом раскладе должны помещатся не все файлы данных а хотя бы их индексы. Ибо для чего вам тогда HDD?
Увеличение размера табличного кэша без увеличения соответствующих настроек ОС невозможно (но вы увидете в логах предупреждение что этот параметр проигнорирован). При выставлении этого параметра в слишком большие значения более 20000 надо быть аккуратным. Ибо в кэше поиск происходит линейно. Есть шанс, что вы отгребете проблемы с поиском таблицы уже в нем.
Кидать временные файлы на диск в ОЗУ надо аккуратнее. Ибо файловая система tmpfs не поддерживает innodb. Завалите себе весь лог ошибками. Можно использовать только если во временных таблицых вы используете memory и myisam движки.
— прочитал статью
— полез на прод проверять max_allowed_packet = 134217728 read_buffer_size = 262144
— ???
— вспомнил что параметр нужен для full scan myisam
кто нибудь реально выставляет в read_buffer_size большие значения? (особенно с учетом давнего анализа работы параметра Петром Зайцевым) никак не могу придумать причины для реализации данного типа извращения, и как следствия причины которая сподвигла автора оригинальной статьи поймать этот баг.
Toad for MySQL, чем лучше? честно уже и не помню, но после осознанного тестирования в реальной среде купил я себе этот продукт только для PostgreSQL.
Toad for MySQL — тоже порядком продвинулся в 2011… не говоря про то, что он бесплатный ;)
Спасибо за статью, дает направление, однако хотелось бы видеть и личное мнение автора, ибо прочитав:
один из наиболее мощных инструментов, который сочетает в себе возможности MySQL Administrator, PHPMyAdmin и некоторые другие инструменты для администрирования и разработки баз данных
я несколько удивился, ибо данный инструмент явно проигрывает такми монстрам как EMS, dbForge, Toad однако полез на сайт и понял откуда это
SQLyog MySQL GUI is the most powerful MySQL manager and admin tool, combining the features of MySQL Administrator, phpMyAdmin and other MySQL Front Ends and MySQL GUI tools.
На главной странице. Самомнение компании — сложно назвать объективным :)
Ну и по фичам — то же самое. Я бы половину из них не заценил (дает возможность при отправке на сервер получать ответ в табличном виде) а некоторые вообще бы в минусы занес, но тут думаю дело в целевой аудитории, ибо нужны и более простые средстава разработки а не только навороченые тулзовины все фичи которых вы вряд ли будете использовать.
Надеялся увидеть в статье — информацию по дебаггингу, инвалидации схемы БД при внесении изменений, адекватность поддержки процедурного языка и др. реально полезный фичи в одной сводной таблице, с указанием "+" и "-", чтоб можно было одним взглядом понять, а не пора ли менять инструментарий разработки.
Но все равно статья полезная, часть приложений — даже ни разу не слышал.
Попробуйте EMS SQL Manager for PostgreSQL — гораздо функциональнее и удобнее SQLYog, правда вроде платный, и у него есть проблемы с форматированием сложных SQL конструкций, приходится использовать Tidycode PL/SQL formatter.
EMS отличный продукт для PostgreSQL, но для MySQL решение у них вышло неудачным, помню на вопрос почему я отказался от их продукта, заданный каким-то менеджером на мыло, я накатал целый лист формата A4 что именно у них не работает или работает не так как описано (правда это было год назад, может за это время что то и изменилось).
Абсолютно согласен. Есть разработчики для которых MySQL это основной инструмент, я один из них. Я занимаюсь только базами данных. При поиске инструмента я попробывал для себя все платные и бесплатные инструменты, существующие на тот момент. Toad for MySQL для меня получился наиболее удобным.
Работать с процедурами в других средах разработки — практически нереально, хотя бы по той банальной причине, что ни в одном из них нет нормального форматирования SQL для процедур. Toad же взял свои наработки из Toad for PL/SQL (oracle) — он в первых версиях даже назывался так же :)
Из явных минусов: не работает под Linux (приходится ставить виртуалку). При потере коннекта с БД — снимается только из процессов… жутко бесит. Версии 4+ были жутко глючные, сейчас вроде не вылетает при каждом чихе.
Так же хочу упомянуть такую штуку как DbVisualiser. После проектирования БД бывает необходимо визуально взглядом окинуть все, что было сделано. Очень часто при взгляде на схему БД сразу находишь явные ошибки, которые не видел раньше. Вот тут эта тулзовина совершенно бесподобна. Можно крутиить схему в любых ракурсах.
В таком случае извиняюсь, просто судя по тому, что что в MySQL вы использовали три конструкции для поиска я было решил, что вы ищете наиболее быстрый вариант для работы с БД.
совершенно некорректно сравнивать БД и специальные программные средства — работающие в памяти
для начала посмотрите как именно работает between в MySQL, в статье как раз показано как делать такое на БД habrahabr.ru/blogs/mysql/125467/
извинияюсь что ссылка на мой пост — зато на хабр.
А второе засуньте все индексы и таблицы в кэш и посмотрите на скорость — поверьте она вас приятно удивит (10000/sec для MySQL это далеко не предел)
Ну отнеситесь к этому как к топику зла :) а очень много статей, которые здесь пишут — написаны на обывательском уровне, просто надо потратить немного своего времени. В действительности профессиональных статей тут не так много, как кажется (за исключением некоторых блогов).
Комментариев конечно не по теме много, ну да ладно, и поболе бывало. А вот ализарщина это ИМХО совершенно некорректный шаблон, у него много нужных и качественных переводов.
Судя по скрину i53.tinypic.com/o5qlip.jpg там ежедневнеы бэкапы, так что ИМХО действия Anonymous в этот раз бесполезны
— данных производителей нету
— данных потребителей нету
— хостинг работает
Хотя обузоустойчивый хостинг конечно хорошо пропиарили… Фига себе 40 сайтов с детским порно безбоязненно хостить…
на сколько я понимаю если табличный кэш умещает все таблицы БД то таких перечитываний, при запросе таблиц INFORMATION_SCHEMA быть не должно, а что насчет парсинга запросов? т.е. я заметил что если мы к примеру запрашиваем select * from partitioned_table t1 where partition_key = 1
мы читаем статистику по всем партициям данной таблицы, по идее запоминаем её в табличном кэше так как происходит их открытие, однако если следом запустить select * from partitioned_table t1, partitioned_table t2 where t1.partition_key = 1 and t2.partition_key = 1
то статистика вновь будет перечитана, даже несмотря на выставление параметра innodb_stats_on_metadata = OFF
вроде она уже в share должна быть… не хватило уже сил разобраться что там не так…
Я атеист, и не придерживаюсь одной СУБД по идеологическим соображениям, но к сожалению я недостаточно знаю MS SQL — по причинам описанным выше, по этому не могу вести квалифицированную техническиую дискуссию о недостатках и достоинствах этого сервера.
Да и вообще ИМХО это удар ниже пояса, когда ты пишешь о проблемах в своей песочнице, а тебе в качестве выхода предлагают перейти в другую.
2. В каждой системе свои проблемы, я оптимист, MySQL вроде стабильно идет вперед, иногда долго, иногда медлено, иногда в обратную сторону, но я надеюсь на лучшее
3. Новый проект пишем под PostgreSQL
Разработчики сервера Percona, используют за основу тот же самый код. Накладывают на него свои патчи по usability и немного расширяют функциональность в плане мониторинга и бэкапирования. Вот и все. Три раза натыкаясь на баги MySQL искал их решение в перконе. После третьего, больше не ищу, хотя часть их кода считаю полезной.
К примеру советы про пул буферов. Для того чтобы менять параметры по сбросу буферного пула на диск и созданию множества пулов буферов, надо хотя бы в начале в performance_schema (к примеру) или в других средствах диагностики увидеть множественные ожидания мьютексов буферного пула. Каждый буферный пул имеет свой мьютекс и свой LRU список адресов загруженных в память буферов. Если в вашей системе всего 4 ядра, но индексы базы занимают 100Gb, вы никак не сможете работать с множеством буферных пулов. Просто не хватит процессоров или дисков, чтобы читать 4 LRU списка одновременно. А вот на 16 ядерной машине с 20 HDD конечно смысл имеется.
В пул буферов при пессимистическом раскладе должны помещатся не все файлы данных а хотя бы их индексы. Ибо для чего вам тогда HDD?
Увеличение размера табличного кэша без увеличения соответствующих настроек ОС невозможно (но вы увидете в логах предупреждение что этот параметр проигнорирован). При выставлении этого параметра в слишком большие значения более 20000 надо быть аккуратным. Ибо в кэше поиск происходит линейно. Есть шанс, что вы отгребете проблемы с поиском таблицы уже в нем.
Кидать временные файлы на диск в ОЗУ надо аккуратнее. Ибо файловая система tmpfs не поддерживает innodb. Завалите себе весь лог ошибками. Можно использовать только если во временных таблицых вы используете memory и myisam движки.
— полез на прод проверять
max_allowed_packet = 134217728read_buffer_size = 262144— ???
— вспомнил что параметр нужен для full scan myisam
кто нибудь реально выставляет в read_buffer_size большие значения? (особенно с учетом давнего анализа работы параметра Петром Зайцевым) никак не могу придумать причины для реализации данного типа извращения, и как следствия причины которая сподвигла автора оригинальной статьи поймать этот баг.
Toad for MySQL — тоже порядком продвинулся в 2011… не говоря про то, что он бесплатный ;)
я несколько удивился, ибо данный инструмент явно проигрывает такми монстрам как EMS, dbForge, Toad однако полез на сайт и понял откуда это
На главной странице. Самомнение компании — сложно назвать объективным :)
Ну и по фичам — то же самое. Я бы половину из них не заценил (дает возможность при отправке на сервер получать ответ в табличном виде) а некоторые вообще бы в минусы занес, но тут думаю дело в целевой аудитории, ибо нужны и более простые средстава разработки а не только навороченые тулзовины все фичи которых вы вряд ли будете использовать.
Надеялся увидеть в статье — информацию по дебаггингу, инвалидации схемы БД при внесении изменений, адекватность поддержки процедурного языка и др. реально полезный фичи в одной сводной таблице, с указанием "+" и "-", чтоб можно было одним взглядом понять, а не пора ли менять инструментарий разработки.
Но все равно статья полезная, часть приложений — даже ни разу не слышал.
Работать с процедурами в других средах разработки — практически нереально, хотя бы по той банальной причине, что ни в одном из них нет нормального форматирования SQL для процедур. Toad же взял свои наработки из Toad for PL/SQL (oracle) — он в первых версиях даже назывался так же :)
Из явных минусов: не работает под Linux (приходится ставить виртуалку). При потере коннекта с БД — снимается только из процессов… жутко бесит. Версии 4+ были жутко глючные, сейчас вроде не вылетает при каждом чихе.
Так же хочу упомянуть такую штуку как DbVisualiser. После проектирования БД бывает необходимо визуально взглядом окинуть все, что было сделано. Очень часто при взгляде на схему БД сразу находишь явные ошибки, которые не видел раньше. Вот тут эта тулзовина совершенно бесподобна. Можно крутиить схему в любых ракурсах.
для начала посмотрите как именно работает between в MySQL, в статье как раз показано как делать такое на БД
habrahabr.ru/blogs/mysql/125467/
извинияюсь что ссылка на мой пост — зато на хабр.
А второе засуньте все индексы и таблицы в кэш и посмотрите на скорость — поверьте она вас приятно удивит (10000/sec для MySQL это далеко не предел)
Комментариев конечно не по теме много, ну да ладно, и поболе бывало. А вот ализарщина это ИМХО совершенно некорректный шаблон, у него много нужных и качественных переводов.
гениальное решение… не знал что хорошую идею можно реализовать настолько криво
— данных производителей нету
— данных потребителей нету
— хостинг работает
Хотя обузоустойчивый хостинг конечно хорошо пропиарили… Фига себе 40 сайтов с детским порно безбоязненно хостить…
select * from partitioned_table t1 where partition_key = 1мы читаем статистику по всем партициям данной таблицы, по идее запоминаем её в табличном кэше так как происходит их открытие, однако если следом запустить
select * from partitioned_table t1, partitioned_table t2 where t1.partition_key = 1 and t2.partition_key = 1то статистика вновь будет перечитана, даже несмотря на выставление параметра
innodb_stats_on_metadata = OFFвроде она уже в share должна быть… не хватило уже сил разобраться что там не так…
Да и вообще ИМХО это удар ниже пояса, когда ты пишешь о проблемах в своей песочнице, а тебе в качестве выхода предлагают перейти в другую.