Postgresso #2 за 2022 (39)

В эти безрадостные дни многим трудно работать, сочинять и даже читать статьи. Но ИТ-инфраструктура это как водопровод — без неё жизнь уже почти невозможна. И мы продолжаем выпускать Postgresso. По понятным причинам в этом выпуске будет много ссылок, меньше анализа. И главная тема — миграция

Миграция

Проблемы миграции с Oracle на Postgres обычно начинаются там, где приходится иметь дело с различиями в синтаксисе команд и прочими расхождениями в этих СУБД. Об этом и говорится в большинстве статей и видео.

Начнём с Oracle to Postgres Conversion ^[1]

Это официальный документ сообщества PostgreSQL ^[2]. Есть список инструментов миграции.

The Complete Oracle to PostgreSQL Migration Guide: Move and convert Schema, Application & Data ^[3]

Довольно пространное руководство от EDB. Есть матрица возможностей миграционных инструментов.

Oracle to Postgres Migrations ^[4]

Полуторачасовая презентация, рассказывает Пётр Петров (Postgres Professional) — очень рекомендуем. Это умелый практик и знаток нюансов миграции. Но презентация на английском.

Почему мы перешли с Oracle на PostgreSQL, и как это сделать ^[5]

Эта статья 2021-го в хаброблоге Ростелекома ^[6]. Их серверы на RedOS 7.2 «Муром», а СУБД брали самую свежую (на тот момент) — Postgres Pro Standard 13. Репликацию делали при помощи расширения Oracle FDW ^[7], которое поддерживает Лоренц Альбе (Laurenz Albe).

В статье разобрано немало нюансов, связанных с различиями Oracle и Postgres, но непредсказуемость ORDER BY — выделили даже в раздел Почему ваши данные скорее всего никогда не сойдутся:
«Все запросы, в которых нет order by будут выполняться „как решил сервер БД“, т.е. порядок сортировки в общем случае „не задан“. К сожалению это влияет на все, где нет ORDER BY — вывод списков с данными на фронте, вывод данных в отчетах. Да, в таких случаях хорошо бы было всегда использовать ORDER BY, но как быть в ситуациях, когда так не было изначально? Отмечать эти особенности как „не ошибка“ и комментировать различия пользователям.»

Более подробно мы говорили об этой статье в Postgresso #33 ^[8].

Миграция приложения Oracle PL/SQL на Postgres pl/pgSQL: взгляд два года спустя ^[9]

Доклад Анатолия Анфиногенова из АО «ВНИИЖТ» (ДЗО ОАО «РЖД») на PGConf.Russia 2021 ^[10]. Анатолий — заместитель директора научного центра, начальник отдела разработки программного обеспечения АО «ВНИИЖТ». Речь о большом проекте РЖД. Распределенное серверное приложение, работающее 24/7 на полигоне 16 железных дорог от Калининграда до Хабаровска плюс несколько БД центрального уровня — РЖД есть РЖД. Перенесли с Oracle 11g SE на ванильный PostgreSQL 11.9. В докладе: как переходили, с какими проблемами столкнулись при переходе и при эксплуатации, что сегодня сделали бы иначе.

Всем доступны слайды, а тем, у кого есть вход в личный кабинет участников конференции, и видео тоже.

Экстремальная миграция на PostgreSQL: без остановки, потерь и тестирования ^[11]

Блог компании ЮMoney (ранее — Яндекс.Деньги, входит в экосистему Сбера). Статья 2017-го. Миграция прошла без остановки и без потерь, заняла 4 с половиной месяца усилиями 4 человек. Переносить пришлось около 50 таблиц.

Использовали SymmetricDS ^[12], но без «ручных» усилий все равно не обошлось. Инструмент миграции выбирался из такого списка (воспроизводим плюсы и минусы, кратко описанные в статье):

