Уважаемые подписчики!

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

Он сравнивает схемы баз данных и количество объектов между исходной и целевой БД.

Поддерживаются:
Microsoft SQL Server
Oracle Database
PostgreSQL

Что умеет:
находит различия в таблицах, представлениях, индексах, триггерах, функциях и ограничениях,
проверяет расхождения в количестве строк
формирует понятный отчёт.

Работает в двух форматах:

Десктоп
(через пошаговый мастер)

Консоль
(через YAML-конфигурации)

Доступен на Linux и Windows - удобно и для админов, и для автоматизации.

Мастер сравнения БД - это удобный финальный чек после миграции: данные доехали, а структура совпала.

В этом посте кратко хочу отметить, как последняя версия Digital Q.DataBase 18.2 воспроизводит сразу три SQL-диалекта: PL/pgSQL, PL/SQL и T-SQL.

Ну что ж давайте посмотрим на самый верх схемы.
Приложение подключается к базе данных через привычный для него протокол (PGWire, TDS).

В версии 18.2 архитектура принципиально меняется.
Теперь перед нами уже не один большой серверный процесс с тремя обработчиками, а три самостоятельных модуля: Pearl, Onyx и Marble.

Pearl — модуль PostgreSQL;

Onyx — модуль, воспроизводящий функциональность Oracle Database;

Marble — модуль, воспроизводящий функциональность Microsoft SQL Server;

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

То есть запрос PostgreSQL приходит в Pearl и внутри Pearl проходит свой путь: парсер, мутатор, планирование, оптимизация и исполнение.
Oracle-совместимый запрос приходит уже в Onyx. У него свой менеджер соединений, свой серверный процесс, свой обработчик PL/SQL и свой конвейер выполнения.
То же самое происходит с T-SQL в Marble: TDS-клиент подключается к Marble, и дальше запрос обрабатывается уже внутри собственного серверного процесса этого модуля.

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

При этом они НЕ превращаются в три совершенно независимые СУБД.

В нижней части схемы как раз показано то, что их объединяет. 
Здесь находятся поддержка кросс-модульных взаимодействий с общими процессами хранения, монитор состояния системных служб, in-memory сервер DGrid, постоянное Key-Value хранилище RocksDB и механизм поколонного хранения MergeTree.

Каждый модуль можно развернуть на одной ноде либо распределить модули по трём отдельным нодам - в зависимости от требований к инфраструктуре.

В продолжение предыдущего поста — немного о Digital Q.DataBase с точки зрения системного администрирования.

Установочный пакет бесплатно скачивается с нашего сайта database.diasoft.ru в формате tar.gz

На примере Astra Linux 1.8 видно, что внутри находятся необходимые серверные deb-пакеты: pearl, marble и onyx.

Установка выполняется стандартным способом через sudo apt install.
Причём модули можно устанавливать как на одну ноду, так и распределять, например, на три — в зависимости от архитектуры вашей системы.

В архиве также есть всё необходимое для работы:

— серверная и клиентская части в qdb-server-client;
— etcd для конфигурации;
— patroni для обеспечения отказоустойчивости;
— pgbouncer для пула соединений;
— vip-manager для плавающего IP-адреса;
— пакет безопасности securityextensions;
— утилиты для переноса данных;
— документация и инструкции.

Отдельно стоит отметить папку samples — в ней находятся готовые T-SQL и PL/SQL-скрипты, которые можно использовать для быстрой проверки функциональности после установки.

Для каждого механизма есть собственный мануал в формате TXT или PDF.
В комплекте также находятся документация по Мастеру переноса, Мастеру сравнения, Руководство пользователя, README с заметками по установке и release_notes с краткой сводкой изменений версии 18.2.

Человек без ученой степени, который построил первую СУБД и получил за это Премию Тьюринга

В начале 1960‑х инженер Чарльз Бахман работал в General Electric и столкнулся с проблемой: данные хранились хаотично, каждый раз приходилось писать новый код для доступа к ним. Его решение — Integrated Data Store (IDS) — стало первой в мире успешной системой управления базами данных, которая позволяла связывать записи и управлять ими без переписывания программ.

Прошло чуть больше десятилетия, и в 1973 году Бахману вручили Премию Тьюринга — высшую награду в компьютерных науках. Событие было настоящей сенсацией, так как он стал первым лауреатом этой премии без PhD и без академического бэкграунда. Инженер-механик по образованию, чистый практик, который просто решал реальные задачи для компании, в которой он работал.

