Дорогие подписчики!
Дорогие подписчики! → Мы продолжаем начатый на нашем вебинаре обзор функциональности новой версии Digital Q.DataBase и сегодня поговорим о таком механизме как Service Broker. → Для начала напомню о том, что это за механизм: В оригинальном 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, но работает в разы быстрее, надежнее и не требует установки какого-либо дополнительного ПО, так как это встроенная в саму СУБД функциональная возможность.