| 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.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. будет
Спасибо, я чуть выше еще прокомментировал, здесь не буду дублировать написанное другим товарищам (всем большое спасибо).
| | |
|
| |
| 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 [^] [^^] [^^^] [ответить]
| +/– |
Потому что сериализация. Чтобы как раз не было ожидания блокировок.
| | |
| |
| |
| 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 [^] [^^] [^^^] [ответить]
| +/– |
мастер мастер сделать нельзя. поменять местами мастер и слейв можно как и везде.
| | |
|
|
