MySQL vs PostgreSQL на примере Liferay

Еще одно сравнение (что-то потянуло меня на них).
Некоторое последнее время пришлось плотно заниматься нагрузочным тестированием одного из проектов. Там у нас используется Liferay 6.1.0 CE и база данных MySQL 5.5
Так вот - в ходе тестирования под нагрузкой обратили внимание - что в какой-то момент времени распределение процессорного времени начинается не в пользу Liferay: мускул начинает отъедать 300% - оставляя Liferay только 100%.

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

Более детальный разбор полетов позволил выяснить - что виноват во всем  Asset Publisher (Публиктор по русски) - а вернее те запросы к таблице  AssetEntry & co которые он генерит. Иногда запрос "вставал" на 15 секунд(!!!) - при том что записей у нас там примерно 25k

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

Честно пробовали тюнить  mySQL -  конфигурировать кеши, буфера и пр. Не помогло. Ну и , я конечно понимаю тюнинг базы данных когда  счет кол-ва записей идет на миллионы, но не десятках тысяч же!

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

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

Итак, в какой-то момент мы все-таки нашли время и провели эксперимент: запустили две одинаковые машинки на амазоне, поставили там один и тот же Liferay (со всеми портлетами и данными), на одном копию базы на  MySQL, на другом сделали миграцию данных на  PostgreSQL ( кстати, миграция данных средствами  Liferay  прошла на ура)

И стали смотреть.  MySQL работал как и ожидалось, а вот PostgreSQL  удивил.... дикими тормозами. То есть - главная страница могла открываться минуту!

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

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

Что делать?

После некоторых изысканий была найдена следующая бага: http://issues.liferay.com/browse/LPS-28364 - как раз про наш случай -  Asset Publisher на Liferay 6.1.0

После бекпорта фикса с 6.1.1 на 6.1.0, и исправления баги http://issues.liferay.com/browse/LPS-31539 (она же Asset Publisher can't handle the multilevel categories - кто использует 6.1.1 - обратите внимание - она там по прежнему есть) PostgreSQL полегчало несколько - страница стала открываться быстрее (заметно) - но общая скорость работы все равно далека от MySQL

И какие из этого следуют выводы?

По большому счету никаких. Нельзя сказать что MySQL быстрее чем  PostgreSQL только на данном специфическом примере. И нельзя сказать что Liferay быстрее на  MySQL  чем на PostgreSQL.

И понятно что любую базу можно оттюнить так - что она начнет работать значительно быстрее (хотя опять-таки, 25k записей - не та база которую надо тюнить)

И в вашем случае вполне возможно Asset Publsiher-ы вообще не используются, и вам проблема с их производительностью неважна. Или у вас такое железо, на котором  PostgreSQL просто летает.

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