В чем основные отличия mySQL от Postgre?

Question

[lxfr]

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

А тут в чем основная разница? В чем основные преимущества постгре, перед mysql, к примеру, если у меня крупный онлайн магазин.

Comments

[DevMan]

Собираюсь переходить, но не понимаю зачем - шедеврально.

[lxfr]

DevMan, это как ездить на мопеде и подумывать перейти на жигули. Чувствуете, интерес есть, а вот чем они лучше?

[Борис Сёмов]

lxfr, Скорее как ездить на мопеде по узкой тропинке вдоль обрыва, и подумывать, а как же я тут на жиге-то проеду, и сколько будет стоить постройка тут шоссе... =)

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

Кстати, и nosql это не быстродействие: это масса разных совсем хранилищ, для совсем разных задач. Где-то быстродействие, где-то отсутствие схемы, где-то масштабируемость где-то отказоустойчивость... И они как таковые не лучше реляционых баз, но конкретный представитель может быть лучше в конкретной задаче, на которую он заточен.

Answer 1

[Алексей Сундуков]

Использую обе РСУБД. Предпочитаю Postgresql, хотя конечно начинал с MySQL. Из того, что на практике приводит к такому предпочтению:
1) Отсутствие проблем на по сути пустом месте. Из последнего было, в одной базе есть таблицы с большим количеством текстовых полей. При вставке в одно из них чуть меньше 200 символов он отказывался ссылаясь на то, что переводите на динамические. И я значит должен начать курить тему движков мускула и выяснять, что мне оказывается нужна Barracuda. При той же InnoDb. Хочется спросить такого черта.
Или вот еще вспомнил. При попытке записи в поле данных, больше чем это возможно для данной колонки он делает запись тупо обрезав лишнее. И проблему могут не заметить очень долго вплоть до момента когда подниматься из бэкапа поздно, там все уже битое.
Или вот взять и сменить могут дефолтные значение переменных в рамках минорной версии. База после накатки апдейтов и ребута может просто не подняться. На хабре даже была статься по этому поводу.
В общем множество подобных ситуаций после которых так и хочется воскликнуть "какого черта?!". Со слоном я не помню ни одной такой ситуации.
2) RETURN во вставках/обновлениях. Можно получить в ответе любое поле такого запроса. И ни каких тебе танцев с LastInsertId.
3) В последних версиях есть UPSERT которого очень не хватало.
4) В целом более строгий подход и нет ощущение бардака.
5) После запуска Postgres Pro появилась полностью руссифицированная документация. Помогает вкатиться в тему новичкам.

Из минусов некоторое время было отсутствие адекватного UI клиента. Но после того, как стал использовать PhpStorm эта проблема была закрыта.

Comments

[lxfr]

Спасибо, познавательно.

Answer 2

[batyrmastyr]

Из простых преимуществ постгреса - многие запросы в нём отрабатывают шустрее, можно весьма гибко прописать ограничения на данные (если в поле "а" что-то есть, то в поле "б" может быть только "с"), даже крупному магазину может хватить настроек по-умолчанию при которых база довольствуется смешным объёмом памяти.

Из недостатков по сравнению с Mysql - нет множеств (заменяется массивом перечислений), большая строгость работы (число или перечисление нельзя взять и сравнить со строкой "5 = '5'", нужно привести их к одному типу "5 = '5'::int" или " 5::text = '5'5 ", а ваша обёртка над базой может быть не готова к такому).

В контексте nosql баз данных например вижу преимущества в быстродействии, например, причем на порядок.

Увы, это преимущество скорее всего окажется мифом - сейчас как раз потихоньку выпиливаем MongoDB.
Если говорить про MongoDB, то в моих задачах он работал либо не быстрее мускуля или постгреса при поиске, либо в разы (в 2 - 50 раз) медленнее при записи. При этом Монга жрала 1,5 гига памяти, мускуль - 300 Мб, а постгрес - меньше 15 Мб (да, меньше жалких пятнадцати мегабайт).

Comments

[tzlom]

Множества в постгрессе есть с 9.1
Да и вообще по количеству возможностей постгрес уступает мускулу только в возможностях по извращённым многосерверным конфигурациям, и то последнее время взял курс на наверстать разницу.