• Oracle GoldenGate ^[13] — может показаться, что это та самая серебряная пуля. По крайней мере, до момента ознакомления с ценой.
• SymmetricDS ^[12] — есть миграция схемы, она будет создана или обновлена при регистрации узла PostgreSQL в мастер-узле Oracle. Есть возможность трансформировать данные при выгрузке или загрузке, используя BASH, Java или SQL.
• Full Convert ^[14] — умеет мигрировать схему и данные, но ограничены возможности кастомизации, нет изменяемых трансформеров (код для изменения данных при миграции).
• Oracle to PostgreSQL Migration ^[15] — переносит схему, данные, внешние ключи, индексы. Полуавтоматическая репликация, трансформации нет, но можно задать соответствие типов в разных БД.
• ESF Database Migration Toolkit ^[16] — переносит все то же, что и Oracle to PostgreSQL Migration. Данные передаются в пакетном режиме, возможность миграции в несколько потоков отсутствует.
• Ora2Pg ^[17] — переносит схему, данные, внешние ключи, индексы, возможна миграция в несколько потоков. Из минусов: медленный перенос таблиц с типами blob/clob (около 200 записей/сек), нет трансформатора.
• SQLData Tool ^[18] — мигрирует только схему, ограничены возможности кастомизации.

От Oracle к PostgreSQL — путь длиною в 4 года ^[19]

Статья по мотивам одноименного доклада ^[20] Андрея Рынкевича (Phorm) на PGDay 2017.

Немаловажная предыстория: «Как только выросло количество данных [в Oracle] и нагрузка — стало понятно, что оптимизации запросов и структуры недостаточно. Как минимум, надо было включить партиционирование, а, в идеале, надо было перейти на какое-то MPP решение, которое у Oracle стоит безумных денег: grid, RAC, Exadata.»

В результате за основу взяли PostgreSQL. Сначала запустили один мощный сервер рядом с Oracle, постепенно на него мигрировали. После собирались переходить на MPP-решение от Greenplum, но не сложилось.

Вся работа заняла 4 года. Задача усложнялась непрерывном ростом статистики и нагрузки, и тем что существует еще один продукт, который интенсивно использует БД.

Во время миграции было реализовано много решений, таких как:

• online репликация Oracle в PostgreSQL;
• система патчинга баз данных, синхронизации и запуска приложений;
• система загрузки большого объема статистических данных;
• система мониторинга, в том числе было реализовано что-то вроде Oracle Enterprise Manager для PostgreSQL;
• переход на BI систему Pentaho на этой базе данных.

История успеха «Яндекс.Почты» с PostgreSQL ^[21]

Доклад Владимира Бородина (из Яндекс, не путать с его коллегой Андреем Бородиным) на Highload++ 2016 ^[22]. Он знакомит со сложностями миграции крупного проекта с Oracle Database на PostgreSQL. Это расшифровка доклада с конференции HighLoad++ 2016. Получасовое видео есть на youtube ^[23].

Это нешуточный проект, мягко говоря: больше 10 миллионов пользователей в сутки, более 200 тысяч запросов в секунду в пике, более 150 миллионов писем в сутки, прошедших проверки на спам и вирусы. Суммарный объём писем за все 16 лет — больше 20 петабайт.

Но речь о переезде метаданных из Oracle в PostgreSQL. Их тоже немало: больше трехсот ТБ. Более 250 тысяч запросов в секунду. В основном это маленькие OLTP-запросы, по большей части (80%) чтение.

О том, как справились, почитайте в статье. Есть там и список проблем, с которыми самим справиться не удалось. По этим вопросам пришлось обратиться к комьюнити, и комьюнити помогло. Есть и перечень того, чего в Postgres этой команде не хватает.

Миграция с Oracle на PostgreSQL при помощи Ora2Pg ^[24]

Видео Клуба разработчиков СПб ^[25]. Вадим Краузе, специалист-разработчик ИС делится собственным опытом миграции данных из Oracle на PostgreSQL. А также о необходимых настройках инструмента миграции Ora2Pg, ошибках и сложных ситуациях, способах их решения, производительности процесса миграции данных. Запись с 6-й конференции «Проекты, процессы и практики» Клуба разработчиков СПб ИАЦ.

Полезные скрипты при миграции из Oracle в PostgreSQL ^[26]

«Процесс переноса выглядел следующим образом: создание структуры таблиц через ora2pg, исправление структуры по эталонной схеме, перенос данных, конвертация blob и Boolean, добавление отсутствующих в PostgreSQL функций (nvl, nvl2, regexp_substr), создания оставшейся структуры — индексов, view и прочего. В статье — накопившиеся за время конвертации sql скрипты для полуавтоматической миграции.»

Заодно напоминаем об интересном пакете — orafce ^[27]

Это набор Oracle-совместимых функций поверх PostgreSQL. Главный разработчик Павел Штехуле (Pavel Stehule).

Cybertec Migrator ^[28]

