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

Krishna

Продался Java
Ты открыл мне глаза --- оказывается Котеров меня летом зазывал переводить МойКруг на MySQL! И сейчас они разработчика ищут не иначе как для того же!

В общем, я бы на твоём месте не очень в будущем доверял автору этой сплетни.
Источники достаточно надёжные, хоть и косвенные, просто было это, как я щас стал вспоминать, похоже не полгода, а полтора назад. Думаю, Котерова тогда там не было и вопрос о смене СУБД был более актуален.
речь о том, что если в конторе есть гуру, то смысла менять работающее решение нет, потому что гуру из него всё что можно выжмет. Вот если гуру в нужный момент нету, то может возникнуть ситуация как с feedlounge.
А я хочу сказать, что, специалист, способный решить 99% не обязан быть гуру мирового уровня. Такого специалиста можно вырастить внутри конторы.
Ну крупные конторы и с Postgres'ом решают проблемы самостоятельно, вот Sony решила деньги, которые раньше уходили на лицензии Oracle, отдать на доработку Postgres'а, чтобы он понимал Oracle'овый синтаксис (EnterpriseDB).
Вот, кстати, осознал еще одно преимущество MySQL - это наличие коммерческой конторы, способной в случае необходимости предоставить профессиональный суппорт, или выпустить патч под нужды клиента. Это ведь серьезный бонус для бизнеса. Мне кажется, что за подобной бизнес-моделью будущее.


Я, вообще не сразу заметил, что ты модератор Постгрес-раздела, это многое объясняет ;)

Поигрался с ним вчера немного. Ооочень порадовал EXPLAIN, особенно его отображение в EMS :) В мускуле он меня постоянно убивает своей кривой нечитабельностью.

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

Есть ли какие ER CASE средства для него?

-~{}~ 27.09.07 13:45:

А правильный переход с MySQL + MyISAM на MySQL + InnoDB может оказаться гораздо более сложным, чем с MySQL + InnoDB на PostgreSQL, просто потому что InnoDB и хранилище PostgreSQL значительно более похожи, нежели MyISAM и InnoDB.
Не знаю, что ты подразумеваешь под правильным переходом, но вообще это банальный ALTER TABLE. И в 90% никаких дополнительных телодвижений )

Что касается сравнений по фичам, если подойти к вопросу честно и делать не таблицу из двух колонок "MySQL, PostgreSQL", а из гораздо большего их количества "MySQL + MyISAM, MySQL + InnoDB, MySQL + Falcon, ..., PostgreSQL", то последняя колонка по фичам будет сильно лучше. Просто потому что в первом случае мы будем сравнивать абстрактный сферический MySQL в вакууме, который одновременно умеет транзакции, внешние ключи, полнотекстовый поиск и rtree индексы и реально данный нам в ощущениях PostgreSQL, который действительно одновременно умеет всё перечисленное.
А вот тут кукиш ) Дело в том, что MySQL позволяет использовать все эти storages в одной базе, в зависимости от предназначения конкретных таблиц :) И это громадный бонус, на самом деле.
Проблема, например несовместимости FT и InnoDB решается просто - созданием таблицы - копии MyISAM, содержимое которой дублируется из InnoDB триггерами.
Проблему поиска решает превосходно и более того, разгружает основную таблицу.
 

MiksIr

miksir@home:~$
> Вот, кстати, осознал еще одно преимущество MySQL - это наличие коммерческой конторы
Ну в России такая контора для Постгреса есть тепереча.

-~{}~ 27.09.07 14:19:

Автор оригинала: Krishna
Проблема, например несовместимости FT и InnoDB решается просто - созданием таблицы - копии MyISAM, содержимое которой дублируется из InnoDB триггерами.
Проблему поиска решает превосходно и более того, разгружает основную таблицу.
Ага, а в постгресе эта проблема просто напросто не решается ввиду отсутствия необходимости - полнотектовый поиск есть. А разгрузка баз делается одинаково - репликацией.
 

Krishna

Продался Java
Ну в России такая контора для Постгреса есть тепереча.
Што за контора?
Ага, а в постгресе эта проблема просто напросто не решается ввиду отсутствия необходимости - полнотектовый поиск есть.
Я ж не говорю, что это не косяк. Просто он не критичный.
 

Sad Spirit

