Xpoint
   [напомнить пароль]

MySQL vs PostgreSQL

Метки: [без меток]
2007-09-05 12:25:27 [обр] Денис Ибаев aka Dionys(0/57)[досье]

Встал вопрос выбора СУБД для проекта. Есть 2 варианта MySQL 5.0/5.1 или PostgreSQL последней версии. Основные критерии выбора: транзакции, триггеры, вложенные запросы и хранимые процедуры. Но всё это есть в обоих СУБД. Поэтому меня интересуют особенности работы с вышеперечисленным и возможные проблемы. Также весьма актуален вопрос производительности.

Поделитесь своими соображениями на этот счёт. И, если это возможно, опишите, для каких проектов лучше подходит та или иная СУБД.

спустя 21 минуту [обр] Thirteensmay(0/157)[досье]
Транзакции, триггеры, вложенные запросы и хранимые процедуры...
А Вы посмотрите на возможности программирования этих вещей в MySQL, все станет понятно. Если планируете большую часть функциональности перенести в базу, что верно для более менее масштабных проектов, то IMHO PostgreSQL однозначно. А что касается особенностей и проблем: Опыт эксплуатации PostgreSQL
спустя 24 минуты [обр] Dennis F. Latypoff aka funky_dennis(0/84)[досье]
Разницы никакой, обе базы когда-нибудь загнутся. Тут главное разработать архитектуру всего проекта так, чтобы весь проект был неубиваем при любых условиях. Если Вам так необходимы триггеры, вложенные запросы и хранимые процедуры — это говорит о том, что архитектура у Вас слабая. Кто-то постоянно говорит, что Оракл делает mysql и postgresql вместе взятые, http://abava.blogspot.com/2007/08/commit.html
спустя 13 минут [обр] Thirteensmay(0/157)[досье]
Dennis F. Latypoff aka funky_dennis[досье] Ну так у них и название соответствующее, люди разные бывают, некоторым вполне достаточно жизненного цикла в 5..7 лет (время безболезненного существования после того как проект БД загнется) и хочется более менее удобства. Ну а про слабость архитектуры это Вы откровенно загнули.
спустя 52 минуты [обр] Денис Ибаев aka Dionys(0/57)[досье]
Thirteensmay[досье], я уже читал Опыт эксплуатации PostgreSQL. Но там об эксплуатации только одной СУБД, а хотелось бы ознакомиться именно со сравнением.
спустя 5 минут [обр] Давид Мзареулян(8/1003)[досье]
Разницы никакой, обе базы когда-нибудь загнутся.

Добрый Вы:)

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

Ну, у Вас в портфолио, конечно, лежит с десяток таких проектов?:)

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

Skype работает на PosgreSQL, и у них всё основано на хранимых процедурах. В частности, это им позволяет «прозрачно» вызывать эти процедуры из одной точки на всём кластере баз данных.

спустя 22 минуты [обр] Thirteensmay(0/157)[досье]

Денис Ибаев aka Dionys[досье] Есть такие сравнения в сети, правда устарели, из свежих припоминаю сравнение производительности на opennet ссылка была посмотрите, там суть в том что mysql быстрее на однопроцессорной машине с небольшим кол-вом одновременных запросов, при увеличении кол-ва процессоров postgre выходит вперед и показывает лучшую нагрузочную способность. По поводу возможностей программирования я уже сказал, надежность насколько я понимаю у обоих на уровне. Естественно я не имею ввиду мегапроекты, а для скажем так средних типа сотен таблиц, десятков одновременных запрсов и т.п. разницы впринципе нет, ну за исключением более расширенных возможностей программирования в postgre. Короче, создается такое впечатление что postgre будет несколько постарше, не знаю, сам вот попробовать хочу...

Давид Мзареулян[досье] Rambler тоже вроде говорят под Postgre ? И если про триггеры ничего особо хорошего сказать немогу, хотя... То уж вложенные запросы и хранимые процедуры назвать слабостью архитектуры... Dennis F. Latypoff aka funky_dennis[досье] Ну предложите такиеже удобные, простые и эффективные с точки зрения производительности инструменты, только чтобы это было реально для среднестатистического использования.

