Mysql vs Postges

Sad Spirit

мизантроп (Старожил PHPClub)
Команда форума
Автор оригинала: Димон
Про настройки согласен. А вот про запросы с реального приложения, нет. Да, тесты могут к реальности имеет немного отношения. Но, как я уже писал, это первичный тест. Чем не показатель простой select, insert, update? Если эти тесты хорошо проходят, то можно перейти к более сложным.
Следует ли из факта, что условная база A выполняет запрос 'select * from foo where foo_pkey = ?' в 3 раза быстрее, чем условная база B, тот факт, что условная база A выполнит запрос с JOIN'ом по 10 таблицам в 30 раз быстрее?..

А с какими, кстати, настройками гоняется pgpool? А то если выделить 5 backend'ов при 100 одновременных запросах, а при этом ещё и подключение в PDO явно не закрывать...
 

korchasa

LIMB infected
Автор оригинала: Димон
Чем не показатель простой select, insert, update?
Тем, что в реальности по отдельности не встречается.

Автор оригинала: Димон
Если эти тесты хорошо проходят, то можно перейти к более сложным.
Ну я и предлагаю перейти. Все равно эти ничего не дадут.

Сравни MyISAM с InnoDB на конкурентных select/insert/update :D
 

Димон

Новичок
Наконец-то руки дошли чтобы поставить точку в этой теме. В общем все верно, дело было в настройках pgpool. И так, выставили для postgres max_pool = 20 вместо родных 4. И получилось, при тех же условиях (запросов в секунду):

PHP:
MySQL (InnoDB)      Postgres
-------------------------------------
 559.03               276.12         - SELECT
 72.18                318.61         - UPDATE
Вывод: Выбрали Postgres, т.к. с транзакциями он работает в целом лучше. Более медленный SELECT с лихвой компенсируется существенно более быстрым UPDATE. И как, я говорил раньше, оракловый язык хранимок plpgsql - это очень существенный плюс в пользу выбора этой базы данных, т.к. ни у кого из нас нет ни малейшего желания возиться с трехэтажными запросами (кто не согласен создавайте отдельный топик и там спорьте до посинения). Из хорошего для MySQL, т.к. лично мне эта база очень нравится за дружественный интерфейс, отличную документацию с комментариями, множеством примеров и, в связи с этим, быстроту разарботки на ней: разработчики мускула обещали, что, начиная с версии 5.5 движок для таблиц по умолчанию будет InnoDB. Надеюсь, что это будет дорабтка движка, а не простое переключение опций.

P.S. Эти небольшое исследование раскрыло лишь малую часть потенциала двух выбранных баз данных и совершенно не претендует на место неоспоримого факта. Мы проводили сравнение в сугубо личных целях (в смысле под проект) и результаты могут совершенно не совпадать с мнениями участников и другими сравнениями.

Еще раз очень прошу не засорять тему всякой чушней. Если Вам объективно написать нечего, то, пожалуйста, ничего не пишите. Спасибо за понимание.
 

BigHarry

Новичок
Автор оригинала: Димон
дело было в настройках pgpool.
А настройки мыскля покрутить поленились? Тогда может и вывод был бы другой...

Автор оригинала: Димон
оракловый язык хранимок plpgsql - это очень существенный плюс в пользу выбора этой базы данных
Хм... Существенность плюса наверно объясняется наличием определенного опыта у программиста БД. Если бы был сишник - то пшп был бы забыт как страшный сон. Ну и скорей всего - оракловый язык будет в мыскле - по крайней мере - в перспективе :)

К сожалению - на большинстве хостинговых площадок крутить настройки сервера б/д - фантастика...
 

zerkms

TDD infected
Команда форума
Хранимки это очень хороший стиль. Можешь поинтересоваться у любого нормального разработчика баз данных. Да и вообще я уже давно отвык писать трехэтажные вложенные селекты. Очень тяжело их править, когда проходит месяца три или больше, да и еще если писал не сам.
а тело SP вы как в системах контроля храните?
 

akd

dive now, work later
Команда форума
zerkms, а в чем проблема? алтер процедуры храним просто полный.
 

akd

dive now, work later
Команда форума
со временем входит в привычку после каждого изменения -> generate script -> save to file ... commit :)
 

zerkms

TDD infected
Команда форума
akd
и после каждого апдейта - следить, не поменялось ли чего. и в случае изменений - открываем каждый изменённый файл (ведь SP лежат каждая в своём файле?), копируем, вставляем, запускаем.... ляпота, хыхы

-~{}~ 13.05.10 18:12:

Очень тяжело их править, когда проходит месяца три или больше, да и еще если писал не сам.
кстати интересный факт: если запрос написан не в коде, а в SP - его смысл проще понять. вот такая вот чудесная метаморфоза ))
 

akd

dive now, work later
Команда форума
zerkms, не, все немного не так :)
есть пара баз.
basic - пустая база нулевой версии.
master - база последней стабильной версии.

флоу.
а. разработчик новый без сырцов
1. чекаут
2. копирует master на свою машину и девелопит
3. после всех изменений - sql toolbelt - compare master <> его копия, и все изменения сохраняет в скрипт yyyymmddhhii.sql
4. коммит и проверка как ложится его скрипт на master.
5. sql toolbelt - compare master <> его копия - должно быть идентично (тут возможно что другой разработчик тоже коммитнул шота, нужно сверять глазами - у нас случалось не чаще раза в год)

b. разработчик с сырцами.
1. update
2. накатываем "новые" скрипты на свою дб
3. девелопмент ... и т.д.

+ есть свои тулзы для контроля и синхронизации дб .. все в один клик почти :)

при больших косяках которые кто-то накоммитил, мастер дропается, в него ресторится basic и накатываются все скрипты от версии 0 :)
 

zerkms

TDD infected
Команда форума
akd
да у всех так :)
вот только получается, что теперь SP даже не в отдельном файле, и все SP не в отдельных файлах, а в дампе.
и отследить что и когда было сломано/изменено становится ещё сложнее :)
 

akd

dive now, work later
Команда форума
zerkms, ну жизнь вообще штука сложная :)
 

weregod

unserializer
если не лень, можно на каждую SP отдельный файл завести, можно и автоматизировать выплёвывание в файлы
 

akd

dive now, work later
Команда форума
weregod, можно, но не нужно.
скорее это будет даже вредно, потому как накат версии должен проходить в транзакции, если все изменения версии в одном файле, то все очень просто.
 
Сверху