СУБД Digital Q.DataBase

Ваш PostgreSQL умеет рисовать. Буквами!

Сегодня я хочу рассказать Вам о расширении pg_aa, которое позволяет превращать бинарные данные PNG в ASCII-графику прямо внутри PostgreSQL.

PostgreSQL умеет хранить изображения... Но что, если вы хотите не просто хранить картинку, а показать её прямо в psql — без графического клиента, без веб-интерфейса, просто символами?

pg_aa — это расширение для работы с библиотеками ASCII-арта внутри PostgreSQL. Оно добавляет функции, которые превращают бинарные данные PNG в ASCII-графику.

Расширение предоставляет две функции:

· aa_out(bytea, int4) — рендеринг через библиотеку libaa
· caca_out(bytea, int4) — рендеринг через библиотеку libcaca

Обе принимают бинарные данные изображения в формате PNG и желаемую ширину ASCII-арта в символах. Внутри расширение конвертирует картинку в оттенки серого и передаёт в ASCII-рендерер.

Пример вызова для показа картинки из БД:





```sql
-- Создаём таблицу для хранения изображений
CREATE TABLE pictures (
id serial PRIMARY KEY,
name text,
data bytea
);

-- Загружаем PNG-файл в таблицу
INSERT INTO pictures (name, data)
VALUES ('logo', pg_read_binary_file('/tmp/logo.png'));

-- Выводим ASCII-арт через libaa (ширина 80 символов)
SELECT aa_out(data, 80) FROM pictures WHERE name = 'logo';

-- Или через libcaca (ширина 60 символов)
SELECT caca_out(data, 60) FROM pictures WHERE id = 1;
```

На выходе — многострочный текст, который отображается в терминале как ASCII-картинка.
Ширина задаётся вторым аргументом: чем больше значение, тем детальнее изображение.

Ваша СУБД на базе PostgreSQL может делать почти всё. Даже рисовать буквами! 😈

Насколько Вы хороший DBA?

Представьте, что Вы полировали структуру БД, настраивали индексы.
А потом появляется расширение, которое без всякой вежливости выловит всё, что Вы могли сделать не так. Просто, жестко, с черным юмором.

Расширение pg_roast — это своего рода аудитор базы данных, который живёт прямо внутри PostgreSQL и проверяет схему, индексы, безопасность, конфигурацию и запросы.

Создатели расширения вдохновились книгой «PostgreSQL Mistakes and How to Avoid Them».

В отличие от всем известного расширения pganalyze, которое отвечает на вопрос «почему сейчас всё работает медленно?», pg_roast отвечает на вопрос «что неправильно в этой базе и режиме её использования?».

Причем описывает все найденные недочеты на человеческом языке — с сарказмом, но по делу. Идеально для code review или для аудита перед релизом.

Рискнете проверить свою БД?

🗓 36-я годовщина IMDb — Internet Movie Database

17 октября 1990 года Кол Нидхэм опубликовал в USENET-группе rec.arts.movies набор Unix shell-скриптов для поиска по спискам фильмов. Так родилась IMDb — на сегодня крупнейшая онлайн-база данных о кино, телевидении и видеоиграх.

И вот тут интересно рассмотреть как менялся техстек этого проекта:

В 1990 это были Unix shell-скрипты и текстовые файлы, а поиск выполнялся прямо из терминала ОС.

К 1995 это был уже сайт, контент стал доступнен через браузер. Внутреннее ПО было написано с нуля на Perl.

В 1998 проект IMDb покупает Amazon и в несколько итераций буквально перекраивает техстек.

Для начала они перенесли контент из файлов в БД под управлением MySQL. А позднее провели куда более мощные преобразования.

Сегодня «под капотом» у проекта IMDb гибридная архитектура на AWS:
• Amazon DynamoDB — NoSQL и key-value БД;
• Amazon Neptune — графовая БД для хранения связей между сущностями (knowledge graph);
• Amazon OpenSearch — полнотекстовый поиск;
• AWS Lambda + federated GraphQL — 19 субграфов (graphlets) и единый шлюз для клиентов (в IMDb данные для каждого уникального запроса параллельно извлекаются из 19 коллекций);
• Amazon S3 + CloudFront — хранение и раздача статики, предрасчитанных индексов и трейлеров.

И отдельно про «Магический поиск» (Magic Search): каждый, кто хоть раз пользовался IMDb отмечал, что она нереально быстро выдает информацию в ответ на Ваши запросы.

Результаты появляются мгновенно, пока Вы набираете запрос.

Как это работает?
Предположим, что Вы набрали «sta» и получили в ответ киноэпопею Star Wars, сериал Star Trek и актера Сильвестра Cталлоне. IMDb заранее рассчитала все осмысленные варианты, куда входит набранное Вами сочетание букв. Данные по каждому такому варианту сохранены в виде готовых документов. Комбинации, которые ни к чему не ведут (вроде stb), не сохраняются.

В результате поддерживаются в актуальном состоянии около 150 000 статических документов о фильмах и снявшихся в них актерах.

Готовые файлы с этим контентом лежат в Amazon S3 и раздаются через Amazon CloudFront (CDN от Amazon).

За счет использования CDN они физически близки к пользователю и отдача происходит намного быстрее, чем генерация любого динамического контента.

