Postgres vs Mysql - есть ли свежие тесты?

Krishna

Продался Java
Postgres vs Mysql - есть ли свежие тесты?

Чего-то не могу найти свежих сравнений Postgres с MySQL.
Не знаю, как Postgres, а MySQL проделал большой путь за последние пару лет, особенно в свете приближающегося 5.1

Неужели их больше не сравнивают? Всё, что я нашел - сравнение с 5.0.4 (бета пятерки)

Не то, чтобы флейм, просто хочется быть в курсе дела ;)
 

Alexandre

PHPПенсионер
В Постгресе есть tablespace - можешь раскидывать таблицы по разным дискам, в Мускуле - нет
В Постгресе есть полноценная XML обработка, в мускуле - только две XML-ные функции.

В Мускуле - и процедуры и триггеры были, еще во времена третьей версии, только они были в коммерческих версиях (информация на основе анализа документации мускуля времен 3.23).

С Выходом в некоммерческое пользование Фиреберда и Постгреса, Мускулю просто уже деваться некуда, и они сделали доступной некоторые части своей коммерческой версии... Конкуренция - дело хорошее.

На счет сравнивания производительности - long давал мне ссылку, Мускуль чуточку выиигрывает на предкомпилированных запросах, постгрес чуточку обгоняет на простых... Тесты ,были сделаны в прошлом году.
 

Krishna

Продался Java
Alexandre
Я хотел бы увидеть более детальное и полное сравнение, хотя, разумеется, можно и попробовать составить его в этом топике самостоятельно.

Могу добавить от себя следующее:

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

В мускуле существует возможность подключения нескольких storage engine, в зависимости от решаемой задачи, в постгрес - нет.


--

А как обстоят дела со сравнением возможностей масштабирования? Репликация, кластеризация?
Работа с большими таблицами (partitioning)?
Где доступно больше типов индексов?
 

MiksIr

miksir@home:~$
По производительности, попадались тесты не так давно. Общий смысл - мускуль делает на однопроцессорных машинах и средней конкуренси, постгрес основательно вырывается вперед при маштабировании по процессорам и при высоких конкуренси. Сссылки, кажись, проскакивали в ru_highload

-~{}~ 25.09.07 20:14:

По репликации на сегодня - у мускуля слейв-мастер встроенный, у постгреса - "слони". У них немного разные методы репликации, что лучше или хуже не знаю. Мультимастера нормального нет ни у кого - у мускуля готовится их мм кластер (сырой и таблица должна помещаться в память), у постгреса есть pgpool-2 и pgcluster - обе сырые, но после напильника рабочие (точно знаю, испоьзуют pgcluster).. правда, были нарицания под нагрузкой.

-~{}~ 25.09.07 20:17:

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

Еще в постгресе есть наследование таблиц... имхо, очень перспективная штука.. тоже не юзал, но очень чешутся руки куда-нибудь применить ;)
 

Alexandre

PHPПенсионер
Я хотел бы увидеть более детальное и полное сравнение
....
На счет сравнивания производительности - long давал мне ссылку
я попрошу Лонга, чтоб он озвучил ссылку
 

MiksIr

miksir@home:~$
Да, слышал что они готовили это, а долгое время не следил за мускулем. Интересно было бы послушать, как это работает, но по-любому, пока 5.1 не выйдет из беты...
 

Sad Spirit

мизантроп (Старожил PHPClub)
Команда форума
Автор оригинала: Krishna
Чего-то не могу найти свежих сравнений Postgres с MySQL.
Не знаю, как Postgres, а MySQL проделал большой путь за последние пару лет, особенно в свете приближающегося 5.1

Неужели их больше не сравнивают? Всё, что я нашел - сравнение с 5.0.4 (бета пятерки)

Не то, чтобы флейм, просто хочется быть в курсе дела ;)
Вот документ с сайта Postgres'а на эту тему, естественно take with a grain of salt.

Кроме того, сравнивать Postgres с абстрактным сферическим MySQL в вакууме не корректно: вроде как и Postgres поддерживает транзакции и полнотекстовый поиск, и MySQL поддерживает транзакции и полнотекстовый поиск. Но последний их не поддерживает одновременно.

