Сравнение PostgreSQL vs MySQL

Вобщем первенство по производительности вовсе не за MySQL как все думали ;)

>...голландское сообщество сетевых "твикеров"*...

ооо

Слон затоптал моську...

красиво. я знал что не ошибся. ИМХО это потому что MySQL всегда больше на производительность упирал, а последнее время они наконец занялись безопасностью данных и языков программирования. Вот и результат. К тому же постгрез изначально делался в научной среде.

Мдаа, без флейма не обойдется, точно.

Нравится Postgres но пока всё на MySQL

А почему для MySQL наблюдается отрицательная производная? Я понимаю почему возникает полка (мне так кажется), но почему число выполняемых запросов в секунду уменьшается?

MySQL это бд для пыхпыха больше, а мужики то и не знали :-))

PostgreSQL наше фсио :-)

Надо полагать потому, что на исполнение каждого запроса требуется выделить память и вообще.

горизонтальная прямая - это количество одновременных потоков запросов. А вертикальная - количество ответов.

Соответственно, "до" полочки ситуация у MySQL и Postgres схожая: _ВСЕ_ запросы, которые им успели дать в < 7 потоков были обработаны.

А вот потом началась запарка: чем больше запросов/сек, тем больше памяти требуется, тем больше требуется работы процессора (и еще больше - нагрузка на контроллер ОЗУ и саму ОЗУ) - выборка из памяти нужной информации. Постгрес с этим справился, а мускуль - нет.

> Постгрес с этим справился, а мускуль - нет.

Ну дык и была бы полочка - почему провалы? Почему Niagara так отваливается?

>красиво. я знал что не ошибся. ИМХО это потому что MySQL всегда больше на производительность упирал, а последнее время они наконец занялись безопасностью данных и языков программирования. Вот и результат. К тому же постгрез изначально делался в научной среде.

Дык и MySQL 4.х тоже медленнее по ходу... ;)

мне кажется из-за алгоритма работы конвееров и кеша второго уровня.
но это чисто на ощущениях. я потроха камней не знаю.

ну если постгрес выдает хорошие результаты у "них" это хорошо...

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

Какой постгрес? версия? в тесте 8.2

Такой показатель только на разогнаных машинах сделал только что тест и все с точностью нааборт. MySQL намного опередил PostgreSQL.

>в реале же (у нас) постоянные тормоза, перешли на мускул. и у нас мускул порвал постгрес как тузик грелку.. и памяти меньше жрал и работал быстрее...

Вася Пупкин и ко неасилили настройку? Слишком голословно, тем более из уст анонимуса.

Шо, опять? (с)

>Такой показатель только на разогнаных машинах сделал только что тест и все с точностью нааборт. MySQL намного опередил PostgreSQL.

Дайте угадаю: настройки PostgreSQL были по умолчанию?

так чего, сервера-то купили ?

Версии почему-то старые... зачем тестить 4.1.20, когда 4.1.21 - стэйбл! зачем тестить 5.0.20а, когда 5.0.26 - стэйбл! и уж тем более если они брали Девел-пакеты, то почему не взяли 5.1.12-beta или 5.1.11???

>Вася Пупкин и ко неасилили настройку? Слишком голословно, тем более из уст анонимуса.

Для очередного Васи Пупкина киньте ссылкой на мануал по тюнингу производительности PostgreSQL (если в стандартной документации -- то не кидайте) :) Заранее благодарен

>Такой показатель только на разогнаных машинах

Гы, сынок, лол (с)

А какая разница, кроме частоты девайсов? Или у мускула всё плохо с масштабируемостью?

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

Например, если (ЕСЛИ, я не знаю как сделано в MySQL на самом деле) при апдейте/вставке записи в таблице лочится вся таблица (или индекс), все остальные запросы ждут завершения апдейта/вставки. В постгресе это точно не так.

Постгрес почти линейно масштабируется до 16 процессоров.

судя по графикам или вакум у постгреса ни вызывался ни разу, или он теперь работает за 0 сек..

Что-то я не нашел по ссылке параметров sql-серверов, а также как минимум типов таблиц MySQL. Вероятнее всего, неоптимально настроены сервер MySQL. Например, в случае таблиц MyISAM мы получим как раз такую деградацию с увеличением числа модифицирующих запросов. При использовании InnoDB нужно смотреть на конфигурацию этого backend-а, потому что при неправильных конфигурациях мы можем получить очень плохие результаты.

www.mysql.com >> MySQL AB :: The world's most popular open source database

www.postgresql.org >> PostgreSQL: The world's most advanced open source database

Это разработчики "о себе".

>Ну дык и была бы полочка - почему провалы? Почему Niagara так отваливается?

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

>Что-то я не нашел по ссылке параметров sql-серверов, а также как минимум типов таблиц MySQL.

поддерживаю..

