Это плохо для "мониторинга" таблицы базы данных, постоянно запрашивая PRIMARY_ID> lastProcessedId

Question

Я индексирую таблицу MySQL в ElasticSearch (полнотекстовый поиск).Вместо отправки каждой новой строки во время ее создания, мы делаем SQL-запрос каждые N секунд (~ 30 секунд) для новых записей в этой таблице.Мы делаем это, сохраняя идентификатор последней обработанной записи (auto_increment) и выполняя запрос вроде:

SELECT * FROM myTable where id > lastProcessedId

Мой вопрос: это хороший способ справиться с этим?Есть ли критические недостатки?Есть ли лучшие альтернативы?

Мы также планировали использовать тот же подход для обработки лайков пользователей (стиль facebook).Каждые N секунд мы выполняем SQL-запрос, чтобы получить последние «лайки», затем обрабатываем их и обновляем временную шкалу каждого пользователя.

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

Есть какие-нибудь мысли или проблемы с этим решением?

Answer 1

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

Есть и другие места, где вы можете поместить данные для последующего сбора и обработки, вместо того, чтобы перемещаться по базе данных. Вы можете использовать что-то столь же простое, как добавление сериализованной копии в файл, запись новой каждые 30-60 секунд и затем скрипт, обрабатывающий предыдущие необработанные файлы. Точно так же вы можете поместить их в какую-то другую очередь, а затем запускать ее так часто, как хотите.

Answer 2

Звучит дорого, я бы рассмотрел другие подходы.

1. Измените старый код, чтобы индексировать материал при вставке!Я знаю, это может быть страшно, но так ли это плохо?:)
2. Создайте триггер вставки, который каким-то образом запустит процесс переиндексации, я думаю, у вас может быть множество вариантов, как его создать.

Проверьте, http://www.roseindia.net/sql/trigger/mysql-trigger-after-insert.shtml