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

Типичное интервью когда сказать нечего А MySQL они уступают только в одном, но это главное: в лидерстве на этом рынке. А из лидерства уже следует, что в MySQL есть _больше_ из того, что нужно потребителям в данной нише

Не знаю как интервью - честно сказать, начал - но лениииво читать :-) но постгре мне бОльше нравится чем мускул :-) Наверное, потому, что по нему у меня книжки хорошие есть :-D

"MySQL used to be faster than PostgreSQL across the board, but we've erased that difference and now it's only faster in certain corner cases at lower load levels."

Дык начерта теперь MySQL нужна?

SadAlex.

> "MySQL used to be faster than PostgreSQL

А это стандартный их треп, который начался еще пару лет назад.
Есть такой комплекс неполноценности у любителей postgres.
Против фактов не попрешь, но выебываться не запрещено ;)
Только они слегка приблизились к скорости mysql на сложных
запросах, как в mysql-4.x появилось кеширование запросов, и
postgres опять отодвинулся по скорости далеко-далеко ;)

В кратце интервью выглядит так: немножко тормозит, немножко
более сложен в настройках, немножко отсутствует репликация,
кластеризация и лоадбалансинг, немножко нет порта на виндовс.
Зато в остальном, прекрасная маркиза, все зашибись ;)

>Только они слегка приблизились к скорости mysql на сложных запросах, хм и давно mysql научился делать сложные запросы? subquery только-только появились в альфа-версии

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

порт на виндовс кстати есть и даже работает Ж8-) кстати - не понимаю - что они заморочились нативным портом если есть цигвиновский? лучше бы репликацию сделали в 7,4 а форточный порт - через версию или вообще гденибудь в районе 9,0 Ж8-)

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

> триггера уже есть

Роль триггеров исполняет application server. И докажи, что это неправильно.

anonymous (*) (2003-04-24 05:56:56.839402): > А это стандартный их треп, который начался еще пару лет назад. Есть такой комплекс неполноценности у любителей postgres. Против фактов не попрешь, но выебываться не запрещено ;)

Что характерно, за эту пару лет не было опубликовано бенчмарков, которые бы доказывали превосходство MySQL, до этого же их дохрена было --- любили в MySQL AB это дело. ;] > Только они слегка приблизились к скорости mysql на сложных запросах,

Оооо! В MySQL появились сложные запросы?!

> как в mysql-4.x появилось кеширование запросов, и postgres опять отодвинулся по скорости далеко-далеко ;)

Кэширование запросов на уровне базы хорошо работает в двух типах задач:

1) База, используемая только для чтения (куча простых веб-приложений)

2) Бенчмарки, изготовленные в MySQL AB/под присмотром MySQL AB

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

> MySQL научился поддерживать встроенные процедуры?

Роль процедур исполняет application server. И докажи, что это неправильно.

> до этого же их дохрена было --- любили в MySQL AB это дело

А куда ты думаешь они делись? Загляни-ка в каталог sql-bench.
Все на месте. Бери, запускай и опровергай.

> В MySQL появились сложные запросы?!

s/сложные/тяжелые/

Много таблиц, много одновременных клиентов.

anonymous (*) (2003-04-24 09:16:59.714017)

Здравствуй, walrus. ;)

> Роль триггеров исполняет application server. И докажи, что это неправильно.

Доказываю: далеко не все приложения работают через application server. И нефиг городить application server, если нужен простой триггер для сбора статистики или учёта изменений.

Или вон в Postgres'е простейшее решение для репликации - contrib/rserv сделан на триггерах. А в MySQL для такого же пришлось все потроха перелопачивать.

> Кэширование запросов на уровне базы хорошо работает в двух типах задач:

> 1) База, используемая только для чтения (куча простых веб-приложений)

А что, есть базы, которые используются только на запись? ;)

> Доказываю: далеко не все приложения работают через application server.

Хм, а кто мешает?

> если нужен простой триггер для сбора статистики

А вывод и представление данных тоже триггер делает? ;)

anonymous (*) (2003-04-24 09:21:29.259602):

> А куда ты думаешь они делись? Загляни-ка в каталог sql-bench. Все на месте. Бери, запускай и опровергай.

