Один із розробників MySQL покидає проєкт. Він його розкритикував і радить користуватися PostgreSQL

Один із розробників вільної системи керування реляційними базами даних MySQL Штайнер Гундерсон заявив про залишення проєкту. При цьому він розкритикував його та рекомендував використовувати іншу об’єктно-реляційну систему керування базами даних PostgreSQL, пише OpenNET. Розповідаємо деталі скандалу.

Що відомо про цього розробника

Штайнер Гундерсон (Steinar H. Gunderson) — один із авторів бібліотеки стиснення Snappy і учасник розробки IPv6. Протягом п’яти років він працював у Oracle над модернізацією оптимізатора системи управління базами даних (СУБД) MySQL.

Тепер Гундерсон оголосив про повернення в компанію Google, у якій свого часу займався розробкою сервісів пошуку за зображеннями та offline-картами. Як очікується, віднині він буде залучений до розробки браузера Chrome.

Зокрема, заява Штайнера цікава критичним ставленням до перспектив MySQL та рекомендацією переходити на PostgreSQL.

Що він критикує

На думку розробника, MySQL сильно застарів і не ефективний, не дивлячись на те, що більшість користувачів і розробників вважають, що все гаразд, не обтяжуючи себе порівнянням з іншими СУБД, які давно пішли вперед.

Гундерсон визнав, що реалізовані для MySQL 8 оптимізації дозволили помітно покращити роботу оптимізатора запитів порівняно з MySQL 5.7, але загалом робота оцінюється як доведення його до рівня технологій початку 2000-х років.

За словами розробника, для подальшого доведення MySQL до прийнятного стану Oracle не виділяє належних ресурсів, що заважає підтримці його як конкурентоспроможного продукту.

Так само в СУБД MariaDB, якщо вірити Гундерсону, ситуація не краща, особливо після відходу команди Майкла «Monty» Віденіуса, незадоволеної новими віяннями в управлінні проєктом.


Раніше у Rust-ком’юніті виник гучний скандал: команда модераторів цієї мови програмування в повному складі оголосила про звільнення з проєкту. Причиною такого кроку вони назвали неможливість впливати на основну команду розробників (Rust Core Team), яка «не підзвітна нікому, крім самої себе».

Також повідомлялося, що спільнота розробників популярної мови програмування PHP заснувала нову некомерційну організацію PHP Foundation. Вона відповідатиме за організацію фінансування проєкту, підтримку спільноти та забезпечення процесу розробки.

Нагадаємо, 30 вересня розробники після року роботи опублікували нову стабільна гілку об’єктно-реляційної системи керування базами даних (СКБД) PostgreSQL 14.

👍ПодобаєтьсяСподобалось3
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Поделитесь личным опытом (не теорией) по postgresql.

Сейчас уже autovacuum справляется с нагрузкой в несколько тысяч update’ов в секунду 24/7 ?
Не пухнет ли таблица и производительность не начинает падать?

Сейчас нет такого «живого» проекта под рукой.

Много лет назад как только autovacuum появился, он не справлялся с очисткой dead tuples, всё равно производительность падала, таблицы росли, приходилось постоянно запускать vacuum full. Всё как Uber описывал в презентации по миграции postgresql на mysql.

Но в каждой версии они это всё улучшают, можно играться c fill factor’ом, есть HOT.

Сейчас если в таблицу (без длинных текстовых полей) будет за сутки прилетать 100 миллионов апдейтов не индексных полей, автоматически всё это будет успевать чиститься автовакуумом без танцев с бубном ?

Раньше это было болью postgresql, ну ещё connection handling на процессах, но здесь хотя бы pgpool спасает.

Марія подала на розлучення?

прикольно, але Марія (і Маша, та котра My у MySQL) — це донька Монті Віденіуса

Как по мне MySQL задумывался так, или так по факту вышло:
что где-то соответствует закону Парето
80% покупателей покупают 20% ассортимента

ну вот, MySQL и реализует эти 20%. и все.
надо больше, потому что вы из тех 20% покупателей которые покупают остальные 80% ассортимента — ну так есть Оракл, MS SQL, PostgreSQL. Они правда тоже не все тянут, так что может вообще надо брать кассандры с клик хаусами