> перешли на мускул. и у нас мускул порвал постгрес

Правильно. Графики *читать* надо!!! А не только верхние линии смотреть.

Из этих же тестов следует - если у вас одно ядро на весь сервер, мускул реально вырывается.

Если у вас два ядра, то при очень тяжелой нагрузке постгресс выйдет вперед.

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

Все правильно, для своей нагрузки своя БД.

> Все правильно, для своей нагрузки своя БД.

И в продолжении.

Там внизу ссылочки есть на предыдущие тестирования. Зашел я на тестирование Т2000 - сановского сервера на ультраспарках.

http://tweakers.net/reviews/649

И совершенно случайно бросился в глаза последний абзац на http://tweakers.net/reviews/649/7 :

It took a lot of trouble to make our benchmark suitable for PostgreSQL: Tweakers.net&#8217;s regular code is highly optimized to satisfy the 'unique personality' of MySQL 4.0. A direct copy of the database and the queries lead to hopelessly bad results, so in order to give PostgreSQL a fair chance, indices were replaced, sub queries were applied, and particular joins were rewritten. This re-optimization yielded an improvement by a factor of four. Still, the effort was far short of the work done over the years to get MySQL to behave properly, which makes us suspect that more performance can be dragged out of PostgreSQL.

Попытаюсь выделить суть: База, написанная с учетом особенностей мускула, будет жутко тормозить на постгресе. Чтобы постгрес летал, нужно включить соображалку, построить нормальные индексы, переписать запросы, в общем немного больше думать, чем с мускулом.

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

И я все равно уважаю мускул.

а я на sqlite и мне все до .....

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

> Из этих же тестов следует - если у вас одно ядро на весь сервер, мускул реально вырывается.

>Если у вас два ядра, то при очень тяжелой нагрузке постгресс выйдет вперед.

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

Следуя ваше логике получается, что все эти ядра нафиг не нужны, зря их делают... нужно ставить однопроцессорный сервер (с одноядерным cpu) и тогда mysql будет лучший, а добавишь ядер добавишь тормозов, выходит не нужно покупать многопроцессорный сервер - только деньги тратить, т.к. postgress везде одинаково работает, а mysql только на одном ядре...

IMHO, вроде, не вредные советы:

http://www.varlena.com/GeneralBits/Tidbits/perf.html

http://revsys.com/writings/postgresql-performance.html

Все ити пиписькомеря для конкретного меня бессмыслены. Если у меня есть Мускуль, но нет Постгреса, я буду использовать Мускуль, и наоборот. Если есть оба, и мне не пох. и не влом поставлю оба, сам сравню и выберу.

ЗЫ. У меня только Мускуль, аднинить СЕЙЧАС я умею только его. Угадайте, что я использую?

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

То есть это следствие версионности?

> Угадайте, что я использую?

Читаешь книгу: Введение в PostgreSQL? ;)

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

>И я все равно уважаю мускул.

а я не могу уважать СУБД у которой нет транзакций и процедурного языка. И кривое упраление пользователями.

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

>а я не могу уважать СУБД у которой нет транзакций - есть.. >и процедурного языка. - зачем? логику в базе писать? а хп есть... >И кривое упраление пользователями. - кому что надо...

низачОт...

а как можно уважать СУБД которая стопорит сервер на время вакума?

Исходя из данных условий, кто бы сомневался.. ;-)

>а я не могу уважать СУБД у которой нет транзакций - есть..

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

>И кривое упраление пользователями. - кому что надо...

низачОт...

а как можно уважать СУБД которая стопорит сервер на время ваккума?

А как можно уважать анонимуса, который только теперь из танка выглянул?

Похоже, изобретена машина времени.

Покури документацию, очнись и спой - в какой версии постгреса вакуум стал не блокирующим. Да, вакуум full блокирующий - но почитай и потестируй, нужно ли его гонять? даже периодически

> То есть это следствие версионности?

Наоборот: много блокировок - это следствие неверсионности. В MySQL есть транзакционные таблицы, а есть и нетранзакционные. Какие использовались в тесте, не написано.

небольшой оффтоп - а никто не сравнивал SQLite 3 и MySQL 4.1 на _простых_ запросах (SELECT из одной табл, UPDATE туда же - и так мого раз в секунду) - что из этого будет по быстродействию лучше?
А то есть задачка, мучаюсь с выбором. постгрес по ряду причин не пододит.

иди читай про mysql5. а то я с год юзаю транзакции и процедурки пишу под него, а тут оказалось что он их не поддерживает.

>А то есть задачка, мучаюсь с выбором. постгрес по ряду причин не пододит.

на сайте скулита есть все тесты. мучаться там надо

>Постгрес почти линейно масштабируется до 16 процессоров.

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

курите ссылку до посинения, потом делайте выводы: http://bugs.mysql.com/bug.php?id=15815

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