storage engine --- волшебная в теории фича, "но есть нюанс" (с) анекдот. Если бы у нас были просто storage engines, оптимизированные под конкретную нагрузку, а так их поведение ничем бы не отличалось --- было бы супер. Но на самом деле их поведение отличается настолько, что разработчику придётся писать своё приложение по-разному для "MySQL + MyISAM" и для "MySQL + InnoDB". Кроме того, вот я слушал на highload'е разработчика Sphinx'а, интерфейс к которому реализован в MySQL как Yet Another Storage Engine. Смысла в этом особого нету, т.к. можно его реализовать просто через функции, возвращающие наборы записей, как в Postgres'е реализован тот же contrib/dblink.

Впрочем даже абстрактный сферический MySQL в вакууме до сих пор не поддерживает:
  • ограничений CHECK
  • индексов по выражениям
  • частичных индексов (CREATE INDEX ... WHERE ...)
Список можно дополнять, ага.

Кроме того Postgres значительно более расширяем: свои типы данных, свои типы индексов, свои агрегатные функции (я помнится на презентации года 3 назад показывал как можно в 3 строчки реализовать новый модный мысклёвый group_concat).

Не говоря уже о том, что вещи, которые в MySQL 5.1 только появились и весьма сыры, в Postgres'е работают уже много лет как.

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

svetasmirnova

маленький монстрик
Sad Spirit
>смогут класть таблицу на диск --- будет фичей.

Можно уже: см. ссылку выше.

MiksIr
5.1 уже RC, release будет в конце этого - начале следующего года.
 

MiksIr

miksir@home:~$
Угу, в потом еще после релиза будут вылавливать косяки. Особо в такой специфичной штуке, как мастер-мастер кластер... еще пол-годика минимум до продакшена, а то и годик.
 

Krishna

Продался Java
MiksIr
На встрече с московской группой юзеров MySQL Константин Осипов сказал, что основная масса багов в ветке 5.х уже исправлена и что он рекомендует тем, кто еще пользует 4.х переходить сразу на 5.1, по выходу релиза.
Вроде бы я его правильно понял.
Хотя, на крупные проекты, конечно, наверное не стоит ставить 5.1 прям сразу же после выхода. Но, с другой стороны, ведь проекты под 5.1 еще нужно разработать, а вот это уже как раз пора делать.

Sad Spirit

Я правильно понял, что по твоему MySQL не имеет никаких преимуществ перед Postgres? )
В таком случае, возникает вопрос - почему столь много крупнейших проектов рунета и не только используют MySQL, а не Postgres?
 

svetasmirnova

маленький монстрик
Krishna
Ну я могу отвечать только за то, что в 5.0 практически нет критических багов. Ну и все исправления в коде, который повторяется во всех ветках, push во все ветки за исключением тех, что limited support.

Но именно Cluster, который 5.1, многие компании успешно успользуют в production.

MiksIr
А что такое мастер-мастер кластер? Репликация имеется в виду? Мастер-мастер и circular репликация MySQL Cluster не поддерживается.
 

Krishna

Продался Java
svetasmirnova
[off]А ты не могла бы пояснить, как именно ты относишься к MySQL AB? Сотрудник, или просто продвинутый специалист по MySQL? Я не в курсе. 0:)[/off]
 

MiksIr

miksir@home:~$
Под мастер-мастер я подразумеваю синхронную мультимастер репликацию. Этого нет!?
 

Krishna

Продался Java
MiksIr
Есть репликация отдельных БД, а есть репликация кластеров БД. Ты спросил (и тебе ответили) про репликацию кластеров.
Разберись в вопросе сначала :)

-~{}~ 26.09.07 14:10:

svetasmirnova
Спасибо за инфо)

-~{}~ 26.09.07 14:12:

P.S. Тогда может быть тебя нужно спрашивать о преимуществах MySQL над Postgres? (если такие есть) :)
 

Krishna

Продался Java
MiksIr
То же самое, что и под обычной репликацией одиночных БД, только для целых кластеров.

-~{}~ 26.09.07 14:17:

З.Ы. Я не спец. в вопросе, так что меня стоит проверить документацией)
 

MiksIr

miksir@home:~$
Репликация кластера на другой кластер? Бррр... это тут причем?

-~{}~ 26.09.07 14:23:

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