Представлена (http://permalink.gmane.org/gmane.comp.db.postgresql.announce...) вторая бета-версия СУБД PostgreSQL 9.1 (http://www.postgresql.org/docs/9.1/static/release-9-1.html), в которой продолжена работа по выявлению и исправлению ошибок. Набор новшеств уже сформирован и до выпуска релиза меняться не будет. Релиз PostgreSQL 9.1 ожидается в течение лета.
Из ключевых улучшений PostgreSQL 9.1 можно отметить:- Поддержка синхронной репликации (http://developer.postgresql.org/pgdocs/postgres/warm-standby...), при которой запасной сервер (standby) будет содержать гарантированно совпадающие с основным сервером данные - до получения подтверждения записи синхронизированных данных транзакция не будет считаться завершенной. Ранее репликация на запасной сервер осуществлялась только в асинхронном режиме. Синхронную репликацию можно применять для отдельных транзакций, что позволяет комбинировать оба механизма, используя по умолчанию быстрый асинхронны...
URL: http://permalink.gmane.org/gmane.comp.db.postgresql.announce...
Новость: http://www.opennet.me/opennews/art.shtml?num=30860
Интересуюсь таким вопросом: могут ли разработчики составить список основных преимуществ СУБД 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-запросов.
На сколько тут можно что-то ожидать и в каком обозримом будущем?
Я могу быть не прав, но возможно, основное преимущество Oracle не в самой СУБД, а в сопутствующем энтерпрайз ПО, например, возможности создания отчетов. Те кто выбирают БД Oracle делают это не потому, что это самая качественная БД, а потому что есть весь стек технологии.
> Я могу быть не прав, но возможно, основное преимущество Oracle не в
> самой СУБД, а в сопутствующем энтерпрайз ПО, например, возможности создания отчетов.
> Те кто выбирают БД Oracle делают это не потому, что это
> самая качественная БД, а потому что есть весь стек технологии.Не уверен, бизнес-продукты от Oracle - это отдельный софт, стоящий отдельных денег и которые по популярности не всегда в лидерах по использованию в мире. Например мегапопулярная в мире SAP - использует СУБД Oracle, но может использовать и другие СУБД.
1) http://en.wikipedia.org/wiki/Comparison_of_relational_databa...4) С версии 9.0 умеет асинхронно. С версии 9.1 - синхронно, читать новость надо :)
А здесь http://enterprisedb.com/ вам ответят более компететно
> 1) http://en.wikipedia.org/wiki/Comparison_of_relational_databa...Спасибо за ссылку. Но, к сожалению, по информации в ней нельзя ответить на мои вопросы (но можно прояснить другое, спасибо)...
> 4) С версии 9.0 умеет асинхронно. С версии 9.1 - синхронно, читать новость надо :)
В моих вопросах не было слов "асинхронно" или "синхронно". Могу уточнить свои вопросы - все относятся к синхронному, гарантированному режиму.
> А здесь http://enterprisedb.com/ вам ответят более компететно
Спасибо.
1. Есть, но немного не полное. Придется поиграться с наследованием таблиц, тригерами и включить constraint_exclusion (подробнее в мануале - http://www.postgresql.org/docs/current/static/ddl-partitioni...)
2. Подозреваю что нет. Если кто-то знает как это сделать - просветите плиз.
3. Репликация, не?
4. См. коммент zet-a
> 1. Есть, но немного не полное. Придется поиграться с наследованием таблиц, тригерами
> и включить constraint_exclusion (подробнее в мануале - http://www.postgresql.org/docs/current/static/ddl-partitioni...)
> 2. Подозреваю что нет. Если кто-то знает как это сделать - просветите
> плиз.
> 3. Репликация, не?
> 4. См. коммент zet-aБольшое спасибо за информацию!
1. нет (будут писать некоторыые что можно через зранимки, но это всё фикция для небольшого кол-ва конфигураций),
2.нет,
3. standby, streaming replication,
4. см 3,
4.2 афаик нет> На сколько тут можно что-то ожидать и в каком обозримом будущем?
1. будет
> 1. нет (будут писать некоторыые что можно через зранимки, но это всё
> фикция для небольшого кол-ва конфигураций),
> 2.нет,
> 3. standby, streaming replication,
> 4. см 3,
> 4.2 афаик нет
>> На сколько тут можно что-то ожидать и в каком обозримом будущем?
> 1. будетСпасибо, я чуть выше еще прокомментировал, здесь не буду дублировать написанное другим товарищам (всем большое спасибо).
> 1) Есть ли у PostgreSQL секционирование?что такое "секционирование" ?
http://www.postgresql.org/docs/current/static/manage-ag-tabl... ?
или
http://www.postgresql.org/docs/current/interactive/ddl-parti... ?
> 2) Можно ли так сконфигурировать PostgreSQL, чтобы под OLTP ГАРАНТИРОВАННО отводилось например 20% ресурсов, оставшиеся можно использовать под сложные запросы?нет.
> 3) Какие возможности есть в плане High Available?
есть разные способы реализовать HA. самый наглядный можно посмотреть в статье про архитектуру skype.
> 4.1) Передавая по локальной сети текущие журнальные изменения у себя (в сжатом виде)
да. это стандартная репликация.
> 4.2) Передавая по локальной сети непосредственно SQL-команды
да. slony.
4.1 и 4.2 одновременно не бывает, впрочем.
> что такое "секционирование" ?Эта ссылка:
> http://www.postgresql.org/docs/current/interactive/ddl-parti... ?
>> 3) Какие возможности есть в плане High Available?
> есть разные способы реализовать HA. самый наглядный можно посмотреть в статье про
> архитектуру skype.High Available реализуется через все ниже перечисленное вместе:
1) Агентов, которые инсталлируются на отдельных нодах. Они информируют какую-то "общую серверную часть" - что у них и как. При отсутствии связи с одним из агентов - нода считается вышедшей из строя.
2) Общая серверная часть, получающая информацию от всех нод.
3) GUI для управления общей серверной части. Позволяет выводить некоторые ноды на тех. обслуживание (отключать, включать), управлять группами нод, показывать информацию о рабочей нагрузке в каждой ноде и т.д. и т.п.
Общая серверная часть может автоматически синхронизировать данные в разных нодах и автоматически перенаправлять трафик с ноды, вышедшей из строя, на доступные ноды.
Можно "самописно" попробовать реализовать все вышеперечисленное, а можно получить инсталляцию всего этого - "из коробки". В последнем случае имеем систему патчей, которые тестируются на множестве систем, что в самописном варианте не бывает из-за отсутствия ресурсов/возможностей. Конечно если речь не идет о мегакорпорациях, которые зачастую реализуют самописные решения и потом иногда делятся ими с сообществом.
Но и в этом случае изначально самописное решение - решало определенные задачи компании, заимствовало определенные сторонние решения, поэтому может накладывать определенный отпечаток на конечный продукт, заточенность и протестированность на отдельных проприетарных технологиях или в принципе невозможность/нецелесообразность из-за вышеперечисленного - открыть продукт. Разве что только в целях продвижения в качестве стандарта в какой-то области или попытке обеспечить массовость возможно умирающей собственной технологии.
Поэтому целенаправленное развитие какой-то возможности в составе базового продукта или отдельных его компонентах - несомненно (при прочих равных) является лучшим решением.
Кстати, я немного тестировал одно _универсальное_ High Available решение. Там есть основная требуемая функциональность в виде системы агентов, общей серверной части, возможность удаленного запуска скриптов через агенты и некоторые другие вещи. Нужно "допилить под себя" GUI (плагинная архитектура существенно упрощает этот процесс). Разработка опенсорсная (JBoss). Есть платный аналог, от Red Hat (ситуация как со взаимоотношением Fedora и RHEL, хотя на лично мой взгляд - в данном случае отличие не такое существенное, хотя я и тестировал/разбирался со всем мало).Но как бы то ни было - в любой СУБД есть внутренний API, есть внутренние алгоритмы, оптимизированные для узкоспециализированных моментов. В том же Oracle через определенный интерфейс программирования - можно запрограммировать на С/С++ дополнительную функциональность для High Available, которую хочет именно ваша компания (помимо того, что есть вся функциональность "из каробки").
Вполне возможно, что "заточенное" решение даст от 20% и выше процент ускорения по производительности, реагированию, обработке ситуаций, динамической смене алгоритма, учет имеющихся индексов, какие-то варианты балансировок - вот на допил этого, в промышленной среде - могут уйти годы (просьбы внести оптимизационные патчи в основную ветку СУБД, обсуждения, конференции, тестирование).
- Прерогатива разработчиков СУБД заниматься этим, по моему.
О, predicate locking это здорово. Я так понимаю, теперь в режиме serializable serialization failure все равно будет, но на сразу перед началом выполнения транзакции, а не где-нибудь посередине?
какой смысл выбрасывать экспепшен вначале транзакции? Должно быть ожидание блокировки.
Потому что сериализация. Чтобы как раз не было ожидания блокировок.
сериализация это немного другое
А какой смысл в ожидании блокировки в начале транзакции? Раньше, до 9.1, если какие-то данные залочены в начале ли, или где-то посередине транзакции, другой транзакцией, транзакция вываливалась с serialization failure. По идее теперь с предикатными блокировками, такое будет происходить только в начале транзакции. Или как?
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" как средство инкрементного бэкапа лучше не заикаться).
> так сказать, "by design" инкрементные бэкапыерунду то писать не нужно. Есть pg-rman, нет никакой проблемы "by design"
http://code.google.com/p/pg-rman/wiki/readme
Хорошая вещь. Но это надстройка, не меняющая сути. Для "Recovery to Point-in-Time" предлагается что бы Вы думали? Правильно, http://developer.postgresql.org/pgdocs/postgres/continuous-a...
Таким образом, дизайн остается как есть, а как есть все транзакции со всех БД постгря валит в один несчастный wal, со всеми вытекающими в виде невозможности использования схем "Full+Inc|Dif" для отдельной БД.Для расширения кругозора попробуйте сравнить схему хранилища постгри с любой "серьезной" пропьетарщиной на рынке: Oracle, M$ (бывший Sybase, если правильно помню), IBM DB2 (ага, еще живой).
> Для расширения кругозора попробуйте сравнить схему хранилища постгри с любой "серьезной" пропьетарщиной на рынке: Oracle, M$ (Вы лучше вначале сами узнайте как же PITR работает во всех перечисленных продуктах. По секрету скажу, работает через те же самые редо (~WAL) логи. А почему именно так - учить мат. часть.
> Таким образом, дизайн остается как есть, а как есть все транзакции со всех БД постгря валит в один несчастный wal, со всеми вытекающими в виде невозможности использования схем "Full+Inc|Dif" для отдельной БД.
Чушь. В PG принципиальный дизайн точно такой же, как и во всех остальных СУБД. Постарайтесь таки посмотреть что делает pg-rman.
> Но это надстройка, не меняющая сути.
Это пока стороний (а не надстройка) для PG продукт. Тут стоит посмотреть как многие из существующих фич в PG пришли из точно таких же стороних разработок.
> про "wal" как средство инкрементного бэкапа лучше не заикатьсяА что есть другие способы?
> стали ругаться на неопределенностьЭто не регрессия, а защита от дурака. Выражение where v.t = t неоднозначно по определению и не нужно его пытаться интерпретировать.
> Это не регрессия, а защита от дурака. Выражение where v.t = t
> неоднозначно по определению и не нужно его пытаться интерпретировать.А по-моему однозначно, т.к. в объявлении функции я явно определил "t" в качестве аргумента, соответственно наверное знаю, что делаю. Восьмерка при этом определяла что-то типа "t := $1" и дальше пользовала "t" именно в таком качестве. Поэтому таки регрессия, т.к. отломали область имен в заголовках функций.
>Возможность исключения отражения в WAL-логе активности по отдельным таблицамОчень полезная возможность, часто бывает необходимо поработать с данными не нагружая лишней работой слейвы, вот если бы опционально на отдельные поля добавили возможность не логать изменения - было бы ещё круче )
А можно ли с этой синхронной репликацией реализовать master-master?
При которой второй сервер всего лишь в режиме ожидания и получения данных, пока жив первый, принимает на себя работу когда первый упал и когда поднялся, то отдает ему первому данные, чтобы он потом стал главным опять.
На mysql это легко делается.
мастер мастер сделать нельзя. поменять местами мастер и слейв можно как и везде.
Кто-нибудь сравнивал по производительности с 8.4?