Node JS + Mysql Как постоянно проверять появление новых элементов в базе?

Question

[Sergo Sergo]

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

Answer 1

[Дмитрий Миронов]

Если нужно совершать операции в базе при вставке, то можно триггеры использовать habrahabr.ru/post/37693

Answer 2

[Дмитрий Энтелис]

Мне кажется что для таких историй гораздо лучше реализовать на уровне приложения логику, что при создании новой записи, уведомление об этом событии, а то и само событие - попадает в некую рассылку из которой его читают все желающие.
Для этого отлично подходит сервер очередей RabbitMQ или хотя бы Redis.

UPD Написанное выше верно если у Вас в базу пишет кто то кроме Вашего приложения на node.js

Comments

[whats]

Может быть еще Open Office установить и ваш любимый сфинкс. Записывать в ексель документ запись о добавлении в таблицу, индексировать сфинксом это все дело и потом еще Рэббит подключить. Огненный стек получится, а главное столько всего подключено, как вы любите!!!

Зачем все это тут нужно ? Какая разница что пользователь будет стучаться за данными в базу и смотреть появилось что-то или нет, или в вашу очередь ? Что от этого меняется ? ЗАЧЕЕЕЕМ тут вообще эта очередь ?

Тут если идет соединение на сокетах то пусть при добавлении в базу и посылает ответный месседж всем слушателям.

Если без них то по таймеру как указал автор с указанием последнего полученного значения.

[Дмитрий Энтелис]

whats:
Спасибо за внимание к моей персоне, даже зачитался.
Я не сторонник какой то дикой каши технологий, у меня достаточно небольшой любимый стек и я искренне уверен что есть объективно задачи которые по моему опыту удобнее и быстрее выполнять определенным образом.

Далее отвечу по сути комментария:

Для доставки событий ничего лучше чем очереди пока не придумали.
Вы реально не понимаете разницы между запросами в базу и подпиской на событие очереди?
Начнем хотя бы с того маленького факта что в первом случае а) будет достаточно большой лаг обработки события, равный времени таймера запроса б) при росте количества воркеров будет расти количество запросов, что с вкупе с пунктом А дает пусть и не особо большую - но все равно абсолютно излюшнюю нагрузку на sql.

Идея с соединением на сокетах в целом лучше, но включая режим телепата - как правило логика которая пишет в базу все таки отделена от демона сокетов. Соответственно надо научить подключаться к нему, убеждаться что все хорошо, прописывать поведение когда демон мертв, думать что делать если демонов несколько итд итп, в общем изобретать кучу велосипедов которые отлично решаются с помощью любого из существующих серверов очередей. Не нравится Rabbit - возьмите Gearman, возьмите ZeroMQ. Но не надо писать велосипеды.

[whats]

Дмитрий Энтелис: может быть вы не понимаете того что понимаю я ? Или я не понимаю. Разберите пожалуйста мои мыли, и укажите в чем я могу быть не прав.

Есть 2 абстракции. Первая (А) - я ,который сижу на какой либо странице и жду когда что-то произойдет. В данной ситуации база данных обновилась. Вторая (Б) - человек который обновил базу скриптом на нашем сервере.
Вариант 1. Веб сокеты.
Приложение подобно чату. Мы записываем всех подключенных клиентов. (Б) при вызове метода добавления в базу чего-либо вызывает метод add. Который у нас проходится по всем слушателям и отправляет им сообщение методом send. Они же подписаны на событие message и обновляют информацию на экране. (А) видит что в базу что-то попало.

Вариант 2. Ajax
Мы раз в 2-3 секунды стучимся на сервер и опрашиваем базу банальным и самым быстрым запросом на чтение где берем например максимальный идентификатор и сравниваем его с уже имеющимся, и выбираем нужные нам данные. Можно даже 1 запросом это делать. Запрос такой 3-5 мс выполняется. Время на подключение к базе не учитываем, можно не открывать каждый раз новое подключение. Издержки практически нулевые.

