🐘 Часть 3.

🟣Также продукт просто идеален для разного рода задач кэширования информации.
Это позволяет кратно ускорять работу информационных систем, иногда даже в десятки раз.

Например, "горячие остатки" банковской системы в памяти.
Вместо того чтобы каждый раз собирать доступный для использования клиентом остаток по разным таблицам (остаток на счёте минус имеющиеся лимиты, блокировки, аресты), система лишь один самый первый раз рассчитывает его, а далее подвешивает в память.

🟣Последующее обращение за доступным остатком идёт уже мгновенно.
Нужно обновить данные?
Они тут же обновляются и в памяти, и потому всегда остаются актуальными.

🟣Скорость работы банковской системы вырастает в разы!

И ещё раз напомним, что для использования всего этого чуда не надо менять архитектуру системы, не надо иметь программиста-бэкендера на языке высокого уровня вроде Java, Go или C++ — достаточно того, что и так умеет обычный SQL-разработчик, которых в банке много.

Где они могут храниться❓

In-memory данные (в зависимости от потребностей и решаемой задачи) могут храниться:

🟣в пределах одной сессии;
🟣для всех сессий конкретного пользователя;
🟣для всех пользователей, подключённых к одной БД;
🟣глобально в пределах сервера или кластера серверов.

Есть возможность гибкого управления доступом к этим данным.

🐘 Финальная часть.

❗️Реальный кейс:
Если у вас есть ресурсоёмкая хранимая процедура, выполняющая некоторый нетривиальный расчёт, которую не хочется запускать каждый раз, можно:

🟣рассчитать её результат 1 раз;
🟣сохранить его в памяти;
🟣при следующем вызове проверять наличие данных в памяти и брать сохранённые in-memory данные, если они актуальны.

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

Можно в разы ускорить работу legacy-приложения, при этом не потребуется сильной переделки архитектуры или значительного переписывания логики SQL-процедур.

Вся обработка остаётся внутри базы!

🐘 Продолжаем рубрику полиглот.
Сегодня поговорим про ядро.

Итак, после протокола и интерпретатора запрос поступает к ядру СУБД.

🟣qdb – это основной сервис СУБД, обеспечивающий работоспособность всех её функциональных возможностей.
Данный сервис является ядром СУБД.

🟣Ядро СУБД представляет собой центральный компонент, отвечающий за выполнение основных функций обработки данных и управление ими.

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

🟣Основные компоненты ядра СУБД:

1️⃣ Менеджер транзакций – управляет транзакциями базы данных, обеспечивая их согласованность и поддерживая ACID-свойства (атомарность, консистентность, изолированность, долговечность).

2️⃣Оптимизатор запросов – преобразует SQL-запросы (или запросы на других языках) в эффективный план выполнения, минимизируя использование ресурсов и ускоряя доступ к данным.

3️⃣Планировщик заданий – распределяет ресурсы между конкурирующими процессами, балансирует нагрузку и гарантирует своевременное выполнение задач.

4️⃣Система хранения данных – организует физическое хранение данных, управляет индексами, распределением пространства и обеспечивает эффективный доступ к информации.

5️⃣Механизм блокировок и синхронизации – предотвращает конфликты при одновременном доступе к ресурсам, используя блокировки и координацию процессов.

6️⃣Средство восстановления – реализует механизмы резервного копирования и восстановления данных после сбоев, возвращая базу в последнее целостное состояние.

7️⃣Интерфейсы API – обеспечивают взаимодействие с приложениями и предоставляют инструменты для интеграции с внешними системами.

🐘 Говоря об инструменте резервного копирования в составе Digital Q.DataBase, важно отметить, что он обеспечивает не просто сохранность данных, а полноценный комплекс возможностей для администратора.

🟣Поддерживаются полные, дифференциальные и инкрементные бэкапы

🟣Достигается высокая скорость за счёт многопоточности и сжатия

🟣Возможен Point-in-Time Recovery благодаря журналам WAL

🟣Реализована проверка целостности и управление сроками хранения

🟣Встроено шифрование копий для повышения безопасности

В основе инструмента лежит pgBackRest, но мы интегрировали его в платформу Q.DataBase, обеспечили поддержку российских ОС (Astra Linux, РЕД ОС, Альт) и добавили управление через консоль «Центра управления».

