Комментарии 7
Подскажите, а BiHA (или какие-то другие механизмы Postgres Pro) поддерживает такой вариант использования ?
Приложение создает соединение к БД (узлу-последователю), которое используется только для чтения, НО создает, модифицирует и использует временные таблицы в течении какого-то времени. Потом (когда пользователь нажал Сохранить), необходимо все эти временные таблицы перекинуть на узел-лидер и там начать транзакцию, которая уже будет править основные таблицы, используя данные из временных таблиц. Хотелось бы конечно, чтобы это делалось "прозрачно" самим кластером (например, по получению команды начать транзакцию), но даже если нет, чтобы можно было бы на уровне подключения указывать он read-only или нет, и иметь возможность перекидывать временные таблицы между соединениями.
Часто слышу от коллег на работе, что пока они не готовы перевезти BI с Oracle на Postgres Pro, в силу того, что на том же железе (правда оно у оракла свое - экзадата) близкий результат от postgres не получить. Будет интересно почитать профессиональный анализ текущего состояния обоих база данных. А так же чего не хватает postgres, чтобы серьезно подвинуть Oracle в крупных инсталляциях, например банках.
А причем здесь BI ? Для BI есть свои СУБД, оптимизированные под массивное чтение и bulk-запись. Или речь все-таки про OLTP системы ?
Но тут у PostgreSQL все не так уж и плохо. У нас есть клиенты из розничной торговли с OLTP-системами на 3.000 одновременно работающих пользователей, с таблицами по миллиард записей и 6ТБ БД. И это все без какой-либо кластеризации на обычном двух-процессорном сервере (с 96 ядрами и 512ГБ памяти) и SSD. И это даже не Postgres Pro (а ванильный PostgreSQL).
Конечно, все зависит от запросов, и мы занимаемся их оптимизацией. Но, если нормально использовать, то в очень большом количестве приложений можно заменить Oracle на PostgreSQL. Понятно, что процессинг транзакций в банках - это целая отдельная сфера применения СУБД, но в общем числе задач она не значительна. И в банках во многих задачах можно без проблем использовать PostgreSQL вместо Oracle.
Ситуация на данный момент такова, что абсолютное большинство (если не все 100%) банков и страховых в стране сидят на Oracle так плотно, насколько это только возможно. Включая сам ЦБ.
Что касается железа, кластера измеряются сотнями ядер, про диски и память я даже писать не буду.
Из того, что я знаю, а я не профессионал в этой области, там:
нет компиляции pg_sql, а только интерпретация
нет встроенного шедулера, предлагается использовать средства ОС
нет пакетов
нет автономных транзакций
Я поэтому и спросил у компании Postgres Pro какие проблемы в миграции клиентов с Oracle они видят, в части возможностей самой СУБД и как их решают.
Я думаю, что главная проблема в логике клиентов. "Не трогай, пока работает". Понятно, что миграция в любом случае создаст проблемы. Вне зависимости от того, справится ли PostgreSQL с этими задачами или нет.
И на SAP подавляющее большинство продолжает работать и будут дальше работать. Просто так исторически сложилось, а не из-за каких-то технических вопросов. Зачем что-то менять, пока петух не клюнул ?
Алилуйя! Обещают возможность создавать триггеры на события ON LOGIN (правда не увдел LOGOFF - хотя он и менее полезен)
Буду ждать еще фичи:
Пакетов как в Оракле (но не через схемы как postgres.pro). Ну пожалуйста ...
Автономных транзакций (но не через dblink)
И встроенный шедулер я тоже хочу (я знаю про pg_cron и т.п.)
На этом, мой список фич из Oracle 8i (1998 год) почти закончен (хотя встроенные аналоги AWR и ADDM я бы с удовольствием увидел. Да, можно Zabbix прикрутить, но я лучше просто помечтаю :) ).
Postgresso 12 (61)