Компания Oracle сформировала новую ветку СУБД MySQL 8.4 и опубликовала корректирующее обновление MySQL 8.0.37. Сборки MySQL Community Server 8.4.0 подготовлены для всех основных дистрибутивов Linux, FreeBSD, macOS и Windows. Выпуск 8.4.0 отнесён к веткам с длительным сроком поддержки (LTS), который выпускаются раз в два года и поддерживаются 5 лет (плюс можно получить ещё 3 года расширенной поддержки)...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=61098
Переделать по-новой:
> SHOW BINARY LOGSSHOW BIT LOGS
> SOURCE_USERSOURCE_ENTITY
> SOURCE_HEARTBEAT_PERIODSOURCE_LONGLINE_PERIOD
и добавить в реплику функцию идентичности относительно источника!
Как у него с производительностью относительно MySQL 5.7 и 8.0?
Все плохо.
Со времен 5.6 производительность на 1 ядро упала на некоторых запросах до 50% - http://smalldatum.blogspot.com/2024/02/perf-regressions-in-m...
Что-то там ни слова про kernel mitigations.
А какая разница? Все тесты на одной и той же виртуалке в облаке запускали, т.е. окружение одинаковое.
Особо веселит, когда оракл полностью удаляет поддержку кеша запросов в 8 версии mysql, а в качестве оправдания что-то мямлит про "мы опросили наших кастомеров, и никто из них не заметил тормозов при переходе на 8 версию". В общем-то, я примерно так себе пользователей энтерпрайза всегда и представляю: существа, которые не замечают падения производительности "до 50%". Что ява, что другой энтерпрайз.
Это на самом деле не такая уж и проблема. Компенсируется через апгрейд железа.
Но железо необходимо собирать самому начиная с добычи кремния следуя канонам пердолинга.
> железо необходимо собирать самому начиная с добычи кремнияАлхимия какая-то ...
> В общем-то, я примерно так себе пользователей энтерпрайза всегда и представляю: существа, которые не замечают падения производительности "до 50%".Ну, просто оракл опрашивал пользователей Oracle RDBMS. Вполне логично, что они не заметили падения производительности мускуля.
Query cache - это реально была сырая и проблемная штука, вешала много приложений (прости Господи битрикс в частности), show processlist запускаешь на 5.7 и все становится понятно, правильно сделали что убрали, а минусов в производительности я не заметил, если приложение чуть чуть серьезней чем микробенчмарки.
как то вы странно про битрикс пишити.
Особенно странно выглядит ваше сообщение в свете того, что именно битрикс требует включённого кеша (без него производительность падает в разы) и официальная позиция битрикса в том, что кеш должен быть включён.
>не замечают падения производительности "до 50%". Что ява, что другой энтерпрайз- нормальный на этом месте подумал бы: а почему так? а не считал всех кроме себя идиотами. JavaEE дает кэширование на уровне ORM поэтому во многих случаях (тут зависит от адекватности разработчиков конечных приложений) провал производительности на уровне СУБД нивелируется
Там такой query cache, что с ним только хуже на серьезных нагрузках из-за блокировок.Его действительно надо выкинуть и переписать заново.
Но поскольку все, у кого серьезные нагрузки, и так его отключают и кэшируют в каком-нибудь memcache или redis, то, видимо, решили, что можно просто выкинуть :)
Можете в двух словах перечислить важные для вас плюсы MySQL над PostgreSQL?
То что есть работающая master-master репликация изкоробки.
А в MySQL ушли дальше простого определения auto-increment-offset на каждом сервере?
в двух версиях, притом оба солюшена работают через WAN, а в постгресе нет ни одной фри версии и для WAN ничего
Че за ерунда? чем отличается физический интерфейс WAN и LAN? Кроме его маркировки разным образом только для удобства неосиляторов?
Не знаю, что имел в виду penetrator, но наверняка речь не о разъёмчиках с надписями, а о специфике работы:
LAN - большая пропускная способность, низкие задержки
WAN - не такая уж большая пропускная способность (иногда совсем маленькая), большие (иногда огромные) задержки,
и для WAN люди пытаются (или нет) создать какие-то оптимизации.
> Не знаю, что имел в виду penetrator, но наверняка речь не о
> разъёмчиках с надписями, а о специфике работы:
> LAN - большая пропускная способность, низкие задержки
> WAN - не такая уж большая пропускная способность (иногда совсем маленькая), большие
> (иногда огромные) задержки,
> и для WAN люди пытаются (или нет) создать какие-то оптимизации.Нормально это решается дополнительными, опциональными решениями от профессионалов, на своем уровне сетевой модели OSI, так как разработчик СУБД может даже не знать что такое VLAN, что такое QoS, или специфики работы сетей ATM или ISDN - для примера. Ну и что он там оптимизировать сможет? Поэтому они вносят какие-то оптимизации, на своем уровне OSI - уровне СУБД, но по факту к WAN или LAN это не имеет никакого отношения. Так как фактически WANом или LANом - занимаются грамотные системные администраторы, строящие виртуальные сети компании с приоритезацией, и не только трафика СУБД.
Когда шардинг называют мастер мастером это полный провал матчасти.
именно, что multi-master с synchronous replication и immediate consistencyпритом Galera не является шардингом вообще share nothing решение
так что у тебя провал в квадрате
если в проекте нет поддержки PostgreSQL, но есть поддержка MYSQL, то это большой плюс.
а если есть поддержка и того и другого, чем это плохо? кроме избыточности?
Тем, что разработчик скорее всего использовал фреймворки и, возможно, даже абстракции наподобие ORM.Настоящие разработчики используют только низкоуровневые функции и строят запросы через интерполяцию строк!
> Тем, что разработчик скорее всего использовал фреймворки и, возможно, даже абстракции наподобие
> ORM.
> Настоящие разработчики используют только низкоуровневые функции и строят запросы через
> интерполяцию строк!я серьезно его спросил, а ты троллишь, ОРМ разные есть
а если есть поддержка и того и другого, то это два больших плюса.
Выбирать все равно буду то, что в проекте считается стабильным, имеет дополнительные плюшки или уже есть на серверах. Все это в зависимости от условий, типа зачем настраивать постгрес, если если кругом мускуль и в конкретно этой базе всего пара табличек будет жить
> если в проекте нет поддержки PostgreSQL, но есть поддержка MYSQL, то это большой плюс.Дайте угадаю, под "проектами" подразумеваются исключительно веб-морды на пыхе?
kmail, digikam, да и вот amarok вернулся.под "проектами" понимается то, что я буду использовать для себя или для дяди. Независимо от того, веб-морда это или fuse демон с бэкендом в виде базы
> kmail, digikam, да и вот amarok вернулся.К их разработчикам всего один вопрос: почему mysql, а не oracle?
А помянутый выше битрикс начал переползать на PG. Возможно, дело тут не совсем в ущербности mysql во всех ее инкарнациях и идеальности PG, но самому проекту это пойдет на пользу.
Раз уж тема зашла, подскажите, а в этих СУБД до сих пор нет точного отображения ошибок синтаксиса как Oracle при любом косяке в запросе, а не просто отписки "You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version"?
а то это похоже на разработку на Си 20-летней давности, когда скобку или точку с запятой не поставишь, и кажет вообще куда угодно, но не на реальную причину. Типа невалидный запрос целиком. Оракл с такими ситуациями справляется как любой современный компилятор.
Какой смысл сравнивать эти базы между собой в таком контексте?
а почему нет? иногда дофига времени уходит на поиск опечаток/ошибок
Ну вдруг есть внешние примочки, даже платные. Я после Оракула мучаюсь иногда.
Заодно вспомнил аргумент: мускул позволяет делать неправильные, не ANSI запросы, например, без GROUP BY в конце, при этом группируя
Ха! Фаны мыскля неправильные запросы наоборот, считают киллфичей проекта и вовсю пользуются этим. И очень страдают сами (и эксплуататоры их поделий), когда у разрабов мыскля иногда просыпается совесть и они правят парсер в сторону ужесточения проверки синтаксиса - привет разрабам Netup UTM!
Хз о чем ты. Как правило, в тексте ошибки указывается часть текста запроса перед которым ошибка синтаксиса.
А, ну значит вы не искушены случаями, ведь иногда он не пишет в чем именно ошибка. А Оракл пишет всегда, даже если запрос криво составлен, а не только отсутствует колонка или тип данных не тот
> А Оракл пишет всегда, даже если запрос криво составленТо есть вы спросили у БД не то, что хотели спросить?
Я конкретно спросил, что он не всегда указывает на кусок кода и правильную строку, а просто пишет текст из кавычек.
Вдруг есть какие-то улучшения или примочки. А постгрес я давно не тыкал.
На майсикле работает изкоробчный вротпресс. В целом этого достаточно.
Конечно, мускул очень круто вырос за 10 лет. Аналитические запросы и таблицы в ОЗУ это раньше прерогатива дорогих версий Оракула и MS-SQL была.
MySQL знаю и есть опыт, а PostgreSQL не знаю, опыта нет
Встроенный пул потоков
IDE нормальные есть и софт для администрирования у MySQL. Из коробки поддержка у фрейморков всяких и ORM (не люблю ORM, люблю чистый SQL). А с постгрес чаще плюшки платные. Я, конечно, не о сайтах на вордпрессе, а о серверах с сотнями гигов и терабайтами, 96 ГБ ОЗУ для OLAP и DWH и т.д., когда блокнота и консоли совсем мало
В PgSQL сейчас софт для работы с SQL построен на ElectronJS. Бесполезная и переусложненная СУБД.
> о серверах с сотнями гигов и терабайтами, 96 ГБ ОЗУ для OLAP и DWH и т.д.Хранить OLAP в реляционке?
А чего не в key-value? Вот redis, например. С таким подходом — идеальный выбор.
Acid?
Aerospike Community Edition?
ACID/CAP
Этот софт был создан до всяких редисов, а так не вопрос
Вот с этого и надо было начинать. Нет там никакого осознанного выбора БД, просто взяли то, что было популярно в нулевых.
И, естественно, тот несчастный, который поддерживает ЭТО двадцать лет спустя, уже не может ничего серьёзно поменять, потому что он один и бесконечно мал в сравнении с этой горой костылей, которая сотрёт его при любом неосторожном движении.
> чаще плюшки платные. Я, конечно, не о сайтах на вордпрессе, а о серверах с сотнями гигов и терабайтамиКупив перечисленное железо, странно сетовать на платность ПО.
Вообще-то Оракл стоил полтора ляма ещё 10 лет назад, и это стандартный.
А MS-SQL около 300к тоже без ограничений.
Мои вопросы не про конкретные случаи, разумеется.
> Удалены ...
> Удалены ...
> Удалены ...Неплохо так кодовую базу почистили!
А с другой стороны, это ж лтс, а мусор когда-то нужно выносить.
она наконец перестала потреблять ресурсы проца в простое или еще нет?
> Удалены системные переменные, в которых использовались слова "master" и "slave": Com_slave_start (следует использовать Com_replica_start); Com_slave_stop (Com_replica_stop); Com_show_slave_status (Com_show_replica_status); Com_show_slave_hosts (Com_show_replicas); Com_show_master_status (Com_show_binary_log_status); and Com_change_master (Com_change_replication_source).Я джва года ждал эту фитчу...
> Удалены связанные с репликацией SQL-выражения,
> которые ранее были объявлены устаревшими
> из-за использования неполиткорректной терминологииЗачем ненравящиеся толерастам выражения удалять? Это же испортит работу программ, в которых эти выражения используются.
Ну не нравится им эта их "неполиткорректность", пусть наваяют себе "политкорректные" выражения и заявят о том, что они хотели бы, чтобы в будущем пользователи использовали эти их "политкорректные" выражения, а старые выражения пусть не трогают - так они не будут выглядеть людьми, ломающими работу программ.
оно в 8.0.х так и было - сыпало warnings, сейчас депрекейтнули
А ещё отмена рабства повлияла на работу плантаций. Совсем не думают о честном бизнесе!
Это рыночек порешал. В индустриальную эпоху рабочая сила должны быть мобильной, чтобы оперативно реагировать на меняющиеся логистические условия. Где удобнее строить рудник/завод — там и строим. Стало неудобно (руда кончилась, возить сырьё/продукцию стало далеко) — забрасываем и уходим. А рабочая сила пусть сама за производством мигрирует, она же теперь свободная.
Как будто отмена рабства на что-то повлияла. Раньше работали за миску риса, теперь за денежный эквивалент миски риса.
Повлияла. Раньше хозяин кормил рабов, обеспечивал, защищал. А теперь хозяев и рабов нет, есть эксплуататоры и расходный материал, на который плевать, пусть хоть подыхают, новый материал на замену рождается каждый день.
Есть злые тёти в должности "вставь всем в ж...", которые не только работают за зарплату, но эту зарплату отрабатывают. Если они перестанут этим заниматься, то их уволят. А кто захочет быть уволенным, если работа не пыльная и высокооплачиваемая. Если бенефициары компаний захотят, то такая практика закончится практически мгновенно. Но они не хотят, ибо это отвлекает ваше внимание от возникновения правильных вопросов. Вот так миром и управляют.
Когда будет горизонтальное масштабирование из коробки?
Ndb cluster, не?
Тот, кто видел в Windows новый инсталлятор Oracle MySQL и сравнивал его с инсталлятором MariaDB, никогда не будет задавать глупых вопросов о "развитии" MySQL...
PostgresPro инсталяторы даже лучше.
https://repo.postgrespro.ru/std/std-14/win/
> Удалены системные переменные, в которых использовались слова "master" и "slave"Ясно! Остаюсь на Постгресе.
Держите нас в курсе!
> Прекращено прямое обновление с MySQL 5.7 до MySQL 8.4. Для перехода с MySQL 5.7 вначале теперь следует перейти на ветку 8.0, а уже затем обновить её до версии 8.4А почему вначале не на 8.3, а уже затем на более новую?