Но на этом история не заканчивается. В 1974 году на легендарной "Великой дискуссии" он на равных спорил с самим Эдгаром Коддом — отцом реляционной модели данных. Бахман отстаивал сетевой подход, Кодд — реляционный. Их спор не был враждой: они признавали заслуги друг друга, а сам Кодд называл IDS «первой настоящей системой баз данных». Эта полемика двигала вперёд всю индустрию.

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

Когда твоя база данных становится умнее тебя или как ИИ проникает внутрь современных СУБД

Раньше ИИ и база данных жили раздельно: данные хранились в СУБД, а модели крутились где-то рядом. Теперь стена рушится — искусственный интеллект переезжает прямо внутрь СУБД. Вот что происходит прямо сейчас.

1. СУБД помогает настраивать себя сама

Раньше DBA вручную правил индексы и переписывал медленные запросы. Теперь это берёт на себя ИИ.

В SQL Server 2025 механизм Query Intelligence анализирует шаблоны запросов и рекомендует изменения индексов или переписывание запросов с учётом контекста.

2. SQL можно генерировать на естественном языке

Расширение для PostgreSQL pg_ai_query позволяет сделать так:

SELECT generate_query('Дай список клиентов, которые ничего не заказывали за последние 3 месяца');

Поддерживаются OpenAI, Anthropic и Google Gemini.

Oracle Select AI через пакет DBMS_CLOUD_AI делает то же самое: передаёт в LLM промпт с метаданными схемы и возвращает готовый SQL.

Microsoft добавила GitHub Copilot в SSMS 22 — помогает писать, оптимизировать и отлаживать T-SQL.

3. Векторный поиск — новая суперсила СУБД

Раньше для семантического поиска (по смыслу, а не по слову) нужна была отдельная векторная база. Теперь — нет.

SQL Server 2025 ввёл тип VECTOR и индекс DiskANN для быстрого поиска по сходству. Функция VECTOR_DISTANCE считает расстояние через косинусную меру или евклидово расстояние.

PostgreSQL с расширением pgvector — классика для RAG-приложений.

OceanBase в ноябре 2025 открыл под Apache 2.0 AI-базу seekdb с гибридным поиском — одновременно по векторам, полнотекстовым запросам, скалярным полям и пространственным данным.

4. AI-агенты работают с Вашими данными

Oracle AI Database 26ai может использоваться как источник векторных данных для OCI Generative AI Agents. База данных становится бэкендом для агентов, которые принимают решения на основе данных — без выноса информации во внешние системы.

Итог: ИИ внутри СУБД — это реальность для 2026 года. Базы данных становятся самонастраивающимися, разговаривающими (понимают естественный язык), всеядными (скалярные и полнотекстовые данные, графика и мультимедиа, графы, векторы, JSON, геоданные) и агентными.

А главное — мы по-прежнему пишем SELECT. Просто теперь он может значить гораздо больше.

Как Вы думаете, ИИ-агент когда-нибудь заменит DBA полностью? Или это всё равно потребует человеческого контроля? Будем рады обменяться мнениями в комментариях 👇

В этом видео показываю работу службы отчётности Digital Q.DataBase и поддержку RDL (Report Definition Language) — формата описания отчётов, используемого в Microsoft SQL Server Reporting Services (SSRS).

► При миграции с Microsoft SQL Server одной из сложных задач становится сохранение существующей отчётности.
В корпоративных системах могут годами накапливаться сотни и тысячи RDL-отчётов, а их перенос на другой стек способен превратиться в отдельный большой проект.

В Digital Q.DataBase реализована совместимость с RDL и привычными механизмами SSRS, чтобы существующие отчёты и интеграции можно было переносить с минимальными изменениями.

Видео также доступно на:
VK
RuTube
Dzen
YouTube

SELECT DISTINCT ON: недооценённая возможность PostgreSQL

В арсенале PostgreSQL есть множество синтаксических конструкций, которые разработчики знают «в лицо», но редко используют по-настоящему. Одна из них — SELECT DISTINCT ON.

Большинство из нас привыкли к классическому DISTINCT: он убирает полные дубликаты строк. А вот расширение DISTINCT ON используется сильно реже. И напрасно!

DISTINCT ON позволяет оставить только первую строку из каждой группы записей, сгруппированных по указанному полю (или набору полей). При этом возвращается целая строка, а не агрегированное значение, как в GROUP BY.