А почему результаты не публикуются? На сайте последние результаты для Postgres'а версии 7.1.1, а сейчас 7.3.2

Да и к тому же, эти бенчмарки однопользовательские. А когда пользователь один, то файлы ещё быстрее работать будут...

> А почему результаты не публикуются?

cd sql-bench/Results

> А что, есть базы, которые используются только на запись? ;)

> А вывод и представление данных тоже триггер делает? ;)

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

> эти бенчмарки однопользовательские.

cd mysqld/tests
./fork_big.pl

Наслаждайся.

Ребята, не надоело членами меряться?
Существует N хороших (в смысле, имеющих своего потребителя) серверов. Ну и слава Богу!
Я тоже, когда прочёл про 7 встроенных языков, подумал: А зачем? Лучше бы пару хорошо развивали... Но в модели написания программ СООБЩЕСТВОМ, оно (сообщество) определяет, что развивать, отсюда вывод: ВСЁ, что пишется в такой модели, КОМУ-ТО нужно!
По-моему, здесь надо побольше меняться опытом и поменьше хаять!

Спасибо за внимание, извините, наболело при чтении новостей...

> То есть по существу сказать нечего

Ну почему же. Ты сказал, что для простых вещей application server не нужен. Вот я и спросил, кто за вывод отвечает.
Клиент? Он же запросами к базе рулит? Дык это ж детский сад,
младшая группа. А если application server все-таки есть, то
какой прок в твоих тормознутых триггерах, которые срабатывают
и когда надо и когда не надо?

to anonymous:

> А из лидерства уже следует, что в MySQL есть _больше_ из того, что
> нужно потребителям в данной нише

На всякий случай напомню, что в нише SQL серверов лидирует пока Oracle и DB2.

10 к 1, что Вы уважаемый анонимус о Постгресе знаете только из пресс-релизов mySQl.

> Есть такой комплекс неполноценности у любителей postgres.
> Против фактов не попрешь, но выебываться не запрещено ;)
> Только они слегка приблизились к скорости mysql на сложных
> запросах, как в mysql-4.x появилось кеширование запросов, и
> postgres опять отодвинулся по скорости далеко-далеко ;)

Если обработка запроса занимает доли секунды что в mySQL, что в PostgreSQL - разительно заметно, что mySQL выполнил операцию за 100 ms, а PostgreSQL , к примеру, за 300 ms.
Зато возьмем базу на 100 тыс записей, которую нужно склеивать, перекапывать selectom и ... (ладно хватит и этого) и выдавать результат.
PostgreSQL v7.2 - 9 секунд,
MySQL v4.0 - 16 секунд.
Структуры таблиц одинаковые, запросы одинаковые и сервер исполнения один в обоих случаях.
Ах да, кеширование MySQL. ( кстати, а что запрещает мне кешировать записи в PostgreSQL ?)
И какой мне от него толк если базы обновляются со скоростью до 10 записей в секунду ?

Это мой часный случай.
Что я установлю в качестве базы данных в этом продукте ? PostgreSQL, потому что в рамках _этой_ задачи он быстрее.

Вывод:
Можно мерять быстродействие в различных "слониках". Можно размахивать пресс-релизами. Но выбирают то, что подходит лучше для решения той или иной задачи.
SQL - он и в Африке SQL и лично мне по барабану как он зовется (в свое время сделал заказ на miniSQL - очень забавная вещищка).
И этот комплекс не только любителей postgres называется Здравый смысл.

Кстати обнаружил что сложные завпросы, которые на postgres 7.2 (дефолтная сборка из шапки 7.3) выполнялись 6 секунд (это тут, прямо на лоре такие есть), после переезда на 7.3 и пересборки его gcc 3.2 c -march=pentium3 -mcpu=pentium3, тот же запрос стал выполняться 2 секунды. До сих пор думаю - к чему бы это? ;)

> А если application server все-таки есть, то какой прок в твоих тормознутых триггерах, которые срабатывают и когда надо и когда не надо?

Насчет тормознутости - как напишешь, так и будет, это твоих рук дело, а не базы. На postgres заведомо можно сделать триггер не медленнее чем та же проверка в appserver. Насчет "когда надо и когда не надо". А кто проверяет - когда надо, а когда нет? appserver? так см. пункт первый. В базе всегда триггеры срабатывают когда надо, потому как by design должно быть заложено, что мусорные данные нужно не хранить а отсеивать.

