Разве плохо запускать задания cron для опроса из огромной таблицы запланированных заданий?

Question

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

Когда действие, обнаруженное заданием cron, готово к выполнению эта запись будет помечена как done после отправки сообщения через SQS. Существует API, который позволяет другим службам проверять, было ли запланированное действие уже выполнено. Поэтому необходимо хранить историю этих done записей.

Однако меня беспокоит вопрос о том, является ли подобный дизайн масштабируемым в долгосрочной перспективе. Есть около 200 тысяч запланированных мероприятий в день или даже больше в некоторые дни. Поскольку я веду записи, помечая их как done после их завершения, я беспокоюсь о том, что таблица в конечном итоге станет очень большой с десятью миллионами строк и станет проблемой для выполнения задачи cron так же часто.

Справедливо ли мое беспокойство даже при правильно проиндексированной таблице? В противном случае, какие еще альтернативы я могу спроектировать, если мне нужно было каким-то образом сохранить эти запланированные действия для cron или что-то для опроса и проверки, когда они готовы к запуску?

Я использую Postgres базу данных.

Answer 1

С правильным индексом у задачи cron не должно быть серьезных проблем. У вас может быть частичный / отфильтрованный индекс, например

create index on jobs (id) where status <> 'done'.

Чтобы размер индекса был небольшим. Запрос должен соответствовать индексу где предложение.

Я использовал (id) только потому, что пустой список не разрешен, и поэтому что-то должно быть там. Исходя из вашего комментария, schedule_dt может быть лучшим выбором. Если вы включите все выбранные столбцы, вы можете получить сканирование только по индексу. Но если вы этого не сделаете, он все равно будет использовать индекс, ему просто нужно посетить таблицу, чтобы выбрать столбцы для этих указанных c строк. Я подозреваю, что попытка сканирования только по индексу не будет вам того стоить, поскольку нужные вам страницы, вероятно, не будут помечены как видимые, поскольку изменения были внесены в соседние кортежи всего за одну минуту go.

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

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

Таблица, размер которой увеличивается без ограничений, вероятно, представит управление проблемы помимо работы cron. Конечно, сервисам не придется оглядываться на месяцы, чтобы сделать это, не так ли? Не могли бы вы удалить готовые работы через несколько дней? Что если служба пытается найти работу и вместо того, чтобы найти ее «выполненной», просто не находит ее вообще?

Я не думаю, что работа cron по своей сути является проблемой, но она было бы чище не иметь его. Почему тот, кто вставляет задание, просто не вызывает SQS в режиме реального времени?

Answer 2

До тех пор, пока количество строк, которые должен получить запрос задания cron, остается постоянным, и вы можете использовать индекс, размер таблицы не будет иметь значения.

Сканирования индекса O (n) относительно количества отсканированных строк и O (log (n)) относительно размера таблицы. Чтобы быть более точным c, увеличение размера таблицы в 10–200 раз (меньший размер ключа индекса приводит к лучшему разветвлению) заставит сканирование индекса использовать еще один блок, и этот блок обычно кэшируется.

Если таблица становится большой, вы все равно можете рассмотреть вопрос о секционировании, но в основном для эффективного избавления от старых данных.