[batyrmastyr]

tzlom, а как они зовутся не подскажете? Что-то в документации из похожего только битовые строки вижу.

[tzlom]

batyrmastyr, с наличием я погорячился, но можно собрать из массива перечислений и соответствующего ограничения

Answer 3

[Елена Степанова]

postgres - массивы, отдельное управление последовательностями (в mysql только одно инкрементное поле на таблицу, в postgres на таблицу можно несколько последовательностей, и одну на несколько таблиц. причем с настраиваемым шагом), оконные фукнции для подсчета статистики https://habrahabr.ru/post/268983/
лёгкое создание полнотекстового поиска без доп. движков типа sphinx и elasticsearch, которого вполне хватает для многих кейсов https://eax.me/postgresql-full-text-search/ , materialized view, наследование таблиц.
Вот более полная таблица фич
https://www.postgresql.org/about/featurematrix/
Но штука в том, что фичи далеко не всегда и везде нужны, поэтому mysql хватает с головой для многих задач

Answer 4

[Алексей Черемисин]

Алгоритмом работы (lock-based/ versioning), транзакциями, хранимыми процедурами, возможностями sql. Это по крупному, в мелочах - еще больше. Собственно, эти базы данных настолько разные, что сравнивать их напрямую нельзя. Каждая хороша для своего класса задач, хотя для магазина/cms обе будут примерно одинаковы.

Comments

[lxfr]

а могли бы вы привести примеры, где стоит использовать, к примеру mariadb, а где postgress?

[Алексей Черемисин]

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

[lxfr]

Алексей Черемисин, на мой взгляд такие вещи как тарантул, например, сейчас могут не менее, чем mariadb, к примеру бложек можно написать и на носикуэль. Вопрос - зачем нужен постгре и чем он лучше масикюэль при том, что есть например redis и тарантул.

Смотрите - юзеров я могу хранить в редисе.
Их посты и комменты - тоже.
Товары - тоже. Покупки тоже.

Просто хочется понять чем так привлекает именно постгре.

[Алексей Черемисин]

lxfr, тем, что это классика, что 95% инструментария заточено на sql, что это путь к успеху, это понятно, просто и эффективно. Nosql не так прост, увы, и чтобы его правильно приготовить, нужно приложить нетривиальные усилия, а порог вхождения на порядок больше, чем в sql. Нельзя просто взять редис и построить модель данных. В тоже время, даже херово спроектированный sql привнесет меньше ошибок, чем херово спроектированный nosql. А при средних нагрузках разницы не будет вообще, будет только больше удобства от sql.
Это как с автомобилями, всем хороши электрокары, но основная масса выбирает бензин и дизель! Их понятно как строить.

[lxfr]

Алексей Черемисин, допустим. И где во всей этой великолепной картине место постгресу?

[Алексей Черемисин]

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

[lxfr]

Алексей Черемисин, вот если бы вам сказали у нас 100 тысяч транзакций донатов в год и пол ляма страничек на сайте, вы какую базы выберете?

[Алексей Черемисин]

lxfr, этого мало, чтобы определиться, очень мало! Для любой базы 500к записей - ниочем!

[Алексей Черемисин]

lxfr, еще раз, для cms пофиг что у вас под капотом, постгрес или мускул.

[lxfr]

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

[lxfr]

Алексей Черемисин,

еще раз, для cms пофиг что у вас под капотом, постгрес или мускул.

речь не о CMS, типа вордпресса. Речь о нагрузке на базу.

[Алексей Черемисин]

lxfr, финансы бы делал на постгресе, а остальное можно на эластике и редисе, или мускуле.

[lxfr]

Алексей Черемисин, а почему финансны на постгрессе? Потому что там есть поля с типом данных финанс?

[Алексей Черемисин]

