Компания Oracle сформировала новую ветку СУБД MySQL 9.0.0. Сборки MySQL Community Server 9.0.0 подготовлены для всех основных дистрибутивов Linux, FreeBSD, macOS и Windows. В рамках внедрённой в прошлом году модели формирования релизов, MySQL 9.0 отнесён к веткам "Innovation", к которым также будут отнесены следующие значительные релизы MySQL 9.1 и 9.2. Innovation-ветки рекомендованы для тех, кто хочет раньше получать доступ к новой функциональности, публикуются каждые 3 месяца и поддерживаются только до публикации следующего значительного релиза (например, после появления ветки 9.1 будет прекращена поддержка ветки 9.0). Примерно через год планируют сформировать LTS-релиз, который будет рекомендован для внедрений, которым необходима предсказуемость и длительное сохранение неизменного поведения. Следом за LTS-веткой будет сформирована новая Innovation-ветка - MySQL 10.0...Подробнее: https://www.opennet.me/opennews/art.shtml?num=61476
Скудновато для мажорной версии
Давно уже все пренебрегают семантическим версионированием и это скорее циферки для конечного пользователя
Это уже даже не маркетинг. А обезьянничество. Просто все так сделали и я тоже так сделаю.
А это по сути не мажорная версия. Это изменение схемы версионирования.Они решили, что 8.x будет stable, а в 9.x будут экспериментальные фичи. Короче, 8.x это RHEL, а 9.x это Fedora :-)
Это просто накрутка номера версии.
Удаление mysql_native_password - достаточно большое несовместимое изменение, чтобы прибавить единичку к мажорной версии.
Их тоже хромозилла покусала
После PostgreSQL как-то не очень...
не работает с эсодин? :-)
А есть с чем сабж работает? Не "посмотреть", а именно работает?
С вордпрессом же.
> не работает с эсодин? :-)Нет. Вообще с 1С дел не имею. Я больше на PHP пишу. Могу напрямую с базой работать без всяких ORM. При чём что с PostgreSQL, что с MySQL. Просто смотришь на некоторые привычные вещи, а они только в новых версиях MySQL. А эта версии ещё не скоро в дистрибутивах появятся.
> А эта версии ещё не скоро в дистрибутивах появятся.Именно эту проблему решает docker.
Хм... Читал, что СУБД в Docker - не для промышленного применения.
Это не так?
Что-то в Докер это для тестов и применения на 5 лиц максимум без особых запросов.
Тут БД - какой в Ж декор? У Вас бабла много проблемы с IO Вы просто зальете баблом? Заказчик знает?
> проблемы с IOБыли лет… Ох… Я уж забыл сколько тому назад, тогда в Линуксе ещё пространтсва имён толком не работали — IBM не дописал нужный код. Да, было дело, прям беда-беда, годилось для автотестов, и то не всех, ДБА производительность решения мерял вручную на отдельной железке, релизы из-за этого иногда на пару недель могли задержаться только так. Но сейчас-то какие проблемы? У меня самого пара базёнок на пару Тб с лишним в Кубере крутятся в контейнерах и нормально всё. Когда переносили с железа, тоже волновались не просядет ли QPS. Не просел. А админам работы убавилось. До переезда два отдела врукопашную дважды в год проверяли восстанавливается ли бэкап и проводили учения по подъёму упавшей БД. А сейчас всё это скрипт делает каждый месяц и пишет в мониторинг две галочки: восстановился ли бэкап и имеют ли смысл восстановленные данные. Но оно и не диво, по сути как раньше был сервер БД, так он и сейчас остался, с той лишь разницей, что раньше всё в одном пространстве имён сидело, а теперь у своё БД отдельное и диск прицеплен через банальный bind mount.
Если Docker под линуксом - то вполне нормально и СУБД и другие вещи там крутить. Единственный момент - максимальную производительность выжать не получится. Но не всем это надо.
> Я больше на PHP пишу.Время стереотипов про PHP-шников! (шутка)
> Могу напрямую с базой работать без всяких ORM.
Все так могут. Сложность в том, чтобы найти ORM/QueryBuilder, который будет заниматься миграциями, гарантиями корректности, и при этом не будет бесить своей ограниченностью
> не скоро в дистрибутивах появятся
А вот неосиляторство докера в 2024 -- это большой грех. Страшнее только то, что разработкой ты занимаешься тоже без докера -- с вагоном мусора на хост-системе
> Сложность в том, чтобы найти ORM/QueryBuilderЕсли про PHP, то Spiral ORM.
Да, там надо осилить, это цена гибкости.
Точнее, Cycle ORM, из фреймворка Spiral (от самого фреймворка зависимостей нет.)
В JS/TS Sequelize, Prisma. Ну, мб, typeorm.
Sequelize и TypeORM не поддерживают концепцю Unit of Work, что серьезное ограничение, поскольку приходится эмулировать его вручную, что далеко не всегда тривиально. Единственная полноценная на js/ts, которую я видел, носит странное название Mikro-ORM, хотя давно уже куда более навороченная, чем остальные.
> будет заниматься миграциями, гарантиями корректности,Миграцию можно писать на SQL. Гарантию корректности дает тоже SQL. Единственное, что последнее происходит в рантайме и чем может помочь какой-нибудь query builder, так это проверкой во время компиляции.
Query builder нужен для того, чтобы удобно собирать запрос по частям. Например, могут быть классы или функции Criteria..., которые добавляют условия фильтров в запрос. Можно, конечно, вручную таскать части запроса и биндинги, и потом всё аккуратно собирать, но это и получится написание своего частного случая Query Builder.А ORM нужны вообще для другого. Для чего они нужны - следует из названия. Для двустороннего маппинга между объектами (или, в случае неООП, структурами или кастомными типами) и структурой данных в РСУБД. Можно в первом приближении сказать, что это такой serialize/unserialize в РСУБД.
> Миграцию можно писать на SQL.Так и код можно двумя проводами настучать в бинарном виде. Но вот поди ж ты…
>> Миграцию можно писать на SQL.
> Так и код можно двумя проводами настучать в бинарном виде. Но вот
> поди ж ты…В чем проблема писать миграцию на SQL?
> Просто смотришь на некоторые привычные вещи, а они только в новых версиях MySQL. А эта версии ещё не скоро в дистрибутивах появятся.Да вы что. В дистрибутивах новые версии появляются на следующий день. Надеюсь вы не используете и не считаете дистрибутивом какой-нибудь дебиан олдстабле или центос?
аргументы будут? давай по пунктам, а то мы все прекрасно помним как Uber переходил с постгреса на мускли да как там в постгрес мультимастер кластера завезли уже?
сразу видно, что ты понятия не имеешь, что такое мускульный мультимастер и в продакшене ты его никогда не видел
А чего с ним не так? Так что с постгрызом?
ты главное верь в это )))
Так неосиляторов из убера уже давно разбомбили.
> Так неосиляторов из убера уже давно разбомбили.никто их не разбомбил, достаточно почитать ответ статью самих разработчиков постгреса
Ну, as for me - multimaster cluster достаточно нишевая штука так-то. Не то, чтобы "ненужно!" - но нужно не только лишь всем и очень-очень часто более, чем компенсируется на уровне архитектуры.
> Ну, as for me - multimaster cluster достаточно нишевая штука так-то. Не
> то, чтобы "ненужно!" - но нужно не только лишь всем и
> очень-очень часто более, чем компенсируется на уровне архитектуры."не компенсируется", и СУБД умеющая такое и есть в таком случае часть архитектуры
технические решения для таких СУБД вырабатываются годами, никто не будет делать это в отдельном взятом проекте, а потому ты наверное хотел сказать, что отсутствие консистенстности между распределенными нодами приводит к обрезанию в функциональности и закостыливанию каких-то вещей
> достаточно нишевая штука
везде где требуется HA и/или sharding, часто используется много где, другое дело что проектов где это не нужно и можно расти вертикально намного больше, так с этим не спорит никто
вопрос в другом - вот вырос ты из постгреса, и не только потому что локально ворочаться сложно, а потому что открылся офис ну например в Сингапуре или Индии, он куда стучаться будет? с какой латенси? 200-300ms в лучшем случае
с чего бы вдруг гуглу Spanner понадобился ))))
Да оспыдя. Кому надо - задолго до "вырастания" из postgres'а уже понабрали кто cassandra'у, кто mongo, кто clickhouse, даже блин redis с георепликацией видел - а вот ар-ригиналов с mysql - нет. В бизнесухе - нет. В чистой вебне - не знаю, может и осталось где с тех еще времен...
> Да оспыдя. Кому надо - задолго до "вырастания" из postgres'а уже понабрали
> кто cassandra'у, кто mongo, кто clickhouse, даже блин redis с георепликацией
> видел - а вот ар-ригиналов с mysql - нет. В бизнесухе
> - нет. В чистой вебне - не знаю, может и осталось
> где с тех еще времен...учитывая твоей уровень ты другого и не мог видеть, ошибка выжившего
>> Да оспыдя. Кому надо - задолго до "вырастания" из postgres'а уже понабрали
>> кто cassandra'у, кто mongo, кто clickhouse, даже блин redis с георепликацией
>> видел - а вот ар-ригиналов с mysql - нет. В бизнесухе
>> - нет. В чистой вебне - не знаю, может и осталось
>> где с тех еще времен...
> учитывая твоей уровень ты другого и не мог видеть, ошибка выжившегоПрям даже хочется ответить в классическом линукс-стайле - "Нет, ты!" - но я пожалуй что не буду.
Вам, разумеется - виднее.
Сколько лет в теме, а постгрес видел пару раз и то у очень больших оригиналов.
> Сколько лет в теме, а постгрес видел пару раз и то у
> очень больших оригиналов.В РФ популярна, исторически )))
Сейчас Postgres в РФ - практически единственная БД, на которую можно переползти с Оракла/MS/остальных для импортозамещения.
Зато мастер-мастер репликация работает.
Чем это лучше Firebird?
Тем что FoxPro.
А что у Firebird за мутная лицензия IDPL Interbase-1.0? Как она совместима с проектами под GPL? MySQL совместим.
>Чем это лучше Firebird?Ну бэкапы к примеру _точно_ восстанавливаются, а не как у этих :)
Версия ради версии. Кто объяснит какой в этом высокий смысл? Это даже не коммерческий продукт чтобы его продать или обогнать конкурентов. В своей нише у майсикуэля нет конкурентов.
А как же MariaDB?
> В своей нише у майсикуэля нет конкурентов.Неуловимый Джо.
Зависть.
Ну завидуйте, ораклята.При наличии универсальных РСУБД, таких, как постгрес, востребованность мускуля крайне сомнительно.
постгрес вообще не универсальная субд, это жалкое зрелищеу оракла есть мультимастер, как кстати и у мускула, притом у последнего два варианта и оба бесплатных
Нет. Просто это не рСУБД, а "объектно-реляционная СУБД" - которая достаточно хорошо "натягивается" в том числе и на нишу чистых реляционок. Не идеально, но прям "хорошо".
Ой, да не надо. Постгрес - самая обычная классическая РСУБД. Мелкая, редко нужная фича в виде наследования таблиц ничего не меняет.
> Ой, да не надо. Постгрес - самая обычная классическая РСУБД. Мелкая, редко
> нужная фича в виде наследования таблиц ничего не меняет.Наследование таблиц, наследование типов, перегрузка функций, развитый тулинг для работы с нереляционными данными, расширяемость в интересные стороны (всякие timescale, edgedb, ferretdb и т та дэ) - тут конечно "чисто-чистые" РСУБД почитай что и повымерли все - но постгря в эту строну зашла пожалуй что и подальше.
Объектная БД - это совсем про другое, это типа Caché, если кто помнит такую проприетарщину. В постгрес этот термин как раз в те времена притянули за уши ради хайпа на модной теме.Постгрес классически-реляционный в своей архитектуре. Да, поверх этого они навертели много плюшек, но суть от этого не меняется, реляции - основа.
поэтому она должна паршивенько решать задачу масштабирования с реляционными данными, что-то оракл с его PL-SQL так не думает
> В своей нише у майсикуэля нет конкурентов.Это что за ниша такая, где MySQL не может заменить PostgreSQL? На серьёзных проектах скорее наоборот, их MySQL может не потянуть. А вот в обратную сторону даже представить себе не могу что это такое может быть.
geographically distributed synchronous replicationот одного сочетания страшно, а у мускула есть 2 реализации
постгрес - инвалид по сравнению с mysql, который тоже не идеален, но в этом плане как у всех
Нукагбэда, но вот NoSQL в этой нише чувствуют себя прям сильно-сильно лучше - и ситуаций, когда нельзя разделить "данные" для которых вот это вот все имеет смысл от "реляционных метаданных" не то, чтобы много - и как бы это сказать... legacy оне.
> NoSQL в этой нише чувствуют себя прям сильно-сильно лучшенет, не чувствуют, там нет консистентности даже в задекларированных возможностях неговоря уже о реальных возможностях
в некоторых отдельных случаях можно увидеть транзакции в монге, можно выбирать стратегии репликации, но в целом все плохо
>> NoSQL в этой нише чувствуют себя прям сильно-сильно лучше
> нет, не чувствуют, там нет консистентности даже в задекларированных возможностях неговоря
> уже о реальных возможностях
> в некоторых отдельных случаях можно увидеть транзакции в монге, можно выбирать стратегии
> репликации, но в целом все плохоОхтыжблин. Мужики-то не знают!(Ц)
В тех 2,5 случаях, когда тебе _действительно_ нужен синхронно геореплицированный ACID на весь объем обрабатываемых данных - у тебя стоит oracle или хотя бы mssql. В 98% остальных кейсов тебя вполне устроит BASE для основного объема данных и ACID для совочка метаданных - а то и вовсе какой transactional outbox поверх кафки - depends on.
> oracle или хотя бы mssqlСразу видно ыксперта )) Из этих двух только oracle умеет в мультимастер.
Тем не менее, если мы говорим о масштабных проектах, то чаще всего не инвестируют в такие дорогие проприетарные решения, а то будет как с Бирмингемом.Остальное даже коментировать смысла нет, там такой же бред и очень вредная самоуверенность.
>> oracle или хотя бы mssql
> Сразу видно ыксперта )) Из этих двух только oracle умеет в мультимастер.
> Тем не менее, если мы говорим о масштабных проектах, то чаще всего
> не инвестируют в такие дорогие проприетарные решения, а то будет как
> с Бирмингемом.
> Остальное даже коментировать смысла нет, там такой же бред и очень вредная
> самоуверенность.Ухтыж! А майкрософту-то и не сказали, что их peer-to-peer нищитова - "танк секретный, учОные могут и не знать!"(Ц)
"Но в ГЛАВНОМ-то он прав!"
давай пруф поржем с тебя, ыксперт, ссылку на документацию, гайд по настройке, ну что-то что может быть подтверждением твоего стендапа )))
> давай пруф поржем с тебя, ыксперт, ссылку на документацию, гайд по настройке,
> ну что-то что может быть подтверждением твоего стендапа )))Уф. Я понимаю, что вы Sql Server видели хорошо если в редакции express и что там в enterprise edition - понятия не имеете, но уж ЗАГУГЛИТЬ-то вы должны суметь? Понимаю, задача сложная - но верю, вы справитесь! Ключевое слово в посте выше.
>> давай пруф поржем с тебя, ыксперт, ссылку на документацию, гайд по настройке,
>> ну что-то что может быть подтверждением твоего стендапа )))
> Уф. Я понимаю, что вы Sql Server видели хорошо если в редакции
> express и что там в enterprise edition - понятия не имеете,
> но уж ЗАГУГЛИТЬ-то вы должны суметь? Понимаю, задача сложная - но
> верю, вы справитесь! Ключевое слово в посте выше.я хочу сказать что ты балабол, который не знает что есть Developer Edition который полностью соответствет максимальной версии кроме промышленного использования
и нету в SQL Server никакой мультимастер, и отсутствие пруфов только подтверждает факт что ты бесполезный
> я хочу сказать что ты балабол, который не знает что есть Developer
> Edition который полностью соответствет максимальной версии кроме промышленного использованияНо его ты тоже в глаза не видел, да? Вендапоганая, вот это всё?
> и нету в SQL Server никакой мультимастер, и отсутствие пруфов только подтверждает
> факт что ты бесполезныйВ гугль не сумел, бедолага - или все же с чтением проблемы? Так ты чатжопэтэ попроси, не стесняйся.
Все случаи, где нужен обобщенный инвертированный индекс. Например, поиск по произвольному множеству атрибутов в каталоге типа Яндекс-маркета. С MySQL придется либо делать поиск во внешней специализированной базе (со всеми проблемами синхронизации), либо костылить поверх полнотекстового поиска, кодируя все атрибуты "словами" с отключением морфологии.
так это и делается полнотекстовым поиском, индексы нормально не работают если значение не начинается с искомого словаесли у постгреса есть что-то из каропки, то это не значит, что это must have
есть вещи которые в БД и только в БД должны быть и никако по-другому нереализуемы, а есть вещи которые в БД существуют просто как сахар, и такой шляпы там дофига не только GIN, но теперь и RUM, а еще GIST
но я уж лучше SolR или Elastic они хотя бы тоже мастштабируется горизонтально
Зачем полнотекстовый поиск для информации, которая изначально естественным образом представляется как Set[Int]?GIN как раз для этого, изначально делался вместе с hstore для обработки астрономических данных, разреженных просто по своей природе.
Непонятно, почему вдруг btree мастхэв, а inverted index - нет. Это два разных индекса для решения двух разных задач.
Горизонтальное масштабирование же далеко не всегда нужно, и отдавать его на откуп СУБД - тоже не всегда разумно: если есть критерий, по которому легко пошардить ручками на уровне приложения, такая реализация будет заведомо эффективнее.
а если я в описании хочу поискать? в том числе произвольные словоформы?и зачем мне искать текст фильтра, если мне нужен код фильтра?
да и в целом вот не вижу я причины почему более универсальное решение должно замениться менее универсальным, так еще интгрерированным в СУБД со своими плюсами, но и минусами
> если есть критерий, по которому легко пошардить ручками на уровне приложения, такая реализация будет заведомо эффективнее.
не будет эффективней
не легко прошардить
а про консистентность уже вообще промолчу
Если ты хочешь поискать в описании, для этого делается полнотекстовый поиск по описанию, для этого есть fts.А еще ты можешь хотеть отсортировать по цене. Это btree.
Прикинь, для каждой задачи свой тип индекса.
> не будет эффективней
От рук зависит. В одном конкуренте Фейсбука очень эффективно было, разведка говорит, что и в самом Фейсбуке примерно так же.
> а про консистентность уже вообще промолчу
А какая может быть неконсистентность при шардинге? Шардинг от репликации не отличаем, зато рассуждаем про эффективность, вау
я этот бред даже коментировать не вижу смысла, удачи
> поиск по произвольному множеству атрибутов в каталогеэто кстати пример корявого использования
А чего в нем корявово? Прямое использование по назначению.Инвертированный индекс - это указатель: в каких строках встречается данное значение. Ровно то, что и нужно.
Зачем нужно MySQL 9.0, когда есть MariaDB 11.4?
> Зачем нужно MySQL 9.0, когда есть MariaDB 11.4?Слабаки! PostgreSQL 16.3
Oracle Database 23ai смотрит на вас как вы сами знаете на что.
MS Access 2404 на вас даже не смотрит
Потому что он при нагрузках которые успешно тянут все вышеназванные уже загнулся в кровавых соплях и глаза закатил
https://jira.mariadb.org/browse/MDEV-11588
Когда этот баг исправят или хотя бы начнут им заниматься, тогда и упоминайте MariaDB!
> https://jira.mariadb.org/browse/MDEV-11588Ну кстати в оракле так было. ХЗ, актуально ли до сих пор
>> https://jira.mariadb.org/browse/MDEV-11588
> Ну кстати в оракле так было. ХЗ, актуально ли до сих порВ MySQL лет 10 назад это тоже было, но это более 10 лет назад исправили.
Ну давайте откровенно, те, кто на это наталкиваются, писали некорректные запросы в старых MySQL, не имевших даже опции ONLY_FULL_GROUP_BY и при неоднозначном GROUP BY просто возвращавших первое, что попалось, а работало это просто потому что в данном конкретном случае конфликтов не возникало. А потом завезли строгий SQL и всё поломалось.PostgreSQL тоже распознает functionally dependent только в простейшем частном случае наличия PK в GROUP BY, и ничего, никто не рассыпался вручную перечислить столбцы в GROUP BY.
Что как там с репликацией?
Репликация репликации рознь. Научитесь точнее формулировать свои мысли.
> MySQL 9.0.0Боромир (MariaDB) был бы уже 10.0.0 (По факту 11.x.x).