О замене Service Broker при помощи Digital Q.DataBase

Для начала напомню о том, что это за механизм:

В оригинальном MS SQL Server есть возможность работать в нескольких базах данных или даже на нескольких серверах в режиме асинхронной отправки/получения сообщений. Можно организовать диалог между двумя БД (даже на разных серверах), передавая информацию о тех или иных событиях, при этом отправитель не обязан ждать доставки сообщения и реакции получателя. Многие крупные информационные системы, работавшие на MS SQL Server использовали и по сей день продолжают использовать эту функциональность. Похожие механизмы есть и в СУБД Oracle, а вот в классическом PostgreSQL ничего подобного нет, а потому и заменить эту функциональность при переходе на многие из отечественных СУБД просто нечем.

Развивая функциональность Digital Q.DataBase, мы пошли по пути максимально точного воспроизведения функциональных возможностей MS SQL Server и Oracle Database. Наша СУБД-полиглот поддерживает как синтаксис SQL-диалектов этих СУБД, так и то, что за ним стоит. И, разумеется, мы не могли пройти мимо такого важного блока функциональности MS SQL Server.

В диалекте T-SQL в нашей СУБД Digital Q.DataBase, начиная с версии 18, появились новые команды:

ALTER DATABASE <db> SET ENABLE_BROKER - Включает эмуляцию Service Broker в указанной БД;

ALTER DATABASE <db> SET DISABLE_BROKER - Отключает эмуляцию Service Broker в указанной БД;

CREATE MESSAGE TYPE - Создаёт тип сообщения;

DROP MESSAGE TYPE - Удаляет тип сообщения;

CREATE CONTRACT - Создаёт контракт информационного обмена и задает набор разрешённых типов сообщений;

DROP CONTRACT - Удаляет контракт информационного обмена;

CREATE QUEUE - Создаёт очередь сообщений;

DROP QUEUE - Удаляет очередь сообщений;

CREATE SERVICE ... ON QUEUE ... - Создаёт службу Service Broker и привязывает её к очереди и к контрактам;

DROP SERVICE - Удаляет службу;

CREATE ROUTE ... WITH SERVICE_NAME = ..., ADDRESS = ... - Создаёт маршрут для межбазовой доставки сообщений;

DROP ROUTE - Удаляет маршрут;

BEGIN DIALOG  - Открывает новый диалог;

SEND ON CONVERSATION - Отправляет сообщение в открытый диалог;

RECEIVE - Читает сообщение из очереди;

WAITFOR (RECEIVE ...) - Ждёт сообщение из очереди;

END CONVERSATION - Завершает диалог;

END CONVERSATION ... WITH CLEANUP - Принудительно завершает диалог;

GRANT SEND ON SERVICE::... - Выдаёт право на отправку в службу;

REVOKE SEND ON SERVICE::... - Забирает право на отправку в службу;

GRANT RECEIVE ON QUEUE::... - Выдаёт право на чтение из очереди;

REVOKE RECEIVE ON QUEUE::... - Забирает право на чтение из очереди.

Некоторые из вышеприведенных команд реализованы с упрощениями по отношению к оригинальному MS SQL Server, однако в достаточном объеме для подавляющего большинства вариантов использования в российских информационных системах. В дальнейшем мы планируем избавиться от этих упрощений и поддержать все нюансы синтаксиса этих команд, в точности как в оригинальном MS SQL.

Важно отметить, что данные команды позволяют наладить информационный обмен не только локально, внутри одной или нескольких БД на одном сервере Digital Q.DataBase, но и между несколькими серверами. Причем поддерживается возможность двустороннего информационного обмена между серверами Digital Q.DataBase и оригинальными серверами Microsoft SQL Server. Мы аккуратно воспроизвели в своей СУБД соответствующий транспортный протокол.

Также поддержана эмуляция системных представлений sys.routes, sys.databases, sys.conversation_endpoints и sys.transmission_queue.

Как и в оригинальном MS SQL Server обеспечивается гарантированная доставка сообщений. Это очень похоже на использование Kafka, но работает в разы быстрее,т надежнее и не требует установки какого-либо дополнительного ПО, так как это встроенная в саму СУБД функциональная возможность.

Поддержка функциональности Service Broker позволила нам стать еще ближе к выполнению нашей главной задачи - беспроблемной замены MS SQL Server его российским аналогом в лице нашей СУБД.

Не требуется менять хранимые процедуры, переписывать прикладной софт, перестраивать информационный обмен.

Просто ставим сервер Digital Q.DataBase вместо MS SQL Server, переносим в него нужные базы нашим Мастером переноса БД и продолжаем работать как раньше.

Мы надеемся, что с нашей помощью задача импортозамещения СУБД превратится в рутинную задачку на пару дней для одного системного администратора, а не будет большим и малопредсказуемым проектом с огромным числом участников и тысячами задач для прикладных разработчиков, как это выглядит сейчас при переходе на некоторые из российских СУБД!