🔥Привыкли к SQL Server Management Studio (SSMS)?
С Digital Q.DataBase вы можете при желании продолжить работать в том же стиле!

🟣Digital Q.DataBase, как настоящий полиглот, обеспечивает совместимость с запросами и логикой MS SQL.
🟣Переносите базы данных из MS SQL — структура, данные и накопленный опыт остаются с вами.
🟣Знакомые подходы к администрированию, анализу и оптимизации — без необходимости полностью переучиваться.

🪁 Когда клиентское приложение отправляет запрос в Digital Q.DataBase, он обрабатывается через один из наших поддерживаемых протоколов:

🟣TDS (Tabular Data Stream) - наш основной протокол для MS SQL Server, который эффективно передаёт табличные данные и SQL-команды

🟣PGWire - основной протокол для PostgreSQL, поддерживающий все его возможности и гарантирующий молниеносную обработку запросов

🟣TNS (Transparent Network Substrate) - протокол Oracle (в активной разработке, скоро будет доступен, а пока запросы на диалекте Oracle мы принимаем и обрабатываем через протокол PGWire)

🪁 Digital Q.DataBase обеспечивает максимальную гибкость работы с разными СУБД.

🪁 После получения запроса через поддерживаемые протоколы, начинается его глубокая обработка:

1️⃣Интерпретация и первичная оптимизация
Наши интегрированные интерпретаторы (часть ядра QDB!) обрабатывают запросы:

🟣PL/pgSQL – для PostgreSQL
🟣PL/SQL – для Oracle
🟣T-SQL – для MS SQL Server

Здесь происходит:
✓ Проверка синтаксиса и семантики
✓ Частичная оптимизация запроса
✓ Формирование первоначального плана выполнения

2️⃣Финальная обработка ядром

Сформированный план поступает в ядро QDB (на базе PostgreSQL), где:

✓ Проводится дополнительная оптимизация (если требуется)
✓ Осуществляется непосредственное выполнение запроса
✓ Обеспечивается стабильная работа с данными

🪁 Представляем расширение на базе tds_fdw для интеграции с MS SQL Server в Digital Q.DataBase.

Важно:

1️⃣Техническая поддержка всех продуктов Digital Q.DataBase в одном окне.
2️⃣Минимальное время внедрения и обучения благодаря технологии FDW.
3️⃣Исходные коды хранятся на серверах в РФ, документация — полностью на русском.
4️⃣Поддержка российской инфраструктуры.

Функционал:

🟣Прозрачный SQL-доступ к таблицам MS SQL Server.

🟣Выполнение распределённых запросов между Q.DataBase и MS SQL Server.

🟣Транзакционная согласованность данных между двумя системами.

🟣Простая интеграция в IT-ландшафт заказчика.

🪁 Также делюсь с вами схемой работы расширения.

🐘 Часть 1.
Как работает in-memory "движок" в составе Digital Q.DataBase?

🟣Это распределённая in-memory база данных, глубоко интегрированная в ядро нашей СУБД.

Поддерживает автоматическое перемещение информации между нодами кластера, при этом память используется весьма экономно — информация хранится только в указанном количестве копий (обычно 2–3), симметрично доступна через любую из нод, но на другие ноды перемещается всего в трёх случаях:

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

Наличие нескольких копий гарантирует сохранность информации при изъятии любой ноды из кластера — всё, что на ней было, будет снова восстановлено в заданном числе экземпляров на других нодах.
Реально неубиваемо!

🐘Часть 2. Для чего это нужно?

🟣Самый простой пример — хранение сессионных данных или разного рода настроек для web-приложения.

❗️Можно легко обойтись без таких продуктов, как Memcached, Redis или Tarantool, при разработке современного высоконагруженного web-приложения.

Достаточно только Digital Q.DataBase, которая возьмёт на себя хранение как персистентной информации, так и временных данных в памяти.

🟣Можно также потеснить документ-ориентированные СУБД типа MongoDB (помним ведь, что значением может быть и JSON-документ!).

❓А зачем иметь в инфраструктуре несколько разных СУБД, когда с задачами легко справится одна мультимодальная или, как ещё говорят, высококонвергентная СУБД вроде нашей Digital Q.DataBase?

🐘 Часть 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, в общем случае представляющая собой «подстрочник» или «черновик» для последующих ручных исправлений.

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