Он позиционируется как самый простой, безопасный способ миграции с Oracle на PostgreSQL. И с малым временем останова.

Миграция с Oracle в PostgreSQL. Как мигрировать базу данных Oracle в PostgreSQL? ^[29]

Видео от Ispirer Systems. В этой презентации: как Ispirer MnMTK осуществляет автоматическую конвертацию базы данных Oracle в PostgreSQL.

Ещё там есть несколько ссылок по теме:
Миграция с Oracle на PostgreSQL ^[30] — коротенький ролик об автоматизации миграции;
Oracle to PostgreSQL Migration with ora2pg ^[31] — доклад на PostgresConf South Africa;
Демо ^[32] миграции.

Миграция на СУБД PostgreSQL/Postgres Pro ^[33]

Есть ещё PDF и видео доклада Миграция на СУБД PostgreSQL/Postgres Pro с многоядерными серверами Bull. Реальный опыт ^[34] (видео только через личный кабинет участника) на PGConf.Russia 2019 ^[35] Артёма Иванова и Алексея Игнатова

Интересно в том числе тем, что здесь касаются сложного вопроса: PostgreSQL и многоузловые NUMA-сервера (Артём Иванов представлял Atos, Алексей Игнатов в то время работал в Postgres Professional). Они рассказывают об опыте стрессового тестирования PostgreSQL и Postgres Pro на BullSequana S и Bullion S. В Postgres Professional делали некоторые доработки (патчи) специально на случай NUMA. Вообще на эту тему советуем почитать здесь: Параллелизм в PostgreSQL: не сферический, не конь, не в вакууме ^[36].

Oracle to PostgreSQL Migration Tutorial part 1 ^[37] и part 2 ^[38]

Видео мастер-класса Альваро Эрнандеса (Álvaro Hernández Tortoza) на PGConf.Russia 2019 ^[38]. Впрочем, это скорее 3-часовой доклад. Важно, что он основан на собственном опыте: переносе софта мессинджера BlackBerry (BBM ^[39]) с 150 млн пользователей, который был на Oracle на серверах DC самой компании BlackBerry. А переехал на PostgreSQL в облачную инфраструктуру. На youtube есть только 1-я часть. Обе части ^[38] есть на сайте конференции, но там видео доступно только через личный кабинет.

Миграция из Oracle в Postgres ^[40]

Статья 2020-го года от InfoWatch, в которой показывается перенос небольшой схемы (15 Гбайт) с Oracle 11.2.0.4 на Linux Redhat 6.8 в Postgres 9.4 на Windows — нечастый случай переезда на Postgres под Windows, да ещё и с Linux.

Миграция с MS SQL

Миграция OLTP с MSSQL на PostgreSQL ^[41]

Это ссылка на PDF-презентацию, есть и 40-минутное видео ^[42]. Кристина Кучерова из Distillery рассказывает не только о том, как надо, но и о собственных ошибках (в презентации раздел Грабли).

Миграция с DB2

Миграция БД больше 10Тб с DB2 на PostgreSQL без простоя БД ^[43]

Рассказывает Дмитрий Погибенко (НИИ Восход). Это ссылка на видео, а здесь тезисы ^[44].

Да, случаются ещё миграции и с DB2. Среди сложностей, о которых рассказывается в этом видео, были: необходимость трансформации данных из-за отличий между DB2 и PG и перемещением BLOB'ов в Ceph. Решали миграционные задачи так:

• отслеживая изменения с помощью триггеров;
• анализируя зависимости с помощью доработанного SchemaSpy ^[45];
• переносили с помощью Spring Batch ^[46];
• разбиение на секции (два подхода: 1. деление диапазона id между min и max на равные части и 2. деление на диапазоны с равным числом строк).

Ещё

Пользовательские агрегатные и оконные функции в PostgreSQL и Oracle ^[47]

Не о миграции, но при миграции может пригодиться. В этой статье Егора Рогова в двух системах создаются пользовательские агрегатные и оконные (в терминологии Oracle — аналитические) функции. Несмотря на различия в синтаксисе и в целом в подходе к расширяемости, механизм этих функций очень похож. Но и различия тоже имеются.

Но не менее полезна может оказаться другая статья Егора, которая фокусируется на серьёзнейшем архитектурном отличии Oracle от Postgres: Обработка запросов в Oracle и PostgreSQL: следствия одного решения ^[48]

