PostgreSQL 8.0

Новость хорошая! Гы, а кто знает чего это mysql.org лежит?

Новость замечательная :)

> Гы, а кто знает чего это mysql.org лежит?

От злости.

mysql.com, а не орг ... а вот сайт постгреса в дауне ... действительно заинтересовали юзеров :)

Список зеркал веб-сайта: http://wwwmaster.postgresql.org/mirror/website

а то основное зеркало уже... того...

Они в трауре. Не знают, что теперь с MAXDB делать.
Посему решили временно залечь на дно.

www.postgresql.org тоже лежит.

Для ярых линуксоидов рекомендуется взглянуть на лицензию PostreSQL

У меня Postgres отрылся нормально. Уже качаем...

Уррра!!! Не повода не выпить. ;)
Хорошее зеркало: http://www.se.postgresql.org/

взглянул... Запрета на использование под Linux не обнаружен.

Месье курит шампиньоны?

Вот приятель попросил бросить. Может кто в курсе.

Он поставил восьмерку под винду, и обнаружилась проблема, которая была во всех бетах. Через ODBC драйвер не видится поле типа TEXT.

Может кто чего посоветует.

ЗЫ. Менять тип поля не катит, т.к. клиентская программа давно написана и работает, только с постгресом под линукс.

Кстати, а не подскажете чем можно потестировать производительность сервера БД? Хотелось бы какую-нибудь небольшую прогу (желательно Open Source и простую в установке), которая могла бы сгенерировать большую базу данных и потом гонять по ней разные сложные SELECT'ы, UPDATE'ы и т.д. Очень уж хочется потестировать PostgreSQL. :)

ODSL-DBT-2 provides a company application for client data and product stock, to which more than one user can have access at once. This test corresponds to the TPC-C-Benchmark.

http://www.pressetext.com/pte.mc?pte=030303044

> ODSL-DBT-2 provides a company application for client data and product stock, to which more than one user can have access at once. This test corresponds to the TPC-C-Benchmark.

Спасибо, я уже сам нашёл OSDL'овские тесты. Ещё нашёл http://osdb.sourceforge.net/

Это знаковое событие!

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

Классная новость! Спасибо тебе, nickg! :)

Классная информативная самодостаточная новость, было бы классно если все ньюсы были такими (в плане информативности).

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

>Народ, есть ли где то бенчмарки мускула и постгресса?

В mandrake10-10.1, например, есть такой пакет, называется типа mysql-bench

Прелестно, прелестно.. ;-))

Еще бы mono до ума довели и прощай asp.net под виндами...

> а если хочется по человечески перенести логику в субд то mysql совсем негодится

не самая хорошая идея с точки зрения масштабируемости

Масштабируемости или переносимости на другие субд?

Как ты собрался сравнивать postgres и mysql?

>не самая хорошая идея с точки зрения масштабируемости

зато бюстро, а маштабирование можно и интелом обеспечить. линух пускают уже на 1024 процах, да и фермы из mysql/pgsql мало кому нужны, для этого есть оракл у которого есть и инструменты как этим управлять и правильная архитектура (RAC).

Это взаимосвязанные вещи: вырастут потребности - вырастет база гигов до 20 - захочется Oracle - запаритесь переносить

Ну и масштабнее - если уже всё на Oracle, то дальнейший рост кучу бабок стоить будет (RAC, дорогущее многопроцессорное железо...)

> Народ, есть ли где то бенчмарки мускула и постгресса?

Вот, есть один интересный бенчмарк:
http://people.ac.upc.es/zgomez/tpch-results.html

Одна интересная закономерность: на linux 2.6 производительность
постгреса увеличивается в разы по сравнению с ядром 2.4.

> маштабирование можно и интелом обеспечить. линух пускают уже на 1024 процах, да и фермы из mysql/pgsql мало кому нужны, для этого есть оракл у которого есть и инструменты как этим управлять и правильная архитектура (RAC).