а может и Монгу, потому что и реляционка вам не нужна

Рыбак внезапно понял, что вода мокрая а рыба не очень приятно пахнет ... право странно такое слышать.
а разве при при переходе в Oracle для работы над MySQL были иные ожидания ?

Странно что вообще не закрыли проект. Корневая команда разработчиков сразу же уволилась, как только были выкуплены Oracle. В общем то что MySQL в отличии от Sysbase все ещё жив обуславливается только его обширным применением в LAMP. В новых проектах ни MySQL ни клонов типа Maria DB я не видел уже лет пять. Все массово съехали или на Postgress или NoSQL: Mongo, Casandra изредка DynamoDB, Hbase и Neo4j. А там где был Oracle или MS SQL никто их трогать не будет, проще создать новую систему и ей заменить старую чем там делать изменения такого уровня как смена базы данных.

А у меня как у не сильно модного хипстера полно проектов на mariadb/mysql
Я вот постгрес редко вижу, ибо все же его без админа не очень получается содержать.
Amazon RDS тоже вроде живее всех живых.
И не падают у меня почему-то ноды с mysql часто, с репликацией, да.
Может потому, что у меня нету 100500 разработчиков каждый из которых лучше знает куда засунуть бд(в контейнер под виртуалку с виртуализированным стореджем на внешнем виртуальном сан с странным расширяемым конфигом lvm over drbd или еще каким то бредом) и нету петабайтных баз?
ну так не предназначен он для петабазных баз, чего уж тут.
Есть, знаете ли, проекты работающие вообще годами без штатного ИТ отдела и админа и нормально себя чувствующие. На серверах, у которых uptime несколько лет и никакой модной контейнерезации. И да, могут по 10 лет не обновлятся и все еще использоваться.

Я вот постгрес редко вижу, ибо все же его без админа не очень получается содержать.

ну чего, видел как-то потроха проекта, где MqSQL загнулся бы. Там под терабайт, и куча логики перетекла с приложения в ХП поэтому :)

но в том и прикол, что Postgress часто густо укутан помимо тяжелой православной ORM, то есть его используют как самую примитивную реляционную БД, без тех его фичей, ради которых его собственно и надо использовать. но фыркают на мускул :)

и давно прикалываюсь аргументу — ORM спасает нас от вендор лок!
потому что — так он вашу БД превращает в жалкое подобие даже MySQL — не думали об этом?

Да, конечно, можно сделать так, что загнется что угодно.
Но по факту в громадном количестве проектов даже sqlite3 хватит и mysql там хранит, к примеру, 30 логинов и логи доступа и на этом все.

даже sqlite3 хватит

все так.
но это, как вы и написали — несовременно совсем.

надо кучу докер поднять, в кубернетесах — вот это круто будет.

примерно как круто — держать 18 серверов под питоном, вместо парочки на JVM

или, как евангелист Ноды Тимур Шемсединов метко замечает
а давайте превратит Ноду в PHP, затолкав ее в амазоновскую лямбду, чтобы — что?

ну, понятно что — чтоб крутее!

ибо все же его без админа не очень получается содержать

Можете более подробно рассказать, что есть такого фатального в PostgreSQL, что его невозможно содержать без админов, в отличии от MariaDB/MySQL? Из вашего описания видно, что у вас был негативный опыт с непонятно с кем и непонятно почему, но о самой проблеме PostgreSQL ничего не сказано.

З.Ы. я наблюдал проблемный проект с MySQL, на котором команда не использовала транзакции, от слова вообще, но это не повод говорить о том, что MySQL не поддерживает транзакции и поэтому «в топку его» :)

Как по мне, критика MySQL в стиле — «а вот в Postgress ...» такая же как критика SQLite — «а вот в MySQL»

А во многих проектах Postgress — это просто из пушки по воробъям. При этом его саппорт выходит дороже.

