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

"объяснить почему ?" ну так что? будете объяснять?

>это же насколько кривыми должны быть руки у пректировщика БД, чтобы >держать в одной базе 10k сущностей ?

>про 1k коннектов скромно умолчим. потому что руки у тех, кто проектировал >приложения, даже ещё более кривые, чем у предыдущего "проектанта".

Во-первых, читай mysql perfomance blog зачем нужно много таблиц, во-вторых ты забыл про хостинг. На хостинге очень много соединений бывает.

> Ага, т.е. mysql - это не современная СУБД? :)

Это современная, но не СУБД :))))))

>Я бы завершил все это фразой, что цианистый калий однозначно лучше всего поможет проектировщику этой базы.

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

PostgreSQL использует shared mem, по дефолту в линуксе стоит 32мб - т.е постгресу можно отдать не более 30мб на кеш. Отсюда и зажатый дефолтный конфиг.

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

УжЭ-таки смешно!

А вот ежели кит будет драться со слоном*, кто победит?

----- ЗЫ. *слон - это просто слон, а не тотемный маскот постгресса.

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

СУБД оценивают по совокупности десятков критериев и их комбинаций в применении к заданному типу задач и скорость там совсем не определяющий критерий...могут простить медлительность (ежели она не выходит за рамки приличий) если все остальное в шоколаде НА КОНКРЕТНОЙ ЗАДАЧЕ для КОНКРЕТНОЙ ПЛАТФОРМЫ!

СУБД - опора подавляющего большинства информационных систем, а от опоры требуется надежность...надежность и еще раз надежность! ИМХО PG - на порядок надежней мыскля...честно говоря я мыскля до самого недавнего времени с понятием СУБД лично для себя не ассоциировал...движок для таблиц, шустрый, но авантюный, глупый, ненадежный...непредсказуемый...для LAMP в вебе еще может и покатит, а для буизнеса - спаси Господь! не нада!

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

А вот я при всей моей антипатии к мысклю...скачал на пробу их MaxDB (ака SAP DB - вполне взрослая СУБД)...а чем лукавый не шутит? вдруг понравится...

Как в том анекдоте: -Гиви, ты памидори любишь? -Есть лублю...а так - нет!

надо же, сколько тараканов в голове

Кнкретнее, пожалуйста

Слишком бльшой флейм и слишком много аргументов, вы мне лучше честно скажите (приму на веру):

Таки у кого все же пиписька длиннее???

как минимум потому, что tsearch2 реализует "честный" fulltext index, работающий со словами на любом языке, был бы словарь. следствием чего является некоторая сложность настройки (подключение словарей и.т.п.).

> Таки у кого все же пиписька длиннее???

У тебя.

У мускула толще.

А у постгреса ерекция дольше держится.

Что нужно, то и выбирайте.

+1

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

>У мускула толще.

Извините, но у слона то уж точно толще должен быть ;)

>А у постгреса ерекция дольше держится.

> мыскля ... движок для таблиц ... непредсказуемый

Это точно. Недавно выполнил ANALYZE TABLE для одной большой таблицы в MySQL (InnoDB), т.к. индекс для одного запроса выбирался не совсем оптимальным образом. Что произошло? "Мама, роди меня обратно": индексы для почти всех запросов стали выбираться от балды; пришлось в срочном порядке прописать почти во всех запросах на выборку явное указание используемых индексов.

> индексы для почти всех запросов стали выбираться от балды

детские болезни. лечатся через багзиллу.

> детские болезни. лечатся через багзиллу.

Это не баг, а фича: ANALYZE TABLE для InnoDB анализирует не всю таблицу, а случайную выборку из неё. Может у меня данные были такими особенными, но, видимо, эта случайная выборка всё время была нерепрезентативной. Как вернуться в предыдущее состояние (до ANALYZE TABLE), я не знаю.

А баги в багзилле, если они не очень критичные, исправляются очень неспешно.