Это не отдельный сторонний сервис, а часть экосистемы Q.DataBase — с единым администрированием и технической поддержкой.

🐘 Сегодня хочу рассказать про один из модулей нашей платформы — Систему управления пулом соединений Digital Q.DataBase.

Что это даёт:

🟣Повышает производительность высоконагруженных приложений за счёт сокращения времени установления соединений.
🟣Снижает нагрузку на сервер Digital Q.DataBase, уменьшая количество открытых подключений.
🟣Основана на полностью открытом и импортонезависимом ПО, совместима с российскими дистрибутивами Linux и включена в Единый реестр отечественного ПО.
🟣Построена на базе проверенного инструмента PgBouncer, при этом глубоко интегрирована в нашу платформу.

Функционал:

🟣Создание пула соединений и распределение их между клиентами.
🟣Поддержка трёх режимов работы: транзакционный, сессионный и операторный.
🟣Возможность изменять конфигурацию «на лету» без перезапуска.
🟣Администрирование пользователей и настройка ограничений подключений.

Это решение позволяет стабилизировать работу приложений, ускорить доступ к данным и обеспечить готовность Digital Q.DataBase к задачам цифровой трансформации.

🐘 Обычно статьи про PostgreSQL рассказывают, как сделать его быстрее.

🔥Но автор Jacob Jackson пошёл навстречу другим целям: шаг за шагом настроил Postgres так, чтобы он работал максимально медленно, но всё ещё выполнял хотя бы одну транзакцию.

➡️Технические условия эксперимента:

PostgreSQL 19-devel на Linux
Ryzen 7950X, 32 ГБ RAM, SSD
Бенчмарк TPC-C (128 складов, 100 соединений)
Базовая производительность: ~7082 TPS (транзакций в секунду)

➡️Что именно «сломало» производительность:

🟣Минимальный кэш
Postgres хранит считанные блоки в памяти для ускорения запросов. В нормальной конфигурации с 10 ГБ кэша он выдавал ~7082 TPS. Но при сжатии буфера до 2 МБ производительность рухнула ниже 500 TPS.

🟣Автовакуум на максималках
Обычно autovacuum запускается периодически. Здесь его настроили так, что даже один INSERT сразу вызывал уборку. В комбинации с маленьким кэшем это дало постоянные обращения к диску и падение до ~293 TPS.

🟣WAL в жёстком режиме
Все изменения начали записываться в журнал (WAL) до внесения в базу максимально агрессивно. Результат — TPS упал ниже 100.

🟣Отключение пользы от индексов
Параметры random_page_cost и cpu_index_tuple_cost завысили настолько, что планировщик перестал использовать индексы и перешёл на последовательное сканирование.
Даже при увеличении кэша до 8 МБ TPS стал меньше единицы.

🟣Один поток на всё
Параметры io_method = worker и io_workers = 1 перевели систему в однопоточный режим. Итог — TPS около 0,1.

➡️Итог: ~42 000× медленнее!
На 100 соединениях за 120 секунд завершились всего 11 транзакций — остальные упали с OOM или по таймауту.

➡️Зачем это нужно?
Не ради практической пользы, а чтобы лучше понять, как работает Postgres изнутри.
Иногда изучение пределов системы даёт больше понимания, чем обычная оптимизация.

➡️Оригинал статьи:
byteofdev.com/posts/making-postgres-slow

🐘 Сегодня хочу рассказать о нашем решении — Адаптер к Oracle Database, который входит в платформу Digital Q.DataBase.

➡️Что это даёт бизнесу?

🟣Прозрачный доступ к данным Oracle прямо из Digital Q.DataBase — без ручного экспорта и сложной интеграции.

🟣Возможность выполнять запросы, которые обращаются одновременно к данным в Oracle и в Digital Q.DataBase.

🟣Согласованность транзакций — данные остаются целостными даже при работе сразу с двумя СУБД.

🟣Постепенный переход: Oracle-компоненты можно выносить из инфраструктуры поэтапно, без остановки бизнес-процессов.

Адаптер разработан на базе проверенной технологии oracle_fdw, работает на импортонезависимом стеке и полностью соответствует требованиям цифровой трансформации.

➡️ По сути, это инструмент, который позволяет не делать «большой прыжок» сразу, а разделить его на управляемые шаги: бизнес получает возможность продолжать работу и одновременно постепенно переходить с Oracle на отечественное решение.