Чем его саппорт дороже ? Несколько раз пытались использовать, что хочешь делай с мукулем но нормально он не реплицируется и не масштабируется. Postgress конечно не Oracle по многим позициям, тем не менее нагрузку держит, реплицируется, масштабируется в клауде и т.д. А все что нужно для нового софта — правильный образ контейнера. Читаю чего Facebook у себя делали чтобы просто перейти на новую версию мускуля, в итоге выходит потратили три года и за эти три года по-существу переписали почти в нуль сам мускуль, ибо репликация не удовлетворительная. Главное преимущество мускуля — он часть LAMP стека, и PHP-шные CMS типа: Drupal, Joomla, Wordpress, TYPO 3 заточены именно под него. Поэтому никуда MySQL не денется слишком много переделывать. Вот только Oracle это наследство от Sun не нужно, а Meta они его не продают. В целом уровень новости непонятный — один чувачек ушел с проекта обратно в Google и пишет что MySQL устарел потому что Oracle в него не вкладывается. Ну ушел и ушел.

Несколько раз пытались использовать, что хочешь делай с мукулем но нормально он не реплицируется и не масштабируется.

Что имеется ввиду ?

Postgress конечно не Oracle по многим позициям, тем не менее нагрузку держит, реплицируется, масштабируется в клауде и т.д.
Читаю чего Facebook у себя делали чтобы просто перейти на новую версию мускуля, в итоге выходит потратили три года и за эти три года по-существу переписали почти в нуль сам мускуль, ибо репликация не удовлетворительная.

Если с пострегресом так хорошо чего не переползти было на него ? Может просто у них задачи столь специфичны, что уже только самописные базы тянут ?

Что имеется ввиду ?

Есть фундаментальный архетектурный изъяны, когда происходит — master crash dev.mysql.com/...​xpected-replica-halt.html не происходит Automatic failover.

Если с пострегресом так хорошо чего не переползти было на него ? Может просто у них задачи столь специфичны, что уже только самописные базы тянут ?

задавал вопрос коменте, не ответили. Понятия не имею, предполагаю им проще довести до ума сам MySQL чем менять движок базы в которой хранится петабайт и по которому ходят разные AI/ML и выясняют какую рекламу тебе показать. Очевидно что данные и таргетированная реклама — основа бизнес модели. Даже просто переход вверх на одну версию у них занимает 3 года, и они вносят множества патчей в сам мускль и драйвят разработку.

Есть фундаментальный архетектурный изъяны, когда происходит — master crash dev.mysql.com/...​xpected-replica-halt.html не происходит Automatic failover.

Пользуемся MySql с репликацией больше 10 лет на ~1Тб базах, на 10-20 серверах.
Программных крашей не было никогда.
Проблемы с репликацией требующие ручного участия бывают, когда сервера физически по питанию некорректно выключаются.
И да, не пользуемся свежими вчера вышедшими версиями.

Чем его саппорт дороже ?

тем что у него есть фичи, которых нет у мускула, и которые надо тюнить.
а у мускула — не надо. потому что их просто нет.

он не реплицируется и не масштабируется

ну да, это не его стихия. хотя вроде вполне ок, зависит от сценария.

я ж о том и написал, о некорректности сравнения.

А все что нужно для нового софта — правильный образ контейнера

я вообще не понимаю на кой пихать БД в контейнеры.
но, если надо, ну значит надо, просто я не понимаю, не видел еще пользы от этого.

Главное преимущество мускуля

простота установки и настроек, и мягкая типизация в SQL

MySQL устарел

он всегда такой был — самый «устаревший». Всегда, с рождения уступал тяжеловесам.

странно, с чего бы ожидать что легковес — станет тяжеловесом.
не, может быть.
ну, значит другой легковес появится. свято место — пусто не бывает

я вообще не понимаю на кой пихать БД в контейнеры.

 в основном за этим

простота установки и настроек

. Запускаете докер и база из коробки с настройками по умолчанию. Если у вас 3-4 проекта можно гибко гасить один инстанс, поднимать другой относительно очень быстро. Передавать все что нужно другим разработчикам, быстро онбордить и т.п. Или микросервисы и баз несколько то можно весь зоопарк поднимать буквально с помощью одного compose файла и одной команды docker-compose up Тоже не понимал этого всего ажиотажа еще пару лет назад, пока сам не попробовал — очень удобно оказалось, рекомендую.

очень удобно оказалось, рекомендую.

пока не нужно было.
БД отдается весь сервер. а не делится между еще какими-то
дублирующий — послабее, лишь для — чтобы хоть как-то шевелилось.
а дальше — подготовка и тестирование аварийного подъема из бекапов.
или парочка — мастер-слейв. мускул вполне тянет.

