PostgreSQL vs MySQL

[Agronom]

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

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[dikens3]

Бытует мнение, что mysql быстрее, более документирован.
postgresql больше возможностей имеет(или имел в свою время).

[Agronom]

кто-нить сравнивал реальную работу сайтов на этих БД?

[dikens3]

Да там как сделаешь.(по задачам) Rambler вроде на postgresql. Тебе нравится?

[serge]

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

[voider]

когда в базе будет у вас 10милионов записей)))) мускул будет тормозить ,а постгри работает

[Alex Keda]

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

[zg]

но на чем лучше их строить?

на PDO

[hizel]

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

[zg]

а мускул больше на простые селект\инсерт

я бы так не сказал http://solutions.mysql.com/partners/services/ на простых "инсерт селект" таких партнёров не сделать

[hizel]

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

[zg]

причем здесь партнеры

MySQL поддерживает транзакции, откаты, хранимые процедуры, таблицы больше 4Гб, кластеры, таблицы на все случаи жизни, множественные запросы и, думаю, много чего ещё чем простые смертные не пользуются.... сертифицирование MySQL состоит их нескольких уровней, при чём как для программистов, так и для администраторов.

MySQL - это не просто инсерт/селект

[alex3]

я на вас балдю.... холивары из ничего... надо выпустить пар - есть спортзал... Или Лёхин Москвич
С наступающим!

[serge]

С наступающим адназначна

[Alex Keda]

я на вас балдю.... холивары из ничего... надо выпустить пар - есть спортзал... Или Лёхин Москвич
С наступающим!

а ведь бегает до сих пор.
Надо тока генератор сменить - хреновенько генерить стал - но, ещё пашет.

[hizel]

причем здесь партнеры

MySQL поддерживает транзакции, откаты, хранимые процедуры, таблицы больше 4Гб, кластеры, таблицы на все случаи жизни, множественные запросы и, думаю, много чего ещё чем простые смертные не пользуются.... сертифицирование MySQL состоит их нескольких уровней, при чём как для программистов, так и для администраторов.

MySQL - это не просто инсерт/селект

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

[paranoidchaos]

однозначно муся быстрее но когда база разрастается реально то постгри незаменим

самый большой минус в постгрии по сравнения с мусей это правовая политика . Очень нехорошо сделанно в мусе куда легче

а что болше всего понравилось - это тип данных массив )) и написания своих функций даже на пхп ))))

[voider]

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

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

тогда уж лучше на Оракл переходить

ничем не деляться столь охотна как своими заблуждениями...

[Alex Keda]

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

[voider]

да мы все походу заблуждаемся ,всё относительно

[zg]

однозначно муся быстрее но когда база разрастается реально то постгри незаменим

приведу простой пример: был биллинг (написан на Perl), жил работал, а когда у него база (MySQL MyISAM) разрасталась больше двух гигов, то падал. Обсчёт статистики занимал 40 минут. Когда я написал новый биллинг (на PHP), база стала занимать ~120 метров, обсчёт статистики стал занимать меньше минуты, падений не наблюдалось. Проблема большой базы была решена качественно, а не количественно. Я могу упихать всю статистику и в 30-40 метров без потери производительности, а обсчёт логов в десять секунд. С базой 30-40 метров справится даже dbase, чё уж говорить о MySQL и постгрес.

Я плохо представляю как сайты могут "реально разрасти" базу.. для меня реальный размер базы это порядка нескольких миллионов записей в одной таблице и общий размер базы порядка гигобайта, и то муся справится, да думаю и постгрес тоже, если правильно базу спланировать. Но чё-то не встречал я таких баз в вебе.

[Alex Keda]

траффик я считал - у меня несколько миллионов было.
нормально работало

[paranoidchaos]

)))) куда миллионы
блин базу в 19 гигов муся выдержит ?

ну и само собой так играет роль оптимизации биллинговой системы

[Alex Keda]

что значит "выдержит"?
У меня dbmail c такой жил.
гигов под 30 она была, когда я последний раз на тот сервер ходил.
работал.

[zg]

блин базу в 19 гигов муся выдержит ?

InnoDB и больше выдержит, но 19 гигов лишку для простых таблиц... могут проблемы быть при проверке целостности таблиц, если к примеру сервак ребутнётся не вовремя