Oracle использует глобальный кэш разобранных запросов, а Postgres сохраняет запросы локально. Из разницы в этом принципиальном архитектурном решении логически следует совершенно разная идеология работы в запросами в этих двух СУБД.

Zero-downtime schema migrations in Postgres using Reshape ^[49]

О миграции, хотя и не с Oracle: статья этого года Фабиана Линдфорса (Fabian Lindfors), который и создал расширение reshape ^[50]. У него статус экспериментального, для промышленной эксплуатации автором не рекомендовано, но стоит обратить внимание. Фабиан делал Reshape для миграции (PG -> PG) без останова. Reshape в каждый момент времени убеждается, что доступны и старая, и новая схема. Это даёт возможность разворачивать миграцию постепенно. Все изменения делаются так, чтобы избежать лишних блокировок. Работает начиная с PostgreSQL 12.

Сейчас доступна версия reshape 0.5.1 ^[51]

В ней исправление багов. А вот в тоже недавней 0.5.0 ^[52] немало нового:

• добавлена возможность remove_foreign_key;
• переменные окружения для соединения автоматически загружаются из .env-файла, если он есть;
• Reshape можно будет использовать без времени простоя для уже существующих приложений и баз данных;
• введён таймаут для блокировок в случае, когда блокировка может вызвать остановку; перед следующей попыткой получить блокировку должна пройти секунда;
• автоматически возобновляются попытки запросов при ошибках (например, ошибках соединений);
• добавлены переменные окружения для всех опций соединения; переменная POSTGRES_URL переименована в DB_URL;
• добавлен флаг --version при котором распечатывается текущая версия.

migra ^[53]

migra — инструмент для сравнения схем баз данных PostgreSQL, представляет собой CLI и Python-библиотеку. Предназначен для автоматизации изменений. Разработчик — DatabaseCI, Австралия. По отзывам довольно необычный и удобный интструмент.

ARM и Postgres

Тема очень актуальна. Сейчас многие пробуют, например, Байкал-М ^[54], работающий на ARM. Но мы здесь не касаемся производительности и архитектуры ^[55] Байкалов. Только о том, как он работает с PostgreSQL.

Тема началась давно. Вот, например, статья 2017-го года:

Running Production PostgreSQL Systems On ARM Architecture ^[56]

Это любопытный проект, поддержанный Евросоюзом: Modular Microserver Data Centre ^[57]. Железо на базе 4-ядерных 2.2GHz Tegra ^[58] (то есть ARM+GPU) от Nvidia. Соответственно, использовалось расширение PG-Strom ^[59]. Автор — Каарел Моппел (Kaarel Moppel, старший консультант Cybertec) — выложил и PDF ^[60].

Опыт тестирования PostgreSQL 13 на ARM-серверах HUAWEI TaiShan 200 ^[61]

Свежая статья от самой Huawai, автор — пре-сейлз Вадим Суфияров. Настройка, оптимизация, pgbench, сравнение с архитектурой x-86.

Выводы: Производительность системы зависит от используемого оборудования, операционной системы и базового программного обеспечения. На это также влияет общий дизайн каждой подсистемы, используемые алгоритмы и настройки компилятора.

Основываясь на результатах текущего тестирования с синтетическими данными, мы можем сделать вывод, что серверы могут использоваться в качестве высоконагруженных узлов PostgreSQL и способны выдать производительность не ниже, чем аналогичные платформы x86. В среднем производительность сервера на платформе ARM выше аналогичной конфигурации на платформе x86 на уровне 10-15%.

PostgreSQL on Oracle free tier ARM ^[62]

Швейцарец Франк Пашо (Franck Pachot), представляет Oracle Team. PostgreSQL на Oracle — звучит странновато, но речь о всего лишь о PostgreSQL 14 beta на Oracle Linux 7.9. Процессоры — ARM v8.2 с инструкциями LSE (по словам Франка это большая разница — см. статью Александра Короткова, ныне OrioleDB ^[63] Dramatical Effect of LSE Instructions for PostgreSQL on Graviton2 Instances ^[64]).

Ещё от Пашо:

SQLcl to transfer data from Oracle to PostgreSQL or YugabyteDB ^[65] — Oracle сделал сам утилиту для миграции ИЗ Oracle. В PostgreSQL и в YugabyteDB. Имеется руководство по экспорту запросов в CSV-файл: How to Export Query Results to a CSV File in SQLcl (Oracle) ^[66].