мизантроп (Старожил PHPClub)
Команда форума
Автор оригинала: Krishna
Источники достаточно надёжные, хоть и косвенные, просто было это, как я щас стал вспоминать, похоже не полгода, а полтора назад. Думаю, Котерова тогда там не было и вопрос о смене СУБД был более актуален.
...а полтора года назад МоимКругом занимались товарищи, которые как раз щас и организовали консалтинговую / саппорт контору для PostgreSQL.

Вот, кстати, осознал еще одно преимущество MySQL - это наличие коммерческой конторы, способной в случае необходимости предоставить профессиональный суппорт, или выпустить патч под нужды клиента. Это ведь серьезный бонус для бизнеса. Мне кажется, что за подобной бизнес-моделью будущее.
Таких контор для PostgreSQL, вообще говоря, существует много. В этом преимущество перед MySQL, где всё замыкается на одну контору

Поигрался с ним вчера немного. Ооочень порадовал EXPLAIN, особенно его отображение в EMS :) В мускуле он меня постоянно убивает своей кривой нечитабельностью.
Дык, я вообще не понимаю, как люди умудряются EXPLAIN в MySQL использовать.

Однако, в продаже литературы, особенно свежей по Постгресу нет. Изучать по документации я не очень люблю)
Лучше изучать по документации, она очень и очень адекватна (её также можно распечатать из pdf'ок, гы-гы-гы). Если всё же нужна книжка, то ищи автора Korry Douglas (не уверен, издавалось ли на русском), но второе издание уже пару лет назад вышло, т.ч. там далеко не всё из современных фич описано.

Есть ли какие ER CASE средства для него?
Sybase Powerdesigner 12 понимает синтаксис PostgreSQL 8.x

Не знаю, что ты подразумеваешь под правильным переходом, но вообще это банальный ALTER TABLE. И в 90% никаких дополнительных телодвижений )
Ага, а подход к блокировкам, транзакциям и прочему в приложении оставить тот же самый?..

Проблема, например несовместимости FT и InnoDB решается просто - созданием таблицы - копии MyISAM, содержимое которой дублируется из InnoDB триггерами.
Проблему поиска решает превосходно и более того, разгружает основную таблицу.
Замечательная разгрузка, вместо одной копии данных у нас в кэше теперь будут жить две копии, друг друга оттуда выталкивая. Ну и выборка с join'ом против выборки из одной таблицы.
Не говоря уже об интересных эффектах с таблицей-копией, если вдруг неожиданно случится ROLLBACK.
 

Rin

*
>Замечательная разгрузка, вместо одной копии данных у нас в кэше теперь будут жить две копии, друг друга оттуда выталкивая. Ну и выборка с join'ом против выборки из одной таблицы.
Не говоря уже об интересных эффектах с таблицей-копией, если вдруг неожиданно случится ROLLBACK.

Грабли ужасные! :)

Вообще, Alexandre правильно мыслит:

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

