The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Вышла вторая бета-версия СУБД PostgreSQL 9.1

13.06.2011 23:50

Представлена вторая бета-версия СУБД PostgreSQL 9.1, в которой продолжена работа по выявлению и исправлению ошибок. Набор новшеств уже сформирован и до выпуска релиза меняться не будет. Релиз PostgreSQL 9.1 ожидается в течение лета.

Из ключевых улучшений PostgreSQL 9.1 можно отметить:

  • Поддержка синхронной репликации, при которой запасной сервер (standby) будет содержать гарантированно совпадающие с основным сервером данные - до получения подтверждения записи синхронизированных данных транзакция не будет считаться завершенной. Ранее репликация на запасной сервер осуществлялась только в асинхронном режиме. Синхронную репликацию можно применять для отдельных транзакций, что позволяет комбинировать оба механизма, используя по умолчанию быстрый асинхронный механизм для обычных операций и надежный синхронный для наиболее критичных изменений;
  • Поддержка указания COLLATION-свойств для отдельных столбцов, доменов, индексов и выражений, что позволяет задать для разных столбцов свои правила хранения, сортировки и сравнения с учетом указанной локали. Например: CREATE TABLE test1 ( a text COLLATE "de_DE", b text COLLATE "ru_RU"...). Ранее COLLATION могли быть указаны только на уровне БД в целом.
  • Возможность исключения отражения в WAL-логе активности по отдельным таблицам. Подобные таблицы отличаются повышенной производительностью, но могут привести к потере данных в случае краха СУБД. Для создания подобных таблиц при выполнении "CREATE TABLE" следует указать признак "UNLOGGED";
  • Реализация KNN GiST индексов (K-Nearest-Neighbor), добавляющая в GiST поддержку алгоритма оптимального поиска ближайших соседей, что может быть использовано для организации поиска географических объектов;
  • Добавлен уровень изоляции "настоящая сериализация", основанный на REPEATABLE READ (бывший SERIALIZABLE), но с перепроверкой условий запроса (predicate locking);
  • Возможность использования выражения "WITH" с операциями INSERT, UPDATE, DELETE, что позволяет осуществить рекурсивное обновление столбцов или обновление по сложному критерию, ранее требовавшему написания встраиваемой процедуры;
  • Интеграция поддержки SELinux для управления доступом на уровне объектов БД. Для привязки SELinux-меток к объектам или изменения меток следует использовать выражение "SECURITY LABEL". Пример: "SECURITY LABEL FOR selinux ON TABLE mytable IS 'system_u:object_r:sepgsql_table_t:s0';";
  • Поддержка расширений, позволяющих упростить формирование пакетов, расширяющих функциональность СУБД. Для создания расширения следует использовать новые команды "CREATE/ALTER/DROP EXTENSION". Выражения createlang и droplang, а также старые методы установки contrib-модулей, в связи с появлением расширений объявлены устаревшими;
  • Поддержка прикрепленных таблиц SQL/MED (Management of External Data), позволяющих через таблицу-враппер управлять при помощи SQL внешними данными, не хранимыми силами СУБД.

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



  1. Главная ссылка к новости (http://permalink.gmane.org/gma...)
  2. OpenNews: Вышла первая бета-версия СУБД PostgreSQL 9.1
  3. OpenNews: Вышла пятая альфа-версия PostgreSQL 9.1. Релиз DBD::PG 2.18.0
  4. OpenNews: Вышла третья альфа-версия PostgreSQL 9.1
  5. OpenNews: Вышла вторая альфа-версия PostgreSQL 9.1 и релиз MySQL Community Server 5.1.52
  6. OpenNews: Вышла первая альфа-версия PostgreSQL 9.1
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/30860-postgresql
Ключевые слова: postgresql
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (28) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.2, eugenyn (ok), 04:33, 14/06/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Интересуюсь таким вопросом: могут ли разработчики составить список основных преимуществ СУБД Oracle и создать таски "и у нас будет реализовано".

    Я вовсе не с критической стороны вопроса подхожу. И даже не знаю список основных фич PostgreSQL.

    Но я знаю, что развивать эту СУБД рекомендует создатель Java, поэтому хотелось бы знать - на сколько большой отрыв у СУБД Oracle (без эмоций), на сколько велики силы разработчиков PostgreSQL (может они и знают, что, например, хорошо бы сделать 20 таких-то вещей, да людей нет, ну и что тут делать).

    Конкретные вопросы:

    1) Есть ли у PostgreSQL секционирование?

    2) Можно ли так сконфигурировать PostgreSQL, чтобы под OLTP  ГАРАНТИРОВАННО отводилось например 20% ресурсов, оставшиеся можно использовать под сложные запросы?

    3) Какие возможности есть в плане High Available?

    4) Можно ли сделать так, чтобы одна СУБД PostgreSQL работала в обычном режиме, а рядом в локальной сети на другой машине - работала вторая СУБД PostgreSQL, при этом первая умела "накатывать" на вторую все свои данные в real time, достигая это следующими путями:

    4.1) Передавая по локальной сети текущие журнальные изменения у себя (в сжатом виде)

    4.2) Передавая по локальной сети непосредственно SQL-команды

    П.4 будет полезен например в таком варианте использования - первая СУБД PostgreSQL работает ТОЛЬКО с OLTP, вторая СУБД PostgreSQL - ТОЛЬКО для обработки сложных SQL-запросов.

    На сколько тут можно что-то ожидать и в каком обозримом будущем?

     
     
  • 2.3, crypt (??), 08:25, 14/06/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Я могу быть не прав, но возможно, основное преимущество Oracle не в самой СУБД, а в сопутствующем энтерпрайз ПО, например, возможности создания отчетов. Те кто выбирают БД Oracle делают это не потому, что это самая качественная БД, а потому что есть весь стек технологии.
     
     
  • 3.12, eugenyn (ok), 16:50, 14/06/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Я могу быть не прав, но возможно, основное преимущество Oracle не в
    > самой СУБД, а в сопутствующем энтерпрайз ПО, например, возможности создания отчетов.
    > Те кто выбирают БД Oracle делают это не потому, что это
    > самая качественная БД, а потому что есть весь стек технологии.

    Не уверен, бизнес-продукты от Oracle - это отдельный софт, стоящий отдельных денег и которые по популярности не всегда в лидерах по использованию в мире. Например мегапопулярная в мире SAP - использует СУБД Oracle, но может использовать и другие СУБД.

     
  • 2.4, zet (??), 09:43, 14/06/2011 [^] [^^] [^^^] [ответить]  
  • +/
    1) http://en.wikipedia.org/wiki/Comparison_of_relational_database_management_sys

    4) С версии 9.0 умеет асинхронно. С версии 9.1 - синхронно, читать новость надо :)

    А здесь http://enterprisedb.com/ вам ответят более компететно

     
     
  • 3.13, eugenyn (ok), 17:01, 14/06/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > 1) http://en.wikipedia.org/wiki/Comparison_of_relational_database_management_sys

    Спасибо за ссылку. Но, к сожалению, по информации в ней нельзя ответить на мои вопросы (но можно прояснить другое, спасибо)...

    > 4) С версии 9.0 умеет асинхронно. С версии 9.1 - синхронно, читать новость надо :)

    В моих вопросах не было слов "асинхронно" или "синхронно". Могу уточнить свои вопросы - все относятся к синхронному, гарантированному режиму.

    > А здесь http://enterprisedb.com/ вам ответят более компететно

    Спасибо.


     
  • 2.5, Аноним (-), 10:02, 14/06/2011 [^] [^^] [^^^] [ответить]  
  • +/
    1. Есть, но немного не полное. Придется поиграться с наследованием таблиц, тригерами и включить constraint_exclusion (подробнее в мануале - http://www.postgresql.org/docs/current/static/ddl-partitioning.html)
    2. Подозреваю что нет. Если кто-то знает как это сделать - просветите плиз.
    3. Репликация, не?
    4. См. коммент zet-a
     
     
  • 3.14, eugenyn (ok), 17:03, 14/06/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > 1. Есть, но немного не полное. Придется поиграться с наследованием таблиц, тригерами
    > и включить constraint_exclusion (подробнее в мануале - http://www.postgresql.org/docs/current/static/ddl-partitioning.html)
    > 2. Подозреваю что нет. Если кто-то знает как это сделать - просветите
    > плиз.
    > 3. Репликация, не?
    > 4. См. коммент zet-a

    Большое спасибо за информацию!

     
  • 2.6, Антоним (?), 10:22, 14/06/2011 [^] [^^] [^^^] [ответить]  
  • +/
    1. нет (будут писать некоторыые что можно через зранимки, но это всё фикция для небольшого кол-ва конфигураций),
    2.нет,
    3. standby, streaming replication,
    4. см 3,
    4.2 афаик нет

    > На сколько тут можно что-то ожидать и в каком обозримом будущем?

    1. будет

     
     
  • 3.15, eugenyn (ok), 17:04, 14/06/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > 1. нет (будут писать некоторыые что можно через зранимки, но это всё
    > фикция для небольшого кол-ва конфигураций),
    > 2.нет,
    > 3. standby, streaming replication,
    > 4. см 3,
    > 4.2 афаик нет
    >> На сколько тут можно что-то ожидать и в каком обозримом будущем?
    > 1. будет

    Спасибо, я чуть выше еще прокомментировал, здесь не буду дублировать написанное другим товарищам (всем большое спасибо).


     
  • 2.17, agent_007 (ok), 17:41, 14/06/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > 1) Есть ли у PostgreSQL секционирование?

    что такое "секционирование" ?
    http://www.postgresql.org/docs/current/static/manage-ag-tablespaces.html ?
    или
    http://www.postgresql.org/docs/current/interactive/ddl-partitioning.html ?


    > 2) Можно ли так сконфигурировать PostgreSQL, чтобы под OLTP  ГАРАНТИРОВАННО отводилось например 20% ресурсов, оставшиеся можно использовать под сложные запросы?

    нет.

    > 3) Какие возможности есть в плане High Available?

    есть разные способы реализовать HA. самый наглядный можно посмотреть в статье про архитектуру skype.

    > 4.1) Передавая по локальной сети текущие журнальные изменения у себя (в сжатом виде)

    да. это стандартная репликация.

    > 4.2) Передавая по локальной сети непосредственно SQL-команды

    да. slony.

    4.1 и 4.2 одновременно не бывает, впрочем.

     
     
  • 3.20, eugenyn (ok), 18:32, 14/06/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Эта ссылка High Available реализуется через все ниже перечисленное вместе 1 А... большой текст свёрнут, показать
     
  • 3.21, eugenyn (ok), 19:41, 14/06/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Кстати, я немного тестировал одно _универсальное_ High Available решение. Там есть основная требуемая функциональность в виде системы агентов, общей серверной части, возможность удаленного запуска скриптов через агенты и некоторые другие вещи. Нужно "допилить под себя" GUI (плагинная архитектура существенно упрощает этот процесс). Разработка опенсорсная (JBoss). Есть платный аналог, от Red Hat (ситуация как со взаимоотношением  Fedora и RHEL, хотя на лично мой взгляд - в данном случае отличие не такое существенное, хотя я и тестировал/разбирался со всем мало).

    Но как бы то ни было - в любой СУБД есть внутренний API, есть внутренние алгоритмы, оптимизированные для узкоспециализированных моментов. В том же Oracle через определенный интерфейс программирования - можно запрограммировать на С/С++ дополнительную функциональность для High Available, которую хочет именно ваша компания (помимо того, что есть вся функциональность "из каробки").

    Вполне возможно, что "заточенное" решение даст от 20% и выше процент ускорения по производительности, реагированию, обработке ситуаций, динамической смене алгоритма, учет имеющихся индексов, какие-то варианты балансировок - вот на допил этого, в промышленной среде - могут уйти годы (просьбы внести оптимизационные патчи в основную ветку СУБД, обсуждения, конференции, тестирование).

    - Прерогатива разработчиков СУБД заниматься этим, по моему.

     

  • 1.7, Forth (??), 11:37, 14/06/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    О, predicate locking это здорово. Я так понимаю, теперь в режиме serializable serialization failure все равно будет, но на сразу перед началом выполнения транзакции, а не где-нибудь посередине?
     
     
  • 2.8, Антоним (?), 12:24, 14/06/2011 [^] [^^] [^^^] [ответить]  
  • +/
    какой смысл выбрасывать экспепшен вначале транзакции? Должно быть ожидание блокировки.
     
     
  • 3.9, Forth (??), 14:38, 14/06/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Потому что сериализация. Чтобы как раз не было ожидания блокировок.
     
     
  • 4.23, Аноним (-), 20:35, 14/06/2011 [^] [^^] [^^^] [ответить]  
  • +/
    сериализация это немного другое
     
     
  • 5.27, Forth (??), 14:34, 15/06/2011 [^] [^^] [^^^] [ответить]  
  • +/
    А какой смысл в ожидании блокировки в начале транзакции? Раньше, до 9.1, если какие-то данные залочены в начале ли, или где-то посередине транзакции, другой транзакцией, транзакция вываливалась с serialization failure. По идее теперь с предикатными блокировками, такое будет происходить только в начале транзакции. Или как?
     

  • 1.10, PnD (??), 16:24, 14/06/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    1. В 9-ке регрессия парсера, однако. Функции вроде:

    create or replace function "InZone"("Region" smallint, "DEF" smallint, "Exten" int)
    returns boolean as $$
    begin
    return exists(select "Zone"."DEF" from "Zone"
            where ("Zone"."Zone"="Region") and ("Zone"."DEF"="DEF") and
                  ("Zone"."FromExten"<="Exten" ) and
                  ("Zone"."ToExten">="Exten" ) );
    end;
    $$ language plpgsql;

    стали ругаться на неопределенность, хотя 8.3,8.4 спокойно такое "проглатывали", рассовывая аргументы как положено в $1, $2 и т.д.

      2. PostgreSQL очень качественно изолировала себя то "энтерпрайза" исключив, так сказать, "by design" инкрементные бэкапы и, соответственно, возможность поднять отдельную БД на нужную точку времени. За что ей Oracle и M$ должны быть $ильно благодарны (про "wal" как средство инкрементного бэкапа лучше не заикаться).

     
     
  • 2.11, Антоним (?), 16:36, 14/06/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > так сказать, "by design" инкрементные бэкапы

    ерунду то писать не нужно. Есть pg-rman, нет никакой проблемы "by design"

     
     
  • 3.25, PnD (??), 11:24, 15/06/2011 [^] [^^] [^^^] [ответить]  
  • +/
    http://code.google.com/p/pg-rman/wiki/readme
      Хорошая вещь. Но это надстройка, не меняющая сути. Для "Recovery to Point-in-Time" предлагается что бы Вы думали? Правильно, http://developer.postgresql.org/pgdocs/postgres/continuous-archiving.html
      Таким образом, дизайн остается как есть, а как есть все транзакции со всех БД постгря валит в один несчастный wal, со всеми вытекающими в виде невозможности использования схем "Full+Inc|Dif" для отдельной БД.

      Для расширения кругозора попробуйте сравнить схему хранилища постгри с любой "серьезной" пропьетарщиной на рынке: Oracle, M$ (бывший Sybase, если правильно помню), IBM DB2 (ага, еще живой).

     
     
  • 4.28, Антоним (?), 20:52, 15/06/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Для расширения кругозора попробуйте сравнить схему хранилища постгри с любой "серьезной" пропьетарщиной на рынке: Oracle, M$ (

    Вы лучше вначале сами узнайте как же PITR работает во всех перечисленных продуктах. По секрету скажу, работает через те же самые редо (~WAL) логи. А почему именно так - учить мат. часть.

    > Таким образом, дизайн остается как есть, а как есть все транзакции со всех БД постгря валит в один несчастный wal, со всеми вытекающими в виде невозможности использования схем "Full+Inc|Dif" для отдельной БД.

    Чушь. В PG принципиальный дизайн точно такой же, как и во всех остальных СУБД. Постарайтесь таки посмотреть что делает pg-rman.

    > Но это надстройка, не меняющая сути.

    Это пока стороний (а не надстройка) для PG продукт. Тут стоит посмотреть как многие из существующих фич в PG пришли из точно таких же стороних разработок.

     
  • 2.16, Аноним (-), 17:38, 14/06/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > про "wal" как средство инкрементного бэкапа лучше не заикаться

    А что есть другие способы?

     
  • 2.18, Аноним (-), 17:55, 14/06/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > стали ругаться на неопределенность

    Это не регрессия, а защита от дурака. Выражение where v.t = t неоднозначно по определению и не нужно его пытаться интерпретировать.

     
     
  • 3.26, PnD (??), 11:45, 15/06/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Это не регрессия, а защита от дурака. Выражение where v.t = t
    > неоднозначно по определению и не нужно его пытаться интерпретировать.

      А по-моему однозначно, т.к. в объявлении функции я явно определил "t" в качестве аргумента, соответственно наверное знаю, что делаю. Восьмерка при этом определяла что-то типа "t := $1" и дальше пользовала "t" именно в таком качестве. Поэтому таки регрессия, т.к. отломали область имен в заголовках функций.

     

  • 1.19, zuborg (?), 18:23, 14/06/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Возможность исключения отражения в WAL-логе активности по отдельным таблицам

    Очень полезная возможность, часто бывает необходимо поработать с данными не нагружая лишней работой слейвы, вот если бы опционально на отдельные поля добавили возможность не логать изменения - было бы ещё круче )

     
  • 1.22, alrond (ok), 20:28, 14/06/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А можно ли с этой синхронной репликацией реализовать master-master?
    При которой второй сервер всего лишь в режиме ожидания и получения данных, пока жив первый, принимает на себя работу когда первый упал и когда поднялся, то отдает ему первому данные, чтобы он потом стал главным опять.
    На mysql это легко делается.
     
     
  • 2.24, Антоним (?), 20:36, 14/06/2011 [^] [^^] [^^^] [ответить]  
  • +/
    мастер мастер сделать нельзя. поменять местами мастер и слейв можно как и везде.
     

  • 1.29, Аноним (-), 13:47, 14/07/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Кто-нибудь сравнивал по производительности с 8.4?
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру