PGConf.Russia 2023

Данный доклад предназначен в первую очередь для компаний, а точнее для их ИТ служб, эксплуатирующих российские системы 1С 8.х и имеющих возможность работать как на СУБД MSSQL Server, так и PostgreSQL. Мы живем в уникальное время, когда наличие в своем арсенале гетерогенной ИТ-системы (системы, имеющей распределенную архитектуру, где каждый экземпляр базы данных работает под управлением разных СУБД и/или имеет разную структуру данных) является оправданным как с экономической точки зрения, так и с учетом возможных рисков. С одной стороны, мы храним данные и пользуемся СУБД с предсказуемым поведением и открытым кодом, независимо от политической обстановки. С другой стороны, мы при таком подходе пользуемся всеми преимуществами (в первую очередь производительности) мощной СУБД поддерживаемой крупнейшим вендором пускай и недружественного нам государства. Именно сейчас необходимо оценивать риски с необходимым уровнем паранойи. Возможно ведь, что данные могут быть испорчены не только на уровне логики хранения, но и методом дополнительного «скрытого» вызова конструкций типа Delete/Update на уровне движка СУБД. Поэтому сейчас актуальным становится не только мониторинг производительности ИТ-системы, но и аудит данных и их своевременная сохранность. Необходимо реализовывать процедуры верификации данных, необходимо реализовывать процедуры закрытия периодов, процедуры отказоустойчивого хранения. И соответственно, предусматривать в процедурах восстановления данных различные модели угроз. В докладе представлены варианты противодействия подобным угрозам и сценарии максимально бесшовного перехода больших баз данных на PostgeSQL, ведь именно для подобных баз проблема перевода на новую СУБД стоит особо остро.

Предлагается вашему вниманию наш опыт по миграции данных и написанную на Java программу Ora2PgCopy для высокоскоростного переноса данных из Oracle в Postgres, которая применяется после создания таблиц и переноса программного кода прикладных систем. Высокая скорость переноса данных обеспечивается за счёт использования Postgres-команды “copy”, применения многопоточной технологии Java для обработки файлов, управления опцией таблиц nologged/ logged, поддержки типов данных LOB и CLOB. По результатам тестов Ora2PgCopy работает заметно быстрее таких аналогов как: Ispirer (convertum), oracle_fdw, ora2pg, Pentaho kettle. Ora2PgCopy может функционировать как модуль в составе системы автоматизации миграции (САМ) LUI4ORA2PG, так и независимо от неё. С историей развития инструмента разработки web-приложений Live Universal Interface (LUI) и инструмента миграции LUI4ORA2PG, можно ознакомится по предыдущим выступлениям на конференциях PgConf: https://pgconf.ru/2019/118109, https://pgconf.ru/201911/264095, https://pgconf.ru/2020/262456, https://pgconf.ru/2021/288310,
https://pgconf.ru/2022/316022.

Импортозамещение не началось в прошлом году после всем известных событий. Его старт датируется 2014 годом. Именно с этого года государственные и окологосударственные компании начали прорабатывать вопрос перехода на рекомендованное ПО. Одна из таких компаний и обратилась к нам еще в 20-м году с проектом перехода с Oracle на PostgreSQL. Данный проект был призван решить накопившиеся архитектурные проблемы (не оптимальное хранение телеметрических данных, сама СУБД работала внутри виртуальной машины), оптимизировать использование дискового пространства (освободить основное хранилище, отладить сохранение архивных данных, обеспечить корректное резервное копирование). Так как система заказчика должна работать бесперебойно 24/7, то требовался переход с одной СУБД на другую без простоев, с одновременной работой обеих для обеспечения пошагового перевода подсистем и возможности контролировать корректность данных. И, само собой, работы нужно было завершить как можно быстрее.

В докладе расскажем, как нам удалось решить этот кейс.

Исторически PostgreSQL используется для транзакционной (OLTP) нагрузки. На это указывает строчное хранение данных и невозможность (или сложность) в организации распределённого исполнения запросов по канонам MPP (massive parallel processing) систем. Однако вследствие расширяемости ядра PostgreSQL (прежде всего, появления интерфейса подключаемых методов доступа) и либеральной лицензии (сходной с BSD) на свет появились различные форки и расширения, которые позволяют эффективно организовать обработку больших массивов данных для запросов аналитического толка.

В текущем докладе планируется дать исчерпывающий обзор форка Greenplum и расширений Citus и TimescaleDB с точки зрение разработчика по основным признакам (фичам) аналитических СУБД - колоночное хранение, сжатие данных, распределённая обработка и др. Результаты данного обзора будут полезны архитекторам, выбирающим СУБД для аналитики под свою систему.