спустя 1 час 20 минут [обр] Давид Мзареулян(8/1003)[досье]
Thirteensmay[досье] «И если про триггеры ничего особо хорошего сказать немогу, хотя...» — а плохое можете сказать? По моему опыту — ну триггеры и триггеры. Работают. Но, может, я каких-то минусов не знаю.
спустя 1 час 10 минут [обр] Thirteensmay(0/157)[досье]
Ну, мне прямолинейные вещи нравятся, а триггеры, ну что, тоже самое что и с mod rewrite и регулярными выражениями, работают конечно, и местами от этого классный эффект, но и заморачивает оно тоже, и проблем если какой косяк добавляет. Могу сказать что с ними надо быть особо аккуратным, взвешивать и не злоупотреблять, наверное так.
спустя 2 минуты [обр] 30-ый(4/584)[досье]

> Если Вам так необходимы триггеры, вложенные запросы и
> хранимые процедуры — это говорит о том, что архитектура
> у Вас слабая

На месте модератора я бы вмешался с большой синей "М", ибо нельзя пользователям разрешать пороть чушь в форуме. Сформулирую иначе: Если вы ни разу не испытывали необходимости в триггерах, вложенных запросах или хранимых процедурах (хотя бы в чем-то из списка), значит вы с серьезных проектах ни разу не учавствовали.

спустя 19 часов [обр] Денис Ибаев aka Dionys(0/57)[досье]
Товарищи, давайте не будем отклоняться от темы. Необходимость триггеров и прочего — вопрос конечно интересный, но в данный момент не актуальный.
спустя 22 дня [обр] Сергей Сирик(19/737)[досье]

Денис Ибаев aka Dionys[досье]
Тяжко в Мускуле с хранимками и триггерами. Последние так вообще ни одной из распространенных админских тулзов не отображаются. С хранимостями работал - танцы с бубном однозначно. Траблы с кодировками, иногда странные результаты. Весьма убогое описание программирования этих самых хранимостей. Это при достаточно высоком уровне хелпа по Мускулю как такового.

А Постгресс мне не понравился еще когда Мускуль был маленький и глупый (т.е. без хранимостей, вложенных запросов и т.д.). И вообще он странный ... объектная (или как там она правильно называется) СУБД с эмуляцией сиквела чтоб ей хоть кто-то пользовался :)

Хотя вложенные запросы Мускуля - тоже отдельная песня. Там надо быть достаточно внимательным к производительности. Пример из личного опыта - структурка и достаточно сложный вопрос к нему (вложенности, джойны и т.д.). Один и тот же компутер. На Мускуле выполняется 12 секунд ... на MS SQLе - 1 :)

Отсюда вывод - попытаться убедить начальство выложить денег на Оракл :)

спустя 42 минуты [обр] Давид Мзареулян(8/1003)[досье]
объектная (или как там она правильно называется) СУБД

Это с каких это пор???

Вообще, с тех пор, «когда Мускуль был маленький и глупый», много воды у текло. Очень. И для Мускуля и для Постгресса. Может, свежим взглядом взглянуть? Оракл — штука хорошая, только вот деньги основные деньги пойдут не на него, а на приставленного ораклоида:)

спустя 1 день [обр] Nuclon(0/22)[досье]
чем это постгрес странный, позвольте спросить?
объектная СУБД?? с этого момента - поподробней, пожалуйста.
спустя 10 часов [обр] Дмитрий Кононов(0/16)[досье]

Dennis F. Latypoff aka funky_dennis[досье]
Про слабую архитектуру, пожалуйста, подробнее.

Денис Ибаев aka Dionys[досье]
Все зависит от того, для чего вы будете использовать БД.
Без привязки к задаче сложно что-либо советовать.
Для многих веб-проектов и других, где данные изменяются редко, лучше использовать mysql.
Если же в базу одновременно пишут десятки и сотни клиентов, то следует остановиться на pgsql.
Бывают задачи, где достаточно будет sqlite или даже bdb, и не надо поднимать громоздкие БД и приставлять к ним человека, чтоб следил.

Если вкратце, то mysql хуже держит большую нагрузку по записи.
Либо затыкается, либо данные портит (как раньше).
Ссылки не просите, поищите сами.
Mysql использует нити (threads), а pgsql на каждое соединение создает процесс.
Смысл в том, что не во всех ОС планировщик задач хорошо справляется с нитями, процессы же отрабатываются лучше, отсюда масштабируемость на SMP, что нужно учитывать для высоконагруженных проектов.

Фичи, которые давно были во "взрослых" БД (триггеры/хранимки), в mysql появились относительно недавно, отсюда сами можете сделать выводы. Тут уже правильно говорили про подзапросы. Хотя и в постгресе фиксят ошибки, которые приводят к порче индексов, а также делают новый релиз сразу после выпуска предыдущего, чтоб пофиксить серьезную ошибку. Тут нужно смотреть объективно: баги находят везде.
В постгресе хранимки можно писать на pl/pgsql, pl/perl, pl/python, pl/tcl.
В мускуле, насколько знаю, только встроенный язык.
Еще постгрес — версионник, отсюда плюсы и минусы.
Например, при дампе база не блокируется. Но есть такая штука, как VACUUM, которая, впрочем, не представляет особой проблемы.

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

