Слоны уже тут. Быстрые, надёжные, мощные. PostgreSQL 8.3!

    Более 200 разработчиков, более 300 патчей, 15 месяцев напряжённой работы разработчиков и тестировщиков… И вот — новейшая версия лучшей СУБД в мире готова к использованию в промышленных условиях!

    4 февраля 2008-го года Глобальная группа разработчиков PostgreSQL (PostgreSQL Global Development Group) анонсировала долгожданный релиз версии 8.3 самой развитой открытой СУБД, факт выхода которой ещё более укрепляет позиции PostgreSQL как и самой производительной СУБД из систем с открытым исходным кодом. Среди новшеств, касающихся производительности, стоит выделить:

    * HOT (Heap Only Tuples)
    * механизм автонастройки параметров процесса bgwriter
    * асинхронная фиксация транзакций (Asynchronous Commit)
    * «размазанные контрольные точки» (Spread Checkpoints)
    * «синронизованные просмотры» (Synchronous Scans)
    * дополнительное уменьшение дискового пространства («Var-Varlena»)
    * защита L2-кэша
    * уменьшение скорости «скорости накрутки» счётчика транзакций (Lazy XID)

    PostgreSQL 8.3 также содержит много интересных и привлекательных новинок, которые по достониству оценят разработчики и администраторы баз данных. Вот некоторые из этих новшеств:

    * CSV-логирование
    * SQL/XML (!)
    * поддержка MS Visual C++
    * ENUM-типы
    * встроенный Tsearch (!)
    * SSPI & GSSAPI
    * массивы составных типов
    * pg_standby

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

    Текст официального пресс-релиза на русском языке: www.postgresql.org/about/press/presskit83.html.ru
    Статья о новинках 8.3 на русском языке: postgresmen.ru/articles/view/78
    Коммерческая поддержка 24/7, консультации на русском языке: postgresmen.ru
    Поделиться публикацией

    Похожие публикации

    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 97

    • НЛО прилетело и опубликовало эту надпись здесь
        0
        тип данных xml, правильная сериализация/десериализация, ну и да — функции экспорта (XMLELEMENT, XMLAGG и т.д.) по стандарту
          +1
          В частности, это возможность хранить данные в специальном XML-типе (теперь встроен в ядро PostgreSQL), возможность выполнять xpath-запросы по таким колонкам (даже используя индексы!), куча функций для т.н. публикации XML и еще много чего интересного...
            0
            ну, индексы использовать можно не для выполнения xpath-запросов, а, скорее, для избежания их выполнения %-)
              +1
              верно, но факт остается фактом: легко можно добиться очень быстрого выполнения запросов вроде SELECT * FROM table WHERE xml_column = xpath('/company/employee/firstname') = 'John'; (ну синтакс не точный, ну приблизительно).
                +2
                блин, чушь написал, конечно
                правильнее так:
                SELECT * FROM table WHERE xpath(xml_column,'//company/employee/firstname')[0] = 'John';
                • НЛО прилетело и опубликовало эту надпись здесь
                    +2
                    да, если ваши запросы смогут использовать функциональный индекс, скорость будет превосходна. уже существуют production-системы с сотнями тысяч (не супер объем, но все же) XML-документов, которые используют именно эту функциональность в PostgreSQL.
                      0
                      Скорость конечно на уровне, ибо легко в таком случае заюзать обычный функциональный btree-индекс ;-)

                      А реляционные БД давным-давно в прошлом, смотрите стандарт, другие СУБД. Всякие там анонимные строчные типы, массивы и тд и тп. В Постгресе это intarray, hstore с нормальными GiST/GIN-индексами от Олега и Фёдора. Слабоструктурированные данные в реляционке хранить теперь просто и приятно. EAV во многих случаях уходит на второй план, т.к. проигрывает в гибкости разработки и прозводительности.
                        0
                        Кстати, система тэгов и всякие там специализированные каталоги в соц. сетях (типа школ, вузов, компаний и т.п.) — это вот как раз такие случаи.

                        Постараюсь рассказать об этом подробнее в ближайших заметках.
                          –2
                          Интересно, это каким же образом b-tree индекс ускорит xpath? Неужели каждый узел dom-модели xml отдельно в индекс суется? Бредятина, сэр!
                            +1
                            Для упомянутого SELECT-a:

                            CREATE INDEX i_zzz ON table1 USING btree((xpath(xml_column,'//company/employee/firstname')[0]));
                              0
                              Не вижу смысла в этом. Зачем делать индекс на запрос xpath? В таком случае гораздо быстрее будет данные не в xml хранить. А что делать в случае, если запрос xpath генерится в процессе работы? Индексировать каждый? Я все к тому, что производительность при использовании xpath к полю xml будет не очень... Хотя не могу отрицать полезность этого дела в частных случаях.
                                +1
                                да, вы правы. именно об этом и речь. просто я лично именно с таким счастливым случаем и сталкивался: модель данных предполагала хранение исключительно в XML; наиболее распространенными выборками при этом были запросы на сравнение значений определенных узлов XML-деревьев. конечно, можно распарсить эти значения и хранить их в varchar-колонках, к примеру. но куда приятнее использовать встроенные возможности, функциональный индекс и дополнительные XML-фильтры, когда запрос по индексу уменьшил кол-во возвращаемых записей до нескольких десятков, согласитесь.
                                  0
                                  К одной неработающей модели добавили другую неработающую модель - в чём проблема ?

                                  Если честно, то дальше BDB API (запрос данных по ключу плюс транзакции) всё абстракции "протекают", причём очень сильно. По хорошему - их лучше бы вообще не пользовать (все абстракции "протекают", но когда масштаб "протечек" превышает определённый рубеж, то борьба с ними превышает выигрыш об абстракций), но столько рекламы здравому смыслу никогда не перебить...
                                    0
                                    7 лет ковыряний с одним продуктом запросто справляются с рекламой :-) Мы именно до этого уровня (запрос по ключу + транзакции) и добрались в итоге, но борьба с протечками заняла в самом деле очень много времени:
                                    http://maximkr.livejournal.com/12147.htm…

                                    Причем транзакции тоже под вопросом: если приложение достает данные из СУБД не каждый раз, а вынуждено что-то хранить в памяти, то эти данные в памяти СУБД-шными транзакциями уже не охватываются и приходится блокировки, их репликацию между узлами кластера и т.п. писать вручную.
                                  0
                                  только этта
                                  SELECT (xpath('/value/text()',data))[1] FROM xmltable where cast((xpath('/value/text()',xml_column))[1] as text) like '%ab%';
                                  и индекс соответсвенно:
                                  CREATE INDEX i_zzz ON xmltable USING btree(cast((xpath('/value/text()',xml_column))[1] as text));
                                  только это никак не помогает в like запросах
                    +2
                    — Слон полосатый, редкий, очень любит рыбий жир, при звуках флейты — теряет волю… ©
                      0
                      Сколько можно об одном и том же? Уже как минимум третий пост про постгрю.
                        +1
                        а где первые два?
                          –1
                          Один пост автор убрал, потому что был вторым и его начали жестоко минусовать. Второй вот. Вот тут про справочник для 8.3.

                          Надоело читать повторы, уже в помойку Хабр превратили. Пользуйтесь поиском.
                            0
                            ну, блог "я умный", видимо, не лучшее место.

                            а справочник не в тему, это не объявление о выходе.

                            моя статья о новинках 8.3 тут была ещё в октябре, её вы почему не вспомнили? ;-)
                              +1
                              Потому что она ваша :)
                              0
                              Автору того поста подкинул кармы. Подкиньте кто-нибудь ещё, чтобы в будущем постил в правильные блоги и дублей становилось меньше ;-)
                                0
                                какое неприкрытое лобби, ай-яй-яй! )
                                +1
                                Справочник, как и этот пост, опубликован в соответствующем сообществе. Если вам не нравится, как работает хабр в смысле вывода на главную тематических сообществ - жалуйтесь создателям.
                                  +2
                                  Всё, сдаюсь :)
                            0
                            А LINQ они планируют поддерживать?
                              0
                              животрепещущий вопрос, но это скорее к мелкомягким)
                                0
                                Почему же? Им нужно самостоятельно реализовать необходимые интерфейсы. Никто не будет это делать за них, тем более Microsoft.
                              0
                              Товарищи Самохвалов и Бесков проведите нам семинар по новым функциям, производительности и т.п.
                                0
                                Господа, а кто-нибудь может доступно обрисовать сравнение PostgreSQL vs MySQL?
                                    0
                                    1 - значит на маленько-средних проектах MySQL выигрывает (хотя возможно, что более глубокий тюнинг позволит выигрывать и на больших проектах с большими нагрузками)
                                    2 - аналогично
                                    3 - outdate
                                      +1
                                      Не будет он выигрывать на больших проектах с большими нагрузками на одной СУБД.
                                        0
                                        если смотреть на второй тест, то непонятно как "глубокий тюнинг позволит выигрывать".
                                        более чем в 10 раз разогнать не получится)
                                          0
                                          Там разница всего в 2 раза при максильном конкуренси.
                                          Опять же, тесту больше 1 года уже...
                                            0
                                            ой. извиняюсь. я о первом
                                            http://wiki.sysfaq.ru/wiki/MySQL_vs_PostgreSQL

                                            5.0.32-Debian_3-log vs PostgreSQL 8.1.8 on i486-pc-linux-gnu
                                            в PostgreSQL может и есть изменения, но в MySQL я не замечаю никаких изменений в сторону увеличения производительности (з.ы. сам пока юзаю MySQL)
                                              0
                                              Этот тест у меня вызывает сомнения если честно.
                                              Я вот тоже нашел "MySQL Beats Sybase and PostgreSQL in Throughput and Power Efficiency", но к сожалению будут перетестровать, так как из Sybase пожаловались =)

                                              http://www.worlds-fastest.com/wfz988.html
                                                0
                                                Могу здесь сказать только одно: в постгресе с времен 8.1.8 произошли без преувеличения гигантские изменения в сторону улучшения производительности, читайте хотя бы описание этого релиза, даже опуская новшества версии 8.2.
                                            +1
                                            Если в проекте нужны транзакции (практически в любом проекте с ненулевой надежностью они нужны), то PostgreSQL обгоняет MySQL по скорости на любых размерах, начиная с небольших проектов и кончая гигантскими вроде Skype.
                                              0
                                              imho, не так всё просто. хватает примеров огромных проектов, отлично чувствующих себя на MySQL (те же гугл, яху).
                                                0
                                                да, конечно, вы правы.
                                                полно вполне нормальных ситуаций, когда даже и транзакции-то не нужны: например каунтеры li.ru работают на MySQL, потому что ценности в информации об одном из сотен миллионов кликов в сутки нет никакой. но если нужна mission critical запись в БД, с MySQL не все так радужно по общему мнению.
                                        0
                                        А правдо ли что с мускула можно безболезнено перейти на постгрес?
                                        А вот на ораклы и другие сайбезы точно низя( нету оператора LIMIT, то да се, так да сяк )
                                          0
                                          Истинная правда
                                          http://www.postgresql.org/docs/techdocs.…
                                            0
                                            Если есть уже готовый проект, "заточенный" под MySQL, то безболезненно - не получится.
                                            Взять всё те же ENUM, SET, inet_aton/inet_ntoa, INSERT DELAYED, password, etc, etc.
                                              0
                                              совсем безболезненно не получится, но усилия стоят того — проверено на личном опыте, мигрировали живую production-систему.
                                                0
                                                Опыт и у меня есть, благодаря ему я дождусь 8.3.4, прежде чем что-то предпринимать. :-) А усилия действительно стоят того.
                                                0
                                                всё, что перечислено в этом небольшом списке, — не проблема, всё делается легко
                                                  –1
                                                  Также, как и здесь? :-)
                                                    +1
                                                    не совсем понятно, причем здесь дискуссия на sql.ru о том, как правильно пиарить PostgreSQL и решения на его основе?
                                                      –1
                                                      PostgreSQL или postgresmen?
                                                        +1
                                                        PostgreSQL. Причем здесь вообще Постгресмен?
                                                          0
                                                          При том, кто есть samokhvalov, и его "всё делается легко". Видимо, по ссылочке вы бегло прочитали.
                                                            0
                                                            если что, то в той дискуссии iz — это я :)
                                                              0
                                                              Нет привычки в профайлы смотреть. Тогда, конечно, всё решительно меняет дело. :-)
                                                  +1
                                                  ENUM в 8.3 как раз сделали.
                                                  INSERT DELAYED можно заменить на использование асинхронных транзакций достаточно безболезненно.
                                                    0
                                                    ENUM, несмотря на его очевидные преимущества, мягко говоря, не совсем тот, к которому привыкли пользователи MySQL.

                                                    Речь всё-таки о:
                                                    » А правдо ли что с мускула можно безболезнено перейти на постгрес?

                                                    А теперь представьте, что по старой привычке у Вас полмиллиона запросов, разбросанных по многочисленным клиентским и т.п. приложениям выбирает enum-значения по их целочисленному индексу.
                                                      0
                                                      Насчёт реализации ENUM'а не вникал, спасибо за инфу - посмотрим.
                                                      А насчёт запросов enum по целочисленному значению, да ещё и по всему проекту - редкостное извращение - зачем енум-то в таком случае :)
                                                0
                                                давно мучаюсь. как невыговариваемое название PostgreSQL принято произносить по-русски? =)
                                                  0
                                                  ПоустгрэЭсКьюЭл?
                                                    0
                                                    неправильно

                                                    Постгрес-Ку-Эл

                                                    а лучше просто Постгрес
                                                      0
                                                      http://www.postgresql.org/files/postgresql.mp3
                                                      0
                                                      это транскрибирование с английского, всё также невыговариваемое по-русски :)

                                                      остановился на: "постгр'ескул" ^_^ (post-grEs-cool)
                                                    0
                                                    такс... Энто хорошо... бум обновлять сервак :)
                                                      0
                                                      Все приемущества слона грубо обрываются на том что его мало где найдёшь на хостингах да и движки в бОльшем случае юзают мускуль :)
                                                        +1
                                                        Хорошие движки поддерживают PostgreSQL, потому что поддерживать его легко. Что касается хостинга — то да, с ним есть проблемы. Но ситуация меняется в лучшую сторону, потому как спрос на постгрес растет неуклонно.
                                                        • НЛО прилетело и опубликовало эту надпись здесь
                                                            0
                                                            Вопрос - какие CMS используют постгрис - особенно про OpenSource интересует
                                                              0
                                                              На чем должна быть написана CMS? Сходу назову не CMS, но тоже "движки" на постгресе: MediaWiki (см. wikipedia.org), Serendipity (blog engine), CakePHP (CMF)
                                                                +1
                                                                drupal, mediawiki
                                                                  0
                                                                  маловато... тем более DB инджил прикрутили в 5,2 пора бы его уже поприменять
                                                                    0
                                                                    скажите, что вам нужно и решение найдется. если гуглить, продуктов будет более чем достаточно даже для предвзятого пользователя.
                                                                      0
                                                                      Вы меня не правильно поняли , я просто сказать хотел что при всей своей крутости и тд база используется маловато :( интересны причины
                                                                        +1
                                                                        Причины: миф о легкости и лучшей производительности MySQL, за которой стоит коммерческая компания с ее рекламными бюджетами, способствует тому, что новички с их нетребовательными приложениями на нее подсаживаются, не подозревая о том, что есть лучшая альтернатива. Вот и юзают 80% малоопытных пользователей MySQL, создавая много шума по этому поводу. Оно может для них и лучше, спорить не буду, но если вы считаете, что попадаете в 20% более продвинутых, то по крайней мере необходимо осознавать, что к чему в мире СУБД. Впрочем, и для новичков, изучающих SQL, лучше начинать не с диалекта MySQL и не ACID-совместимого продукта, а с гораздо более стандартного и ACID-совместимого PostgreSQL.
                                                                          0
                                                                          А что же постгрис ? что за ним кроме крутости ? Многие проекты были лучшее чем что то но канули в лету
                                                                  +1
                                                                  Не CMS, но поддерживается Django-й
                                                                    0
                                                                    Тогда и qt ;)
                                                                      0
                                                                      и RoR-ом
                                                                0
                                                                Интересно было бы найти желающих провести собственное тестирование. Например у меня есть Mysql на таком то сервере, у кого то есть Postgre. Давайте составим проверочную структуру данных и потестим.
                                                                  0
                                                                  сильно грубо будет. нужно на одном и том же сервере тестить.
                                                                  с одним и тем же наполнением БД
                                                                    0
                                                                    Именно такой ответ и ожидал :) Думаю не скоро мы найдём желающего, с двумя обеими установленными БД (и временем для тестов). Можно пробовать и на разных (однозначно с одинаковой структурой и наполнением ДБ). Если до сих пор сохраняется такая "разительная" разница в производительности как в старых сравнительных тестах, то это и так будет понятно, а если получим что-то схожее будем делать поправку на аппаратное обеспечение или может и не прийдётся ;)
                                                                      0
                                                                      Результаты подобных тестов (с различающимся оборудованием, но с одинаковыми схемами БД и данными) были опубликованы летом 2007-го. Причём очень на высоком уровне, тестировали инженеры Sun на протяжении многих месяцев.

                                                                      http://postgresmen.ru/news/view/44

                                                                      Это самое лучшее, самое серьёзное сравнение различных СУБД на сегодняшний день. Даже с учётом того, что оборудование было разным.
                                                                        +1
                                                                        Дельная ссылка. Спасибо.
                                                                        Вопрос само собой разумеется закрыт.
                                                                      0
                                                                      Я не считаю это тестирование правильным и точным.
                                                                        +1
                                                                        Тока укажите критерии тестирования. Я работал и с MySQL и с PostgreSQL. Из моего опыта работы следует, что PostgreSQL работает стабильнее и быстрее на больших объемах данных и при количестве операций ввода-вывода с двадцати и более. Кроме этого PostgreSQL тюнить надо существенно меньше по сравнению с MySQL. Стабильная работа MySQL наблюдается только на InnoDB. MyISAM будет более менее работать только при распределении профиля нагрузки между двумя серверами (один на чтение, второй на запись).
                                                                          0
                                                                          MyISAM - сам по себе формат не предполагает одновременную запись и чтение (ввиду отсутствия в нем транзакций). Чтобы использовать сервер баз данных на полную
                                                                          , нужно хорошо разбираться в принципах его функционирования (думаю это касается любого сервера БД).
                                                                          P.S. обратите внимание на http://blogs.ittoolbox.com/database/soup/archives/postgresql-publishes-first-real-benchmark-17470
                                                                          "This publication shows that a properly tuned PostgreSQL is not only as fast or faster than MySQL"
                                                                          Люди не кричат что наше сервер БД быстрее всех, а весьма осторожно - "не медленнее, а может и быстрее"
                                                                            0

                                                                            MyISAM - сам по себе формат не предполагает одновременную запись и чтение (ввиду отсутствия в нем транзакций).

                                                                            Вообще СУБД как раз таки подразумевает наличие одновременного чтения и записи.


                                                                            Чтобы использовать сервер баз данных на полную, нужно хорошо разбираться в принципах его функционирования

                                                                            Я вполне разбираюсь как работает MySQL, но от этого он быстрее и стабильнее чем PostgreSQL вести себя не начинает.


                                                                            Люди не кричат что наше сервер БД быстрее всех, а весьма осторожно - "не медленнее, а может и быстрее

                                                                            Я вообще-то указывал при каких условиях MySQL менее производителен. В тесте так же указано как и что тестировалось. Можете проверить результаты.
                                                                              0
                                                                              Я вовсе не собирался спорить и утверждать, что MySQL лучше или хуже PostgreSQL. Просто считаю, что не имеет сравнивать производительность плоско (одни и те же структуры данных одни и те же запросы). К этому нужно подходить более гибко, то есть ставить задачу: такой то набор данных, такая то задача по выборке и обновлению. После чего уже писать под каждую БД свою структуру и свои запросы, и уже тогда сравнивать производительность по скорости выполнения самой постановочной задачи. Так ИМХО будет более точно (недаром инженеры сан потратили на тестирование несколько месяцев, а не дней), и результаты будут не такими однозначными.
                                                                                0

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

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


                                                                                После чего уже писать под каждую БД свою структуру и свои запросы, и уже тогда сравнивать производительность по скорости выполнения самой постановочной задачи.

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

                                                                                PS Да MySQL может дать большую производительность при определенных условиях. Но это обычно требует дополнительных шаманств.
                                                                    0
                                                                    немного занудства: всегда думал что СУБД мужского рода - все-таки сервер, а не женского
                                                                      0
                                                                      Ошибаетесь. Система.
                                                                      0
                                                                      После безапелляционной фразы "... лучшей СУБД в мире ..." остальное читать даже не хочется. Хоть бы улыбочку какую поставили. Детский сад, штаны на лямках, ей Богу!
                                                                        0
                                                                        По многим показателям действительно лучшая. Вам сюда: http://www.postgresql.org/about/
                                                                        А мою заметку, конечно, не читайте, если нет желания.
                                                                          0
                                                                          С учётом инфы по ссылке "лучшей СУБД для Линукс" (особенно с самой ссылкой в сноске) звучало бы уже вполне корректно.
                                                                          В целом статья полезная, но вот такое вступление ИМХО вызывает отторжение у людей с другими предпочтениями. Вы ведь не хотите, чтобы PostgreSQL стала закрытым фан-клубом? :)
                                                                          –1
                                                                          +1

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

                                                                        Самое читаемое