Образование

Удалось уже подержать в руках новые книги:

PostgreSQL изнутри ^[67] — 660 страниц, 29 глав, одно Содержание занимает 11 страниц.

По этому поводу 8-го февраля состоялся прямой эфир на Постгрес-вторнике ^[68] у Николая Самохвалова и Ильи Космодемьянского: Постгрес-вторник с Егором Роговым. Внутри PostgreSQL ^[69]

Postgres: первое знакомство ^[70] — новая «малютка» на основе 14-й версии Postgres.

awesome-postgres ^[71]

Список софта, библиотек, инструментов и ресурсов. Примером для подражания брали awesome-mysql ^[72].

Персона

Henrietta Dombrovskaya ^[73]

В середине февраля Генриэтта 'Хетти' Домбровская стала персоной недели ^[74]. Многие знают её по книге Оптимизация запросов в PostgreSQL ^[75] в соавторстве с Борисом Новиковым и Анной Бейликовой.

О расширениях

Джоэл Джейкобсон (Joel Jacobson) собрал все известные ему расширения в список ^[76]. Их больше тысячи, и список пополняется (для сравнения: на PGXN ^[77] их сейчас «всего» 338). Сообщество заинтересовалось, но предлагает структурировать и добавлять краткие описания. Это и было сделано — хотя бы по строчке текста есть о каждом расширении. Сейчас есть такие разделы:

• Uncategorized ^[78];
• Access Methods ^[79];
• Aggregate Functions ^[80];
• Data Types ^[81];
• Dictionaries ^[82];
• Foreign Data Wrappers ^[83];
• Procedural Languages ^[76];
• Spatial and Geographic Objects ^[84].

Дерево разделов не сбалансировано никак: в разделе FDW много-много экранов, а в Access Method только одно расширение: RUM ^[85] access method — inverted index with additional information in posting lists — то есть обратный индекс с дополнительной информацией в дереве идентификаторов ^[86].

Implementing your first PostgreSQL extension: From Coding to Distribution ^[87]

В этом PDF Burak Yücesoy и Önder Kalacı из Citus (то есть Microsoft) делятся своим опытом написания расширений.

Разное

PostgreSQL 14.2, 13.6, 12.10, 11.15 и 10.20 ^[88]

Исправлено 55 багов.

A Hairy PostgreSQL Incident ^[89]

Любопытная статья Джереми Шнайдера (Jeremy Schneider, Ardent Performance Computing). Он считает, что случаи, когда база рухнула, не самые сложные — обычно удаётся понять, что случилось, по коркам или другим печальным результатам. Самыми тяжелым для диагностики могут оказаться (неумышленные) brownouts ^[90] (не знал этого интересного выражения) — когда катастрофа не произошла, но что-то определённо не так. Конечно, он обращается к pg_stat_statements ^[91] и pg_stat_activity ^[92], но и они не всегда спасают. На помощь Джереми призывает флеймграфы ^[93]. Их в статье аж 4. В ней и в комментариях также упоминается расширение pg_show_plans ^[94].

У нас в прошлом году была статья с диагностикой тоже своего рода браунаутов: Битвы на территории ZFS ^[95], тоже не без флеймграфа, кстати. Там используется диагностическое расширение pgpro_pwr/pg_profile ^[96]. Ещё в этом жанре у нас была статья Параллелизм в PostgreSQL: не сферический, не конь, не в вакууме ^[36].

SQL Notebook ^[97]

Опенсорсное приложение для анализа данных при помощи SQL в Python. Данные можно экспортировать из CSV-файлов, Excel, Microsoft SQL Server, PostgreSQL и MySQL, а потом работать в привычной среде Jupyter-notebook. Можно писать хранимые процедуры. Создано на базе расширенной SQLite, поддерживает и стандартные SQL-запросы, и специфические для SQL Notebook команды и функции.

Mirage of memory, part 4: why am I swapping? ^[98]

Это 4-я часть цикла статей Память как мираж Фрица Хугланда (Frits Hoogland). Кажется, не последняя. Вот предыдущие:

part 3: overcommit ^[99]

Обратите внимание: OOM killer может убить не (только) тот процесс PostgreSQL, который следует убить.

part 2. PSS ^[100]

part 1. ^[101]

На этом выпуск #2 за 2022, пожалуй, закончим.