| |
| 2.39, Аноним (-), 20:30, 29/09/2015 [^] [^^] [^^^] [ответить]
| +/– |
ты бы ещё газетку бульварную почитал. Тупорылость архитектуры заключается в том что есть несклько вариантов хранения данных? Уже 3 года прошло, кстати 5.6 уже вышло, 5.7 выходит.
| | |
|
| 1.13, Аноним (-), 09:31, 29/09/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
Лучше бы делом уже занялись, в доках что не раздел, то restrictions and limitations, разработку всех нововведений забрасывают на полпути...
| | |
| |
| 2.14, leap42 (ok), 10:21, 29/09/2015 [^] [^^] [^^^] [ответить]
| –2 +/– |
 они и занимаются. или они, по-вашему, купили mysql чтобы развивать конкурента своей платной базе? mysql мёртв, just as planned.
| | |
| |
| |
| 4.25, Аноним (-), 13:54, 29/09/2015 [^] [^^] [^^^] [ответить]
| +/– |
Ага, всё висит недоделанное. По багтрекеру правят, откровенно говоря, какую-то хрень. Из 5.5 и 5.6 - партицирование нормально так и не доделано, банальные вьюхи работают отвратительно. Движок memory висит со всеми багами и ограничениями с прошлого века. У 5.7 единственная подававшая надежды вешь - query rewrite plugin реализована только для галочки. То, что предполагалось, и что получилось никак не сходится.
Слово "успешно" тут ну никак не применимо. Болотный затухший застой и никак иначе.
| | |
| |
| 5.37, Аноним (-), 18:25, 29/09/2015 [^] [^^] [^^^] [ответить] | +2 +/– | ну так Вы бы и написали чего именно Вам не хватает для счастья и какие баги долж... большой текст свёрнут, показать | | |
|
|
|
| 2.15, Аноним (-), 10:25, 29/09/2015 [^] [^^] [^^^] [ответить]
| –1 +/– |
MySQL развиваться если и будет то за счёт других спонсоров, либо в случае когда эти ограничения будут мешать опробованию "новых фич" для основной БД Oracle.
| | |
| |
| 3.22, Аноним (-), 13:09, 29/09/2015 [^] [^^] [^^^] [ответить]
| –1 +/– |
> MySQL развиваться если и будет то за счёт других спонсоров, либо в
> случае когда эти ограничения будут мешать опробованию "новых фич" для основной
> БД Oracle.
бред. см.выше.
| | |
| |
| 4.26, Аноним (-), 13:55, 29/09/2015 [^] [^^] [^^^] [ответить]
| +/– |
Бред ваш бред. Только абсолютно не в теме человек будет утверждать что у MySQL нет проблем с развитием.
| | |
| |
| 5.34, Аноним (-), 18:02, 29/09/2015 [^] [^^] [^^^] [ответить]
| +/– |
> Бред ваш бред. Только абсолютно не в теме человек будет утверждать что
> у MySQL нет проблем с развитием.
ну и насмешили...
| | |
|
|
| 3.29, iPony (?), 15:16, 29/09/2015 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> для основной БД Oracle.
Ну Oracle SQL и MySQL это как лошадь и пони. Странно их напрямую сравнивать...
| | |
|
| 2.17, Аноним (-), 11:13, 29/09/2015 [^] [^^] [^^^] [ответить]
| –1 +/– |
Обидно что подававшая надежды MariaDB тоже повисла. Сейчас работают только Percona, но и то в рамках полной совместимости с MySQL и тоже очень медленно... На мой взгляд эта проблема куда критичнее всяких там оптимизаций запросов. Кому оптимизация нужна была, уже давно на postgresql.
| | |
| |
| 3.21, Аноним (-), 13:08, 29/09/2015 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Обидно что подававшая надежды MariaDB тоже повисла. Сейчас работают только Percona, но
> и то в рамках полной совместимости с MySQL и тоже очень
> медленно...
посмотрите на фичи добавленные в MySQL командой из Oracle: http://www.thecompletelistoffeatures.com/ и сравните их с несколькими патчами которые поверху добавляет Percona -- а затем сделайте для себя вывод кто реально "работает" и развивает MySQL на сегодня.
| | |
| |
| 4.27, Аноним (-), 14:04, 29/09/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
По вашему сайту ошибка 404. Если сравнивать багтрекер Percona и mysql, то у первого обсуждения и правки производятся намного активнее. Если в багтрекер mysql написать - то скорее всего на тебя там положат, в Percona не оставят без внимания.
> посмотрите на фичи добавленные в MySQL
Все эти фичи абсолютно сырые недоделки для галочки. В MySQL успешно создают видимость движухи. А как решаешься что-то использовать, либо недокументированное поведение, либо какая-та корявость не позволяют.
| | |
| |
| 5.35, Аноним (-), 18:10, 29/09/2015 [^] [^^] [^^^] [ответить] | –1 +/– | не знаю почему, но в ссылке появились ненужные символы, вставляю еще раз http ... большой текст свёрнут, показать | | |
|
|
|
|
| |
| 2.46, _KUL (ok), 00:34, 30/09/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Да, кто по часовому поясу ещё спать не будет, запишите, выложите на обменник какой-нибужь пожалуйста. Ну или раздачу на каком-нибудь торрентообменнике оформите, будьте добры.
| | |
|
| 1.18, vitalif (ok), 11:43, 29/09/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 > Использование оперативной памяти в mysql
Вот вот, пусть расскажут. А то сколько инструкций в интернетах начинаются с: сделайте вам buffer pool размером больше ваших данных...
| | |
| |
| 2.23, Аноним (-), 13:12, 29/09/2015 [^] [^^] [^^^] [ответить]
| –2 +/– |
>> Использование оперативной памяти в mysql
> Вот вот, пусть расскажут. А то сколько инструкций в интернетах начинаются с:
> сделайте вам buffer pool размером больше ваших данных...
ну если диски тормозят, то что еще тогда посоветовать?
| | |
| |
| |
| 4.36, Аноним (-), 18:13, 29/09/2015 [^] [^^] [^^^] [ответить]
| –2 +/– |
> innodb в синтетических тестах показывает увеличение расходов дискового пространства до
> 7 раз ( https://www.percona.com/forums/questions-discussions/mysql-and-percona-server/
> ). До 7 раз увеличивается и потребление памяти. И до 7
> раз увеличивается объем передаваемых данных. Поэтому если хочешь увеличить тормоза до
> 7 раз и занасиловать свой жесткий диск - используй innodb и
> зависай над buffer pool.
Ну так а в чем вопрос тогда? - пользуйте себе MyISAM на здоровье и дискам тоже будет спокойно ;-)
| | |
| |
| 5.52, Аноним (-), 12:37, 30/09/2015 [^] [^^] [^^^] [ответить]
| +/– |
Это два разных анонима. Да и было бы глупо самому себе так отвечать...
| | |
| |
| 6.58, Аноним (-), 16:15, 30/09/2015 [^] [^^] [^^^] [ответить]
| +/– | |
> Только не MyISAM, а TokuDB. MyISAM нифига не замена innodb.
TokuDB тоже не для всего хорош.. -- да, заливает данные он хорошо, а вот потянет ли он у вас OLTP нагрузку - это уже совсем другой вопрос.
| | |
|
|
|
| 3.42, vitalif (ok), 22:37, 29/09/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
так а причём тут диски? buffer pool это размер кэша в памяти. чтобы его сделать > данных, надо чтобы данные полностью влезали в память)) а нафиг в этом случае вообще что-то оптимизировать, если данных и так кот наплакал?
| | |
| |
| 4.47, Аноним (-), 01:05, 30/09/2015 [^] [^^] [^^^] [ответить]
| +/– |
> так а причём тут диски? buffer pool это размер кэша в памяти.
> чтобы его сделать > данных, надо чтобы данные полностью влезали в
> память)) а нафиг в этом случае вообще что-то оптимизировать, если данных
> и так кот наплакал?
если данных кот наплакал, то я вообще не понимаю в чем проблема тогда? ;-)
а Buffer Pool (BP, если мы про InnoDB здесь говорим) не только под сами данные используется.
| | |
| |
| 5.55, vitalif (ok), 13:17, 30/09/2015 [^] [^^] [^^^] [ответить]
| +/– | |
ну так вот и я не понимаю! :)
а все руководства по оптимизации mysql начинаются именно так - сделайте buffer pool больше размера данных!
| | |
| |
| 6.59, Аноним (-), 16:17, 30/09/2015 [^] [^^] [^^^] [ответить]
| +/– |
> ну так вот и я не понимаю! :)
> а все руководства по оптимизации mysql начинаются именно так - сделайте buffer
> pool больше размера данных!
хреновые руководства значит ;-)
нормальное руководство всегда будет начинаться с "it depends.." ;-)
| | |
|
|
|
|
|
| 1.19, Demo (??), 11:45, 29/09/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +4 +/– |
У меня вызывает когнитивный диссонанс. Оракел расскажет о производительности MySQL. :)
| | |
| |
| 2.24, Аноним (-), 13:16, 29/09/2015 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> У меня вызывает когнитивный диссонанс. Оракел расскажет о производительности MySQL. :)
ну раз только Oracle на сегодня и развивает производительность MySQL, то больше и рассказывать некому :) а любую полезную информацию всегда лучше получать из первых рук, не правда ли?
| | |
| 2.43, vitalif (ok), 22:38, 29/09/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
выступит какой-нить маркетоид и скажет - производительность мускля говно, айда все покупать оракл!!!)))
| | |
| |
| 3.65, Аноним (-), 12:51, 01/10/2015 [^] [^^] [^^^] [ответить]
| +/– |
> выступит какой-нить маркетоид и скажет - производительность мускля гoвнo, айда все покупать
> оракл!!!)))
Не свисти. Предположения будешь делать на кухне.
| | |
|
|
| |
| 2.31, Аноним (-), 15:42, 29/09/2015 [^] [^^] [^^^] [ответить]
| –1 +/– |
Обратите внимание - оптимальной производительностью, а не производительностью. Смысл слова "оптимально" совершенно неконкретен. Оракловцы смеются что все восприняли оптимально как быстро и т.п.
| | |
| |
| 3.32, Andrey Mitrofanov (?), 16:20, 29/09/2015 [^] [^^] [^^^] [ответить]
| +2 +/– |
> Обратите внимание - оптимальной производительностью, а не производительностью. Смысл
> слова "оптимально" совершенно неконкретен. Оракловцы смеются что все восприняли оптимально
> как быстро и т.п.
Продажники оракле настроют мой mysql оптимальным для "производительности" продаж oracle sql образом, так что ли?
| | |
| |
| 4.33, Аноним (-), 17:13, 29/09/2015 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> оптимальным для "производительности" продаж
Оптимальное решение — решение, которое по тем или иным признакам предпочтительнее других. Оптимальным может быть как увеличение продаж, так и их снижение. Не думаю что подобное подразумевалось.
> будет разбираться настройка MySQL для обеспечения оптимальной производительности
Если цель оракла снизить производительность, то снижающие производительность настройки и будут оптимальными. Хрень всё это.
| | |
| |
| 5.38, Аноним (-), 18:34, 29/09/2015 [^] [^^] [^^^] [ответить]
| –1 +/– |
>> оптимальным для "производительности" продаж
> Если цель оракла снизить производительность, то снижающие производительность настройки
> и будут оптимальными. Хрень всё это.
позволю себе лишь вам напомнить что более 95% пользователей MySQL никогда вообще ничего у MySQL не покупали, и даже копейки на поддержку не потратили. Зато гонору как правило всегда на миллион ;-))
| | |
| |
| 6.41, Аноним (-), 22:12, 29/09/2015 [^] [^^] [^^^] [ответить]
| +/– |
На самом деле да, всё так и есть. Просто очень четко чувствуется что MySQL купили чтобы убить. Темпы разработки несоизмеримы с количеством проблем. Может они что-то новое и вводят, для себя лично я ничего интересного в новых версиях не нахожу. А вот старые косяки не допиливают, из-за этого много полезных вещей просто не получается использовать.
| | |
| |
| 7.48, Аноним (-), 01:10, 30/09/2015 [^] [^^] [^^^] [ответить]
| +/– |
> На самом деле да, всё так и есть. Просто очень четко чувствуется
> что MySQL купили чтобы убить.
брехня.. ;-)
Вы за релизами следите, дела они сами за себя говорят.
> Темпы разработки несоизмеримы с количеством проблем.
> Может они что-то новое и вводят, для себя лично я ничего
> интересного в новых версиях не нахожу. А вот старые косяки не
> допиливают, из-за этого много полезных вещей просто не получается использовать.
Вот и напишите чего именно Вам не хватает в новых версиях, чего бы хотелось больше всего (с приоритетами), и какие именно косяки так давят на мозоль.
| | |
|
|
|
|
|
|
| |
| 2.45, Аноним (-), 23:43, 29/09/2015 [^] [^^] [^^^] [ответить] | +/– | Прошло более 10 лет, и что мы видим В MySQL есть раздражающие проблемы с транза... большой текст свёрнут, показать | | |
| |
| 3.50, Аноним (-), 01:24, 30/09/2015 [^] [^^] [^^^] [ответить] | +/– | gt оверквотинг удален А можно ли выложить где-либо этот тест на репликацию ... большой текст свёрнут, показать | | |
| 3.54, Аноним (-), 12:43, 30/09/2015 [^] [^^] [^^^] [ответить]
| –1 +/– |
У себя все проекты перевел на postresql, кроме тех, в которых используется memory движок для хранения данных в памяти и кэширования записи. Разработчики postresql в это смысле ведут себя упрямо. Они твердо уверены что лучше знают что нужно конечным пользователям.
| | |
| |
| 4.64, Аноним (-), 12:48, 01/10/2015 [^] [^^] [^^^] [ответить]
| +/– |
> У себя все проекты перевел на postresql, кроме тех, в которых используется
> memory движок для хранения данных в памяти и кэширования записи. Разработчики
> postresql в это смысле ведут себя упрямо. Они твердо уверены что
> лучше знают что нужно конечным пользователям.
Ни одни из разработчиков иначе не считают.
| | |
|
|
| 2.49, Аноним (-), 01:13, 30/09/2015 [^] [^^] [^^^] [ответить]
| +/– | |
> то то mailru дернул на PostgreSQL
так вот и UBER тоже "он из лесу вышел и снова зашел" -- перешли они на PostgreSQL, почесали репу, и назад на MySQL вернулись..
| | |
| |
| 3.57, Аноним (-), 14:12, 30/09/2015 [^] [^^] [^^^] [ответить]
| +/– |
Тут как, скорее всего просто неосилили, или стоимость миграции стала зашкаливать, поэтому решили оставить всё как есть. Похожий пример с CCP и их EVE Online, у ребят огромный кластер и 50+ тысяч онлайна в одном пространстве, но внезапно они использую MSSQL. Их как-то спросили, а чего на убогом MSSQL сидите, вам сам Бог велел какой-нибудь RAC. Они ответили, что миграция уже просто не возможна из-за привязки к фичам MSSQL.
| | |
| |
| 4.61, Аноним (-), 16:25, 30/09/2015 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Тут как, скорее всего просто неосилили, или стоимость миграции стала зашкаливать, поэтому
> решили оставить всё как есть.
насколько я понял - осилили, и стоимость не зашкаливала, просто PostgreSQL не потянул нагрузку.
| | |
|
|
|
| |
| 2.60, Аноним (-), 16:20, 30/09/2015 [^] [^^] [^^^] [ответить]
| +/– |
>>обеспечения оптимальной производительности
>>MySQL
> Выберете что-то одно.
неужели так до сих пор и не удалось увидеть MySQL с высокой производительностью?
ну к примеру хотя бы то что MySQL 5.7 теперь способен обрабатывать больше 500К SQL(!) запросов/сек. -- новости уже 2 года как минимум, видели?
| | |
| |
| 3.63, Аноним (-), 06:45, 01/10/2015 [^] [^^] [^^^] [ответить]
| +/– | |
> MySQL 5.7 теперь способен обрабатывать больше 500К SQL(!)
Galera != MySQL 5.7
| | |
| |
| 4.66, Аноним (-), 14:40, 01/10/2015 [^] [^^] [^^^] [ответить]
| +/– |
>> 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М запросов/сек.)
| | |
|
|
|
|
