В эти безрадостные дни многим трудно работать, сочинять и даже читать статьи. Но ИТ-инфраструктура это как водопровод — без неё жизнь уже почти невозможна. И мы продолжаем выпускать Postgresso. По понятным причинам в этом выпуске будет много ссылок, меньше анализа. И главная тема — миграция
Миграция
Проблемы миграции с Oracle на Postgres обычно начинаются там, где приходится иметь дело с различиями в синтаксисе команд и прочими расхождениями в этих СУБД. Об этом и говорится в большинстве статей и видео.
Начнём с Oracle to Postgres Conversion
Это официальный документ сообщества PostgreSQL. Есть список инструментов миграции.
The Complete Oracle to PostgreSQL Migration Guide: Move and convert Schema, Application & Data
Довольно пространное руководство от EDB. Есть матрица возможностей миграционных инструментов.
Полуторачасовая презентация, рассказывает Пётр Петров (Postgres Professional) — очень рекомендуем. Это умелый практик и знаток нюансов миграции. Но презентация на английском.
Почему мы перешли с Oracle на PostgreSQL, и как это сделать
Эта статья 2021-го в хаброблоге Ростелекома. Их серверы на RedOS 7.2 «Муром», а СУБД брали самую свежую (на тот момент) — Postgres Pro Standard 13. Репликацию делали при помощи расширения Oracle FDW, которое поддерживает Лоренц Альбе (Laurenz Albe).
В статье разобрано немало нюансов, связанных с различиями Oracle и Postgres, но непредсказуемость ORDER BY — выделили даже в раздел Почему ваши данные скорее всего никогда не сойдутся:
«Все запросы, в которых нет order by будут выполняться „как решил сервер БД“, т.е. порядок сортировки в общем случае „не задан“. К сожалению это влияет на все, где нет ORDER BY — вывод списков с данными на фронте, вывод данных в отчетах. Да, в таких случаях хорошо бы было всегда использовать ORDER BY, но как быть в ситуациях, когда так не было изначально? Отмечать эти особенности как „не ошибка“ и комментировать различия пользователям.»
Более подробно мы говорили об этой статье в Postgresso #33.
Миграция приложения Oracle PL/SQL на Postgres pl/pgSQL: взгляд два года спустя
Доклад Анатолия Анфиногенова из АО «ВНИИЖТ» (ДЗО ОАО «РЖД») на PGConf.Russia 2021. Анатолий — заместитель директора научного центра, начальник отдела разработки программного обеспечения АО «ВНИИЖТ». Речь о большом проекте РЖД. Распределенное серверное приложение, работающее 24/7 на полигоне 16 железных дорог от Калининграда до Хабаровска плюс несколько БД центрального уровня — РЖД есть РЖД. Перенесли с Oracle 11g SE на ванильный PostgreSQL 11.9. В докладе: как переходили, с какими проблемами столкнулись при переходе и при эксплуатации, что сегодня сделали бы иначе.
Всем доступны слайды, а тем, у кого есть вход в личный кабинет участников конференции, и видео тоже.
Экстремальная миграция на PostgreSQL: без остановки, потерь и тестирования
Блог компании ЮMoney (ранее — Яндекс.Деньги, входит в экосистему Сбера). Статья 2017-го. Миграция прошла без остановки и без потерь, заняла 4 с половиной месяца усилиями 4 человек. Переносить пришлось около 50 таблиц.
Использовали SymmetricDS, но без «ручных» усилий все равно не обошлось. Инструмент миграции выбирался из такого списка (воспроизводим плюсы и минусы, кратко описанные в статье):
- Oracle GoldenGate — может показаться, что это та самая серебряная пуля. По крайней мере, до момента ознакомления с ценой.
- SymmetricDS — есть миграция схемы, она будет создана или обновлена при регистрации узла PostgreSQL в мастер-узле Oracle. Есть возможность трансформировать данные при выгрузке или загрузке, используя BASH, Java или SQL.
- Full Convert — умеет мигрировать схему и данные, но ограничены возможности кастомизации, нет изменяемых трансформеров (код для изменения данных при миграции).
- Oracle to PostgreSQL Migration — переносит схему, данные, внешние ключи, индексы. Полуавтоматическая репликация, трансформации нет, но можно задать соответствие типов в разных БД.
- ESF Database Migration Toolkit — переносит все то же, что и Oracle to PostgreSQL Migration. Данные передаются в пакетном режиме, возможность миграции в несколько потоков отсутствует.
- Ora2Pg — переносит схему, данные, внешние ключи, индексы, возможна миграция в несколько потоков. Из минусов: медленный перенос таблиц с типами blob/clob (около 200 записей/сек), нет трансформатора.
- SQLData Tool — мигрирует только схему, ограничены возможности кастомизации.
От Oracle к PostgreSQL — путь длиною в 4 года
Статья по мотивам одноименного доклада Андрея Рынкевича (Phorm) на PGDay 2017.
Немаловажная предыстория: «Как только выросло количество данных [в Oracle] и нагрузка — стало понятно, что оптимизации запросов и структуры недостаточно. Как минимум, надо было включить партиционирование, а, в идеале, надо было перейти на какое-то MPP решение, которое у Oracle стоит безумных денег: grid, RAC, Exadata.»
В результате за основу взяли PostgreSQL. Сначала запустили один мощный сервер рядом с Oracle, постепенно на него мигрировали. После собирались переходить на MPP-решение от Greenplum, но не сложилось.
Вся работа заняла 4 года. Задача усложнялась непрерывном ростом статистики и нагрузки, и тем что существует еще один продукт, который интенсивно использует БД.
Во время миграции было реализовано много решений, таких как:
- online репликация Oracle в PostgreSQL;
- система патчинга баз данных, синхронизации и запуска приложений;
- система загрузки большого объема статистических данных;
- система мониторинга, в том числе было реализовано что-то вроде Oracle Enterprise Manager для PostgreSQL;
- переход на BI систему Pentaho на этой базе данных.
История успеха «Яндекс.Почты» с PostgreSQL
Доклад Владимира Бородина (из Яндекс, не путать с его коллегой Андреем Бородиным) на Highload++ 2016. Он знакомит со сложностями миграции крупного проекта с Oracle Database на PostgreSQL. Это расшифровка доклада с конференции HighLoad++ 2016. Получасовое видео есть на youtube.
Это нешуточный проект, мягко говоря: больше 10 миллионов пользователей в сутки, более 200 тысяч запросов в секунду в пике, более 150 миллионов писем в сутки, прошедших проверки на спам и вирусы. Суммарный объём писем за все 16 лет — больше 20 петабайт.
Но речь о переезде метаданных из Oracle в PostgreSQL. Их тоже немало: больше трехсот ТБ. Более 250 тысяч запросов в секунду. В основном это маленькие OLTP-запросы, по большей части (80%) чтение.
О том, как справились, почитайте в статье. Есть там и список проблем, с которыми самим справиться не удалось. По этим вопросам пришлось обратиться к комьюнити, и комьюнити помогло. Есть и перечень того, чего в Postgres этой команде не хватает.
Миграция с Oracle на PostgreSQL при помощи Ora2Pg
Видео Клуба разработчиков СПб. Вадим Краузе, специалист-разработчик ИС делится собственным опытом миграции данных из Oracle на PostgreSQL. А также о необходимых настройках инструмента миграции Ora2Pg, ошибках и сложных ситуациях, способах их решения, производительности процесса миграции данных. Запись с 6-й конференции «Проекты, процессы и практики» Клуба разработчиков СПб ИАЦ.
Полезные скрипты при миграции из Oracle в PostgreSQL
«Процесс переноса выглядел следующим образом: создание структуры таблиц через ora2pg, исправление структуры по эталонной схеме, перенос данных, конвертация blob и Boolean, добавление отсутствующих в PostgreSQL функций (nvl, nvl2, regexp_substr), создания оставшейся структуры — индексов, view и прочего. В статье — накопившиеся за время конвертации sql скрипты для полуавтоматической миграции.»
Заодно напоминаем об интересном пакете — orafce
Это набор Oracle-совместимых функций поверх PostgreSQL. Главный разработчик Павел Штехуле (Pavel Stehule).
Он позиционируется как самый простой, безопасный способ миграции с Oracle на PostgreSQL. И с малым временем останова.
Миграция с Oracle в PostgreSQL. Как мигрировать базу данных Oracle в PostgreSQL?
Видео от Ispirer Systems. В этой презентации: как Ispirer MnMTK осуществляет автоматическую конвертацию базы данных Oracle в PostgreSQL.
Ещё там есть несколько ссылок по теме:
Миграция с Oracle на PostgreSQL — коротенький ролик об автоматизации миграции;
Oracle to PostgreSQL Migration with ora2pg — доклад на PostgresConf South Africa;
Демо миграции.
Миграция на СУБД PostgreSQL/Postgres Pro
Есть ещё PDF и видео доклада Миграция на СУБД PostgreSQL/Postgres Pro с многоядерными серверами Bull. Реальный опыт (видео только через личный кабинет участника) на PGConf.Russia 2019 Артёма Иванова и Алексея Игнатова
Интересно в том числе тем, что здесь касаются сложного вопроса: PostgreSQL и многоузловые NUMA-сервера (Артём Иванов представлял Atos, Алексей Игнатов в то время работал в Postgres Professional). Они рассказывают об опыте стрессового тестирования PostgreSQL и Postgres Pro на BullSequana S и Bullion S. В Postgres Professional делали некоторые доработки (патчи) специально на случай NUMA. Вообще на эту тему советуем почитать здесь: Параллелизм в PostgreSQL: не сферический, не конь, не в вакууме.
Oracle to PostgreSQL Migration Tutorial part 1 и part 2
Видео мастер-класса Альваро Эрнандеса (Álvaro Hernández Tortoza) на PGConf.Russia 2019. Впрочем, это скорее 3-часовой доклад. Важно, что он основан на собственном опыте: переносе софта мессинджера BlackBerry (BBM) с 150 млн пользователей, который был на Oracle на серверах DC самой компании BlackBerry. А переехал на PostgreSQL в облачную инфраструктуру. На youtube есть только 1-я часть. Обе части есть на сайте конференции, но там видео доступно только через личный кабинет.
Статья 2020-го года от InfoWatch, в которой показывается перенос небольшой схемы (15 Гбайт) с Oracle 11.2.0.4 на Linux Redhat 6.8 в Postgres 9.4 на Windows — нечастый случай переезда на Postgres под Windows, да ещё и с Linux.
Миграция с MS SQL
Миграция OLTP с MSSQL на PostgreSQL
Это ссылка на PDF-презентацию, есть и 40-минутное видео. Кристина Кучерова из Distillery рассказывает не только о том, как надо, но и о собственных ошибках (в презентации раздел Грабли).
Миграция с DB2
Миграция БД больше 10Тб с DB2 на PostgreSQL без простоя БД
Рассказывает Дмитрий Погибенко (НИИ Восход). Это ссылка на видео, а здесь тезисы.
Да, случаются ещё миграции и с DB2. Среди сложностей, о которых рассказывается в этом видео, были: необходимость трансформации данных из-за отличий между DB2 и PG и перемещением BLOB'ов в Ceph. Решали миграционные задачи так:
- отслеживая изменения с помощью триггеров;
- анализируя зависимости с помощью доработанного SchemaSpy;
- переносили с помощью Spring Batch;
- разбиение на секции (два подхода: 1. деление диапазона id между min и max на равные части и 2. деление на диапазоны с равным числом строк).
Ещё
Пользовательские агрегатные и оконные функции в PostgreSQL и Oracle
Не о миграции, но при миграции может пригодиться. В этой статье Егора Рогова в двух системах создаются пользовательские агрегатные и оконные (в терминологии Oracle — аналитические) функции. Несмотря на различия в синтаксисе и в целом в подходе к расширяемости, механизм этих функций очень похож. Но и различия тоже имеются.
Но не менее полезна может оказаться другая статья Егора, которая фокусируется на серьёзнейшем архитектурном отличии Oracle от Postgres: Обработка запросов в Oracle и PostgreSQL: следствия одного решения
Oracle использует глобальный кэш разобранных запросов, а Postgres сохраняет запросы локально. Из разницы в этом принципиальном архитектурном решении логически следует совершенно разная идеология работы в запросами в этих двух СУБД.
Zero-downtime schema migrations in Postgres using Reshape
О миграции, хотя и не с Oracle: статья этого года Фабиана Линдфорса (Fabian Lindfors), который и создал расширение reshape. У него статус экспериментального, для промышленной эксплуатации автором не рекомендовано, но стоит обратить внимание. Фабиан делал Reshape для миграции (PG -> PG) без останова. Reshape в каждый момент времени убеждается, что доступны и старая, и новая схема. Это даёт возможность разворачивать миграцию постепенно. Все изменения делаются так, чтобы избежать лишних блокировок. Работает начиная с PostgreSQL 12.
Сейчас доступна версия reshape 0.5.1
В ней исправление багов. А вот в тоже недавней 0.5.0 немало нового:
- добавлена возможность
remove_foreign_key
; - переменные окружения для соединения автоматически загружаются из
.env
-файла, если он есть; - Reshape можно будет использовать без времени простоя для уже существующих приложений и баз данных;
- введён таймаут для блокировок в случае, когда блокировка может вызвать остановку; перед следующей попыткой получить блокировку должна пройти секунда;
- автоматически возобновляются попытки запросов при ошибках (например, ошибках соединений);
- добавлены переменные окружения для всех опций соединения; переменная POSTGRES_URL переименована в DB_URL;
- добавлен флаг
--version
при котором распечатывается текущая версия.
migra — инструмент для сравнения схем баз данных PostgreSQL, представляет собой CLI и Python-библиотеку. Предназначен для автоматизации изменений. Разработчик — DatabaseCI, Австралия. По отзывам довольно необычный и удобный интструмент.
ARM и Postgres
Тема очень актуальна. Сейчас многие пробуют, например, Байкал-М, работающий на ARM. Но мы здесь не касаемся производительности и архитектуры Байкалов. Только о том, как он работает с PostgreSQL.
Тема началась давно. Вот, например, статья 2017-го года:
Running Production PostgreSQL Systems On ARM Architecture
Это любопытный проект, поддержанный Евросоюзом: Modular Microserver Data Centre. Железо на базе 4-ядерных 2.2GHz Tegra (то есть ARM+GPU) от Nvidia. Соответственно, использовалось расширение PG-Strom. Автор — Каарел Моппел (Kaarel Moppel, старший консультант Cybertec) — выложил и PDF.
Опыт тестирования PostgreSQL 13 на ARM-серверах HUAWEI TaiShan 200
Свежая статья от самой Huawai, автор — пре-сейлз Вадим Суфияров. Настройка, оптимизация, pgbench, сравнение с архитектурой x-86.
Выводы: Производительность системы зависит от используемого оборудования, операционной системы и базового программного обеспечения. На это также влияет общий дизайн каждой подсистемы, используемые алгоритмы и настройки компилятора.
Основываясь на результатах текущего тестирования с синтетическими данными, мы можем сделать вывод, что серверы могут использоваться в качестве высоконагруженных узлов PostgreSQL и способны выдать производительность не ниже, чем аналогичные платформы x86. В среднем производительность сервера на платформе ARM выше аналогичной конфигурации на платформе x86 на уровне 10-15%.
PostgreSQL on Oracle free tier ARM
Швейцарец Франк Пашо (Franck Pachot), представляет Oracle Team. PostgreSQL на Oracle — звучит странновато, но речь о всего лишь о PostgreSQL 14 beta на Oracle Linux 7.9. Процессоры — ARM v8.2 с инструкциями LSE (по словам Франка это большая разница — см. статью Александра Короткова, ныне OrioleDB Dramatical Effect of LSE Instructions for PostgreSQL on Graviton2 Instances).
Ещё от Пашо:
SQLcl to transfer data from Oracle to PostgreSQL or YugabyteDB — Oracle сделал сам утилиту для миграции ИЗ Oracle. В PostgreSQL и в YugabyteDB. Имеется руководство по экспорту запросов в CSV-файл: How to Export Query Results to a CSV File in SQLcl (Oracle).
Образование
Удалось уже подержать в руках новые книги:
PostgreSQL изнутри — 660 страниц, 29 глав, одно Содержание занимает 11 страниц.
По этому поводу 8-го февраля состоялся прямой эфир на Постгрес-вторнике у Николая Самохвалова и Ильи Космодемьянского: Постгрес-вторник с Егором Роговым. Внутри PostgreSQL
Postgres: первое знакомство — новая «малютка» на основе 14-й версии Postgres.
Список софта, библиотек, инструментов и ресурсов. Примером для подражания брали awesome-mysql.
Персона
В середине февраля Генриэтта 'Хетти' Домбровская стала персоной недели. Многие знают её по книге Оптимизация запросов в PostgreSQL в соавторстве с Борисом Новиковым и Анной Бейликовой.
О расширениях
Джоэл Джейкобсон (Joel Jacobson) собрал все известные ему расширения в список. Их больше тысячи, и список пополняется (для сравнения: на PGXN их сейчас «всего» 338). Сообщество заинтересовалось, но предлагает структурировать и добавлять краткие описания. Это и было сделано — хотя бы по строчке текста есть о каждом расширении. Сейчас есть такие разделы:
- Uncategorized;
- Access Methods;
- Aggregate Functions;
- Data Types;
- Dictionaries;
- Foreign Data Wrappers;
- Procedural Languages;
- Spatial and Geographic Objects.
Дерево разделов не сбалансировано никак: в разделе FDW много-много экранов, а в Access Method только одно расширение: RUM access method — inverted index with additional information in posting lists — то есть обратный индекс с дополнительной информацией в дереве идентификаторов.
Implementing your first PostgreSQL extension: From Coding to Distribution
В этом PDF Burak Yücesoy и Önder Kalacı из Citus (то есть Microsoft) делятся своим опытом написания расширений.
Разное
PostgreSQL 14.2, 13.6, 12.10, 11.15 и 10.20
Исправлено 55 багов.
Любопытная статья Джереми Шнайдера (Jeremy Schneider, Ardent Performance Computing). Он считает, что случаи, когда база рухнула, не самые сложные — обычно удаётся понять, что случилось, по коркам или другим печальным результатам. Самыми тяжелым для диагностики могут оказаться (неумышленные) brownouts (не знал этого интересного выражения) — когда катастрофа не произошла, но что-то определённо не так. Конечно, он обращается к pg_stat_statements и pg_stat_activity, но и они не всегда спасают. На помощь Джереми призывает флеймграфы. Их в статье аж 4. В ней и в комментариях также упоминается расширение pg_show_plans.
У нас в прошлом году была статья с диагностикой тоже своего рода браунаутов: Битвы на территории ZFS, тоже не без флеймграфа, кстати. Там используется диагностическое расширение pgpro_pwr/pg_profile. Ещё в этом жанре у нас была статья Параллелизм в PostgreSQL: не сферический, не конь, не в вакууме.
Опенсорсное приложение для анализа данных при помощи SQL в Python. Данные можно экспортировать из CSV-файлов, Excel, Microsoft SQL Server, PostgreSQL и MySQL, а потом работать в привычной среде Jupyter-notebook. Можно писать хранимые процедуры. Создано на базе расширенной SQLite, поддерживает и стандартные SQL-запросы, и специфические для SQL Notebook команды и функции.
Mirage of memory, part 4: why am I swapping?
Это 4-я часть цикла статей Память как мираж Фрица Хугланда (Frits Hoogland). Кажется, не последняя. Вот предыдущие:
Обратите внимание: OOM killer может убить не (только) тот процесс PostgreSQL, который следует убить.
На этом выпуск #2 за 2022, пожалуй, закончим.
Автор:
Igor_Le