спустя 12 часов [обр] Сергей Сирик(19/737)[досье]

Вот про объектность :)
Other advanced features include table inheritance, a rules systems, and database events. Table inheritance puts an object oriented slant on table creation, allowing database designers to derive new tables from other tables, treating them as base classes. Even better, PostgreSQL supports both single and multiple inheritance in this manner.

Отсюда: http://www.postgresql.org/about/
А тут http://www.postgresql.org/download/ еще интересней :)

Насколько помнится, Постгерсс сам по себе - детище кого-то из оркалоидов, решивших развить объектные идеи, которые как-то пытались заложить в Оракл. Даром что ли и PL\SQL и Постгресный его аналог есть "творческое переосмысление" одного из классических объектных языков - Ады?

А по поводу затрат на Оракл ... Если проект в один распрекрасный момент выйдет за возможности Мускуля по производительности, то это будет стоить значительно больше денех. В Оракле значительно больше встроенных средств увеличения производительности системы. Т.е. приемы борьбы с тормозами более стандартизованы и универсальны. И найти хорошего "борца за производительность" в Оракле значительно проще, чем аналогичного уровня Мускулиста, где реально нагруженных Мускульных проектов не так уж и много. И любой проект обладает своей уникальной спецификой, которую не факт что удастся применить в другом проекте.

спустя 19 минут [обр] Давид Мзареулян(8/1003)[досье]
Other advanced features include table inheritance, a rules systems, and database events. Table inheritance puts an object oriented slant on table creation, allowing database designers to derive new tables from other tables, treating them as base classes. Even better, PostgreSQL supports both single and multiple inheritance in this manner.

Всё это в P. имеется, но пассажи про “object oriented” — это пиаровская трескотня. P. — нормальная реляционная база. «Наследование» таблиц в нём к ОО-наследовани отношения не имеет.

Насколько помнится, Постгерсс сам по себе - детище кого-то из оркалоидов, решивших развить объектные идеи, которые как-то пытались заложить в Оракл. Даром что ли и PL\SQL и Постгресный его аналог есть "творческое переосмысление" одного из классических объектных языков - Ады?

Я не очень понял, это в плюс, в минус или так, для сведения? В любом случае, если там и есть какие-то родственные связи, то завязывались они лет 20 назад (http://en.wikipedia.org/wiki/Postgresql#History), а тогда и Оракл ещё в пелёнки гадил, и Мускуля ещё и в проекте не было.

Против Оракла ничего не имею (нэ знаю, нэ щупал), но в условиях задачи он не был упомянут. Ну как если бы человек спрашивал, на чём ему лучше кататься на дачу — на жигуле или на москвиче, а Вы бы ему стали советовать белаз — а вдруг случится небывалый урожай картошки…

спустя 10 часов [обр] Сергей Сирик(19/737)[досье]

Давид Мзареулян[досье]
С моей точки зрения - это минус :) Потому как реляционку "натянули" на не совсем родную структуру-архитектуру. Хотя действительно многое уже могло поменяться ...

Почему Оракл - потому что в условиях задачи упоминаются достаточно сложные вещи: хранимости, триггера и т.д. У Оракле же эти вещи реализованы самым богатым образом - и сам PL\SQL, и Ява в хранимостях - сложно переплюнуть. А если посчитать денежку, всю, с учетом рисков - то и не так все грустно с Ораклом получается ...

спустя 2 часа [обр] Thirteensmay(0/157)[досье]

Сергей Сирик[досье]
Ну, начать с того что Postgre старше Oracle на добрые 10 лет, или если уж придраться к имени то как минимум ровесник. Postgres вовсе не детище кого-то из оркалоидов, и это изначально реляционная СУБД. http://www.sai.msu.su/~megera/postgres/talks/what_is_postgresql.html Так что все эти "натянули" и "object oriented" - в зад. Просто Postgres поддерживает много чего, а ктото нет...

Что касается "странности" Postgres, то это вещь субъективная, уж не знаю что у Вас там стряслось ;) но вот мной например, человеком новым, разбирающимся с последней версией, никаких странностей не замечено.