> как по тексчтовому полю в InnoDB таблице построить FULLTEXT индекс?

У разработчиков InnoDB были планы реализовать полнотекстовый индекс сначала к январю 2006, потом к апрелю, а сейчас уж и не знаю, какие планы. :)

> У разработчиков InnoDB были планы реализовать полнотекстовый индекс сначала к январю 2006, потом к апрелю, а сейчас уж и не знаю, какие планы. :)

реализовать когда-нибудь :)

"как минимум потому, что tsearch2 реализует "честный" fulltext index, работающий со словами на любом языке, был бы словарь. следствием чего является некоторая сложность настройки (подключение словарей и.т.п.)."

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

> у меня в мускуле на всех языках все ок индексирует.

да ну ? и stop words для всех языков учитывает ? не делайте мне смешно (с).

> а чо там и как работает меня мало волнует.

вы разработчик ? обычно их "мало волнует" как и что работает.

> Так что с БД с довольно оптимальной производительностью можно начать работать сразу после запуска.

А лучше еще до запуска. Типа, получается еще более "довольно оптимально".

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

Уже умеет, уже написали ведь.

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

Ну давай. Где пример?

> это же насколько кривыми должны быть руки у пректировщика БД, чтобы держать в одной базе 10k сущностей ?

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

> А вот ежели кит будет драться со слоном*, кто победит?

> ----- ЗЫ. *слон - это просто слон, а не тотемный маскот постгресса.

Ну, тогда кит тоже не имеет никакого отношения к мускулу? ;-)

Я никогда не понимал почему "бизнесы которые стоят милиард" используют mysql ???? Вот прмеры на вскидку: http://www.niallkennedy.com/blog/uploads/flickr_php.pdf http://www.danga.com/words/2005_mysqlcon/mysql-slides-2005.pdf

Что-нибудь подобное для постгресса плиз в студию. А то какие-то бессмысленные утверждения лубителей постгреса. Конкретику и ссылки хотелось бы видеть.

Можно глянуть на www.postgresql.org Case Studies

Вот, например, здесь: http://www.sai.msu.su/~megera/postgres/talks/what_is_postgresql.html

Олег Бартунов пишет:

Где используется

Если изначально POSTGRES использовался в основном в академических проектах для исследования алгоритмов баз данных, в университетах как отличная база для обучения, то сейчас PostgreSQL применяется практически повсеместно. Например, зоны .org, .info полностью обслуживаются PostgreSQL, известны многотерабайтные хранилища астрономических данных, Lycos, BASF. Из российских проектов, использующих PostgreSQL, наиболее известными является портал Рамблер, в разработке которого я принимал участие в 2000-2002 годах, федеральные порталы Минобразования.

>Ну давай. Где пример?

alter table v neblokirujus4ej transakcii mysql mojet sdelat?

Прошу обратить внимания: все адепты MySQL горячечно доказывая широкую распространенность этой СУБД указывают примеры: малоизменяемые живые журналы, хранилища эккаунтов, биллинговые системы (пишу-пишу-пишу ...читаю...пишу-пишу-пишу)...короче...от одного словосочетания СЕРВЕРНАЯ БИЗНЕС ЛОГИКА мускул "немеет"

Не понимаю что-такое "серверная бизнес логика", особенно прменительно к MySQL/Postgre. Можно подробнее, где читать?

>Вот, например, здесь: http://www.sai.msu.su/~megera/postgres/talks/what_is_postgresql.html

и здесь:

http://en.wikipedia.org/wiki/Comparison_of_relational_database_management_sys...

есть сравнение баз данных - сравнивать можно только PostgreSQL и Oracle, другие просто в равнение не идут, даже MS SQL (как я и думал, в принципе), по функционалу.