Ага, это в теории хорошо. А у нас тут Oracle на 4х-процессорной машине (ксеоны) тысяч так за 300 баксов. И ещё вторая такая же - standby. Итого 600 штук. И дальнейший рост тоже немеряно бабок стоить будет.

А если честно признаться без всяких левых оправданий, то постгрес
безусловный тормоз. И его тормознутость нельзя объяснить его более
сложным устройством. Как вам эта реплика из бенчмарка, линк на который
дан выше: Postgresql took approx. 2.5 days to load the entire database data.

> вырастет база гигов до 20 - захочется Oracle

Значит, всё-таки ты имел в виду переносимость. Не путай разные вещи.

Ага, это в теории хорошо. А у нас тут Oracle на 4х-процессорной машине (ксеоны) тысяч так за 300 баксов. И ещё вторая такая же - standby. Итого 600 штук. И дальнейший рост тоже немеряно бабок стоить будет.
------

не понял про теорию, у вас оракл плохо работает ? стандбай неподнимается ? или вы думаете что могли бы как google понаставить тучу дешевых писюков и на mysql вместо оракла вашу задачу крутить ? нет ? вот и рынок ERP говорит что нет ...

Ответ идет предложением дальше =):

But we have to consider too, that mysql in its default config (myisam tables) doesn't recognice foreign keys and does not check this restriction, so it is normal to see that mysql is faster loading data.

Так что ничего удивительного в этом нет. Кстати это и к вопросу о тормознутости =).

> it is normal to see that mysql is faster loading data.

Да, но где предел терпимости? ;) 20 раз faster, 40 раз faster, 100 раз...
Какая потеря производительности оправдана после добавления некоторой фичи?

> Какая потеря производительности оправдана после добавления некоторой фичи?

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

> Postgresql took approx. 2.5 days to load the entire database data.
annonymous: Дочитай фразу до конца, не нужно тут черного PR MySQL, я тоже могу много и действительно плохого про MySQL найти и написать.

Опять без священных войн не обошлось...

> А если честно признаться без всяких левых оправданий, то постгрес безусловный тормоз. И его тормознутость нельзя объяснить его более сложным устройством. Как вам эта реплика из бенчмарка, линк на который дан выше: Postgresql took approx. 2.5 days to load the entire database data.

В данном конкретном случае его тормознутость можно объяснить кривыми руками афтара, который ничего не смог настроить. Это получается как "тест производительности современных графических ускорителей под управлением драйвера Generic VGA". Да, можно такой тест провести, даже какие-то графики нарисовать и делать "выводы": "принципиальной разницы между видеокарточкой за 5 баксов и за 500 --- нету! народ дурят!"

А что у афтара кривые руки, замечательно показывает следующая цитата:

> The surprising thing is that all returned results are incorrect answers from the point of view of TPC-H result set.

Ну ладно, Postgres отдаёт неверные результаты, потому что он "тормозной" и "глючный". Но почему же "самый быстрый" и "устойчивый" мыскль делает то же самое? ;

> а именно обеспечения целостности =).

Не проблема. Используем Innodb. Только не происходит 20-50-кратной
потери производительности. Я так и знал, что сечас начнутся гнилые оправдания, вместо признания медленной реализации.

> Не проблема. Используем Innodb. Только не происходит 20-50-кратной потери производительности.

Да? А покажи-ка независимый бенчмарк с использованием InnoDB... ;

Родной! Ты чего хочешь-то? Чего с чем сравнитЬ?

Кирпич с ящиком? А по каким критериям? Кирпич тящелее, зато ящик больше? Кипич тонет, зато ящик горит?

Чего ты хочешь, родной?

> не понял про теорию, у вас оракл плохо работает ? стандбай неподнимается ?

Да всё нормально работает. Просто если появится заказчик, у которого в 100-1000 раз больше нагрузка, то на данном этапе мы никаким железом такой производительности не дадим.

И логика у нас не в Oracle. Что радует, она уже неплохо распараллелена и крутится на нескольких более дешевых двухголовых серверах.

Короче, Оракл тут узкое место, точнее файловое хранилище под Ораклом.

