► Продолжаем рассказывать о встроенных пакетах Digital Q.DataBase, обеспечивающих совместимость с PL/SQL-окружением Oracle.
Мы поддержали пакет DBMS_CRYPTO.

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

► Пакет DBMS_CRYPTO предоставляет функции для шифрования, дешифрования и хэширования данных. В Oracle он пришёл на смену DBMS_OBFUSCATION_TOOLKIT и содержит более широкий набор криптографических алгоритмов .

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

· ENCRYPT / DECRYPT — шифрование и дешифрование данных (RAW, BLOB, CLOB);
· HASH — вычисление хэш-значений (MD5, SHA-1, SHA-2);
· MAC — хэширование с секретным ключом для проверки подлинности;
· RANDOMBYTES — генерация криптографически стойкой случайной последовательности.

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

-- Шифрование и дешифрование строки
DECLARE
    l_src RAW(128) := UTL_RAW.cast_to_raw('Секретные данные');
    l_key RAW(128) := UTL_RAW.cast_to_raw('0123456789abcdef');
    l_enc RAW(2048);
    l_dec RAW(2048);
BEGIN
    l_enc := DBMS_CRYPTO.ENCRYPT(l_src, DBMS_CRYPTO.ENCRYPT_AES256 + DBMS_CRYPTO.CHAIN_CBC + DBMS_CRYPTO.PAD_PKCS5, l_key);
    l_dec := DBMS_CRYPTO.DECRYPT(l_enc, DBMS_CRYPTO.ENCRYPT_AES256 + DBMS_CRYPTO.CHAIN_CBC + DBMS_CRYPTO.PAD_PKCS5, l_key);
    DBMS_OUTPUT.PUT_LINE(UTL_RAW.cast_to_varchar2(l_dec));
END;

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

· Шифрование персональных данных и платёжной информации;
· Проверка целостности данных через хэш-значения;
· Аутентификация файлов и сообщений с помощью MAC;
· Генерация случайных ключей для криптографических операций.

В Digital Q.DataBase, в модуле Onyx, предназначенном для замены Oracle Database, добавлена поддержка типов ANYDATA и ANYDATASET.

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

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

ANYDATA — самоописываемый тип, который содержит как данные, так и информацию о своём типе . Может хранить значения NUMBER, DATE, VARCHAR2, RAW, BLOB, CLOB, объектные типы и коллекции . Для создания значений используются методы ConvertXXX (например, ConvertNumber, ConvertVarchar2), а для извлечения — методы GetXXX .

ANYDATASET — тип для работы с набором данных одного типа . Позволяет хранить несколько экземпляров и последовательно их обрабатывать .

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

-- Создание и использование ANYDATA
DECLARE
    v_data SYS.ANYDATA;
    v_num  NUMBER;
BEGIN
    v_data := SYS.ANYDATA.ConvertNumber(12345);
    
    IF v_data.GetNumber(v_num) = DBMS_TYPES.SUCCESS THEN
        DBMS_OUTPUT.PUT_LINE('Число: ' || v_num);
    END IF;
END;

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

· Универсальные буферы для обмена данными между системами с разными типами;
· Промежуточное хранение результатов динамических запросов;
· Построение гибких ETL-конвейеров.

Пишем функции для PostgreSQL на… BASIC? 😳

Сегодня, в качестве "поста выходного дня" хочу рассказать Вам об одном довольно необычном расширении для СУБД на базе PostgreSQL.

Сейчас уже никого не удивить тем, что хранимую логику в PostgreSQL можно писать не только на PL/pgSQL, но и на Java или C#. Однако иногда сообщество PostgreSQL создаёт воистину необычные вещи, от которых у старшего поколения разработчиков наворачивается ностальгическая слеза, а у младшего — удивленно округляются глаза.

Встречайте: PL/CBMBASIC — расширение, которое позволяет писать функции для PostgreSQL на Commodore 64 BASIC V2.

Внутри расширения работает настоящий интерпретатор BASIC образца 1982 года, извлеченный из ПЗУ Commodore 64. Каждый вызов функции — это, по сути, «перезагрузка» виртуального компьютера: обнуляется 64 КБ памяти, сбрасываются регистры, и управление передаётся по адресу $E394. Всё это занимает около 15–20 микросекунд — примерно в тысячу раз быстрее, чем на настоящем C64.

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

