Почему говорят, что postgress лучше для более-менее серьезного проекта чем что-либо иное?

Question

[suhuxa1]

Добрый день!
Всю жизнь работал только с mysql, и куда-либо переходить желания особого нет (разве что для саморазвития).
Однако в последнее время все чаще и чаще я встречаю людей на форумах, которые говорят так:
"Если планируете серьезный проект - выбирайте постгрес. Если планируете простой проект, который в дальнейшем будет расти в серьезный - опять же - постгрес".

А почему?
Чем, например, mysql хуже?

Только попрошу ответов из практики. Потому что по техническими характеристикам я читал много, и честно говоря мало что понял: мускул реляционная база, постгрес - объектно реляционная. Это все хорошо, но хотелось бы понимать как это будет влиять на проект.

Спасибо!

Answer 1

[Сергей Горностаев]

Этот вопрос на Тостере задают примерно раз в неделю и в Интернете полно сравнений. Например, это или это. Для меня лично самый главный косяк MySQL в том, что в 2018-м году он даже стандарт SQL 92-го года поддерживает не в полном объёме. Или вот косяк из недавнего вопроса - он не запускает триггер на действиях с внешними ключами. И таких косяков просто чудовщное количество. Как только выходишь за рамки чего-то сложнее select * from some_table, начинаешь материть разработчиков ежесекундно. И ещё один факт, мало влияющий на повседневную работу, но достойный упоминания - при проверке статическим анализатором кода нескольких популярных СУДБ, MySQL по количеству ошибок оказался на первом месте с существенным отрывом!

Comments

[Виталий]

проблема современности в другом, люди не выходят за пределы орм, а потому понять эту разницу очень сложно.

[Сергей Горностаев]

Виталий, смешная часть этого в том, что если проект выстрелил и дорос до того уровня, когда ORM надо подпиливать или вообще от него избавляться, столкновение с MySQL будет существенно более болезненным, чем было бы с PostgreSQL, если бы его выбрали в самом начале.

[Виталий]

Сергей Горностаев, я давно с мискуля слез, меня устраивает постгря

[Donald_Duck]

Сергей Горностаев,

когда ORM надо подпиливать или вообще от него избавляться

Простите за глупый вопрос, но что используется вместо ORM на более крупных проектах?

[Сергей Горностаев]

Donald_Duck, вопрос не в крупности, а в нагрузке. ORM для крупности как раз хорош, большую кодовую базу с ORM легче сопровождать. Но под высокими нагрузками ORM часто становится бутылочным горлышком системы и вопрос удобства разработчика отступает на второй план. Обычно, в этот момент особенно кучерявая часть модельной логики переезжает в хранимые процедуры. С дальнейшим ростом нагрузки проект может полностью избавиться от ORM и перейти на голые SQL-запросы.

[DevMan]

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

[Donald_Duck]

Сергей Горностаев, DevMan, Большое спасибо за пояснение, теперь понятно.

[xfg]

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

[Станислав Б]

xfg, а что же создавалось под веб тогда?

[xfg]

Станислав Б, большинство из https://en.wikipedia.org/wiki/NoSQL

Интернет распределенная система и приложения под неё тоже желательно делать распределенными.

[sazhyk]

xfg, не спешите с выводами. Инструменты надо использовать по назначению. Там где надо использовать РСУБД - надо использовать их, там где NoSQL - соответственно их. Вы же не покупаете камаз, что бы ездить в булочную в соседнем квартале))

Answer 2

[abroabr]

Не так.

Серьезные проекты, например, у того же Google прекрасно работают и с MySQL

Дело в другом - у PostgreSQL больше функционала. Если он вам нужен и если вы умеете им пользоваться.

У MySQL функционала меньше, он проще, и потому во многих случаях быстрее.

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

Как пример, JSONB (рекомендую его в PostgreSQL, работает эффективно, позволяет реализовать schemeless). Не путать с JSON (это старая реализация в PostgreSQL, не рекомендуется).

Смотрите выступления Олега Бартунова на Youtube - он разработчик PostgreSQL и проводит просветительскую работу по некоторым особенностям PostgreSQL.

Comments

[Сергей Горностаев]

Быстрее? Разве что на обычной выборке по PK. На сложных запросах MySQL печален.

[abroabr]

Сергей Горностаев, я же написал по функционал. трактуйте сложные запросы как "расширенный функционал".
по факту это будет не "сложные запросы", а "дико сложные". "умеренно сложные" запросы MySQL переваривает хорошо.

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

[Сергей Горностаев]

abroabr, под сложным запросом я имею ввиду запрос с подзапросами, объединениями и группировками. Ничего экстраординарного, никаких CTE, оконных функции или JSONB.

[Сергей Горностаев]

Впрочем, свежий MySQL и на простых запросах стал сливать относительно свежему PostgreSQL. Тыц.

[abroabr]

Сергей Горностаев,

под сложным запросом я имею ввиду запрос с подзапросами, объединениями и группировками. Ничего экстраординарного, никаких CTE, оконных функции или JSONB.

Понятие сложности у каждого свое.

Работая над проектами с миллиардными (в месяц) оборотами - сталкивался с SQL-подзапросами лет 5 назад. Архитектура вообще, где можно перепилена на СУБД in-memory key-value, где проще лишний запрос сделать, чем с подзапросами заморачиватсья.

прочем, свежий MySQL и на простых запросах стал сливать относительно свежему PostgreSQL. Тыц.

А кто даст гарантию, что у автора будут именно подобные запросы? Или вообще никогда такого не будет?

Я думаю, что это очевидно всем, что не нужно доверять абстрактным бенчмаркам, а следует проверить как работает та или иная СУБД на конкретно ваших "кейсах".

[Сергей Горностаев]

abroabr, ну, автор вопроса нам кейс не предоставил. Уверен, что у него его и нет в данным момент. А значит обсуждаем сферического коня в вакууме - большинство случаев, средние значения, показатели синтетических тестов :)

[abroabr]

Сергей Горностаев, мы полагаемся всего-то на вкус авторов синтетических тестов. почему именно этих?

Серьезные синтетические тесты разбиты на группы - имитация OLTP-нагрузки, имитация OLAP-нагрузки. Чтобы каждый мог выбрать даже заочно под свою задачу.

[DevMan]

Сергей Горностаев, постгрес всегда был хорош своей предсказуемостью.
он как трак с низкооборотистым движком: ему похер тянуть 20 тонн со скоростью 50 км/ч по ровной дороге или в горку под 45 градусов.

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

Answer 3

[Армянское Радио]

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

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

Comments

[abroabr]

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

А HandlerSocket у MySQL пробовали?
https://ruhighload.com/mysql+handlersocket

[lubezniy]

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

[Армянское Радио]

lubezniy, аналогии из реального мира зачастую не катят для айти.

[Сергей Горностаев]

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

Answer 4

[sim3x]

постгрес - СУБД, с ядром, которое начало разрабатываться, когда части аудитории еще не было в проекте, при спонсировании DARPA в Беркли

мускул - обертка над субд (innodb, myisam, etc), на 9 лет позже, в Швеции не в универе, создавалась как скуль обертка для другого ЯП

Answer 5

[АртемЪ]

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

Answer 6

[fridary]

Меня радуют функции агрегаты в postgres, которых в mysql я не находил