LINUX.ORG.RU

PostgreSQL 8.0


0

0

NY, NY: 19 января 2005 г. - Международная команда разработчиков PostgreSQL выпустила версию 8.0 объектно-реляционной системы управления базами данных, закрепив позицию PostgreSQL как самой передовой в мире СУБД с открытым исходным кодом. Версия включает такие возможности, которые ранее были доступны только в самых дорогих закрытых СУБД. Это значительно повышает интерес к PostgreSQL и среди пользователей, и среди производителей программного обеспечения.

Кроме новых возможностей и значительного улучшения производительности, PostgreSQL 8.0 демонстрирует не имеющий равных темп разработки открытого программного обеспечения. Более десятка компаний, включая Red Hat, Fujitsu, Afilias, Software Research Associates, Inc., 2nd Quadrant, и Command Prompt Inc., вместе с сотнями разработчиков, внесли свой вклад в реализацию идей, количество которых значительно больше, чем у любой из предшествующих версий.

Новые возможности включают:

"Родная" поддержка Windows: PostgreSQL теперь работает в ОС Windows без дополнительных "прослоек" для эмуляции системных вызовов. Это значительно улучшает производительность по сравнению с предыдущими версиями, и предоставляет реальную альтернативу закрытому программному обеспечению баз данных для независимых производителей программного обеспечения, корпоративных пользователей и индивидуальных разработчиков для Windows.

Точки сохранения (savepoints): Эта возможность, которая есть в стандарте SQL, позволяет выполнять откат отдельных частей транзакций, не прерывая транзакцию в целом. Это полезно для разработчиков бизнес-приложений, требующих сложных транзакций с восстановлением после ошибок.

Восстановление на определенный момент (point in time recovery) : Эта функция дает возможность полностью восстанавливать данные из непрерывно архивируемых журналов транзакций, что является давно востребованной альтернативой ежечасному или ежедневному резервному копированию критичных данных.

Табличные пространства (tablespaces): Критически важные для администраторов многогигабайтных хранилищ данных, табличные пространства позволяют размещать большие таблицы и индексы на отдельных дисках или массивах, что повышает производительность запросов.

>>> Подробности



Проверено: maxcom ()

Ответ на: комментарий от anonymous

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

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

От злости.

CybOrc
()
Ответ на: комментарий от anonymous

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

anonymous
()

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

OpenStorm ★★★
()
Ответ на: комментарий от anonymous

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

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

anonymous
()

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

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

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

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

vada ★★★★★
()

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

SKYRiDER ★★★
()
Ответ на: комментарий от anonymous

> 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/

SKYRiDER ★★★
()

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

anonymous
()

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

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

dotcoder ★★★★★
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

Ay49Mihas ★★★★
()

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

MiracleMan ★★★★★
()

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

drd ★★
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от annonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

annonymous ★★
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от annonymous

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

annonymous ★★
()
Ответ на: комментарий от anonymous

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

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

annonymous ★★
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от annonymous

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

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.

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

RSM
()
Ответ на: комментарий от RSM

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

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

annonymous ★★
()
Ответ на: комментарий от annonymous

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

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

RSM
()
Ответ на: комментарий от annonymous

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

saper ★★★★★
()

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

phicus
()
Ответ на: комментарий от annonymous

> А если честно признаться без всяких левых оправданий, то постгрес безусловный тормоз. И его тормознутость нельзя объяснить его более сложным устройством. Как вам эта реплика из бенчмарка, линк на который дан выше: 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 отдаёт неверные результаты, потому что он "тормозной" и "глючный". Но почему же "самый быстрый" и "устойчивый" мыскль делает то же самое? ;

sad_spirit
()
Ответ на: комментарий от RSM

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

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

annonymous ★★
()
Ответ на: комментарий от annonymous

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

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

sad_spirit
()
Ответ на: комментарий от annonymous

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

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

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

vada ★★★★★
()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

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

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

anonymous
()
Ответ на: комментарий от annonymous

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 идет с такими дефолтными настройками, которые позволят ему запуститься где угодно. О производительности на конкретных задачах при дефолтной конфигурации речи быть не может. Разработчики постгресса так об этом и говорят.

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

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

anonymous
()

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

opeg
()

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

sad_spirit
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.