Народ, да вы что! Нельзя сравнивать MySQL и Postgres, это 2 совершенно различных продукта, заточенных для разных задач. Использование Postgres для Guestbook смотрится так же криво как и использование MySQL для серьёзной многопользовательской базы. Я раньше работал с Oracle, а сейчас пересел на Postgres потому как задачи стали проще :) Любителям application server хочу сказать, что решать задачи, для которых реально нужен as на MySQL как минимум странно, кроме того никакие приблуды и навороты не дадут сохранить целостность и непротиворечивость базы. Это возможно сделать только с помощью FOREIGN KEYS и TRIGGERS. Особо хочу отметить plpgsql - порадовал, но packages-ов пока что не хватает... Ещё порадовали древовидные запросы, которые один наш соотечественник ваяет. А MySQL я тоже использую - для форумов и новостей на сайте, прекрасно работает, придратся не к чему, особенно 4-ка.

P.S. Особенно меня порадовали сообщения о комплексах :) Скажите, а что у кого-то реально проблемы с психикой из-за программных продуктов? Я по на ивности душевной считал, что это тоже две совершенно различных области :)

база должна следить за целостностью даных а не апсервер и это имхо самый правильный подход

TurboVision

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

Объясни мне отличие constraints от foreign key. Re: База должна быть тупым хранилищем данных. Мда, ребят, вам не SQL а Clipper нужен.

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

при чем здесь TurboVision?

> База должна быть тупым хранилищем данных.

Слав богу что такие дебилы остановились в своем развитии на mysql

Дело скорее не тогда когда ты добаляешь, а когды ты УДАЛЯЕШЬ запись, а тригер чистит все ссылки. А чем тебе plsql не нормальный язык?

> гребаные коскадные тригеры с тучей разветвлений ... бля в сад такое. транзакции, ну может фкей, все остальное не нужно, остальное на нормальном языке должно быть (а не ущербный plsql) !

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

вообще имхо ругаться на триггеры в SQL это то же самое что ругаться на конструкторы/деструкторы в C++. конечно, можно и на C++ писать только struct {} и быть довольным...

в чем ущербность pl/sql? вы ж на нем не gui рисуете.

Да ни при чём - Mozilla тоже воображает себя слишком умной ;)

> Слав богу что такие дебилы остановились в своем развитии на mysql

Спасибо за комплимент. Я предпочитаю Firebird (сознательно игнорируя его хранимые процедуры).

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

Тригеры плохи:

- неявными зависимостями - мутацией

plsql плох:

- отсутсвием нормального OO ( D ) - oтсутсвием нормальной обработки exceptions ( c наследованием ) - отсутсвием возможности создавать нормальные и удобные структуры данных

Вывод дейсвительно печален - oracle - это действительно большой, умный и продвинутый storage. plsql - язык работы с данными, но не как не язык создания приложений - он был таковым во времена ada etc и процедурного програмирования, но ничто новое, по хорошему, его не коснулось ( 7.x oracle ).

Теперь про storage. Кто как - я уже задолбался играть хинтами оптимизатора.

Общий вывод - при всем богатстве выбора альтернатив действитьно мало )( если базы более 300+ gb ), но полноценно получается использовать только как smart and powerfull storage.

ответ to0r'у:

MySQL уже давно не поделка для форумов. Его уже с версии 3.23 реально используют с терабайтными объёмами данных, и не только в России.

Ты конечно выбираешь что лучше в рамках решения твоей задачи главное, чтобы ты не был trapped with your database solution. Postgres развивается много хуже, а на рынке если ты второй - можешь закрывать лавочку.

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

Теперь по поводу фич MySQL, которых в постргресе нет: - репликация, hot backup - binlogging - character set per database, per table, per column (utf8 also) - mature and fast Oracle-style transactions (multi-versioning model) - список платформ на которых он _работает_ - куча third-party продуктов: phpMyAdmin, ODBC/JDBC всякие гуи и контрол центры и т. д. - fulltext search, query cache, embedded server - professional support && community size

