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

🟣С Digital Q.DataBase переписывание кода не требуется, эта СУБД понимает одновременно диалекты PostgreSQL, Oracle Database и Microsoft SQL Server. Настоящий полиглот в мире СУБД.

🟣Импортозамещение СУБД такое, каким оно должно быть! Если что-то не работает - это ответственность разработчика СУБД, а не Ваша головная боль!

👆Кратко из аудиозаписи.

💣В преддверии выхода первой версии нашей СУБД-полиглота хотелось бы напомнить и про другие способы перевода функционала с MS SQL на Digital Q.DataBase,
которые предлагает наша компания, которые доступны и на предыдущих версиях нашей СУБД.

🟣Клиент подготавливает код и передаёт его «Диасофт» через защищённый канал.
Сервис автоматически конвертирует T-SQL в синтаксис компонента Digital Q.DataBase.

🔥Что в итоге:
🟣до 95% кода переводится за 1 день,
🟣сохраняется бизнес-логика,
🟣нет необходимости в переобучении команды,
🟣можно поддерживать две версии кода из одного исходника,
🟣снижаются затраты и сроки миграции.

🔥Диасофт также может подключиться к подготовке, миграции и тестированию.
Готовое решение — под задачи высоконагруженных систем.

🟣Плюс этого способа в том, что воспользоваться можно немедленно, не дожидаясь выхода полиглота.
И СУБД для этого обновлять не потребуется.

🟣Сегодня немного затронем тему логической репликации — это механизм, который позволяет передавать изменения данных
(INSERT, UPDATE, DELETE) из одной базы в другую в реальном времени.

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

💪В Digital Q.DataBase логическая репликация получила важные обновления для повышения стабильности и производительности:

🟣Параллельная обработка больших транзакций — теперь подписчик может обрабатывать крупные изменения одновременно в нескольких потоках.
Это значительно ускоряет репликацию и снижает нагрузку на систему.

🟣Новый инструмент pg_createsubscriber — автоматизирует создание подписчика из резервной копии. Настройка логической реплики теперь занимает гораздо меньше времени.

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

🟣Нам поступил вопрос: поддерживает ли логическая репликация в Digital Q.DataBase команды DDL?

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

🟣DML (Data Manipulation Language) — команды для работы с данными: INSERT, UPDATE, DELETE, TRUNCATE, COPY.

🟣DDL (Data Definition Language) — команды, которые изменяют структуру базы данных: CREATE, ALTER, DROP и другие.

🟣JSON в Digital Q.Database особенно полезен благодаря появлению функции JSON_TABLE() и новых предикатов, которые значительно упрощают извлечение, фильтрацию и преобразование данных из JSON-структур прямо на уровне SQL-запросов.

🟣Например можно распарсить JSON прямо в SQL и построить выборку по отдельным полям (например, фильтрация по статусу товара).

SELECT item_name, quantity
FROM JSON_TABLE(:order_json, '$.items[*]'
  COLUMNS (
    item_name TEXT PATH '$.name',
    quantity INT PATH '$.qty'
  )
) AS items;

🟣Или легко превратить лог в табличный формат и сразу агрегировать: частота действий, география, время отклика и пр.

SELECT country, COUNT(*) AS event_count
FROM JSON_TABLE(user_event, '$'
  COLUMNS (
    country TEXT PATH '$.geo.country'
  )
) AS data
GROUP BY country;

🟣Можно обрабатывать эти данные без ETL-инструментов: JSON → SQL → вставка в структуру базы.

INSERT INTO payments (id, amount, currency)
SELECT *
FROM JSON_TABLE(:json_data, '$.payments[*]'
  COLUMNS (
    id TEXT PATH '$.payment_id',
    amount NUMERIC PATH '$.sum',
    currency TEXT PATH '$.curr'
  )
);

🟣Можно найти все записи, где в JSON есть определённый флаг или значение.

SELECT *
FROM orders
WHERE json_data->'delivery'->>'status' = 'shipped';

🟣Также JSON легко адаптируется под любые бизнес-настройки без изменения схемы БД.

SELECT user_id
FROM user_settings
WHERE json_config->>'theme' = 'dark';

🔥Привыкли к 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-процедур.

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