было да, поднимали БД для прогонов автотестов. да. но в проде зачем... пока непонятно.

Передавать все что нужно другим разработчикам,

пару файлов конфигов? для этого нужен контейнер?

для разработки нескольких проектов
переключил на другие конфиги, и все. сервер БД по прежнему один на машине
смысл пихать его в контейнер на дев машине?

Или микросервисы и баз несколько то можно весь зоопарк поднимать

а если нет этого зоопарка? ну просто нет его, потому что не нашлось никого с резюме драйв девелопмент чтобы его создать, а с нагрузками на проекте пару дедиков хороших справляются, с типовой загрузкой не более 30%

еще раз — противопостовлять межгалактические лайнеры рыбацкой лодке — нелепо. как и оборудовать рыбацкую лодку гиперпространственными двигателями и криокамерами.

Колись теж mysql був один на сервері ... але зараз відійшли від цього.

Зараз стараємось так не робити. Одна база на сервер — це велика база і це проблема: це мінімум пару терабайт бази, їх важко бекапити, важко запустити репліку(великий снапшот), важко розгорнути бекап, важко апгрейдити (якщо downtime, то один і великий і страждає все)

До того ж репліка і відновлення бекапа по нормальному мали б використовувати точно ту ж версію mysql як і мастер. А керувати версіями в умовах mysql з пакетів — то щось неймовірне.

Тому зараз ми стараємось різати по можливості десь до 200-400Gb баз на instance. На кожен instance виділяється окремий lvm, на бекапі снапшотиться і в фоні архівується (практично, без downtime ... лиш writelock на пару секунд для снапшота). Це все в докері з фіксованою версією: апгрейд — окрема процедура, якщо дуже багато з’єднаннь, то DNAT замість docker proxy. Відновлення з бекапа — практично ідеальне: розпакувати, переслати і run.

Все працює як треба ... єдиний мінус — це те, що навантажена база з активним lvm снапшотом помітно просідає. Коли це важливо, снапшот робиться з репліки.

Можливо, у вашому випадку, реалії інакші, але після того як ми налаштуавали все згадане (+ prometheus), питаннь до баз в нас принципових не залишилось.

у вас так. у мене сяк. а у того — ще якось

я не бачу не те щоб сенсу, а самої можливості обговорювати усі випадки — і у яких що треба використувати, які фічі вкрай необхідні, якими можна знехтувати і т.і.

тому залишаю цю тему, бо те що буде безглуздне обговорення я означив відразу:

Как по мне, критика MySQL в стиле — «а вот в Postgress ...» такая же как критика SQLite — «а вот в MySQL»
я вообще не понимаю на кой пихать БД в контейнеры.

Бо вам просто лінь взяти і вивчити нове. Кажуть, таке часто з віком трапляється
Потім йде «раньше било лучше», «деды воевали», «та я 40 років на делфі коджу, куди вам соплякам» ітд

Не знаю що там кому лінь, але вік так, якось впливає на невігласів. чим молодше — тим менше знає чомусь, а тому пишається якоюсь дріб’язковою навичкою.

у контейнер щось запхати — то велика наука, аха :)

а от зрозуміти питання — а навіщо те щось туди пихати? — то так, треба академічна освіта!

Я девопс по текущей модной классификации.
Я знаю как запихать mysql в контейнер, даже в варианте написанном мной(с raid, lvm и другими извратами).
Вот только я знаю, что вы так ничего не выиграете ибо почти во всех случаях гипотетических ситуаций, для которых вы его засунули в контейнер вам прийдется пересоздать контейнер и по расходам времени это не будет отличаться от инсталяции на другой хост.
Нет, я могу придумать искуственную ситуацию, в которой так надо сделать. Но в большинстве случаев это бесполезно и вредно для производительности.
Имеет смысл только если у вас 100500 гибридных инсталяций(по 3+ контейнера на штуку) и вы их постоянно разворачиваете и сворачиваете. Что НЕ является обычным для проекта.