Выглядит это так:

CREATE EXTENSION plcbmbasic;

CREATE FUNCTION hello(who text) RETURNS text AS $$
10 PRINT "HELLO, ";WHO$;"!"
$$ LANGUAGE plcbmbasic;

Если хотите сильно удивить коллег или подшутить над ними — «запилите» кусочек хранимой логики столь экзотическим образом. Правда, есть риск, что в качестве «ответки» Вам прилетит хранимая функция на языке BrainF*ck 🤦

Расширение, которое ломает PostgreSQL... чтобы проверить выживет ли он 💥

В сегодняшем «посте выходного дня» я продолжу начатую вчера тему о необычных расширениях для СУБД на базе PostgreSQL и расскажу Вам о pg_kaboom.

Это, пожалуй, самый «разрушительный» и одновременно полезный для тестирования DR проект. Название обыгрывает англоязычное подражание звуку взрыва. По-русски это было бы «бабах!».

Это расширение намеренно «крашит» сервер PostgreSQL самыми разными способами. Цель отнюдь не вредительство, а тестирование отказоустойчивости: можно симулировать нехватку места на диске, segfault, разрушение данных и другие катастрофы прямо из SQL-запроса. Это удобно для проверки систем автоматического переключения (failover) и отработки действий при сбоях.

⚠️ Критически важные предупреждения

Никогда не используйте это расширение на production-средах. Оно предназначено исключительно для тестовых или изолированных сред.

Защита «от дурака» также присутствует. Функции не сработают, пока вы не установите специальный параметр pg_kaboom.disclaimer в значение 'I can afford to lose this data and server'. Для некоторых способов уничтожить сервер дополнительно требуется pg_kaboom.execute = on.

🛠️ Установка и использование

1. Установка расширения в БД (предполагается, что само расширение уже скомпилировано):

   CREATE EXTENSION pg_kaboom;
   

2. Установка «предохранителя» (обязательно в каждой сессии):

   SET pg_kaboom.disclaimer = 'I can afford to lose this data and server';
   -- При необходимости:
   SET pg_kaboom.execute = on;
   

3. Вызов основной функции: pg_kaboom(text) с названием выбранного Вами «оружия».

4. Вспомогательная функция pg_kaboom_arsenal() возвращает таблицу со списком всех доступных «оружий».

☠️ Арсенал «оружия»

· break-archive — устанавливает нерабочую команду archive_command и заставляет сервер перезапуститься, что приводит к сбою архивации WAL.

· fill-log — заполняет всё доступное пространство в каталоге логов (log_directory).

· fill-pgdata — заполняет всё доступное пространство в основном каталоге данных ($PGDATA).

· fill-pgwal — заполняет всё
доступное пространство в каталоге WAL ($PGDATA/pg_wal), что быстро приводит к остановке сервера.

· mem — выделяет большой объём оперативной памяти, провоцируя OOM-killer или сбой.

· restart — выполняет немедленный перезапуск сервера.

· rm-pgdata — выполняет rm -Rf $PGDATA. Самый разрушительный вариант.

· segfault — вызывает segmentation fault в работающем бэкенд-процессе.

· signal — отправляет сигнал SIGKILL процессу Postmaster.

· xact-wrap — быстро вызывает переполнение счётчика транзакций.

· random — выбирает случайное «оружие» из списка и применяет его. Отличный способ проверить устойчивость инфраструктуры к заранее неизвестному сбою сервера.

· null — не делает ничего.

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

Полностью поддержан пакет DBMS_JOB

В Digital Q.DataBase теперь полностью поддерживается DBMS_JOB, классический планировщик заданий Oracle.

Регламентные задачи, которые годами работают в Oracle-приложениях (ночные расчёты, закрытие дня, рассылки, очистка данных), переносятся в Q.DataBase без переписывания кода.

► Что поддержано

• Все документированные процедуры пакета: SUBMIT, ISUBMIT, RUN, REMOVE, CHANGE, WHAT, NEXT_DATE, INTERVAL, INSTANCE, BROKEN, USER_EXPORT.

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