Классический пример — для каждого клиента получить его самый последний заказ. Без DISTINCT ON пришлось бы использовать оконную функцию или самосоединение. С ним — запрос лаконичен и легко читаем:

SELECT DISTINCT ON (customer_id) 
       id, customer_id, total_amount, created_at
FROM orders
ORDER BY customer_id, created_at DESC;

Что здесь происходит:

DISTINCT ON (customer_id) — говорит СУБД оставить по одной строке на каждого уникального клиента.
ORDER BY определяет, какая именно строка из группы будет выбрана. В примере — самая поздняя (по убыванию created_at).

Важное ограничение, о котором часто забывают: первый столбец (или несколько) в ORDER BY обязан совпадать с полями, указанными в DISTINCT ON. Иначе PostgreSQL не сможет однозначно определить порядок внутри группы, и результат может оказаться недетерминированным. Это не ошибка проектирования, а строгое требование логики: СУБД должна знать, по какому критерию выбирать «первую» строку.

Если в Ваших запросах встречаются задачи типа «самый последний», «самый ранний» или «на максимальную сумму» в разрезе некоторого объекта — присмотритесь к DISTINCT ON. Вы удивитесь, как часто он оказывается именно тем, что нужно, и как редко о нём вспоминают.

Попробуйте в следующий раз — и, возможно, он займёт почётное место в вашем SQL-арсенале. 🐘

СУБД и терабайты мусора. История о том, как "PostgreSQL полетел на Марс"

В одном консалтинговом проекте синхронизация двух серверов БД в легаси-приложении порождала несколько терабайт временных данных в день — при том, что сама БД занимала менее 50 ГБ.

Решение нашлось в двунаправленной логической репликации (bidirectional replication), которая стала возможна благодаря улучшению механизма логической репликации в PostgreSQL, которая впервые появилась в 16 версии этой СУБД. Она позволяет двум экземплярам работать в режиме «активный-активный», синхронизируясь без лавинообразного роста служебных данных. Механизм избавляет от лишних циклов и радикально сокращает накладные расходы.

Эту технику инженер Percona Фернандо Лаударес Камаргос впервые представил на Postgres Conference: Seattle 2024. Но вместо сухих цифр он проиллюстрировал её… космическим круизом на Марс.

Представьте: лайнер с автономной БД под управлением PostgreSQL на борту, связь с Землёй ненадёжна, а данные нужно синхронизировать при редких сеансах. Именно для такого сценария двунаправленная репликация — идеальный спасательный круг.

Конечно, в реальности мы с Вами не управляем космическими кораблями. Но если Ваш проект не летит к Марсу, а просто синхронизирует два дата-центра по ненадежному или медленному каналу связи, то этот механизм PostgreSQL сэкономит вам не терабайты, а нервы. 😉

В этом видео показываю Digital Q.CDC (Change Data Capture) - инструмент для захвата и передачи изменений между СУБД.

Разберём, как CDC позволяет переносить данные без длительного простоя: пока пользователи продолжают работать с исходной системой, изменения фиксируются и передаются в целевую базу.

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

► Основные сценарии использования Digital Q.CDC:

🔹 миграция промышленных баз данных с минимальным окном переключения;
🔹 поддержание актуальной копии данных на резервной площадке;
🔹 передача изменений из транзакционной СУБД в аналитические системы и хранилища;
🔹 консолидация данных из нескольких распределённых систем в единой базе.

Отдельно показываю новый веб-интерфейс Digital Q.CDC.

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

Digital Q.CDC поддерживает двустороннюю репликацию между Digital Q.DataBase и Oracle Database, PostgreSQL и Microsoft SQL Server.

В видео также показываю настройку репликации СУБД Digital Q.DataBase → Oracle, мониторинг обработки изменений, журнал работы, аудит, SMTP-уведомления и разграничение доступа пользователей по ролям.

Видео также доступно на:
VK
RuTube
Dzen
YouTube

#DigitalQCDC #CDC #ChangeDataCapture #СУБД #МиграцияДанных

Давайте чуть подробнее про DGrid.

Мы привыкли, что СУБД работает с таблицами: строки, столбцы, индексы, SQL-запросы.
Но далеко не для всех задач нужна полноценная реляционная модель.

Иногда нужно просто очень быстро сохранить значение по ключу и так же быстро его получить.