Что нужно большинству мелких и средних WEB проектов: быстрая и простая БД, расчитанная на программиста с год опыта (посмотрите кто требуется на рынке труда?)... Мускуль - полностью отвечает этим требованиям. Знаю - многие проекты еще сидят на 3.23 и им - этих возможностей вполне достаточно. У мускуля - есть уже раскрученный годами бренд
Ладно, будем честны -- у MySQL на сегодняшний день еще много чего нет, что есть у PostgreSQL; репликации для InnoDB нормальной тоже нет. :(
Но MySQL AB движется в правильном направлении -- БД стремительно набирает функционал и становится все более удобной в использовании. Разработчики стараются соблюдать стандарты и вносят изменения довольно продуманно. У MySQL есть преимущество в том смысле, чтобы не повторить не слишком удачные решения PostgreSQL. Вобщем, разрыв между базами уменьшается.
А выбор в использовании БД зависит от задач, которые предстоит решить.
 

Sad Spirit

мизантроп (Старожил PHPClub)
Команда форума
Автор оригинала: Rin
Вообще, Alexandre правильно мыслит:
Правильно, только не надо валить всё в одну кучу. Если проект живёт на MySQL 3.23 и поддерживается арехтипичными веб-программистами с годом опыта (ну и при этом проблем в его эксплуатации нету), то пусть себе и живёт, пока тихо не скончается.

Другой вопрос, если мы выбираем СУБД под новый проект и разработчики у нас чуть-чуть поадекватнее. При этом аргументация "всего через 2 года MySQL догонит по фичам нынешний Postgres" несколько странно звучит: разработчики Postgres'а в общем тоже на месте не сидят, да и разработка поддерживается кучей крупных команий.

Но MySQL AB движется в правильном направлении -- БД стремительно набирает функционал и становится все более удобной в использовании. Разработчики стараются соблюдать стандарты и вносят изменения довольно продуманно.
Так зачем заниматься ловлей багов в "набираемом" функционале, если можно взять такой же, но стабильный? А про поддержку стандартов я уже выше писал, вот сделают неотключаемый strict mode и всё равно придётся все свои запросы с датами '0000-00-00' и group by без агрегатных функций переписывать.
 

Rin

*
'0000-00-00' -- это, видимо, досталось в наследство с тех времен, когда значения NULL в некоторых базах небыло (привет DBF?). Поэтому MySQL разрешала такие нелепые даты для более простого перевода данных с древних БД на MySQL.

>Какие например?
VACUUM в нагруженных системах (MyISAM не в счет), только транзакционные таблицы, более медленная работа команд INSERT, DELETE и UPDATE, чем аналогичные в MySQL.
Хотя 8-я версия PostgreSQL довольно хорошо продвинулась вперед.
 

Sad Spirit

мизантроп (Старожил PHPClub)
Команда форума
Автор оригинала: Rin
'0000-00-00' -- это, видимо, досталось в наследство с тех времен, когда значения NULL в некоторых базах небыло (привет DBF?). Поэтому MySQL разрешала такие нелепые даты для более простого перевода данных с древних БД на MySQL.
Ну то есть на утверждение "всё равно придётся запросы переписывать" возражений нет. Хорошо.


>Какие например?
VACUUM в нагруженных системах (MyISAM не в счет),
Ну вот как раз в версии 8.3 обещают добавить новую фичу, сильно снижающую потребность в VACUUM'е в нагруженных системах. Ну и, естественно, команда для сборки мусора и прочих дел в MySQL тоже есть, просто называется более пафосно: OPTIMIZE.

Вот кстати, а что случится с MySQL, если вдруг в нагруженной системе понадобится построить дополнительный индекс?

только транзакционные таблицы, более медленная работа команд INSERT, DELETE и UPDATE, чем аналогичные в MySQL.
Да-а-а? На любых таблицах, при любом количестве одновременных подключений? А в Дедушку Мороза ты тоже веришь?

Хотя 8-я версия PostgreSQL довольно хорошо продвинулась вперед.
8-я версия вышла уже почти 3 года назад. Мы тут пытаемся обсуждать несколько более современные версии...
 

Dagdamor

Новичок
Sad Spirit
Вот кстати, а что случится с MySQL, если вдруг в нагруженной системе понадобится построить дополнительный индекс?
Таблица будет временно заблокирована, будет построен индекс, после чего работа продолжится. По-моему, вполне ожидаемое поведение, нельзя же позволять другим запросам менять данные в таблице в тот момент, когда происходит построение индекса.
 

Sad Spirit

мизантроп (Старожил PHPClub)
Команда форума
Автор оригинала: Dagdamor
Таблица будет временно заблокирована, будет построен индекс, после чего работа продолжится. По-моему, вполне ожидаемое поведение, нельзя же позволять другим запросам менять данные в таблице в тот момент, когда происходит построение индекса.
А насколько временно таблица будет заблокирована? Вот на том же Slashdot'е перестройка неправильного индекса заняла несколько часов:
Fixing is a simple ALTER TABLE statement... but on a table that is 16 million rows long, our system will take 3+ hours to do it, during which time there can be no posting.
А вот в Postgres'е есть опция CREATE INDEX CONCURRENTLY:
When this option is used, PostgreSQL will build the index without taking any locks that prevent concurrent inserts, updates, or deletes on the table; whereas a standard index build locks out writes (but not reads) on the table until it's done.
 

Dagdamor

Новичок
Sad Spirit
Зачем все так опошлять :)
У каждой монеты есть 2 стороны, если Постгре умеет строить индекс, не блокируя таблицу, значит, за эту возможность приходится платить чем-то еще, а именно гораздо большим временем построения (минимум в 2 раза, судя по докам), и большей нагрузкой на базу все это время. Решений без недостатков не существует...
 

Rin

*
>Ну то есть на утверждение "всё равно придётся запросы переписывать" возражений нет. Хорошо.

Есть возражения. Толковые программисты сразу сделали "UPDATE t SET col_date = NULL WHERE col_date = '000-00-00'" и им ничего переписывать не пришлось.
 
Сверху