30 сентября в 16:00 (MSK) состоится (https://eventreg.oracle.com/profile/web/index.cfm?PKWebId=0x...) вебинар, на котором будет разбираться настройка MySQL для обеспечения оптимальной производительности, проведение анализа и оптимизации запросов для выявления и устранения узких мест в работе приложения.Некоторые темы, про которые будет рассказано на вебинаре:
- Использование оперативной памяти в MySQL.- Анализ текущего состояния сервера.- Скорость счетчика изменения.- Анализ эффективности механизма хранения InnoDB.- Анализ и установка настроек InnoDB (размер буферного пула (buffer pool), размер логов и другое).- Организация работы оптимизатора MySQL- Применение EXPLAIN для анализа плана запросов. - Инструменты для мониторинга, анализа и тюнингa запросов.
URL: https://eventreg.oracle.com/profile/web/index.cfm?PKWebId=0x...
Новость: http://www.opennet.me/opennews/art.shtml?num=43056
>тюнингa запросов.Как ускорить запрос? Использовать RDBMS c чуть менее тупоpылой архитектурой.
MySQL is bad by design.
http://grimoire.ca/mysql/choose-something-else#by-design
ты бы ещё газетку бульварную почитал. Тупорылость архитектуры заключается в том что есть несклько вариантов хранения данных? Уже 3 года прошло, кстати 5.6 уже вышло, 5.7 выходит.
Лучше бы делом уже занялись, в доках что не раздел, то restrictions and limitations, разработку всех нововведений забрасывают на полпути...
они и занимаются. или они, по-вашему, купили mysql чтобы развивать конкурента своей платной базе? mysql мёртв, just as planned.
зачем пургу-то гнать?
вот к примеру лишь список всех новых фич в MySQL 5.7 : http://www.thecompletelistoffeatures.com
а это про производительность MySQL 5.7 : http://dimitrik.free.fr/Presentations/MySQL_Perf-Benchmarks-...за всю свою историю MySQL не развивался так успешно как сейчас с Oracle, а последние релизы MySQL (5.5 и 5.6) однозначно названы "лучшими за всю историю".
Ага, всё висит недоделанное. По багтрекеру правят, откровенно говоря, какую-то хрень. Из 5.5 и 5.6 - партицирование нормально так и не доделано, банальные вьюхи работают отвратительно. Движок memory висит со всеми багами и ограничениями с прошлого века. У 5.7 единственная подававшая надежды вешь - query rewrite plugin реализована только для галочки. То, что предполагалось, и что получилось никак не сходится.
Слово "успешно" тут ну никак не применимо. Болотный затухший застой и никак иначе.
> Ага, всё висит недоделанное. По багтрекеру правят, откровенно говоря, какую-то хрень. Изну так Вы бы и написали чего именно Вам не хватает для счастья и какие баги должны быть устранены в первую очередь
> 5.5 и 5.6 - партицирование нормально так и не доделано, банальные
в 5.7 теперь Native Partitions у InnoDB, что с ними-то плохо ?
> вьюхи работают отвратительно. Движок memory висит со всеми багами и ограничениями
кому нужен Memory? (HEAP engine я так подразумеваю) - в 5.7 его слегка подправили, но его лучше переписать заново чем долбить старое.. - с приходом InnoDB Memory Tables будет и здесь счастье ;-)
> с прошлого века. У 5.7 единственная подававшая надежды вешь - query
> rewrite plugin реализована только для галочки. То, что предполагалось, и что
> получилось никак не сходится.да ну?.. bug report тогда шлите поскорее
кстати, код же ведь открыт, почему бы и самому не поучаствовать?> Слово "успешно" тут ну никак не применимо. Болотный затухший застой и никак
> иначе.ну-ну ;-)
даже и не знал что тут так весело ;-)
надо будет заходить почаще ;-)
MySQL развиваться если и будет то за счёт других спонсоров, либо в случае когда эти ограничения будут мешать опробованию "новых фич" для основной БД Oracle.
> MySQL развиваться если и будет то за счёт других спонсоров, либо в
> случае когда эти ограничения будут мешать опробованию "новых фич" для основной
> БД Oracle.бред. см.выше.
Бред ваш бред. Только абсолютно не в теме человек будет утверждать что у MySQL нет проблем с развитием.
> Бред ваш бред. Только абсолютно не в теме человек будет утверждать что
> у MySQL нет проблем с развитием.ну и насмешили...
> для основной БД Oracle.Ну Oracle SQL и MySQL это как лошадь и пони. Странно их напрямую сравнивать...
Обидно что подававшая надежды MariaDB тоже повисла. Сейчас работают только Percona, но и то в рамках полной совместимости с MySQL и тоже очень медленно... На мой взгляд эта проблема куда критичнее всяких там оптимизаций запросов. Кому оптимизация нужна была, уже давно на postgresql.
> Обидно что подававшая надежды MariaDB тоже повисла. Сейчас работают только Percona, но
> и то в рамках полной совместимости с MySQL и тоже очень
> медленно...посмотрите на фичи добавленные в MySQL командой из Oracle: http://www.thecompletelistoffeatures.com/ и сравните их с несколькими патчами которые поверху добавляет Percona -- а затем сделайте для себя вывод кто реально "работает" и развивает MySQL на сегодня.
По вашему сайту ошибка 404. Если сравнивать багтрекер Percona и mysql, то у первого обсуждения и правки производятся намного активнее. Если в багтрекер mysql написать - то скорее всего на тебя там положат, в Percona не оставят без внимания.
> посмотрите на фичи добавленные в MySQLВсе эти фичи абсолютно сырые недоделки для галочки. В MySQL успешно создают видимость движухи. А как решаешься что-то использовать, либо недокументированное поведение, либо какая-та корявость не позволяют.
> По вашему сайту ошибка 404. Если сравнивать багтрекер Percona и mysql, то
> у первого обсуждения и правки производятся намного активнее. Если в багтрекер
> mysql написать - то скорее всего на тебя там положат, в
> Percona не оставят без внимания.
>> посмотрите на фичи добавленные в MySQL
> Все эти фичи абсолютно сырые недоделки для галочки. В MySQL успешно создают
> видимость движухи. А как решаешься что-то использовать, либо недокументированное поведение,
> либо какая-та корявость не позволяют.не знаю почему, но в ссылке появились ненужные символы, вставляю еще раз: http://www.thecompletelistoffeatures.com/
а насчет сырых недоделок: т.е. Facebook, Twitter, Google, LinkedIn, Booking.com, и т.д. -- все они MySQL используют тоже "лишь для видимости" ?
и я так понимаю Вы уже отсылали bug reports в MySQL, какой конкретно? и кто на него положил?
(и еще мне интересно: а до Oracle как дела обстояли? неужели лучше?)
Ctrl + F -> percona -> Нет соответствий
никто не подскажет планируется ли делать запись вебинара?
Да, кто по часовому поясу ещё спать не будет, запишите, выложите на обменник какой-нибужь пожалуйста. Ну или раздачу на каком-нибудь торрентообменнике оформите, будьте добры.
> Использование оперативной памяти в mysqlВот вот, пусть расскажут. А то сколько инструкций в интернетах начинаются с: сделайте вам buffer pool размером больше ваших данных...
>> Использование оперативной памяти в mysql
> Вот вот, пусть расскажут. А то сколько инструкций в интернетах начинаются с:
> сделайте вам buffer pool размером больше ваших данных...ну если диски тормозят, то что еще тогда посоветовать?
innodb в синтетических тестах показывает увеличение расходов дискового пространства до 7 раз ( https://www.percona.com/forums/questions-discussions/mysql-a... ). До 7 раз увеличивается и потребление памяти. И до 7 раз увеличивается объем передаваемых данных. Поэтому если хочешь увеличить тормоза до 7 раз и занасиловать свой жесткий диск - используй innodb и зависай над buffer pool.
> innodb в синтетических тестах показывает увеличение расходов дискового пространства до
> 7 раз ( https://www.percona.com/forums/questions-discussions/mysql-a...
> ). До 7 раз увеличивается и потребление памяти. И до 7
> раз увеличивается объем передаваемых данных. Поэтому если хочешь увеличить тормоза до
> 7 раз и занасиловать свой жесткий диск - используй innodb и
> зависай над buffer pool.Ну так а в чем вопрос тогда? - пользуйте себе MyISAM на здоровье и дискам тоже будет спокойно ;-)
Это два разных анонима. Да и было бы глупо самому себе так отвечать...
Только не MyISAM, а TokuDB. MyISAM нифига не замена innodb.
> Только не MyISAM, а TokuDB. MyISAM нифига не замена innodb.TokuDB тоже не для всего хорош.. -- да, заливает данные он хорошо, а вот потянет ли он у вас OLTP нагрузку - это уже совсем другой вопрос.
А есть основания полагать что не потянет?
так а причём тут диски? buffer pool это размер кэша в памяти. чтобы его сделать > данных, надо чтобы данные полностью влезали в память)) а нафиг в этом случае вообще что-то оптимизировать, если данных и так кот наплакал?
> так а причём тут диски? buffer pool это размер кэша в памяти.
> чтобы его сделать > данных, надо чтобы данные полностью влезали в
> память)) а нафиг в этом случае вообще что-то оптимизировать, если данных
> и так кот наплакал?если данных кот наплакал, то я вообще не понимаю в чем проблема тогда? ;-)
а Buffer Pool (BP, если мы про InnoDB здесь говорим) не только под сами данные используется.
ну так вот и я не понимаю! :)а все руководства по оптимизации mysql начинаются именно так - сделайте buffer pool больше размера данных!
> ну так вот и я не понимаю! :)
> а все руководства по оптимизации mysql начинаются именно так - сделайте buffer
> pool больше размера данных!хреновые руководства значит ;-)
нормальное руководство всегда будет начинаться с "it depends.." ;-)
У меня вызывает когнитивный диссонанс. Оракел расскажет о производительности MySQL. :)
> У меня вызывает когнитивный диссонанс. Оракел расскажет о производительности MySQL. :)ну раз только Oracle на сегодня и развивает производительность MySQL, то больше и рассказывать некому :) а любую полезную информацию всегда лучше получать из первых рук, не правда ли?
выступит какой-нить маркетоид и скажет - производительность мускля говно, айда все покупать оракл!!!)))
> выступит какой-нить маркетоид и скажет - производительность мускля гoвнo, айда все покупать
> оракл!!!)))Не свисти. Предположения будешь делать на кухне.
Oracle в одном предложении с производительностью? Смешно.
Обратите внимание - оптимальной производительностью, а не производительностью. Смысл слова "оптимально" совершенно неконкретен. Оракловцы смеются что все восприняли оптимально как быстро и т.п.
> Обратите внимание - оптимальной производительностью, а не производительностью. Смысл
> слова "оптимально" совершенно неконкретен. Оракловцы смеются что все восприняли оптимально
> как быстро и т.п.Продажники оракле настроют мой mysql оптимальным для "производительности" продаж oracle sql образом, так что ли?
> оптимальным для "производительности" продажОптимальное решение — решение, которое по тем или иным признакам предпочтительнее других. Оптимальным может быть как увеличение продаж, так и их снижение. Не думаю что подобное подразумевалось.
> будет разбираться настройка MySQL для обеспечения оптимальной производительностиЕсли цель оракла снизить производительность, то снижающие производительность настройки и будут оптимальными. Хрень всё это.
>> оптимальным для "производительности" продаж
> Если цель оракла снизить производительность, то снижающие производительность настройки
> и будут оптимальными. Хрень всё это.позволю себе лишь вам напомнить что более 95% пользователей MySQL никогда вообще ничего у MySQL не покупали, и даже копейки на поддержку не потратили. Зато гонору как правило всегда на миллион ;-))
На самом деле да, всё так и есть. Просто очень четко чувствуется что MySQL купили чтобы убить. Темпы разработки несоизмеримы с количеством проблем. Может они что-то новое и вводят, для себя лично я ничего интересного в новых версиях не нахожу. А вот старые косяки не допиливают, из-за этого много полезных вещей просто не получается использовать.
> На самом деле да, всё так и есть. Просто очень четко чувствуется
> что MySQL купили чтобы убить.брехня.. ;-)
Вы за релизами следите, дела они сами за себя говорят.> Темпы разработки несоизмеримы с количеством проблем.
> Может они что-то новое и вводят, для себя лично я ничего
> интересного в новых версиях не нахожу. А вот старые косяки не
> допиливают, из-за этого много полезных вещей просто не получается использовать.Вот и напишите чего именно Вам не хватает в новых версиях, чего бы хотелось больше всего (с приоритетами), и какие именно косяки так давят на мозоль.
то то mailru дернул на PostgreSQL
Прошло более 10 лет, и что мы видим? В MySQL есть раздражающие проблемы с транзакциями между таблицами разных storage engine и у MySQL проблемы с репликацией. За эти десять лет у PostgreSQL появились подключаемые типы данных и индексы, а также есть репликация — т. е. преимущество MySQL было нивелировано, в то время как архитектурные проблемы MySQL остались и мешают жить. В MySQL 5.7 попытались решить проблему производительности репликации, распараллелив её. Поскольку проект на работе очень чувствителен к производительности репликации в силу своего масштаба, я попытался протестировать, стало ли лучше. Я нашёл, что параллельная репликация в 5.7 работает медленней однопоточной в 5.5, и лишь в отдельных случаях — примерно также. Если вы сейчас используете MySQL 5.5 и хотите перейти на более свежую версию, то учтите, что для высоконагруженных проектов миграция невозможна, поскольку репликация просто перестанет успевать выполняться.После доклада на highload, в Oracle приняли к сведению разработанный мной тест и сообщили, что попытаются исправить проблему; недавно мне даже написали, что смогли увидеть параллелизм на своих тестах, и выслали настройки. Если не ошибаюсь, при 16 потоках появилось незначительное ускорение по сравнению с однопоточной версией. К сожалению, до сих пор не повторил свои тесты на предоставленных настройках — в частности потому, что с такими результатами наши проблемы всё равно остаются актуальными.
Точные причины такой регрессии производительности неизвестны. Было несколько предположений — например, Кристиан Нельсен, один из разработчиков MariaDB, у себя в блоге писал о том, что могут быть проблемы с перфоманс-схемой, с синхронизацией тредов. Из-за этого наблюдается регрессия в 40%, которая видна на обычных тестах. Oracle-разработчики это опровергают, и меня даже убедили, что её нет, видимо, я вижу какую-то другую проблему (и сколько же их всего?).
>[оверквотинг удален]
> версией. К сожалению, до сих пор не повторил свои тесты на
> предоставленных настройках — в частности потому, что с такими результатами наши
> проблемы всё равно остаются актуальными.
> Точные причины такой регрессии производительности неизвестны. Было несколько предположений
> — например, Кристиан Нельсен, один из разработчиков MariaDB, у себя в
> блоге писал о том, что могут быть проблемы с перфоманс-схемой, с
> синхронизацией тредов. Из-за этого наблюдается регрессия в 40%, которая видна на
> обычных тестах. Oracle-разработчики это опровергают, и меня даже убедили, что её
> нет, видимо, я вижу какую-то другую проблему (и сколько же их
> всего?).А можно ли выложить где-либо этот тест на репликацию ? -- очень странно слышать про 40% разницу.
У меня до сих пор были как раз обратные сведения: пользователи переходили с 5.5 на 5.6 (даже еще до GA релиза) именно потому что репликация в 5.5 не тянула. (кстати, в 5.5 ведь даже binlog group commit отсутствует, очень странно слышать что 5.5 пилит лучше) -- возможно Ваш тест тогда что-то и прояснит..
У себя все проекты перевел на postresql, кроме тех, в которых используется memory движок для хранения данных в памяти и кэширования записи. Разработчики postresql в это смысле ведут себя упрямо. Они твердо уверены что лучше знают что нужно конечным пользователям.
> У себя все проекты перевел на postresql, кроме тех, в которых используется
> memory движок для хранения данных в памяти и кэширования записи. Разработчики
> postresql в это смысле ведут себя упрямо. Они твердо уверены что
> лучше знают что нужно конечным пользователям.Ни одни из разработчиков иначе не считают.
> то то mailru дернул на PostgreSQLтак вот и UBER тоже "он из лесу вышел и снова зашел" -- перешли они на PostgreSQL, почесали репу, и назад на MySQL вернулись..
Тут как, скорее всего просто неосилили, или стоимость миграции стала зашкаливать, поэтому решили оставить всё как есть. Похожий пример с CCP и их EVE Online, у ребят огромный кластер и 50+ тысяч онлайна в одном пространстве, но внезапно они использую MSSQL. Их как-то спросили, а чего на убогом MSSQL сидите, вам сам Бог велел какой-нибудь RAC. Они ответили, что миграция уже просто не возможна из-за привязки к фичам MSSQL.
> Тут как, скорее всего просто неосилили, или стоимость миграции стала зашкаливать, поэтому
> решили оставить всё как есть.насколько я понял - осилили, и стоимость не зашкаливала, просто PostgreSQL не потянул нагрузку.
поржал :))))))
>обеспечения оптимальной производительности
>MySQLВыберете что-то одно.
>>обеспечения оптимальной производительности
>>MySQL
> Выберете что-то одно.неужели так до сих пор и не удалось увидеть MySQL с высокой производительностью?
ну к примеру хотя бы то что MySQL 5.7 теперь способен обрабатывать больше 500К SQL(!) запросов/сек. -- новости уже 2 года как минимум, видели?
> MySQL 5.7 теперь способен обрабатывать больше 500К SQL(!)Galera != MySQL 5.7
>> MySQL 5.7 теперь способен обрабатывать больше 500К SQL(!)
> Galera != MySQL 5.7А при чем тут Galera ??
MySQL 5.7 без никакой Галеры и пр. (т.е. сам по себе (т.е. "single MySQL 5.7 Server instance")) спокойно обрабатывает более 500 тысяч SQL запросов/сек. (именно SQL запросов, т.к. не-SQL через Memcached plugin он вытягивает больше 1М запросов/сек.)
Ну и где записи взять то?