🐘 Утилита ora2pg для миграции с Oracle в PostgreSQL существует уже много лет, и многие успели её попробовать ещё в первой половине 2010-х.

С тех пор она стала лишь немного «умнее» и обросла новыми настройками, но архитектурно осталась прежней. Поэтому, несмотря на длительную историю, интерес к ней не угасает — её регулярно упоминают в статьях и обсуждениях.

Что ж, давайте разберёмся, какие у неё сильные и слабые стороны.

🟣Плюсы ora2pg
➕Бесплатна — это open source.
➕Довольно резво переносит структуру таблиц и данные — с bulk-миграцией справляется достойно.
➕Поддерживает выгрузку схем, индексов, последовательностей, представлений и прав.
➕Умеет делать отчёты о сложности миграции, что помогает при планировании.

🟣Минусы ora2pg
➖Perl в основе
Код «олдскульный», поддержка и расширение требуют знаний Perl.
➖Неполная поддержка возможностей Oracle
➖Современные фичи обрабатываются частично или совсем не поддерживаются.
➖Nested tables
Таблицы с NESTED TABLES не конвертируются вообще.
➖Автономные транзакции
Поддерживаются только «костыльно», логика часто ломается.
➖Packages (пакеты)
В Oracle их более 760.
В PostgreSQL есть расширение orafce, где реализованы лишь отдельные функции из самых популярных пакетов (например, dbms_output).
Но это капля в море — реальных поддержанных пакетов меньше десяти.
В итоге после конвертации процедуры, использующие пакеты, содержат вызовы к тому, чего в ванильном PostgreSQL просто нет.
Значит, либо переписывать вручную, либо логика ломается полностью.
➖Ассоциативные массивы, коллекции, VARRAY
Частично конвертируются, часто с потерями или предупреждениями.
➖Динамический SQL
Конвертируется плохо, требует ручной переписки.
➖Хранимая логика (PL/SQL → PL/pgSQL)
Почти никогда не работает «из коробки».
Если процедура заработала без ручной правки — это вам просто очень повезло.
Реалистично воспринимать результат только как «подстрочник» для переписывания.
➖Производительность и оптимизация
Код, сгенерированный утилитой, может быть рабочим, но неоптимальным для PostgreSQL.
➖Сложность освоения
Конфигурационный файл громоздкий и не всегда очевидный.
Без опыта миграции легко запутаться.

➡️Есть и другие инструменты для решения задачи переноса, многие из которых дают результаты лучше, чем ora2pg. О них расскажем в будущих сообщениях. #субд

🐘 В прошлом выпуске говорили про ora2pg — бесплатный, но не всегда полезный инструмент.

Существует и доработанная версия — ora2pgpro.

➡️Форк ora2pg, созданный для использования совместно с Postgres Pro.
➡️ Упор на миграцию из Oracle с учётом «расширенных» фич (автономные транзакции, пакеты, коллекции).
➡️ Более умный парсинг PL/SQL → PL/pgSQL (AST вместо регулярок).

🟣Плюсы ora2pgpro

➕ Лучше понимает сложный PL/SQL, меньше ручных правок.
➕ Конвертирует вызовы, которые обычная ora2pg оставляет TODO.
➕ Поддерживает ассоциативные массивы, пакеты и init-функции.
➕ Даёт более чистый и предсказуемый результат миграции.

🟣Минусы ora2pgpro

➖ Работает только с Postgres Pro — на «ванильном» или облачном PostgreSQL просто бесполезен.
➖ Код открыт (это по-прежнему Perl), но лицензия запрещает самостоятельные доработки, чтобы никто не адаптировал под другие форки PostgreSQL.
➖ Пользу от этого инструмента могут получить только те, кто приобрёл лицензию на Postgres Pro.

➡️ В следующем посте я расскажу про Конвертум - еще один популярный инструмент для миграции БД на PostgreSQL.

🐘 После ora2pg и ora2pgpro самое время взглянуть на Конвертум
Ещё один претендент на звание «спасителя миграций».
Разберём, что он делает хорошо, а где придётся вздохнуть и править руками.