По поводу того, что на рынке лидируют Oracle и DB2: как ни странно, несмотря на разные весовые категории, MySQL распространён уже не менее широко. И стандартный минимальный набор баз данных, который должно поддерживать хороший unix middleware (по крайней мере в России и Германии, за всю Одессу говорить не буду) - это Oracle (first) MySQL (second), DB2 (third).

Это то, чем MySQL уже превосходит Postgres. И с учётом того, с какой скоростью MySQL развивается, отрыв будет только увеличиваться, и все фичи постгреса в ближайшее время (1-2 года) будут в MySQL. Хотя нет, не все. Объекты и наследование, думаю, появятся нескоро. MySQL это всё таки RDBMS.

> в чем ущербность pl/sql? вы ж на нем не gui рисуете.

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

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

PostgreSQL

Tico, применение аппсерверов оправдано в маленьких задачах тоже. Это вытекает из общего принципа "разделяй и властвуй" - вредно смешивать логику хранения и логику обработки. Правда, должен признаться, что пока я реализовал только один действительно большой проект с БД, и там использовал триггеры и хранимые процедуры, и на деле убедился в их отстойности с точки зрения поддержки (а заниматься поддержкой этой базы мне приходится до сих пор).

Внешний ключ - частный случай явного ограничения.

btw, в mysql триггеры и хранимые процедуры будут на Python'е

Мутация триггеров - проблема достаточно тривиальная со стандартными путями решений. Я, также, не считаю что необходимо разносить хранение и обработку - если обрабатываешь где хранишь, то скорость гораздо выше. По поводу недостатков plsql могу сказать просто: прекрасный язык для своих задач. Никто от него не ждал ОО, не для этих целей он был создан, если действительно нужен ОО - ставь апликейшин сервер. Но нормальный AS увеличит стоимость разработки и обслуживание продукта на порядок. Я просто более чем уверен, что некоторые коллеги используют перловые скрипты/С++ программы, которые называют AS, просто потому что не знают что все эти задачи можно решить на plsql. Поэтому КАКОЙ АПЛИКЭЙШИН СЕРВЕР ВЫ ИСПОЛЬЗУЕТЕ и для каких задач?

По поводу теребайтных баз в MySQL верю, но готов поспорить что базы в основном статичные, направленные на SELECT и INSERT а не на UPDATE, а таблицы плоские. Один мой знакомый использует MySQL для хранения сырых данных netflow - просто супер.

А по поводу Oracle и DB2 то я думаю, что сравнивать с ними MySQL и Postgres просто некорректо, это абсолютно разные разные ценовые и качественные ниши.

Tico (*) (2003-04-24 10:23:57.634018):

> Народ, да вы что! Нельзя сравнивать MySQL и Postgres, это 2 совершенно различных продукта, заточенных для разных задач.

проблема в том, что сами разработчики MySQL имеют наглость это делать: http://www.mysql.com/doc/en/MySQL-PostgreSQL_features.html

anonymous (*) (2003-04-24 12:28:25.460322):

> Postgres развивается много хуже,

именно поэтому фичи, которые в Postgres'е несколько лет _работают_, в MySQL _обещают_ в "версии 5.x"

> Теперь по поводу фич MySQL, которых в постргресе нет: - репликация

кури: http://directory.google.com/Top/Computers/Software/Databases/PostgreSQL/Repli...

> hot backup -

если имеется в виду consistent backup при работающей базе - то есть, причём бесплатно, в отличие от InnoDB. Если log replay, то пока нет.

> binlogging

кури: http://www.postgresql.org/docs/view.php?version=7.3&idoc=1&file=wal.html

> character set per database, per table, per column (utf8 also)

нету, зато есть полноценная поддержка unicode

> mature and fast Oracle-style transactions (multi-versioning model)

кури: http://www.postgresql.org/docs/view.php?version=7.3&idoc=1&file=mvcc....

это в Postgres'е появилось на несколько лет раньше

> список платформ на которых он _работает_

...примерно такой же. А выигрывает MySQL за счёт одной платформы - Вынь32, под которой сидит куча "разработчиков".

> куча third-party продуктов: phpMyAdmin, ODBC/JDBC всякие гуи и контрол центры и т. д.