Спорт выходит дороже — это субъективное мнение. По какой методике вы рассчитываете эту цену ? Методика «я лучше знаю MySQL» и ещё куча народу это в общем аргумент на самом деле но не основной. Я когда то Delphi знал лучше чем C++ только Delphi это не спасло от ее участи.

По какой методике вы рассчитываете эту цену ?

по простой — чем сложнее штука — тем дороже ее эксплуатация
чем за бОльшим числом параметров надо следить — тем дороже система управления

это не спасло от ее участи.

ну, я слабо представляю что Postgre вытеснит MySQL — потому что он в другой нише. Это примерно как верить что все пересядут с седанов на рамные внедорожники, потому что «настоящие пацаны на седанах не ездят!»
А почему он хуже Оракла и MS SQL в энтерпрайзе — тоже встречал подробные сравнения. Как причастный — мне они были понятны.

Методика «я лучше знаю MySQL»

Это не методика. Это то что дает расширение применения Пайтона, JS, и PHP

И — уверен, бОльшая часть не знает никакого Postgre, а спрятавшись за ОРМами использует урезанный диалект SQL

Думаєш це нормально, перекласти новину з Opennet і навіть не вказати тут посилання на оригінал?

Це новина не з опеннет, а з блогу головного героя новини: blog.sesse.net/...​-16-41_leaving_mysql.html

DOU: На думку розробника, MySQL сильно застарів і не ефективний, не дивлячись на те, що більшість користувачів...
OpenNET: По мнению Штайнара, MySQL сильно устарел и неэффективен, при том, что большинство пользователей...

DOU: Зокрема, заява Штайнера цікава критичним ставленням до перспектив MySQL та рекомендацією переходити на PostgreSQL.
OpenNET: Заметка Штайнара примечательна критическим отношением к перспективам MySQL и рекомендацией переходить на PostgreSQL.

DOU: Так само в СУБД MariaDB, якщо вірити Гундерсону, ситуація не краща, особливо після відходу команди Майкла «Monty» Віденіуса, незадоволеної новими віяннями в управлінні проєктом.
OpenNET: В СУБД MariaDB ситуация не лучше, особенно после ухода команды Микаэля Видениуса (Michael «Monty» Widenius), недовольной новыми веяниями в управлении проектом.

І так ледве не кожне речення. Це ж не він про себе у третій формі пише.

Додали посилання за вашим проханням.

Спасибі.

Прошу вибачення, ви праві, а я полінився почитати опеннет. Саму новину ще раніше читав на HackerNews.

MySQL із самого початку створювався, як спрощений движок із спрощеним діалектом заради продуктивності. І це зпрацювало. А коли довели до пуття баракуду — то взагалі стало добре. Ну, так, нема фул-аутер-джойну, і колись давно Монті детально розписував — чому його нема і що за цей рахунок здобувається. Так, є проблеми з великими джойнами, де задіяно 20-30 таблиць і інколи доводиться гратися з ’optimizer_search_depth’ - але це теж ціна за цілком зрозумілі та корисні плюшки.

Я вважаю, що якщо питають, чого пішов, то є одна відповідь: знайшов щось краще.
А вичитувати, що отам гівнокод, там ретрогради, а тут бюрократія, а тут мене не зрозуміли і не оцінили — це негідне справжнього самурая.

То не движки, то стораджі. Движок — це те, що виконує SQL-код.

Если на клетке слона прочтешь надпись: буйвол — не верь глазам своим ©

Тогда стоило бы определиться с определениями, что вы считаете движком ?

DB-engine в мускля/марії — це те, що парсить SQL-код, будує план виконання, оптимізує його та, власне, виконує. Storage engine — то, власне, ніякий не енжин, а формат файлів, де зберігаються таблиці, та АПІ з функцій для доступу до тих файлів.

Бо коли мова йде про оптимайзер — це виключно про енжин, не про стораджі. Енжин є сторадж-блайнд, йому байдуже, чи то дані в іннодб, чи то в муісам/арія, чи в токудб, чи в роксдб. Дані є — маслаємо. Єдине лиш, що деякий функціонал, як то транзакційність, реалізується тільки у журнальованих стораджах, а їх є тільки іннодб.

с rocksdb тоже работают транзакции, с некоторыми некритичными ограничениями.