Например, состояние пользовательской сессии, параметр приложения, промежуточный результат расчёта или часто используемое значение.

Для таких задач используется модель key-value, «ключ - значение».
Знаем ключ, сразу получаем связанное с ним значение.

В Digital Q.DataBase эту задачу решает DGrid.

Использовать его можно в двух вариантах.

► Первый - внутреннее KV-хранилище Digital Q.DataBase.
Оно работает отдельным процессом под контролем СУБД, и обращаться к нему можно непосредственно из SQL.

► Второй - DGrid как самостоятельный сервис.
Его можно вынести за пределы конкретного экземпляра СУБД и использовать в распределённой конфигурации с автоматическим перераспределением данных между нодами.

При этом DGrid не ограничивается простым key-value.
Он поддерживает и табличные структуры, а работать с данными можно через SQL-функции, собственный API, а также Redis- и Memcached-совместимые протоколы.

Данные могут храниться на уровне сеанса, пользователя или глобально.

Практические сценарии - хранение Web-сессий, кэширование результатов тяжёлых расчётов и промежуточный кэш между компонентами приложения.

► В составе Digital Q.DataBase DGrid также заменил ранее использовавшийся Tarantool DB.

То есть DGrid не заменяет обычное реляционное хранилище, а дополняет его там, где нужен быстрый доступ к данным и другой способ их хранения.

#СУБД #DGrid #KeyValue #Redis

Onyx - модуль Digital Q.DataBase, воспроизводящий функциональность Oracle Database.
И это не только поддержка PL/SQL.
В Onyx реализована функциональность системных пакетов DBMS_* и UTL_*, которые используются в Oracle-приложениях.

Несколько интересных примеров:

DBMS_AQ / DBMS_AQADM - очереди сообщений внутри СУБД: отправка, получение и управление очередями.

DBMS_CRYPTO - хеширование, шифрование/расшифрование и MAC.

DBMS_LOCK - пользовательские блокировки для синхронизации процессов.

DBMS_PARALLEL_EXECUTE - разбиение больших операций на части и их параллельное выполнение.

DBMS_PIPE - обмен сообщениями между сессиями через именованные каналы.

DBMS_SCHEDULER - планирование и выполнение фоновых заданий.

DBMS_SQL - расширенная работа с динамическим SQL: курсоры, параметры, выполнение и получение результатов.

И это только часть реализованных Oracle-пакетов.

Digital Q.DataBase: меняем СУБД, а не приложение.

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

#ЗаменаOracle #OracleDB #Импортозамещение #СУБД

🦆 Как утка по имени Уилбур дала название для DuckDB – самой скачиваемой аналитической СУБД в мире

В 2018 году двое амстердамских учёных из CWI (того самого научного центра, где в 1989-м Гвидо ван Россум начал писать Python) — старший научный сотрудник Ханнес Мюлайзен и его аспирант Марк Расвельдт — начали проект без бюджета, роадмапа и заказчика. Они задались вопросом: почему дата-сайентисты мучаются с медленными dataframe-движками вместо нормальной СУБД? И решили написать свою.

Идея проекта формулировалась просто — «нужна легкая СУБД вроде SQLite, но только для аналитики»: встраиваемый движок без сервера и сложной установки, но оптимизированный под аналитические запросы.

Первое демо с результатами проекта они провели в 2019-м на конференции SIGMOD. Именно тогда мир узнал о СУБД DuckDB - названной так в честь утки по имени Уилбур, принадлежавшей Ханнесу.

В 2021-м Ханнес и Марк основали DuckDB Labs. А 2024-м вышла версия 1.0 с кодовым именем Snow Duck. Сегодня DuckDB — одна из самых популярных аналитических СУБД: миллионы загрузок в месяц и десятки тысяч звёзд на GitHub.

История DuckDB — редкий пример того, как исследовательский проект стал востребованным инструментом для крупнейших корпораций, тысяч стартапов и миллионов специалистов по анализу данных. Просто два умных человека заметили реальную боль data-аналитиков и не стали никого ждать: взяли и сами написали инструмент для решения проблемы. Ну а утка по имени Уилбур им в этом помогла.

С Днём программиста!

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

Мы видим программистов каждый день: они пишут то, что потом живёт в банках, больницах, на транспорте, в магазинах.
Без них любые системы это просто железо.

Спасибо Вам за Вашу работу!
За терпение, за любопытство, за умение не сдаваться, когда что-то не собирается с первого раза.

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