Далее, смотрим на тему, причем здесь Oracle ? То что он крут это конечно несомненно, и то что Postgres где то посередине между Мускулем и Oracle тоже очевидно, но это вовсе не значит что лучше через него перепрыгнуть. Ну вот есть у меня среднестатистический intranet проект автоматизации организации, до сотни одновременно работающих пользователей, сотни таблиц, естественно хочется нормальных возможностей серверного программирования, коих Мускул не предоставляет, чтож мне Oracle теперь покупать ? Да ну нафиг, Postgres вполне справится, он бы и Мускул справился, просто корячится не охота. Получим удобство в программировании и сэкономим несколько десятков килобаксов. Oracle говорите ? - лесом, лесом...

спустя 2 часа 6 минут [обр] Сергей Сирик(19/737)[досье]
Thirteensmay[досье]
А Вы пробовали статью целиком прочитать???
"Еще при проектировании оригинальной версии POSTGRES основное внимание было уделено расширяемости и объектно-ориентированным возможностям ..."
спустя 7 минут [обр] Сергей Сирик(19/737)[досье]
Thirteensmay[досье]
Оракл для Ваших задач и объемов стоит 5 килобаксов ...
спустя 13 секунд [обр] Сергей Сирик(19/737)[досье]
Денис Ибаев aka Dionys[досье]
Сорри за оффтопик.
спустя 3 часа 5 минут [обр] Thirteensmay(0/157)[досье]

Сергей Сирик[досье] Ну уделили, и что ? это же не значит что под корень отказались от всех реляционных идей, посмотрите кто это делал, и на основе чего,, обычное развитие, расширение функциональности... Что то конечно выкинули, и вполне возможно много, но как показала практика остатка хватает для полной поддержки реляционности, ну или скажите чего такого реляционного в постгресе сделать нельзя ? А вообще чего мы будем спорить, от части Вы правы, и сами разработчики называют постгрес не иначе как объектно-реляционная система управления базами данных уж они то знают наверное что к чему. Только вот думаю что скрещивание такое вовсе не минус ;) Новые возможности и функциональность появились ? - да, старые остались ? - да, появились тормоза ? - нет. Это плохо ?

Ну не 5 а 15, узнавали... и это только единовременно лицензии...

спустя 1 час 32 минуты [обр] Давид Мзареулян(8/1003)[досье]
Потому как реляционку "натянули" на не совсем родную структуру-архитектуру.
Ну, извините, это просто не имеет никакого отношения к действительности.
спустя 3 часа 35 минут [обр] Сергей Сирик(19/737)[досье]

Thirteensmay[досье]
Ммм, я собственно про это вот: http://oraclestore.oracle.com/......CtpSctDspRte.jsp?section=15105
Оракл обладает весьма гибкими условиями лицензирования, тот же Энтерпрайз можно покупать на 1-2-4 года. Т.е. фактически в рассрочку. А с учетом того, насколько часто выходят новые версии - раз в 4 года просто переходим на новую версию.
В общем, хочу сказать, что Оракл - не настолько дорогущая штука как кажется на первый взгляд. Просто считать надо не "в лоб" ... Конечно, если использовать Оракл на уровне возможностей Мускуля - то будет очень дорого, но в нем же есть куча других интересных возможностей :) Кстати, интранет приложение можно написать на одном Оракле, БЕЗ использования РНР, Явы или любого другого серверного языка. Вот и посчитайте, что будет дешевле - разнородная (ДБ+ЯВУ) или однородная (только ДБ) команда??

Давид Мзареулян[досье]
Еще цитата из той же статьи :)
"В 1995 году они заменили язык запросов POSTQUEL на общепринятый SQL".

Хотя Постгресс поддерижвает "Частичные индексы (partial indices) - можно создавать индекс по ограниченному подмножеству значений" - очень пользительная штука с точки зрения производительности. Еще дойти до partial tables - и будет почти Оракл :)