Кому як. Швидкість там висока, але транзакційність у випадку збою під час великих транзакцій на наших тестах призводила до суттєво більших простоїв, ніж на іннодб. Безпечніше вважати, що її там нема :)

Ну для целей переноса данных — достаточна.
Хотите больше скорость, ставьте другие настройки.
Справедливости ради откат транзакций в mysql и для innodb может часами длиться.

движок із спрощеним діалектом заради продуктивності

Продуктивності чого саме? Швидше працює чим PostgreSQL?

Так, є проблеми з великими джойнами, де задіяно 20-30 таблиць і інколи доводиться гратися з ’optimizer_search_depth’ - але це теж ціна за цілком зрозумілі та корисні плюшки.

Надайте будь ласка приклад, чому PostgreSQL в важких випадках може використовувати генетичний алгоритм для складних запитів замість динамічного програмування, а MySQL отримує корисні плюшки, які я, наприклад, цілковито не знаю які.

Ну как бы понятно, что ораклу mysql нужен исключительно для того, что бы продавать оракл разочаровавшимся в mysql :)
Соответственно они ни при каких условиях себе бесплатного конкурента выращивать не будут, будут просто поддерживать его не совсем отстойным.

В ораклу ж наче є «безкоштовні» версії їх зубд
І після створення життєздатних форків, це більше схоже на собаку на сіні

(a) internally use the unmodified Programs for the purposes of developing,
testing, prototyping and demonstrating your applications, and running the Programs 
for your own internal business operations
соответственно это только для разработки или внутреннего использования, денег на них зарабатывать нельзя

Ну от виправити це огородження і прикрити розробку — всього-то ділов

Зачем? :) Оракл намного сложнее в настройке и поддержке, соответственно давать на него нормальную поддержку в бесплатной версии намного дороже, чем на мускль.
А если ты не сможешь запустить его в первые 15 минут по видео с первой страницы ютуба, то большая вероятность, что ты таки пойдешь на что-то другое.

Ну и на платной поддержке костылей для мускля они тоже что-то зарабатывают.

В підтримці і тюнінгу — можливо і складніший
А швидкий старт там такий самий як і в дефолтному мускулі

ты таки пойдешь на что-то другое.

Є багато софту який залочений на мускул чи на інші зубд

Ну и на платной поддержке костылей для мускля они тоже что-то зарабатывают.

Оце мабуть найсильніший аргумент — невідомо скільки вони насправді на ньому заробляють

Зтикався з сапортом ентерпрайз-едішну MariaDB — обняти й плакати. Простіше зразу в джиру їхню писати, там реакція на три порядки адекватніша.

Вот не скажи. Приходилось и то и то устанавливать и настраивать. Чтобы поставить Oracle конечно нужно запустить иксы чтобы установщик запустился и ядро пропатчить, впрочем есть полным полно иинструкций. И можно сразу купить готовое с Oracle linux. Остальное делается вооружившись книжонцией Тома Кайта, создать инстансы баз/базы и настроить TNS listener, правильно создать tablespase db файлы и схемы с нужными превелегиями. Две проблемы: первая — жрет память, CPU и диск и куда попало типа бюджетного POD с 2 GB RAM не поставишь. Вторая — очень кусучая цена ещё и прогрессивная (впрочем по партнёрской программе ставь чего хочешь). MySQL неоднократно ломал мне мозг, из пакетов которые идут с дистрибутивами как всегда какая то старая и не подходящая сборка, перекинуть файлы данных на выделенный партишен с подключенным расширенным диском — пол дня ищешь мануал. Когда наконец все настроено, начинаешь создавать схемы, таблицы и т.д. — транзакции оно оказывается поддерживает полностью только с InoDB — а по умолчанию MyISAM и надо начинать с начала. ИМХО по сравнению с Oracle и Postgress SQL — MySQL геморой пользователя и конструктор аля сделай сам. Вишенка на торте — у него двойное лицензирование. Конечно если давно работаешь с этой базой, потому что «бесплатно» и хорошо ее знаешь вдоль и поперек, то понятно почему не хочется замечать очевидный мазохизм пользователя и общую убогость по сравнению с конкурирующими продуктами. Потому как Postgress вообще ставится в три щелчка, на любой поддерживаемой операционке и настраивается тоже не сильно геморойно, документация к нему есть в виде который можно читать и функций больше и т.д.