> или вы думаете что могли бы как google понаставить тучу дешевых писюков и на mysql вместо оракла вашу задачу крутить?

Ага, именно так. Google смог - заработал миллиарды $. Так что есть к чему стремиться...

> нет ? вот и рынок ERP говорит что нет ...

А надо быть впереди рынка. У нас пока получается...

Ладно, а тут что скажешь: http://www.eweek.com/article2/0,3959,293,00.asp

http://archives.postgresql.org/pgsql-advocacy/2004-04/msg00206.php

Во-первых, этот тест проводился год назад. "I would also like to see you test the current CVS for PostgreSQL. We've been working with the OSDL to improve our TPC-H test results, and the queries which timed out now return correct results."

Во-вторых: "Your load time of days for the data in particular indicates a tuning problem; when I ran TPC-H, data loaded in under an hour." "Testing MyISAM tables on MySQL without Foriegn keys or transactions invalidates your test; these are requirements of the TPC and not optional. You should test on an installation of MySQL which supports these features."

В-третьих: если используешь СУБД, нужно поинтересоваться как она тюнится. PostgreSQL идет с такими дефолтными настройками, которые позволят ему запуститься где угодно. О производительности на конкретных задачах при дефолтной конфигурации речи быть не может. Разработчики постгресса так об этом и говорят.

>Да всё нормально работает. Просто если появится заказчик, у которого в 100-1000 раз больше нагрузка, то на данном этапе мы никаким железом такой производительности не дадим.

да легко ibm power5 с 64 двухголовыми процами. в самой большой канторе не более 0.5M юзеров, если ваша логика не в субд то это у вас что-то типа tpc-c, а там ibm 2.5 милиона юзеров гоняет.

>А надо быть впереди рынка. У нас пока получается...

впереди ? вы ... это если с oebs или sap конкурируете то вы из МС, получается у вас axapta на оракле на дешевых пц распаралелина :)

распораллелить ERP имхо не реально ...

> Вот, есть один интересный бенчмарк: http://people.ac.upc.es/zgomez/tpch-results.html

дорого же расплачивается постгрес за фичи ..

Дайте пожалуйста ссылочку на русскую документацию

Бизнес-логику в СУБД пишут только пингвины. Нормальные люди бизнес логику пишут на уровне middle tier, а СУБД используют как хранилище данных и не более того. И вот при таком использовании MySQL вполне оправдывает себя, только его тоже тюнить надо чтобы на запросах с парой join'ов он не делал прохода по всем таблицам без использования индексов как он это любит делать при неграмотно созданных индексах. Но есть и крутые перцы у которых oracle за 300 килобаксов на многопроцессорных тачках, но там все так запущено что сравнивать "типичные" аппликухи с их задачей просто смешно.

>Нормальные люди бизнес логику пишут на уровне middle tier

Читал недавно Тома Кайта, так он в своей книге говорит совсем обратное, и в отличие от тебя вполне аргументировано. В совсем малюсенькой базе может это и оправдано, но тогда откуда в ней middle tier? Сразу видно, что про сложную бизнес-логику и большие БД вы только немного наслышены, люди делающие такие системы в вашей терминологии "крутые перцы"...

А вот когда у вас нагрузка возрастет до того, что трафик между middle tier и БД станет узким местом, тогда вы поймете, что в БД нужно затолкать как можно больше бизнес-логики, а что не получится - в серверы приложений.

>В совсем малюсенькой базе может это и оправдано

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

в общем можно засчитать anonymous'у слив за "бенчмарки", т.к. на мои сообщения он не ответил, и перейти к следующему пункту:

> Бизнес-логику в СУБД пишут только пингвины.

а почему тогда разработчики Самой Быстрой в Мире СУБД с Дельфинчиком задрав штаны бегут реализовывать всякие хранимые процедуры и, не побоюсь этого слова, триггеры? и при этом постоянно хвалятся своими достижениями в этой области? неужели они считают "пингвинов" своей целевой аудиторией?