Как отслеживать и выводить обновления базы данных?

Question

[WhileAD]

Нужно создать чат на asp dot net core 6 с базой данных mysql. Для этого нужно отслеживать и выводить изменения в базе данных.
Решил попробовать через websocket. Создал сервер:

WebSocketServer wssv = new WebSocketServer("Айпи и порт");
wssv.AddWebSocketService<Echo>("/Echo");
wssv.Start();

И в том же проекте:

WebSocket ws = new WebSocket("Айпи и порт");
    ws.Connect();

После чего просто выводил SELECT'ом последние строки и сравнивал (с помощью while(tue)). Я знаю что это нагружает базу и не очень оптимизировано.

Answer 1

[Akina]

Есть ли другие способы как реализовать мою задумку или оптимизировать уже имеющийся?

Да цельный воз и маленькая тележка.

Обычно у каждой записи в БД имеется поле, в котором регистрируется штамп времени создания и/или последнего обновления записи. Так что всего и делов - запомнить, когда последний раз обращались к БД, и в следующий раз запросить те записи, что изменены позже. MySQL позволяет получать штамп времени с точностью до микросекунды.

Или уж совсем по-простому. В каждой таблице держим синтетический первичный ключ-автоинкремент, и по аналогичной схеме запоминаем, каким было максимальное значение при предыдущем обращении.

Answer 2

[Сергей Соловьев]

1. Здесь, скорее всего нужны триггеры. На SO есть похожий вопрос - https://stackoverflow.com/questions/26418412/how-t...
2. В данном случае, тебе нужно использовать больше чем 1 СУБД. Предлагаю такой вариант:
- MySQL - для хранения всех сообщений
- Redis - для очереди событий

Алгоритм такой:
1. Кто-то отправляет сообщение
2. Сохраняешь сообщение в БД
3. Публикуешь событие "сообщение добавлено"
4. Все подписавшиеся отправляют это сообщение своим клиентам

Получение истории - при первом подключении (это уже SELECT)

Т.е. тут без активного опроса.
P.S. если сервер только 1, то и какая-нибудь inmemory очередь сообщений сойдет.

3. SignalR твою проблему не решит - это просто фреймворк поверх вебсокета (рекомендую использовать его, т.к. облегчает многие задачи). Твоя проблема кроется скорее в слое хранения, т.к. mysql (как и любая другая реляционная СУБД) плохо заточена под event-driven архитектуру, скорее запрос-ответ.

Comments

[Akina]

mysql (как и любая другая реляционная СУБД) плохо заточена под event-driven архитектуру

Ну насчёт "любая" - наверное, излишне категорично. Скажем, в том же Постгрессе есть LISTEN/NOTIFY. Опять же многие СУБД позволяют подключать внешние модули, которые вполне себе способны генерировать и слать уведомления.

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

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