Плюсы
➕ Конвертация процедур быстрая и точная — используется синтаксический анализ на уровне AST, а не простые регулярки.
Тут они реально лучше ora2pg и даже ora2pgpro.
➕ Есть бесплатный сканер — можно хотя бы понять масштаб бедствия перед тем, как достать кошелёк.
➕ Обещают офлайн-режим и работу только с правами на чтение — базу не испортят.
➕ Гибкость: заявляют, что могут быстро добавить правила под конкретный проект — звучит неплохо.

Минусы (и тут интереснее)
➖ Инструмент полностью коммерческий — без лицензии не запустится, без поддержки далеко не уедешь.
➖ Не учитывает расширенные возможности российских форков PostgreSQL (кроме Postgres Pro) — нативные пакеты Oracle, реализованные dbms_-пакеты и прочие фишки останутся за кадром.
➖ Красивые слова про поддержку PL/SQL на сайте — это здорово, но что реально конвертируется без ручных правок, узнаешь только в бою.
➖ Почти всегда придётся подключать их команду - иначе риск получить полуфабрикат.
➖ Ну и всё это удовольствие стоит денег.

➡️ Несмотря на всё это, Конвертум показал лучшие результаты среди уже рассмотренных инструментов, особенно в части конвертации процедур.

🔥 В следующий раз я расскажу вам, как перенести данные из Oracle или Microsoft SQL Server в Digital Q.DataBase, используя инструменты Диасофт.

🐘 В предыдущих статьях мы рассмотрели ряд инструментов для миграции баз с Oracle на PostgreSQL и его форки.

🟣Все рассмотренные нами инструменты роднит одно общее свойство: они пытаются автоматизированно подстроить то, что нашли в исходной СУБД (т. е. в Oracle), к возможностям PostgreSQL,
которых не всегда хватает.

Из-за этого процесс миграции баз реальных клиентских систем превращается из суперхайвея в убитую и извилистую проселочную дорогу в глухом лесу — и ночью.

Если в СУБД нет аналогов для используемых в оригинальном PL/SQL-коде функций dbms-пакетов, нет понятия пакетов, нет ряда механизмов — ничего работоспособного почти наверняка не получится.

🟣Лучшее, на что можно рассчитывать, — это перенос данных (и то не факт — привет от nested tables, несовпадающих типов и пр.) и какая-то конвертация текста хранимых процедур и функций к синтаксису PostgreSQL, в общем случае представляющая собой «подстрочник» или «черновик» для последующих ручных исправлений.

Продолжение ⬇️

➡️ Работая над Digital Q.DataBase, мы опирались на свой предыдущий опыт создания автоматизированных инструментов миграции хранимой бизнес-логики и сделали по-настоящему революционный шаг.

Наш подход можно описать просто: не нужно «приземлять» работающий клиентский код под ограниченные возможности большинства форков ванильного PostgreSQL.
Вместо этого нужно сделать обратное — реализовать в своей СУБД всё то, что есть в популярных зарубежных системах и активно используется в российских информационных решениях.

Это значит, что СУБД должна уметь исполнять не только PL/pgSQL, но и PL/SQL, и даже T-SQL — напрямую, без промежуточных преобразований и ручных миграций.

В ней должны быть:

🟣все встроенные функции, привычные разработчикам Oracle и SQL Server,
🟣поддержка создания пакетов «как в Oracle»,
🟣системные таблицы и представления или их эмуляция,
🟣dbms_- и utl_-пакеты Oracle,
🟣аналоги востребованных sp_-процедур из MS SQL и многое другое.

Когда в СУБД есть всё это, миграция с зарубежной платформы проходит просто, быстро и без боли.

Продолжение ⬇️⬇️

➡️ Главный принцип диасофтовского «Мастера переноса БД в Digital Q.DataBase» — выгрузка и перенос всего содержимого базы данных как есть, без каких-либо преобразований.

🔥 Это первая в России миграция без конвертации.
Конвертация к синтаксису PostgreSQL для Q.DataBase просто не нужна - она прекрасно понимает и непреобразованные скрипты от MS SQL и Oracle.
Никто не вмешивается в текст ваших хранимых процедур или функций, которые успешно работали в зарубежной СУБД.
Они загружаются в Q.DataBase без изменений и работают максимально близко к оригиналу.

➡️ Мы также учли, что не все DBA любят командную строку, и снабдили инструмент графическим фронтендом в стиле «нажми кнопку — дальше, дальше, дальше — и готово».

