альтернатива опросу базы данных?

Question

У меня есть приложение, которое работает следующим образом: машины Linux генерируют 28 различных типов писем клиентам. Письма должны быть отправлены в формате .docx (формат Microsoft Word). Секретарь поддерживает шаблоны MS Word, которые автоматически используются при необходимости. Отказ от использования MS Word не вариант.

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

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

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

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

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

Существует ли ноль или почти нулевое программное обеспечение для конфигурации / обслуживания, которое могло бы достичь этого? Какие есть варианты?

X

Answer 1

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

Должно быть, приятно, чтобы все работало так гладко, чтобы вы смотрели на вещи, которые, возможно, только можно улучшить!

Answer 2

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

Если вы просто хотите уменьшить нагрузку на БД, вы можете создать таблицу с одной строкой: последний идентификатор задания. Затем клиентам просто нужно сравнить это со своим последним идентификатором, чтобы увидеть, нужно ли им провести полный опрос реальной таблицы. Таким образом, накладные расходы должны быть значительно сокращены, если это сейчас является проблемой.

Answer 3

Существует ли ноль или почти нулевое программное обеспечение для настройки / обслуживания, которое могло бы достичь этого? Какие есть варианты?

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

1. какой-то триггер, который запускает ваш исполняемый файл с использованием вызовов командной строки (sp_cmdshell)

2. с использованием COM-объекта, который SQL Server может открывать и запускать

3. использование задания агента SQL для запуска сценария VBScript (что снова будет считаться "опросом")

Эти параметры немного нелепы, учитывая, что то, что вы уже сделали, намного проще.

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

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

Answer 4

В отличие от Postgres и SQL Server (или хранилищ объектов, таких как CouchDb), MySQL не генерирует события базы данных. Однако есть некоторые шаблоны кодирования, которые вы можете использовать для имитации этого.

Если у вас есть одна или несколько таблиц, которые вы хотите отслеживать, вы можете создать триггеры для этих таблиц, которые добавят строку в таблицу «изменений», которая записывает очередь событий для обработки. Ваши триггеры фильтруют подмножество изменений данных, которые вас интересуют, и создают записи в таблице изменений для каждого события, которое вы хотите выполнить. Поскольку этот шаблон очередей и сохраняет событий, он работает хорошо, даже когда рабочие, обрабатывающие эти события, имеют перебои.

Вы можете подумать, что MyISAM - лучший выбор для таблицы изменений, так как она в основном выполняет записи (или даже MEMORY, если вам не нужно сохранять события между перебоями сервера базы данных). Однако имейте в виду, что и Memory, и MEMORY, и MyISAM имеют только блокировки полной таблицы, поэтому ваш триггер на таблице InnoDB может попасть в горлышко бутылки при выполнении вставки в таблицу MEMORY и MyISAM. Вам также может потребоваться InnoDB для таблицы изменений, если вы используете ON DELETE CASCADE с другой таблицей InnoDB (требуется, чтобы обе таблицы использовали один и тот же механизм).

Вы также можете использовать SHOW TABLE STATUS, чтобы проверить время последнего обновления таблицы изменений, чтобы проверить, есть ли что выполнить. Эта функция не будет работать для таблиц InnoDB.

В этих статьях более подробно описываются некоторые альтернативные способы реализации очередей в MySQL и даже избежания опроса!

• Как уведомить слушателей событий в MySQL
• Как реализовать очередь в SQL
• 5 тонких способов использования MySQL в качестве очереди и почему это вас укусит