А тебе функционал mysql не устраивает? Я читал описание оракла и постргреса(имхо постгресу до оракла как до луны), но у меня ни разу не возникло желания на них перейти ибо смысла нет. И не надо тут убеждать что фичастость самый важный критерий в СУБД, в подавляющем большинстве случаев этор не так. А если у тебя сервер "уровня предприятия" то ты и без ЛОРа знаешь что там должно стоять и что там стоять не должно(по крайней мере должен знать).

> Ну давай. Где пример?

Из жизни. Алгоритм действий следующий:

начали транзакцию
изменили структуру таблицы (добывили/удалили колонки)
создали триггер
подвесили его на таблицу
погоняли тестовые запросы, посмотрели на результаты. Не понравилось
откатились на исходное состояние rollback-ом

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

Блин ну почему Firebird2 ни с чем не сравнивают ? ... мож умники с ibase.ru пояснят ? ... хотя на вскидку приходит идея о том что Fb2 всех порвёт по маштабирумости, производительности и надёжности ... или FB2 используют только "под конкретную задачу" ? ... )))

> Блин ну почему Firebird2 ни с чем не сравнивают ? ... мож умники с ibase.ru пояснят ? ... хотя на вскидку приходит идея о том что Fb2 всех порвёт по маштабирумости, производительности и надёжности ... или FB2 используют только "под конкретную задачу" ? ... )))

Ну не знаю. По скорости может быть. Если индексы для запроса удачно выберет. Но сильно сомневаюсь на счёт масштабируемости. По крайней мере ни разу не слышал о потугах запускать его (firebird в целом) на многопроцессорных машинах.

Кроме того, Firebird имел серьезные недоработки в SQL (в сравнении с PostgreSQL).

Пробовал я Firebird 1.5, когда выбирал базу для билла на работе. На простых запросах он рвал PostgreSQL. Но чуть шли запросы по сложнее, у птички начинались глюки с индексами. Кроме того, SQL у постгресса был богаче, и написание процедур понятнее.

Ну теперь можно меня клевать

>Блин ну почему Firebird2 ни с чем не сравнивают ?

потому, что ФБ2 - полный сакс даже в сравнении с mysql4. в ФБ нет лога транзакций, хрень называемая "невостановимый бэкап", кривой sql (bug cursor stability), нет нормального супорта smp и прочая, прочая ...

давным давно перешли на постгрес и никаких проблем )

> давным давно перешли на постгрес и никаких проблем )

Я с ним изначально работал и был доволен :) Вот уже год пытаюсь привыкнуть к мускулу... :-E

Да это давно известный факт ... FB сливает Постгрессу по всем параметрам ... сам ставил тесты ... хотя по версии фанатов FB ... в нем нет никаких проблем ...

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

По ссылочкам походи. Там есть более ранние тесты, где есть ответы на вопросы: какие тесты они проводили и что хотели получить от них.

Тестировали железо. Тестировали на своей базе (я понял, что это база их сайта). Старались выжать максимум. Вовсе не желали показать крутость PostgreSQL.

И не забывайте: на однопроцессорной машине MySQL делает PostgreSQL в полтора раза - поэтому все коментарии о предвзятости и криворукости твикеров отметаются как не состоятельные (лично мною).

>Теперь хотелось бы видеть алгоритм для того же самого в мускуле.

mysqldump? Таки да, таких фич он не держит. А если оракел взять, то постгрес в трубочку свернется. Однако, подчеркну еще раз, для большинства задач такое не нужно. Зато часто все упиралось в SQL как таковой, либо было неудобно на нем описывать. Об альтернативах слышал, но не юзал(кто-нить пробовал bdb+xerces+pathan?).

И вообще, смотрите вот эти бенчмарки: http://www.sqlite.org/speed.html :)

> начали транзакцию > изменили структуру таблицы (добывили/удалили колонки) > создали триггер > подвесили его на таблицу > погоняли тестовые запросы, посмотрели на результаты. Не понравилось > откатились на исходное состояние rollback-ом

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