• Повторяющиеся задания с интервалом в виде выражения Oracle, например 'TRUNC(SYSDATE) + 1 + 2/24'.

• Поведение как в Oracle: после 16 неудачных запусков подряд задание помечается как сломанное (broken). Процедура RUN запускает задание вручную, даже сломанное.

• Представления DBA_JOBS, USER_JOBS и DBA_JOBS_RUNNING для мониторинга заданий.

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

DECLARE
  l_job BINARY_INTEGER;
BEGIN
  DBMS_JOB.SUBMIT(
    job       => l_job,
    what      => 'billing.close_day;',
    next_date => TRUNC(SYSDATE) + 1 + 2/24,
    interval  => 'TRUNC(SYSDATE) + 1 + 2/24');
  COMMIT;
END;

Задание будет каждую ночь в 02:00 закрывать операционный день, как и в Oracle.

Мастер переноса БД переносит задания DBMS_JOB вместе со схемой. На время загрузки данных задания отключены, после загрузки включаются, поэтому регламент не запустится на неполных данных.

DBMS_JOB работает вместе с современным планировщиком DBMS_SCHEDULER: в Q.DataBase доступны оба механизма.

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

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

Пакет DBMS_ROWID предоставляет функции для работы с ROWID — уникальными идентификаторами строк в таблицах Oracle. Пакет позволяет создавать ROWID и извлекать информацию о них из PL/SQL-программ и SQL-выражений, не разбирая вручную внутренний base-64 формат .

► Основные функции

· ROWID_CREATE — создаёт ROWID из составных частей (для тестирования);
· ROWID_INFO — возвращает тип и компоненты ROWID;
· ROWID_TYPE — возвращает тип ROWID (0 — restricted, 1 — extended);
· ROWID_OBJECT — возвращает номер объекта данных;
· ROWID_RELATIVE_FNO — возвращает номер файла;
· ROWID_BLOCK_NUMBER — возвращает номер блока;
· ROWID_ROW_NUMBER — возвращает номер строки;
· ROWID_TO_EXTENDED / ROWID_TO_RESTRICTED — конвертируют ROWID между форматами.

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

DECLARE
    row_id    ROWID;
    object_no INTEGER;
BEGIN
    SELECT ROWID INTO row_id FROM emp WHERE empno = 7499;
    object_no := DBMS_ROWID.ROWID_OBJECT(row_id);
    DBMS_OUTPUT.PUT_LINE('Номер объекта: ' || object_no);
END;

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

· Определение физического расположения строки (файл, блок) без прямого разбора ROWID;
· Конвертация ROWID между ограниченным и расширенным форматами;
· Проверка валидности ROWID перед операциями;
· Диагностика проблем с блоками данных.

Можно ли при импортозамещении поменять СУБД, не переписывая вместе с ней всё приложение?

Именно этот вопрос на INFOSTART TECH EVENT 2026 поднял Андрей Жуйков, Руководитель направления СУБД Digital Q.DataBase.
В своем выступлении он развеял главный миф импортозамещения: переход с Oracle или MS SQL Server не обязательно означает годы разработки, переписывание кода и остановку бизнес-процессов.

Мы на практике доказываем обратное.
Вот 5 ключевых отличий Digital Q.DataBase, которые меняют правила игры:

1. Совместимость, а не просто «база на PostgreSQL»

Мы поддерживаем диалекты T-SQL и PL/SQL «из коробки». Ваши существующие хранимые процедуры, функции, триггеры и даже пакеты Oracle (DBMS_, UTL_, OWA) исполняются без переделки. Приложение продолжает «думать», что работает с родной СУБД.

2. Миграция без остановки бизнеса

Вместо «большого взрыва» мы предлагаем контролируемый переход: встроенные инструменты переноса данных, автоматическая проверка результатов миграции и встроенный CDC (Change Data Capture) для непрерывной синхронизации. Даже корпоративная отчетность на базе RDL/SSRS продолжит работать.

3. Возможности за пределами классического PostgreSQL