По сути, динамический поиск превратили в раздачу статики. Сервер ничего не генерирует в момент запроса — он просто отдаёт Вам через CDN заранее подготовленный файл. Это и обеспечивает ту самую «магическую» скорость работы под огромными ежедневными нагрузками.

В «кровавом enterprise» корпоративные архитекторы за такое бы руки вырвали любому, кто посмел бы такое предложить.

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

А потому IMDb живет и весьма шустро отвечает под нагрузкой более 200 миллионов запросов в день.

Еще раз поздравляем этот интересный с инженерной точки зрения проект с 36 годовщиной его существования.

Всем хороших выходных и отличного настроения!

Поделюсь немного инсайдами о том, куда движется Digital Q.DataBase

Для начала напомню: в версии 18.2 мы разделили СУБД на три независимых модуля:

⚪Pearl — модуль PostgreSQL

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

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

Каждый из них можно устанавливать, обновлять и сопровождать отдельно.
Если приложениям нужен только PostgreSQL, достаточно Pearl.

А теперь — о том, что впереди и что уже успели сделать.

В 🧊Marble скоро появится полнотекстовый поиск.

В ⚪Pearl готовимся к переходу на PostgreSQL 19.

В ⚫Onyx начали работу над прямым восстановлением дампов Oracle.
Без необходимости сначала разворачивать их в Oracle, а затем переносить базу в Onyx.
Это позволит убрать промежуточный этап миграции.

В нашем Digital Q.CDC (захвате изменения данных) уже появилась возможность репликации DDL и прав доступа.
То есть реплицировать можно не только изменения данных, но и изменения структуры базы и прав доступа.

Вот такие новости изнутри разработки.
Буду делиться подробностями по мере готовности!

Расширяем набор пакетов, доступных в Digital Q.DataBase для тех, кто переходит с Oracle Database.
Сегодня — о пакете DBMS_AQ.

► Для чего он нужен

Пакет DBMS_AQ предоставляет интерфейс к механизму Oracle Advanced Queuing (AQ) — встроенной в СУБД системе обмена сообщениями.
Это позволяет приложениям обмениваться данными асинхронно, через очереди: один процесс помещает сообщение в очередь (enqueue), другой — извлекает его для обработки (dequeue).

►Основные возможности

· ENQUEUE — помещение сообщения в указанную очередь ;
· DEQUEUE — извлечение сообщения из очереди ;
· DEQUEUE_ARRAY — пакетное извлечение нескольких сообщений за один вызов ;
· LISTEN — прослушивание одной или нескольких очередей от имени агентов ;
· REGISTER — регистрация адреса электронной почты, PL/SQL-процедуры или HTTP-URL для уведомлений о поступлении сообщений ;
· Поддержка различных типов полезной нагрузки: RAW, объектные типы, XMLType .

Пример использования





```sql
-- Помещение сообщения в очередь
DECLARE
enqueue_options DBMS_AQ.ENQUEUE_OPTIONS_T;
message_properties DBMS_AQ.MESSAGE_PROPERTIES_T;
message_id RAW(16);
payload VARCHAR2(100) := 'Текст сообщения';
BEGIN
DBMS_AQ.ENQUEUE(
queue_name => 'my_queue',
enqueue_options => enqueue_options,
message_properties => message_properties,
payload => payload,
msgid => message_id);
COMMIT;
END;
```

Области применения

· Асинхронный обмен данными между приложениями;
· Организация очередей задач для фоновой обработки;
· Интеграция с внешними системами через сообщения;
· Замена самописных механизмов очередей на встроенный в СУБД инструмент.

В Digital Q.DataBase реализован наш аналог Service Broker - встроенный механизм асинхронного обмена сообщениями между базами данных через очереди и диалоги.

Принцип работы:
отправитель → очередь сообщений → обработчик.

Отправитель передаёт сообщение, а принимающая сторона извлекает его из очереди для обработки.
Отправителю не требуется ждать завершения обработки сообщения получателем.

► Наш аналог Service Broker позволяет обмениваться сообщениями с Microsoft SQL Server в обоих направлениях, используя стандартные команды T-SQL.

В представленном примере Digital Q.DataBase находится слева, а Microsoft SQL Server 2022 - справа.

Сначала на обеих сторонах создаются службы командой CREATE SERVICE.
Каждая служба связывается с очередью сообщений.
Затем командой CREATE ROUTE настраивается маршрут доставки; в демонстрации проверяется адрес локального сервера localhost.

После настройки командой BEGIN DIALOG CONVERSATION открывается диалог.
Через SEND ON CONVERSATION из Digital Q.DataBase отправляется сообщение в Microsoft SQL Server.
На стороне SQL Server сообщение принимается, и проверяется его содержимое.

Затем Microsoft SQL Server отправляет ответ в рамках того же диалога.
На стороне Digital Q.DataBase ответное сообщение извлекается из очереди и читается.
Таким образом, демонстрация подтверждает успешный двусторонний обмен сообщениями между двумя СУБД.

► Для заказчика наш аналог Service Broker может быть полезен при постепенной (или даже полной) миграции приложений, использующих этот механизм.
Компоненты, работающие на Microsoft SQL Server и Digital Q.DataBase, могут продолжать обмениваться сообщениями при условии поддержки необходимых сценариев.

Схемы обмена сообщениями:

1. Очередь сообщений: отправитель → очередь → обработчик.

2. Publisher / Subscriber: одно событие доставляется нескольким подписчикам.