Нагрузка на базу - она разная! И сильно! В отгом случае у вас транзакция затрагивает 20-30 таблиц и подвывертами, в другом те же самые 20-30 таблиц без транзакций -счетчики обновить. Все сильно будет зависеть и от модели данных и от запросов и от самого приложения. И хорошо спроектированную базу убить можно, пытаясь из нее сделать olap. И херово спроектированную разогнать до космических скоростей.
Серебряной пули нет! Никто не скажет, возьмите базу Х и будет щазтие.
Как пример 1С битрикс, какую базу под него не поставь и как ни оптимизируй - либо на селектах загнется, либо на инсертах, а потому что рукожопие сплошное, вот и извращаются, кто кешами, кто прикруткой редисов, кто голым sql.
Продукт, онине с базы начинается, а с архитектуры, и если мне понадобится воткнуть 5 баз данных, воткну и обосную.

[Алексей Черемисин]

lxfr, финансы, потому что там транзакции честные, а это денюжка ой как любит!

[lxfr]

Алексей Черемисин, а разве mysql не поддержит 500 к транзакций в месяц методом инсерт селект?

[Алексей Черемисин]

lxfr, ну и я вам не объясню, почему Х предпочтительней У в той или иной задаче, оно же вам все равно непонятно будет.

[Алексей Черемисин]

Еще раз 500к транзакций даже в день, и то не нагрузка, ни для постгреса ни для мускула! Вопрос, обычно, не про транзакции, а про их качество.
Берите любую базу.

[Алексей Черемисин]

Обычно говорят, что мне нужно записать информацию в столько-то таблиц по таким-то условиям и если что-то пойдет не так, то вот эта информация должна вернуться в исходное состояние. Вы где нибудь в этой фразе видите тип базы или тип транзакции? И мускул тоже умеет откатить транзакцию, ипостгрес, а вот редис не может (но это не беда, если знать как).

[Алексей Черемисин]

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

[Алексей Черемисин]

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

Answer 5

[Fixid]

Две не самые свежие, но хорошие статьи
1
2

Comments

[lxfr]

Я бы хотел услышать ваше короткое умозаключение "своими словами".

[Fixid]

lxfr, каждый хорош в своей области и для своей задачи. Постгрес сложнее и мощнее, но не подготовленным разработчикам туда лучше не лезть + очень строгий SQL. Использую постгрес с postgis

[lxfr]

Fixid, ну допустим мы тут все подготовленные. Понимаем что такое типы данных ООП и тд.

[Fixid]

lxfr, ну например для типового проекта возьму марию + редис.
для базу больше 300гб уже точно постгрес.
иногда надо прямо указывать тип в запросе (бесит): WHERE login::TEXT = ""

задавайте вопросы точнее

Answer 6

[sim3x]

мускул (и все его производные - мария и перкона) не субд - а обертка для движков
постгрес - обьектно-ориентированная субд

Для владельца магазина - разницы никакой
Если ваш разработчик хочет переходить на постгрес и он ее умеет настраивать - пусть переходит

Answer 7

[Глеб Жуков]

https://habrahabr.ru/company/southbridge/blog/322624/ там написано почему InnoDB лучше чем postgres

Comments

[Алексей Ашурок]

А за три года до этого, Убер перешел с MySQL на PostgreSQL.
Ну т.е. они не следили за пулом соединений, открывали долгие транзакции, что было ок для MySQL, переползли на PostgreSQL и начали страдать от того что эти проблемы на Другой СУБД начали стрелять?
С репликацией я согласен, нужно уметь её готовить в PostgreSQL, равно как и в MySQL. У каждой есть свои плюсы и минусы и в PostgreSQL субьективно это делается с бОльшими танцами с бубном, но по остальным пунктам - есть у меня подозрение что они просто умели в MySQL (и весь их имеющийся на тот момент код) и перейдя на другую СУБД огребли от тех аспектов которые в MySQL не стреляли.

Я поработал с тем и другим и при прочих равных выберу PostgreSQL за более мощную работу с типами и индексами или последнюю MySQL в strict режиме только если команда или заказчик того захотят. Потому что ловить баги "какого хрена у меня в NOT NULL поле ничего не лежит?!" или не получать ошибки при попытке записи строки в 1000 символов в поле VARCHAR(20) - это непосильно для моих нервов =)

[Глеб Жуков]

А за три года до этого, Убер перешел с MySQL на PostgreSQL.

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

[batyrmastyr]

Ждём статью "Как мы обновили MySQL до 8.0, а потом ушли на MariaDB потому, что 8.0 слишком строгий" ))