Есть ли какие-нибудь СУБД, которые могут уведомлять клиентов об изменении данных?
Задача такая: Есть некий сервис (назовём его A), который меняет данные в базе, и несколько других сервисов (назовём их B), которые должны на эти изменения реагировать.
Существует ли такая фича в каких-то СУБД? Если нет, то какие ещё есть альтернативные способы решения такой задачи, кроме всяких очередей сообщений и пушинга сервисов B со стороны сервиса A? (в идеале хочется, чтобы A и B ничего друг о друге не знали).
Сервисы могут, и скорее всего будут разнесены по разным машинам.
Всё зависит от того, что из себя представляет ситуация, когда B не онлайн. Если B все изменения должна 'пережить', которые происходят, даже в её отсутствие, то это одно решение, если эт не важно, то это уже другое.
Всё зависит от того, что из себя представляет ситуация, когда B не онлайн
Если B оффлайн и пропустит уведомления - ничего страшного. Полностью сканить базу при запуске достаточно недорого (ибо записей будет порядка десятков тысяч).
Пока из ответов прихожу к варианту, чтобы B всё-таки знали об A и периодически пуллили у него информацию об изменениях.
Возможно, даже через grpc.
Василий Банников, А, если из таких систем как кафка подсмотреть реализацию. Мне что-то "знание" у В о А не нравиться вообще.
1. Для этого и должна быть или база данный сама по себе, т.е. и данные хранятся там и все изменения триггерами собираются в доп. талицу. Надо просто определиться что за изменения нужны для информации.
2. Или доп. протокол создать, где все иземения в виде телеграм ставяться в очередь и могут быть считаны с любого момента времени.
Первое решение с триггерами мне нравиться больше, т.к. оно интегрируется в саму суть и логика находиться в базе, что для В постовляется и нужно. Во втором варианте мне не нравиться усложнение доп. логикой для очереди и необходимостью создавания доп. логики для интерпретации очереди на стороне В.
Но запросы от В к А об изменениях - мне это вообще не нравится. Как-то противоречит принципам - кто за что ответствен. Плюс. Представьте себе - завтра не только одна машина пишит в базу. А это процесс скалируется на несколько нодов. Какой из них спрашивать, какие измененния произошли? Нет, для этого база данных и существует. Только она знает, что измененно. Хотя, может быть мне деталей для большего понятия вашей идеи не хватает.
Вопрос как раз о транспорте, который для этих евентов можно использовать.
Первое что приходит в голову - очереди (что-нибудь типа общей шины) и вебхуки.
Тк состояние надо ещё и хранить - значит очередь становится дополнительной сущностью к уже существующей базе, а ведь ещё нужен кто-то кто эти события должен отправлять - это ещё + сущность.
А вебхуки создают слишком жёсткую связь, тк отправитель события должен знать про слушателя.
Предполагал, что возможно есть что-то уже существующее, что позволит решить задачу чуть проще.
В БД Oracle есть постоянные активности.. например работы и шедулеры, а так же триггеры. и все они могут например отправить смс или письмо и естественно они сами могут запустить процедуры и функции которые есть в БД.
Триггеры реагируют на изменения в БД, а роботы запускают проверку по времени...
Средний