спустя 1 час 21 минуту [обр] Давид Мзареулян(8/1003)[досье]
Сергей Сирик[досье] Сергей. Вы чего-то всё пытаетесь доказать всем, но чтобы доказать, надо хоть немного разбираться в предмете. Постгреса Вы не знаете. Оракл — хорошая штука, все согласны. Ну так чего ещё-то Вы хотите?
спустя 1 день 13 часов [обр] Давид Мзареулян(8/1003)[досье]
P.S. Об истории Постгреса и не только: http://postgresmen.ru/articles/view/57 — статья Олега Бартунова, немного устаревшая (написана в 2005-ом), но тем не менее.
спустя 22 часа [обр] Сергей Сирик(19/737)[досье]
Давид Мзареулян[досье]
Это именно та статья, на которую приводится ссылка выше :) И именно из нее я черпал основную информацию, из которой уже в свою очередь делал выводы.
спустя 1 год 5 месяцев [обр] vitalif[досье]
А вот я хочу добавить насчёт "Оракл - хорошая штука":
С моей точки зрения, тот же MySQL по сути своей гораздо красивее ораклятины. Оракл - МОНСТР. Туда напихано ну ОЧЕНЬ много всего и вперемешку, такое впечатление, что авторы просто не знают, что нужно, а что не нужно, и добавляют всё подряд, только бы продать.
Он, конечно, и хорош - тем, что (особенно так было в начале) на тех объёмах данных, на которых он работает нормально, больше просто не работал никто, все загибались.
И PL/SQL аналогично. "Язык Ада". БЫГЫН, ..., буль-буль, ЭНД. Меняешь кодировку - работает в 10 раз медленнее.
И реализация встроенной Java - тоже ужас сплошной.
И конфиг - как будто прошлись по коду, и вытащили туда все константы.
спустя 21 минуту [обр] Давид Мзареулян(8/1003)[досье]
Оракл - МОНСТР. Туда напихано ну ОЧЕНЬ много всего и вперемешку, такое впечатление, что авторы просто не знают, что нужно, а что не нужно, и добавляют всё подряд, только бы продать. Он, конечно, и хорош - тем, что (особенно так было в начале) на тех объёмах данных, на которых он работает нормально, больше просто не работал никто, все загибались.
По-моему, Вы какой-то бред пишете.
спустя 18 часов [обр] Thirteensmay(0/157)[досье]
vitalif[досье]
Это Вы правда чтото того...
 
Моменты связанные с тем что он монстр конечно есть, но это дело опыта, так что в зад. По поводу begin/end - мелочная придирка обусловленная вашими личными капризами, реальной хоть сколь-нибудь значимой проблему тут нет. "Aвторы просто не знают, что нужно, и добавляют всё подряд" - ага, делать им нефиг за бесплатно добавлять все подряд, раз добавляют значит за это платят и это комуто нужно. Признаться у меня раньше тоже были такие подозрения (не к Oracle), думал мол большая контора, денег не считает и такие шалости себе позволить может, пока я не поучаствовал в разработке более-менее массового продукта, даже при нескольких десятках корпоративных пользователей начинается конкретный бардак с удовлетворением их уникальных требований, что уж тогда говорить про Oracle с их масштабами и позиционированием. То что он монстр - явление нормальное и закономерное, обусловленное массой предъявляемых требований, и Oracle их удовлетворяет, так что не надо тут "MySQL по сути своей гораздо красивее ораклятины", как я уже сказал - дело опыта, что лучше: бабочка или носорог ? Бабочка может конечно и красивее, до поры до времени, пока не залетит в болото и не будет случайно раздавлена. По поводу "языка Ада" - вполне себе нормальный язык, разве что почти сильнотипизированный и строгий, что конечно после какого нибудь Perl6 раздражает, но ведь это выливается во внятные сообщения об ошибках и увеличение производительности, а это имхо для баз данных, где первична структура и огромные объемы данных - как раз ключевые требования. Так что тут тоже все логично. Ну не нравиться вам - не пользуйте, ваше право, мне например нравится. По поводу "Меняешь кодировку - работает в 10 раз медленнее" - означает что Меняешь кодировку на другую - работает в 10 раз быстрее ;). Это какраз плюс, потому как очевидно что затраты на обработку разного рода кодировок различны, Oracle позволяет выжать из этого пользу, а вот у тех у кого разницы нет, очевидно чтото жестко затуплено. Хотя если честно, особо с кодировками не шаманю и с таким не сталкивался (не замечал), как собственно говоря и с Java - по этому поводу ничего сказать не могу. Конфиг, ну может и не идеальный, честно говоря тоже не замечал, опять похоже придираетесь, но даже если и так - то мелочи.
спустя 4 месяца 19 дней [обр] Amnesyac[досье]
Здесь эта тема довольно глубоко обсасана и можно таки сделать четки вывод что использовать. http://madjack.ru/developer/2009/08/mysql-vs-postgresql.html
спустя 23 часа [обр] Дмитрий Кучкин(7/236)[досье]
Почему-то в статье не указан английский первоисточник http://www.wikivs.com/wiki/MySQL_vs_PostgreSQL
Powered by POEM™ Engine Copyright © 2002-2005