В чем PostgreSQL лучше чем MySQL?

Question

[123 123]

Всем доброго времени суток. Последнее время частенько слышу от знакомых которые работают в IT компаниях что мы используем PostgreSQL. Чем же он так хорош. И почему выбирают именно его? Неужели MySQL так плох. Буду рад услышать что вы думаете по этому поводу.

Answer 1

[Никита Любчич]

Тыц.

Comments

[123 123]

Спасибо, почитаю.

Answer 2

[Дмитрий Энтелис]

devacademy.ru/posts/sqlite-vs-mysql-vs-postgresql
www.ibm.com/developerworks/ru/library/os-mysql-pos...
и далее в google и toster
А еще есть разные форки mysql: mariadb, percona, galera.

Comments

[123 123]

Спасибо за ссылки. Почитал. Но все же. Хотелось услышать ваше мнение, если вы сталкивались с перечисленными БД и знаете их отличие.

Answer 3

[Вячеслав Успенский]

Если коротко: практически всем.
- Намного лучше оптимизатор, перед которым не нужно плясать с бубном как с MySQL.
- Намного более продвинутый язык - pl/PgSQL + возможность использовать Java
- Схемы
- Продвинутые констрейны, при желании можно например проверять попадание точки на карте в заданную область.
- Rule instead/Also
- Массивы
- Множество продвинутых типов данных как например hstore или jsonb с возможностью использования индексов
- Именованные Prepared
- крайне продвинутый FTS, который можно гибко настраивать и исползовать для многих разных целей (все же прямой поиск по текстам я предпочитаю выполнять при помощи sphinx/elastic)

Это все - первое, что пришло в голову. Кроме на Postgre можно легко и просто реализовать почти всю или всю логику и выбирать наружу только данные ужо.

Если MySQL хватает - хорошо. Если же нужны сложные связи данных, всякие навороченные штуки, то переход с my На postgre довольно приятен 8)

UPD: ах да, еще рекурсивные запросы, очень много раз жалел что в MySQL их нет

Comments

[123 123]

Ну я уже поставил. Буду смотреть как работает + разбираться с её фишками.

[Дэн Иванов]

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

[whats]

ptchol: представляю ваш говнокод в проектах где вы на вашем ЯП обрабатываете данные которые должна была обработать база данных

[Дэн Иванов]

Причем здесь говнокод :) Есть уровень сырых данных, а есть уровень представления. Эти самые представления, необязательно реализовывать на уровне БД, есть замечательные быстрые кэши, которые позволяют это красиво организовать, и эффективно сжать при необходимости, сохранив скорость доступа.

[Вячеслав Успенский]

ptchol: и на кой черт выносить представления из бд? Бд это сделает в разы быстрее при грамотной реализации. Распихиваем данные в нормализованном виде по таблицам, обвешиваем констрейнами, потом прорисовываем связи во вьюхе, потом обвешиваем вьюху Rule'ми и с ней работаем. Все, пока нам не нужна иная форма представления - идеальные вариант, можно даже другому отделу отдать - они впринципе ничего сломать не смогут. Но для такого подхода нужен архитектор - да.

Грамотная логика в бд она не вредит а наоборот. Простой пример: писал я для одной компании форум на Mysql, быстрый и простой. Для скорости чтения в родительском элементе хранилась информация о последнем посте,авторе итд, все это обеспечивалось пачкой триггеров. В итоге когда коллега трогал это дело через phpmyadmin или консоль, все работало как ему и положено

[Дэн Иванов]

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

[Вячеслав Успенский]

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

[tushev]

А почему при всем при этом MySQL на 1-2 порядка более распространен в веб-проектах?

[Вячеслав Плиско]

tushev популярность сложилась исторически был момент, когда mysql сильно выигрывал в простоте установки и хорошими дефолтными настройками. Администрирование предопределило популярность, а функциональность не столь важна для большинства проектов.

[Вячеслав Успенский]

OnYourLips: да какое зло, я вас умоляю) Когда у вас есть архитектор бд и отдел программистов, да вы молится на него будете если БД будет контролировать все и вся во имя целостности связей данных и их корректности

[Вячеслав Успенский]

OnYourLips: ок, модифицирую вашу задачу еще одним вопросом: данные будут добавляться только вашим приложением? Или только приложением этого отдела?
То, что ниукого никогда нет архитектора БД и программер он же архитектор бд есть великая проблема, но мне даже лучше, я себе на игрушки зарабатываю людьми, который приходят с: "аааа, сайт лежит базазагнуласьнизнаючтоделать" и всегда, на 100%, во всех случаях, виноваты программеры.

[Алексей Павлов]

Postgres периодически запускает процедуру обслуживания файлов базы, которая называется вакуум. В некоторых случаях, выполнение этой процедуры может затянуться на несколько секунд.
Вячеслав Успенский OnYourLips А как вы боретесь с вакуумом?

[Вячеслав Успенский]

Алексей Павлов: зачем с ним бороться? его грамотно настраивать нужно) то о чем вы говорите называется автовакуум и если его выполнение затягивается на несколько секунд, значит у васм серьезные проблемы где-то