http://phppgadmin.sourceforge.net/ http://jdbc.postgresql.org/ http://gborg.postgresql.org/project/psqlodbc/projdisplay.php http://techdocs.postgresql.org/guides/GUITools

> fulltext search

contrib/tsearch http://openfts.sourceforge.net/

> query cache

читай выше

> professional support

есть бабки - можешь и за поодержку PostgreSQL заплатить

> community size

главное не уточнять про community quality

Упс! Столько нового! Огромное спасибо! Пошёл читать.

anonymous (*) (2003-04-24 13:04:17.284464):

> btw, в mysql триггеры и хранимые процедуры будут на Python'е

ключевое слово "будут". а теперь сюда: http://www.postgresql.org/docs/view.php?version=7.3&idoc=1&file=plpyt...

PostgreSQL

> Я просто более чем уверен, что некоторые коллеги используют перловые скрипты/С++ программы, которые называют AS, просто потому что не знают что все эти задачи можно решить на plsql. Поэтому КАКОЙ АПЛИКЭЙШИН СЕРВЕР ВЫ ИСПОЛЬЗУЕТЕ и для каких задач?

Да, я использую C++ программы, которые работают с БД и общаются с юзером через CGI. Задачи небольшие, но бывают логически сложными. Oracle не знаю.

С мутацией дейсвительно довольно просто бороться, но это усложняет всю конструкцию или появляются очереди + обвязка кодом.

Далее - попробуйте без ОО написать довольно большое приложение. Начнем от примерно 100 сущностей - посмотрите, что получится.

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

Теперь попробуйте линейно масштабировать полученное решение.

Попробуйте побороться с проблемой dead locks внутри! dbms_alert. Попробуйте понять причину умирания инстансов AQ.

И тд и тп. Все можно - вопрос лишь удобства и собственной производительности.

до кучи - в реляционной моделе все таблицы по определению плоские :)

RE: Далее - попробуйте без ОО написать довольно большое приложение. Начнем от примерно 100 сущностей - посмотрите, что получится.

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

Теперь попробуйте линейно масштабировать полученное решение.

Попробуйте побороться с проблемой dead locks внутри! dbms_alert. Попробуйте понять причину умирания инстансов AQ.

Да вообщем-то приходилось участвовать в подобном проекте Oracle + OAS. Но вот только какое это отношение имеет к Postgres и MySQL? :)

Угу

Короче, господа, пока вы тут треплетесь, у нормальных людей работает
не один серьезный программный продукт (это бэк-офис и депозитарий, если
анонимусам что-то эти слова говорят) именно на Постгресе.
База - умное хранилище данных. ВСЯ логика (а она очень даже непростая)
уместилась в plpgsql. Клиент - тупейшая морда на VC++ с гридами.
Результат - навороченные отчеты за торговый день (листов 100-200)
печатаются автоматически со скоростью, на которую способен принтер.
Короче, работать надо а не пиписьками меряться, тогда мож и результат
будет.

dixi

2 hbee: Но вы, я думаю, согласитесь, что это не Application Server? Это скорее Application который выполняется на Server. Я более чем уверен, что вашу задачу возможно решить с помощью stored procedure.

Народ, да шо вы мучаетесь?? Юзайте interbase aka firebird! И все у вас будет зашибись!

>> Теперь по поводу фич MySQL, которых в постргресе нет: - репликация

>кури: > http://directory.google.com/Top/Computers/Software/Databases/PostgreSQL/Repli...

Детский сад, последний апдейт сайта 2 года назад, про 7.3 они даже не слышали ничего.

>> binlogging

> кури: http://www.postgresql.org/docs/view.php?version=7.3&idoc=1&file=wal.html

Опять суёте фуфло. Речь о функциональности http://www.mysql.com/doc/en/Binary_log.html , а не о том, что у них транзакции через WAL сделаны.

> mature and fast Oracle-style transactions (multi-versioning model)

> кури: http://www.postgresql.org/docs/view.php?version=7.3&idoc=1&file=mvcc.... > это в Postgres'е появилось на несколько лет раньше

Да, но без vacuum'а не работает. Как, vacuum всё ещё нагибает всю базу?

Все ваши возражения - в Postgres'е это есть, только хуже. MySQL тоже своего г. хватает.