MySQL неоднократно ломал мне мозг,

ни разу еще не сталкивался с проблемой его установки.
может да, на каких-то диковинных ОСях, и какие-то редкие плагины к нему хочется.

Потому как Postgress вообще ставится в три щелчка

у вас редкие сценарии, если MySQL ставить сложнее чем Postgress :)

а по умолчанию MyISAM и надо начинать с начала

где вы такое прочитали, кто вам такое сказал?

обычно ж наоборот, сразу дефолтно ставится InnoDB, и только если вот точно надо — то при создании таблицы указывай MyISAM/Aria

MySQL геморой пользователя и конструктор аля сделай сам

и что же там такого надо делать?

документация к нему есть в виде который можно читать

а MySQL такой простой — что документацию к нему можно и не читать, а просто копипастить cnf с какого-нить бложика, и больше не вспоминать

функций больше

да, так он и делался, минимальный комплект-диалект. Потому что — YAGNI, и потому что задумывался как очень простой, и в установке, и в использовании. И как нетребовательный к железу. Потому стал любимым на шаред хостингах например, и обслуживает одним инстансом тысячи сайтиков.
Владельцы хостингов видать не в курсе что Postgre круче.

очевидный мазохизм пользователя

так в чем мазохизм с MySQL, раз он очевидный?

обычно ж наоборот, сразу дефолтно ставится InnoDB, и только если вот точно надо — то при создании таблицы указывай MyISAM/Aria

На це є опція у my.cnf.
Просто деякі хостінги та системи керування хостінгами по дефолту додають цю опцію, щоби був MyISAM. Ну або донедавна додавали, давно не дивився.

а MySQL такой простой — что документацию к нему можно и не читать, а просто копипастить cnf с какого-нить бложика, и больше не вспоминать

Дефолтні налаштування у MySQL доволі придурковаті, тому таки доведеться з ними розбиратись, як тільки сайт почне плужити при хоч якомусь навантаженні.

Потому стал любимым на шаред хостингах например, и обслуживает одним инстансом тысячи сайтиков.
Владельцы хостингов видать не в курсе что Postgre круче.

Це так не працює.
Популярність MySQL — це здебільшого інерція LAMP стеку, «тут так заведено».
Вона з’явилась у часи, коли інші альтернативи — той же Postgres — були в стані «обійняти і плакати» (почитайте про фічі і особливості Postgres-а до 9-ї версії), і на фоні інших співвідношення плюшки/геморой у MySQL виглядали досить непогано. Просто з часом не MySQL став гіршим — він таким і є, на троєчку — а інші альтернативи сильно просунулись вперед.
Плюс є певні особливості MySQL, які роблять його більш пристосованим до «обслуживает одним инстансом тысячи сайтиков» — наскільки знаю, щоби юзати Postgres у такому режимі, треба біля нього трохи попригати.

Дефолтні налаштування у MySQL доволі придурковаті

а у кого вони супер, дефолтні?

зазвичай вони такі щоб сервіс БД точно піднявся. на чому завгодно.

тому таки доведеться з ними розбиратись

можна і не розбиратись, а взяти з інету.
та й розбиратись там треба ну якщо дуже якись тонкий тюнінг треба.

але ок, у настройках якої БД не треба розбиратись?

Популярність MySQL — це здебільшого інерція LAMP стеку, «тут так заведено».

так. бо він був простий, і працював. тому й стало — «так тут заведено»
як Postgre стане таким же простим — то замінить.

але ок, давайте цей аргумент викорстаємо
Популярність Postgres — це здебільшого інерція X стеку, «тут так заведено».

X замінить на який завгодно, де він популярний. І що доводить — «тут так заведено»?

почитайте про фічі і особливості Postgres-а до 9-ї версії)

читав. і слідкував за розвитком.
конкретніше — що ви маєте на увазі?

щоби юзати Postgres у такому режимі, треба біля нього трохи попригати.

і не тільки з цим треба буде поригати. як воно треба — ну що зробиш, треба пригати.
а як не треба — то навіщо?

він таким і є, на троєчку