Вот 2 моих варианта. Без каких либо добавлений в стек технологий.
Первый вариант я с вашим не рассматриваю, мой уже лучше и быстрее. Так как нет никаких издержек на не нужные очереди, при добавлении данных в базу мы сразу рассылаем всем подключившимся информацию.

Второй вариант. Разницы никакой нет, вы подключаетесь к рэббиту через брокера, либо вы подключаетесь к базе. Лага никакого нет, не забывайте что мы делаем это не на соккетах и при обращении к очереди вы так же испытаете эту задержку. Как вы собираетесь по другому пути обращаться к очереди я не понимаю. Какие воркеры вы имеете ввиду ? 1 воркер = 1 запрос который потом отпадает.

Почему логика отделена, при чем тут демон, мы о nodejs говорим ? Для этого существуют события. Мы можем выбрасывать событие записи в базу данных, и его обрабатывать. Нам не важно что и как происходит в этой логике. У нас есть событие и есть его обработчик. Они могут быть в любых прослойках нашего приложения.
Научить???
var WebSocketServer = new require('ws');
var webSocketServer = new WebSocketServer.Server();
Научил ? Когда он мертв мертво наше приложение. Не понимаю дальше о каких демонах вы говорите, почему их несколько, может быть и можно ими управлять но зачем ?

Если я не понимаю чего нибудь покажите статью где это решение описано лучше. Может быть реально я чего то не знаю.

[Дмитрий Энтелис]

whats: и Вы, и я - изрядно додумали вопрос автора, но я в своих додумках ушел возможно в сторону.
Возможно меня подвели кейсы из проектов которые я наблюдаю в последнее время - у нас приложения на node.js занимаются только вебсокетами и ничем другим.
Что именно автор имел в виду - мы наверное не узнаем пока автор не появится.

В случае если у человека единое приложение на node.js реализующее в том числе и вставку в базу - Ваш вариант за номером 1 бесспорно является правильным.

[Дмитрий Энтелис]

whats: Но вообще мы сильно отклонились от вопроса автора. Он спрашивал не как уведомить юзера - а как узнать об обновлении базы данных. Мне все таки думается что если у автора в базу пишет его же приложение - он бы дошел до идеи вызвать событие внутри приложения)

[whats]

Дмитрий Энтелис: По описанному вами вы перекинули задачу на пхп где есть и демоны и воркеры. В ноде же этого нет, там 1 процесс с очередью разбора запросов. Можно так же в приложении и хранить изменение данных и брать их из переменной процесса, даже если у нас нет сокетов. Но если уйти от варианта с нодой и вернуться к Пхп то ваш вариант с рэббитом проигрывает обычному запросу к базе. Потому что все что вы описали нужно настраивать и с очередью.

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

вот это все какой то вакуум не из этой задачи. Так что во второй раз вы не попали с дополнительным стеком.

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

[Дмитрий Энтелис]

whats
С чего чего Вы взяли что в ноде 1 процесс? Можно отлично запускать пачку процессов ноды. По одному на ядро вполне оправдано.
Прямой селект из базы можно применять в ничтожном количестве случаев - вам должно быть пофиг на скорость реакции на событие, вам должно быть пофиг на контроль за обработкой данных, вам должно быть пофиг на распределение обработки между процессами - да на все пофиг по сути.
"Лишь бы работало"

[whats]

Дмитрий Энтелис: ну пошли лялял не по теме, вы опять чушь начали нести. Так что закрываем ее. Про пачку я знаю, но смысл очереди при этом не меняется.

[Дмитрий Энтелис]

whats: Ок, удачи.

Answer 3

[Вячеслав Успенский]

Если вы вставляете в базу из приложения то там же и организуйте оповещение всех связанных объектов.
Если сторонними методами то таймер - вполне нормальное решение, но запрос лучше использовать prepared (если у вас драйвер использует нативные prepared ане эмуляцию, но под нод я вроде таких не видел)