Мы не просто форк, мы расширяем границы:
► In-memory компонента DGrid для сверхбыстрой аналитики;
► Персистентное Key-Value хранилище;
► Встроенные очереди сообщений (Publisher/Subscriber);
► Диагностика производительности в привычном для DBA стиле Oracle AWR/ASH.

4. Встроенный AI, а не сторонние «костыли»

Векторный поиск — это часть ядра. Нативный тип данных VECTOR, генерация эмбеддингов непосредственно из СУБД, поддержка индексов DiskANN и бесшовная интеграция как с внешними, так и с локальными LLM-моделями.

5. Прозрачная экономика

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

Главный вывод доклада:

Поменять СУБД без переписывания приложения реально. Но только если выбрать платформу, которая говорит с вашим кодом на его родном языке.

Хотите увидеть, как это работает на практике?

► Вопросы по настройке и внедрению можно направлять на наш адрес службы поддержки: supportqdb@diasoft.ru

Рассказываем о пакетах, поддержанных в Digital Q.DataBase для совместимости с PL/SQL-окружением Oracle.
Сегодня — о пакете UTL_RECOMP.

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

► Пакет UTL_RECOMP предназначен для перекомпиляции недействительных (invalid) объектов PL/SQL, представлений, Java-классов, индексов и операторов. Он особенно полезен после крупного обновления версии, когда все объекты становятся недействительными.

► Хотя недействительные объекты перекомпилируются автоматически при первом обращении, предварительный запуск UTL_RECOMP позволяет избежать задержек при выполнении операций в дальнейшем.

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

· RECOMP_SERIAL — последовательная перекомпиляция недействительных объектов в указанной схеме или во всей базе данных;

· RECOMP_PARALLEL — параллельная перекомпиляция с использованием нескольких потоков. Количество потоков задаётся первым аргументом, если не указано — используется значение параметра job_queue_processes;

· Параллельная перекомпиляция задействует несколько процессоров и сокращает время обработки, однако создаёт значительную нагрузку на дисковую подсистему.

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

-- Последовательная перекомпиляция всех объектов в базе
EXEC UTL_RECOMP.RECOMP_SERIAL();

-- Перекомпиляция объектов в схеме SCOTT
EXEC UTL_RECOMP.RECOMP_SERIAL('SCOTT');

-- Параллельная перекомпиляция с 4 потоками
EXEC UTL_RECOMP.RECOMP_PARALLEL(4);

-- Перекомпиляция схемы JOE с числом потоков по умолчанию
EXEC UTL_RECOMP.RECOMP_PARALLEL(NULL, 'JOE');

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

· Перекомпиляция объектов после миграции или крупного обновления;
· Восстановление работоспособности приложений после изменения схемы;
· Оптимизация производительности за счёт устранения недействительных объектов.

Сегодня 10 октября и это значит, что проекту "ВКонтакте" исполнилось 20 лет.

Для нас, людей из мира данных, эта дата интересна прежде всего инженерной стороной вопроса. VK начинался как студенческий проект одного всем известного человека — и писался с нуля: без сторонних библиотек и фреймворков, от личных сообщений до поиска.

И вот здесь начинается самое любопытное для DBA.

То, что начиналось как PHP-монолит на MySQL, сегодня — экосистема, которая пережила несколько волн переписывания архитектуры. Пик нагрузки VK — около 3 млн запросов в секунду, петабайты данных, сотни миллионов пользователей. Обычный MySQL с этим бы не справился — и не справился. Отсюда рост в сторону распределённых решений: шардирование, Galera Cluster для синхронной репликации, вынос аналитики в ClickHouse, переход на Go-сервисы и современные open-source СУБД.

Сейчас в стеке VK — PostgreSQL, MongoDB, Redis, Cassandra, ClickHouse, Kafka. Это уже не «сайт для студентов», а распределённая система, которая по сложности сопоставима с инфраструктурой любого глобального игрока.

Что полезного тут можно вынести для себя?

Пожалуй, одну простую мысль: любая система начинается с малого. MySQL в 2006-м казался достаточным. Через пять лет — перестал. Через десять — потребовалась собственная распределённая платформа.

Хороших Вам выходных, коллеги!

Расширение pg_when — человеческий способ записывать время