ну да. Він же — «Мускул»! Завжди таким був. Він і транзакцій не мав багато років наприклад :)
Version 5.0: beta from March 2005, production release October 2005 (cursors, stored procedures, triggers, views, XA transactions).

тобто ви кажете що MySQL то MySQL
Повністю згоден.
PostgreSQL це PostgreSQL
Так, ніяких заперечень.

Іншими словами, те що я відразу написав у цій темі
Мені незрозуміло навіщо MySQL ставати PostgreSQL коли PostgreSQL вже є?
Оракл DB? так і Оракл DB вже є

P.S.
погуглив про популярність
db-engines.com/en/ranking
www.statista.com/...​abase-management-systems

а у кого вони супер, дефолтні?

зазвичай вони такі щоб сервіс БД точно піднявся. на чому завгодно.

У MSSQL по дефолту більш притомні налаштування.

можна і не розбиратись, а взяти з інету.
та й розбиратись там треба ну якщо дуже якись тонкий тюнінг треба.

але ок, у настройках якої БД не треба розбиратись?

Питання було не «якщо» — на нього відповідь «доведеться»
Питання було «коли» і «наскільки вони притомні»

але ок, давайте цей аргумент викорстаємо
Популярність Postgres — це здебільшого інерція X стеку, «тут так заведено».

X замінить на який завгодно, де він популярний. І що доводить — «тут так заведено»?

Наскільки знаю, так не вийде, ібо Postgres грає на полі, там де грають MSSQL, Оракли ти інші Сібейси, і усталеного стеку, наподобі LAMP, у нього нема.
Тому і ніякої інерції там не буде, все що вполює своїми перевагами — те і буде його.
Якщо ж у Postgres-а є якісь стеки, типу LAMP — цікаво послухати.

У MSSQL по дефолту більш притомні налаштування.

ну, там може бути

з всього що мацав — MS SQL найкраща БД :)

Якщо ж у Postgres-а є якісь стеки

як я бачу — як Пітон на беку, то там чекай на Postgres
на Ноді також, як не Монга, то Postgres, бо хлопці засміють.

мені то нема різниці, все одно на тупій роботі з РБД, яка зазвичай у проектах з «ОРМами» лягає все, і мускули, і постгреси

і постогнавши, і собі під носа «їбігож мать!» — починаєш те виправляти...

. Чтобы поставить Oracle конечно нужно запустить иксы чтобы установщик запустился и ядро пропатчить, впрочем есть полным полно иинструкций

Вже давно ні, ставиться за допомогою unzip та улюбленого текстового редактора. А то й просто yum install.

У MySQL такая же лицензия, он платный для коммерческого использования.

Ну и «жизнеспособность» форков не так что бы очень :) Т.е. да они поддерживают его в жизнеспособном состоянии, но взять и сменить эвристики на настоящий оптимизатор — вряд ли кто-то захочет это делать в текущих форках.

Oracle Express — какаха та ещё, кое как для разработки сойдёт и то лучше поставить Enterprise но выбрать single редакцию и руками подправить потребление памяти. Обычно во время разработки особо нет нагрузки на базу и много памяти не нужно. В прод експресс полностью непригоден, начиная хотя бы с момента что там один поток.

Якщо код зубд не повне гівно, то це там має фікситись на рівні параметрів компіляції

Але це знов ніяк нас не наближує до відповіді — на який біс ораклу мускул

Але це знов ніяк нас не наближує до відповіді — на який біс ораклу мускул

Є підозра, що він йому дістався як приємний бонус, коли купили Сан, щоби мати свої серверні технології та свою джаву.

так, є такий напрямок «розвитка». А є інший — використовувати ком’юніті задля отримання даних щодо нових фіч (які створювати), їх створення (як створювати), їх випробування у «smaller and free»-проекті, публікація у «bigger paid»-проекті. Наприклад, VS Code та VS. В одному «програмісти» накодили за «дякую», ще пара програмістів за $$ — верифікувала. Якщо «прокатило» — Ctrl+C, Ctrl+V у VS Professional, VS Enterprise. Профіт.

Зокрема, заява Штайнера цікава критичним ставленням до перспектив MySQL та рекомендацією переходити на PostgreSQL

This is your captain obvious speaking

Підписатись на коментарі