➡️ Инструмент работает как на Linux-системах, так и под Windows. Он может создать копию имеющейся БД из Oracle или Microsoft SQL Server как напрямую в Digital Q.DataBase, так и «сдампить» её в набор SQL-файлов, которые при желании можно загрузить даже обратно в исходную зарубежную СУБД.

Продолжение ⬇️⬇️⬇️

➡️ Забавно, но с задачей скриптования больших баз Мастер переноса справляется лучше оригинальных средств.

Когда Generate SQL Scripts в Microsoft SSMS падает с ошибкой «Out of memory», Мастер всё равно генерирует скрипты до конца.

Поэтому им пользуются даже те, кто ещё не перешёл на Digital Q.DataBase.

А те, кто уже перешёл, активно запускают PL/SQL и T-SQL наравне с родным #PostgreSQL

И мы продолжаем нашу историю ⬇️⬇️⬇️

➕ Так какие же плюсы использования нашего Мастера переноса БД?

1️⃣Есть GUI и CLI — на выбор, новичкам удобно, профи довольны.

2️⃣Кроссплатформенность — работает на Linux и Windows.

3️⃣Высокая скорость миграции — 10-террабайтная база переносится меньше чем за сутки.

4️⃣Сохранение в неприкосновенности всей хранимой логики и прав пользователей, никаких трансформаций — код хранимок переносится "как есть". После завершения миграции система сразу готова к работе.

5️⃣Многопоточность — при запуске инструмент автоматически определяет конфигурацию оборудования и использует имеющиеся аппаратные ресурсы максимально эффективным образом.

6️⃣При возникновении в процессе переноса БД нештатных ситуаций информация о них автоматически заносится в файл журнала, который можно легко отправить в поддержку.

7️⃣Проблемы с различными кодировками кириллицы решаются на лету — миграция БД проходит без сюрпризов, в отличие от оригинальных инструментов Oracle.

8️⃣Инструмент имеет ценность даже в отрыве от СУБД Digital Q.DataBase - его можно использовать как бесплатное средство для создания полного SQL-дампа Вашей БД.

В заключение отмечу и один минус — он тут всего лишь один.

Наш инструмент «Мастер переноса БД» предполагает, что целевая СУБД умеет выполнять все то, что работало в исходной.

➡️ На текущий момент только одна российская СУБД умеет исполнять PL/SQL и T-SQL без из преобразования.

Поэтому полные возможности инструмента доступны лишь в его связке с нашей СУБД - Digital Q.DataBase.

Использовать его для миграции на «ванильный» PostgreSQL или его коммерческие форки с "недоразвитыми" по сравнению с MS SQL и Oracle функциональными возможностями нет никакого практического смысла.

➡️ Вывод
Мастер переноса БД в Digital Q.DataBase — это не просто утилита, а мост между популярными зарубежными и российской СУБД.

Он экономит время, убирает головную боль с "поломанными" хранимыми процедурами, кодировками и правами.
Система готова к работе сразу же после переноса.

Если вы всё ещё думаете, стоит ли пробовать Digital Q.DataBase, — начните с знакомство с ней с этого инструмента. Вы удивитесь тому, как просто может выглядеть миграция Вашей БД.

🐘 Мы исправили ошибку в крупном банке, которая в определённых случаях приводила к полному падению сервера.

🔪 Охотились за ней почти две недели: она проявлялась стохастически и только под высокой параллельной нагрузкой. Система могла десять раз отработать нормально, затем несколько раз подряд упасть, а потом снова функционировать без проблем. Воспроизвести её было сложно — для этого должен совпасть ряд факторов: высокая вложенность и сложность хранимых процедур, серьёзная параллельная нагрузка и ситуация, когда операционная система отдаёт только что освобождённую память другому процессу.

🧬 Ошибка затрагивает «ванильный» PostgreSQL 17-й версии и, с высокой вероятностью, может встречаться и в других форках.

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

Страшно представить, что было бы, если бы банк остался с этой нетривиальной проблемой один на один.

🧰 Само исправление в итоге заняло всего один день.

👾 А вот и моя статья на Хабре!

🟣Можно ли перейти с Oracle или MS SQL на СУБД из Реестра российского ПО без переписывания всей хранимой логики?

🟣Один из возможных подходов к решению этой задачи.

#dqdb #cубд

🔄https://habr.com/ru/articles/949980/