Сколько раз составляя SQL-запрос Вы мучались, высчитывая выражения дат и времени для критериев отбора? Расширение pg_when решает эту задачу элегантно: оно парсит естественный язык (к сожалению, только английский) и возвращает timestamptz (или Unix epoch в секундах, миллисекундах, микросекундах).

Запрос для функций из pg_when состоит из трёх компонентов — дата, время, часовой пояс — соединённых ключевыми словами at и in.

Несколько примеров:

-- Начало текущего часа, но 5 дней назад, в Москве
SELECT when_is('5 days ago at this hour in Europe/Moscow');

-- Следующая пятница, 20:00, в Москве
SELECT when_is('next friday at 20:00 in Europe/Moscow');

-- Ровно через 2 месяца, полночь, GMT+3
SELECT when_is('in 2 months at midnight in UTC+3');

-- Новогоднее выступление
SELECT when_is('31/12/2026 at 23:55');

-- Те же значения, но в Unix epoch
SELECT seconds_at('5 days ago at this hour in Europe/Moscow');
SELECT millis_at('5 days ago at this hour in Europe/Moscow');
SELECT micros_at('5 days ago at this hour in Europe/Moscow');

Поддерживаются относительные даты (today, yesterday, next week, last month, in 2 years), точные даты в разных форматах (YYYY-MM-DD, DD/MM/YYYY, 31-12-2026), время (midnight, evening, 20:00, 22:30) и именованные часовые пояса. Если часовой пояс не указан — используется UTC.

Расширение pg_when особенно полезно для создания запросов вида «покажи заказы за последнюю неделю» так, чтобы они работали каждый день без модификации их текста и при этом сохраняли «читаемость».

Рассказываем о пакетах, поддержанных в Digital Q.DataBase для совместимости с PL/SQL-окружением Oracle.
Сегодня — о пакете DBMS_XMLPARSER.

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

► Пакет DBMS_XMLPARSER предоставляет интерфейс для чтения XML-документов и доступа к их содержимому и структуре . Он следует спецификации W3C XML и строит дерево разбора, доступное через DOM API .

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

· newParser — создаёт новый экземпляр парсера ;
· parseBuffer / parseClob — разбирает XML из строки или CLOB ;
· parse — разбирает XML из файла или URL ;
· getDocument — возвращает DOM-документ после разбора ;
· freeParser — освобождает ресурсы парсера .

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

DECLARE
  myparser DBMS_XMLPARSER.parser;
  indomdoc DBMS_XMLDOM.DOMDocument;
  indoc    VARCHAR2(2000);
BEGIN
  indoc := '<emp><name>De Selby</name></emp>';
  myParser := DBMS_XMLPARSER.newParser;
  DBMS_XMLPARSER.parseBuffer(myParser, indoc);
  indomdoc := DBMS_XMLPARSER.getDocument(myParser);
  -- работа с DOM-документом
  DBMS_XMLPARSER.freeParser(myParser);
END;

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

· Разбор входящих XML-сообщений без внешних парсеров;
· Построение DOM-дерева для последующей обработки;
· Интеграция с системами, обменивающимися XML-данными.

До второго Дня СУБД осталось всего 2 недели!

► Встречаемся уже 27 октября!
Если вы планируете миграцию с MS SQL или Oracle, хотите увидеть живые демо-стенды без необходимости переписывать код и лично пообщаться с командой разработки Digital Q.DataBase — это событие создано именно для вас!

Когда: 27 октября, 14:00–23:00 (МСК)
Где: Москва, Кибердом (м. «Улица 1905 года», 2-я Звенигородская ул., 12с18)

► И это не только про технологии: помимо насыщенной деловой программы, гостей ждут вкусный фуршет и отличная развлекательная программа!

► Вход свободный успейте забронировать место:
https://dbd.diasoft.ru

В 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: одно событие доставляется нескольким подписчикам.

Расширяем набор пакетов, доступных в 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.

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

-- Помещение сообщения в очередь
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

Для начала напомню: в версии 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 и прав доступа.
То есть реплицировать можно не только изменения данных, но и изменения структуры базы и прав доступа.

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

🗓 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 годовщиной его существования.

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

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

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

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

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

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

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

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