Борьба с блоатом

Каждый администратор баз данных так или иначе сталкивался с тем, что таблицы и индексы в PostgreSQL иногда могут значительно увеличиваться в размерах. Зачастую поиск причины такого роста приводит нас к выводу, что объекты "раздулись". В докладе мы поговорим о причинах такого поведения, подготовим тестовую среду для определения того какой же метод борьбы с блоатом является самым подходящим. Сравним несколько утилит по борьбе с блоатом, а также познакомимся с ещё одним инструментом, который позволяет нам бороться с этим явлением более эффективно. Этот доклад будет полезен как начинающим, так и опытным администраторам PostgreSQL.

Как мы перевели клиента с Oracle на PostgreSQL до того, как это стало мейнстримом

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

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

Аналитические open-source решения на базе PostgreSQL

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

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

Как перенести 10Тб из Oracle в Postgres за 24 часа?

Предлагается вашему вниманию наш опыт по миграции данных и написанную на 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.