Глупый вопрос про postgres и mysql

Говнокод?

и главный вопрос: почему mysql популярнее?

Потому что LAMP.

Потому-что она входит в троицу apache+php+mysql, используемую на всех шаред-хостингах последние лет двадцать и задающую тон веб-разработке. Инерция.
Ну а ещё мускуль вполне пристойно работает из коробки, а пострес зачастую требует тюнинга

екзешники

На винфак!

весят по 5-17 мегабайт

Может дело в том что там несколько (в машке даже много) движков хранилища, многие из них весьма жирные и все они вкомпилены в основной бинарь

почему LAMP не LAPP - вот о чем я

Ну а ещё мускуль вполне пристойно работает из коробки, а пострес зачастую требует тюнинга

вот наверное поэтому, да

Потому что psql немного сложнее mysql.

Не знаю, я никогда ни с PHP, ни с MySQL дела не имел.

Буквально сегодня обновился у меня постгрес и база не подымается. Как оказалось нужно обязательно на каждый мажор обновление запускать https://wiki.archlinux.org/index.php/PostgreSQL#Upgrading_PostgreSQL. Я воспользовался их скриптом и как оказалось для обновления базы, нужен бинарник старой версии. Конечно же у меня ее не оказалось, т.к. обновление исходников завершилось. Обновить не удалось, хорошо хоть там база была только тестовая.
у мускула нету такой политики

Буквально сегодня обновился у меня постгрес

archlinux

Ну, ты сам всё знаешь, да?

мажор это с 8 на 9?

мажор это с 8 на 9?

нет, у них мажор это 9.5 -> 9.6
соответственно у меня был 9.5.4 -> 9.6.2 и все, приехали

Ну, ты сам всё знаешь, да?

нет, проясни

Какая разница, с какого дистра это производится. Если Слона так сложно обновить — понятно, почему в хостингах мускуль/маша будут всегда. И хорошо, что так.

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

у меня с 9.1 до 9.5 всё живёт без проблем на генте.

9.6 стабилизируют увидим :-).

хотя тут всё в слотах. параллельно можно поставить.

нет, проясни

Это очень известная проблема archlinux — нестабильность при обновлении софта. Иными словами, там часто всё падает при обновлениях, если вовремя не сделать нужные подпорки. Rolling release, мать его.

Если Слона так сложно обновить

В Fedora, например, его совсем не сложно обновить. Всё зависит от ментейнеров, наверное.

Конечно же у меня ее не оказалось, т.к. обновление исходников завершилось. Обновить не удалось

Арч ставь, мозга не имей? Как насчёт поставить из репозиториев предыдущую версию, которая всегда там есть под другим именем ровно с этой целью?

Это очень известная проблема archlinux

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

А что насчет убера? Говорят, постгре медленнее, держит меньше соединений на тех же мощностях, пишет на диск интенсивнее итд итп

https://eng.uber.com/mysql-migration/

Ох. Тогда неудевительно, что на всех хостингах mysql

Так там все бинари здоровенные. Даже утилитки

Блокировочник проще по архитектуре. В отличие от слона - нормально переваривает тысячи коннектов. Позволяет писать говнокод. myisam - быстр как понос, innodb - практически неубиваем, archive экономит кучу места. Имеет предсказуемый размер базы. Имеет предсказуемое потребление памяти. Не страдает от vacuum'а.

Как-то так.

У MySQL тоже надо запускать mysql_upgrade. Хотя на ней процесс обновление попроще.

innodb - практически неубиваем

ХА-ХА.

Имеет предсказуемый размер базы

И совершенно непредсказуемое потребление памяти %)

archive экономит кучу места

Всегда хотел посмотреть на него в продакшине, но никогда не видел, чтобы кто-то его использовал. И года 3-4 назад в нем было несколько не самый приятных багов.

Ну это действительно рачепроблемы. Что мешало например добавить в пакет (или ебилд, или как там называется штука которую берут из реп и которая автоматизирует ./confirgure && make && make install) проверку версии базы и запуск нужного скрипта до собственно обновления бинарей? Да и мажорную версию логично было-бы ставить не вместо, а вместе со старой

P.S. а потом меня спрашивают почему я называю стабильным некродебиан, а не рачину (в котором всё свежее и пофикшеное). И не надо мне рассказывать что пр наличии мозга рач стабилен, при наличии достаточно качественного мозга всё стабильно

С моей точки зрения DevOps'а, мускуль предпочтительнее.

Оно и проще, и идиоты-разработчики больше опыта с ним имеют (а потому более вменяемы).

В постгресе что мне ну просто дичайше не нравится - необходимость прописывать разрешения на сетевые подключения к базе во внешнем текстовом конфиге - и, соответственно, рестартовать постгрес - а ведь к одному серверу далеко не один проект подключен и на время рестарта всё это недоступно.