[Вячеслав Успенский]

OnYourLips: ну, вам везет 8) У меня последний из случаев -классический: собственная разработка + 1с УТ. Делать все из ут? да мы в ней самой используем обращение к вьюхам вместо ее собственного ORM. Ибо выигрыш в производительности доходит до 1000%

[Вячеслав Успенский]

OnYourLips: 1с использует ODBC либо напрямую из ее скриптов либо при помощи новшества а-ля внешние источники данных (8.2.5+)

Answer 4

[Иван]

А еще лицензирование.

Answer 5

[whats]

Всем лучше чем mysql
Особенно функционалом и хранимыми процедурами.
Репликация в 4 шага, так же легко как и mysql.
Большинство статей сравнивают со скоростью, но это все бред. Реляционные базы это не скорость а удобство. Хотите скорость установите NOSQL. Но даже в этом случае база быстрее.

Ну а самый главный плюс - это люди которые ее разрабатывают. Постоянное совершенство и следование стандартам. Чего нельзя сказать о гомункуле mysql

Comments

[Вячеслав Успенский]

NoSQL со своей скоростью идет лесом, как только вы попытаетесь использовать джоины, в некоторых тестах posgre со своим jsonb хранилищем легко и просто обгоняет mongodb

[whats]

Вячеслав Успенский: Join и nosql ? зачем вам оно тогда, оно не создано для этого! Но в любом случае все зависит от схемы по которой вы решаете задачу. Никогда еще реляционные базы не выигрывали по скорости перед nosql решениями.

[Вячеслав Успенский]

whats: давайте не будем разводить оффтопик, просто скажу: вижу такое постоянно, на хабре споры были эпические не так давно на эту тему.

[Вячеслав Успенский]

whats: и вы легко можете найти в гугле информацию как и почему в приведенной мной ситуации postgre обгонял mongo

[whats]

Вячеслав Успенский: в синтетических тестах, то есть тесты ради тестов. Если бы вы знали как устроены 2 вида этих баз вы бы не писали такое. Я бы не стал использовать джоины.

[Вячеслав Успенский]

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

[whats]

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

[Вячеслав Успенский]

whats: и вам того же. Только в следующий раз не включайте режим Ванги 8)

[Дэн Иванов]

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

[Вячеслав Успенский]

ptchol: у нас то как раз постоянно, а вот как делают другие мне неподвластно, посему тезис "Никогда еще..." и выглядел несколько странно. На хабре совсем недавно была статья про Mongo. Там в комментах джины на джоинах.

[Денис Никаноров]

whats прав. Джоины и nosql (даже не только nosql, а highload в целом) не совместимы. Если учитывать, что архитектура многих нагруженных приложений строится как набор отдельных взаимодействующих приложений (которые могут быть запущены на нескольких машинах), то о каких джоинах речь?

[whats]

SlimHouse: ну человек делает маленькие сайты, уровень пока еще не тот. Тут нет смысла ему что то доказывать. Настанет время и он сам все осознает.

[Вячеслав Успенский]

SlimHouse: на хабре поищите - увидите о чем я. Там горячно обсуждался IMBDlike на MongoDB

[Вячеслав Успенский]

whats: я не делаю сайты, моя стезя - веб приложения и у меня аллергия на NoSQL, хотя была возможность и повод их использовать.
ЗЫ не переходите на личности, если вам влом зайти на самый посещаемый айти ресурс и глянуть комменты - этио ваши личные проблемы

Answer 6

[Boniface]

Postgres просто офигенен! Это я как любитель noSql говорю.

+ Очень быстрая
+ (ИМХО) понятно масштабируется
+ Мощные хранимые процедуры

По моему Postgres можно сравнивать с самим Oracle db!

Comments

[Вячеслав Успенский]

ну оракл неимоверно крут, но да, можно) Некоторые вещи в оракле сложнее, некоторые проще

[Boniface]

guessss_who: хрень полная, а не киллер фича ;)

[whats]

guessss_who: у постгреса он тоже есть, и вообще не киллер нифига

Answer 7

[Алексей Волегов]

Если вам в проекте нужны выборки по GEO координатам, то вам нужен — PostgreSQL.
Во всех других случаях лучше взять MySQL, темболее если вы его уже знаете.

Comments

[Boniface]

1) Да, есть даже расширение -Postgis (postgis.net/) 2) Вы что!!! с дуба рухнули... и вообще это не совет!

[Алексей Волегов]

Boniface: с чего бы? Все советы приведенные выше новичку как мертвому припарка. На практике большинство описанных фитчей не применяется. И единственное в чем реально есть приемущество — так это в гео индексах с реальным приростом скорости.

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

[Boniface]

Так никто не спорит, что MySQL решает свои задачи :) По моему мускул очень даже не плох! Но, вы говорите следующее: " Если ван нужно делать запросы к данным Geography или Geometry, то используйте postgres, если нет то mysql" - вот это полный бред ;)

Answer 8

[lubezniy]

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