В то время, как в мускле достаточно соответствующий GRANT написать и, максимум, добавить flush privileges. Без рестарта мускля.

Что касается размера бинарников, то подозреваю, что попросту в мускуль много чего статикой линкуют. Учитывая общую политику виртуализации «один сервис - одна виртуальная машина» и политику innodb направленную на максимальное использование доступной оперативной памяти - это разумно. Дольше загружается, но зато после этого дисковые операции только на работу с БД.

Дольше загружается, но зато после этого дисковые операции только на работу с БД

А как связаны статическая линковка и дисковые операции?

А при динамической линковке оно откуда будет подгружать библиотечки по мере надобности?

В постгресе что мне ну просто дичайше не нравится - необходимость прописывать разрешения на сетевые подключения к базе во внешнем текстовом конфиге - и, соответственно, рестартовать постгрес - а ведь к одному серверу далеко не один проект подключен и на время рестарта всё это недоступно.

pg_ctl reload?

http://thebuild.com/presentations/uber-perconalive-2017.pdf

1. Его нужно уметь готовить. И, естественно, не для всех задач он подходит идеально.

2. Чистая правда. Такая же правда, что pgbouncer появился не вчера.

3. См. п.1 и не запускай его на тухлых виртуалках.

потому что прощает (прощала, на самом деле, лавочку прикрывают понемногу) больше.

Ну да, наверное.

Неприятность в том, что тут сильное влияние человеческого фактора.

Если в конфигах ошибки, при перезагрузке конфигов сервер рухнет. То есть, это гораздо менее безопасно с точки зрения обеспечения работоспособности сервера, чем «GRANT ... ; flush privileges; »

А запускать несколько копий сервера на машине грешно?

А pg_ctl reload не проверяет кошерность конфигов перед их загрузкой? Или речь о более тонких ошибках чем пропущенная точка с запятой?

почему LAMP не LAPP

Потому что лет 15 назад MySQL был быстрее на характерных для веба операциях (из-за отсутствия транзакционности). 10 лет назад Postgres стал так же быстр в однопотоке и быстрее при параллельной нагрузке от множества запросов (гуглить по «Медленных слонов больше нет»), но MySQL уже плотно занял нишу (кроме того, Postgres более строго относился к синтаксису запросов, т.е. кривые запросы в MySQL работали, как ожидал разработчик, а в Postgres выдавали ошибку синтаксиса). Несколько лет спустя (когда Оракл купил MySQL) начали дорабатывать MySQL до приличной скорости работы на многоядерных процах (включили в основную репу патчи гугла и других разработчиков). При этом у хостеров MySQL был у каждого, а Postgres, если повезет, поэтому веб разработчики так и остались на MySQL (который привычнее, проще (в настройке и прощает кривой синтаксис запросов), есть везде, по скорости уже примерно такой же, а особых возможностей, типа оконных запросов, от базы не требуется).

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

Угадал дистрибутив по сообщению.

инструмент под задачу. ну и неосилятор, да. постгрес очень динамично развивается и это хорошо.

И совершенно непредсказуемое потребление памяти %)

ну-ка?

Какая разница, с какого дистра это производится.

Огромная разница. В Дебиане скрипт установки Postgres все сам сделает, либо выдаст сообщение, что сделать, если требуется ручное вмешательство. Так что возникшие сложности - следствие выбора дистрибутива, но арчеводам этого не понять.

Если Слона так сложно обновить — понятно, почему в хостингах мускуль/маша будут всегда.

У хостеров очень квалифицированные админы. Они не станут обновлять Postgres. Они просто поднимут новую версию на другой машине, дадут пользователю в панели выбрать, какую версию использовать и, возможно, автоматизируют миграцию для уже работающих проектов (но запускать ее нужно будет вручную из панели, если вдруг тебе потребуются возможности более новой версии, а если не понадобятся, то и мигрировать не нужно).

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

//хотя я даже и не припомню, как в ванильном дебиане, я всегда пользуюсь apt.postgresql.org

Postgres все сам сделает

Даже если его не просишь? Даже если база в пару десятков терабайт? Все-равно будет делать дамп?

нет. не делает. посмотрел .deb из убунты, нет такого

Арч ставь, мозга не имей?

обоснуй, с чего ты сделал такой вывод?

Как насчёт поставить из репозиториев предыдущую версию, которая всегда там есть под другим именем ровно с этой целью?

без проблем, я разве где-то говорил что это проблема?
Топик про postgres и mysql. И я лишь указал проблему с которой я лично столкнулся. А из данных у меня была только тестовая база поэтому ее было не жалко, и устанавливать старую версию для миграции просто лень.